© Matt. 2021. All rights reserved. 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 2021年11月15日 松沢 敏志 Google Cloud | Anthos Service Mesh(ASM)勉強会 クラウド技術情報共有コミュニティ勉強会

© Matt. 2021. All rights reserved. 1 自己紹介 一言でいうと 日立のクラウドCoEチーム所属のソリューションアーキテクト、通称CCoEの何でも屋 所属 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 職歴 (※1) - 2007年に日立製作所入社以降、LinuxカーネルモジュールやOSSの開発エンジニア、 Red Hat製品のテクニカルサービス/サポートサービスL3エンジニア、 VMware/Microsoft製品を活用した国内HCIビジネス企画/立ち上げ、などを経験 - 2019年10-11月に米国FinTech系スタートアップにてデータ分析プログラムの開発 (インターン) - 2020年4月に日立グループのクラウドCoEチーム設立とともに異動、 クラウドアーキテクト/SREの役割でAWS/Azure/GCP案件に参画しての設計支援活動を中心に、 社内へのクラウド技術の普及活動、社外イベント講演などのプレゼンス向上活動にも従事 資格・受賞歴 (※1) - AWS認定資格12種コンプ、Azure認定資格6種、GCP認定資格3種など - 2021 APN AWS Top Engineer & APN ALL AWS Certifications Engineer受賞 その他 - 好きなものは真っ赤なスポーツカーとロックミュージック、趣味は投資と仕事 - 次の目標は「Google Cloud Partner Top Engineerに、俺はなるっ!!!」 ※1：詳細はLinkedIn（https://www.linkedin.com/in/satoshi-matsuzawa-b209a1157/）をご参照ください。 まつざわ さとし 松沢 敏志

© Matt. 2021. All rights reserved. 2 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 3 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ の前に

© Matt. 2021. All rights reserved. 4 おさらい、マイクロサービスとは 用途や目的ごとに小さなアプリケーションを作って、それらを組み合わせてシステムを構築するアーキテクチャのパターン 密結合 疎結合 API

© Matt. 2021. All rights reserved. 5 おさらい、マイクロサービスの主な利点 マイクロサービスの方が 変更をかけやすい、開発がしやすい マイクロサービスの方が スケールアウトがしやすい

© Matt. 2021. All rights reserved. 6 マイクロサービスが抱える課題 ① 性能 ② サービス検出 (サービスディスカバリ) ⑤ セキュリティ ③ トラフィック制御 ④ 可観測性 (オブザーバビリティ) APIコールはメモリ処理と比較して遅い 依存関係にあるサービスの参照先が動的に変更されるので接続先情報の管理が大変 他サービス障害に引きずられて落ちないようAPIコールのリトライ、タイムアウト、サーキットブレーカの実装が必要 サービス間通信の可視化やログの追跡が困難で、レスポンス遅延やエラー発生がどこで起きたのかの特定が難しい サービス間の通信暗号化や認証・認可機能などの実装が必要

© Matt. 2021. All rights reserved. 7 マイクロサービスが抱える課題 ① 性能 ② サービス検出 (サービスディスカバリ) ⑤ セキュリティ ③ トラフィック制御 ④ 可観測性 (オブザーバビリティ) APIコールはメモリ処理と比較して遅い 依存関係にあるサービスの参照先が動的に変更されるので接続先情報の管理が大変 他サービス障害に引きずられて落ちないようAPIコールのリトライ、タイムアウト、サーキットブレーカの実装が必要 サービス間通信の可視化やログの追跡が困難で、レスポンス遅延やエラー発生がどこで起きたのかの特定が難しい サービス間の通信暗号化や認証・認可機能などの実装が必要 サービスメッシュが解決する課題

© Matt. 2021. All rights reserved. 8 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 9 サービスメッシュとは マイクロサービスごとに(サイドカー)プロキシを配置して他のサービスとのすべての通信をプロキシ経由に させ、プロキシの管理はコントロールプレーンにて一元的に行うことによって、サービスの依存関係の解決、 トラフィック制御、セキュリティ、可観測性などの機能を提供をする仕組みです。 すべてのサービスがメッシュ状に接続される構造から「サービスメッシュ」と呼ばれているようです。

© Matt. 2021. All rights reserved. 10 補足、サイドカーとは コレ！ 補助的な機能を盛り込んだコンテナを付属することで、 メインコンテナ自身には手を加えず(コード改修不要で)、 補助的な機能を実装することが可能なコンテナ技術です。

© Matt. 2021. All rights reserved. 11 サービスメッシュのユースケース

© Matt. 2021. All rights reserved. 12 サービスメッシュを実現する主要なソフトウェア CNCF(Cloud Native Computing Foundation)の卒業プロジェクトとなったことでも 話題になったソフトウェア、知名度は高い、読み方はリンカーディー AWS発祥のソフトウェア Microsoft発祥のソフトウェア Google発祥のソフトウェア、知名度は高い、 IBMやRed Hatも推しててOpenShiftなどでも採用されてる 読み方はイスティオ

© Matt. 2021. All rights reserved. 13 サービスメッシュを実現する主要なソフトウェア CNCF(Cloud Native Computing Foundation)の卒業プロジェクトとなったことでも 話題になったソフトウェア、知名度は高い、読み方はリンカーディー AWS発祥のソフトウェア Microsoft発祥のソフトウェア Google発祥のソフトウェア、知名度は高い、 IBMやRed Hatも推しててOpenShiftなどでも採用されてる 読み方はイスティオ 世はまさにサービスメッシュ戦国時代！！ 信長(Linkerd)、今川(Istio)、武田(App Mesh)、上杉(OSM)、だれが世を取るのかわからない!! ※武将とソフトウェアの対応は適当なので本当に意味はないです 道三(CFCN)の後ろ盾を得て、 今まさに桶狭間の戦いが起きようとしている!?

© Matt. 2021. All rights reserved. 14 各クラウドサービスにおけるサービスメッシュへの対応 Anthos Service Mesh (ベースはIstioの独自Distro) AWS App Mesh (ベースはAWS App Mesh) Open Service Mesh AKSアドオン (ベースはOSM) 今日はこちらについてのお話をします！

© Matt. 2021. All rights reserved. 15 各クラウドサービスにおけるサービスメッシュへの対応 Anthos Service Mesh (ベースはIstioの独自Distro) AWS App Mesh (ベースはAWS App Mesh) Open Service Mesh AKSアドオン (ベースはOSM) 今日はこちらについてのお話をします！ ちなみに、 3社ともベースの技術が違くて困ったなと思われた方、 そもそもIaaS(VM、ネットワークなど)の定義の仕方ですら まったく同じじゃないでしょ？でも使えてますよね？ ベース技術が違うからってビビることはありません。 いつも通り設定の項目が多少違うだけ、 何も問題はありません。恐れる必要はないでしょう。

© Matt. 2021. All rights reserved. 16 Anthos Service Mesh(ASM)とは Googleが提供するマネージドサービスメッシュ 動作環境としては次をサポート(※1) ‐Google Kubernetes Engine(GKE)(※2) ‐各Anthosクラスタ(VMware/ベアメタル/AWS/Azure) ‐各Anthosアタッチクラスタ(Amazon Elastic Kubernetes Service(EKS)/Azure Kubernetes Engine(AKS)) ※1: GKEとそれ以外でサポートするKubernetesバージョンの範囲が異なるので注意が必要 ※2: Autopilotは現時点では未サポートなので注意が必要 Istio --> Anthos Service Mesh(ASM) OSS Google Cloud ASMのメリット ‐Googleのサポートが得られる(要サポート契約) ‐Cloud Monitoring / Loggingと統合されている

© Matt. 2021. All rights reserved. 17 ASMとIstioの比較 項目 ASM GKE ASM On-Prem ASM Other Clouds Istio サポート Google Google Google コミュニティサポート サポート期間 (特定マイナーバージョン) 最低9か月 最低9か月 最低9か月 通常約6か月 コントロールプレーン管理 (istiod) Google管理 or ユーザ管理 ユーザ管理 ユーザ管理 ユーザ管理 (リソース管理、死活監視) mTLS証明書/鍵管理 Google管理(Mesh CA) or ユーザ管理(Istio CA) Google管理(Mesh CA) or ユーザ管理(Istio CA) ユーザ管理 (Istio CA) ユーザ管理 (Istio CA) トレーシング Cloud Trace Cloud Trace Zipkin, Jaeger, etc. Zipkin, Jaeger, etc. テレメトリ Cloud Monitoring + ASM Dashboard Cloud Monitoring Prometheus + Grafana Prometheus + Grafana サービスメッシュ可視化 ASM Dashboard Kiali Kiali Kiali ロギング Cloud Logging + ASM Dashboard Cloud Logging Stdout or other Stdout or other

© Matt. 2021. All rights reserved. 18 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 19 v1 Pod (k8sリソース) Envoy Proxy Application Container IstioとKubernetesのAPIリソース相関図 Gateway (Istioリソース) VirtualService (Istioリソース) DestinationRule (Istioリソース) Pod (k8sリソース) istio-ingressgateway v2 Pod (k8sリソース) Envoy Proxy Application Container 設定 設定 参照 サブセット参照 サブセット定義 App Service (k8sリソース) Endpoints 指定 転送先ルートとして指定 Selector istiod経由で Endpointを取得 通信

© Matt. 2021. All rights reserved. 20 Istio Gatewayリソース apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: webapp-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" 外からメッシュへ入ってくる通信、外へ出ていく通信を管理するためのリソース ➢ 外から/内から待ち受けるプロトコルやポートなどを定義 ➢ Selectorで利用するIngress/Egress GatewayのPodを指定 ➢ デフォルトで作られるIngress Gatewayを指定する場合は、 "istio: ingressgateway"を指定する ➢ Ingress Gatewayが複数ある場合やEgress Gatewayをデプロ イした場合は、対象のGateway Podに指定したLabel値を Selectorに指定する ➢ TLS終端なども定義可能 http://*:80/ で受付

© Matt. 2021. All rights reserved. 21 Istio VirtualServiceリソース apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: webapp-ingress spec: hosts: - "webapp.sample.com" gateways: - webapp-gateway http: - route: - destination: host: webapp subset: v1 weight: 75 - destination: host: webapp subset: v2 weight: 25 トラフィックの振り分け、ルーティングテーブルのルールを定義するリソース ➢ パスベースやヘッダー情報ベースなどの基本的なルーティング からトラフィック分割(Canary)などの高度な定義も指定可能 ➢ Gatewaysセクションでルールを適用するGatewayを指定 ➢ Destinationセクションで送信先のk8s Serviceを指定 (Subsetについては次のDestinationRulesリソース参照) ➢ タイムアウトやリトライ、疑似障害注入(Fault Injection)など の設定を構成することも可能 webappというk8sサービスの v1サブセットへ75%振り分けて v2サブセットへ25%振り分け というCanaryの例

© Matt. 2021. All rights reserved. 22 Istio DestinationRuleリソース apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: webapp-route spec: host: webapp trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN 転送先サービスのサブセット化や各種トラフィックポリシーを定義するリソース ➢ 負荷分散ポリシーにはシンプルな分散アルゴリズムから ローカリティを意識した高度な分散アルゴリズムも指定可能 ➢ 流量制御としてコネクション数の上限値、異常検知によるサー キットブレーカの定義が可能 ➢ サービスとのTLS設定について定義可能 webappというk8sサービスの version: v1ラベルが付与された Podをサブセットv1、 version: v2ラベルの付与された Podをサブセットv2と定義

© Matt. 2021. All rights reserved. 23 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 24 ASMの主要な設計ポイント 1. どこまでGoogle管理にするのか ⚫ コントロールプレーン(Istiod)管理 ⚫ データプレーン(Envoy proxy)管理 ⚫ mTLS証明書/鍵管理 2. 課金プランをどうするのか 3. ネットワーク構成をどうするのか

© Matt. 2021. All rights reserved. 25 コントロールプレーンIstiod管理 (Google管理 vs ユーザ管理) GKEリリースチャンネルを利用するならGoogle管理、それ以外の構成だと選択肢自体がユーザ管理のみです Google管理 Good Point 管理はGoogle任せなのでユーザはよりビジネスロジックに注力できる Bad Point リリースチャンネルのGKE構成のみで利用可能、カスタムCA利用不可 = GKEノード上にリソースとして展開 ユーザ管理 (In-cluster) Good Point バージョン管理、更新タイミングなどをユーザがある程度制御できる Bad Point Istiodを定期的にユーザが更新する必要があるので手間がかかる

© Matt. 2021. All rights reserved. 26 補足、GKEリリースチャンネルについて Kubernetesのコントロールプレーンとノードを自動アップデートするモードです (前回のGKE勉強会より抜粋) インターネット上に転がっている情報の中には「StableチャンネルだとASMがサポートされない」、 「StableチャンネルではIstiodのGoogle管理は利用できない」とウソを言っていることがあります。 現在ではちゃんとStableチャンネルでもサポートはされますのでご安心ください。

© Matt. 2021. All rights reserved. 27 ASMリリースチャンネルについて ASMのコントロールプレーンを自動アップデートするモード、概念はGKEリリースチャンネルと同じです チャンネル 利用可能なバージョン 詳細 Rapid 最新のASMバージョン アップグレード頻度高。 最新の機能を早く利用したい人向け、テスト環境/評価環 境などでの利用を推奨されるチャンネル。 Regular Rapidを経たASMバージョン アップグレード頻度中。 最新機能は使いたいけど、なるべく安定したものを使いた いという欲張りさん向けのチャンネル。 Stable Regularを経たASMバージョン アップグレード頻度低。 安定性を最優先にするようなプロダクション用途での利用 を推奨されるチャンネル。

© Matt. 2021. All rights reserved. 28 Google管理データプレーンの適用について Google管理データプレーンとは Google管理コントロールプレーンの自動アップグレード時に、 サイドカープロキシも自動アップグレードを行う機能です。 現在はASMのRapid/Regularチャンネルのみに対応しています。 Google管理データプレーンの適用について ユーザがGoogle管理コントロールプレーンのアップグレードを 検知して、手動でサイドカープロキシのアップグレードを実施、 という運用が省略できるのでとても楽になる見込みです。 ただし、現時点ではプレビュー段階の機能のためプロダクショ ン用途での適用は現時点では見送った方が良いかもしれません。 ①こっちが自動でアップグレードされたら ②こっちも自動でアップグレードしてくれる ご参考: Envoy Proxyの手動アップグレード手順 1. ASMのコントロールプレーンがアップグレードされたことを確認する 2. 手動でEnvoy Proxyを含むKubernetes Deploymentリソースを入れ替える $ kubectl rollout restart -n 例えば以下のメトリクスを確認するなどCloud Monitoringからも確認できる - Resource type: Kubernetes Container - Metric: Proxy Clients - Group By: control_plane_version

© Matt. 2021. All rights reserved. 29 mTLS証明書/鍵管理 (Mesh CA vs Istio CA) カスタムCAが必要な場合はユーザ管理(Istio CA)、それ以外はGoogle管理(Mesh CA)がおすすめです Google管理 (Mesh CA) ユーザ管理 (Istio CA、旧称Citadel) IstiodをGoogle管理とした場合は、Istio CAを選択することができません。 カスタムCAが必要な場合は、Istiodをユーザ管理(In-cluster)とする必要があります。 Good Point ローテーションを意識しなくていい Good Point カスタムCAを扱うことができる Bad Point Istiodをユーザ管理(In-cluster)にする必要がある vs

© Matt. 2021. All rights reserved. 30 vs 課金ライセンス (Anthosライセンス vs ASMスタンドアロン) GKEでASMのみ使う場合はASMスタンドアロンライセンスの方が安くなる可能性あるので一考の余地あり Anthosライセンス https://cloud.google.com/anthos/pricing ASMスタンドアロンライセンス https://cloud.google.com/service-mesh/pricing ➢ ノードのvCPU数に基づいた従量課金制 ➢ オンプレミスやマルチクラウドでのASMには必須 ➢ ASM以外のAnthos機能を使う場合にも必須 ➢ クラスタ数とPod数に基づいた従量課金制 (2021/10までは無料だったけど、、、) ➢ GKEでASMのみ使う際に利用可能 Anthos APIをプロジェクトで有効化するとAnthosライセンス料金での請求となるため、 ASMスタンドアロンライセンスを利用したい場合は注意が必要です。 (とはいえ、有料化されたのでスタンドアロンライセンスを利用するメリットはだいぶ薄れた感はある、、、)

© Matt. 2021. All rights reserved. 31 Ingressネットワーク構成 (L4LB vs L7LB、外部 vs 内部) ASMのデフォルトネットワーク構成 (=External L4LB) k8s deployment istio-ingressgateway k8s deployment Envoy Proxy App B Container k8s deployment Envoy Proxy App A Container k8s service: LoadBalancer istio-ingressgateway 外部TCP負荷分散 Cloud Load Balancing Replica: 2 Limits: CPU: 2, MEM: 1Gi Requests: CPU: 100m, MEM: 128Mi Sidecar(Envoy Proxy) Limits: CPU: 100m, MEM: 50Mi Requests: CPU: 10m, MEM: 10Mi ➢ istio-ingressgateway は Deployment として配置、 Service のタイプは LoadBalancer が指定されていて実体は外部TCP負荷分散が裏で動作している ➢ アクセス元制限をするのであればServiceを書き換えて loadBalancerSourceRanges でアクセス元IPを定義する kube-proxy(iptables) spec: loadBalancerSourceRenges: - “1.2.3.4/27" - “5.6.7.8/30" - “9.10.11.12/28" 特定の送信元からのアクセスに制限する例

© Matt. 2021. All rights reserved. 32 Ingressネットワーク構成 (L4LB vs L7LB、外部 vs 内部) Cloud Armor(WAF)やCloud CDNとの統合をするなら外部HTTP(S)負荷分散に入れ替え k8s deployment istio-ingressgateway k8s deployment Envoy Proxy App A Container k8s service: NodePort(NEG有効) istio-ingressgateway ➢ Ingress を作成し、istio-ingressgateway の Service を NodePort にして NEG を有効化する ➢ istio-ingressgateway のヘルスチェックは /healthz/ready の15021ポートを指定する NEG(Network Endpoint Group) k8s ingress 外部HTTP(S)負荷分散 Cloud Load Balancing metadata: annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: NodePortz BackendConfigで /healthz/ready の Port 15021 に対してヘルスチェックを設定 API Gatewayなどをフロントに置いて、Podへは内部通信のみとするならば内部負荷分散へ metadata: annotations: cloud.google.com/load-balancer-type: "Internal" metadata: annotations: kubernetes.io/ingress.class: "gce-internal" L4LB(ServiceのLoadBalancerタイプ)の場合は定義にこちら(↓)を挿入 L7LB(Ingress)の場合は定義にこちら(↑)を挿入

© Matt. 2021. All rights reserved. 33 Egressネットワーク構成のベストプラクティス 多層防御アーキテクチャとするのが良いでしょう。

© Matt. 2021. All rights reserved. 34 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 35 アップグレードの基礎 リリースサイクル ➢ ASMは3か月~ごとに最新マイナーバージョンをリリース、パッチは~1か月ごとにリリース ➢ ASMはIstioのリリースに加えて、独自にセキュリティおよびバグ修正を提供 ASMのバージョンポリシー ➢ ASMのマイナーバージョンはKubernetesの特定マイナーバージョン1つのみに対応 例外でGKEについては(GKE Stableチャンネルなどの関係で)古いKubernetesのマイナーバージョンも一部対応 1.11.2-asm.17 マイナーバージョン パッチバージョン ASM独自パッチバージョン 1.11.x 1.21.x 1.10.x 1.20.x 1.9.x 1.19.x ASM Kubernetes

© Matt. 2021. All rights reserved. 36 アップグレードのパターン Google管理コントロールプレーン(リリースチャンネル)を利用している場合 ➢ 各チャンネルごとに設定された頻度に従い、コントロールプレーンが自動アップグレードされる ➢ データプレーンはユーザ管理の場合は手動アップグレードが必要 ➢ 自動アップグレード自体は無効化できない ユーザ管理コントロールプレーンを利用している場合 ➢ サポートが切れる前にユーザによるコントロールプレーン及びデータプレーンの手動アップグレードが必要 ➢ マイナーバージョンを飛ばしたアップグレードは避け、直上へのアップグレードを数回転させることを推奨

© Matt. 2021. All rights reserved. 37 本番環境で無理なくGKE+ASMをアップグレードしていくには 2. 自動アップグレードの前にテストを行う 3. なるべくStableチャンネルを使う 4. メンテナンス時間枠を正しく設定する 5. メンテナンス除外枠を正しく設定する ➢ テスト用クラスタを常設し、事前にテスト用クラスタで手動で最新バージョンにあげて動作確認をする ➢ バグもアップグレード頻度も少なめにする ➢ ビジネス時間と被らないようにする ➢ ビジネスのピークタイム (ECサイトのセールなど)は絶対に避けよう ワークフロー例 1. アップグレードの存在にいち早く気付く ➢ Pub/SubとCloud Functionsを設定してアップグレードのメッセージ通知をタイムリーに受け取る

© Matt. 2021. All rights reserved. 38 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 39 ASMの使い方の例 トラフィック制御 ‐ カナリアリリース ‐ パスベースルーティング ‐ ヘッダー情報を基にしたルーティング ‐ カオスエンジニアリング ‐ サーキットブレーカ オブザーバビリティ(可観測性) ‐ ASM Dashboard ‐ ログ・メトリック ‐ 分散トレーシング セキュリティ ‐ Mutual TLS(mTLS) ‐ ASMユーザアクセス制御 ‐ Anthos Security Insights

© Matt. 2021. All rights reserved. 40 トラフィック制御

© Matt. 2021. All rights reserved. 41 カナリアリリースの設定例 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - route: - destination: host: service_b subset: v1 weight: 95 - destination: host: service_b subset: v2 weight: 5 service_a service_b v1 service_b v2 service_b v1 : 95% 5% 一般的なカナリアの例

© Matt. 2021. All rights reserved. 42 webapp auth パスベースルーティングの設定例 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: webapp spec: hosts: - webapp http: - match: - uri: prefix: "/login" route: - destination: host: auth - route: - destination: host: webapp パスベースルーティングの例 frontend

© Matt. 2021. All rights reserved. 43 service_b v1 service_b v2 ヘッダー情報を基にしたルーティングの設定例 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - match: - headers: end-user: exact: matt route: - destination: host: service_b subset: v2 - route: - destination: host: service_b subset: v1 matt 上記以外 ユーザIDに基づくルーティングの例

© Matt. 2021. All rights reserved. 44 カオスエンジニアリングの設定例 カオスエンジニアリングとは 本番稼働中のサービスにあえて疑似的な障害を起こして、 実際の障害にもちゃんと耐えられるようにするための取り組み 疑似障害注入(Fault Injection)の設定例 ASM(Istio)では疑似障害としてレスポンス遅延を起こしたり、 エラーレスポンスを返却させたりすることが可能 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - fault: delay: fixedDelay: 7s percentage: value: 100 match: - headers: end-user: exact: matt route: - destination: host: service_b subset: v1 - route: - destination: host: service_b subset: v1 → 例では matt さんからのアクセスの場合だけ7秒だけ遅延を発生

© Matt. 2021. All rights reserved. 45 サーキットブレーカの設定例 サーキットブレーカとは apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: webapp spec: host: webapp trafficPolicy: connectionPool: tcp: maxConnections: 100 http: http2MaxRequests: 1000 maxRequestsPerConnection: 10 outlierDetection: consecutive5xxErrors: 5 interval: 30s baseEjectionTime: 3m maxEjectionPercent: 100 他のサービス障害に引きずられて連鎖的に障害を起こして しまうのを抑制するための手法です。 1. リクエスト数が閾値を超えるとエラーを返却する 2. リクエスト先からエラーが返ってきた場合に 一定期間負荷分散対象から除外する 流量制御、外れ値検出の設定例 →例では30秒間に5回連続でリクエスト先からエラーが 返ってきたら3分間はそのリクエスト先を振り分け先から外す

© Matt. 2021. All rights reserved. 46 オブザーバビリティ(可観測性)

© Matt. 2021. All rights reserved. 47 ASM Dashboard ➢ サービス間の依存関係を可視化 ➢ SLO(サービスレベル目標)を使ったサービスレベルの監視、アラート

© Matt. 2021. All rights reserved. 48 ログ・メトリック ➢ Cloud Monitoring、Cloud Loggingとの連携 ➢ 監査ログはCloud Audit Logsで取得 ↓Envoyのアクセスログを有効化するには 追加設定が必要だよ

© Matt. 2021. All rights reserved. 49 分散トレーシング Envoyの分散トレーシング機能と Cloud Traceとで連携可能 ↓トレーサーにデータを送るには設定が必要だよ！

© Matt. 2021. All rights reserved. 50 セキュリティ

© Matt. 2021. All rights reserved. 51 Mutual TLS(mTLS) サーバ⇔クライアント間の相互認証(HTTPS+TLSクライアント認証)を行う。 →サービス間通信を暗号化するケースで利用する。 mTLSは2つのモードが設定可能です。 Permissive: 暗号化された通信と平文どちらも許容(デフォルト) Strict: 暗号化された通信のみ許容 ↓名前空間(Namespace)ごとに設定する場合 ←ワークロードごとに設定する場合 ↓

© Matt. 2021. All rights reserved. 52 ASMユーザアクセス制御 ➢ Identity-Aware Proxy(IAP)によるユーザ認証 https://cloud.google.com/service-mesh/docs/unified-install/options/iap-integration ➢ 既存のIDプロバイダでのユーザ認証 https://cloud.google.com/service-mesh/docs/unified-install/options/end-user-auth

© Matt. 2021. All rights reserved. 53 Anthos Security Insights(プレビュー)

© Matt. 2021. All rights reserved. 54 本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ

© Matt. 2021. All rights reserved. 55 まとめ ⚫ サービスメッシュはマイクロサービスの課題を解決するソリューションです。 ⚫ ASMはGoogleサポートを得られるIstioベースのマネージドサービスメッシュです。 ⚫ ASMはGKE以外のKubernetes(オンプレ、他クラウド)でもサポート対象です。 ⚫ 運用をうまく回すには事前のアップグレード戦略の作成がとっても重要です。

© Matt. 2021. All rights reserved. 56 終わりに とはいえ、サービスメッシュ/ASMはまだまだ過渡期、 今日できなかったことが明日できるようになっていても可笑しくありません！ 特に今回の資料で「〇〇は未サポート」「××はプレビュー機能」と記載した部分は、 近い将来、間違いなく情報に変化が起きると思われます！ ご利用の際は、常に最新の情報を公式ドキュメントから入手するよう心がけましょう！ ASM公式ドキュメント: https://cloud.google.com/service-mesh/docs Istio公式ドキュメント: https://istio.io/latest/docs/

© Matt. 2021. All rights reserved. END Google Cloud | Anthos Service Mesh(ASM)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年11月15日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志