suzu6この記事について
こんにちは、suzu6です。
本ブログはAWSのLambdaとDynamoDBを使って、サーバレスなシステム構成になっています。
現在の構成はこちら
Lambdaのところに、PythonのFlaskで作ったシステムがのっています。全体像はこちらで解説しています。
この記事では、DynamoDBを使う中で感じた、特徴とLambdaとの相性を紹介します。
DynamoBDの特徴
- NoSQLでタイプはキーバリューストア型
- 自動的なスケールアップ。
- 読み込み書き込みが早い。
- プライマリキーは
HASHかHASH + RANGEの２通り - コピーを３箇所に分散して保管してくれる
- SQLではなく、APIで操作する。
- SQLに比べて、学習コストが高い。
NoSQLなDynamoDB
DynamoDBはNoSQLであり、（馴染み深い）Postgresqlなどのリレーショナルデーターベースとは大きく異なります。
NoSQL データベースとは
NoSQL データベースは、スケーラブルなパフォーマンスとスキーマレスなデータモデル向けに最適化された非リレーショナルデータベースです。
NoSQL データベースには、列指向、ドキュメント、グラフ、キーバリューストアという4つのタイプがあります。 その内、DynamoDBはキーバリューストア（Kye-Value Store）にあたります。
キーバリューストアは、保存する情報（value）に識別記号（key）をつけて管理しようというもの。 保存できる情報を固定化せず大小様々なものを保管し、検索するときに識別記号だけ見みます。
AWS LambdaとDBの相性について
AWSで利用できるデータベースは、Postgresなどが使えるRDSとNoSQLのDynamoDBがあり、この２つを比較しました。
(調査不足のためRedShiftは考えていませんでした。。。)
Lambdaの特徴は、リクエスト受信の回数に合わせて自動的にスケールすることです。
ブログへリクエストが頻発すると、データベースへのアクセス数も多くなります。
ここで、RDSでは接続数が問題になります。 当然ながら同時に接続される数が多ければ多いほど必要なCPU数、メモリ数が増えていきます。
また、DBへ都度接続することは負荷になるため、一般的にはコネクションプールを使って接続を使いまわします。 しかし、Lambdaは処理が終われば接続は切れますし、接続を共有することもありません。
RDSではピークの処理に合わせて始めから大きなスケールアップが必要となります。 よって、Lambdaとの相性はよくありません。
一方、DynamoDBはLambdaと同じくスケーリングが可能です。
そのため、Lambdaと合わせるDBはDynamoDBを選ぶと良いです。
さらに詳しくは、こちらをご参照ください。
設計のポイント
- プライマリーキーを3つ以上指定できない
- プライマリーキー以外でのソートはできない
- 空文字が利用出来ない
- テーブル結合した検索はできない
- 複雑なデータ更新の多いシステムの利用には向かない
- キャパシティユニットは自動ではスケールしない
- 一回の検索で得られるのは１MBまで
使ってみた感想
本ブログでは、記事やタグの管理をDynamoDBを使っています。
PV数も月に数百PVくらいなので、スケールアップの恩恵はまだ受けていませんが、料金が無料利用枠に十分収まっています。
良い点は、コンソール画面が使いやすいところでしょうか。 ちょっとした編集やテスト用の項目を手軽に消したりできます。
困った点は、SQLが使えずライブラリのboto3を利用したところです。 SQLならこう書くのにとすぐ思い浮かんでも、DynamoDBとboto3の書き方を頑張って調べて、英語のドキュメントも読んでどうにか実装していきます。 学習コストが高い点が最大の壁かもしれません。
もう一点困ったことは、ページネーションです。
SQLでは、offsetとlimitを使って取得する範囲と件数を簡単に書けます。
DynamoDBでは、boto3のPagenatorを利用するようです。
情報が少なくまだ理解しきれてないため、現在はscanで全件取得して必要な範囲を得ています。
重そうな処理ですが、記事数が少ないためか、記事一覧のページネーションが意外とサクサク動いています。 今後、ベストな方法に変更していきたいです。
参考
サーバレスアーキテクチャを勉強される方は、こちらの本がおすすめです。
動画シェアサイトをAWS Lambda, S3を使って実際に構築する手順が載っています。 その中で、どのようにLambdaを構成したら良いか大変参考になりました。また、DynamoDBとAuth0も詳しく書かれています。