Agile Cat — in the cloud

DynamoDB Talk Notes and the SSD Hot S3 Cold Pattern
http://wp.me/pwo1E-4Cy
Monday, May 14, 2012
http://highscalability.com/blog/2012/5/14/dynamodb-talk-notes-and-the-ssd-hot-s3-cold-pattern.html

My impression of DynamoDB before attending a Amazon DynamoDB for Developers talk is that it’s the usual quality service produced by Amazon: simple, fast, scalable, geographically redundant, expensive enough to make you think twice about using it, and delightfully NoOp.

Amazon DynamoDB for Developers トークに参加する前に、私が持っていた DynamoDB の印象は、Amazon が提供する通常品質のサービスであるというものだった。 つまり、シンプル／高速／スケーラブル／地理的冗長性／再び利用しようと思わせる価格／とても面白い NoOp などである。

After the talk my impression has become more nuanced. The quality impression still stands. Look at the forums and you’ll see the typical issues every product has, but no real surprises. And as a SimpleDB++, DynamoDB seems to have avoided second system syndrome and produced a more elegant design.

そして、そのトークを聞いた後、私は微妙な印象を持ち始めた。 品質に関する印象は、依然として変わらない。このフォーラムに注目すれば、すべてのプロダクトが持っている典型的な問題が判るだろうが、それが本当の驚きというわけではない。 そして、SimpleDB++ としての DynamoDB は、2番目のシステム･シンドロームを回避し、さらにエレガントなデザインを生み出したように思える。

What was surprising is how un-cloudy DynamoDB appears to be. The cloud pillars of pay for what you use and quick elastic response to bursty traffic have been abandoned, for some understandable reasons, but the result is you really have to consider your use cases before making DynamoDB the default choice.

驚くべきことは、いかに DynamoDB が、非クラウド的だと思えるかという点である。つまり、クラウドの中心に置かれるものは、使ったものに対する支払いであり、また、爆発的なトラフィックに対して、迅速かつエラスティックに反応するものだという要件が、いくつかの理解できる理由により捨て去られている。しかし、そこに結論があるのではなく、ディフォルトとして DynamoDB を選択にする前に、誰もが自身のユース･ケースについて、真剣に検討しなければならない点にある。

Here are some of my impressions from the talk…

このトークに対する、いくつかの、私の印象を以下にまとめる…

• DynamoDB is a clean well lighted place for key-value data. The interface is simple, consisting of operations like CreateTable, PutItem, BatchWriteItem, GetItem, Scan, Query. Transactions are not supported in the batch write. Access is by a primary key and Composite Hash Key / Range Keys. The max size for data is 64KB. It’s schemaless. The supported type are string and numbers and sets of strings and numbers. Reads can be consistent, or inconsistent, writes are always consistent, consistent reads cost 2x more.
  
• DynamoDB is a clean well lighted place for key-value data. インタフェースはシンプルであり、CreateTable／PutItem／BatchWriteItem／GetItem／Scan／Query といったオペレーションより構成される。 Transaction は、バッチ記述ではサポートされない。 Access が主キーであり、Composite Hash Key／Range  Keys がある。 データのための最大サイズは、64 KB である。 スキーマレスである。 サポートされるタイプは、String と Number であり、この２つの組み合わせも可能である。 Read は、コンシステント／非コンシステントを選べるが、Write はコンシステントのみである。 なお、コンシステント Read のコストは ２倍以上になる。
  
• Operations are usually under 10 msecs, typically 3-4 msecs. Typical is ~1.5 msecs for the network path and ~1.5 msecs for the database component, depending on the size of your data. Customers wanted one or two millisecond response times so Amazon took the radical step of using SSD for storage. Initially they ran into performance problems due to SSD garbage collections cycles. Extensive work with vendors solved the problem, but because of IP issues we have no idea how.
  
• Operations are usually under 10 msecs, typically 3-4 msecs. 一般に、ネットワーク･パスに ～1.5 msecs を要し、データベース･コンポーネントに ～ 1.5 msecs を要するが、それぞれのデータサイズに依存するものとなる。 顧客たちが 1～2 msecs を要求したため、Amazon はストレージに SSD を用いるという、急進的な対応を取っている。 当初、SSD のガーベジ･コレクション･サイクルに起因する、パーフォマンス上の問題に遭遇している。 ベンダーと協調した大規模な作業により問題は解決したが、IP 問題については、どのように処理したのか分からない。
  
• Provisioned throughput model. This is the most innovative feature of DynamoDB and its most problematic, taking the “make it simple” Apple design aesthetic to 11. Programmers are in charge of specifying the number of database requests per second their application should be capable of supporting. DynamoDB does the rest. It automatically spreads data over the number of servers required to provide the desired performance. You can change the rate on the fly, but the catch is it can take up to 10 minutes for the system to support the new request rate.
  
• Provisioned throughput model. これは、DynamoDB における最もイノベイティブな特徴であり、また、最も解決の困難な問題でもある。 それは、Apple の Ver 11 へ向けた、審美的な “make it simple” デザインにも通づる。 プログラマーは、自身のアプリケーションがサポートすべき、毎秒あたりのデータベース･リクエスト数を指定するという責任を持つ。 そして、その残りは DynamoDB が処理していく。 そして、必要なパーフォマンスを提供するために、大量のサーバーに対して、自動的にデータを展開していく。その比率は On The Fly で変更できる。 しかし、システムが新しいリクエスト･レートをサポートするには、最大で 10 分を要することがある。
  
• Solving the noisy neighbor problem. A problem with the cloud is noisy neighbors can ruin the performance of other neighbors. To ensure DynamoDB can meet SLAs in a multi-tenancy environment, a maximum size restriction of 64KB is put on values. In addition, requests are priced in units of Read/Write Capacity equal to one read (or write) per second of capacity of 1KB in size. By fixing the data sizes and requiring the specification for a guaranteed throughput rate, DynamoDB has all the information it needs to schedule workloads in such a way as they can meet their SLAs with a high degree of confidence.
  
• Solving the noisy neighbor problem. クラウドにおける問題は、ノイジーな隣人のせいで、パフォーマンスを台無しにされる可能性である。 マルチ･テナント環境において、DynamoDB の SLA クリアを保証するために、最大で 64KB の制限が価値を与える。 それに加えて、 Read/Write Capacity のユニットで定められたリクエストの料金は、1KB の容量を 毎秒 1 Read（もしくは 1 Write）を実行するケースに等しくなる。 データ･サイズを固定し、また、保証されたスループット･レートを指定することで、DynamoDB は ワークロードのスケジューリングに必要な全情報を取り込み、高度な信頼性で SLA に合致させさていく。
  
• Pay for what you don’t use. A downside of the provisioned throughput model is you pay for the throughput you have reserved, not the traffic you have actually generated. From Amazon’s perspective they are reserving the capacity so in a sense you are using the capacity, but this is the same capacity planning issue that made the elastic nature of the cloud so attractive to begin with. How do you specify the correct throughput? If you underspecify you lose customers. If you over specify you lose money. And if your traffic is at all bursty you technically would have to reserve the peak usage, which is fiscal insanity. You can adjust your throughput reservation, but you can’t do it fast enough to meet a burst, and the drop notification mechanisms are clumsy, you get an email alert and then have to do the adjustment by hand.
  
• Pay for what you don’t use. プロビジョニングされたスループット･モデルの欠点は、実際には自分で生成していないトラフィックに対しても、リザーブされたスループットに対して支払いが生じる点である。 Amazon の視点から見ると、ユーザーが容量を用いているという面で、その容量がリザーブされていることになる。 しかし、それは、エラスティックという魅力的なクラウドの性質にも通ずる、キャパシティ･プランニングにおける共通の問題でもある。適正なスループットを、そのように指定するのか？ 過小に指定すると、顧客を失う。 過大に指定すると、コストを失う。 そして、すべてのトラフィックが突発的なものなら、そのピークに合わせてリザーブが必要になるだろうが、それは、会計的に破綻している。スループットのリザーブに関しては調整が可能であるが、突発的なピークに対して迅速に対応することは困難である。そして、劣化のノーティフィケーション･メカニズムは不器用であるため、電子メールによる警告に気を配らせて、また、マニュアルで調整をしなければならない。
  
• Some cool features. DynamoDB supports both an increment operation and compare-and-swap, both of which are quite useful.
  
• Some cool features.  DynamoDB は、Increment Operation と Compare-and-Swap をサポートするが、どちらも、きわめて有用である。
  
• Not NoOp. Hard stuff is left for developers to solve. You’ll still have operations with DynamoDB, it will just be in different areas.
  
• Not NoOp. Hard stuff is left for developers to solve. 依然として、DynamoDB ではオペレーションが必要であるが、それは少し異なるエリアでのものとなる。
  
• A lack of transactions means developers have to implement idempotency, garbage collection, and pay for all the accesses needed to implement features that DynamoDB should be supporting. Secondary indexes and search are not supported, for example, and are difficult and error prone to implement without direct system support.
  
• A lack of transactions. デベロッパーはガーベジ･コレクションをベキ等で実装し、DynamoDB がサポートするはずの機能に対して、実装で必要とされる全アクセスに対応しなければならない。 たとえば、セカンダリ･インデックスとサーチがサポートされていないが、ダイレクトにシステムをサポートすることなく、実装することは困難であり、また、エラーを起こしやすい。
  
• Hot keys / Hot partitions are not supported. The provisioning model is not really automatic as hot keys are not automatically load balanced. If a lot of reads are going to one key or partition it’s up to the programmer to fix the problem, DynamoDB won’t do it. The NoOp promise falls a little short here.
  
• Hot keys / Hot partitions are not supported. ホット･キーが自動的にロード･バランスされないようにするため、このプロビジョニング･モデルの自動化は、実際のところ達成されていない。 多数の Read が 1つのキーやパーティションに対して行なわれる場合には、その問題の解決はプログラマに委ねられ、また、DynamoDB が対応することはない。 NoOp の約束は、ここでは充分とはいえない。
  
• Backups not supported. To backup data you have to use Hadoop. This is a problem that will likely be fixed, but it’s a hole for now.
  
• Backups not supported. データのバックアップには、Hadoop を使う必要がある。 これは、これから修正される問題点であるが、現時点では弱点である。
  
• > 64KB. Tricks to store data greater than 64KB without transactions invite corruption and impacts throughput.
  
• ＞64KB. トランザクションを壊すことなく、また、スループットに影響を与えることなく、64KB 以上のデータをストアするためのトリックである。
  
• The Intellectual Property shield. The talk was annoying at certain points because the IP excuse was used to not answer certain questions. Is, for example, hinted handoff used? Sorry, that’s IP. An advantage many other products have is that they are open. If you want to know something about Cassandra, VoltDB, Riak, Redis, MongoDB, etc, you’ll get the straight dope.
  
• The Intellectual Property shield. いくつかの質問に対して、IP だからという言い訳が用いられたことが、いらだちの種になった。たとえば、Hinted Handoff は使われているかという質問に、 すみません IP ですと、切り返される。 数多くのプロダクトが有するアドバンテージは、それがオープンであることだ。もし、Cassandra／VoltDB／Riak／Redis／MongoDB などについて何かを知りたいのなら、本当の情報が得られるだろう。
  
• Limited to a single region. Several questions were about the need to operate across multiple regions, but if Amazon built this feature in it would become a SOP, so Amazon quite rightly stays out of the multi-region business.
  
• Limited to a single region. マルチ･リージョンをまたいだ運用について、いくつかの質問があったが、そのための機能を Amazon が構築するなら、それが SOP（Standard Operating Procedure）になるだろう。 したがって、Amazon は慎重であり、このマルチ･リージョン･ビジネスに立ち入らないようにしている。
  
• Use Hive to browse data. DynamoDB is targeted at large data sets so you need to use Hadoop/Hive to take a look at the data. Eventually more functionality will be built into the dashboard, but it’s a powerful way to look at your data, just factor this kind of management traffic into your throughput requirements.
  
• Use Hive to browse data. DynamoDB は、広大なデータセットをターゲットにしているため、データを参照するために、Hadoop/Hiveを用いる必要がある。 最終的には、より多様な機能がダッシュボードに組み入れられ、データ参照のためのパワフルな方式が実現されるが、それが、スループット要件におけるトラフィック管理の要因となる。

Store Hot Data in DynamoDB, Cold Data in S3, and use Hadoop/Hive to Make them Look the Same

One of the most interesting ideas of the talk is how a new Hadoop/Hive ecosystem is being used to act as a unifying bridge between DynamoDB and S3. The idea is that data stored in DynamoDB costs 10 times as much as data in S3, so what you want to do is move historical or cold data to S3 as soon possible and just keep the hot data in DynamoDB. For example, time series data is often stored by day, week, or month, so rather than keep all that historical time series data in DynamoDB, move it to S3 and save some money.

このトークで、面白しろかったものに、DynamoDB と S3 を統一するブリッジとして、どのように Hadoop/Hive エコシステムが役割を果たすかというアイデアがあった。この発想は、DynamoDB コストにストアされたデータは、S3 と比べて 10倍のコストが必要というところから始まる。したがって、何を行いたいかといえば、ヒストリカルなコールド･データを、可能な限り早期に S3 へと移行させ、ホット･データは DynamoDB の保持し続けることだ。 たとえば、時系列データは大半のケースにおいて、日／週／月の単位でストアされる。 したがって、すべてのデータを DynamoDB に保持し続けるより、S3 に移動したほうがコストを抑えられる。

The problem is now you have two very different ways to access data. DynamoDB is purely programmatic access via tables and S3 is via files. How do you bridge that gap without writing a lot of code?

現時点の問題は、データにアクセスするための、きわめて異なる 2つの方式が存在することだ。 DynamoDB はテーブルを介して、プログラムでピュアにアクセスするが、S3 はファイルによりアクセスする。 大量のコードを書くことなく、どのようにして、このギャップをブリッジするのか？

Using EMR and Hive sophisticated queries can be run against data in DynamoDB and S3, allowing a common data access layer against the cheapest storage option. It’s a good example of how well all these tools work together to provide a powerful ecosystem.

EMR と Hive を用いる洗練されたクエリーを、DynamoDB と S3 に対して実行できる。それにより、最も安価なストレージ･オプションに対する、共通のデータ･アクセス･レイヤーを実現する。 それは、パワフルなエコシステムを提供するために、すべてのツールを協調させるという意味で、最適な事例となるだろう。

ーーーーー

さすが High Scalability、さすが Todd Hoff さんという感じの記事です。このコンテントの翻訳は、理想のストレージを追い求める DynamoDB のコンセプトを勉強しながら、ストレージの難しさも同時に理解するという、とても貴重な体験でもありました。5月から、翻訳リストに入ってはいたのですが、なかなか手を付けられずにいました。 暑くて暇だった、今年のお盆休みの成果です James Hamilton 先生の「Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚」も、あわせて ど～ぞ。 ーーー

ーーーーー

＜関連＞

Amazon が通り過ぎた後に、どれだけのクラウドが生き残れるのか？
AWS S3 にストアされる Object が [ １兆 ] を超えた
AWS と Rackspace の間で、クラウド･バーストを実験する！
トップを快走する AWS と、それを追いかける 7人の チャレンジャー
NASA は OpenStack を捨て、Amazon に乗り換えたのか?