初めに
2022年中のクラウドDB(主にAWS)の進化の振り返りと、今後の展望となります。
（特に網羅的な調査等を実施したわけではなく、単なるポエムです）
今年のAWSのDBサービスの進化について
今年のAWSの各種DBサービスでは、明らかに以下の点での強化が目立ちました。
1. DB(DWH、Analyticsも含む)のServerless化
そもそもServerless Databaseの明確な定義は存在しないと思われますが、プロビジョニングやアップグレードなどの操作をAPIで簡単に実施可能なManaged Databaseから一歩進んで、無停止でのワークロードに応じたリソースのスケーリング、pay-as-you-useモデルによる高いコスト効率等の特徴が一般的に挙げられると考えられます。
一般的なServerless Databaseの定義と代表的な製品については次のWebサイトにて説明があります。
Top 6 Serverless Databases to Start a New Project in 2022
AWSでは今年だけでも以下のDBのServerless版がGAもしくはpreviewとなっています。
※DocumentDB Elastic CLustersについては自動的にデータの分散/再分散を実施するものの、スケーリング操作が自動化されておらずかつ無停止でもなく、pay-as-you-useモデルでないことから除外しました
- Aurora Serverless v2
- Neptune Serverless
- Redshift Serverless
- OpenSearchService Serverless
しかしながら実はAWSにおけるServerlessのDBサービスは目新しいものではなく、スケーラビリティの高いServerlessのDBサービスであるDynamoDBは2012年にリリースされています。
以下のWebサイトではDynamoDBの特徴やリリースまでの経緯について説明があります。
次の記事にて詳細な説明がある通り、DynamoDBはジョインやソート、集計等の操作がサポートされておらず、計算量がO(1), O(log n)の操作を主に利用します。
全件を取得するScanの操作も存在しますが、1リクエストのレスポンスのサイズは最大で1MiBとなることから、個別のクエリがデータ量の増加に伴い無尽蔵にCPUやメモリ、ストレージI/O、ネットワーク等の各種リソースを使い潰すことはありません。
SQL, NoSQL, and Scale: How DynamoDB scales where relational databases don't
そもそもRDBのようにオプティマイザ統計や実行計画の概念すら登場しないので、データの肥大化や更新に伴い、全く同一のクエリであったとしてもアクセスパターンやリソースの使用量が大きく変わるということも原理上起き得ないです。
このシンプルなクエリモデルおよびキャパシティユニットによるプロビジョニングの仕組みにより、10年前の時点でもスケーラビリティの高いServerlessのDBサービスを実現できたと思われます。
一方で2022年にGAとなった各種Serverlessサービスは、いずれもジョインやソート、集計等の操作をサポートしており、クエリ毎にアクセスするデータ量が著しく異なる可能性があります。
加えて、オプティマイザ統計や実行計画の概念が存在することから、データの肥大化や更新に伴いアクセスパターンやリソースの使用量が大きく変わる可能性があります。
以上のことを踏まえると、パフォーマンスと迅速なスケール、コスト効率、サーバーの稼働率等の相反する要素を同時に満たしてServerless化する難易度が非常に高いことが2022年まで登場がずれ込んだ原因であると考えられます。
※Aurora Serverless v1?知らない子ですね。
また前述のとおり原理上、複数の相反する様子を同時に満たしつつ、「お客さんの求める良い感じの動作」を実現することは非常に難しいので、期待通りに動かなかったり、あるいはワークロード次第ではコスト削減にならないといったことも十分考えられ、今後も改善と試行錯誤が続くと考えられます。
2. 異なるデータベース間のデータ連携の強化
AWSは用途毎にDBを使い分けるPurpose-Built Databaseの考え方を推奨しています。
以下はAWS公式のPurpose-Built DatabaseについてのWebサイトとなります。
この時、実現する機能の単位でDBを分割するだけではなく、「低いレイテンシーで小容量のデータへアクセスし、高いスループットが求められる操作はOLTP用のデータベースで実行する」「OLTP用のデータベースに格納された大量データの分析、集計処理はDWHを利用する」といった、同じデータをワークロード毎に適切なデータベースで処理することも求められます。
従来のやり方ではETLの構成をユーザーが独自に考える必要があり、しかも複雑な設定が必要でした。
加えて仕組みの限界からどうしても性能のボトルネックが生じやすいといった問題もありました。
今年のre:Inventでpreviewが発表されたAurora zero-ETL integration with Amazon Redshiftでは名前の通りETLなしでシームレスなAuroraとRedshiftの統合を実現しています。
以下、youtubeで公開されているre:Inventの動画となります。
AWS re:Invent 2022 - [NEW] Enable operational analytics w/Amazon Aurora & Amazon Redshift (DAT328)
動画中で解説されている通り、Redshiftへのレプリケーションを実現する際のAurora側のボトルネックが解消されています。
Redshift側も従来のクエリのプランニング、実行のフローでは小サイズの更新クエリを大量かつ低レイテンシーで実行することに向いていないためか、コンピュートノードで直接並列で更新を実行する方式がとられています。
以下、公式ドキュメントのRedshiftのクエリ実行のフローとなります。
Query planning and execution workflow
上記のzero-ETLと仕組みが完全に同等か公開情報からは確認できていませんが、GAとなったRedshift Streaming Ingestionでは、S3を経由せずにKinesis Stream、もしくはKafkaから直接、各コンピュートノードに対して並列でデータを取り込むことが可能です。
データベースからのデータの移行専用ではありませんが、従来、DynamoDBの更新履歴を取り込む際には例えばFirehorseでS3へ一度書き出してから、通常のクエリの実行フローでCOPY文でデータを取り込む等、S3を経由することが多かったので、スループット、レイテンシーともに大きく進歩しているとみられています。
※ただし、仕様を見る限りではあくまでストリームデータのリアルタイムの検索に特化しており、前述のzero-ETLのようなレプリケーションを実現するためには作りこみが必要になると思われます。
今後の展望について
恐らくDBサービスは今後、以下のような発展が見込まれるのではないでしょうか。
1. リソースのスケーリング以外の面での自動化の追求
CPU、ストレージ、メモリ等の自動的な無停止でのリソースのスケールアップ/アウト/ダウン/インのほかに、データベースの特性に合わせた自動化、最適化がより多くの取り入られるの出ないでしょうか。
例えばRedshiftでは多くの自動化が取り入れられおり、次のスライドに記載がある通り、以前は非常に難しい調整を強いられたWLMの設定やバックグラウンドでのVacuumの自動実行、分散キーの設定が自動化する等、大きく進歩しています。
※実はDynamoDBと同期で10年選手であり、Aurora, Neptune, DocmentDB, OpenSearch Service等のサービスよりも歴史が長いです
Amazon Redshift evolution history and future direction/redshift-evolution-2021-en
Aurora, Neptune, DocumentDB等の他のDBサービスでは機能の追加や性能の改善、Serverless化等で手が回っていないのかもしれませんが、Redshiftのような高度な自動化が順次取り入れられるのではないでしょうか。
例えばインデックス付与/削除の自動化は他のDBサービスでは実績があるようですし、セッション毎のワーキングメモリ容量の設定やメンテナンス系のタスクはもっとインテリジェント化されてもよいように思えます。
2. zero-ETLを実現できる範囲の拡大
恐らく一番要望が多かったとみられるAuroraからRedshiftへのデータの取り込みがまずはzero-ETL化されましたが、他のDBサービス間のデータの連携も順次zero-ETL化がとり入れられるのではないでしょうか。
例えばDocumentDB/DynamoDBからRedshift/OpenSearch Service/Neptuneへの取り込みは需要がありそうです。
3. アクセスするエンドポイントの統合
現状のzero-ETLや手動のETLでは、アプリケーション側で個別のDBサービスに対応したドライバーを用意し設定なども実施する必要があります。
加えて実際にアクセスする際にも明示的に利用するドライバーを指定する必要があります。
これらのドライバーの管理は負担なので、最終的には単一のData API(可能であればクエリ言語)でアクセス可能な形を目指すのではないでしょうか。
オーバーヘッドの問題やプロトコル、機能の差分から完全な統合は実現が難しい可能性もありそうですが、例えばAurora PostgreSQLでRedshiftとのzero-ETLが実現した際に、RedshiftへアクセスするためのFDWを自動生成することは特に難しくないと思われます。