OPENREC.tvにおけるDynamoDBを用いたデザインパターン | CA BASE NEXT

□ 登壇者
藤井 貴大

□ 発表について
ゲーム配信を中心とした高画質・低遅延のライブ配信プラットフォームサービスであるOPENREC.tv では、NoSQL データベースとして Amazon DynamoDB を積極的に使い、スケーラブルかつ高可用性なアプリケーションを構築、提供しています。このセッションでは、Amazon DynamoDB を用いたアーキテクチャ、キャパシティプランニングや監視などについて、実際の事例をもとにご紹介します。

セッション動画はこちら

□ CA BASE NEXT (CyberAgent Developer Conference by Next Generations) とは
20代のエンジニア・クリエイターが中心となって創り上げるサイバーエージェントの技術カンファレンスです。
当日はセッション・LT・パネルディスカッション・インタビューセッションを含む約50のコンテンツをYouTube Liveを通じて配信します。
イベントページ

□ 採用情報
サイバーエージェントに少しでも興味を持っていただきましたら、お気軽にマイページ登録やエントリーをおねがいします！

◆新卒エンジニア採用
エントリー・マイページ登録はこちら
採用関連情報のまとめはこちら

◆新卒クリエイター採用
エントリー・マイページ登録はこちら

◆中途採用
採用情報はこちら

Transcript

2. 藤井 貴大 2019年度 新卒入社 株式会社CyberZ 開発本部 プロダクト開発局 SRE 普段の業務ではEKSの運用や負荷対策などを中心に OPENREC.tvのサービス開発に従事 @toro-ponz @toro_ponz
3. ・ゲームを中心とした、高品質低遅延な ライブ配信プラットフォーム ・AWS上にシステムを構築し提供 ・2015年1月 サービス開始 ・2019年 EKSの本番運用を開始 について
4. について
5. 今回は Amazon DynamoDB を用いて実現している、 タイムライン機能 についてご紹介します。 について
6. 1.タイムライン機能について 2.RDBで実現するタイムライン 3.DynamoDBで実現するタイムライン 4.まとめ 目次
7. タイムライン機能とは
8. タイムライン機能とは 自分がフォローしている配信者の ライブ配信を時系列順に追うことができるページ・機能
9. RDBで実現する 時系列タイムライン機能
10. 前提: DB設計 ユーザーテーブル フォローテーブル 配信情報テーブル
11. RDBでの実現例: 取得SQL SELECT * FROM lives WHERE user_id IN ( SELECT followee_user_id FROM follows WHERE user_id = 12345 ) ORDER BY published_at LIMIT 40; SELECT * FROM lives JOIN follows ON lives.user_id = follows.followee_user_id WHERE follows.user_id = 12345 ORDER BY lives.published_at LIMIT 40; フォロイーのID一覧を取得して WHERE INで絞る 配信テーブルとフォローテーブルを JOINする OR
12. メリット データ構造がシンプルで実装コストが低い 複雑な検索も場合によっては可能 フォロー数が増えるにつれ、クエリ速度が低下する 同様に配信レコード数が増えるにつれ、クエリ速度が低下する => サービスの成長と共に、フォロー数の多いヘビーユーザーで顕著化 メリット デメリット
13. 解決策: ユーザーごとのデータ保存 ユーザーごとにタイムラインのデータを持ち、ユーザーごとに時系列を維持する (Write Heavyな方式)
14. Amazon DynamoDBで実現する 時系列タイムライン機能
15. キー設計 Partition Key: 参照ユーザーID Sort Key: タイムスタンプ + 配信ID(重複防止)
16. Queryによる取得(PartiQL) SELECT * FROM timeline WHERE user_id = 12345 ORDER BY sort DESC LIMIT 40; SELECT * FROM timeline WHERE user_id = 12345 AND sort < “xxxxx_yyyy” ORDER BY sort DESC LIMIT 40; SELECT * FROM timeline WHERE user_id = 12345 AND BEGINS_WITH( sort, “20210501” ) ORDER BY sort DESC LIMIT 40; 最新の40件取得 特定のキーより前の 40件取得 (ページング等) 特定の日付の40件取得
17. BatchWriteItemによる保存 配信開始時にフォロワー数分のアイテムが作成される 最大で数十万のアイテムを作成するため SQS & Lambdaで非同期化 PatitionKeyはフォロワーのIDのため、書き込みが均等に分散する PartitionKeyが適切に分散しないと、特定パーティションに書き込みリクエストが集中し スロットリングする恐れがある
18. Lambdaでリトライ アプリケーションの実装でリトライ AWS SDKでリトライ SQSでリトライ 無限リトライを防ぐため、リトライ回数の上限で DLQへ流す DynamoDBでの実現例: リトライ
19. 予め必要なキャパシティを予約しておく方式 そのキャパシティが使われなくても課金される オートスケーリングを設定できる 余分な課金の割合が高い 消費した分だけ課金 消費したキャパシティに対する 従量課金方式 過去の消費キャパシティの 2倍に自動でスケール => 今回の場合オンデマンドモードを選択 ・オンデマンドモード ・プロビジョンドモード
20. 配信情報のマスターデータはRDBに永続化されている RDBとDynamoDBのデータをどこまで同期するかを定義する必要がある データのライフサイクル 例: 配信削除時、非公開時など 1. DynamoDBからBatchWriteItemで全て削除 2. アプリケーション (取得API) 側で除外 → こちらを採用
21. DynamoDBにはキャパシティ以外にも、ストレージ課金が存在 そのままだと無限にデータが増え、コストが増える タイムラインのデータは新しいものほどアクセスされ、 古いものほどアクセスされない特性がある 一定期間以上経過したデータを削除する → TTL (Time To Live) の設定 TTL
22. まとめ
23. まとめ DynamoDBは時系列データをユーザーごとに保存する用途として有用 ただし正しくキー設計をしないと、スケーラビリティが損なわれる 数秒〜数十秒かかっていた場合もあったリクエストタイムを 100ms程度に短縮 オンデマンドモードを利用することで、 スパイク耐性や料金の最適化ができる 予測が難しく、かつユーザー数に比例しづらい突発的なアクセスでは有効 単位当たりの料金ではオンデマンドの方が割高なため注意 データのライフサイクルなどを適切に定義する必要がある リトライ戦略および監視 RDBとのデータ整合性
24. 参考 How CyberZ performs read-light operations to display followees’ activities in the timeline using Amazon DynamoDB en: https://aws.amazon.com/jp/blogs/database/how-cyberz-performs-read-light-operations-to-display-followe es-activities-in-the-timeline-using-amazon-dynamodb/ ja: https://aws.amazon.com/jp/blogs/news/how-cyberz-performs-read-light-operations-to-display-followees- activities-in-the-timeline-using-amazon-dynamodb/