なぜABEMAは「サッカーW杯」を安定配信できた？ 担当者が明かすリアーキテクチャ、サービスメッシュ導入とは：キャパシティーとスケール戦略の全貌

ABEMAの配信プラットフォームはAmazon Web ServicesとGoogle Cloudの特徴をそれぞれ生かしたクラウドネイティブなアーキテクチャで構成されている。2022年に開催された「FIFA ワールドカップ カタール 2022」の配信に当たって、安定配信を実現するためリアーキテクチャに取り組んだという。どのような取り組みだったのか。

[齋藤公二，＠IT]

　「新しい未来のテレビ」として2016年に開局し、2022年には「FIFA ワールドカップ カタール 2022」（以下、ワールドカップ）を全64試合無料生中継を実施して知名度や人気が急上昇した「ABEMA（アベマ）」。配信時はデーリーアクティブユーザーが1700万人、ウイークリーアクティブユーザーが3400万人を突破するなど、ライブ配信システムの構築、運用面からも大きな注目を集めた。

　AbemaTVが2023年4月19日に実施した開発者向けオンラインイベント「ABEMA Developer Conference 2023」で、その舞台裏が明らかにされた。本稿では、ABEMAの永岡克利氏（Cloud Platform Group Manager）による講演内容をお伝えする。

AWSとGoogle Cloudの特徴を生かしたマルチクラウド構成

　ABEMAの配信プラットフォームは、Amazon Web Services（AWS）とGoogle Cloudの特徴をそれぞれ生かしたマルチクラウド環境で構成されている。アプリケーションはGKE（Google Kubernetes Engine）を活用したマイクロサービスとして展開され、メディアアセットマネジメント（MAM）システムはAWS EKS（Elastic Kubernetes Service）を活用したマイクロサービスとして展開されている。

　ワールドカップのような大規模イベントを配信するに当たって、既存のクラウドアーキテクチャには大きく分けて3つの課題があり、どう乗り越えるかが大きなチャレンジになったという。

ABEMA Cloud Platform Group Manager 永岡克利氏

　「課題の1つ目は通信遅延です。アプリケーションを展開しているGoogle Cloudは東京リージョンと台湾リージョンを利用していましたが、約9割のマイクロサービスは主要なデータベースが稼働している台湾リージョンを利用していました。ユーザーのリクエストが台湾リージョンを経由するため通信遅延が増加し、より良いユーザー体験を提供できない可能性がありました。2つ目は、サービスメッシュです。Google Cloudはサービスメッシュソリューションとして『Anthos Service Mesh（ASM）』を提供していますが、フリートと呼ばれるコンポーネントの制約により、台湾リージョンではASMを適用できませんでした。3つ目は、ライブ配信システムの耐障害性です。ワールドカップに合わせてライブ配信システムにAWSのMedia Servicesを利用する予定でしたが、ライブ配信システムではAWSのリージョン障害への耐久性が必須要件でした。ただ、既存のMAMシステムでは障害への耐久性を必須としていなかったため、関連するマイクロサービスを展開するEKSを含めたマルチリージョンの立て付けが必要となりました」（永岡氏）

AWSとGoogle Cloudそれぞれで大規模な構成変更を実施、3つの課題を解消

　これら3つの課題を解消するために、クラウドアーキテクチャ構成を大規模に変更した。

　まず、台湾リージョンに起因していた「通信遅延」の課題を解消するため、通信遅延の短縮とASMを全面的に活用できる構成に変更した。具体的には、ユーザーのレスポンスに関わるマイクロサービスとデータベースを東京リージョンに移設した。

　「ユーザーのレスポンスに関わらないマイクロサービスの移設先として、本番環境専用のGoogle CloudプロジェクトにGKE台湾リージョンを構築。GKE東京リージョンと同じメッシュにひもづけることでASMによるクロスリージョン通信を実現しました。なお、従来利用していた『Cloud Spanner』や『Bigtable』などのマネージドデータベースは、Google Cloudプロジェクトの移設を効率的にできる手段が提供されていないため、東京リージョンのレプリケーションを構築しました。また、セルフホスティングしているMongoDBは、本番環境専用のプロジェクトに東京リージョンのシャードを追加しレプリケーションを構築しました。その上で、ユーザーのレスポンスに関わらないマイクロサービスを新しい構成のGKE台湾リージョンに展開。東京と台湾の両方のリージョンでリクエストを受け入れる構成にし、Cloud DNSのルーティングポリシーのウエイトを段階的に調整することで、東京リージョンへの移設を完了しました」（永岡氏）

　これにより、移設前後で比較すると、東京から台湾リージョンに通信していたAPIが従来の400msから250msに改善し、150msの通信遅延を削減できた。

　次に、AWSに起因した「ライブ配信システムの耐障害性」の課題を解消するため、Media Servicesの技術検証を進めた。Media Servicesは東京リージョンで利用することに加え、耐障害性のためにソウルリージョンを整備した。ソウルリージョンはMedia Servicesが大阪リージョンをサポートしていないことから選定した。

　「AWSのサービスメッシュとして提供されている『App Mesh』はリージョンごとにサービスメッシュを設計する必要があります。そのため基本的にはリージョンに閉じた設計としつつ、例外的にクロスリージョン通信をするパターンとしました。クリティカルパスに関わらない幾つかのマイクロサービスは東京リージョンのみで稼働し、ソウルリージョンから通信します。App Meshはリージョナルリソースなので、VPCピアリングとインターナルALBでクロスリージョン通信を実現しました」（永岡氏）

　ソウルリージョンの整備で、リージョンごとにライブ配信するシステムを構築できた。

構成変更後のアーキテクチャ（永岡氏の講演資料より）

約1カ月にわたる大規模イベント配信に備え、キャパシティー戦略とスケール戦略を立案

　この大規模な構成変更が完了したことを受けて、キャパシティー戦略を立てた。キャパシティープランニングの主軸はGoogle Cloudとなった。これは、ライブ配信システムを展開するAWSでは、AkamaiやAmazon CloudFrontなどのCDNが存在するため、負荷が大きく変動しないためだ。一方、Google Cloudはアプリケーションを展開しているため、大規模な負荷が発生する。

　「キャパシティープランニングには2つの戦略で臨みました。1つ目はマルチリージョンを活用したキャパシティー確保です。GKEなどのコンピュータリソースからデータベースにつなぐ経路の問題で、必要とするキャパシティーを東京リージョンで確保できない懸念が生じました。そこで、ユーザー体験に関わらないAPIのうち、特にRPS（リクエスト／秒）の大きいAPIを切り出したマイクロサービスを実装し、それらを台湾リージョンに展開することで、懸念のあるコンポーネントに負荷がかからない構成に変更しました。効果的にマルチリージョンを使用することで必要とするキャパシティーを分散したのです。2つ目は、ストックアウト対策です。ワールドカップ期間は、感謝祭とブラックフライデーが重なっていました。クオーター（上限緩和）の緩和を申請していましたが、急激に需要が増加すると、実際にはリソースが足りなくなり使用できないストックアウトが発生する懸念があります。これに対しては、プライベートプレビュー版だった『Future Reservations』と呼ばれる機能を利用しました。ゾーンごとにマシンタイプと台数を指定し、Google Cloudの承認を得ることで、未来の期間におけるキャパシティーの確約を得ることができます。同機能により必要なキャパシティーの1.5倍を確保できました」（永岡氏）

　このようにしてキャパシティーを確保した後は、キャパシティーを効果的に使用するためのスケール戦略を立てた。スケール戦略は、Kubernetesのスケール戦略、Kubernetesワークロードのスケール戦略、モニタリングシステムのスケール戦略の3つだ。

　「Kubernetesのスケール戦略では、想定を超える負荷に備えたNode Pool設計を進めました。固定サイズの『Fixed』とリクエストに応じて動的に変動する『Auto Scale』という2つのNode Poolを設け、通常時にNodeリソースを効率よく使用しつつ、想定負荷を超過した場合は新規Nodeを迅速に起動できる構成にしました。Kubernetesワークロードのスケール戦略では、ワークロードの特性に合わせたHPA（Horizontal Pod Autoscaler）の活用に取り組みました。HPAではリソースメトリクスをベースとし、一部のワークロードはカスタムメトリクスを使用します。試合がハーフタイムに入るとユーザーは一斉に回遊を始めますが、カスタムメトリクスで局所的な負荷に対応しています」（永岡氏）

イベント期間中、GKEは1万2000コア規模にスケールアウト、複数企業が密に連携

　モニタリングシステムのスケール戦略については、PrometheusとVictoriaMetricsの利用方法を解説した。

　「ワークロードのメトリクスは同じKubernetesで稼働するPrometheusが担当します。その後、VictoriaMetricsに対してリモート書き込みを行い永続化します。Prometheusは、HTTP、GRPC、Istioなどのメトリクスの種類ごとに分離されていて、全てのワークロードごとに重要度を設定しています。想定を超えたスケールが発生した場合、重要度の高いワークロードを担当するPrometheusが、重要度の低いワークロードによる影響が全体に広がることを回避できるようにしています。VictoriaMetricsのキャパシティーが超過した場合は、重要度の低いワークロードのスクレイピングを停止するオペレーションを整備しました。また、モニタリングシステムに発生した障害がワークロードのスケール性質に影響を及ぼす可能性もあるため『Google Managed Prometheus』も併用しました」（永岡氏）

　ワールドカップに合わせて全面採用されたのがサービスメッシュだ。永岡氏は、サービスメッシュ適用の効果として「自動回復性」「障害の局所化」「障害による影響箇所の確認」の3つがあったとし、こう解説した。

　「ネットワークレイヤーで一貫したリトライを実装することで、あらゆるサービス間通信において一時的な異常の自動回復性を実現できました。ABEMAは300以上のマイクロサービスや関連システムが展開されていますが、一部のサービスで発生したスローダウンが全体に連鎖して大きな障害につながることがありました。小さく壊れるアーキテクチャに改善し、サーキットブレーカーを随所に活用したことで、障害が局所化されました。また、フォールトインジェクションを活用することで、一部のサービスの障害や応答速度の意図的な悪化など、シミュレーションを容易に実現できました。副次的に分散トレーシングも実現でき、ワールドカップ期間中におけるリアルタイムトラフィックを用いた分析も可能になりました」（永岡氏）

　ワールドカップ期間中は、ユーザーの行動パターンや負荷傾向を瞬時に把握するためにダッシュボードを整備し、重要システムに対するアラートとアラートにひも付くダッシュボードで即座に調査に取り掛かれる状況を整備した。また、Google Cloud、AWS、Akamai、MongoDB社と密に連携した監視体制を構築した。一部のGKEは1万2000コア規模にスケールアウトしたという。負荷試験によるシナリオと乖離（かいり）がないかどうかを確認し、懸念がある場合は処理の最適化など対応を随時実施した。

ダッシュボードの画面（永岡氏の講演資料より）

　永岡氏は、次のようにまとめ、講演を締めくくった。

　「クラウドアーキテクチャの構成変更、キャパシティーの確保、負荷に応じたスケールアウト、サービスメッシュを最大限に活用したことで、より堅牢（けんろう）なシステムを実現できました。負荷傾向を確認するモニタリング体制強化により、ワールドカップの配信を無事に成功させることができました」