you know somethig?

Use it for myself.

あなたの知らない DynamoDB の世界

はてなブログ初ポストです。よろしくお願いいたします。

さて、実は「とある機能の API サーバ」を書かねばならないことになってしまって、DB に何を使ったものかと、あれこれ悩んでおりました。そんな最中に突如登場した Amazon さん本家の KVS。放って置く訳にも参りますまいw

そんなこんなで、年初早々の発表以来、暇さえあれば、ず~っと打ち込んでいる日々でありまして、以下に、ここ一ヶ月の取り組みを備忘録代わりとして、まとめてみました。


ライブラリ

やはり公式が一番安心です。ドキュメントの存在。きちんと動作すること。などなど、やはり初物でありますので、現状では OSS との差は歴然です。

私の利用可能言語の中で API サーバに一番向きなのは Erlang だったので、こちらで行きたかったところなのですが、ライブラリがまだまだ試験レベルを脱しておりません。

さりとて自作していては時間も掛かりますので、今回は泣く泣く(失礼!> AWS の中の人) AWS SDK for Java を利用させていただくことにしました。


開発環境

Eclipse 上で開発しています。AWS Explorer などの補助ツールも Plug-in と同時にインストールされますので、取りあえず無難な選択肢だと思います。

また、フレームワークは Play! を採用しました。

  1. Javaフレームワークであること(当然ですねw)
  2. 過去に開発経験が有ったので、新規に覚えることが何も無いこと(大事ですねw)
  3. クラウドの性質上、いずれ非同期処理が必要になると想定されたこと

の三点が理由です。現在は DynamoDB に慣れることが最優先なので、非同期処理に手を付けるのはまだ先ですが...(^^ゞ

ちなみに、API のインターフェースには Thrift を採用しました。理由は... とにかく楽!これに尽きますw


ご料金

学習が進んで参りますと、目新しさだけだった幸せな時期も終わり、いよいよ本格的な開発と現実的な採算を考えねばなりません。

SimpleDB の事例ではありますが、こちらを拝見しておりますと、予想の 10倍近いご料金が掛かったことが書かれておりました。

対象が異なりますので、一概に比較できることではありませんが、さりとていささか心配なってしまい、Account Activity を見てみると...

なんと!課金されているではありませんか?! 確か...

AWS無料使用枠の中で利用できます。100MBのストレージ、5ライト(書込み)/秒、 10リード/秒(強一貫性 - strongly consistent reads - の場合) もしくは20リード/秒(結果整合性 - eventually consistent read - の場合)が無料になります

【AWS発表】 Amazon DynamoDB - インターネット時代のアプリケーションのために設計された高速でスケーラブルなNoSQLデータストレージ - Amazon Web Services ブログ

とのことでしたので、確かにそのように設定していて、まだほとんど読み書きなどしていないのに課金されてしまっているのは何故だろう。もしかすると、本格的に使い始めたら超高額になってしまうのではないか?と、正直申し上げて、不安になってきました。

結局、あちこちで足掻いているよりも、さっさとご本家で伺うのが早いだろう、と、疑問点をフォーラムで質問させていただきました。


また、ご料金については、メールでご返答をいただくことができました。
(ご返答くださったご担当の方、またご翻訳してくださった方にこの場を借りて御礼申し上げます。<返答者は英語圏の方のようですので翻訳者がいらっしゃるようです>)

特に、後のメール内容が秀逸で、ようやく子細を理解することができました。そこで、私なりに理解できた範囲で以下に述べさせていただきます。もし誤りなどがありましたら、ご指摘などを頂けると大変ありがたいです。


まず結論から申し上げますと、私は、か・な・り、勘違いしておりました。DynamoDB は従前の AWS のサービスと違って時間貸しでも、容量貸しでもありません。

もちろん、ストレージ容量やデータ転送量に応じて課金されますので、従来型のサービス同様容量貸しでもあるのですが、DynamoDB の課金のハイライトは、肝である SSD の能力を予約するところにあります。つまり、DynamoDB は

  • 予約した容量に基づいて 1時間ごとに定額が課金される
  • したがって、テーブルを作成すること、即ち能力を予約していれば課金が発生する
  • データの読み込み・書き込みを実際に実行したかどうかは関係無い

ということなります (上記質問の Q2)。例えば、

  • 東京リージョンで
  • 1ヶ月間に
  • 読み込みユニットを 5
  • 書き込みユニットを 5

を予約する場合は...

  • READ: (24h × 31d) × (5 read/s × 1kb) × ($0.012 ÷ 50u) = $0.8928 ≒ $0.89
  • WRITE: (24h × 31d) × (5 read/s × 1kb) × ($0.012 ÷ 10u) = $4.464 ≒ $4.46

という計算になります。また、上記無料枠 (5 write/s, 10 read/s) を 1ヶ月間 (お支払い期間) のユニット数に置き換えると...

  • READ: (24h × 31d) × (10 read/s × 1kb) = 7,440unit
  • WRITE:(24h × 31d) × (5 read/s × 1kb) = 3,720unit

となり、これらが固定値として Account Activity の表示に現れている、ということだったのです (上記質問の Q3)。


ちなみに、ユニットとは、転送できるキャパシティ・どれぐらいデータを転送できるかというリミットのことです。ここが肝だったのですが、ユニット料金はどれだけデータを転送していたかとは関係ありません。データ転送量は別途課金されることになるのです。

したがいまして、全体のご予算を掌握するために、後は、実際に DynamoDB 上に構築するサービスで利用するデータ量を想定するだけです。また、この部分は Amazon さんとは関係無い自分たちの領域となりますので、適切に計算することができると思います。

当初は恥ずかしながら、データ量とスループットをゴチャ混ぜに捉えて何やら無茶苦茶なご料金計算の末に高額なご料金として算出してしまっていました(上記質問の Q4)。

しかしながら、こういうお話しであれば、それほどビックリするようなご料金でもありませんし、よくよく考えますと利用データ量さえ押さえておけば、ご料金を非常に予測しやすい価格体系になっているのだなぁ、というのが改めての感想であります。


GAE とは異なり「どんなデータでもイラッシャーイ」という KVS ではありませんが、ハッキリとした「能力」を切り売りしていただいた上で、BigTable に匹敵する超弩級のスケールが手に入る訳ですから、利用価値は大変高い、と感じ始めています。

まだまだ初物でありますから、素晴らしい活用法からバッドノウハウまで、皆さんで色々と共有していくことができるとイイですね。では、また。

© 2012-2014 toomore_such