ミッションクリティカルなシステム向けレジリエントなインフラストラクチャプラットフォームを構築する12の原則

American Expressのエグゼクティブ・バイスプレジデント兼グローバル・インフラストラクチャ責任者であるMatthew Listeは、成功するテクノロジープラットフォームは構成要素の数ではなく、複雑性を隠し、開発者に安定した明確な体験を提供する能力によって測られると考えている。ListeはQCon San Franciscoでの講演において、Goldman Sachs、JPMorgan Chase、American Expressでミッションクリティカルなシステム向けのプラットフォームとインフラストラクチャの構築に携わってきた20年以上の経験に基づいて説明した。

Listeが取り上げたプラットフォームは、多数の社内開発者を支えている。American Expressでは約2万人、JPMorgan Chaseでは約6万人のユーザーがいる。クラウドサービスプロバイダーとは規模が異なるものの、他者が依存するレイヤーを構築するチームであれば、基本原則は同じように適用できるとListeは考えている。

優れたプラットフォームは、何が起きているかを隠さずに複雑性を隠す

Listeはまず、プラットフォームを、その上にアプリケーションを構築するための基盤となる、統合されたテクノロジー群と定義している。水道や下水道のサービスになぞらえ、機能している限り利用者は背後のインフラを意識しないが、停止するとすぐに気づくと説明する。

そのため、プラットフォームの体験は直感的であり、監視、アイデンティティ、名前空間の統一された基盤など、共通して交換可能なコンポーネントを利用すべきである。この構成可能性により、プラットフォームは、追加の努力なしには連携しない個別サービスの集合ではなく、Legoブロックに近いものになる。

安定性、安全性、スケーラビリティはオプションではない

Listeは、彼が「3つの柱」と呼ぶ安定性、安全性、スケーラビリティを定めている。必要な可用性の水準はシステムの価値によって異なる。彼の説明によれば、American Expressのクレジットカード承認システムは6ナインから7ナインに達する水準で稼働する一方、他のシステムではより多くの停止時間に耐えられる可能性がある。

また、初期の成功がスケーラビリティの問題を隠すことがあると強調する。利用が増えると、初期には問題なく機能していたプラットフォームがボトルネックに直面し、それが安定性に直接影響する可能性がある。そのため、サービスレベル目標（SLO）を利用者とともに定め、リリース当日だけでなく、時間の経過後も遵守しなければならない。

継続的な更新と差別化につながらない作業の削減

Listeは、プラットフォームを最新の状態に保つことを、最も難しく、先送りされやすい業務の一つと考えている。延期されたアップグレードが積み重なると、より新しいバージョンへの移行が高コストになり、顧客に影響を及ぼす可能性がある。彼は、0114と呼ぶ社内基準を提案している。これは、自動化によって定期メンテナンスに必要な人員をゼロにすること、フリートのすべてのコンポーネントをアップグレードできること、1日未満でアップグレードを完了すること、そして14日以内に更新サイクルを実行することである。

また、十分な品質で利用可能なものを再構築しないよう呼びかけている。新しいPostgreSQLエンジンを書く代わりに、規制要件を満たすために必要な部分として、オブジェクトストレージへの日次バックアップを実行する制御レイヤーを構築する例を挙げている。重要なのは、エンジニアリング上最も興味深い作業ではなく、組織が必要とする価値に焦点を当てることである。

明確な意思決定と利用者との契約関係

プラットフォームの所有者は顧客の声に耳を傾けるべきだが、すべての要望を実装する必要はない。リソースには限りがあり、古い機能を廃止せずに残し続けると技術的負債が蓄積し、より重要なものの開発を妨げる。そのため、プラットフォームは明確な「意見」を持ち、何をサポートし、何をやめ、何が大多数のユーザーに役立つのかを定めなければならない。

これには、API、サービスレベル契約、プロセスを通じて責任範囲を公式に定めることが含まれる。チームが何を提供するかを知っているだけでは不十分であり、利用者も自分が何を担当し、プラットフォームが越えない境界がどこにあるかを理解しなければならない。Listeはプラットフォームを、形状が固定されたコンポーネントになぞらえている。限られたチームが顧客ごとにカスタム製品を構築することはできない。

実践的な体験：早く試し、詳細を隠さずに抽象化を利用する

Listeは、構築を決定した後は、顧客を移行中の影響から守りながら、素早く繰り返し失敗することを勧めている。Linuxコンテナやさまざまなオーケストレーションツールを早期に試し、最終的にKubernetesへ移行した経験を例に挙げる。早期の実験により、1つのソリューションの成熟を待つ前にチームが学習できた。

一方で、抽象化レイヤーがその下で起きていることを隠してはならない。ユーザーインターフェース、API、TerraformなどのInfrastructure as Codeを提供できるが、障害を理解し、必要に応じて挙動を調整できるだけの可視性と詳細を提供しなければならない。Listeは最後に、オープンソースとオープン標準の上に構築することの重要性を強調している。これにより、プラットフォームチームはすべてのレイヤーをゼロから再構築するのではなく、統合と付加価値に集中できる。

なぜこれらの原則が重要なのか

Listeの提案の基本的な価値は、プラットフォーム構築をツール群をリリースするプロジェクトから、長期的な運用上のコミットメントへと捉え直している点にある。プラットフォームは採用後、多くのチームに影響を与えるため、更新可能性、責任範囲の明確さ、廃止の管理は、素早く新機能を追加することよりも重要になる。これらの原則は、成功を保証する統一基準ではなく、実務経験に基づく指針である。可用性の水準、自動化の範囲、抽象化の選択は、システムの性質とその利用者のニーズに依然として結びついている。