「無制限にスケール、高速で安定したスループット」

Amazon Web Services、新たなNoSQLデータベースサービス提供開始

2012/01/19

　米Amazon Web Servicesは1月18日（米国時間）、NoSQLデータベースサービス「Amazon DynamoDB」のベータ提供を開始したと発表した。AWSのCTOであるヴァーナー・ヴォーゲルズ（Werner Vogels）氏は同氏のブログで、「Amazon DynamoDBはAmazon.comのための大規模ノンリレーショナル・データベース構築、そしてAWSにおける高度にスケーラブルで信頼性の高いクラウド・コンピューティング・サービスについてわれわれが学んできたことすべての結果だ」と書いている。

　DynamoDBは、物理的なインフラを完全に抽象化したNoSQLデータベースサービス。AWS management Consoleから容易にテーブルを作成でき、スループットはリクエストに応じて向上、データセットのサイズに制限はない。DynamoDBではSSDを採用するとともに、単一のテーブルのデータとトラフィックを多数のサーバに分散するため、高速で安定したスループットを確保できるという。また、データは最低3つのデータセンターに複製するため、耐障害性にも優れるという。

　ヴォーゲルズ氏はブログで、同社のこれまでのNoSQLデータベースサービスであるSimpleDBは成功していたものの、限界があったと下記のように記している。

ドメインのスケーリングに関する制限

SimpleDBでは、顧客はデータセットをDomainと呼ぶコンテナで管理するが、これにはスレージ容量（10GB）とリクエスト・スループットの点で限界があった。多数の顧客はSimpleDBのスケーリングに関する制限を回避するため、多数のDomainにワークロードを分割したが、この点ではSimpleDBはシンプルではなかった。また、NoSQLソリューションを求める多くの顧客にとって死活的に重要な、漸次的な拡張の要求に応えることができなかった。

パフォーマンスの予測可能性

SimpleDBは、シンプルにするという目標に沿って、domainに保存されたアイテムのすべての属性をインデックスする。これはスキーマの設計における顧客体験をシンプル化し、柔軟なクエリを可能にするが、パフォーマンスの予測可能性に負の影響を与える。例えば、データベースへの書き込みでは、基本レコードだけでなく、すべての属性インデックスを更新する必要がある（クエリにすべての属性を使うかどうかにかかわらず）。同様に、Domainは大量のインデックスを維持するため、ワーキングセットが必ずしもメモリに収まらないことがある。特にデータベースのサイズが拡大すると、これがDomainの読み出し遅延の予測可能性に影響を与える。

一貫性

SimpleDBの当初の実装は「最終的には一貫性を確保できる」というアプローチを追求し、一貫性ウインドウは1秒までとなっていた。これが意味したのは、システムが直感的に使いにくく、従来型のデータベース・ソリューションに慣れた開発者にとって、適応するのに骨が折れるということだった。SimpleDBのチームは最終的に、特定の読み出しオペレーションについて、強い一貫性か最終的な一貫性かを顧客が指定できるようにすることで、この問題に対処した。

料金に関する複雑さ

SimpleDBは「Machine Hours」という非常にきめの細かい料金体系を導入した。ほとんどの顧客は最終的にコストをどのように予測するかを体得したが、これはあまり透過的でもシンプルでもなかった

　ヴォーゲルズ氏によると、DynamoDBは数年前に同社が論文を発表した「Dynamo」という技術に基づくサービスという。

　DynamoDBではテーブルが固定的なスキーマを持たず、各アイテムが属性をいくつでも持つことができる。すべての属性をインデックスすることなく、書き込みではプライマリキー・インデックスのみを更新する。現在のところ、プライマリ・キーについてはHash Key、およびHash KeyとRange Keyの組み合わせの 2種を利用できるという。後者ではハッシュ属性とレンジ属性の組み合わせでプライマリ・キーを作成できる。

　料金は、ストレージ利用量、および読み／書きそれぞれのスループットによって決まる。ストレージは1GB当たり0.01ドル。読み書きについては、最大1KBのアイテムを1秒に1回書き込む（あるいは読み出す）オペレーションを1ユニットとし、書き込みについては10ユニット当たり0.01ドル／時、読み出しについては50ユニット当たり0.01ドル／時としている。現在のところ、ベータ版としての提供となる。

{2012/01/19訂正}当初「読み／書きそれぞれのリクエストの量によって決まる。」と記述していましたが、誤りでしたので「スループットによって決まる。」に訂正しました。