本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は導入事例ページもご覧ください。

全４回の内容は以下からアクセスできますので、ご興味のある回をご覧いただければ幸いです。

第一回　適切なデータストアの選定とアーキテクチャの見直し

第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜

第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜

第四回　AWSでのライブ配信アーキテクチャ

第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜

1.はじめに

第三回では、Lemino のサービスリリース時にどんな検証をし、リリース後のデプロイサイクルでどのような確認をしているか、ご紹介します。

2.サービスリリース前のテスト

Lemino のリリース前には、機能面のテスト・負荷テスト・異常時を想定した検証など様々な検証を行なっています。

開発に加えて、複数の観点の検証を並行して効率的に実施するために、開発・負荷試験・ステージング・商用環境を更に分割した8面で構成し、それぞれの環境を各開発チーム・試験チームに割り当てています。複数環境を運用するため、IaCツール(Terraform)で各環境のリソースを管理し、各環境で不用意な差分が発生しないように管理しつつ、プロビジョニングの作業を効率化しています。

機能面のテストは日々の開発の中でも実施するのですが、サービスリリース前のテストとして、ライブイベント時のピーク負荷を実際にかける検証をしています。Leminoでは同時視聴ユーザが数百万規模のライブに耐えうる基盤を作ることを想定しましたので、その負荷テストの中でどの部分を実際の負荷をかけて検証するかが課題になりました。

視聴開始に関連するアクセスなどピーク負荷が課題になる部分は、本番相当の負荷をかけて検証しました。

検証の際には以下に注意する必要があります。

全体として 1 分を越えて継続する、1Gbps (10 億ビット/秒) または 1Gpps (10 億パケット/秒) を超える検証についてはネットワーク負荷テストの申請が必要になります。（参考：Amazon EC2 Testing Policy）ほとんどの場合、このネットワーク負荷に到達する試験が必要になるケースはありませんが、今回のような大規模トラフィックの場合、この申請が通る前に負荷試験を行うことはできないため、大規模な負荷試験の場合、十分なリードタイムをもって、負荷試験を行う計画をたてることが必要です。
負荷を発生させるためのアカウントで、想定負荷を出すためのリソース準備が必要になります。

※Amazon EC2 Testing Policy を基準に、十分小規模な負荷テストであれば同一アカウントから、大規模な負荷試験の場合、負荷を発生させるためのアカウントを別途用意し、試験を実施

Lemino では、システムごとに異なる負荷試験のツールを使いましたが、たとえば、Grafana k6 はコンテナ実行可能なJavaScript ベースの負荷試験ツールでコードベースなのでGit での試験コード管理も可能です。EC2 からの軽微な負荷試験や 5000rps 程度の負荷試験であれば Docker がインストールされている環境から負荷試験が実施可能ですが、Kubernetes cluster からの大規模負荷及び 100万 rps 近い負荷試験を実施する場合は k6-operator を Kubernetes にデプロイすることで cluster が実行可能となります。eksctlでEKSを作成すれば30分程度で構築可能です。

負荷試験の前に、ピーク負荷を発生させるために必要なリソースと、ピーク負荷をかけた際にそれを処理するために必要となるリソースが問題なく起動できるか確認し、必要に応じて上限緩和申請を行う必要性があります。非常に大きなトラフィックを発生させようとした場合、通常は問題にならないことが課題になるケースがあります。例えば、ALB や Fargate がスケールするために必要とするIPアドレスが、既存の Subnet のIPレンジからでは払い出せない、などといったことがありえます。思いもよらない制限のために、本番当日にリソースが用意できない自体に陥らないよう、利用するサービスについてはすべての上限に当たる可能性を確認し、あらかじめ検証で本番ピーク相当にスケールアウトさせた上で、実際のピーク負荷をかけています。また、上限緩和申請についても十分なリードタイムを持って実施することが必要ですので、ネットワーク負荷テストの申請が必要になる程の一定以上大規模な試験を計画する場合には、あらかじめ入念な計画が必要です。
本番相当の負荷をかける試験に意味がある部分、ない部分を判断することも重要です。通常のトラフィック処理では、CDN を使っていれば、多数のクライアントに対して、地理的に分散されたエッジロケーションでリクエストを処理するため、処理は適切に分散します。

• 通常のトラフィック処理

例えば、CDN を経由して Live 配信の動画を視聴する検証を特定の AWS アカウントに擬似的に作った環境で再現しようとした場合、仮に下りの通信が1ユーザーあたり 1Mbps だったとしても、1000万同時視聴を想定すると 10Tbps になります。このトラフィックを受ける検証環境を用意することは技術的にもコスト面でも非常に難しく、また、全国のユーザーがアクセスする場合と1つのAWSアカウントのリージョンからアクセスするのでは接続する CDN の Edge ロケーションのトラフィックパターンも変わってしまいます。

• アンチパターン：特定のクライアントからの負荷試験

特定のクライアントからの大量のリクエストは、一部のリソースだけにリクエストが集中するため、実際のトラフィックパターンとは異なった試験になり、キャッシュヒットやパフォーマンスの観点で検証にならない場合が多くあります。概ねどの程度CDN でキャッシュヒットするかなどの確認は、小規模なライブを開催し、過去の配信実績をベースにして試算します。大規模トラフィックについては机上でどの程度キャッシュヒットするか検討した上で、バックエンドにかかる負荷を試算し、その試算をベースに負荷を想定することも選択肢の一つです。

参考：CloudFront の負荷テスト

3.リリース後も継続するデプロイの中でのテスト

リリース前の検証も大切ですが、機能面の検証は本番運用開始後も継続的に、楽にできるようにしておかなければ、開発のアジリティを向上することはできません。
Lemino でのデプロイ可能ブランチは一つのみ運用し、タグのPUSHを契機として単体テストから各環境へのデプロイ及び、エンドツーエンドテストまでGitlab-CI で自動化しています。またステージング環境から商用への展開、Blue-Green切替え、切戻しのタイミングだけ手動で指定できるように制御することで、品質とアジリティの両立を実現しています。CIで利用したエンドツーエンドテストのスクリプトは、外形監視でも流用するなどの効率化も行っています。

4.まとめ

AWS では本番相当のテスト環境を一時的に作成し、テスト完了後に環境を破棄できるため、容易に本番環境をシミュレートできます。一方、その本番相当の検証が意味がないものにならないよう、十分計画する必要があります。リリース後も継続するCI/CD の中でのテストは自動化することで、開発のアジリティを向上しつつ品質を担保できます。

こうした Lemino での知見が皆様の今後の開発の役に立てば幸いです。

次回は最終回、

第四回　AWSでのライブ配信アーキテクチャ

をお届けします。

著者について

株式会社NTTドコモ

第一プロダクトデザイン部 映像サービス担当　松原拓也

株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。

アマゾン ウェブ サービス ジャパン合同会社

技術統括本部 ストラテジックインダストリー技術本部　津和﨑美希

通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げるなど、幅広いAWS活用をご支援しています。