Edited at

大規模データについて第5回~EMR開発_運用編~

More than 5 years have passed since last update.


はじめに

今回は 「EMR開発/運用編」になります。

EMRバッチを継続的に安定運用するためのコツについてまとめました。

EMR編の最後になります。

EMR運用のコツは、特性である

「必要なときに必要なだけ使う」

を生かすことだと思います。

これを徹底することで我々のEMR費用は当初の

約半額程度まで、持っていくことができました!


EMRインスタンス起動について

先ず最初に、以下が我々のEMR起動オプションになります。

export EMR_CREATE_OPTION="--create --hadoop-version 1.0.3 --ami-version 2.3.6 \

--subnet ${EMR2_SUBNET_ID} \
--region ${EMR_INSTANCE_REGION} \
--num-instances ${EMR_INSTANCE_NUM_INSTANCES} \
--slave-instance-type ${EMR_INSTANCE_SLAVE_INSTANCE_TYPE} \
--master-instance-type ${EMR_INSTANCE_MASTER_INSTANCE_TYPE} \
--log-uri ${S3_BUCKET_PATH}/${EMR_INSTANCE_LOG_URL}/ \
--bootstrap-action s3://elasticmapreduce/bootstrap-actions/install-ganglia \



  • 「ami-version」、「hadoop-version」を必ず指定する。


    • 指定しない場合は最新バージョン(latest)が使われます。安定運用のために必ず指定しましょう!

    • AMIはバージョンアップが頻繁で、突然仕様が変わって動かなくなったり、バグってしまう現象が起きます...




  • 「slave-instance-tpye」、「master-instance-type」について


    • slaveはMRのタスク実処理を実行するので、 強めのインスタンスを使います。


    • 弱インスタンス多数 < 強インスタンス少数
      となるので、よほど軽い処理でない限り「m2.4xlarge」を設定しています。
      masterの役割はMRタスクの割り振り処理で、それほどリソースがいらないので「m1.medium」を使います。




  • 「num-instances」について


    • 起動時は最小構成のslave、masterが各1台となるように起動します。

    • リソースが足りない場合は後述のドーピングを実施してリソース追加します。




  • 「log-uri」について


    • EMR実行ログの保存先パスを指定します。

    • トラブルが起きた際に真先に見に行くところなので分かり易いところに設定した方がよいです。




  • 「bootstrap-action」について


    • 新機能リリース直後は、リソース消費量把握の為に「ganglia」をセットするようにしています。

    • こなれてくると不要 (起動が遅くなる) なので外します。

    • 他には、Hadoopパラメータの調整値を設定します。ここから調整できる設定はソースの変更が不要なので楽できますw




実行中のインスタンス変更について (インスタンスの増設)


スポットインスタンスの増設(ドーピング)


  • CLIから実行します。通常のインスタンス利用料金の1/5〜1/4程度の料金で起動できます。


注意点としては、

繁忙期(月初)に稀に調達できない可能性があり、実行中に他者の入札によって

強制終了させられる可能性があります。

EMR利用料は変わらず(EMR利用料=EC2利用料くらいになる)

ですが、ほとんど問題は起きずに安く使えるのでおススメです。



通常インスタンスの増設


  • CLIまたはWebコンソールから実施できます。

  • 高いので我々はほとんど使いませんが、EMRを長時間安定稼働させたい場合は有用だと思います。


実行中の進行状況、リソースの把握


HadoopUI


  • オンプレ時代にも使ってましたが、EMRで使えます。

  • マスタノードのパブリックIP(ポート9100)で見れます。


ganglia


  • 「bootstrap-action」で指定します。

  • 各ノードのリソース消費量を把握出来ます。


トラブル対応

先ず「log-uri」を見て何処でエラーが起きたかを把握します。


bootstrap以前の段階で落ちた場合。


  • EMRサービス自体がトラブっている可能性が高いです。

  • EMRのバックエンドは結構な頻度でアップデートされているらしく、突然起動すらしないトラブルが起こることが稀にあります。

  • そうなってしまうと、サポートに連絡して対応を待つしかないです...


bootstrap中に落ちてしまう場合。


  • bootstrapの設定が間違っている可能性が高いです。

  • 稀にEMRサービスのトラブルの場合もあります。


bootstrap以降で落ちてしまう場合。


  • アプリケーショントラブルの可能性が高いです。

  • 「log-uri」パスにあるEMR実行ログから原因を見つけましょう。


おわりに

これまで、EMRについて以下を連載していました。

今回の 「EMR開発/運用編」

我々の大規模データ処理におけるEMR利用法の紹介は一通りとなります。

これからも引き続きEMR使って行くので話題が

溜まったら不定期にqiitaアップして行きます〜


大規模データについてのリンク

「大規模データについていろいろやってみます!(第1回)」

「大規模データについて第2回~EMR(Hadoop)について、なぜEMRなのか〜」

「大規模データについて第3回~EMR開発_基礎編〜」

「大規模データについて第4回~EMR開発_実践編〜」

「大規模データについて第5回~EMR開発_運用編〜」

「大規模データについて第6回~Redshift編〜」