架空シナリオで考えるアーキテクチャ 有料動画サイト編

こんにちは、中山（ @k1nakayama ) です。

弊社でAWSパートナーとしての事業である「クラウドパートナー事業」を行っている部門では、毎月の定例スキルアップイベントとして、Tech Challenge Dayというイベントを行っています。Tech Challenge Dayでは、普段テレワークで直接顔を合わせることも少ないため、周りのメンバーがどんな分野に長けているのか、どんなチームワークを行うと効率よく進められそうか、などのチームビルディングを行っていくことも目的の1つとしていますが、毎回様々な分野のスキルをつけていくために、1つのアプリケーションをみんなで1日掛けて構築したり、アーキテクチャについて討論を行ったりする時間を設けています。今月行ったTech Challenge Dayでは、架空のシナリオを用意して、その要件に合わせたアーキテクチャを出来るだけ具体的に検討していき、AWSを使った課題解決力を高めていくための教育を兼ねて行いました。

今回はその中で予め私が用意したシナリオについて、弊社のメンバーにもいくつかの気付きや、新しいサービスなどを含む知見を共有することが出来たので、その内容を公開したいと思います。

架空シナリオ

今回検討するシナリオは下記のような要件となります。

上記の点を網羅するためのアーキテクチャを考えていきます。ただし、今回は上記に挙げた要件を満たすためにどの様に解決していくかの検討が目的のため、具体的な要件が出ていない部分は触れません。

アーキテクチャの具体的な検討

早速アーキテクチャの検討を進めていきたいと思いますが、皆さんはどこから検討を始めていきますか？

今回ワークロードを構成する基本的なリソースなどに関連する要件もありません。このような場合、私はまず、要求される要件の中で最も制限が大きい（仮想サーバー上にインストールをすることを前提としているパッケージアプリケーションを使うことなど）要件を検討します。そうすることで、EC2をベースとして構築する必要があるのか、Dockerコンテナなどを使うべきかなど、アーキテクチャの中で確定するものを見つけることができます。

しかし、今回は特段ワークロードを構成する要素について、制限をもつものは見当たりません。今回の要件の中で最も制限が厳しいものは、恐らく要件8のRTO/RPOを満たすことかと思います。この要件を満たすためには、IaCで構成管理することは必須要件となりそうですが、それ以外は特に縛られることはなさそうです。

私はこのような状況の場合は、出来る限りサーバーレスアーキテクチャで構成するようにし、運用負荷を下げられるように考えています。

ここからは、各要件に対してどのようなアーキテクチャで構成すると解決できるかを検討していきます。

要件１: ブラウザベースで利用でき、PC、スマホ、タブレットで利用可能

前述の通りサーバーレスアーキテクチャで構成する事にするうえ、SPAやSSRなどの要件も特に設けられていないため、フロントエンドはReact.jsで作るSPAとしたいと思います。React.jsをデリバリーする手段はいくつかありますが、今回は最も運用コストを抑えやすいS3でReact.jsをホストし、CloudFrontからデリバリーする一般的な構成を取りたいと思います。あとは、React.jsでPC、スマホ、タブレットそれぞれで閲覧可能なレスポンシブデザインのサイトを構築することで、本要件は対応出来ます。

要件2: 管理画面からMPEG4形式の動画をアップロードすることで動画を追加することができる

この要件の肝は、動画ファイルのような大容量のファイルを、安全にクラウド上にアップロードする方法を考えることです。フロントエンドをSPAで実装する事になったため、画面上の様々な情報を取得・更新するために、なんらかのAPIを使って行うようになります。しかし、API GatewayやAppSyncといったWebアプリケーションで使われるAPIサービスでは、リクエスト出来るデータサイズの制限があり最大でも10MB程度となります。今回の要件では動画ファイルの容量の想定などは示されていないものの、動画ファイルが一般的に10MBを超えることは十分に想定できます。

このような時には、動画ファイルをフロントエンドから直接S3バケットにアップロードしてしまうという考え方が有効的です。ただし、誰でもS3バケットの情報を知っていればアップロードが行える状態だと問題があります。

このようなシーンで検討できる手段は、主に2つあります。

1つ目は、事前署名URL（Presigned URL)を使ったS3へのアップロードです。これは、S3バケット上の特定のオブジェクトに対する読み取りまたは書き込みの権限を付けた署名を発行し、その署名をURLに付けてリクエストすることで、一時的な認可が提供されオブジェクトに対する読み取りまたは書き込みを行うことが出来ます。

もう一つの方法は、Amazon Cognitoを使って認証済みユーザーに対するIAM Roleを割り当て、IAM Roleの権限を使用してS3バケットに対する読み取りまたは書き込みを行う方法です。

今回は、管理者画面から動画に関する情報を登録することも想定されるため、動画情報の登録時に事前署名URLを発行しAPIからのレスポンスに含め、フロントエンドから発行された事前署名URLを使ってアップロードする方法を採用することにします。

要件3: 画質選択を数パターン選択出来る（自動的に帯域に合わせて変更も可能）

この要件を検討する前に、関連する課題として、動画をどの様に配信するか検討する必要があります。管理者画面で登録される動画ファイルはMPEG4形式ですが、MPEG4形式のままブラウザで再生させるには、ユーザー側に動画ファイルをダウンロード出来る状態にする必要があります。この場合、MPEG4形式の動画ファイルをダウンロードされ、再配布されてしまう可能性もあり、有料動画サイトのビジネスとして成り立たなくなります。そこで、動画の配信はストリーミング配信をすることとします。

動画をストリーミング配信し、ブラウザ上で視聴する事ができる方法もいくつかの方法が考えられます。ただし今回の要件として、画質選択が行えるうえ、帯域幅に合わせて自動的に変更できる機能を使える必要があります。これらの機能を備えて配信できるプロトコルとして一般的なものに、HLS（HTTP Live Streaming）があります。HLSは、動画を10秒毎ののセグメントファイルに分割して配信を行う形をとっており、配信時の帯域に合わせてビットレート（1秒間あたりのデータ量）を自動調整することが可能です。これにより複数のビットレートでの出力を用意しておくことで、画質選択も可能となります。

では、管理者画面からアップロードされたMPEG4形式の動画を、HLS形式に変換するためにはどうしたら良いでしょうか？

ここで登場するのがAmazon Elemental Media Convertです。このMedia Convertを使うと、様々な動画や音声を形式変換してくれたり、動画から一定間隔でサムネイル画像をキャプチャし出力してくれたり、横向きになってしまっている動画を90度回転させたりと、様々な変換を行ってくれるサービスです。

もちろん、MPEG4から複数のビットレートでHLS形式の出力を行うことも可能です。変換されたファイル群（セグメントファイルが大量にできる）は、指定したS3バケットに格納されます。インデックスファイルとなるm3u8ファイルをCloudFront経由で配信し、ブラウザ上ではvideo.js等を使用して再生できるようにすることで、この要件は満たせそうです。

要件4: 動画のタイトル、説明、出演者などの情報に対するフリーワード検索で動画を検索可能

今回のような複数のコンテンツを提供するサイトでは、コンテンツの検索機能は必須と言える機能です。また、普段から様々なサイトで検索機能を使われている方はイメージが湧きやすいかもしれませんが、ある程度特定の動画を探したいと思った時に、頭に思い浮かんだキーワードが必ずしもタイトルや出演者名と完全一致していなかったり、説明文に書かれた表現と微妙に一致していなかったりということはありがちです。このようなケースを想定した検索では、自然言語処理を用いた検索が行えるものを使用するとUXが向上します。

AWS上で自然言語処理を用いた検索が行えるサービスとしては、Amazon OpenSearch Serviceがありますが、OpenSearchでのクエリはOpenSearch独自の固有言語（DSL）を使用したものになることや、原則としてノードの管理等を必要とするサーバーレスライクな使い方が出来ません。（OpenSearch Serverlessというものもありますが、このServerlessは自らの管理なしに処理性能をスケールアウトさせたりすることが出来る機能を持っているだけで、アイドル時でもコストは発生しますし、ノードの構成管理はやはり必要となります）

上記を踏まえ、私が提案するのは、Algoliaという全文検索SaaSです。Algoliaは、SaaSなのでもちろんノードの管理も不要で、データ量や検索数が少なければ無料から利用でき、各種言語向けにSDKも用意されているため、比較的簡単に導入することが出来ます。また、今回の要件のように検索対象に対するフリーワード検索や属性（カテゴリや出演者名など）でフィルタリングすることなどを備えたUIを、簡単なJavaScriptを設置するだけで提供できる機能も存在しております。Algoliaはなんと言っても、検索結果のレスポンスが爆速なので、その性能を活かすためにもフロントエンドから直接SDKを使うなどして検索を行い、結果を表示する仕組みを実装することがよいです。

ここまでで、バックエンド（APIバックエンド）で使用するデータベースを何を使うかが検討されていませんでしたが、今回の要件において特段リレーショナルな情報を多く扱うことはなさそうですので、サーバーレスアプリケーションとしても相性のよいDynamoDBを使うことにしたいと思います。DynamoDBであれば、レコードの更新時にDynamoDB Streamsにより更新データを送信することができます。この機能を利用して、動画のマスタデータを登録・更新された際に、Algoliaのインデックス情報を更新する処理を実装することで、常に動画情報をAlgoliaと同期することができ、新鮮なデータを対象に検索を行うことができます。

要件5: 各動画に対するイイネボタンを設置し、イイネが押されると、リアルタイムでカウントがあがって表示される

Youtubeなどでお馴染みのGoodボタンですが、この要件はどの様に実装するのがいいでしょうか？

最も簡単な方法として、動画情報の属性の1つとしてイイネ数を持たせ、動画情報などを表示する際にイイネボタンと一緒に数を表示する方法ですが、これだと誰かがイイネを押しても再度動画情報を読み込まない限り数が更新されません。定期的にページを更新すると、UXが悪いばかりでなく、動画再生中の場合動画再生が中断されサービスになりません。この流れで従来まで一般的？だった更新方法は、JavaScriptにより定期的にイイネ数を取得し、イイネ数を表すDOMだけを更新していく方法です。これでも見た目上は概ね問題ないのですが、”リアルタイム”という要件が満たせているとは言い難いことと、アクティブな閲覧中のユーザー数が増加すると、無駄にイイネ数の取得をするためのリクエストが来続け、APIコール数やLambda等のバックエンドリソースの実行数が増えるため、無駄なコストが増えていきます。

そこで採用したいのが、AWS AppSyncです。AppSyncはフルマネージドなGraphQL APIを提供するためのサービスです。ここではGraphQLの詳細を触れませんが、GraphQLのSubscription（購読）という機能を使用することで、変更があったときに通知を受けることができるPub/Subの機能が使用できます。イイネ数などの情報に更新が入ったら、閲覧中の動画情報（イイネ数を含む）を更新する様にすることで、リアルタイムに更新を行うことができ、無駄なAPIリクエストを行うことも回避出来ます。

要件6: 月額で見放題プランと単品視聴が行える

この要件はぱっと見簡単そうな要件に思えるかもしれませんが、実はこの要件だけでいくつかの検討しなければならないことが含まれます。

まずは、ユーザー毎のプランをどの様に管理していくかです。DB上にユーザー管理テーブルを設け、プランを表す属性を入れて管理する形でも良いのですが、これだとプランを参照する必要のあるAPI処理全てで毎回ユーザー情報の参照から行う必要があり非効率です。そこで、APIの認証情報にユーザー属性情報を含ませるようにします。これを実現するためには、Cognito User Poolを使用してユーザー管理を行い、属性情報にプランを持たせるか、プランごとのグループに属させる形にして管理することで実現できます。しかし、Cognito User Poolは一度User Poolを作成した後は、柔軟な設定更新などが行えないものもあり、将来の機能追加によりユーザー管理系に対する変更を加えたい時に、足かせとなるケースが見受けられます。

そこで私がおすすめしたいのはAuth0です。Auth0は多くのサービスで利用されているIDaaSで、幅広い認証プロバイダとの連携も簡単に行なえ、ユーザー属性の管理などは基本的にJSONデータで格納されているためとても柔軟に扱うことが出来ます。AppSyncとの連携で認証をする場合は、OIDC認証を使用しAuth0での認証時に発行されるアクセストークンを使用して認可を得る事ができます。AppSyncのバックエンドのLambda等では、アクセストークンに含まれるユーザー属性情報を使うことが出来るため、プランを含ませるようにしておくことで、プランごとの処理を実装しやすくなります。

続いては、単品購入プランのユーザーの場合、動画毎に再生ボタンを表示するべきか、購入ボタンを表示するべきかの判断をどの様に行うかです。購入済みコンテンツのIDなどをリストで取得して、表示されている動画がリストに含まれるか否かで判断する方法もありますが、なかなか効率が悪いことや、購入数が多いとパフォーマンスが悪そうです。

そこで、今回APIにはAppSyncを使用することにしているため、GraphQLスキーマの動画データのフィールドの1つとして、購入済みか否かを表すフィールドを設け、フィールドリゾルバとして購入済みか否かを判断してBool値を返すようなリゾルバを設定しておきます。これにより、動画情報をクエリするだけで、そのユーザーが対象の動画を購入済みか否かを判断して返すことが出来るので、フロントエンドではそのBool値に従って表示を出し分けすることが出来ます。

この要件で考える必要のある項目の最後に、動画へのアクセスをどの様に制限するかです。要件3で、HLS形式のストリーミングデータをCloudFrontから配信することで動画を視聴する仕組みを考えましたが、これだけだと、m3u8ファイルのURLを知っている人なら誰もが動画を視聴出来てしまいます。

要件2で使った事前署名URLをm3u8ファイルに対して発行する方法でS3から配信する方法も考えられますが、HLS形式の動画はm3u8ファイルだけにアクセスできれば良いわけではなく、10秒毎に切り分けられた複数のセグメントファイルも参照できる必要があります。しかもこれらのファイルのパスは、m3u8ファイル内で定義されているので、ユーザー毎に各セグメントファイルの事前署名URLを発行したものに書き換えて配信するのはあまりにも非効率的です。

今回ここで使うことが出来る機能が、CloudFrontの署名付きCookieです。先程のS3の事前署名URLと同様に、CloudFrontにも署名付きURLや署名付きCookieという制限付きアクセスを提供する機能があります。仕組みはS3の事前署名URLと基本的に同じなので、署名付きURLも今回は使えません。署名付きCookieは、特定のパス以下のファイルに対する制限付きアクセスを提供する機能で、署名情報をCookieに持たせることで制限を通過することが出来ます。

動画の再生をAPIにリクエストすると、ユーザーがその動画を視聴することができるかのチェックが行われ、チェックに通ると署名付きCookieを発行し、Cookie情報とともにm3u8ファイルのURLをレスポンスし、ブラウザ側でCookieをセットした上でm3u8ファイルのURLにビュアーからアクセスを行い動画を再生することが出来ます。この時、単品購入の動画については、購入から48時間後の時間でCookieの有効期限が切れるように署名付きCookieを発行します。

これらにより要件6を満たすことができそうです。

要件7: 単品視聴は購入から48時間限定で、残り時間が5時間を切ると注意喚起のメールが送信される

今回の要件に対する処理はあまり難しく考えずに、10分ごとなどの周期で購入から43時間経過した履歴を持つユーザーをリストアップし、メールを送信していく処理を実装する方が多いのではないでしょうか？

それでも十分要件を満たせているのですが、是非AWSをフル活用した新しい発想で実装することも検討していただきたいです。それは、EventBridge Schedulerという機能を使用した方法です。EventBridge Schedulerは、OneTimeの実行と定期的な実行の両方のスケジュールを管理することができ、管理できるスケジュール数も100万以上を管理できます。

これを利用すると、単品購入時に43時間後の時間で注意喚起メールを1通送信するためのLambdaに対してイベントを発火するようなスケジュールを作成します。これにより、各コンテンツの購入から43時間後に適切にLambdaが実行されます。こうすることにより、10分ごとに対象のコンテンツがなくメール送信する必要がなくても、毎回Lambdaがじっこうされるということがなくなり、必要な時に必要なだけLambdaが実行されるため、コストを最適化することができます。また、ユーザーがサービスを解約した際に、スケジュール済みの送信処理を削除することで、解約した後でリマインドメールが送られてくるという問題もなくなります。

EventBridge Schedulerについては、下記の記事で詳しく解説していますので併せてお読みください。

要件8: RTO 4時間、RPO 障害発生直前とする

いよいよ最後の要件です。

RTO（目標復旧時間）、RPO（目標復旧時点）についてはプロジェクトを進めていく上で、検討しておくべき基本要件の1つだと思います。しかし、私の感覚だと意外とこの要件をしっかり初期段階に検討しているプロジェクトは少ない印象です。仮にこれらの要件を定めずに成り行き任せで運用した場合、どうなるでしょうか？要件に必要のない構成を取らず、最小限の構成で構築していくことが基本とすると、DBのバックアップも取得していない、場合によっては環境構築もマネジメントコンソールから手動で設定を行っているかもしれません。

数年前に東京リージョンでの大規模なAZ障害が発生し、主にEC2系のサービスでは大きな影響を受けていました。その際、私が担当していたワークロードの一部で使われていたEC2も障害による影響で使用していたEBSがクラッシュし、再起不能となりました。幸いにもそのインスタンスは開発環境用のものでしたが、バックアップも取っていなかった上、PoC的な形で使用していたため、構築も手動で行っていたものだったため、そのインスタンスの復旧は諦めることにしました。

もし、今回の要件にRTO/RPOが入っておらず、同様にEC2上にアプリケーションを構築し提供開始した後、DB機能を持ったインスタンスがクラッシュし復旧困難な状況に陥った場合、このプロダクトは半ば強制的に終了せざるを得なくなり、場合によってはそれまでに課金をしていたユーザーさんからの集団訴訟を受ける事になり、最悪の場合、会社自体が存続不可能となります。

このような事態に陥らないよう、プロダクトの初期段階でRTO/RPOをしっかり検討し、適切な目標を設定することが重要です。ここで”適切な”と言ったのは、当然RTO/RPOは出来る限り短い時間で復旧でき、データの消失もゼロに近い状態を維持することが理想です。ですが、それを実現するには莫大なコストや実装しなくてももっと早くにリリースを行えたかもしれないビジネス機会など、様々なものを犠牲にします。かと言って、RTO1週間などといった時間を設定した場合、要件を満たせていたとしても実際の障害により復旧できる時間が大幅にかかりすぎた場合、やはりビジネスインパクトが大きいかもしれません。そのようなことを踏まえ、適切に要件を検討する必要があります。

さて、前置きが長くなりましたが、今回のRTO4時間、RPO障害発生直前という要件を満たすためにはどのような点を考慮する必要があるでしょうか？まず、要件が厳しいRPOから検討します。RPOは障害発生によって、データが消失することが許容できる時点がどのくらいかを設定したものです。RPOが仮に12時間となっている場合、少なくとも12時間毎できれば6時間毎のバックアップ取得を行っておくことで要件にあったデータを確保しておき復旧作業に使うことができます。が、今回は障害発生の直前まで残っている必要があります。このような要件の場合は、少なくともデータベースなどの常時更新がされているデータについて、ワークロードで使用されているものとは別のインスタンス等に、リアルタイムなレプリケーションを行って、いつ障害が発生して使用中のDBストレージがクラッシュしたとしてもデータが残っている状態を作る必要があります。

今回DBにはDynamoDBを採用することにしましたが、DynamoDBにはGlobal Tablesというマルチリージョンにリアルタイムな同期を行い、マルチマスターで運用する事ができる機能があります。これを採用することでRPOの要件は満たせそうです。

次に、RTO4時間の要件ですが、仮に今回のサービスを手動でマネジメントコンソールから設定を行いデプロイをしていった場合、果たして何時間で同じ環境を復元できるでしょうか？考えるまでもなく、4時間では到底不可能ですね。また、RTOを検討する上で考慮する必要があるのは、復旧作業に掛かる時間ではなく、障害発生時点から4時間なので、障害が発生したことを検知し復旧作業に取り掛かることを決めるまでに30分程度要するとした場合、残り3時間半以内に復旧できなければ要件を満たせません。

これを実現可能にする方法は1つで、IaC(Infrastructure as Code)でワークロード全体を構築できるようにすることです。IaCでワークロード全体を複製可能な状態にしてあれば、デプロイコマンド1発で新たな環境を構築できますので、復旧作業を最小の時間で進めることが可能です。AWSでIaCによりワークロードを構成管理するサービスとしては、CloudFormationがあります。CloudFormationテンプレートを作成しておき、別のリージョンなどで新たなスタックを作成することにより、環境全体を構築し直せます。

今回の要件では、CloudFormationテンプレートを作成しておくでも要件は満たせそうですが、開発効率なども考慮した場合に、プログラマブルに普段使用している言語で構成を定義し、最終的にCloudFormationテンプレートを生成し、CloudFormationスタックを自動的にデプロイしてくれるAWS CDK（Cloud Development Kit）を使用して構築することがオススメです。

ここまでで既にRTOも要件を満たせていそうですが、果たして本当にそうでしょうか？

皆さんは夜も眠らずにこのワークロードを維持し続けることができそうですか？やはり無理があります。深夜に障害が発生してしまった場合、障害発生を検知した通知を受けて、どうにか起きることができたとしても、デプロイするための準備を進めていたら、すぐに4時間は過ぎてしまいます。

この問題を対処するためには、常時サービスの正常性を監視するためのヘルスチェッカーを構築しておき、複数のリージョンから定期的にヘルスチェッカーを実行し、結果をCloudWatchメトリクスにプッシュしていき、一定時間内に異常を検知したら、自動的にDR（災害復旧）リージョンに対する復旧作業を開始するプロセスを自動化しておくことが必要です。そして、障害発生から4時間以内に復旧が確認できなければ、別のアラームが発動しDNSを切り替え、DRリージョンに構築したワークロードにトラフィックを流す様にします。これにより深夜の障害発生も対処できそうです。

また、上記の手順の場合、どうしても障害発生中に4時間以内のサービスダウンが発生する可能性がありますが、今回DBとしてDynamoDBのGlobal Tablesを採用しています。マルチマスターなので、仮に東京リージョンにデプロイしていて障害が発生したとしても、もう一つシンガポールリージョンにデプロイしておき、常にトラフィックを流し続けておくこともでき、そのような構成にした場合、大抵の場合はダウンタイムを伴うことなく障害を乗り越えることができ、さらなる信頼性を向上させられます。ただし、このようなマルチリージョンでActive-Activeの構成を取ることは、一般的にコストが2倍になる可能性があるため考慮が必要ですが、今回はワークロード全体をサーバーレスで構成したこともあり、全体的なトラフィックが変わらなければ、単純に2倍になることはなく、単一リージョンで構成するよりも若干のコスト増で提供できるため、メリットを享受しやすいといえます。

以上で全ての要件を対応するためのアーキテクチャ検討ができました。

全体アーキテクチャ

全ての要件を検討した後の全体アーキテクチャは下記の様になりました。

まとめ

今回は、架空シナリオとして有料動画配信サイトを構築する際に、様々な要件をどの様に解決したらよいかを検討してみました。

8個ぐらいの要件だけでも様々な点を考慮する必要があり、幅広いAWSサービスに触れる機会となりました。このような架空シナリオを用意して、アーキテクチャを検討することは、AWSサービスに対する知識の更新をしていく機会でもあるので、定期的に行っていきたいと思いました。

このテーマをシリーズ的に記事にしていけたらと思います。