ABEMAの本番環境負荷試験への挑戦

SRE NEXT 2025 で発表した資料です。

Transcript

1. AbemaTV, Inc. All Rights Reserved
 AbemaTV, Inc. All Rights Reserved
 1 ABEMA の 本番環境負荷試験への挑 戦 2025 July 12th 宮﨑 大芽
2. AbemaTV, Inc. All Rights Reserved
 宮﨑 大芽 2022年にサイバーエージェントに中途入社。
 入社後はABEMAにてバックエンドエンジニアとしてサービス開発に従事。
 2024年よりABEMAのSREとしてサービスの信頼性向上を目指し、特に本番環境を用い た負荷試験や障害試験の領域を中心に活動しています。
 2 Profile
3. AbemaTV, Inc. All Rights Reserved
 3 1. ABEMAについて 2. 「本番」で試験するに至った背景 3. 設計 4. 導入計画 5. 組織の合意形成 6. 得られた成果 7. 今後の展望 INDEX
4. AbemaTV, Inc. All Rights Reserved
 ABEMAについて 4
5. AbemaTV, Inc. All Rights Reserved
 ABEMAについて 登録不要で、いつでも無料で楽しめる 24時間365日編成されているリニア配信と 見逃した作品を好きなタイミングでオンデマンドでも楽しむこともできます。 国内最大級のオリジナルエピソード数 オリジナルエピソード数は国内発の動画サービスで日本No.1(※)を誇り、 注目の新作映画、国内外の人気ドラマ、話題のアニメなど豊富なラインナップの作品や、 様々な音楽や舞台のオンラインライブも展開。 ※2024年8月時点、自社調べ 100%プロコンテンツ サイバーエージェントとテレビ朝日 それぞれの強みを活かした制作体制で高品質なコンテンツを配信しています。 多彩なラインナップ 24時間編成のニュース専門チャンネルをはじめ、 オリジナルのドラマや恋愛番組、アニメ、スポーツなど、 多彩なジャンルの約25チャンネルを24時間365日放送しています。 5
6. AbemaTV, Inc. All Rights Reserved
 ABEMA 紹介 複数デバイス対応・多彩なチャンネルラインナップ 6
7. AbemaTV, Inc. All Rights Reserved
 2025 年 4 月 2,892 万 WAU 3,408 2,892
8. AbemaTV, Inc. All Rights Reserved
 ABEMA: High Level Cloud Architecture 8
9. AbemaTV, Inc. All Rights Reserved
 「本番」で試験するに至った背景 9
10. AbemaTV, Inc. All Rights Reserved
 人気番組やニュース速報による突発的なトラフィック急増が 度々発生する。 突発的なトラフィック 「本番」で試験するに至った背景： ABEMAの状況 10 ABEMA はイベント配信の時だけでなく、平常時においても 多くの同時接続が可能であることが要件となってる。 事業要件
11. AbemaTV, Inc. All Rights Reserved
 「本番」で試験するに至った背景： ABEMAの状況 11 • サービスの成長に伴い、システムの複雑性も増加 • 試験を行うために本番と同等の環境を構築し、またそれを運用していくのは時間的・金銭的コストが指数的に増加する ため非現実的 • 気軽に試験できる状況ではない サービスの成長に伴い、システムは複雑に
12. AbemaTV, Inc. All Rights Reserved
 我々の決断 「本番」で試験するに至った背景 12 • 課題 ◦ 事業要件や突発的なトラフィックに対応できる必要がある ◦ システムの複雑性やコストから気軽に試験できる状況ではない ◦ 負荷試験環境は仮想環境であって、本番特有の問題を再現できないことも • 結論 ◦ 本番に近づけた検証環境を使うのではなく、本番環境そのものを使う
13. AbemaTV, Inc. All Rights Reserved
 設計 13 「安全」を担保しながら実現するために
14. AbemaTV, Inc. All Rights Reserved
 設計の基本方針は「ユーザーの体験を損なわない」こと 設計 14 • 試験の影響範囲を限定的にする • 危険を察知したら即座に手動/自動で停止できる機構を持つ
15. AbemaTV, Inc. All Rights Reserved
 設計 15 全体アーキテクチャ図
16. AbemaTV, Inc. All Rights Reserved
 設計 16 • 本番環境の同じクラスター内に構築された、もう一つのアプリケーション群 • PodとNodeを完全に分離し、 ABEMA利用者のリクエストを捌く Podのリソースを食い潰さない • データソースは共有している ◦ ABEMAは様々な種類の DBを利用していることから DBまで複製するのは厳しい コア技術 : マルチテナント化
17. AbemaTV, Inc. All Rights Reserved
 設計 17 • Uber, Mercariさんの取り組みをヒントにさせていただきました コア技術 : マルチテナント化 https://www.uber.com/en-JP/blog/multitenancy-microserv ice-architecture/ https://engineering.mercari.com/blog/entry/20220218-dy namic-service-routing-using-istio/
18. AbemaTV, Inc. All Rights Reserved
 設計 18 • Kubernetesの自作カスタムコントローラーによる Tenant構築 • 開発者はカスタムリソースを定義するだけで、迅速に Tenantを構築可能 • レプリカ数, CPU, Memoryなどの変更をしたい場合に、カスタムリソース 経由で変更が可能 Operatorによる宣言的なテナント構築
19. AbemaTV, Inc. All Rights Reserved
 設計 19 1. オリジナルのリソースを取得し、 nameなどのフィールドを書き換えて作成 a. カスタムリースでは CPU, Memoryなどを個別に定義できるので、それらも含めて全て書き換え 2. Tenantアプリケーションへトラフィックが流れるように、 VirtualServiceにヘッダーベースルーティングを追加 Operatorの内部動作 : 自動的なマニフェスト書き換えとデプロイ
20. AbemaTV, Inc. All Rights Reserved
 設計 20 • Tenantアプリケーションを構築しただけでは、トラフィックの制御はできない • VirtualServiceのヘッダーベースルーティングを動的に追加することで Tenantアプリケーション間の通信を実現 ◦ 大元のVirtualServiceを更新したくなかったので、 Delegate機能を利用 Istioによるトラフィック制御
21. AbemaTV, Inc. All Rights Reserved
 設計 21 • 試験対象のAPI一覧をもとに、必要な Tenantアプリケーションを構築するための Custom Resourceを自動生成でき るようにした カスタムリソースの作成を簡単にするアプローチ
22. AbemaTV, Inc. All Rights Reserved
 設計 22 • 負荷シナリオ ◦ メトリクスの時系列データから k6シナリオを自動生成 • 負荷試験に利用するリクエストパラメータ ◦ 課題 ▪ システムの変化に追従していくのが難しい ▪ 番組など時間的な制約があり、一度作った試験用のリクエ ストパラメータを使い回せない ◦ 直近のアクセスログからリクエストパラメータを自動生成 負荷トラフィックの自動生成
23. AbemaTV, Inc. All Rights Reserved
 設計 23 • モニタリングは既存のモニタリングツールをそのまま利用 • DBは共有リソースとなっているため、より注意が必要 ◦ 利用している DBの中でアラートが未設定のものを調査し、アラートの追加を行った • Tenantと(試験)Versionで対象の試験のメトリクスのみを表示できるように対応 ◦ 例: Tenant = loadtest, Version = Latest で最新の試験のメトリクスのみを表示 モニタリングとアラート
24. AbemaTV, Inc. All Rights Reserved
 設計 24 • k6のThresholds機能を利用して、性能を下回ったタイミングで負荷試験を停止 ◦ 本来のSLOと同じ値でthresholdsを設定すると、負荷があまりかかっていない段階で停止することもあった ため、少し緩めた閾値で設定 自動緊急停止トリガー
25. AbemaTV, Inc. All Rights Reserved
 その他 設計 25 • DBリソースを共有していることから、主にGET APIを負荷試験の対象としている ◦ ABEMAのサービス特性上、Readが多いためことから、GET APIの試験だけでも高い効果が得られる • POST系のAPIについては、データ汚染を防止するために特定のダミーフラグを付与し、試験後にデータをク リーンアップできる仕組みを導入 ◦ 優先度が高いPOST系APIのみ試験対象としている • アクセスログ・アクションログなど調査や分析等に利用されるデータへの書き込みはノイズになることから省く ような対応を入れた • 負荷試験によってWAFが誤作動しないように、OperatorでTenantのBackendConfigの設定を修正
26. AbemaTV, Inc. All Rights Reserved
 設計 26 全体アーキテクチャ図（再掲）
27. AbemaTV, Inc. All Rights Reserved
 導入計画 27 どのように「段階的」に進めたか
28. AbemaTV, Inc. All Rights Reserved
 導入計画 28 • 導入フェーズ ◦ Dev環境で手動による Tenantの構築、負荷試験を実施し実現可能性を検証 ▪ トラフィックが意図した挙動をするか ▪ 意図しない書き込みなどの副作用がないか ◦ Prd環境で手動による Tenantの構築、高トラフィックの負荷試験を実施 ▪ Istioによるルーティングがボトルネックとならないか懸念があり、大きく動き出す前に検証を行った ◦ 仕組みをスケールさせるための基盤構築 ▪ Custom Operator ▪ 負荷トラフィックの自動生成ツール ◦ 最初は単一エンドポイントで試験を実施し、徐々に対象範囲を広げる • 運用フェーズ ◦ 継続的な実施 段階的な導入
29. AbemaTV, Inc. All Rights Reserved
 組織の合意形成 29
30. AbemaTV, Inc. All Rights Reserved
 組織の合意形成 30 • 前提として、定期的に最大同時接続数の負荷に耐えられるか チェックしたいという、 経営側の課題感もあった • 現状の共有 ◦ 複雑性の増加により、通常の手法での解決は難しい ◦ 既存の方法ではコスト（リソース・お金）がかかる • 意思決定のための判断材料を渡し合意を得た ◦ コスト削減メリット ◦ 大規模かつ日本国内であれば事例もないので技術的価 値も大きい 本番で試験することへの説得と理解獲得
31. AbemaTV, Inc. All Rights Reserved
 組織の合意形成 31 • プロダクト開発チーム ◦ 試験対象コンポーネントの特性や懸念点のヒアリング • Developer Productivityチーム ◦ 可観測ツールのコストについての懸念ヒアリング • Cloud Platformチーム ◦ インフラ設計、コストについての共有と合意 ◦ 負荷試験によるトラフィック増加に関して Google への共有 • データマネジメントチーム ◦ データ汚染に関するリスク箇所の整理と対策 チーム間のコラボレーション
32. AbemaTV, Inc. All Rights Reserved
 組織の合意形成 32 • 負荷試験を実施して良いボーダーラインを決定 ◦ 同時接続数など • 負荷試験の実施前に開発者に対して必ず周知 ◦ 万が一障害が発生した場合に、迅速に連携を取れるように その他
33. AbemaTV, Inc. All Rights Reserved
 得られた成果 33
34. AbemaTV, Inc. All Rights Reserved
 • 事業要件として掲げられている最大同時接続数まで スケールできるかのテスト • 最大同時接続数まで徐々に負荷を増やしながら試 験実施 スケールテスト 実践した2種類の負荷試験 34 • 人気番組やニュース速報による突発的なトラフィック を想定したテスト • 仮装待機室によってジョインレートを定めており、そ の最大の閾値で試験実施 スパイクテスト
35. AbemaTV, Inc. All Rights Reserved
 Contextual Bandit を用いたレコメンドシステムのリリース前負荷試験 35 • 新しいアルゴリズム (Contextual Bandit)を用いたレコメンドシステムのリリース前負荷試験に利用 • レコメンドシステムはデータ次第で負荷が変わる可能性があったため、本番環境で実際のデータを利用して負荷試 験を実施した • 実際のデータかつ本番で負荷試験を行った事によるエンジニアの安心感 性能試験 https://developers.cyberagent.co.jp/blog/archives/57070/
36. AbemaTV, Inc. All Rights Reserved
 • 人的・金銭的に多額のコストがかかる • 環境の二重管理が不要 に • 毎年の負荷試験環境への予算を 85%削減 • 大規模イベント時のコストを考慮すると 99%削減見込み 試験環境の運用にかかるコスト コスト削減 36 • 負荷試験環境としてシステム全体の構築に数ヶ月か かっていた • 環境構築にかかる時間を 99%削減（数十分に短縮） 環境構築にかかる時間的コスト
37. AbemaTV, Inc. All Rights Reserved
 今後の展望 37
38. AbemaTV, Inc. All Rights Reserved
 継続的な負荷試験 今後の展望 38 • ABEMAの最大キャパシティを把握するための大規模な負荷試験を定常的に 行う運用体制の構築 • リリースプロセスへの統合 ◦ リリースが性能に与える影響をリリース前に評価
39. AbemaTV, Inc. All Rights Reserved
 今後の展望 39 • これまでも Chaos Mesh を用いたカオスエンジニアリングは度々行ってきた ◦ 開発環境のみでしか実施できない ◦ 開発中のエンジニアや QAの手を止める必要があった • Tenantアプリケーションを利用し、 ABEMA利用者や開発者に影響を与えずに、開発環境・本番環境でカオスエンジニアリン グが可能だと考えている ◦ 定常的に実施される自動カオスエンジニアリングも視野 カオスエンジニアリングへの応用
40. AbemaTV, Inc. All Rights Reserved
 今後の展望 40 • マイクロサービスアーキテクチャを採用しているが、複雑さからローカルでサーバー起動による動作確認は難しい • アプリケーションやサービス間の連携に起因する問題は、 mainブランチへのマージと開発環境へのデプロイを経なければ 確認できない • Tenantアプリケーションを利用した DarkCanaryリリースを導入 ◦ PRからTenantアプリケーションを立ち上げられるフローを検討中 DarkCanaryリリースへの応用
41. AbemaTV, Inc. All Rights Reserved
 今後の展望 41 • Ingress ではヘッダーベースルーティングができないため、テナント用に Ingress を別途作成している • Gateway API を利用することで、ヘッダーベースルーティングやミラーリングが可能に GatewayAPIを利用したマルチテナント基盤のブラッシュアップ
42. AbemaTV, Inc. All Rights Reserved
 まとめ 42
43. AbemaTV, Inc. All Rights Reserved
 まとめ 43 • 事業要件と突発的なトラフィックへの対応、システム複雑化、既存手法のコストが課 題 • 「本番」環境での負荷試験を安全に実施するため、マルチテナント化を提案 • 段階的な導入と組織間の合意形成を経て、負荷試験・コスト削減での成果 • 今後は継続的な負荷試験、カオスエンジニアリング、DarkCanaryへの応用を目指 す
44. AbemaTV, Inc. All Rights Reserved