
最近、『フェルマーの最終定理』(Simon Singh)を読み終えました。意外に思われるかもしれませんが、この本にはドラマや陰謀、殺人、愛人の話が満載でした。本当です。数学の歴史には、私たち凡人には到底理解できない概念を驚異的なまでに深く理解していながら、結局のところ一人の人間にすぎない人物が数多く登場します。
しかし、今日の本題はそこではありません。重要なのは、350年以上にわたり、数学者たちが「フェルマーの最終定理」として知られる命題を証明(または反証)しようと駆り立てられてきたことです。これは定理というより予想に近いものでした。優れた(アマチュア)数学者フェルマーは、ピタゴラスの定理はほぼ自明であるものの、成り立つのは平方の場合だけだと記しました。つまり、次の式を満たす解は存在しません。an + bn = cnただし、「n」が「2」以外の数の場合です。数学者たちを本当に熱狂させたのは、フェルマーがこの命題について実に見事な証明を得たものの、書き込みをしていた本の余白が狭すぎて記せない、と書き残したことだったようです。
そして、その証明はどこにも見つかりませんでした。
そこで数学者たちは、この主張を証明または反証しようと取り組み始めました。結論から言うと、ついに証明した人物が現れました。しかし、その証明には、まったく異なる2つの数学分野を組み合わせる必要がありました。いずれも、フェルマーがこの主張をした当時には存在しなかった分野です。その一部は、フェルマーの最終定理をはじめとする難解な数学問題を解こうとする試みに端を発しています。フェルマーの最終定理の証明に用いられた分野の1つには、楕円曲線の研究が含まれていました。楕円曲線という言葉に聞き覚えがあるとすれば、それは楕円曲線がECC(楕円曲線暗号)の基礎だからです。ECCは、従来の脆弱性がより高い暗号方式に代わるものとして、現在ますます支持されています。
要するに、ある数学分野の問題を解決することには、関連性はあるものの明確に異なる他の数学分野で、しばしばイノベーションが促されるという利点があります。
では、なぜタイトルに「ハードウェア」とあるのか、疑問に思われるかもしれません。ハードウェアは所詮ハードウェアではないか、と。あらゆるものがソフトウェア化し、アプリケーションを提供する今日の世界で、ハードウェアがいったいどのような有意義なイノベーションを促せるのでしょうか。
もちろん、ソフトウェアです。
データセンターの南北方向の通信経路に展開されるサービスに必要な容量と速度を確保するために独自のハードウェアを構築する場合、それに対応するソフトウェアも開発する必要があります。というのも、ほとんどの場合、ハードウェアだけでは単なるリソースにすぎないからです。この状況も変わりつつありますが、それについてはまた別の機会に取り上げます。現実には、ハードウェアが提供するのは主にリソースです。そのリソースを利用可能な形に変え、インターネット上で常時アプリを保護し、配信するサービスに活用できるようにするのが、ソフトウェアの力です。したがって、ネットワークの世界で新しいハードウェアの登場が注目されるとき、それは新しいソフトウェアの発表も意味します。ソフトウェアがなければ、カスタムハードウェアは十分に機能しないからです。
ここで、イノベーションがハードウェアとソフトウェアの垣根を越えます。そのソフトウェアは、元のハードウェアからコモディティハードウェア(COTS)へ移行できます。つまり、汎用サーバーです。あらゆる用途に対応する必要があるため、特定の用途には最適化されていないことから、そう呼ばれています。しかし、専用ハードウェア上で稼働していたソフトウェアは、最適化されており、エンジニアが長年にわたって学び、改良してきたノウハウも、ソフトウェア版に引き継がれます。
そして、その多くは実際、想像以上に幅広く応用できます。たとえばIntelなどのチップには、カスタムビルドのハードウェアで使用されている一方で、コモディティシステムにも同様に搭載されているものがあります。しかし、ほとんどのソフトウェアはそうしたハードウェアを想定して開発されていないため、通常、それらのチップが持つパフォーマンスや処理能力を高める特性を活用していません。一方、一部のシステムはそうしたハードウェアを想定して開発されています。そのため、そのソフトウェアをコモディティハードウェアへリフト&シフトしても、同じ目的で開発されながら専用ハードウェアを活用しない他のソフトウェアと比べて、パフォーマンスと処理能力の面で多くの優位性を維持できます。
ソフトウェアに伴うパフォーマンスと処理能力の課題を解決しようとした結果、1990年代には、システム内でデータを受け渡す方法に関する新たな内部アーキテクチャを含め、ネットワークでハードウェアが広く活用されるようになりました。現在では、パフォーマンスと処理能力を向上させるため、そうした工夫や技術が再びソフトウェアに取り入れられています。開発対象のハードウェアに対応するプラットフォームが存在しない状況で、高速かつ大容量のソフトウェアを設計する必要に迫られると、開発者は新たな手法を生み出します。従来の前提を見直し、システムを通過するデータを操作、検査、変更するための、より優れた方法を見いだします。また、メモリ管理やプロトコル解析を改善する新たなアルゴリズムと、より優れたデータ構造を考案します。
ハードウェアとイノベーションを結び付けて考える人は多くありません。しかし実際には、数学と同様に、ある分野の問題を解決することが、別の分野のイノベーションにつながります。F5のカスタムハードウェアプラットフォーム上で動作するBIG-IPソフトウェアを、プライベートクラウド、オンプレミス、パブリッククラウド環境で使用される汎用ハードウェアへリフト&シフトする際にも、これは常に見られます。リフト&シフトには作業が必要であり、仮想化、コンテナ化、クラウド化された形態に適合するようソフトウェアを調整しなければなりません。それでも、新しいハードウェアから生まれたイノベーションは引き継がれ、汎用プラットフォーム上でも、より高速でスケーラブルかつ効率的な運用を実現します。
新しいハードウェアを開発し、その新機能に合わせてソフトウェアを適応させることは、そのソフトウェアがカスタムハードウェアと汎用ハードウェアのどちらで稼働する場合でも、最終的にはソフトウェアのイノベーションにつながります。だからこそ、新しいハードウェアの登場には期待が高まります。それは、イノベーションの到来を告げるものだからです。
これが「ハードウェアのイノベーション定理」です。フェルマーの定理を解くことが数学全般のさらなるイノベーションにつながり、その進歩が暗号技術やセキュリティの領域にも波及するように、ソフトウェアを新しいカスタムハードウェアに適応させるという課題を解決することは、そのソフトウェアのさらなるイノベーションにつながり、今後何年にもわたってオンプレミスおよびクラウドのデータセンター全体に波及していくでしょう。
著者について

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。