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

by Miyazaki Taiga

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

AbemaTV, Inc. All Rights Reserved  ABEMAについて登録不要で、いつでも無料で楽しめる 24時間365日編成されているリニア配信と見逃した作品を好きなタイミングでオンデマンドでも楽しむこともできます。国内最大級のオリジナルエピソード数オリジナルエピソード数は国内発の動画サービスで日本No.1(※)を誇り、注目の新作映画、国内外の人気ドラマ、話題のアニメなど豊富なラインナップの作品や、様々な音楽や舞台のオンラインライブも展開。 ※2024年8月時点、自社調べ 100%プロコンテンツサイバーエージェントとテレビ朝日それぞれの強みを活かした制作体制で高品質なコンテンツを配信しています。多彩なラインナップ 24時間編成のニュース専門チャンネルをはじめ、オリジナルのドラマや恋愛番組、アニメ、スポーツなど、多彩なジャンルの約25チャンネルを24時間365日放送しています。 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

AbemaTV, Inc. All Rights Reserved  設計 16 ● 本番環境の同じクラスター内に構築された、もう一つのアプリケーション群 ● PodとNodeを完全に分離し、 ABEMA利用者のリクエストを捌く Podのリソースを食い潰さない ● データソースは共有している ○ ABEMAは様々な種類の DBを利用していることから DBまで複製するのは厳しいコア技術 : マルチテナント化

Slide 17

Slide 17 text

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/

Slide 18

Slide 18 text

Slide 19

Slide 19 text

AbemaTV, Inc. All Rights Reserved  設計 19 1. オリジナルのリソースを取得し、 nameなどのフィールドを書き換えて作成 a. カスタムリースでは CPU, Memoryなどを個別に定義できるので、それらも含めて全て書き換え 2. Tenantアプリケーションへトラフィックが流れるように、 VirtualServiceにヘッダーベースルーティングを追加 Operatorの内部動作 : 自動的なマニフェスト書き換えとデプロイ

Slide 20

Slide 20 text

AbemaTV, Inc. All Rights Reserved  設計 20 ● Tenantアプリケーションを構築しただけでは、トラフィックの制御はできない ● VirtualServiceのヘッダーベースルーティングを動的に追加することで Tenantアプリケーション間の通信を実現 ○ 大元のVirtualServiceを更新したくなかったので、 Delegate機能を利用 Istioによるトラフィック制御

Slide 21

Slide 21 text

Slide 22

Slide 22 text

AbemaTV, Inc. All Rights Reserved  設計 22 ● 負荷シナリオ ○ メトリクスの時系列データから k6シナリオを自動生成 ● 負荷試験に利用するリクエストパラメータ ○ 課題 ■ システムの変化に追従していくのが難しい ■ 番組など時間的な制約があり、一度作った試験用のリクエストパラメータを使い回せない ○ 直近のアクセスログからリクエストパラメータを自動生成負荷トラフィックの自動生成

Slide 23

Slide 23 text

AbemaTV, Inc. All Rights Reserved  設計 23 ● モニタリングは既存のモニタリングツールをそのまま利用 ● DBは共有リソースとなっているため、より注意が必要 ○ 利用している DBの中でアラートが未設定のものを調査し、アラートの追加を行った ● Tenantと(試験)Versionで対象の試験のメトリクスのみを表示できるように対応 ○ 例: Tenant = loadtest, Version = Latest で最新の試験のメトリクスのみを表示モニタリングとアラート

Slide 24

Slide 24 text

Slide 25

Slide 25 text

AbemaTV, Inc. All Rights Reserved  その他設計 25 ● DBリソースを共有していることから、主にGET APIを負荷試験の対象としている ○ ABEMAのサービス特性上、Readが多いためことから、GET APIの試験だけでも高い効果が得られる ● POST系のAPIについては、データ汚染を防止するために特定のダミーフラグを付与し、試験後にデータをクリーンアップできる仕組みを導入 ○ 優先度が高いPOST系APIのみ試験対象としている ● アクセスログ・アクションログなど調査や分析等に利用されるデータへの書き込みはノイズになることから省くような対応を入れた ● 負荷試験によってWAFが誤作動しないように、OperatorでTenantのBackendConfigの設定を修正

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

AbemaTV, Inc. All Rights Reserved  導入計画 28 ● 導入フェーズ ○ Dev環境で手動による Tenantの構築、負荷試験を実施し実現可能性を検証 ■ トラフィックが意図した挙動をするか ■ 意図しない書き込みなどの副作用がないか ○ Prd環境で手動による Tenantの構築、高トラフィックの負荷試験を実施 ■ Istioによるルーティングがボトルネックとならないか懸念があり、大きく動き出す前に検証を行った ○ 仕組みをスケールさせるための基盤構築 ■ Custom Operator ■ 負荷トラフィックの自動生成ツール ○ 最初は単一エンドポイントで試験を実施し、徐々に対象範囲を広げる ● 運用フェーズ ○ 継続的な実施段階的な導入

Slide 29

Slide 29 text

Slide 30

Slide 30 text

AbemaTV, Inc. All Rights Reserved  組織の合意形成 30 ● 前提として、定期的に最大同時接続数の負荷に耐えられるかチェックしたいという、経営側の課題感もあった ● 現状の共有 ○ 複雑性の増加により、通常の手法での解決は難しい ○ 既存の方法ではコスト（リソース・お金）がかかる ● 意思決定のための判断材料を渡し合意を得た ○ コスト削減メリット ○ 大規模かつ日本国内であれば事例もないので技術的価値も大きい本番で試験することへの説得と理解獲得

Slide 31

Slide 31 text

AbemaTV, Inc. All Rights Reserved  組織の合意形成 31 ● プロダクト開発チーム ○ 試験対象コンポーネントの特性や懸念点のヒアリング ● Developer Productivityチーム ○ 可観測ツールのコストについての懸念ヒアリング ● Cloud Platformチーム ○ インフラ設計、コストについての共有と合意 ○ 負荷試験によるトラフィック増加に関して Google への共有 ● データマネジメントチーム ○ データ汚染に関するリスク箇所の整理と対策チーム間のコラボレーション

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

AbemaTV, Inc. All Rights Reserved  ● 事業要件として掲げられている最大同時接続数までスケールできるかのテスト ● 最大同時接続数まで徐々に負荷を増やしながら試験実施スケールテスト実践した2種類の負荷試験 34 ● 人気番組やニュース速報による突発的なトラフィックを想定したテスト ● 仮装待機室によってジョインレートを定めており、その最大の閾値で試験実施スパイクテスト

Slide 35

Slide 35 text

AbemaTV, Inc. All Rights Reserved  Contextual Bandit を用いたレコメンドシステムのリリース前負荷試験 35 ● 新しいアルゴリズム (Contextual Bandit)を用いたレコメンドシステムのリリース前負荷試験に利用 ● レコメンドシステムはデータ次第で負荷が変わる可能性があったため、本番環境で実際のデータを利用して負荷試験を実施した ● 実際のデータかつ本番で負荷試験を行った事によるエンジニアの安心感性能試験 https://developers.cyberagent.co.jp/blog/archives/57070/

Slide 36

Slide 36 text

AbemaTV, Inc. All Rights Reserved  ● 人的・金銭的に多額のコストがかかる ● 環境の二重管理が不要に ● 毎年の負荷試験環境への予算を 85%削減 ● 大規模イベント時のコストを考慮すると 99%削減見込み試験環境の運用にかかるコストコスト削減 36 ● 負荷試験環境としてシステム全体の構築に数ヶ月かかっていた ● 環境構築にかかる時間を 99%削減（数十分に短縮）環境構築にかかる時間的コスト

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

AbemaTV, Inc. All Rights Reserved  今後の展望 39 ● これまでも Chaos Mesh を用いたカオスエンジニアリングは度々行ってきた ○ 開発環境のみでしか実施できない ○ 開発中のエンジニアや QAの手を止める必要があった ● Tenantアプリケーションを利用し、 ABEMA利用者や開発者に影響を与えずに、開発環境・本番環境でカオスエンジニアリングが可能だと考えている ○ 定常的に実施される自動カオスエンジニアリングも視野カオスエンジニアリングへの応用

Slide 40

Slide 40 text

AbemaTV, Inc. All Rights Reserved  今後の展望 40 ● マイクロサービスアーキテクチャを採用しているが、複雑さからローカルでサーバー起動による動作確認は難しい ● アプリケーションやサービス間の連携に起因する問題は、 mainブランチへのマージと開発環境へのデプロイを経なければ確認できない ● Tenantアプリケーションを利用した DarkCanaryリリースを導入 ○ PRからTenantアプリケーションを立ち上げられるフローを検討中 DarkCanaryリリースへの応用

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

AbemaTV, Inc. All Rights Reserved  まとめ 43 ● 事業要件と突発的なトラフィックへの対応、システム複雑化、既存手法のコストが課題 ● 「本番」環境での負荷試験を安全に実施するため、マルチテナント化を提案 ● 段階的な導入と組織間の合意形成を経て、負荷試験・コスト削減での成果 ● 今後は継続的な負荷試験、カオスエンジニアリング、DarkCanaryへの応用を目指す

Slide 44

Slide 44 text