Lapis Lazuli

technical blog for web developer

【AWS】DynamoDBを活用したい

AWSの代表的なNoSQLデータベースのDynamoDB。
SAAの勉強で覚えたきりでしたが今回復習を兼ねて活用方法を考えてみました。

DynamoDBとは

Amazon DynamoDB は、規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースです。完全マネージド型マルチリージョン、マルチマスターで耐久性があるデータベースで、セキュリティ、バックアップおよび復元と、インターネット規模のアプリケーション用のメモリ内キャッシュが組み込まれています。DynamoDB は、1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエストをサポートします。

aws.amazon.com

公式のドキュメントによると以上のように書いてあります。
主に以下の特徴を持っているそうです。

  • 完全マネージドなサービス
  • 柔軟なスケールが可能

なんだか魅力的なワードが並んでいますねぇ。
一つずつみて見ましょう。

完全マネージドなサービス

他のAWSのサービスと同じくマネージドなサービスになります。
負荷がかかるとキャパシティユニットを使って性能を増加することが出来ますし、データの保存容量は無制限です。
この辺りは他のサービスと似てますね。
特徴的なのがキャパシティユニットに応じて性能が左右される点です。
キャパシティユニットとは、読み書きの性能を左右するもので、それぞれRead/Writeの2つの容量を決める事が出来ます。
DBを作成するときに決めますが、あとで増減は可能。AutoScaleにも対応しています。
1キャパシティユニットは1秒間に1回の書き込み、もしくは読み込み2回、整合性のある読み込み1回と設定されています。
ちなみに料金もキャパシティユニットの数によって決まるので、コストの観点から無駄に大きいサイズを指定していいものではなりません。
なので最初は妥当な数を指定して、CloudWatchでモニタリングしながら最適なユニット数を決めていくのが基本的な運用の流れになると思います。

柔軟なスケールが可能

上のキャパシティユニットでも説明しましたが、これを増減することで簡単に性能アップもしくはダウンを図る事が出来る柔軟性があります。
ただ数を増やしすぎると、今度はRead性能があまり上がらない・・・という状況になる可能性があります。
これはDynamoが内部で並列化してスケールしているため、一つのデータにReadが集中するとこういう状況になります。
その時はDAXというオンメモリキャッシュの出番です。
Dynamoの前にキャッシュを配置することでRead性能を劇的に向上させる事が出来ます。
書き込みよりも読み込みが多いような用途では絶大な効果を発揮しそうですね。


という特徴がありますが、私的にはスケールが効くのでlambdaと相性が良いっていうのが大きかったりします。
どうしてもRDSと比較するとスケールされるlambdaとの相性は悪いので・・・
この問題に関してはRDSの前にスレッドプール的な機構を設ける事である程度解決するらしいですが。