AWS re:Invent2013参加レポート #31 ひと目でわかるAWSデータストアの使いどころ AWS Storage and Database Architecture Best Pracices – Japanese Track

はじめに

AWS Storage and Database Architecture Best Practices というセッションを- Japanese Trackで行ないました。講師のSiva Raghupathyさんは、DynamoDBのスペックを書いた人でもあるというとです。英語のセッションのレポートは、AWS re:Invent2013参加レポート #13 で書かれています。こちらは各サービスの使いどころをまとめていますが、これ以外の部分で勉強になったデータストア(ストレージ、データベース)の選び方について書きたいとおもいます。

RDBMS = スイスアーミーナイフ

データベースはスイスアーミーナイフであるとのことでした。とりあえずいれておけば後からSQLでとりだせますし、トランザクションだってサポートしています。便利です。ただ、便利であるがゆえにオーバヘッドが大きかったり、半構造化データの保存に工夫が必要だったり、マシンを数百台にスケールすることが難しかったりします。無理にデータベースを使うことでコストも高くなるわけですし、必要とされるデータ保存の要件をあきらかにすることで、より低コストで高いパフォーマンスを発揮するサービスを選択できます。

データの特徴

このセッションのキーとなるスライドが3つありました。まずはデータの特徴です。 全体のサイズ、1つの要素のサイズ、遅延(レイテンシ)、耐久性、リクエストの頻度、単価という項目でHot、Warm、Coldの3種類にわけています。

どのデータストアを使うべきか

図形式がこちらです。

表形式がこちらです。

この中でAWSにだけあり、他のサービス/ソフトウェア製品に存在しないものはDynamoDBくらいですので、広く一般に適用できる考えかと思います。

シンプルですが、これを書くのは難しいですよね。講師のレベルの高さを感じるスライドでした。

セッション後の質問

幾つか質問をしてみました。

SimpleDBがなかったのですが?

SimpleDBはSQLインターフェースもあり、簡単に使えるよいサービスだが、スケイラビリティがまったくない。DynamoDBをつかって欲しい。

Elasti Cache(memcached)とRedis、どちらを使うべきか?

どちらもよいサービスだが、機能としてはRedisが多く(構造化データがもてる等)、歴史はmemcachedがあるという違いがある。歴史があるということは対応ツールも多いということなのでシステムの要件にあわせて使い分けて欲しい。サービスの安定性についてはどちらも問題ない。

英語が話せない人が質問する方法

ツアー参加でしたのでADSJの方がJapanese Tracksの中には必ずいました。上記の質問はADSJのエクマンさんに通訳していただきました。エクマンさんありがとうございました。 また、そこら中にソリューションアーキテクトがいるので、その方に質問してもよいとおもいます。このセッションではありませんでしたが、立看板でしかみたことがなかった@ar1さんと話せたのも収穫でした。

おわりに

セッションより、データの特徴によりどのサービスを使うべきかについて説明しました

re:Inventの事例を見てきて感じたことですが、スケールが大きいです。同時数万インスタンスを使うという事例がばんばん出てきます。日常業務で見ているものですと、RDBMSでまにあうものが殆どです。ただ、大きいデータの案件は増えてきているのでこれからが楽しみです。

そういえば、会期中あまりにブログばかり書いていて寝不足だったのですが一つよい点がありました。時差ボケがまったくなかったです。