Upgrade to Pro — share decks privately, control downloads, hide ads and more …

大規模イベントを支えるクラウドアーキテクチャの実現 / ABEMA Cloud Platfor...

大規模イベントを支えるクラウドアーキテクチャの実現 / ABEMA Cloud Platform Architecture for Large-scale Events

FIFA ワールドカップ カタール 2022 に向けて、我々のクラウドアーキテクチャに対して、どのような懸念があったのか、どのような対応を行って懸念を解消したのか、キャパシティ戦略・スケール戦略・サービスメッシュ・モニタリングシステムなどを紹介します。

https://developer.abema.io/2023/sessions/zonrtHzFiY/?utm_medium=social&utm_source=speakerdeck

CyberAgent

April 19, 2023
Tweet

More Decks by CyberAgent

Other Decks in Technology

Transcript

  1. Software Engineer / Manager, Cloud Platform Group, AbemaTV, inc. 2011

    年株式会社サイバーエージェント入社 2017 年より ABEMA に参画。プロダクト開発のテックリードを経て、 2019 年より Cloud Platform Group のマネージャーとして ABEMA のクラウ ドソリューション全般を担当。 永岡 克利 Katsutoshi Nagaoka Twitter @na_ga GitHub @na-ga 発表者紹介
  2. 1 従来構成と課題 Index FIFA ワールドカップ カタール 2022、(以後 ワールドカッ プ)Cloud Architecture

    2 どのように構成変更を進めたか 3 キャパシティ戦略 4 スケール戦略 5 サービスメッシュの適用と効果 6 期間中の対応
  3. 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
  4. 大部分は 台湾リージョンで稼働し、 東京リージョンの利用は 一部に限られている 従来のクラウドアーキテクチャの課題 通信遅延 限定的な サービスメッシュ 耐障害性 ワールドカップ向けの

    ライブ配信システムは リージョン障害への耐久性を必 須とする 構成上の理由により 台湾リージョンで サービスメッシュを 活用できていない
  5. Google Cloud 東京リージョンへの移設 & プロジェクトの分離 目的 ◦ 通信遅延の短縮と、 ASM を全面的に活用できる構成に変更する

    方針 ◦ リージョン障害への耐久性は目的としない ◦ ユーザーへのレスポンスに関わるサービスを東京に配置する ◦ 上記以外はコスト単価の低い台湾リージョンを、新しい構成で配置する
  6. AWS ソウルリージョンの立て付け 目的 ◦ ワールドカップ向けライブ配信システムのリージョン障害耐久性 方針 ◦ AWS Media Services

    に対応しているソウルリージョン環境を構築する ◦ EKS 東京リージョンと同じ構成を行えるように EKS ソウルリージョンを提供する ◦ 原則リージョンに閉じた設計とするが、例外的なクロスリージョン通信を許容する
  7. ワールドカップに向けた構成 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
  8. Google Cloud を主軸としたキャパシティプランニング AWS ◦ ワールドカップ向けライブ配信システムを展開している ◦ CDN 帯域の確保は必須であったが Origin

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

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

    への負荷は限定的となる ◦ Security Group を用いて CDN Layer 以外の Origin アクセスを遮断 Google Cloud ◦ ワーストケースを想定したシナリオによる負荷試験で大枠を捉える ◦ 並行してアプリケーションの効率化を実施し、最終的なキャパシティを算出する ◦ キャパシティプラニングは SRE セッションで触れられている為、ここでは割愛とする
  11. • 準決勝 ストックアウト対策 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 アメリカ
  12. • 準決勝 ストックアウト対策 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 アメリカ • 感謝祭 & ブラックフライデー
  13. • 準決勝 ストックアウト対策 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) が計画されています • 感謝祭 & ブラックフライデー
  14. ストックアウト対策 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
  15. 固定サイズの Fixed と、リクエストに応じて動的に変動する Auto Scale 想定を超える負荷に備えた Node Pool 設計  Kubernetes

    Cluster (GKE/EKS 共通)   Node Pool  Future Reservations で確保した Capacity を常 時稼働し、通常時は 33% の空きがある  Fixed (固定サイズ)  Priority Class の低い Balloon Pod のみを配置 し、通常時は最小構成で稼働する  Auto Scale (動的サイズ) 
  16. 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
  17. 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 
  18. 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 
  19. 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 
  20. Workload 特性に合わせた HPA ◦ CPU や Memory 等の Resource Metrics

    ◦ Workload の負荷係数に対応した Custom Metrics Custom Metrics は正常に取得できない状況が発生しうる ◦ Custom Metrics のみは設定しない ◦ セーフガードとして Resource Metrics を必ず設定する Kubernetes Workload のスケール戦略
  21. 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 を設定 予想される局所的な負荷に備える
  22. 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 による一括スケールアウト機構の設定例
  23. Google Managed Prometheus による可用性担保 HPA として使用するカスタムメトリクスは GMP を併用することで可用性を担保 ※ Managed

    Service for Prometheus が属する Cloud Monitoring は SLA 99.95% (月間 21 分のダウンタイム ) が適用される
  24. Google Managed Prometheus 障害時の防衛策 GMP に障害が発生した場合は Victria Metrics Cluster に切り替える機構を整備

    ※ 各種 HPA に設定するメトリクスキーを変更することで Stackdriver Adapter から Prometheus Adapter に切り替える
  25. AWS ◦ App Mesh は、従来から利用できる状態になっていた ◦ リージョンに閉じた通信は App Mesh によるサービス間通信を適用した

    Google Cloud ◦ ASM は、Google Cloud プロジェクト分離によって利用できる状態になった ◦ 従来クライアント SDK で行っていた処理を ASM に置き換えを実施した App Mesh と Anthos Service Mesh を全体的に適用
  26. レスポンスコード等による 指数 Backoff 再試行によって一 時的な異常を自動回復 サービスメッシュによる効果 自動回復性 障害の局所化 影響箇所の確認 Fault

    Injection による疑似的なエ ラーを発生させ、 障害が連鎖しないことを確認 障害影響を最小化し、障害が連 鎖しない仕組みとしてCircuit Breaker を随所に活用
  27. サービスメッシュによる分散トレーシング活用 課題 ◦ 統合負荷試験によって、ボトルネック箇所の特定に時間がかかっていた 方針 ◦ ASM と Cloud Trace

    連携による分散トレーシングを実現する ◦ TraceId の伝搬を行う SDK を実装し Workload に適用する ◦ オーバーヘッドを避けるために分散トレーシングの適用箇所は Workload 側で制御する
  28. Grafana Dashboard の整備 ◦ 想定範囲内の負荷傾向であることを随時確認 ◦ 全体俯瞰用の Dashboard に加えて、重要システムの専用 Dashboard

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

    を整備 Grafana Unified Alert の活用 ◦ Dashboard に紐づいた主要メトリクスに対する Alert を整備 ◦ 紐づいている Dashboard のスクリーンショットを自動投稿し、即座に調査に取り掛かる 関連各所と連携したコミュニケーション ◦ CyberAgent グループ管轄の関連システムと共同の監視体制 ◦ Google Cloud / AWS / Akamai / MongoDB 社と密に連携した監視体制 特別体制によるモニタリング