アプリケーション中心性の実装 第3部：宣言的契約とプラットフォーム抽象化の力

アプリケーション中心インフラストラクチャ（ACI）に関するシリーズを続けます

第1部では、アプリケーション中心インフラストラクチャ（ACI）の概念と、それが現代の分散システムの管理に不可欠である理由を紹介しました。第2部では、従来のインフラストラクチャ中心アプローチの一般的な落とし穴と、単純なGitOpsモデルの限界を探りました。そして第3部では、「どのようにして」ONDEMANDENVがそのコアコンポーネント、具体的にはcontractsLibと独立した比較可能な環境（Envers）の概念を通じて真のACIを実現するのかを掘り下げます。

従来の行き詰まり：サイロ化、静的環境、スコープの盲目性

ONDEMANDENVのソリューションを理解する前に、従来のセットアップにおける典型的な課題を再確認しましょう。

• サイロ化されたチームとスコープのローカリゼーション： 開発チームは、特定のマイクロサービスやアプリケーションにのみ焦点を当てることがよくあります。下流または上流のサービスに対する変更の要件や影響について可視性がなかったり、無視したりすることさえあります。「複雑さのもつれ」で議論したように、この「スコープのローカリゼーション」は、重要な依存関係や統合ポイントがしばしば遅れて発見され、摩擦や不安定性を引き起こすことを意味します。
• モノリシックで静的な環境： システムは通常、いくつかの共有された長寿命の環境（例：開発、QA、ステージング、本番）にデプロイされます。各環境内では、サービスは通常、そこにデプロイされている他のすべてのサービスと密結合した単一のインスタンスとして存在します。単一のサービスを更新するには、多くの場合、複雑な調整が必要になるか、共有環境全体を不安定にするリスクがあります。
• 運用上の距離： これらの共有環境は、別の運用チームまたはDevOpsチームによって頻繁に管理されます。これらのチームは熟練しているかもしれませんが、特定のアプリケーションの相互依存関係や、特定の開発チームの変更の当面の利害関係について深いコンテキストを持っていない場合があります。
• 比較不能性： 複数のサービスにまたがる複雑で断続的な問題をデバッグすることは悪夢になります。なぜなら、システムまたはそのサブコンポーネントのわずかに異なる、分離された実行状態を作成して比較する実用的な方法がないからです。モノリシックなデプロイメントからのログとメトリックを分析し、サービス境界を越えて因果関係を推測しようとすることに行き詰まってしまいます。

contractsLib：分散システムのためのコード化された議会

ONDEMANDENVは、ACI実装の基礎としてcontractsLibを導入しています。これは単なる構成ではなく、すべてのアプリケーションとサービスがそのニーズ、依存関係、および提供されるインターフェースを明示的に述べる必要がある、**コード化された宣言的な議会**と考えてください。

contractsLibの主な側面：

• 宣言的な信頼できる情報源： アプリケーション契約は、アプリケーションが*何を*必要とするかを定義し、それを*どのように*プロビジョニングするかは定義しません。これには以下が含まれます。
  • 他のサービスの特定のバージョンへの依存関係（コンシューマー）。
  • 必要なプラットフォーム機能（例：データベースタイプ、メッセージキュー、キャッシュレイヤー）。
  • 特定の構成または環境変数。
  • リソース要件（CPU、メモリ）。
  • 公開されたインターフェースまたはエンドポイント（プロダクト）。
• 早期の可視性の強制： コードでの明示的な宣言を要求することにより、contractsLibは、開発サイクルの*早い段階*で潜在的な競合、非互換性、および統合の課題を表面化させます。サイロ化されたチームは、より広範なシステムへの影響に対して盲目であり続けることはできなくなり、契約書で彼らの「本性」と仮定が露呈します。
• コードとしてのアーキテクチャ： contractsLibは、システムのアーキテクチャとコンポーネントの相互作用の高レベルでバージョン管理された表現を提供します。これは単なるインフラストラクチャコードではなく、サービスが互いにどのように関連し、プラットフォームにどのように関連しているかを示す生きた青写真です。
• プラットフォームによる維持/強制： これらの契約は単なるドキュメントではなく、ONDEMANDENVプラットフォームに不可欠です。プラットフォームはこれらの契約を読み取り、検証し、使用してデプロイメントを調整し、制約を強制します。プラットフォームの権限外で宣言された契約はカウントされません。

# contractsLib定義の概念的な例（構文は説明用）
AppContract(appName='order-service', version='1.2.0') {
  dependencies: [
    ServiceDependency(name='payment-service', version='~>2.1'), # payment-service v2.1.x を消費
    ServiceDependency(name='inventory-service', tag='stable'),   # 'stable' とマークされた inventory-service を消費
  ],
  platformNeeds: [
    Database(type='postgres', size='medium'),
    MessageQueue(name='order-events'),
  ],
  configuration: {
    API_TIMEOUT_MS: 500,
    FEATURE_FLAG_X: true,
  },
  provides: [
    ApiEndpoint(path='/orders', port=8080), # 他のプロダクト用
  ]
}
    

解放：オンデマンドで分離されたEnvers

contractsLibを基盤として、ONDEMANDENVは環境管理に革命をもたらします。すべてのサービスをいくつかのモノリシックな環境に強制する代わりに、**各アプリケーション/サービスチームが複数の独立したオンデマンドのEnvers**（環境バージョン）を作成できるようにします。

「Enver」は、特定のバージョンのコードとその宣言されたcontractsLibからの契約（正確な依存関係を含む）に基づいて、完全にプロビジョニングされた実行可能なアプリケーションのインスタンスです。決定的に重要なのは：

• 分離： 各Enverは分離して実行され、他のEnversや従来の共有環境の影響を受けません。
• 独立性： チームは、環境スロットを待ったり、複雑な共有デプロイメントを調整したりすることなく、機能ブランチ、特定のコミット、または異なる依存関係バージョンに基づいてEnversを作成できます。
• 真のACI： 環境は契約で定義されたアプリケーションバージョンに*帰属*し、その逆ではありません。

デバッグの超能力：分離された環境の比較

この独立性により、従来のセットアップでは欠けていた重要な機能が解放されます。それは**異なる実行環境を直接比較する能力**です。これは、分散システムにおける複雑な問題をデバッグするのに非常に強力です。

• コードの違い： バグは最新のコード変更によって引き起こされていますか？機能ブランチ（feature-xyz）用のEnverとmainブランチ用の別のEnverを起動します。両方にデプロイし、同じテストを実行し、完全に分離された状態で動作、ログ、リソース使用量を直接比較します。違いは*必ず*コードの変更に関連しているはずです。
• 依存関係の問題： 依存関係（例：payment-serviceのv2.1からv2.2へのアップグレード）をアップグレードすると問題が発生しますか？order-service用に2つのEnversを作成します。1つはpayment-service v2.1を契約し、もう1つはv2.2を契約します。それらの動作を並べて比較し、依存関係の変更によって引き起こされる統合の問題を特定します。
• 構成のドリフト： 構成の違いが問題を引き起こしている疑いがありますか？契約で定義されたわずかに異なる構成を持つ2つのEnversを作成します。それらを比較して、特定の設定の影響を分離します。
• バグの再現： バグが発生した正確な条件（コードバージョン、依存関係、構成）に対応するEnverを起動することで簡単に再現でき、診断が大幅にスピードアップします。

分離された完全に機能する環境を比較するこの機能は、共有環境の断片化されたログに基づく当て推量から、決定論的な除外プロセスへとデバッグを変革します。

プラットフォーム抽象化：それを現実にする

contractsLibの宣言的契約は、どのようにして実行中の分離されたEnverになるのでしょうか？これがONDEMANDENV内の**プラットフォーム抽象化レイヤー**の役割です。

• 解釈とオーケストレーション： プラットフォームはアプリケーション契約を読み取り、宣言された依存関係とプラットフォームのニーズを理解し、基礎となるインフラストラクチャのプロビジョニングを調整します（現在の実装ではAWS CDKなどのツールを使用）。
• 複雑さの処理： 契約とプラットフォームポリシーに基づいて、ネットワーキング、セキュリティ境界、サービスディスカバリ、シークレット管理、基本的な可観測性などの横断的な懸念事項を管理し、アプリケーション開発者をこの複雑さから保護します。
• 一貫性の確保： 契約からプロビジョニングを駆動することにより、プラットフォームは、結果として得られるEnverがアプリケーションの宣言された状態を忠実に表すことを保証します。
• 移植性： 現在の実装はAWS CDKを使用するかもしれませんが、contractsLib定義自体はツールに依存しません。プラットフォーム抽象化レイヤーにより、アプリケーション契約を変更することなく、基礎となる実装を進化させることができます。

結論：ACIを通じた真のアジリティの達成

アプリケーション中心インフラストラクチャの実装は、単に新しいツールを採用することだけではありません。視点の転換が必要です。ONDEMANDENVは、以下を提供することでこの転換を促進します。

1. contractsLib： 依存関係とニーズの明示的な宣言を強制するコード化された議会であり、コードとしてのアーキテクチャと早期の統合可視性を可能にします。
2. 独立したEnvers： 特定のアプリケーション契約バージョンに結び付けられた、分離されたオンデマンド環境であり、チームをモノリシックな環境の制約から解放します。
3. 比較可能性： 異なる環境状態を並べて起動して比較する重要な機能であり、デバッグと検証に革命をもたらします。
4. プラットフォーム抽象化： 宣言的な契約を実行可能な現実に変換し、基礎となる複雑さを管理するインテリジェントなレイヤー。

これらの要素を組み合わせることで、ONDEMANDENVは従来のアプローチの限界を超え、最終的にマイクロサービスのアジリティの約束を実現し、分散システムの複雑さを抑制します。