インフラ設計について

インフラ設計も要件を実現するための具体化という点でアプリケーション設計と同じです。

アプリケーション設計は「処理の塊（コンポーネントや関数）」を具体化します。これに対してインフラ設計では「リソースの塊（サーバー、データベース、ストレージ、ネットワークなど）」を具体化していきます。

アプリケーション設計が「どう動くか」ならばインフラ設計は「どこでどう動かすか」です。

インフラ設計は信頼性・可用性・保守性・保全性・安全性といった指標と、機能要件や予算のバランスをとる作業です。

アプリケーション設計では、通常、フローという概念で考えます。リクエストが届き、ロジックが段階的に適用され、データが明確に定義されたブロックを通過してレスポンスが生成されます。まるで物語を最初から最後まで描いているような感覚で、すべての機能が物語の中でそれぞれの役割を果たしています。

しかし、インフラストラクチャとクラウドの設計は、私にとって全く異なる感覚です。それは、一つの物語を書くというよりは、物語が通り抜ける都市を築くようなものです。

最初は、「機能」という概念から脱却し、制約と負荷がかかった状態での挙動、つまりトラフィックが突然倍増した場合、リージョンがダウンした場合、あるいは単一のサービスが静かに障害を起こした場合に何が起こるかを考えるようになりました。「このリクエストをどう処理するか？」と問うのではなく、「すべてが同時に少しずつ不具合を起こしたとき、このシステムはどのように動作するか？」と問うようになったのです。

こうして、設計はレイヤー構造へと移行しました。エントリーポイントは一種のゲート、つまり都市の端にあるチェックポイントのようなロードバランサーだと想像します。ロードバランサーは、内部の状況を全て把握することなく、静かにトラフィックを分散させているのです。それらの背後にあるサービスは、もは​​や直線的なブロックではなく、それぞれが独自のペースでスケーリング、リトライ、キャッシング、リカバリを行う、生きたシステムとなっています。

データは単なる「保存された情報」ではなくなり、複数の領域に分散されたメモリのようなものへと変化します。常に複製され、時にはわずかな遅延が生じることもありますが、常に障害に耐えられるように設計されています。私は複製を、山々を越えるこだまのように考えています。完全に同一ではありませんが、元のデータが失われても意味を保つのに十分なほど近いものです。

そして、障害があります。インフラストラクチャにおいて、障害は例外ではなく、必然です。だからこそ、真の設計はそこから始まります。私は成功ではなく、崩壊を想定して設計しています。何が最初に壊れるのか、何が引き継ぐのか、何が穏やかに劣化するのか、そして何が誰にも気づかれずに静かに自己修復するのか、といったことを設計しているのです。

時が経つにつれ、クラウドアーキテクチャは、単に箱と矢印を描くようなものではなく、回復力のオーケストレーション、つまりコスト、レイテンシ、スケーラビリティ、そして信頼性を、目に見えない緊張関係にある力のようにバランスよく調整していく作業へと変化していきます。もはや単に機能するものを作るだけでは不十分で、一部が故障しても正しく動作し続けるものを作ることが求められている。

そういう意味で、インフラ設計とは、無数の知られざる物語を支える目に見えない土台を築くようなものだ。静かで、目に見えず、故障した時に初めてその存在が認識される。だからこそ、細心の注意を払って設計する必要があるのだ。