はじめに
こんにちは。adingoの岩川です。第3回ではCloudFrontのログを解析するHadoopプログラムを書き、それをローカル環境上で実行するところまで解説しました。
うまく動作しましたか?
今回は、第3回のHadoopプログラムをEMR上で実行する手順を追っていきます。
Amazon Elastic MapReduce Ruby Client
EMRは管理画面からも起動できますが、今回は定期バッチを想定して、コマンドラインツールを使うことにしましょう。
下準備として、下記のものを入手します。なお、Amazon Elastic MapReduce Ruby Clientを実行するにはRuby 1.8が必要です。
- Amazon Elastic MapReduce Ruby Client
- Security Credentials
- キーペア
Amazon Elastic MapReduce Ruby Clientを下記のページからダウンロードします。
解凍したら、elastic-mapreduce-cliにパスを通しておくとよいでしょう。
Credentialsはアカウント認証のために使用します。
Credentialsはマネジメント・コンソールにログイン後、右上にあるユーザ名をクリックし、プルダウンメニューから「Security Credentials」を選択すると進むセキュリティ証明書のページで確認することができます。
キーペアファイルはマネジメント・コンソールの「EC2」タブ→左ナビゲーション「Key Pairs 」→「Create Key Pair」と進むと作成できますので、安全な場所に保存しておきましょう。
最後に下記のファイルを作成します。入手したSecurity Credentialsやキーペアの値に置き換え、credentials.jsonとして保存して下さい。
なお、ap-northeast-1は東京リージョンを意味します。
これで、コマンドラインツールの導入は完了です。
プログラムをEMRに移植する
作成したHadoopアプリケーションをEMRで実行するには、S3に入力ファイルとプログラムをアップロードする必要があります。
アップロード用のjarファイルを作成します。まずはmainメソッドを含むクラスを指定するために、マニフェストファイルを作成します。
jarコマンドを実行します。
テスト用のS3バケットを作成し、jarファイル、サンプルファイルをアップロードします。以降の例では、下図のように配置した想定で解説します。
ただし、S3バケットの名前空間は、リージョンごとに1つずつです。ここではまだ誰にも使われていない名前を選択しておく必要があります。
準備が整いましたので、elastic-mapreduce-cliを呼び出します。
以下は、m1.smallインスタンス1台で計算する例です。
マネジメント・コンソールを見ると、EMRが起動していることを確認できると思います。コンソールには--nameオプションで指定した名前が表示されますので、わかりやすい名前にすると良いでしょう。
Stateの欄がSTARTING→RUNNING → COMPLETEDと推移していきますので、計算が完了してしばらくしたらS3のs3://cflog-testxxx/outputフォルダを確認してみましょう。
S3への実行結果やログの転送には時間がかかることがあります。
CloudFrontのログ形式
実際のCloudFrontのログはテキスト形式ではなく、gzip形式です。HadoopのTextInputFormatを使う場合、gzip形式の圧縮テキストファイルの内容を透過的に扱うことができますので、プログラムの変更は必要ありません。
ロギングを有効にするには、CloudFrontのDistribution作成ウィザードのDistribution Detailsの画面でLoggingをOnにし、保存先のS3バケットを選択してください。
なお、CloudFrontにアクセスがあってからログが収集されるまでには、数時間のタイムラグが発生する場合もありますので覚えておきましょう。
EMRでのデバッグ
--enable-debuggingオプションを有効にしてEMRでのデバッギングを有効にすると、標準出力と標準エラーをマネジメントコンソールから確認することができます。
ただし、デバッグツールの初期化には時間がかかります。デバッグ時には、--aliveオプションを加えてインスタンスを立ち上げっぱなしにしておくのがおすすめです。同じインスタンス群を使って、再度計算を実行することができます。
実行時に出力されるjobflowidを控えておきましょう。
EMRではジョブとステップという2つのライフサイクルがあります。インスタンス群が起動して終了するまでをジョブ、1回のMapReduceをステップと呼びます。したがって、1つのジョブにはひとつ以上のステップが含まれることになります。
既存のジョブにステップを追加するには下記のようにします。
EMRの導入費用
EMRの費用はインスタンスタイプと「のべ」のインスタンス起動時間によって決まります。
cosmiのシステムは現在1日に600MBほどのファイルを処理しています。内容の異なるEMRバッチを4本実行しており、それぞれm1.smallインスタンス1台を使って、20~30分で済んでしまいます。時間のかかる月次バッチ1本だけはインスタンス数を5台に増やしても2時間ほどの時間を必要とします。
トータルで概ね130インスタンス時間、m1.smallインスタンス費用は0.1USドル, EMR追加料金が0.015USドルですので、ひと月あたり約15USドルの費用が掛かっています。
cosmiの場合、いざやってみるとほとんどのバッチがクラスタ1台の規模で足りてしまったわけですが、月に1度の高負荷バッチや、今後のサービス拡大にも稼働台数を変更するだけで対応できるので、便利に感じています。
EMRの導入に際しては、まずは1台ではじめ、必要に応じてインスタンス数を調整するのがオススメです。なお、EMRの実行時間がたとえ1分であったとしても、1時間とカウントされます。1回のバッチが極端に短い場合には1つのジョブで複数のステップを実行すると良いでしょう。
終わりに
前後編に分けて、Amazon EMRとCloudFrontを組み合わせたデータ処理アプリケーションの実装に取り組みました。EMRの最大の強みは、システムの性能を簡単に拡大・縮小できることです。それにより、開発者は影も形もないサービス、1行も書かれていないアプリケーションの負荷を予測するという、難仕事から解放されるわけです。
EMRはすぐに始められます。EMRを武器にして、あなたのサービスに大規模解析を取り入れてみてはいかがでしょうか。