※本記事は、こちらの記事を和訳したものです

序章

航空機が音速を超えると、衝撃波が発生する。衝撃波は周囲の空気が伝わる速度よりも速く移動するため、周囲の空気がその擾乱を吸収しきれず、不連続性が生じる。これがソニックブームである。

池の水面に広がる波紋のように、衝撃波は外側へと伝播し、その影響は距離とともに薄れていく。AIサービスの需要は、技術サプライチェーンが吸収できる速度をはるかに超えて拡大している。マイクロソフトのCEOによれば、当初は大規模な言語モデルの学習と実行にGPUが必要だったが、今ではそれらを動かすためのエネルギーが課題となっている。こうした波紋は私たちの日常生活にも波及し、データセンターの需要が電力網の容量を圧迫するにつれて電気料金が高騰し、限られた半導体供給を巡って家電製品同士の競争が激化するにつれて、家電製品の価格も上昇している。

物理的なサプライチェーンは、ソフトウェアのようなスピードで変化に対応できない。半導体工場や発電所の建設には、数十億ドルもの設備投資と数年にわたる期間、そして建設と運営に必要な人材が不可欠である。需要が明確で資金も潤沢にある場合でも、生産能力を一夜にして拡大することはできない。この媒体は、急激な変化に抵抗する。

物理的および経済的な制約によって計算能力が制限される世界において、ソフトウェアアーキテクチャはますます企業戦略の表現としての役割を担うようになっている。それは、顧客の需要と希少で高価なリソースとのバランスを取り、それによって何が拡張可能で、何が停滞し、何が非経済的になるかを決定する。

豊富な資源に基づいて構築されたソフトウェア

数十年にわたり、ソフトウェアはハードウェア性能の着実な向上という環境の中で発展してきた。ムーアの法則のおかげでトランジスタ数は約2年ごとに倍増し、より高速なプロセッサ、より高速なネットワーク、そしてより多くのメモリが実現した。デナードのスケーリングは、トランジスタ密度の向上と駆動電圧の低下によって電力密度を抑制することで、この進歩を持続させることを可能にした。しかし、メーカーがマルチGHz帯に進出し、コア電圧がトランジスタの閾値電圧に近づくにつれて、この傾向は鈍化した。小型化に伴う非効率性が増幅されたことも相まって、電力密度は持続不可能な熱特性に近づいた。

IntelのXeon 6やAMDのEPYC 9005シリーズといった最新のハイエンドデータセンターCPUは、前世代と同じクロック周波数範囲で動作し、性能向上の大部分はシングルコア性能の向上ではなくコア数の増加によるものであり、ソケットあたり200コア近くに達することもある。しかし、キッチンで料理人を増やしても必ずしも夕食の準備が速くなるわけではないように、コア数を増やしてもコンピュータの速度が自動的に向上するわけではない。マルチコアCPUは高度な協調メカニズムを必要とし、これらの新たな協調の課題をソフトウェアに押し上げ、ロック、セマフォ、そして並列コンピューティングに特化した研究分野を生み出した。これらの概念は、ソフトウェアチームに大きな認知負荷をかけ、顧客に機能を提供する方法だけでなく、基盤となるハードウェアの利用率を最大化して高性能なユーザーエクスペリエンスを提供する方法についても考えなければならない。

ハードウェアによってもたらされるこうした複雑さに対処するために、私たちは詳細を隠すための抽象化を作り出す。モバイルアプリ開発者はAPIのことだけを考えればよく、3GPPやLTEといったAPIを支えるセルラー技術を理解する必要がない。ウェブサイトを構築する人は、豊富なアニメーションやグラフィックに集中でき、それらを支えるグラフィックレンダリングパイプラインについて心配する必要はない。ジョン・オースターハウトは著書『ソフトウェア設計の哲学』の中で、この原則を的確に捉えている。つまり、複雑さをカプセル化するシンプルなインターフェースを備えた「深い」モジュールを構築することで認知負荷を軽減し、組織の拡張性を高めることができる。

パブリッククラウドの登場はこの抽象化をさらに推し進めた。物理的なコンピューティングリソースはAPIの背後に移り、サーバーの調達やデータセンターの稼働開始を待つ必要がなくなった。新しいコンピューティングクラスターはクリック一つで利用できる。すべてのハードウェアを調達するために必要な設備投資さえも、従量制の運用費用として抽象化された。クラウドプロバイダーは規模の経済性を活用することで、一見すると豊富なコンピューティングリソースを提供し、摩擦をほとんど感じることなく、数千台のサーバーに垂直方向および水平方向に拡張できる選択肢を与えた。今や、特定のソフトウェアパフォーマンスの課題を、単により多くのコンピューティングリソースとメモリを投じることで、つまり資金調達によって解決するオプションが生まれたのだ。しかし、現代のワークロードの要求の急激な変化により、これらの回避策の一部が限界に達し始めている。

メモリの逼迫

抽象化は問題を分解し、人間が扱いやすくするのに役立つが、根本的なパフォーマンス上の課題を解決するものではない。並列化されたワークロードが増加するにつれて、特にGPUやその他のアクセラレータにおいて顕著に見られるように、課題は並列計算を実行することから、十分なデータを効率的に供給することへと変化した。

1990年代後半にNvidiaによって普及したGPUは、もともと並列化が容易で反復的なグラフィックス処理パイプラインを高速化するために開発された。これらの特殊な技術は並列処理の限界を押し広げてきた。実際、最新のデータセンターGPUは数万個のコアを搭載し、同時に動作して毎秒数千兆回の計算を実行する。追いきれないほどのゼロの数である。同様に、数万人の料理人がいるキッチンでは、全員を忙しくさせるために大量の食材が絶えず流れなければならない。演算コアにデータを流し込むこの能力、しばしばメモリ帯域幅と呼ばれるもの、は容易にボトルネックになり得る。

メモリ技術は長年にわたって進歩してきたが、トランジスタと電力密度の課題によりシングルコアCPUのパフォーマンス向上が大幅に鈍化したのと同様に、メモリ密度の向上も鈍化している。より多くのメモリチップを並列に配置することで帯域幅を拡張できるが、PCB上の物理的なスペースは有限であり、密度と帯域幅は相互に関連する制約となる。高度に並列化されたワークロードは、対応する大量のメモリと、データをやり取りするための帯域幅を必要とする。ほとんどのコンピュータは、半世紀前に誕生して以来、何度か改訂されてきたDRAMと呼ばれるメモリ技術を使用している。最新の改訂版であるDDR5は、チャネルあたり50GB/秒以上を実現しており、DDR4の約2倍の速度である。これらは大きな進歩だが、GPUの性能が向上するにつれて、大規模言語モデルのワークロードはメモリにさらに多くのものを要求するようになった。計算能力が利用可能なメモリ技術を追い越すこの現象は、しばしば「メモリの壁」と呼ばれる。

このメモリの壁を打破するのに役立つ技術の一つが、HBM（高帯域幅メモリ）だ。2010年代半ばに初めて登場したHBMは、メモリチップを垂直に積み重ねることで、より高いビット密度と帯域幅を実現する。各階に専用エレベーターを備えた高層マンションを想像してみよう。これにより、より多くの人が同時に建物に出入りできる。シリコンを積み重ね、これらの「エレベーター」を織り込む複雑な工程のため、HBMは標準的なDRAMと比較して製造工程における歩留まりと効率に課題を抱えている。この課題に加え、ハイパースケーラーからの需要も、今日見られるメモリ不足の一因となっている。GPUサプライチェーンで始まった衝撃波は、メモリにまで及んでいる。

CPUは中心的な役割を担わなくなる

今日のメモリ制約が顕在化するずっと前から、ハードウェアとソフトウェアのアーキテクチャは、スループットの向上と専門化の進展に対応するために再編成されてきた。過去10年間、シングルコアCPUの性能はほぼ停滞している一方で、ネットワーク帯域幅は桁違いに増加した。現代のオフィスネットワークは一般的にギガビットイーサネットで配線されており、ほとんどのデータセンターは現在100GbEをはるかに超える速度で稼働している。わずか2年前の2024年には、800GbEが標準化された。これは、4K映画1本を1秒未満で転送できる十分な帯域幅であり、単一のCPUコアが処理できる速度をはるかに上回る。

GPU間通信の需要の高まりが、高帯域幅化の傾向を加速させている。今日の大規模言語モデルは非常に大きいため、単一のGPUでは実行できない。GPUのクラスタ全体が必要となる。データ量が単一のCPUで効率的に処理できる量を超えて増加するにつれ、最新のシステムはCPUをデータパスから切り離すことで対応してきた。高速トラフィックをCPU経由でルーティングするのではなく、専用のシリコンがデータ転送を直接処理し、CPUはオーケストレーションの役割を担い、操作の設定、ポリシーの適用、例外処理を行う。NVLinkなどの専用インターリンクはこの変化を象徴するものであり、CPUを経由せずにGPU同士を直接接続することで、低ジッター、低遅延、高帯域幅を実現する。

このパターンはGPUに限ったものではない。イーサネットNIC（ネットワークインターフェースカード）は、高度なコンピューティングデバイスへと進化し、VXLANなどの最新のカプセル化プロトコルからRDMA（リモートダイレクトメモリアクセス）などの技術まで、あらゆる処理をCPUからオフロードできるようになった。従来、NICはネットワークパケットをオペレーティングシステムのネットワークスタックに渡し、ネットワークスタックがペイロードを抽出してユーザー空間プロセスに転送して処理を行っていた。しかし今日では、ネットワークトラフィックが高速すぎて、CPUによる効率的な処理が困難になっている。現代のデータセンターの基準からすると比較的平凡な100Gbpsでも、単一のCPUコアでネットワークを飽和させることはほぼ不可能である。ネットワークが高速すぎるため、CPUは利用可能な帯域幅を十分に活用できるほど十分なバイト数を迅速に送信することができない。このCPUボトルネックを回避するため、NICはCPUの関与なしに、RAMから直接データを読み込み、処理し、ネットワーク経由で送信する。

同様に、ストレージの世界では、NVMe SSDはCPUを介してデータを処理する代わりに、PCIeバス上でDMA（ダイレクトメモリアクセス）を利用してシステムメモリとの間でデータを転送する。これは、レストランの荷降ろし場からパントリーまで専用の独立した経路を作り、厨房の料理人が食材を運ぶ手間を省くことと同じようなものだ。ストレージとネットワークの両方におけるこれらの進歩により、NVMe-oF（NVMe-over-Fabrics）などの技術を利用して、ネットワーク経由でリモートのNVMeドライブにほぼローカル接続と同等の速度でアクセスできるようになった。これらの技術は、最新の高度なNICを活用して高帯域幅のデータ転送をCPUからオフロードする。

ワークロードパターンの変化に伴うこうした技術的変化は、ハードウェアだけにとどまらない。大規模な需要ショックはシステムが動作する環境そのものを再構築し、ソフトウェアアーキテクチャはシステムが動作するハードウェアと一緒になって処理を行う。

物理とソフトウェアが出会う場所

データベースは、コンピューティング、メモリ、ストレージ、ネットワークの交点に位置し、これらのダイナミクスを非常に明確に把握できる。データベースは性能の技術的な限界で動作し、レイテンシとスループット、一貫性と可用性など、様々なトレードオフを強いられる。

Cassandraなどの有名なデータベースで採用されているシェアードナッシング（Shared Nothing）アーキテクチャは、リソースの完全な分離を重視し、各ノードが独自のCPU、メモリ、ストレージを備えている。他のノードへの依存関係はないが、ワークロードが一定でない場合、ハードウェアリソースがアイドル状態になる可能性があることを意味する。CPU、メモリ、ストレージの比率は動的に変更できないため、ハードウェア利用率を最大化するには、比較的安定したワークロードパターンが必要となる。イベントログ用のデータベースは、大容量のストレージを必要とするが、読み取りクエリは非常に少ないため、計算要件は低くなる。eコマースストアで使用される製品データベースは、買い物客からの読み取りクエリが多数発生する可能性があるが、ストレージ容量は比較的少なく、販売される製品数に応じてのみ拡張される。言い換えれば、シェアードナッシングアーキテクチャでは、リソース比率のミスマッチがアイドル状態のシリコンへの支払いやパフォーマンスのボトルネックに直結する可能性がある。

対照的に、シェアードストレージアーキテクチャは、データストレージ層をCPUやメモリなどのコンピューティングリソースから分離する。この概念は、GoogleがBigQueryで初期に取り組んだことに端を発している。これにより、CPUとメモリのリソースをストレージ要件とは独立して拡張できるため、特にクラウド環境において、より高いリソース利用率を実現できる。2025年にDatabricksに買収されたデータベース企業Neonは、コンピューティングとストレージの分離を可能にするために、Postgresストレージ層の大部分を再設計した。これにより、データ量とは独立して負荷に応じてリソースをスケールアップおよびスケールダウンできるようになり、常時専用リソースを必要としない一種の「サーバーレス」データベースが実現した。

ElasticsearchやClickHouseのようなシステムもこれと似たシェアードストレージアーキテクチャを採用しており、Amazon S3などのサービスからの安価で耐久性の高いオブジェクトストレージの可用性によって実現されることが多い。これらのストレージサービスは、読み取り後書き込み整合性や条件付き書き込みのようなプリミティブを提供することで、同時読み取りと書き込みを処理できる分散した一貫性のあるストレージを提供するという難問を解決に貢献する。Apache IcebergやDelta LakeといったオープンなLakehouseフォーマットは、この変化を象徴するものであり、コモディティ化された共有ストレージの上に、より高レベルのデータセマンティクスが重ねられている。

ベクトル埋め込みを利用したAI関連サービスの需要が急増したことで、ベクトル検索を中心とした新しいデータベース開発が急増し、この分離が主流になりつつある。現在の最先端のベクトル検索アルゴリズムには、複雑なチューニングなしで動的な挿入とリコール性能のバランスが取れていることから多くのデータベースで採用されているHNSW（階層型ナビゲーション可能なスモールワールド）のバリエーションが含まれている。しかし、これらのグラフベースのアルゴリズムは、メモリ内のデータ構造を走査する必要があるため、メモリをかなり消費し、データベースの計算コストを増大させる。ストレージ容量とは独立して計算リソースを動的にスケールアップおよびスケールダウンできるアーキテクチャを採用することで、データベースは限られたハードウェアリソースの利用率を高めることができる。

ワークロードパターンが変化し、ハードウェアが進化するにつれて、データベースアーキテクチャは、そのアーキテクチャに内在するトレードオフを浮き彫りにせざるを得なくなった。今日の状況では、コンピューティング、メモリ、ストレージ、ネットワークという4つの柱をどれだけ密接に結合するかという決定は、パフォーマンス特性だけでなく、ハードウェアの利用率、コスト、スケーラビリティにも影響する。データベースはシステムの物理的な限界に近い位置にあるが、その根底にあるダイナミクスはデータベース特有のものではない。ソフトウェアが強い制約の下で動作する場合、アーキテクチャの選択は技術的な成果だけでなく、経済的な実現可能性にも影響を与え始める。ここに明確な答えはない。どのアーキテクチャも、どの制約が最も強く影響するかという賭けを内包している。それを誤ると、もはや存在しない世界に合わせて最適化したことになる。

圧力下における抽象化

抽象化は無料ではない。それらが生み出された環境の前提条件に従って価格付けられている。数十年にわたり、ハードウェアの普及が進んだことで、そのコストは容易に無視されてきた。しかし、物理的な制約が強まるにつれて、抽象化に内在する隠れたコストが再び明らかになりつつある。

抽象化の中には、実質的にコストがかからないものもある。例えば、スマートポインタやジェネリクスなどが挙げられる。これらのメカニズムは、実行時のパフォーマンスを損なうことなく、開発者の認知負荷を軽減する。一方、コストがかかるものもある。ガベージコレクションは、実行時に一時停止が発生する代わりに、開発者が変数のライフタイムを管理する必要をなくす。仮想関数は、パフォーマンスの低下と引き換えに、実行時の動的なディスパッチを可能にする。組み込みシステムや高性能コンピューティングでは、C、C++、Rustといった言語が広く使われている。これらの言語は、開発の複雑さや認知負荷を犠牲にして、実行時の動作を制御可能にする。これは、すべてのバイトとすべてのサイクルに目に見えるコストがかかる状況では、合理的な選択と言える。

現代において最も重要なソフトウェアの一つであるLinuxカーネルは、ユーザー空間のプログラムがハードウェアの詳細を気にしなくて済むようにしてきた。そのシステムコールはハードドライブやNICに関する詳細を抽象化し、メモリ、ファイル、ネットワークのようなプリミティブを扱うための安定したインターフェースを公開する。カーネルはドライバーを通じてハードウェアを直接管理・通信し、最終的にそれらを抽象化された汎用リソースとしてユーザー空間に提供する。これらは抽象化だけでなく、関心の分離も提供する——カーネルはハードウェアリソースが適切に管理・保護されることを保証し、ユーザー空間はユースケースにより集中する。

ハードウェアの限界で動作する場合、これらの抽象化のパフォーマンスオーバーヘッドは、利点を上回り始める可能性がある。ネットワーキングとストレージ技術がCPU性能に対して大幅に進歩するにつれ、増大する需要に追いつくソフトウェアの能力が重要になる。メモリのコピーやコンテキストスイッチは、毎秒数百万回繰り返されると、その負荷が蓄積される。LLMベースのサービスに対する現在の需要は、こうしたプレッシャーを大幅に加速させている。その衝撃波は、ハードウェアの不均一な進歩によって既に負荷がかかっていた抽象化全体に波及し、もはや無視できないコストを露呈させている。

例えば、数十ギガバイトものリアルタイム高解像度ビデオをネットワーク経由でSSD搭載のリモートストレージデバイスに送信するアプリケーションを考えてみよう。データは、ビデオ送信アプリケーションのユーザー空間メモリからカーネル、NIC、光ファイバーケーブルを経由して受信側のNIC、受信側のカーネル、ユーザー空間、そして再びカーネルへとコピーされ、最後にSSDに書き込まれる。各ステップでデータは再配置され、時には仮想的なデジタルエンベロープにカプセル化され、受信側で取り出される。コンピュータからより多くのパフォーマンスを求めるにつれ、この仮想的な書類のやり取りのオーバーヘッドが明らかになる。

このシャッフルは、カーネルとユーザー空間の抽象化レイヤーの結果だ。データはカーネルを介して出入りする。2010年代後半、データセンターのネットワークは100Gbpsを超え、この抽象化を回避する「近道」を見つけたいという要望が高まった。DPDK（Data Plane Development Kit）は、カーネルの抽象化を完全にバイパスし、カーネルを介さずにユーザー空間アプリケーションがNICと直接通信できるようにする業界標準フレームワークである。ネットワークスタックの責任をアプリケーションに移し、カーネルのセキュリティ保証と多重化機能の一部を犠牲にする代わりに、処理速度を向上させる。メモリコピーとコンテキストスイッチを削減することで、DPDKは、高帯域幅でパフォーマンスを重視するアプリケーションが、カーネルを経由する場合と比較して2～3倍の効率を実現できるようにしている。DPDKにはトレードオフがあり、万能の解決策ではないが、機会費用の方程式が変化するにつれ、業界がこれらの抽象化の境界を再構築するために動いてきた多くの方法の一つだ。

環境の変化、技術の進歩、ワークロードの変化に伴い、抽象化の概念を再検討する必要が生じている。コスト、パフォーマンス、経済性に関する暗黙の前提は、プレッシャーがかかった時に明確になる。これらのマクロな動きに気づかないか、適応を拒むことは、隠れた負債の一形態を積み重ねる——システムとプロダクトは健全に見えるが、負荷がかかると破綻してしまうのである。

ハードウェアへの意識

2025年以降にリリースされたデータセンター向けGPUには、数年前には存在しなかった4ビットおよび8ビット浮動小数点表現であるFP4とFP8での動作に特化したモジュールがシリコンに組み込まれている。これらの超低解像度数値表現は、LLMのメモリ効率と演算効率を向上させるために開発されたものであり、トランジスタレベルのハードウェアに組み込まれているという事実は、新たなワークロードとハードウェア設計の密接な連携を反映している。ソフトウェア要件に関する想定は、ハードウェアが急速に変化するワークロードパターンに適応するにつれて、短期間でシリコンに組み込まれていく。

同様に、CUDAエコシステムにおける専用ライブラリであるFlashAttention-3は、最新のNvidiaアーキテクチャで導入されたLLM最適化ハードウェアプリミティブを活用することで、トランスフォーマーベースの学習と推論を高速化している。これは、動作対象ハードウェアに関する深い知識に基づいて記述されたソフトウェアであり、メモリ操作と計算処理を並列化します。GPUメーカーとソフトウェアエコシステム間の共同設計のペースは、この分野におけるハードウェアとソフトウェア開発の緊密な統合を示している。かつて数十年を要したソフトウェアのニーズと専用シリコンの間のフィードバックループは、今や数年に短縮されている。

物理的な制約が強い場合、ハードウェアへの意識は最適化のための手段から戦略的な手段へと変化する。しかし、パフォーマンスがハードウェア固有の機能の活用にますます依存するようになると、それらの機能を制御する者が優位に立つことになる。共同設計は価値を生み出すが、同時に依存関係も生み出す。パフォーマンスへの道がベンダー固有のシリコンを通る場合、抽象化レイヤーを誰が制御するかという問題は、市場支配力の問題となる。

半導体ベンダーは、顧客を自社ハードウェアに囲い込む強い動機を持っている。ベンダー固有の機能を使用するかどうかというアーキテクチャ上の選択はすべてが賭けであり、今日のパフォーマンスを犠牲にして将来の柔軟性を確保するか、パフォーマンスを犠牲にして選択の自由を維持するかの選択となる。抽象化は最小公倍数効果に直面し、すべてのハードウェアプラットフォームに共通する機能はコモディティ化されたものだけとなる。限られたハードウェアリソースからパフォーマンスを引き出すには、最新かつ最高のハードウェア機能を活用するための抜け道が必要となる。これらの機能は、移植可能な抽象化の外、ベンダー固有の扉の向こう側に存在する。

機械学習の分野では、XLA、TVM、Tritonがこの緊張関係を典型的に表している。これらのコンパイラ技術は、高レベルモデルをハードウェア固有の実行可能コードに変換することで、PyTorchなどのフレームワークが比較的ハードウェアに依存しない状態を維持し、多様化するハードウェア環境において選択肢を確保できるようにしている。Googleは、LLMが主流になる何年も前に導入した自社開発のTPU（テンソル・プロセッシング・ユニット）と呼ばれるチップ上でLLMを実行するために、XLAに多額の投資を行ってきた。彼らはシリコンとコンパイラの両方を構築した。抽象化レイヤー自体が、独自のハードウェアを活用してパフォーマンスを向上させつつ、ソフトウェアスタックを外部のチップサプライヤーへの依存から切り離す戦略的な資産となった。

しかし、制約条件下でパフォーマンスを最大化するためにハードウェアの認識が重要であるにもかかわらず、その影響は一様ではない。共同設計には、エンジニアリング作業、人的資本、そして複数の技術分野にわたる長期的なメンテナンスにおいて、多大なコストがかかる。このコストを償却できるのは、これらのアーキテクチャ上の選択が持続的にサポートできる場合に限られる。結果として、ハードウェア認識を最大限に活用できるのは、規模、資本、そして長期的な計画期間が既に存在する分野に集中する傾向がある。そして、この分野で最も有利な立場にあるのは、パブリッククラウドプロバイダーである。

豊かさの後のクラウド

クラウドコンピューティングは、大規模な運用には物理インフラの所有が不可欠だった時代に登場した。導入にはサーバー、ネットワーク、電力契約などに数百万ドルもの費用がかかり、キャパシティプランニングには多額の資本が必要だった。また、企業はリソースの利用率が低いリスクを負わなければならなかった。

クラウドコンピューティングの主要な価値提案の一つは、計算リソースを豊富かつ代替可能に見せることだった。弾力性はクラウド利用者にとって当然の前提となり、キャパシティプランニングを後回しにできるほどになった。開発者はピーク需要に対応するためにリソースを準備する必要がなくなり、クラウドプロバイダーが提供する事実上無限のサーバー群から必要なリソースを引き出し、使用した分だけ料金を支払うだけで済むようになった。

このモデルは、必要な時にインフラが十分に利用可能であること、価格が予測可能であること、そして規模の経済性を活かせるプロバイダーが遊休設備の利用リスクを吸収するという暗黙の前提に基づいていた。規制はなかったものの、数十年にわたる継続的なハードウェア改良による豊富な供給量と、ハイパースケールクラウドプロバイダー間の競争が相まって、これらの前提は概ね維持されてきた。

今日のGPU、メモリ、電力といった物理的な制約のある世界では、その均衡は崩れつつある。弾力性はもはや無条件ではない。供給は迅速に対応できず、需要は衰える兆しを見せない。供給と需要の両方が非弾力的になると、供給量と価格は想定される環境条件ではなく、不確実性の要因となる。

クラウドプロバイダーはこれまで概ね製品の価格改定を避けてきたが、実際には使用量に応じた課金ではなく、割り当て量に応じた課金を行っている。容量へのアクセスは、クラウドプロバイダーとの事前契約、最低利用額契約、長期契約によって、いわば順番待ちの列に並び続けることがますます重要になっている。柔軟性は、可用性と商用契約に左右されるようになった。

物理的な制約がある状況下では、クラウドプロバイダーはインフラサービスプロバイダーというよりも、むしろ資本配分者に近い存在と言える。その規模の大きさによって、希少なリソースへの優先的なアクセスと価格設定が可能となり、さらにリソースを自社で開発する選択肢も得られる。マクロレベルでは、リソースの調達を一元化し、下流のクラウド顧客にアクセスを再分配すると同時に、大規模なユーザーベース全体でリスクを分散させる。

クラウドコンピューティングは、システムから設備投資をなくしたわけではない。むしろ、設備投資を集中させたのだ。リソースが豊富にある時代には、その集中はほとんど目立たなかったが、リソースが不足する時代には、それが顕在化する。クラウド自体は依然として存在するが、その役割は変化した。物理的な制約に対する仮想的な緩衝材から、そうした制約の中でリソースを割り当てるためのメカニズムへと変化したのである。

現実の厳密さ

クラウドが物理的限界に対する緩衝材として機能しなくなるにつれ、それらの限界はソフトウェアシステム自体の中に再現される。デナードのスケーリングが鈍化するにつれて、複雑さがハードウェアからソフトウェアへと移行したのと同様に、今度はリソース不足の問題がクラウドインフラストラクチャからより高レベルのソフトウェアへと押し上げられていく。何を抽象化し、何を構築し、何を最適化するかという決定は、コスト構造、利益率、そして競争優位性を直接的に左右する。これらの決定をもはや後回しにはできない。

これは理論上の話ではない。電力、メモリ、コンピューティングといった分野では、需要が供給をますます上回っており、既にプレッシャーがかかっている。リソースの競合はもはや一時的な異常事態ではなく、エンジニアは日々の開発作業において、割り当てやレート制限に直面することが増えている。これらは、意図的なアーキテクチャ上の決定を必要とするトレードオフを迫られる、不均衡のシグナルだ。

すべての製品やビジネスがこうした限界で運用されているわけではない。多くの企業は、収益に対するコンピューティングコストが安価で、パフォーマンスが許容範囲内であり、規模が物理的な制約よりも人やプロセスによって左右されるような環境で事業を展開している。このような状況では、抽象化に注力し、より上位のボトルネックに焦点を当てることが合理的な判断となる。しかし、こうした状況は常に変化する。ワークロードが進化するにつれて、かつては当然と思われた前提が崩れることがある。アーキテクチャ上の決定は、将来の顧客需要、技術進歩、そして構造的な優位性がどこから生まれると予想されるかといった点に対する、一種のコミットメント、つまり賭けなのである。

アーキテクチャ設計は、物理的な制約と組織の意図とのインターフェースだ。基本原理から考えることで、制約について論理的に考察し、理想ではなく現実を直視したシステムを設計することができる。アーキテクチャをエンジニアリング部門に委任する技術的な決定事項として扱う組織は、暗黙のうちに、現在の抽象化を形作った環境が今後も存続するという賭けをしていることになる。すべてのシステムには、それが構築された世界に関する前提が組み込まれている。重要なのは、世界が変化する前に、それらの前提を検証することである。