Amazon DynamoDB オンデマンドキャパシティーモードを使用して、急増するワークロードを実行し、コストを 90% 以上最適化する

これは、TVer Technologies Inc. のソフトウェアエンジニアであるウツミケイスケ氏によるゲスト投稿です。同社の言葉を借りると、「 TVer Technologies Inc. は、テレビ放送と同期されたウェブサイトを利用して、ユーザーにインタラクティブなエンターテイメントサービスを提供しています 」との事です。

TVer Technologies Inc. は、日本のテレビ視聴者向けにウェブサイトとアプリベースのインタラクティブコンテンツを提供しています。当社のアプリケーションの多くは、Amazon DynamoDB をデータベースとして使用して、登録ユーザー情報を保存し、テレビ放送中のライブ投票イベントでユーザーの投票活動の履歴を記録します。当社のアプリケーションは、毎朝の番組や季節ごとのポップミュージック番組でよく用いられています。このブログ記事では、DynamoDB のオンデマンド読み取り/書き込みキャパシティーモードを使用して、TV ライブ投票イベントで使用されるシステムのコストとパフォーマンスを最適化する方法を確認します。

視聴者の投票期間はテレビ番組の放映時間に制限されているため、ほとんどのライブ投票プロジェクトでは、ユーザーアクセスは数時間しか見られません。この数時間で、アクセスリクエストが急増するのはほんの数分間です。ピーク時以外のワークロードは、ピーク時と比較してほとんどありません。両者を比べると、1:100 または 1:10,000 の割合です。

次のグラフは、視聴者をウェブサイトに投票させるテレビ番組中のウェブサービスへのアクセスリクエストの記録を示しています。投票がなかったときは、視聴者からの投票活動へのアクセスがないため、リクエストはありませんでした。具体的には、19:30 から 20:15 の間、ユーザーからの投票アクティビティがなかったため、リクエストはありませんでした。それから 20:15 に、視聴者が投票を開始し、システムがユーザーのデータを記録し始めたため、数分間スパイクが見られました。プログラムが 22:30 に終了するまで、投票時間中に短いスパイクが繰り返されるこのパターンが不規則に広がっています。Amazon CloudWatch Logs がレコードを収集したため、数値は 1 分あたりの平均値です。ピーク時に記録された実際の数は、非ピーク時の 2～3 倍でした。

Amazon DynamoDB オンデマンドを使用する理由

このケースでは、Amazon DynamoDB オンデマンドが最も有用であることがわかりました。DynamoDB の Auto Scaling を使用することもできましたが、TV プログラムでの計画外のプロモーションが原因でリクエストが突然または予期せず急増した場合、DynamoDB の Auto Scaling では十分に早く追いつけないでしょう。DynamoDB オンデマンドを使用すると、お金を節約し、手動による介入を減らすことができ、遅滞がありません。

一部のライブプログラムには、プログラム中、イベントの厳密なスケジュールがありません。したがって、トラフィックが急増する時間帯を事前に予測することは困難です。ピーク時のトラフィックに備えて DynamoDB のキャパシティーを事前にプロビジョニングした場合、実際にピークがいつ発生したかに関係なく、そのリソースに対して料金を支払う必要があります。DynamoDB オンデマンドが利用できるようになる前は、潜在的なスパイクに対応するためにテレビ番組の開始 1 時間前にキャパシティーを手動でスケールアップし、番組終了後にスケールダウンしていました。突然の急上昇に備えるこのプロセスにはコストがかかりました。

DynamoDB オンデマンドにより、リクエストごとに支払うことができるようになり、トラフィック量が少ない期間が長く続く中で短いリクエストを急に受信する当社のサービスに最適でした。次のグラフは、あるテレビ番組の Request Count メトリクスを示しています。リクエストはあまり受けませんでしたが、その後 21:15～22:30 の間にテレビ番組のコンテンツに関連してリクエストの短いピークがありました。

本稼働

TVer Technologies は DynamoDB オンデマンドを re:Invent 2018 でローンチした翌朝に実装しました。設定は簡単で、BillingMode を PayPerRequest に更新する必要があります。午後 2 時に DynamoDB オンデマンドを設定し、同日午後 9 時のブロードキャストをスケジュールしました。午後 4 時に負荷テストを完了し、何も問題はありませんでした。

DynamoDB オンデマンドに切り替える前は、番組が終わるごとに数多くの DynamoDB テーブルを手動でスケールダウンするのに時間がかかっていました。DynamoDB オンデマンドの一般公開リリースの直後に、300 の DynamoDB テーブルの設定を PayPerRequest に更新し始めました。ブロードキャスト後に手動でスケールダウンする時間をとる必要がなくなり、開発者は他のタスクに集中できるようになりました。プロビジョンドモードとオンデマンドモードを切り替えるには、次のスクリーンショットに示すように、AWS マネジメントコンソールの DynamoDB テーブルの Capacity タブでクリックすることで簡単に行えます。

コスト削減の測定

複数のサービスで DynamoDB を使用しており、テーブルの 95% をオンデマンドに設定しました。これらのテーブルは、以前はプロビジョニングされた料金を支払うように設定されていました。その結果、1 か月で次のコスト削減が行え改善が見られました。

• プラットフォームサービス – これは他のすべてのサービスの基本サービスです。月額費用は 1,981 USD から 198 USD に減少し、90% の節約になりました。
• ゲートウェイサーバー – このサーバーはテレビ番組とやり取りします。月額費用は 2,587 USD から 95 USD 削減され、95% の節約になりました。
• オーディエンスリクエスト – これは、オーディエンスからのリクエストを受け付け、抽選でギフトを贈呈するサービスです。月額費用は 613 USD から 0.58 USD に減少し、99.9% の節約になりました。

この時点からの課題

オンデマンドモードで新しい DynamoDB テーブルを作成すると、デフォルトで最大 4,000 WCU または 12,000 RCU のキャパシティーで開始されます。オンデマンドテーブルは、以前の最高水準点の最大 200% のトラフィックスパイクに即座に対応でき、30 分ごとにその可能性を 2 倍にすることができます。けれども、場合によってはさらに多くのキャパシティーが必要になり、テーブルがスケーリングするのを待ちたくありませんでした。

このような場合、要件を満たすのに十分な WCU と RCU でプロビジョニングされたテーブルを「事前に温めて」おいてから、テーブルをオンデマンドモードに切り替えます。これは、以前にプロビジョンドモードを使用していたオンデマンドテーブルのキャパシティーを決定する DynamoDB のロジックのおかげで機能するものです。以前のピークは、テーブルにプロビジョニングされた従前の最大書き込み容量と読み取り容量ユニットの半分、またはオンデマンドキャパシティーモードで新しく作成されたテーブルの設定のいずれか高い方でした。詳細については、DynamoDB 開発者ガイドの「オンデマンドキャパシティーモードの初期スループット」を参照してください。

設定をオンデマンドに変更し、プロビジョンドに戻すと、再びオンデマンドに戻すのに 24 時間間隔を空けなければならないことに注意してください。この 24 時間の間に、プロビジョニングされた WCU と RCU を調整して、アプリケーショントラフィックに対応する必要があります (または単に Auto Scaling をオンにします)。

まとめ

複数のピーク時間でリクエストを受信し、ワークロードが急激に急増するサービスに DynamoDB を使用する場合、オンデマンドモードに切り替えることでメリットが得られます。ただし、サービスが急激なスパイクなしで安定したトラフィック量を受信する場合は、Auto Scaling で DynamoDB プロビジョニングモードを使用することをお勧めします。開発環境とテスト環境では通常、リクエストを散発的に受け取るため、DynamoDB オンデマンドモードはそのような環境において優れたコスト節約手段になります。ユースケースで保証されているときにオンデマンドモードを選択したため、TVer Technologies Inc. は費用を節約し、運用負荷を削減できました。

原文はこちらです。

著者について

ウツミケイスケ氏 は TVer Technologies Inc. のソフトウェアエンジニアです。