No content

藤井 貴大 2019年度 新卒入社 株式会社CyberZ 開発本部 プロダクト開発局 SRE 普段の業務ではEKSの運用や負荷対策などを中心に OPENREC.tvのサービス開発に従事 @toro-ponz @toro_ponz 

・ゲームを中心とした、高品質低遅延な ライブ配信プラットフォーム ・AWS上にシステムを構築し提供 ・2015年1月 サービス開始 ・2019年 EKSの本番運用を開始 について 

について 

今回は Amazon DynamoDB を用いて実現している、 タイムライン機能 についてご紹介します。 について 

1.タイムライン機能について 2.RDBで実現するタイムライン 3.DynamoDBで実現するタイムライン 4.まとめ 目次 

タイムライン機能とは 

タイムライン機能とは 自分がフォローしている配信者の ライブ配信を時系列順に追うことができるページ・機能 

RDBで実現する 時系列タイムライン機能 

前提: DB設計 ユーザーテーブル フォローテーブル 配信情報テーブル 

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 

メリット データ構造がシンプルで実装コストが低い 複雑な検索も場合によっては可能 フォロー数が増えるにつれ、クエリ速度が低下する 同様に配信レコード数が増えるにつれ、クエリ速度が低下する => サービスの成長と共に、フォロー数の多いヘビーユーザーで顕著化 メリット デメリット 

解決策: ユーザーごとのデータ保存 ユーザーごとにタイムラインのデータを持ち、ユーザーごとに時系列を維持する (Write Heavyな方式) 

Amazon DynamoDBで実現する 時系列タイムライン機能 

キー設計 Partition Key: 参照ユーザーID Sort Key: タイムスタンプ + 配信ID(重複防止) 

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件取得 

BatchWriteItemによる保存 配信開始時にフォロワー数分のアイテムが作成される 最大で数十万のアイテムを作成するため SQS & Lambdaで非同期化 PatitionKeyはフォロワーのIDのため、書き込みが均等に分散する PartitionKeyが適切に分散しないと、特定パーティションに書き込みリクエストが集中し スロットリングする恐れがある 

Lambdaでリトライ アプリケーションの実装でリトライ AWS SDKでリトライ SQSでリトライ 無限リトライを防ぐため、リトライ回数の上限で DLQへ流す DynamoDBでの実現例: リトライ 

予め必要なキャパシティを予約しておく方式 そのキャパシティが使われなくても課金される オートスケーリングを設定できる 余分な課金の割合が高い 消費した分だけ課金 消費したキャパシティに対する 従量課金方式 過去の消費キャパシティの 2倍に自動でスケール => 今回の場合オンデマンドモードを選択 ・オンデマンドモード ・プロビジョンドモード 

配信情報のマスターデータはRDBに永続化されている RDBとDynamoDBのデータをどこまで同期するかを定義する必要がある データのライフサイクル 例: 配信削除時、非公開時など 1. DynamoDBからBatchWriteItemで全て削除 2. アプリケーション (取得API) 側で除外 → こちらを採用 

DynamoDBにはキャパシティ以外にも、ストレージ課金が存在 そのままだと無限にデータが増え、コストが増える タイムラインのデータは新しいものほどアクセスされ、 古いものほどアクセスされない特性がある 一定期間以上経過したデータを削除する → TTL (Time To Live) の設定 TTL 

まとめ 

まとめ DynamoDBは時系列データをユーザーごとに保存する用途として有用 ただし正しくキー設計をしないと、スケーラビリティが損なわれる 数秒〜数十秒かかっていた場合もあったリクエストタイムを 100ms程度に短縮 オンデマンドモードを利用することで、 スパイク耐性や料金の最適化ができる 予測が難しく、かつユーザー数に比例しづらい突発的なアクセスでは有効 単位当たりの料金ではオンデマンドの方が割高なため注意 データのライフサイクルなどを適切に定義する必要がある リトライ戦略および監視 RDBとのデータ整合性 

参考 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/ 

No content