3.0 第3部の紹介: システム
アーキテクチャとは、元に戻すのが高くつく決定の集合です。システムをどう部品に分けるか。それらの部品はどう互いに話すか。データはどうモデル化されるか。そして全体は、負荷のもとで、失敗のもとで、どう振る舞うか。第3部は、それらの判断を意図して行うことについてです。小さなチームでは、アーキテクチャは少数の頭の中に住み、進めながら進化できます。大きな組織(何百人ものエンジニア、数十のチーム、それを築く人々のキャリアより長生きするシステム)では、アーキテクチャは全員の足並みを揃えるものになります。それが明確なら、チームは衝突せずに独立して動きます。曖昧なら、あらゆるチーム間の依存が交渉になり、あらゆるインシデントが考古学のプロジェクトになります。
賭け金が最も高いのは、企業と政府です。税のエンジン、給付のプラットフォーム、国の医療記録、銀行の中核の元帳は、長寿命で、厳しく規制され、部門間で共有され、公衆に説明責任を負います。結合、データのオーナーシップ、品質特性について今日下す決定は、十年以上にわたって、何が可能かを制約します。規制当局と監査人は、信頼性、セキュリティ、プライバシー、耐久性が後付けではなく設計に組み込まれたという本物の証拠を伴う、文書化された擁護できるアーキテクチャを、ますます期待しています。見出しになる失敗は、アーキテクチャの失敗です。ローンチの日に崩れるポータル、期限にタイムアウトする申告システム、レコードを失ったり二重に数えたりする移行。
この部は、持続的な基礎から始まり、具体的な構造の選択を経て、分散、データ、規模の現実に進み、ほとんどの大きな組織が実際に直面する最も難しい問題、すでに運用しているシステムのモダナイズで締めくくります。全体を結ぶ糸は、良いアーキテクチャは、流行の既定ではなく、意識的なトレードオフの連なりだということです。
この部の章
3.1 アーキテクチャの基礎。技術の流行を生き延びる持続的な道具。品質特性(「〜性」)、アーキテクチャ上重要な要求、フィットネス関数(選ばれたアーキテクチャの品質を守る自動テスト)と進化的アーキテクチャ、C4モデル(四つの拡大率でのアーキテクチャ図の入れ子)とarc42(アーキテクチャ文書化のテンプレート)による軽量なドキュメント、そして構造化されたトレードオフ分析。
3.2 アーキテクチャのスタイルとパターン。モノリスからマイクロサービス、CQRS(コマンドクエリ責任分離。読み取りモデルと書き込みモデルを分ける)とイベントソーシング(状態を追記専用のイベントのログとして保存する)を伴うイベント駆動アーキテクチャ、サービスメッシュ(サービス間通信のための専用のインフラ層)とゲートウェイ、サーバーレス、ヘキサゴナルとクリーンアーキテクチャまで、主要なシステムの形の概観。それぞれがいつ合うかの指針とともに、コンウェイの法則(システムは、それを作る組織のコミュニケーション構造を映す傾向がある)によって枠づけられます。
3.3 分散システム。ネットワークの境界を越えた瞬間に現れる厳しい真実(信頼できないネットワーク、部分的な失敗、共有の時計がないこと)と、標準的な防御。一貫性の推論、冪等性(操作を繰り返しても安全にすること)、バックオフ付きのリトライ、サーキットブレーカー(失敗している依存先への呼び出しを止める)、サガ(補償的な取り消しのステップを伴うローカルトランザクションの連なり)、分散オブザーバビリティ。
3.4 データアーキテクチャとストレージ。データがどうモデル化され、保存され、一貫性が保たれ、規模で速く提供されるか。主要なストレージのパラダイムとそれぞれをいつ使うか、ポリグロットパーシステンス(一つのシステムで複数の特化したデータストアを使う)、スキーマの進化と移行、キャッシュとCDN(コンテンツ配信ネットワーク)、負荷のもとでのトランザクションと並行性。
3.5 スケーラビリティ、性能、レジリエンス。後付けではなく設計に組み込まれる、三つの別個の品質。水平と垂直のスケーリング、ステートレス性とシャーディング(キーによってデータをマシンに分割する)、負荷分散とオートスケーリング、性能予算、レジリエンスのパターンとカオスエンジニアリング、RTO(目標復旧時間)とRPO(目標復旧時点)で枠づけられるマルチリージョンの災害復旧。
3.6 レガシーのモダナイゼーション。実際にうまくいく漸進的なパターン。ストラングラーフィグ(古いシステムを退役させられるまで、その周りに新しいシステムを育てる)と抽象化によるブランチ(開発のメインラインで、インターフェースの背後のコンポーネントを置き換える)に加え、レガシーのリスク評価、メインフレームとCOBOL(共通事務処理指向言語)の管理、データ移行と並行稼働、そしてこの分野で最も高価な失敗を生む大きな書き直しの誘惑にどう抵抗するか。
3.7 ソフトウェア保守。ソフトウェアの寿命の支配的なフェーズ。是正、適応、完全化、予防の保守、プログラム理解とリエンジニアリング、そして長寿命のシステムが変更に手頃なままであるための保守性の設計。
3.8 相互運用性とオープンスタンダード。独自の統合ではなく、オープンスタンダードを通じて相互運用するようシステムを設計すること。技術的、構文的、意味的な相互運用性、医療のFHIRのようなドメインの標準、そして独自仕様によるロックインのコスト。
3.9 システムズエンジニアリング。しばしばソフトウェア、ハードウェア、人々、プロセスを組み合わせた、複雑なシステムを端から端まで設計すること。ライフサイクル、要求の割り当てとトレーサビリティ、インターフェース、統合、検証と妥当性確認。
3.10 組み込みとリアルタイムのシステム。厳しい制約のもとのデバイスのためのソフトウェア。リアルタイムの振る舞いと決定性、RTOSかベアメタルのファームウェア、限られたメモリと電力、ハードウェアとの相互作用、安全が重要な標準。
3.11 クラウドアーキテクチャ。データセンターをそのまま持ち上げるのではなく、クラウドのために設計すること。サービスモデルとサーバーレス、障害ドメインとしてのリージョンと可用性ゾーン、責任共有モデル、マネージドサービスとロックインのトレードオフ、複雑さに見合うときのマルチクラウドとハイブリッド、コストを意識したウェルアーキテクテッドな設計。
3.12 イベント駆動アーキテクチャとメッセージング。イベントを生成し、それに反応することで通信するシステムを築くこと。キューと永続的なストリーム、コレオグラフィとオーケストレーション、見合うときのイベントソーシングとCQRS、分散トランザクションのためのサガ、配信保証と冪等性、そして非同期のフローを信頼できるものに保つパターン。
3.13 ネットワーキングと接続性。アプリケーションエンジニアが実際に扱うネットワーキング。DNS、TCPとHTTPの進化、TLS終端、負荷分散とリバースプロキシ、コンテンツ配信とエッジ、サービスディスカバリとサービスメッシュ、そしてネットワークの信頼性のなさを生き延びられるものにするタイムアウト、リトライ、サーキットブレーカー。
3.14 マルチテナンシーとSaaSアーキテクチャ。互いを見たり飢えさせたりさせずに、一つのソフトウェアインスタンスから多くの顧客に提供すること。隔離と効率のスペクトラム、データのパーティショニング、うるさい隣人に対するテナントごとのクォータ、テナントのライフサイクル、コストの帰属。
3.15 キャッシュとコンテンツ配信。少しの古さを、キャッシュ階層(クライアント、エッジとCDN、リバースプロキシ、アプリケーション、データストア)にわたるレイテンシ、負荷、コストの大きな利得と交換しつつ、キャッシュの無効化とスタンピード対策を第一級の設計として扱うこと。
3.16 APIゲートウェイとサービスメッシュ。APIゲートウェイでの南北のトラフィック(ルーティング、認証、レート制限、合成)と、サービスメッシュを通じた東西のトラフィック(相互TLS、トラフィックのシフト、リトライ、オブザーバビリティ)を扱い、メッシュがその複雑さに見合うときを決めること。
3.17 検索と情報検索。転置インデックスと関連度ランキングから、クエリ理解、ファセット、ベクトルとハイブリッドの検索まで、検索を第一級のシステムとして扱い、当て推量ではなく本物の関連度評価を行うこと。
これらの章の相互関係
章は順に積み重なります。3.1章は、以後のすべての章が使う語彙(品質特性とトレードオフ分析)を与えます。それが挙げる「〜性」は、まさに3.4章と3.5章が具体化するものです。3.2章はそれらの基礎を構造の選択に変え、それが支持するより分散したスタイル(マイクロサービス、イベント駆動、サービスメッシュ)は、3.3章が管理を教えるコストをもたらします。3.3章、3.4章、3.5章は互いに強く依存します。分散はデータアーキテクチャの一貫性と耐久性の決定を強い、分散とデータが合わさって、実際に到達できるスケーラビリティとレジリエンスを形づくります。3.6章はループを閉じます。ほとんどの大きな組織は白紙の上に築いているのではなく、先の章が述べるあらゆる選択を制約する記録のシステムを進化させているからです。
第3部は外にも手を伸ばします。3.2章は、良いサービスの境界を見つけるために、2.2章の設計原則とドメイン駆動設計に依拠します。これらのシステムを動かし続ける運用の規律は第9部にあります。サイト信頼性エンジニアリング(9.1章)とオブザーバビリティ(9.2章)は、アーキテクチャのレジリエンスが本番で証明される場所です。規制当局が求めるセキュリティとプライバシーの性質はここで設計されますが、第4部で詳述され、第8部のプラットフォームとデリバリーの実践が、アーキテクチャを多くのチームが同時に実際に出荷し運用できるかを決めます。