【ITニュース解説】The Day I Learned Why DynamoDB Costs More

以前、あるシステムエンジニアは、アマゾンの提供するサーバーレスなNoSQLデータベースであるDynamoDBをアプリケーションデータ格納に利用する計画に関わっていた。当時、そのエンジニアはデータベースのコストは主に保存するデータの量、ストレージ容量に依存するという考えを持っていた。しかし、シニアエンジニアから「このシステムの読み書きの容量はどれくらいになるのか？」という質問があり、その答えが「非常に高い」と判明した時、シニアエンジニアはDynamoDBの採用に難色を示した。

シニアエンジニアは、その理由として「DynamoDBではストレージだけでなく、読み込みと書き込みに対してより多くの費用がかかるため、大量の読み書きがあるシステムではコストが爆発的に増大する」と説明した。当時のエンジニアにはこの指摘の真意が理解できなかった。データベースのコストはストレージ容量が全てという固定観念があったからである。しかし、後にDynamoDBの料金モデルとアーキテクチャを深く理解する中で、この言葉の意味を明確に把握することができた。

DynamoDBの料金モデルは、従来の多くのデータベースとは異なる特徴を持つ。ストレージの料金自体は比較的安価で、例えば1ギガバイトあたり月額約0.25ドル程度とされている。しかし、DynamoDBのコストの大部分を占めるのは、RCU（Read Capacity Unit：読み込みキャパシティユニット）とWCU（Write Capacity Unit：書き込みキャパシティユニット）と呼ばれる、読み書きのリクエストに対する料金である。RCUはアイテムのサイズと読み込みの一貫性モデルに基づいて、WCUはアイテムのサイズに基づいて課金される。つまり、システムが実行する読み込みおよび書き込み操作の数が増えるほど、それに応じてRCUとWCUの消費量が増え、料金も高くなる仕組みなのだ。さらに、テーブルにインデックス（ローカルセカンダリインデックスやグローバルセカンダリインデックス）を設定している場合、データを書き込むたびにこれらのインデックスも更新されるため、書き込み操作ごとにWCUの消費量が実質的に増加する点も考慮が必要である。結果として、毎秒何百万もの読み書き操作が発生するようなシステムでは、保存データ量よりも操作回数に応じて費用が大きく変動することになる。

DynamoDBのシステムアーキテクチャは、高いスループットと効率的な処理を実現するいくつかの重要な概念に基づいている。まず「パーティションとキャパシティ」の概念がある。DynamoDBのデータは複数のパーティションに分散して保存され、各パーティションはそれぞれ独立したRCUとWCUの容量を持っている。そして、各パーティションには「トークンバケット」と呼ばれる仕組みがあり、これは未使用の容量を一時的に蓄積しておく機能である。このトークンバケットには最大約5分間分の未使用容量を蓄積でき、急激なトラフィック増加、いわゆる「バースト」発生時には、蓄積された容量で一時的に処理を吸収できる。これにより、通常ではスロットリング（リクエストの拒否や遅延）が発生するような急なスパイクでも、システムが安定して対応できるよう設計されている。

次に、「キャッシング」の仕組みが重要だ。DynamoDBは、よくアクセスされるデータをキャッシュすることで、パフォーマンスの向上とコスト削減を図っている。例えば、DynamoDB Accelerator（DAX）のような専用キャッシュサービスを利用すれば、アプリケーションからの読み込みリクエストの多くをキャッシュで処理できる。キャッシュからデータを読み取る場合、RCUを消費せず、特に読み込み頻度の高いワークロードで大幅なコスト削減につながる。DAXを利用しない場合でも、DynamoDB内部にはメタデータやその他のキャッシュ戦略が存在し、非常に高いキャッシュヒット率（約99.7%）を維持することで読み込みレイテンシーの低減に貢献する。

さらに、DynamoDBはデータの「レプリカ」を複数作成し、複数のアベイラビリティゾーン（AZ）に分散して配置することで、高い耐久性と可用性を実現している。これにより、一部のAZで障害が発生してもデータが失われたり、サービスが停止したりするリスクが低減される。ただし、レプリカが追加されても、テーブル全体のRCUやWCUのスループット容量が増えるわけではない。RCUとWCUはあくまで各パーティションに割り当てられた容量に基づいて計算される。

これらの仕組みを理解した上で、筆者はシニアエンジニアが言った「ストレージではなく、読み書きの量に対して課金される」という言葉の真意をようやく理解した。それは単にコストの話だけではなく、システムのワークロード（負荷のパターン）に最も適したデータベースを選択することの重要性を示していたのである。中程度の読み書きの負荷を持つワークロードであれば、DynamoDBはそのサーバーレス性、スケーラビリティ、そして予測可能な性能によって非常に優れた選択肢となる。しかし、毎秒数十万、数百万といった極めて高い読み書きの負荷がかかるシステムの場合、そのコストモデルゆえに、他の選択肢、例えばAmazon Auroraのようなリレーショナルデータベース、Apache CassandraのようなオープンソースのNoSQLデータベース、あるいはAmazon S3とキャッシュレイヤーの組み合わせの方が、全体的なコストパフォーマンスにおいて優れている可能性がある。

この経験から得られる重要な教訓はいくつかある。第一に、DynamoDBで最大のコスト要因はストレージではなくRCUとWCUである点を常に意識することだ。第二に、システムのパフォーマンスとコスト効率を予測可能にするためには、バーストキャパシティの仕組みとキャッシングの活用が極めて重要になる。特にDAXなどのキャッシュ戦略を導入することで、読み込み中心のワークロードにおけるRCU消費を劇的に抑えられる。第三に、DynamoDBの採用を検討する際には、「このシステムはどれくらい読み書きが頻繁に行われるのか？」という問いを常に自らに投げかける必要がある。そして最後に、優れたメンターは、単に特定の技術の機能だけでなく、その技術がどのようなワークロードパターンに適しており、どのようなコストモデルを持つのか、といった本質的な側面からシステム設計を考えるように促してくれる。

あの時、なぜDynamoDBが選択されなかったのか、その理由は理解できなかった。しかし、今ではDynamoDBのアーキテクチャ、バーストキャパシティ、そしてキャッシングの仕組みがどのように連携して機能するのかを理解したことで、その決定の妥当性を納得できる。この学びはDynamoDBに限らず、あらゆるシステム設計の決定が、単に技術的側面だけでなく、コストモデル、ワークロードパターン、パフォーマンス戦略といった複数の要素と密接に結びついていることを示している。時に、物事の点と点が結びつき、その意味を完全に理解するまでに数年を要することもあるのだ。