Amazon Web Services (AWS)は、すごい勢いで機能を増やしており、いわゆるクラウド業界の中で圧倒的な存在感を示しています。AWS ＝ クラウドと言っても過言では無いでしょう。
AWSは、他のレンタルサーバーやホスティングと比べたり、自社でデータセンターを借りるのに比べると、だいぶ割高な設定になっています。しかし、その機能は他のサービスを圧倒しています。
AWSがすごいのは、分散ストレージである
S3などの分散システムを管理不要で提供していることです。
分散システムには、耐障害性、性能(スケーラビリティ)などの点で大きなメリットがありますが、実際に分散システムを管理運用するのはとても面倒で煩雑な作業になります。弊社でも分散ストレージを自社開発運用していますが、かなりややこしく、可能な限りやりたくない作業です・・・
とくに分散システムのソフトウェア開発者と、分散システムの管理運用者が異なる場合には、ハードウェアとの相性や、ソフトウェアの細かい癖、ソフトウェアのバグなどを克服してうまく分散システムを運用するのは至難の業となります。
そのため、弊社では、わざわざ自前で分散ストレージのソフトウェアを自社開発しています。機能が少ない簡易的な自社製品の方が、機能が多くて挙動が完全に把握できない他人の作品よりもマシだからです。
その点で、自前でソフトウェアを開発し、サービスを自前で運用しているAmazon Web Servicesは、分散システムの理想型と言えます。これができる企業は、世界でも多くはないでしょう。
Amazonのさらなる強みは、Salesforceのようなエンタープライズ業界の企業と違って、ずっとセンスの良いAPIや使い勝手の良いUIや分かりやすいドキュメントを提供していることです。
さて、本題に移ります。
先日登場したAmazon
DynamoDB (分散NoSQLデータベース)には私も強い興味を抱いており、このたびAmazonが開催したDynamoDBセミナーに参加してきました。そこから得たDynamoDBの情報と印象をお伝えしたいと思います。
私はMongoDBなどの既存のNoSQLには極めて懐疑的な見方をしていました。先述のように、分散システムを運用し、期待通りの性能を安定してたたき出すにはかなりの苦労が伴います。それを考えると、どうしても極めて高いスケーラビリティの必要なソーシャルゲーム業界など以外では有用性はないだろうと考えていました。
しかしDynamoDBは違います。テーブルを作成し、必要なスループット(毎秒の読み書き数)を設定するだけで、勝手に分散データベースを自動で作成・運用してくれます。スループットはリアルタイムに変化させることも可能です。これなら何の苦労もなく分散データベースを運用することができます。
DynamoDBの特徴は、極めて簡単な運用、驚愕のスケーラビリティ(高い書き込みスループット)、高可用性の３つです。スケーラビリティは驚くほどで、最高で、秒間200万リクエストの実績があるそうです。データは自動的にリージョン内の3つのデータセンターにレプリケーションされ、高い可用性を誇ります。
DynamoDBの弱点は、現時点では機能がめちゃくちゃ限られていることです。複雑なクエリはもちろんのこと、テーブルにプライマリキー以外のインデックスを貼ったり、バックアップを取ったりする機能すら標準では備わっていません。なんとデータ型も、整数と文字列とそれらの集合の4種類しかありません。
複雑なクエリを実行したり、バックアップを取ったりするためには、Elastic Map Reduce (Hadoop)を利用して、Hiveというクエリマネージャを使ってクエリを実行する必要があります。これははっきりいってややこしいです。
しかしワークショップに参加して、実際にコーディングをして使ってみて思ったのは、実際には意外と色んな用途に使いやすいかもしれないということです。
EC2から同リージョンのDynamoDBにアクセスする場合、レイテンシは極めて短く、データも高速に転送されます。そのため、誇張気味に言うと、ローカルにあるファイルのような感覚で扱うことができます。これなら、小規模システムの場合は、インデックスなど使わずとも、フルスキャンを多用しちゃってもいいのかな、と思いました。
かなり曲者で使いこなしが難しい印象のDynamoDBですが、既にかなり導入実績があり、どんどん売上が伸びているそうです。ソーシャルゲームなどの業界にとっては福音と言えるのでしょう。
将来的に、二次インデックスがサポートされ、データ型もいろいろと実装されてきて、複雑なクエリをうまく実行できるライブラリなどがでると、ソーシャルゲーム業界に限らず、一般のシステムも一部はこれで置き換えられていくのではないかなと思います。RDBMSの運用はいささか面倒ですからね。
EC2, S3, DynamoDB, Cloudfrontの登場によって、スケーラビリティや高可用性を実現するということはお金さえ払えば誰にでもできる仕事になってしまったな、という印象です。
弊社としても、今後はAWSの使いこなしに力を入れていこうと考える次第です。
ところで、Amazonワークショップ内で、2時間で「並列的にニコニコ動画のタグをクロールして集計するスクリプト」を書いたので、おまけとして以下に乗せておきます。DynamoDBの並列性を確保する機能であるConditional PutとAtomic Counterを活用することで、簡潔に並列集計を実現しています。
require 'uri'
require 'net/http'
require 'kconv'
require 'rexml/document'
require 'rubygems'
require 'aws-sdk'
AWS.config({
:access_key_id => "",
:secret_access_key => ""
})
dynamo_db = AWS::DynamoDB.new(:dynamo_db_endpoint => "dynamodb.ap-northeast-1.amazonaws.com")
videos = dynamo_db.tables["nicovideo_videos"]
videos.load_schema
tags = dynamo_db.tables["nicovideo_tags"]
tags.load_schema
# タグ収集、カウント
loop {
vid = (rand * 17392999).to_i
video_id = "sm#{vid}"
puts video_id
begin
url = URI.parse("http://ext.nicovideo.jp/api/getthumbinfo/#{video_id}")
http = Net::HTTP.new(url.host, url.port)
result = http.get(url.path)
xml = REXML::Document.new(result.body)
next unless xml.elements['//title']
title = xml.elements['//title'].text
puts title
videos.items.put({"video_id" => video_id, "title" => title},{:unless_exists => "video_id"})
xml.elements.each('//tag') { |tag|
tag_name = tag.text
puts tag_name
t = tags.items.put({"tag_name" => tag_name, "count" => 1}, {:unless_exists => "tag_name"}) rescue nil
unless t
t = tags.items.at(tag_name)
t.attributes.add({"count" => 1})
end
}
puts "\n\n"
rescue Exception => e
p e
end
}
# 集計
rank = {}
tags.items.select { |tag|
count = tag.attributes['count'].to_i
tag_name = tag.attributes['tag_name']
# puts "#{count}: #{tag_name}"
rank[count] ||= []
rank[count] << tag_name
}
rank.keys.sort[-10..-1].reverse.each_with_index { |count, i|
puts "#{count}件: #{rank[count]}"
}
