大量データ処理時に知っておきたいAmazon DynamoDB活用テクニック4選：大規模プッシュ通知基盤大解剖（2）（1/3 ページ）

大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する連載。今回は、アプリ単位でテーブル分割を行い「スループットの奪い合い」を防ぐ方法、「全件走査用テーブル」を用意して処理を効率化する方法、Amazon SQSやAWS CloudWatchと連携して「スループット超過エラー」を防ぐ方法、「並列スキャン」で読み取り速度を向上させる方法などを紹介します。

[相野谷直樹，リクルートテクノロジーズ]

連載目次

　リクルートテクノロジーズ APソリューショングループの相野谷です。前回の「プッシュ通知の基礎知識＆秒間1万を超えるプッシュ通知基盤のアーキテクチャと仕組みとは」では、Pusna-RS全体のアーキテクチャ構成について解説しました。今回からは、システム構成の各要素を複数回にわたり、ピックアップして解説していきます。

　まずこの記事では、Pusna-RSのデータ永続化層を支える「Amazon DynamoDB」（以下、DynamoDB）周りの構成について、ユースケースを交えながら紹介いたします。

フルマネージドNoSQLデータベース「Amazon DynamoDB」の採用理由

　Pusna-RSでは永続化層のマスターDBとしてDynamoDBを利用しています。DynamoDBは、AWSが提供するフルマネージドNoSQLデータベースです。RDBや他のNoSQLに比べ、次のような特徴があります。

• 読み書き性能（スループット）をプロビジョニングできる。キャパシティに応じてテーブルごとに読み書き性能を設定し、必要に応じて高いパフォーマンスを求めることが可能
• フルマネージド。自前でDBを保守運用する手間が掛からない
• 内部で自動的に3つのavailability zoneにレプリカが作成され、ユーザーが意識せずとも高い可用性が保たれている

※参考:AWS Black Belt Techシリーズ Amazon DynamoDB

　上記の特徴に加え、Pusna-RSでは複雑なデータ構造が不要であったこと、スマートデバイスからの急激な負荷に耐え得る高速な読み書き性能と高いスケーラビリティが必要であったことが、DynamoDBを採用した理由です。

　DynamoDBの採用により、アプリケーション層だけではなく永続化層にも高いスケーラビリティを実現できました。次項からは、Pusna-RSにおけるDynamoDBの活用方法の実際について4つ紹介していきます。

【1】アプリケーション単位でのテーブル分割で「スループットの奪い合い」を防ぐ

　本システムでは、プッシュ通知の対象となるスマートデバイスの情報をDynamoDBのテーブルに格納しています。本システムは複数のクライアントアプリから利用されるため、デバイス情報のテーブルはどのデバイスがどのクライアントアプリから登録されたものか識別できるように管理する必要があります。

　このデバイス情報とクライアントアプリのひも付け管理は、テーブル内のカラム情報で管理せず、クライアントアプリごとにテーブルを分けることで行っています。クライアントアプリ別にテーブルを分けることで、異なるクライアントアプリからのデバイステーブル参照リクエストが同じテーブルに集中することがなくなり、負荷が集中したときに設定した「スループットの奪い合い」が起こるのを防ぐことができます。

アプリのデバイス数に応じて最適なスループット値を設定