DynamoDBのベストプラクティス的なパターン
High Scalability - High Scalability - DynamoDB Talk Notes and the SSD Hot S3 Cold Pattern
＝＝＝＝
Amazon DynamoDB for Developersトークに参加する前の、DynamoDBに対する印象は、シンプル・速い・スケーラブル・地理的冗長性・使うには高い・運用不要、という、Amazonのいつもの品質のサービスだった。
トークの後、印象はより微妙(nuanced)になった。品質の印象はそのまま。フォーラムを見れば、すべてのプロダクトに典型的な問題があることがわかるが、それは驚きではない。SimpleDBの発展版( SimpleDB++)として、DYnamoDBはセカンドシステム症候群を避けて、もっとエレガントな設計を作ったように見える。
驚いたのは、DynamoDBがとても非クラウド的だったことだ。従量課金モデルと、バーストトラフィックに対して素早く柔軟に対応するというクラウドの柱が捨てられ、DynamoDBを作る前に使い方を考える必要があることだ。
トークの中で感じたことは、、、、
- DynamoDBは Key-Valueデータの地位を明らかにした 。インターフェースは簡潔で、CreateTable, PutItem, BatchWriteItem, GetItem, Scan, Queryのように操作に一貫性がある。バッチ書き込みはトランザクションがサポートされていない。アクセスは、主キー、もしくは、ハッシュキーとレンジキーの複合で行う。データの最大サイズは64KB。スキーマレス。対応する型は、文字列型と数値型、そしてその集合(set)。読み込みは整合性有り、もしくは無しが可能で、書き込みは常に整合性有りで、整合性有りの読み込みは2倍のコストになる。
- 操作は通常10msec以下で、だいたい3-4msec。だいたいネットワークで1.5msec以下、データベース処理で1.5msec以下で、データサイズに依存する。顧客は 1-2msecの応答時間を要求するのでAmazonはストレージにSSDを使うという革命的な手段を選んだ。はじめはSSDのガベージコレクション周期に起因する性能問題があった。ベンダーとの広範な作業により問題は解決したが、知財の事情で、どのようにやったかはわかならい。
- プロビジョンスループットモデル。 DynamoDBの最も革新的な機能であり、最も不確かであり、簡潔なAppleの設計美学である。プログラマはアプリケーションが必要になるだけのデータベースへの秒間リクエスト数を指定する担当である。DynamoDBが残りを請け負う。要求された性能を実現するためにデータを自動で多くのサーバに分散する。実行中(on the fly)にレートを変更できるが、新しく要求するレートをサポートするまでには最大10分必要になる。
- 騒音隣人問題を解決する。クラウドの問題は、うるさい隣人が他の隣人の性能に影響を及ぼす可能性があること。DynamoDBがマルチテナント環境でSLAを順守するために、格納する値の最大サイズ64KBという制限を設けた。更に、1KBのデータを1回読み(書き)するのを Read/Writeキャパシティの単位としてリクエストが課金される。データサイズを固定し、スループットレートを保証するための仕様を決めるすることで、負荷をスケジュールために必要な情報を得た。
- 従量課金ではない。プロビジョンスループットモデルの反面、実際に発生したトラフィックに対して支払う代わりに、確保したスループットに対して支払うことになる。Amazonの見方(perspective)だと、キャパシティを確保しているのだからある程度キャパシティを使っている、ということだが、クラウドの弾力的な素性が生み出すキャパシティ計画問題が同じように発生する。正しいスループットをどうやって弾きだすか？下回れば、顧客を失う。上回ればお金を失う。トラフィックがバーストしがちなら、ピーク時のスループットで年中確保しなければならない。スループットを調整できるが、バーストに合わせられるほど素早く調整できないし、drop通知のメカニズムもイケてなく(clumsy)て、メールでアラートを受け取ったら手動で調整する必要がある。
- イケてる機能たち。 DynamoDBは、インクリメント操作と CAS( compare-and-swap)をサポートしており、両方ともとても便利である。
- 運用不要(NoOp)ではない。開発者を助けるために腕利きは残る。 DynamoDBの運用は残るが、領域が違ってくるだろう
-
- トランザクションが無い。開発者は冪等性(idempotency)、ガベージコレクション、その他DynamoDBがサポートすべき機能を実装する必要がある。例えば、セカンダリインデックスや検索がサポートされておらず、難しく、直接システムがサポートされt無いのであれば実装にエラーが入りやすくなる。
- ホットキー・ホットパーティションがサポートされてない。プロビジョンモデルは自動ではないので、ホットキーも自動で負荷分散しない。特定のキーやパーティションに対する読み込みが大量にあると、プログラマーがその問題を修復する必要があり、DynamoDBは何もしない。NoOpは通用しない。
- バックアップをサポートしていない。データをバックアップするには、Hadoopを使う必要がある。これは解決される問題らしいが、現時点では抜けている。
- 64KB以上のデータ。 64KB以上のデータを保存するトリックは、スループットの性能低下を引き起こす。
- データ閲覧にHiveを使う。 DynamoDBは巨大なデータ集合をターゲットにしているので、データを見るには Hadoop/Hiveを使う。そのうち、より便利な機能がダッシュボードに実装されるだろうが。。
ホットデータはDynamoDBにコールドデータはS3に、そして同じように見るためにHadoop/Hiveを使え
最も興味深い考えの一つは、DynamoDBとS3をつなぐ新しいエコシステムとしてHadoop/Hiveがとても機能しているということ。DynamoDBに保存されているデータのコストはS3よりも10倍高いので、古いデータやコールドデータはできる限りS3に移してほっとデータのみDynamoDBにおいておきたい。例えば、時系列データはだいたい、日・週・月単位で保存されるが、すべてのデータをDynamoDBに保存するのではなく、S3に移してコストを削減する。
問題は、データにアクセスする方法が大きく異なること。DynamoDBは純粋にテーブル経由のプログラム的アクセスだが、S3はファイル経由である。コードの修正を少なくしてどのようにこの差異を埋めるか？
EMRとHiveの洗練されたクエリを使うことでDynamoDBとS3のデータを共通のアクセスレイヤで実行可能になる。強力なエコシステムを提供する上でこのようにツールが使えることは良い例になる。
