業種: 配信サービス, 高負荷, パフォーマンス改善, フルサーバレスアーキテクチャ
ユースケース: Video Distribution
Hokkaido Television Broadcasting Co., Ltd. は、北海道を放送対象地域とする特定地上基幹放送事業者であり、テレビジョン放送事業を行っています。放送だけではなく、動画配信やECサービスなどの放送外の事情にも積極的に取り組んでいます。
どうしてキャッシュが必要だったのか
[水曜どうでしょう」という人気番組の道内放送に合わせて、放送直後に同番組の配信がスタートするのですが、その際に番組配信サービスのスパイクアクセスが発生していました。高負荷が予測される状態でも、スムーズな番組配信を行うための仕組みとしてキャッシュ機構が必要でした。
なぜMomentoを採用したのか
我々のサービスは、フルサーバーレスなアーキテクチャで構成されているため、この構成に相応しいキャッシュサービスが存在していなかったため、キャッシュを導入できずにいました。
Momento を導入することによってサーバーレスな構成でスパイクアクセスを乗りこなすことができるのではないか、という期待があったのです。またパフォーマンスの向上という点でも期待がありました。
導入した結果、期待通りとなり、スパイクアクセスが発生した状態でも問題なく動画配信サービスを提供することができました。また、APIのレスポンスも大きく改善されたのです。
Momentoと既存のフルサーバレスアーキテクチャを組み合わせ
- BFFとしてAppSyncによるGraphQLのAPIを構築しています。最終的には、そのResolverとして設定しているLambdaからMomentoのCacheをGetしてくるという形を採用することにしました。
- AppSyncに対してたくさんのリゾルバーが動く大きくて複雑なクエリをしていたため、AppSyncのTokenConsumedが200-300まで膨れ上がってしまっていたため、この値を1桁まで減らすことが求められていました。また、DynamoDBのホットパーテーションに引っかからないようにする必要もありました。
- 根本的な解決をするためには、バックエンドのNoSQL設計を根本から見直す必要があるとわかったのですが、この時点で本番まで２ヶ月を切っていたため、再設計をする時間はなく、別の方法でオフロードをする必要がありました。
- まずはAppSyncにもともと備わっているキャッシュの有効化を試したのですが、リゾルバー単位のキャッシュを設定することで、DyanamoDBのホットパーテーション対策はできたのですが、TokenConsumedに関しては改善する設定方法を見つけることができませんでした。
- また、AppSyncのキャッシュはElastiCacheをベースにした時間課金のサービスであったため、予算的にも常時採用することは難しいと判断しました。
- ちょうど機能追加されたAppSyncのMerged APIを活用することで、この特定の大きなクエリで取得するデータを格納したMomentoのデータを取得するAppSyncに切り替えることによって、バックエンドの一部だけを機能追加することで、他への影響なく対応することができました。
本番デプロイまでにかかった時間
設計を考えるのに1週間。開発環境で負荷試験を実施するまで1週間ほど。エラーハンドリングなどを加えて本番環境にデプロイするまでもう1週間。ゼロから初めて合計3週間で本番環境のデプロイまでできました。
本番環境でのMomentoのコスト削減やパフォーマンスの改善について
- パフォーマンスの改善について、AppSyncのDynamoDBリゾルバーを用いてのデータ取得には平均して2秒前後の時間がかかっていましたが、Lambdaリゾルバー経由でMomentoからのデータ取得に変更することによって、500ms 前後までパフォーマンスを改善することができました。
- コストについて、時間課金のキャッシュの場合、予測されるタイミングだけに絞ってデプロイするという方法で最小限のコストを実現することも考えましたが、この方法では予測されないスパイクアクセスには対応ができないため、従量課金の設定になっているMomentoはコストの最適化も実現することができました。
Momentoとの将来
- Momentoを採用することで、フロントエンドも含めたアーキテクチャ全体を通してのキャッシュ戦略をサーバーレスでも考えることができるようになったのは非常に嬉 しいです。データを新しくSetした場合の結果整合性や強い一貫性の担保なども対応していただけると実装上で考えることが減るので、期待しています。
- た、フロントエンドからのMomentoへのアクセスですが、今回は時間の関係上テストまでして採用を見送ったのですが、 Web SDK も非常に実装がしやすいものだったため、今後のリファクタリングの中で使い所を考えていきたいと思っています。
EN 
JP