Amazon DynamoDB、それはAmazon.comとAmazon Web Servicesでの経験すべてを結集して生まれた、次世代のNoSQLデータベースサービスだ。2000年始め頃、Amazon.comのサービスを支えるシステムは、すべてがリレーショナルデータベースの上で動いていた。「リレーショナルデータベースは、スイスアーミーのナイフのようなものです。Key-Value型のアクセスもできれば、複雑な検索もできる。分析もトランザクション処理もなんでもこなせます」―Amazon Web Servicesテクニカルアドバイザーのシャムズ・クワジャ氏は、なんでもできるリレーショナルデータベースには、Amazon.comのような仕組みを実現する上でさまざまなメリットがあったと言う。たとえばSQLが利用でき、技術者がそれを学ぶのも容易だ。
リレーショナルデータベースの拡張性問題を克復したい
とはいえ、Amazon.comのサービスが大きくなるにつれ、新たな問題も出てくる。まずは、拡張性の問題だ。パーティショニングで大規模データの処理を効率化することは、リレーショナルデータベースでもできる。しかし、実運用のまま、それを拡張するのはかなり難しい。そうなると将来を予測し、最初からかなり大きなサーバーを用意する必要が出てくる。

さらに、ピーク時に対応する処理能力確保も課題だった。「小売業では、クリスマスシーズンの需要をどう乗り切るかが課題です。その時のためだけに、サーバーを増やすのか。さらに、可用性の面でも課題がありました。たとえば、開発者が複雑なクエリーを投げてしまうと、他の処理に影響を及ぼしてしまうのです」とクワジャ氏。これらの課題を解決するためにAmazon.comで新たなシステムが構築された。それが「Amazon Dynamo」と呼ばれるシステムだった。
「これは、現在提供しているDynamoDBではありません。分散ハッシュテーブルで、Optimistic Replicationができる環境でした」という。一貫性の制約を緩めることで、大幅な拡張性と可用性の向上を実現。また、シンプルなクエリーに限定することで、パフォーマンスの予測も容易になった。この仕組みであれば、サーバーの横展開で、簡単に拡張性を確保できる。
しかしながら、Dynamoでシステムの拡張性、可用性は向上したが、アプリケーション開発者は引き続きインフラ管理者的な業務を担う必要があった。
「容易に拡張ができるようになったとはいえ、クリスマスシーズンが近づけばエンジニアはサーバーを追加し、何十台ものサーバーにシステムを展開する作業をしなければなりませんでした」(クワジャ氏)
当然ながら、監視などの運用作業も自分たちでやらなければならない。このように、Dynamoという新たな可用性と拡張性の高い環境はできたが、エンジニアの苦労は残っていた。なので現場のエンジニアからは「Dynamoというデータベースではなく、DynamoDBというサービスが欲しい」という声があったのだ。
この記事は参考になりましたか?
- この記事の著者
-
谷川 耕一(タニカワ コウイチ)
EnterpriseZine/DB Online チーフキュレーターかつてAI、エキスパートシステムが流行っていたころに、開発エンジニアとしてIT業界に。その後UNIXの専門雑誌の編集者を経て、外資系ソフトウェアベンダーの製品マーケティング、広告、広報などの業務を経験。現在はフリーランスのITジャーナリスト...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア