Home > Amazon EC2 Archive

Amazon EC2 Archive

Amazon CloudWatch を使ってみた

Amazon EC2で、Amazon CloudWatch(インスタンス監視サービス)、Amazon Elastic Loadbalancer(ロードバランサー), Amazon AutoScaling(自動スケールアウト機構)がリリースされました。

各サービスへのリンクです。

CloudWatchはEC2上のインスタンスを監視する仕組みです。AutoScalingは、自動スケールアウトを実現する仕組みで、CloudWatchで得たデータを使用します。Elastic Load Balancingは、EC2上のインスタンスにパケットをロードバランシングする仕組みです。

これらのサービスを利用すると、負荷に応じて自動でマシンを起動する、”AutoScaling”という仕組みを作ることができます。

Continue reading

Amazon Elastic MapReduceを使ってみた

連日のEC2ネタです。本日、AmazonからElastic MapReduceというサービスがリリースされました。大規模データ処理技術が一気に民間の手に下りてくる、まさに革命的なサービスだと思います。

Elastic MapReduceは、Googleの基盤技術の一つであるMapReduceを時間単位課金で実行できるサービスです。MapReduceについては以下のエントリが参考になります。

Elastic MapReduce自体についての技術情報は以下に有ります。

概要はGettingStartedGuideでもつかめますが、ようはEC2の上にMapReduceのオープンソース実装であるHadoopを走らせ、さらに入出力としてAmazon S3を使用するサービスです。

なんと言っても値段が安く、EC2のインスタンス代 ($0.10/h per Small Instance) + MapReduce使用代 ($0.015/h per Small Instance)がコストになります。

軽く計算してみると100台を1時間使用しても、100 * ($0.10 + $0.015) = $11.5 なので、大体1000円程度で済んでしまいます。今までは大企業に入って強大なクラスタを構築してやっと使える台数が、この値段で使えてしまうのは、本当に凄いと思います。

Elastic MapReduceの中核に使われているHadoopについては僕がいくつか記事をCodeZineに寄稿させて頂いております。最近ではYahoo, Facebookはもちろん、国内では楽天さんやはてなさんも使用されているようです。

また、2009/4/23発売の「クラウド大全」という本にHadoopについての記事を書かせて頂きました。概要～使用方法までを解説した内容になっておりますので、もしよろしければ参考にして頂ければと思います。

実は、これまでもEC2上に自前でHadoopクラスタを構築する事で、Elastic MapReduceと同じ事ができました。

しかしそれと異なる点はWeb GUIからジョブを投げて必要な数のマシンを自動的に起動できたり、コマンド一発で同じ事が行える点です。

# MapReduceジョブを実行するためのコマンド
elastic-mapreduce \
  --create \
  --stream \
  --input s3n://elasticmapreduce/samples/wordcount/input \
  --mapper s3://elasticmapreduce/samples/wordcount/wordSplitter.py \
  --output s3n://mybucket/output_path

僕も簡単にですが使用してみたので、スクリーンショットと共にお届けします。以下、MapReduce・Hadoop・EC2についてのある程度の知識を前提とします。

具体的なイメージがつきやすいように、Apacheのログファイルを処理し、あるIPが何回アクセスして来たかをElastic MapReduceを使用してカウントしてみます。

まず、ApacheのログファイルをAmazon S3にアップロードします。アップロードしたS3のパスは、kazuki.ohta-bucket/hadoop/input/access.logとします。形式は以下のようになります。

114.48.132.12 - - [29/Mar/2009:06:52:59 +0900] "GET /books.html HTTP/1.1" 304 - "http://kzk9.net/blog/" "Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8"
114.48.132.12 - - [29/Mar/2009:06:53:00 +0900] "GET /public/javascript/prototype-1.4.0.js HTTP/1.1" 304 - "http://kzk9.net/books.html" "Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8"

次に、以下のようなスクリプトもS3にアップロードします。パスはkazuki.ohta-bucket/programs/ipCounter.pyとします。これがMapフェーズ用のスクリプトになります。


#!/usr/bin/python
import sys
import re
def main(argv):
  line = sys.stdin.readline()
  try:
    while line:
      print "LongValueSum:" + line.split()[0] + "\t" + "1"
      line = sys.stdin.readline()
  except "end of file":
    return None
if __name__ == "__main__":
  main(sys.argv)

HadoopはJavaで記述されているのですが、Hadoop Streamingという拡張を使用すると標準入出力が使える言語で有ればMapReduceプログラムを書く事が出来ます。

Elastic MapReduceではStreamingを使用するのが推奨されているようです。この例では、標準入力から与えられるログを一行一行処理し、以下のような出力を行います。

LongValueSum:114.48.132.12    1
LongValueSum:114.48.132.12    1
LongValueSum:127.0.0.1    1

今回はReducerにHadoop Aggregate Packageというものを用います。

このパッケージを使用すると、単純に足し合わせる・Maxを取る・Minを取るようなreducerなら、自分でスクリプトを書く必要が無くなります。ただし足すために、キーの前に”LongValueSum:”という識別子を付ける必要があるので、上のスクリプトではそうなっています。Reduce後のデータは以下のようになります。

114.48.132.12    2
127.0.0.1    1

以上でデータとプログラムが用意できたので、次はこの処理をAmazon EC2上で行ってみます。まずAWS Management Consoleにアクセスし、Amazon Elastic MapReduceのタブをクリックします。

Create New JobFlowというボタンが有るのでクリックします。ジョブ名(FlowJobName)を入力します。Typeは、今回は自分で作成したスクリプトを使用するので”Streaming”を選択します。

次に、入出力を行うS3のパスと、プログラムのパスを指定します。今回は以下のように指定しました。

  • Input Location: kazuki.ohta-bucket/hadoop/input
  • Output Location: kazuki.ohta-bucket/apacheloganalysis/ipcount-0421
  • Mapper: kazuki.ohta-bucket/programs/ipCounter.py
  • Reducer: aggregate

Output Locationは予め作成しておかなくても、自動で作成されます。Reducerにaggregateを使用しているのは、前に触れたようにHadoop Aggregate Packageを利用するためです。

次に使用するインスタンス数、インスタンスタイプを指定します。

確認画面が出るのでokを押します。

するとジョブがリストに追加され、実行が開始されます。

実際にジョブがRUNNINGの状態になるまでには、約3-5分かかります(VM、Hadoopの起動時間)。気長に終了まで待ちます。

正常に処理が終わると、kazuki.ohta-bucket/apacheloganalysis/ipcount-0421/part-0000というファイルが出来ています。これをダウンロードしてみてみると、以下のようなアウトプットが得られます。

110.0.37.132    2
113.32.139.66    21
113.32.170.52    8
113.32.65.194    4
113.33.116.81    27
114.111.35.23    2
114.111.36.31    2
114.144.157.247    5
...

今回は比較的小さめのログファイルを使用しましたが、これが数百Gになっても、それ相応のマシンを一時的に借りる事で、1時間程度でも処理する事が可能です。大量にアクセスのあるようなサービスのログ解析では早速役に立つのではないでしょうか。

また最先端の実験は必然的に大規模化するという話もありますが、大量のデータを扱う研究というのはElastic MapReduceの出現によって完全にコモディティ化してしまう可能性が有ります。アカデミックの分野でも非常に革命的だと思います。

ただ、いくつか問題も有って現状ではカウント以上の事をしようとするとHadoopの内部的な知識が必要になる事や、またジョブが失敗した時に何が悪かったのかが全く表示されないので、非常に苦心します。30回ぐらいJob Failedさせちゃいましたよ…(しかも1回5分かかるし)

この辺りが改善していけば非常に使い勝手の良いものになるのではないかと思います。Hadoopにはジョブの実行状況を見るためのWeb Interfaceが有るので、せめてここへのリンクぐらいは欲しいですね。

またストレージにS3を利用しているので、GoogleFileSystem + MapReduceの本来の良さで有るデータのローカリティを考慮したコンピューテーションが行えません。入力と出力に必ずネットワーク転送が挟まってしまいます。システムのパフォーマンスという面ではベストでは無いです。ただしS3を運用しているクラスタとElastic MapReduceを運用しているクラスタが将来的に一緒になるので有れば、性能が高まる可能性が有ると思います。

以下、EC2を色々と触って見ての所感 & 怪しい未来予想です。Elastic MapReduceには関係有りません。

7～8年前、高校生の頃にインターネットを始めて以来、Amazonは本屋さんだと思っていました。それがITインフラサービス事業会社になろうとしているのをひしひしと実感しています。価格もこれからどんどん安くなるだろうし、もうデータセンターに自前でサーバーを用意する必要性が無くなって来ているのかもしれません。

これは完全に個人的な予想ですが、Amazonの次のロードマップはAWS自体のプラットフォーム化です。これが起こると、今回のElastic MapReduceのようなアプリケーションを、個人開発者が自由に追加しユーザーに提供できるようになります。Management Consoleのタブが自由に増やせるイメージです。

開発者は、AWSアプリケーション(ec2, s3, simpledb, 3rd party, etc)をコンポーネントとして組み込んで、新しいAWSアプリケーションを提供できるようになります。その上に現在の課金の仕組みが乗っかり、開発者が利益を得られるような仕組みが登場します。

例えばSQLクエリからMapReduceが使えるアプリケーションを書いてインスタンス単位で課金できるようになったり、独自のKey-Value StoreをAWSユーザーに提供してPUT/GETオペレーション単位で課金出来たり。他にもロックサービス、分散DB、検索エンジン、分散共有メモリ、HPCシステム、Single System Image。

もっと上位レイヤを言うと、ERP・CRM・DWH・ECサイト構築パッケージ・SNS構築パッケージ・動画配信(CDN)。Windows Azure, Google AppEngine, SalesForce互換アプリなんかも登場するかもしれません。AmazonのDCが世界中に構築されれば、世界中に拠点が有るようなシステムも簡単に作れる (Akamaiみたいな)。

全てのシステムソフトウェアがAWSというプラットフォーム上で提供できる、そんな世の中になると、楽しそうですね。妄想ですけどね。しかしAmazon…恐ろしい子！今月何万円払ったんや。

cloudkickでAmazon EC2のインスタンスを手軽に監視

EC2上にあるサーバーの監視をしたいけど、「そもそも監視用のサーバーどこに置くの?」「Nagiosの設定ファイル死んでほしい」ということでTechCrunchで紹介されていたcloudkick.comを使ってみました。

以下の3ステップで監視開始。

  1. ユーザー登録
  2. Amazon EC2のアクセスキー、シークレットキー登録
  3. インスタンスの監視方法にチェックを入れる (ping, https, http, sshをサポート)

サーバーの応答が無くなるとメールが送られてきます。Webからコンソールも使えます。サーバーにタグを付けて管理する事も出来ます。Graphを書いてくれる機能も有るようなんですが、動いてない模様。データが溜まってないのかな?

後はMySQLの監視とかも出来ればいいんでしょうけど、まあ無料だし、これで十分です。本格的に使う場合はRightScale使うのが良いんでしょうね。

少しだけはまったのは、EC2ではデフォルトではpingをフィルタリングしているため、許可をする必要が有ります (ElasticFoxではSecurity Group -> Grant New Permission -> Other Protocol -> ICMP)。

Amazon EC2 Reserved Instance購入

EC2 Reserved Instanceを1つ(1year, small, us-east-1b)購入し、kzk9.netをその上で稼働させ始めました。

これによって、年間コストが $876 から $500 になりました。

移行には以下のエントリが参考になりました。有難うございます。

稼働中のインスタンスをReserved Instanceには出来ないようだったので、AMIを作成して丸ごとコピーを取り、それを使用して新しいインスタンスを立ち上げました。

Elastic IP変更時の数秒のダウンタイムで移行完了。工夫すればNo Downtimeで移行する事も可能だと思います。

うーん、しかし大分お安くなりましたね。正直、Reserved Instanceが登場しなかったら鯖の移行はしなかったと思います (^_^;

3年モノにしなかったのは、1年後ぐらいにはAsiaにもDCが出来るんじゃね、という適当な推測によるものです。

kzk9.netをEC2へ移行

本日、kzk9.netをAmazon EC2上(1 Small Instance)に移行しました。

合わせて、今までブログツールとしてMovabileTypeを使用していたのを、WordPressに移行しました。以下のエントリが非常に参考になりました、ありがとうございます。

また、以下のテーマ・プラグインを使用させて頂いています。

まだ色々と調整中ですが、完全移行に向けて、ちまちまと作業して行きたいと思います。レスポンスの方ですが、少し気になりはしますが、E-Mobileで日常的に過ごしている自分としてはあまり気にならないレベルじゃないかと。

元々kzk9.netはMacMiniのサーバーで動かしていたのですが、4年間動かしっぱなしで、いつHDDが壊れてもおかしくない状態だったので、EC2 + S3への定期的なバックアップシステムへの移行の機会を伺っていました。特に自分のsvnリポジトリは無くなったら悲しすぎるので、S3に定期バックアップするようにしました。

残りタスクは以下のような感じ。

  • WordPressのキャッシュシステムの導入
    • SmallInstanceだとCPU厳しめかも?
  • Header画像の作成
  • コード表示の改善
    • [code][/code]という特殊タグをMTの時は使っていたので、WordPressでもそれをなんとかしたい
  • サイトマップ
    • WordPressは動的にページを生成するようになったので、全ページを把握するにはどうしたらよいか?
  • ガジェット貼り付け
    • 右にスペースができたので、色々貼りまくる

ちなみに移行時間ですが、EC2のインスタンスを立ち上げて静的IPを振るまではElastic Foxで3分ぐらいだったのですが、WordPressに移行するのに数時間かかってしまいました。正直、もっと楽かなと思ってました…。

Home > Amazon EC2 Archive

自己紹介
CTO at Preferred Infrastructure, Inc.
Blog Parts
あわせて読みたいブログパーツ
TopHatenar
アクセス解析
お薦め本
kzkの本棚
広告
Archives
Categories

Return to page top