DynamoDBで実現する柔軟性と高パフォーマンスなデータ管理

ツール導入前の課題

Schoo（以下、スクー）では社会人向けの学習コンテンツを配信しており、ユーザーごとに「おすすめ授業」や「人気のコンテンツ」などをパーソナライズして表示します。

この表示ロジックのための集計処理（複数のテーブル結合や、非常に大量のデータ取得を伴う処理）を、当時はページアクセスごとに「RDSから取得 → Webサーバでの処理」という流れで行っていました。しかし、その処理に起因するスロークエリやレイテンシーの悪化が計測されていました。

どのような状態を目指していたか

この集計処理に起因するレイテンシー悪化を改善しUXを向上させるため、ページアクセス時は集計を極力行わずに必要なデータを取得するだけに留め、複雑な処理はバッチ処理などで事前に集計しておく状態を目指しました。

この「事前集計データ」の蓄積先として、DynamoDBの導入を行いました。

• RDS（index追加や集計専用テーブルの配置など、既存構成の最適化）
• Redis

• データ管理におけるパフォーマンス
• データの永続性

1桁ミリ秒のパフォーマンス

あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現することを目的として構築されており、100 ユーザーの場合でも 1 億ユーザーの場合でも、アプリケーションで一貫した 1 桁ミリ秒のパフォーマンスを出せる。 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Introduction.html

Redisとの使い分け

スクーでは、以下のように使い分けています。

• DynamoDB: データの永続性が必要で、かつ整合性を保ちたいデータ -（例：ランキング集計データ、ブックマーク数など、RDSを元にした集計データ）

  • 特に「RDSから取得してWebサーバーで都度集計する」と処理が重くなるような、事前集計データの保存先として利用

• Redis: 揮発してしまっても（消えても）問題ない一時的なデータ

• 事前集計データのキャッシュ先として導入したことで、集計処理に起因するレイテンシーの悪化を改善

柔軟性と高パフォーマンスを必要とするデータを管理したいとき、DynamoDBは強力な選択肢の1つになると思います。

ただし、上記に挙げた通り、RDBとは違ったDynamoDB特有の特徴や思想（特にアクセスパターン中心の設計）があります。自分たちが実現したい要件（データの永続性は必要か、クエリのパターンは事前に予測可能か、トランザクションは必須かなど）を明確にし、その要件を満たしているかを確認することが非常に大切だと思います。