Anthos Service Mesh とは
フルマネージドでサービスメッシュソリューションの利用ができる。
トレーシング、モニタリング、ロギング機能でサービスのパフォマンスや、他のプロセスに与える影響、存在的な問題を把握できる。
ゼロトラストセキュリティモデルに基づいたサービスや通信を自動的かつ宣言型の手法で保護できる。アプリケーションへの変更することなくサービス間の認証認可、暗号化を管理することができる。
トラフィックフローやAPI呼び出しを制御しながら可視化することができる。
ASM 特徴
Cloud Logging , Cloud Monitoring , Cloud Trace を組み合わせてサービスレベルごとのSLOのモニタリングや、レイテンシ・可用性のターゲット設定などの機能を利用できる。グラフの生成、コンプライアンスの継続的なトラッキングが自動的に行われエラーバジェットとの比較検討も可能となる。
mTLS によってサービス間やエンドユーザとサービス間の通信を保護できる。段階的に導入も可能。
ロールベースのアクセス制御 (RBAC) によってメッシュ内のサービスへのアクセス権を簡単に制御できる。
A/B テスト用の動的ルーティング、カナリーリリース、段階的なロールアウトなどが利用できる。
タイムアウト設定、サーキットブレイカー、ヘルスチェック、リトライ処理にも対応している。
一定条件に一致するリクエストに対して遅延やエラーを挿入することが簡単にできるようになるフォルトインジェクションも可能になる。
負荷分散ではラウンドロビン、ランダム、重み付け最小リクエストのいずれかの方式で行うことができる。
サービスメッシュとは
サービス間で管理され、監視可能な安全な通信を可能とするアーキテクチャ。
モニタリング、ネットワーク、セキュリティなどのサービス実行についての共通の懸念を整合性のあるツールで分析するため、開発者・運用者はユーザ向けの開発と管理に専念できるようになる。
Anthos Service Mesh では Istio を利用している。
サービスメッシュは1つ以上のコントロールプレーンとデータプレーンで構成されている。
Kubernetes ではプロキシはメッシュのマイクロサービスにサイドカーパターンによってデプロイされる。VM の場合はプロキシが VM にインストールされる。
この図では利用者が管理するコントロールプレーンとサイドカープロキシの Anthos Service Mesh コンポーネントと機能を示している
コントロールプレーンとは
内部のワークロードインスタンス間の通信を管理する。
Anthos Service Mesh 1.9移行では2つのコントロールプレーンが良いされている
- Google が管理するコントロールプレーン
- フルマネージドで信頼性、アップグレード、スケーリング、セキュリティに対応する
- 利用者が管理するコントロールプレーン
- istiod を使用して Anthos Service Mesh をインストールする場合はセキュリティ、スケーリングのアップグレードと構成は利用者の責任となる
データプレーンとは
ワークロード間の通信を直接制御するメッシュの一部。
サイドカーとしてデプロイされたプロキシを使用してメッシュサービスが送受信するすべての TCP トラフィックを仲介、制御する
特徴
トラフィック管理
サービス間のメッシュと外部サービスへのトラフィックフローを制御する。
L7レイヤーでトラフィックを管理するように Istio 互換のカスタムリソース( CRD )を構成してデプロイすると以下のようなことが可能となる
- カナリーリリースと Blue/Green デプロイメント
- サービスの特定のルートを管理する
- サービス間の負荷分散
- サーキットブレイカー
Anthos Service Mesh ではメッシュないのすべてのサービスのサービスレジストリを名前別、エンドポイント別に管理する。
メッシュはサービスレジストリを使用して、サービスと同時にプロキシを実行することで適切なエンドポイントにトラフィックを転送する。
CRD ( Custom Resource Definity )
Istio 互換のカスタムリソースは以下のものとなる
-
Virtual serivces
- Istio のトラフィックルーティング機能の構成要素の一つ。一致条件などで PATH 、ヘッダーやユーザを指定して接続先を変更することが可能となる。重み付けをすることによって A/B テストやカナリーリリースを行うこともできる。
-
Destination rules
- Virtual services の後に評価され、トラフィックをどのように流すかを決める。ラウンドロビン方法もランダム、加重、最小リクエストの3種類に分けられる。
-
Gateways
- Gateway を使用してインバウンド・アウトバウンドトラフィックを管理し、メッシュに出入りするトラフィックを指定する。サイドカー Envoy プロキシではなく、メッシュのエッジで実行されるスタンドアローン Envoy プロキシに適用される。
- Istio ゲートウェイでは公開するポート、TLS設定などのレイヤー4~6の負荷分散プロパティを構成できる。L7を同じAPIリソースに追加する代わりに Istio Virtual services をゲートウェイにバインドする。
-
Service entries
- Isito が内部で維持するサービスレジストリにエントリを追加する。サービスエントリを追加すると Envoy プロキシはメッシュないのサービスであるかのようにトラフィックをサービスに送信できる。
- リダイレクト、リトライ処理、タイムアウト設定、フォルトインジェクションを定義できる
- 仮想マシンを追加して仮想マシン上でメッシュサービスを実行できる
-
Sidecars
- Istio は関連するワークロードすべてのポートでトラフィックを受け、トラフィックを転送するときにメッシュないの全てのワークロードに到達するように、すべての Envoy プロキシを構成する。
- サイドカー構成を使用して Envoy プロキシが受け入れるポートとプロトコルのセットを微調整する。Envoy プロキシが到達できるサービスのセット制限する。
オブザーバビリティの分析情報
以下のサービスメッシュにかんする情報を利用できる。
- GKE クラスタないの HTTP トラフィックに関して、サービスの指標とログが自動的に Google Cloud に取り込まれる
- 事前構成されたサービスダッシュボードで、サービスの理解に必要な情報を確認できる
- Cloud Monitoring , Cloud Logging , Cloud Trace によってサービスの指標とログを深く掘り下げることができる
- 各サービスに接続しているユーザと、各サービスが依存しているサービスを理解するうえで有用
- SLO によりサービスの状態について分析情報を取得できる。独自の基準を使用して SLO とアラートを定義できる
セキュリティ上のメリット
-
相互 TLS 証明書 (mTLS) を使用してピア認証をする
- mTLS はクライアントとサーバの両方が相互に証明書を提示して互いの ID を検証する
- すべての TCP 通信が通信中に暗号化される
- 承認されたクライアントだけが気密データを含むサービスにアクセスできるように制御できる
- ネットワークないでユーザデータ侵害のリスク軽減
- 機密データのあるサービスにアクセスしたクライアントを識別する
- Logging を使用して IP やクライアントの mTLS ID を収集できる
- コントロールプレーンのすべてのコンポーネントとプロキシで FIPS 140-2 認証取得済み暗号化モジュールが使用されます。
デプロイのオプション
1.9 以降の場合デプロイオプションがある
- Google が管理するコントロールプレーンをデプロイする
- サービスメッシュに Compute Engine VM を含める
Google が管理するコントロールプレーン
Google が管理するコントロールプレーンをプレビュー機能として使用できる。
Google が管理するコントロールプレーンによって、メッシュのアップグレード、スケーリング、保護が自動的に行われる。
Google が管理するコントロールプレーンとユーザのサイドカープロキシの Anthos Service Mesh コンポーネントと機能を示した図が以下のものになる
コントロールプレーンの設定、移行の方法は Google が管理するコントロール プレーンの構成に記載されている。
コントロールプレーンはローカル PC か Cloud Shell からインストールを行う。
Compute Engine VM 用の Anthos Service Mesh
同じメッシュ内の Compute Engine の マネージドインスタンスグループ (MIG) と GKE on Google Cloud 上の Service を両方とも管理、監視保護が可能になる。
GKEクラスタと同じサービスメッシュ内の MIG を示した図が以下のものとなる
VM へのインストール手順はこちらの Docs に記載されている
参考
Anthos Service Mesh
Anthos Service Mesh とは
Istio Traffic Management
その他リンクを各文言に付けています