こんにちは、Webエンジニアのちょうです。先週開催したAWS SUMMIT 2018に行ってきました。予約が遅くて、２セッションしか取れなかったですが、その中の一つ「Tech上級：データベース入門」について自分の理解と感想をここで記録したいと思います。
セッションのレポートはこちらからご覧になれます。
AWSにおいて、大枠に分けると、RelationalとNon-Relationalデータベース２種類があります。MySQL、PostgreSQLなどのRDBMSはもちろんRelationalデータベース（AWS RDS）に当てはまります。それとDWHに特化したRedshift。Non-Relationalには、NoSQLデータベースであるDynamoDB、KVデータベースのElasticCacheとまだPreview段階のグラフデータベースNeptuneが入ってます。
実際、利用するシーンとデータベースのタイプを見れば大体どれを使うのは分かるでしょう。例えば、PBレベルのデータがあり、SQLを使いたい場合はRedshift、キャッシュとして使いたいならElasticCache。でもRDSの中ではAWSでしかないAuroraというRDBMSがあります。普段使ってるデータベースとなにが違うのかすこし迷うになるでしょう。
セッションでは、普通のRDSはDBサイズが16TB未満という制限を言及していますが、多分これはクリティカル的な問題ではない。AuroraがMySQL 5.6/5.7, PostgreSQL 9.6と互換性がある上で、パフォーマンスとシームレスインスタンスのアップグレードが一番注目される機能でしょう。Auroraの紹介ページでは同じハードウェアの前提でMySQLの5倍、PostgreSQLの3倍早いと書かれています。その原因について、セッションで紹介されているAuroraのアーキテクチャからすこし分かると思います。
- AWSの既存サービス特にS3を利用し、可用性と耐久性の向上
- 複数ノード構成
ここで複数ノードがポイントになるでしょう。普通のRDBMSではシングルノードが想定されていて、パフォーマンスの向上はインスタンスタイプに決められています。つまりスケールアップの方法しかないということです。でも複数ノードになることで、分散実行などが可能になり、一リクエストに対して、並列実行のメリットが得られます。
もちろん、現実はマージソートのような簡単な問題ではありません。Auroraの内部で、分散データベースのように、ノードのダウンを備えて、データブロックは複数のAZにコピーしています。それと、アーキテクチャではノードとストレージが分離されています。つまり、スケールアウトもできるようになります。普通のデータベースがダウンしたら、再起動する段階でものすごくリクエストが入ってしまってまだダウンする問題を考え、キャッシュレイヤーがデータベースのプロセス外に移動されるという施策も紹介されました。
AWSすべてのデータベースを一通り説明するセッションなので、もっと詳しいアーキテクチャが話さなかったです。でもこれでAuroraについて大体なイメージをつかまり、なかなか興味深いです。
それ以外に、HTTPセッションに使えそうなDynamoDBのTTL機能も面白そうです。
いかがでしょうか。AWSのデータベースサービスが多くて、選択が難しいという方が多くいらっしゃると思いますが、ぜひこのセッションを見て決めるようになりましょう。
