No content

Software Engineer / Manager, Cloud Platform Group, AbemaTV, inc. 2011 年株式会社サイバーエージェント入社 2017 年より ABEMA に参画。プロダクト開発のテックリードを経て、 2019 年より Cloud Platform Group のマネージャーとして ABEMA のクラウ ドソリューション全般を担当。 永岡 克利 Katsutoshi Nagaoka Twitter @na_ga GitHub @na-ga 発表者紹介

1 従来構成と課題 Index FIFA ワールドカップ カタール 2022、(以後 ワールドカッ プ)Cloud Architecture 2 どのように構成変更を進めたか 3 キャパシティ戦略 4 スケール戦略 5 サービスメッシュの適用と効果 6 期間中の対応

従来構成と課題

2022 年前半のクラウドアーキテクチャ Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services 　　Cloud Bigtable Micro Services 　　Cloud Trace Micro Services 　　Pub/Sub Micro Services 　　Cloud Spanner Micro Services 　　Momerystore Micro Services 　　Cloud Storage Micro Services 　　BigQuery Micro Services 　　MongoDB Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services DynamoDB Micro Services SQS Micro Services SNS Micro Services Aurora Micro Services Lambda Micro Services S3 Micro Services Redshift Micro Services Kinesis Micro Services 　　Cloud CDN Region: 東京 & 台湾 Region: 東京 AWS Cloud Micro Services CloudFront Micro Services Edge Proxies Micro Services Edge Proxies Kubernetes Cluster Kubernetes Cluster App Mesh Anthos Service Mesh … etc … etc Client 2021 年12 月に開催した ABEMA Developer Conference 2021 300 以上のマイクロサービスを支えるクラウドアーキテクチャ戦略 より転載 使用割合: 東京 1 : 台湾 9 Plain mTLS

従来のクラウドアーキテクチャの課題 通信遅延 限定的な サービスメッシュ 耐障害性

大部分は 台湾リージョンで稼働し、 東京リージョンの利用は 一部に限られている 従来のクラウドアーキテクチャの課題 通信遅延 限定的な サービスメッシュ 耐障害性

大部分は 台湾リージョンで稼働し、 東京リージョンの利用は 一部に限られている 従来のクラウドアーキテクチャの課題 通信遅延 限定的な サービスメッシュ 耐障害性 構成上の理由により 台湾リージョンで サービスメッシュを 活用できていない

大部分は 台湾リージョンで稼働し、 東京リージョンの利用は 一部に限られている 従来のクラウドアーキテクチャの課題 通信遅延 限定的な サービスメッシュ 耐障害性 ワールドカップ向けの ライブ配信システムは リージョン障害への耐久性を必 須とする 構成上の理由により 台湾リージョンで サービスメッシュを 活用できていない

どのように構成変更を進めたか

Google Cloud 東京リージョンへの移設 & プロジェクトの分離 目的 ○ 通信遅延の短縮と、 ASM を全面的に活用できる構成に変更する 方針 ○ リージョン障害への耐久性は目的としない ○ ユーザーへのレスポンスに関わるサービスを東京に配置する ○ 上記以外はコスト単価の低い台湾リージョンを、新しい構成で配置する

従来の構成

移設期間中の構成

移設期間中の構成

移設期間中の構成

移設期間中の構成

移設期間中の構成

移設対応後の構成

通信遅延の削減効果 　例) 東京から台湾リージョンに通信していた API 　Request Duration 99 percentile を 150ms 削減 Baseline 400ms Baseline 250ms 7/06 7/12 7/14 7/18 7/08 7/10 7/16

AWS ソウルリージョンの立て付け 目的 ○ ワールドカップ向けライブ配信システムのリージョン障害耐久性 方針 ○ AWS Media Services に対応しているソウルリージョン環境を構築する ○ EKS 東京リージョンと同じ構成を行えるように EKS ソウルリージョンを提供する ○ 原則リージョンに閉じた設計とするが、例外的なクロスリージョン通信を許容する

従来の構成

耐障害性を目的としたソウルリージョン整備

リージョン毎にサービスメッシュを設計

例外的なクロスリージョン通信

ワールドカップに向けた構成 Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services Cloud CDN Region: 東京 & 台湾 Region: 東京 & ソウル AWS Cloud Micro Services CloudFront Micro Services Edge Proxies Micro Services Edge Proxies Kubernetes Cluster: 台湾 Kubernetes Cluster: ソウル App Mesh Anthos Service Mesh Client 使用割合: 東京 9 : 台湾 1 使用割合: 東京 5 : ソウル 5 Micro Services Micro Services Micro Services API Gateways Micro Services Edge Proxies Kubernetes Cluster: 東京 Micro Services Micro Services Micro Services API Gateways Micro Services Edge Proxies Kubernetes Cluster: 東京 App Mesh Internal ALB Plain mTLS

キャパシティ戦略

Google Cloud を主軸としたキャパシティプランニング AWS ○ ワールドカップ向けライブ配信システムを展開している ○ CDN 帯域の確保は必須であったが Origin への負荷は限定的となる ○ Security Group を用いて CDN Layer 以外の Origin アクセスを遮断 Google Cloud ○ ワーストケースを想定したシナリオによる負荷試験で大枠を捉える ○ 並行してアプリケーションの効率化を実施し、最終的なキャパシティを算出する ○ キャパシティプラニングは SRE セッションで触れられている為、ここでは割愛とする

Google Cloud を主軸としたキャパシティプランニング AWS ○ ワールドカップ向けライブ配信システムを展開している ○ CDN 帯域の確保は必須であったが Origin への負荷は限定的となる ○ Security Group を用いて CDN Layer 以外の Origin アクセスを遮断 Google Cloud ○ ワーストケースを想定したシナリオによる負荷試験で大枠を捉える ○ 並行してアプリケーションの効率化を実施し、最終的なキャパシティを算出する ○ キャパシティプラニングは SRE セッションで触れられている為、ここでは割愛とする

Google Cloud を主軸としたキャパシティプランニング AWS ○ ワールドカップ向けライブ配信システムを展開している ○ CDN 帯域の確保は必須であったが Origin への負荷は限定的となる ○ Security Group を用いて CDN Layer 以外の Origin アクセスを遮断 Google Cloud ○ ワーストケースを想定したシナリオによる負荷試験で大枠を捉える ○ 並行してアプリケーションの効率化を実施し、最終的なキャパシティを算出する ○ キャパシティプラニングは SRE セッションで触れられている為、ここでは割愛とする

マルチリージョンによるキャパシティ確保 キャパシティ懸念 Google Cloud 東京リージョンで 必要とするキャパシティを満たせない 可能性が生じた コンピュートからデータベースに 繋ぐパスにあるコンポーネントに キャパシティ上の懸念があった

台湾リージョン活用 Request Volume が大きく ユーザー体験に関わらない API を 集約したマイクロサービスを作成 台湾リージョンに配置し 懸念のあるコンポーネントに 大きな負荷を回避した構成に変更 マルチリージョンによるキャパシティ確保 強制アップデート後

マルチリージョンによるキャパシティ確保 強制アップデート後 クロスリージョン通信 東京リージョンに 依存しているサービス間通信は ASM の Multi Cluster Mesh を活用

● 準決勝 ストックアウト対策 11/20 12/18 12/13 12/03 11/24 ● 開幕 ● BEST16 12/09 ● 準々決勝 ● 決勝 11/23 ● 日本 vs ドイツ 11/27 ● 日本 vs コスタリカ 12/01 ● 日本 vs スペイン 12/05 ● 日本 vs クロアチア 12/17 ● 三位決定戦 11/22 ● アルゼンチン vs サウジアラビア ● スペイン vs ドイツ ● オランダ vs アルゼンチン 12/10 ● イングランド vs フランス ● フランス vs アルゼンチン ● カタール vs エクアドル ワールドカップの全 64 試合 ● オランダ vs アメリカ

● 準決勝 ストックアウト対策 11/20 12/18 12/13 12/03 11/24 ● 開幕 ● BEST16 12/09 ● 準々決勝 ● 決勝 11/23 ● 日本 vs ドイツ 11/27 ● 日本 vs コスタリカ 12/01 ● 日本 vs スペイン 12/05 ● 日本 vs クロアチア 12/17 ● 三位決定戦 11/22 ● アルゼンチン vs サウジアラビア ● スペイン vs ドイツ ● オランダ vs アルゼンチン 12/10 ● イングランド vs フランス ● フランス vs アルゼンチン ● カタール vs エクアドル 期間中はアメリカの感謝祭 & ブラックフライデーと重なっている 　　 クォータが緩和されていたとしても、ストックアウトが発生するリスクがある ● オランダ vs アメリカ ● 感謝祭 & ブラックフライデー

● 準決勝 ストックアウト対策 11/20 12/18 12/13 12/03 11/24 ● 開幕 ● BEST16 12/09 ● 準々決勝 ● 決勝 11/23 ● 日本 vs ドイツ 11/27 ● 日本 vs コスタリカ 12/01 ● 日本 vs スペイン 12/05 ● 日本 vs クロアチア 12/17 ● 三位決定戦 11/22 ● アルゼンチン vs サウジアラビア ● スペイン vs ドイツ ● オランダ vs アルゼンチン 12/10 ● イングランド vs フランス ● フランス vs アルゼンチン ● カタール vs エクアドル Future Reservations ※ を利用して、指定期間中のキャパシティを事前に確約した 　　 各ゾーン毎に Machine Type と台数を指定し、Google Cloud の承認を得る ● オランダ vs アメリカ Future Reservations ※ 当時 Private Preview として利用しましたが 2023 年内に一般提供 (GA) が計画されています ● 感謝祭 & ブラックフライデー

ストックアウト対策 Future Reservations ※ を利用して、指定期間中のキャパシティを事前に確約した 　　 単一ゾーン障害が発生しても影響がないように、必要なキャパシティの 1.5 倍を確保 Zone A 空き 33 Node 使用 100 Node Zone B 空き 33 Node 使用 100 Node Zone C 空き 33 Node 使用 100 Node 合計 300 Node

ストックアウト対策 Future Reservations ※ を利用して、指定期間中のキャパシティを事前に確約した 　　 単一ゾーン障害が発生しても影響がないように、必要なキャパシティの 1.5 倍を確保 Zone A 空き 50 Node 使用 100 Node Zone B 空き 50 Node 使用 100 Node Zone C 空き 50 Node 使用 100 Node 合計 300 Node + 空き 150 Node

ストックアウト対策 Future Reservations ※ を利用して、指定期間中のキャパシティを事前に確約した 　　 単一ゾーン障害が発生しても影響がないように、必要なキャパシティの 1.5 倍を確保 Zone A 空き 50 Node 使用 100 Node Zone B 空き 50 Node 使用 100 Node Zone C 空き 50 Node 使用 100 Node Zone A 使用 150 Node Zone B 使用 150 Node Zone C ゾーン障害 合計 300 Node 合計 300 Node + 空き 150 Node

スケール戦略

❶ Kubernetes のスケール戦略

固定サイズの Fixed と、リクエストに応じて動的に変動する Auto Scale 想定を超える負荷に備えた Node Pool 設計 　Kubernetes Cluster (GKE/EKS 共通)　 　Node Pool　 Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある 　Fixed (固定サイズ)　 Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する 　Auto Scale (動的サイズ)　

Pod Disruption Budget (PDB) による割合制御と Priority Class & Node Affinity を設定 Workload の特性に合わせた配置 　Kubernetes Cluster (GKE/EKS 共通)　 　Node Pool　 Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある 　Fixed (固定サイズ)　 Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する 　Auto Scale (動的サイズ)　 　Kubernetes Workload (GKE/EKS 共通)　 利用不能状態を許容する割合を指定 　PDB　 apiVersion: policy/v1beta1 kind: PodDisruptionBudget spec: maxUnavailable: 30% selector: matchLabels: name: xxx

Pod Disruption Budget (PDB) による割合制御と Priority Class & Node Affinity を設定 Workload の特性に合わせた配置 　Kubernetes Cluster (GKE/EKS 共通)　 　Node Pool　 Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある 　Fixed (固定サイズ)　 Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する 　Auto Scale (動的サイズ)　 　Kubernetes Workload (GKE/EKS 共通)　 Priority Class High として Fixed に配置 　Evict を避けたい Workload　

Pod Disruption Budget (PDB) による割合制御と Priority Class & Node Affinity を設定 Workload の特性に合わせた配置 　Kubernetes Cluster (GKE/EKS 共通)　 　Node Pool　 Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある 　Fixed (固定サイズ)　 Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する 　Auto Scale (動的サイズ)　 　Kubernetes Workload (GKE/EKS 共通)　 Priority Class High として Fixed に配置 Priority Class Middle として Fixed に配置 もし空きがない場合は Auto Scale に配置 　Evict を許容できる Workload　 　Evict を避けたい Workload　

Pod Disruption Budget (PDB) による割合制御と Priority Class & Node Affinity を設定 Workload の特性に合わせた配置 　Kubernetes Cluster (GKE/EKS 共通)　 　Node Pool　 Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある 　Fixed (固定サイズ)　 Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する 　Auto Scale (動的サイズ)　 　Kubernetes Workload (GKE/EKS 共通)　 Priority Class High として Fixed に配置 Priority Class Middle として Fixed に配置 もし空きがない場合は Auto Scale に配置 　Evict を許容できる Workload　 　Evict を避けたい Workload　

❷ Kubernetes Workload のスケール戦略

Workload 特性に合わせた HPA ○ CPU や Memory 等の Resource Metrics ○ Workload の負荷係数に対応した Custom Metrics Custom Metrics は正常に取得できない状況が発生しうる ○ Custom Metrics のみは設定しない ○ セーフガードとして Resource Metrics を必ず設定する Kubernetes Workload のスケール戦略

apiVersion: autoscaling/v2beta2 spec: metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 25 - type: External external: metric: name: "prometheus.googleapis.com|ccu_scale|gauge" target: type: AverageValue averageValue: "20000" Resource Metrics と Custom Metrics の設定例 Resource Metrics CPU 使用率 25% を設定 セーフガードとして必ず併用する Custom Metrics CCU 平均値 20,000 を設定 予想される局所的な負荷に備える

Custom Metrics 有効時は 1 を返却 最大 Replicas までスケールアウト apiVersion: autoscaling/v2beta2 spec: metrics: ... - type: External external: metric: name: "prometheus.googleapis.com|bulk_scale|gauge" target: type: Value value: "1" Custom Metrics による一括スケールアウト機構の設定例

❸ Monitoring System のスケール戦略

基本構成 Workload Metrics は Prometheus の Remote Write によって Victria Metrics Cluster に永続化

従来のスケール戦略 Metrics の種類毎に Prometheus を分離し、必要なリソースを割り当てる

従来のスケール戦略 対象 Workload のスケールアウトによって Promethues のキャパシティを超過する懸念

全ての Workload に重要度を制定 クリティカルパスとなる API に関わっているかを判断基準とする

重要度に応じて担当する Prometheus を分離 重要度の低い Workload による影響が全体に連鎖することを回避

Victoria Metrics キャパシティ超過時の防衛策 想定負荷を大きく超過した場合は、重要度の低い Workload の Scraping を停止

Google Managed Prometheus による可用性担保 HPA として使用するカスタムメトリクスは GMP を併用することで可用性を担保 ※ Managed Service for Prometheus が属する Cloud Monitoring は SLA 99.95% (月間 21 分のダウンタイム ) が適用される

Google Managed Prometheus 障害時の防衛策 GMP に障害が発生した場合は Victria Metrics Cluster に切り替える機構を整備 ※ 各種 HPA に設定するメトリクスキーを変更することで Stackdriver Adapter から Prometheus Adapter に切り替える

サービスメッシュの適用と効果

AWS ○ App Mesh は、従来から利用できる状態になっていた ○ リージョンに閉じた通信は App Mesh によるサービス間通信を適用した Google Cloud ○ ASM は、Google Cloud プロジェクト分離によって利用できる状態になった ○ 従来クライアント SDK で行っていた処理を ASM に置き換えを実施した App Mesh と Anthos Service Mesh を全体的に適用

サービスメッシュによる効果 自動回復性 障害の局所化 影響箇所の確認

レスポンスコード等による 指数 Backoff 再試行によって一 時的な異常を自動回復 サービスメッシュによる効果 自動回復性 障害の局所化 影響箇所の確認

レスポンスコード等による 指数 Backoff 再試行によって一 時的な異常を自動回復 サービスメッシュによる効果 自動回復性 障害の局所化 影響箇所の確認 障害影響を最小化し、障害が連 鎖しない仕組みとしてCircuit Breaker を随所に活用

レスポンスコード等による 指数 Backoff 再試行によって一 時的な異常を自動回復 サービスメッシュによる効果 自動回復性 障害の局所化 影響箇所の確認 Fault Injection による疑似的なエ ラーを発生させ、 障害が連鎖しないことを確認 障害影響を最小化し、障害が連 鎖しない仕組みとしてCircuit Breaker を随所に活用

サービスメッシュによる分散トレーシング活用 課題 ○ 統合負荷試験によって、ボトルネック箇所の特定に時間がかかっていた 方針 ○ ASM と Cloud Trace 連携による分散トレーシングを実現する ○ TraceId の伝搬を行う SDK を実装し Workload に適用する ○ オーバーヘッドを避けるために分散トレーシングの適用箇所は Workload 側で制御する

ASM と Cloud Trace 連携による分散トレーシング Head based Sampling Algorithm は呼び出し元の判定に従う

ASM と Cloud Trace 連携による分散トレーシング Global Setting で Sampling Rate を 0% に設定する

ASM と Cloud Trace 連携による分散トレーシング リクエストの起因となる Workload で Sampling Rate を上書き

ASM と Cloud Trace 連携による分散トレーシング 本番環境でも導入を進め、リアルトラフィックを用いた分析・改善を可能とした

期間中の対応

Grafana Dashboard の整備 ○ 想定範囲内の負荷傾向であることを随時確認 ○ 全体俯瞰用の Dashboard に加えて、重要システムの専用 Dashboard を整備 特別体制によるモニタリング

Grafana Dashboard の整備 ○ 想定範囲内の負荷傾向であることを随時確認 ○ 全体俯瞰用の Dashboard に加えて、重要システムの専用 Dashboard を整備 Grafana Unified Alert の活用 ○ Dashboard に紐づいた主要メトリクスに対する Alert を整備 ○ 紐づいている Dashboard のスクリーンショットを自動投稿し、即座に調査に取り掛かる 特別体制によるモニタリング

Grafana Dashboard の整備 ○ 想定範囲内の負荷傾向であることを随時確認 ○ 全体俯瞰用の Dashboard に加えて、重要システムの専用 Dashboard を整備 Grafana Unified Alert の活用 ○ Dashboard に紐づいた主要メトリクスに対する Alert を整備 ○ 紐づいている Dashboard のスクリーンショットを自動投稿し、即座に調査に取り掛かる 関連各所と連携したコミュニケーション ○ CyberAgent グループ管轄の関連システムと共同の監視体制 ○ Google Cloud / AWS / Akamai / MongoDB 社と密に連携した監視体制 特別体制によるモニタリング

Kubernetes のキャパシティ監視

Kubernetes Workload の HPA 可視化

重要システムの関連メトリクスを集約

まとめ

まとめ ワールドカップに向けたクラウドアーキテクチャの構成変更 マルチリージョンによるキャパシティ確保とストックアウト対策 Kubernetes および Monitoring System のスケール戦略 サービスメッシュの全体的な適用による恩恵を最大限に活用 社内外との連携や、重要コンポーネントの専用ダッシュボードによるモニタリング体制

No content