Kubernetesアプリケーション上でOracle Cloud Infrastructure Service Meshを有効にします

Oracle Cloud Infrastructure(OCI)のお客様は、マイクロサービス・アーキテクチャに移行し、そのメリットとともに新しい課題ももたらしています。マイクロサービス・アーキテクチャでは、モノリシック・アプリケーションは、APIを使用してネットワーク経由で通信する小さなマイクロサービスに分類されます。これにより、ネットワーク・トラフィックが急増し、アーキテクチャの複雑さと全体的な攻撃対象領域が増加します。

サービス・メッシュをマイクロサービスに追加すると、マイクロサービス・アーキテクチャで導入される多くの課題が軽減され、次の利点が得られます。
  • マイクロサービス・トラフィック・フローを制御できます。
  • アプリケーションを可視化します。
  • マイクロサービスは、アプリケーション・コードを変更せずにセキュアに接続できます。
OCI Service Meshを使用すると、マネージド・サービス・メッシュ・アーキテクチャをOracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes EngineまたはOKE)クラスタにデプロイできます。このリファレンス・アーキテクチャは、OKEクラスタにデプロイされたOCIサービス・メッシュ・アーキテクチャの詳細な例を提供します。

OCIサービス・メッシュ機能

セキュリティ
  • セキュリティ関連ポリシーの実施

    OCI Service Meshは、アクセス・ポリシーを使用してアクセス・ルールを定義します。アクセス・ポリシーにより、マイクロサービス間の通信が強制され、アプリケーションの内外で発生した検証済リクエストのみが許可されます。アクセス・ポリシーは、外部サービスへの許可される通信の定義にも使用されます。

  • ゼロ・トラスト

    OCI Service Meshは、すべてのマイクロサービスでゼロトラスト・セキュリティ・アーキテクチャを自動的に実装しています。マイクロサービス間のデータは暗号化されます。マイクロサービス間識別は、通信の開始時に必要です。両者は、資格証明をID情報と交換する必要があります。これにより、サービスは相互に識別して、対話する権限があるかどうかを判断できます。これは、Oracle Cloud Infrastructure Certificates (OCI Certificates)サービスとOracle Key Management Cloud Serviceを使用して証明書とキーを管理し、自動証明書とキー・ローテーションを備えた相互TLSで実装されます。

トラフィック管理
  • トラフィック・シフト

    OCI Service Meshでは、カナリア・デプロイメントを実行できます。新しいバージョンのコードを本番環境に公開する場合、トラフィックの一部のみがそのコードに到達できます。この機能を使用すると、すばやくデプロイでき、アプリケーションの障害が最小限に抑えられます。メッシュ内のすべてのマイクロサービス間通信を制御するルーティング・ルールを定義できます。トラフィックの一部を特定のバージョンのサービスにルーティングできます。

監視
  • モニタリングとロギング

    OCI Service Meshは、すべてのマイクロサービス間通信が通信を通過する必要があるため、テレメトリ情報を提供するユニークな立場にあります。これにより、サービス・メッシュは、ソース、宛先、プロトコル、URL、期間、ステータス・コード、レイテンシ、ロギングなどのテレメトリ・データを取得できます。ロギング情報をOracle Cloud Infrastructure Logging (OCI Logging)サービスにエクスポートできます。OCI Service Meshには、エラー・ログとトラフィック・ログの2種類のログがあります。これらのログを使用して、404または505の問題をデバッグしたり、ログベースの統計を生成できます。メトリックおよびテレメトリ・データはPrometheusにエクスポートし、Grafanaで可視化できます。どちらもOKEクラスタに直接デプロイできます。

アーキテクチャ

Oracle Cloud Infrastructure Service Mesh (OCI Service Mesh)は、サイドカー・モデルを使用します。このアーキテクチャは、ネットワーク機能を実装するコードをネットワーク・プロキシにカプセル化し、サイドカー・プロキシにリダイレクトされるサービスとの間のトラフィックに依存します。各アプリケーションにプロキシが接続されているため、サイドカーと呼ばれ、バイクにサイドカーが付いています。OKEでは、アプリケーション・コンテナは、同じポッド内のプロキシ・サイドカー・コンテナとともに配置されます。これらは同じポッド内にあるため、同じネットワーク・ネームスペースとIPアドレスを共有するため、コンテナはlocalhostを介して通信できます。

OCI Service Meshには、次の2つの主要コンポーネントがあります。
  • コントロール・プレーン

    OCI Service Meshコントロール・プレーンは、トラフィックをルーティングするためにプロキシのコレクション全体を管理および構成します。テレメトリの転送、健全性検査、負荷分散、認証、承認、および集約を処理します。コントロール・プレーンは、OCI証明書サービスおよびOCIキー管理サービスと対話して、各プロキシに証明書を提供します。

  • データ・プレーン

    データ・プレーンは、環境にデプロイされたサイドカー・プロキシのコレクションで構成され、アプリケーションのセキュリティ、ネットワーク機能および可観測性を担当します。また、すべてのメッシュ トラフィックでテレメトリを収集およびレポートします。Envoyプロキシは、OCI Service Meshのデータ・プレーンに使用されます。

次の図は、このリファレンス・アーキテクチャを示しています。



oci_service_mesh_oke_arch-oracle.zip

このリファレンス・アーキテクチャは、3つのサービスを持つOKEクラスタにデプロイされたアプリケーションを示しています。アプリケーションがデプロイされているネームスペースはメッシュ化されています。メッシュ化されたネームスペースは、ネームスペース内にデプロイされたサービスがサービス・メッシュの一部となり、デプロイされた新しいポッドがエンボイ・プロキシ・コンテナで注入されることを示します。各ポッドがデプロイされると、構成および証明書がOCI Service Meshコントロール・プレーンによって各プロキシ・コンテナに送信されます。OCIサービス・メッシュ・コントロール・プレーンは、OCI証明書サービスとOracle Key Management Cloud Serviceと通信して、各プロキシの証明書を取得します。

イングレス・ゲートウェイは、アプリケーションへの外部アクセスを提供するためにデプロイされます。イングレス・ゲートウェイは、OCI Service Meshデータ・プレーンの一部であり、OCI Service Meshコントロール・プレーンから構成および証明書を受信する使節プロキシでもあります。

プロキシ・コンテナは、宛先サービスでサービス検出、トラフィック暗号化および認証を実行する責任があります。また、プロキシ・コンテナは、異なるサービス・バージョン間でのトラフィックの分散方法やアクセス・ポリシーの施行方法などのネットワーク・ポリシーも適用します。イングレス・ゲートウェイは、サービス・メッシュ外のトラフィックに対して同じ機能を実行します。

PrometheusおよびGrafanaは、サービス・メッシュの一部ではない別のネームスペースでOKEクラスタ内にデプロイされます。サービス・メッシュ・データ・プレーンは、レイテンシ、障害、リクエスト、テレメトリなどの主要な動作統計をPrometheusデプロイメントに送信します。GrafanaはPrometheusデプロイメントからデータをプルします。Prometheusデプロイメントは、ビジュアライゼーション用のダッシュボードの作成に使用できます。

OCIサービス・メッシュはOCIロギング・サービスと統合されており、サービス・メッシュの作成時にロギングを有効にできます。OCI Service Meshには、エラー・ログとトラフィック・ログの2種類のログがあります。これらのログは、404または505の問題をデバッグしたり、ログベースの統計を生成するために使用できます。

このアーキテクチャには、次のOCIサービスがあります。

  • OCI Kubernetes Engine (OKE)

    高可用性でスケーラブルな本番対応Kubernetesクラスタを提供して、コンテナ化されたアプリケーションをクラウドにデプロイします。

  • ロード・バランサ

    OKEクラスタ内のイングレス・ゲートウェイへのアクセスを提供します。イングレスは、OKEクラスタ内のリクエストされたサービスにトラフィックを転送します。

  • 認証局

    OCIサービス・メッシュ・サービスのTLS証明書を管理します。

  • キー管理

    認証局サービスで使用されるキーを管理します。

このアーキテクチャには、次のコンポーネントがあります。

  • リージョン

    Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用するとネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • セキュリティ・リスト

    サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

OCIサービス・メッシュ・リソース

OKEクラスタにデプロイされたOCIサービス・メッシュを構成する場合、アプリケーションの主要コンポーネントにマップする複数のKubernetesリソースが定義されます。

次の図は、構成されたOCIサービス・メッシュ・リソース(アクセス・ポリシー、イングレス・ゲートウェイ、仮想サービスおよび仮想デプロイメント)がアプリケーション・リソース(K8sサービス、K8sサービス・ロード・バランサ、デプロイメントおよびポッド)にどのようにマップされるかを示しています。


oci_service_mesh_oke_config.pngの説明が続きます
図oci_service_mesh_oke_config.pngの説明

レコメンデーション

次の推奨事項を開始点として使用します。お客様の要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • VCN

    VCNを作成するときには、必要なCIDRブロックの数を決定し、VCN内のサブネットにアタッチする予定のリソースの数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。

    サブネットを設計するときには、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能できる同じサブネットにアタッチします。

  • ロード・バランサの帯域幅

    ロード・バランサの作成時に、固定帯域幅を提供する事前定義済のシェイプを選択するか、帯域幅範囲を設定するカスタム(フレキシブル)シェイプを指定して、トラフィック・パターンに基づいて帯域幅を自動的にスケーリングできます。どちらの方法でも、ロード・バランサの作成後にいつでもシェイプを変更できます。

考慮事項

このリファレンス・アーキテクチャをデプロイする場合は、次のオプションを考慮してください。

  • コスト

    OKEクラスタ上のOCIサービス・メッシュのコントロール・プレーンには料金はかかりません。サービス・メッシュ・データ・プレーンのプロキシ・コンテナのリソース使用率は、お客様に請求されます。ただし、実際には、お客様はOKEクラスタ内のノード・プールのリソースに対してすでに支払を行っており、プロキシ・コンテナの使用によってノード・プールの使用率が100%を超えてプッシュされないかぎり、OCIサービス・メッシュをマイクロサービス・アーキテクチャに追加する追加料金はありません。

  • 可用性

    OCIサービス・メッシュのコントロール・プレーンは、常に高可用性でデプロイされます。

確認

  • Author: Chiping Hwang
  • Contributors: Dusko Vukmanovic, Anupama Pundpal