OCI Service Mesh

解決する課題

OKE（Kubernetes）上のマイクロサービスが増えると、サービス間の暗号化・認可・観測を各アプリに個別実装するのは負担になります。Service Mesh は、これらの横断的関心事をアプリのコードから切り離し、共通基盤として提供することを狙ったサービスでした。

• サービス間通信を**アプリ無改修で暗号化（mTLS）**したい
• どのサービスがどのサービスを呼べるかをアクセスポリシーで宣言的に制御したい
• リトライ・タイムアウト・トラフィック分割といった通信制御を一元化したい
• サービス間のメトリクス・トレースを横断的に収集して可観測性を高めたい

主要概念と用語

• メッシュ（Mesh）: 論理的な境界。配下の仮想サービス・仮想デプロイメント・ポリシーをまとめる最上位リソース
• 仮想サービス（Virtual Service）: 論理的なサービスの定義。1つの DNS 名に対応し、複数の仮想デプロイメントをぶら下げる
• 仮想デプロイメント（Virtual Deployment）: 仮想サービスの具体的な実体（バージョンやリビジョン）。OKE 上の Pod 群に対応する
• 仮想サービスルートテーブル（Virtual Service Route Table）: 仮想サービス内で、どの仮想デプロイメントへ何パーセント振り分けるかなどのルーティングを定義
• イングレスゲートウェイ（Ingress Gateway）: メッシュ外部からの流入をメッシュ内サービスへ取り次ぐ入口
• アクセスポリシー（Access Policy）: 送信元と宛先を指定し、サービス間の通信可否を宣言的に許可・拒否するルール
• サイドカープロキシ（Sidecar Proxy）: 各 Pod に注入される Envoy ベースのプロキシ。通信を肩代わりして mTLS・ルーティング・テレメトリを担う
• mTLS（相互 TLS）: サイドカー同士が双方の証明書を検証し合う相互認証。PERMISSIVE（平文と暗号化を併用）と STRICT（暗号化必須）のモードがあった

仕様・制限・クォータ

• OKE（Kubernetes）専用。各 Pod にサイドカープロキシを注入する方式で、汎用 Compute 単体では使えない
• メッシュ／仮想サービス／仮想デプロイメントなどのリソース数にはサービスリミットが設定されており、テナンシ・リージョンごとに上限がある
• mTLS の証明書は OCI の Certificates サービスと連携して管理する設計だった
• リージョナルなリソースとして提供され、特定リージョン内で完結する
• 提供終了済みのため、現在は新規リソース作成や継続利用はできない。最新の数値・上限は EOL に伴い参照する意味が薄く、移行先（Istio）の制約を確認すべき

内部の仕組み

各 Pod に Envoy ベースのサイドカープロキシが注入され、アプリの送受信トラフィックはすべてこのプロキシを経由します。プロキシ同士が mTLS で相互認証・暗号化し、アプリ本体はプレーンな HTTP を話すだけで、暗号化や認可はメッシュ側が肩代わりする構造です。

コントロールプレーンが、定義した仮想サービス・ルートテーブル・アクセスポリシーをデータプレーン（各サイドカー）へ配布し、サイドカーはそれに従ってルーティング・トラフィック分割・アクセス許可判定を実行します。通信のテレメトリ（メトリクス・トレース）もサイドカーが生成するため、アプリにライブラリを組み込まなくても観測できる点が利点でした。

イングレスゲートウェイはメッシュの入口として外部トラフィックを受け、ホスト名やパスに応じてメッシュ内の仮想サービスへ取り次ぎます。これにより、外部公開とメッシュ内の宛先解決を分離できました。

設計パターン / ベストプラクティス

• 段階導入: 重要サービスから順にサイドカーを注入し、PERMISSIVE から STRICT へ移行
• 最小権限の通信: アクセスポリシーで「許可する通信だけを明示」し、デフォルト拒否に寄せる
• カナリア／トラフィック分割: ルートテーブルの重み付けで新バージョンへ少しずつ流す
• 入口の集約: イングレスゲートウェイで外部流入をまとめ、API Gateway や Load Balancer と役割分担する
• 可観測性の標準化: サイドカー由来のメトリクス・トレースを共通基盤に集約し、サービス横断で監視する

運用・監視

• サイドカーが生成するメトリクス・分散トレースを可観測性基盤に集約し、サービス間レイテンシやエラー率を監視する
• 通信遮断時は、アクセスポリシーの拒否か、STRICT mTLS とサイドカー未注入の組み合わせを真っ先に疑う
• 設定変更（メッシュ・ポリシー）の監査は OCI Audit ログで追跡する
• EOL 後の運用方針: 既存環境は Istio への移行計画を立て、移行期間中はメッシュ機能に新たな依存を増やさないことが重要

コスト

OCI Service Mesh のコントロールプレーン自体は追加料金なしで提供される位置づけでしたが、メッシュを動かすための周辺リソース（OKE のワーカーノード、サイドカーが消費する CPU/メモリ、可観測性の取り込み量など）は別途発生します。EOL 済みのため、現在は移行先となる Istio 構成（自前運用の運用コスト）を前提にコストを見積もるべきです。

セキュリティ

• mTLS（相互 TLS）: サイドカー間で証明書を相互検証し、サービス間通信を暗号化・認証する中核機能
• アクセスポリシー: 送信元・宛先を指定したデフォルト拒否ベースの認可で、横移動（ラテラルムーブメント）を抑止
• IAM ポリシー: メッシュやポリシーの管理操作を最小権限で付与し、Certificates など連携リソースは動的グループ経由でアクセス
• 証明書管理: OCI Certificates サービスと連携し、証明書のローテーションを基盤側で扱う設計だった

関連サービス・比較

最も近い後継・代替は、OKE 上で動かす Istio です。OCI Service Mesh はマネージドのコントロールプレーンを提供していましたが、EOL 後はオープンソースの Istio をユーザー側で運用する形に移ります。

ハンズオン / CLI例

OCI Service Mesh は EOL のため、現在は新規リソース作成ができません。以下は概念把握のための参考例で、実行は移行先の Istio（kubectl ベース）を前提に置き換えてください。

# 参考: かつての OCI CLI でのメッシュ確認系コマンド（現在は EOL のため実行不可）
# メッシュ一覧（過去の操作イメージ）
oci service-mesh mesh list \
  --compartment-id "$COMPARTMENT_OCID" --output table

# --- 現在の推奨: OKE 上の Istio で同等機能を構成する ---

# 1. 名前空間にサイドカー自動注入を有効化
kubectl label namespace app istio-injection=enabled

# 2. mTLS を STRICT にして名前空間内の平文通信を禁止
kubectl apply -f - <<'YAML'
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: app
spec:
  mtls:
    mode: STRICT
YAML

# 3. 動作確認（サイドカーが注入されたか）
kubectl get pods -n app -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}{end}'