Asakusa バッチの保守と運用

この記事は Asakusa Framework Advent Calendar 2013 の6日目の記事として書いています.

Asakusa Framework は Hadoop の上に位置するフレームワークで, Hadoop バッチをより設計しやすく, 保守しやすくするためのものです.

Asakusa Framework を使った開発については @hishidama さんの記事 (http://www.ne.jp/asahi/hishidama/home/tech/asakusafw/), 土佐鉄平 さんの記事 (http://teppei.hateblo.jp/search?q=asakusa), fullkawa さんの記事 (http://d.hatena.ne.jp/fullkawa/20120730/p1) があります. 開発についての記事はいくつかあるのですが, 保守についての記事はなかなか見ないです.

私は Asakusa バッチの開発に, Asakusa のバージョンが 0.2.6 (←確か) だった頃から関わっています. (フレームワークの方ではなくて, Asakusa Framework で作ったバッチの方です.) そこでは主に CI やテスト環境の整備, リリース管理, 運用のためのスクリプト作成をやっています. もちろんそれだけでは収まらなくて, バッチ書いたり, データの表示のための Web アプリを書いたりもしています. せっかくなので, ここらへんの保守やら運用やらの話について書いていこうと思います.

書く予定の内容

  1. Hadoop クラスタの準備

    社内か AWS (EC2 や EMR) か

  2. 全体構成について

    YAESS と WindGate の分散配置について

    Windows がある場合

    Asakusa バッチ実行環境の構成 (前編), Asakusa バッチ実行環境の構成 (後編)

  3. リリース, デプロイについて

    リリースとデプロイ

  4. デプロイとビルドについて

    デプロイとビルド

  5. ログについて

    EMR の新画面について

  6. 外部連携について

    速度計測計画中

今日は「1」の「Hadoop クラスタの準備」について書いていきます.

Hadoop クラスタの準備

Asakusa Framework は Hadoop クラスタ上で動作するフレームワークですので, まず Hadoop クラスタを用意しなければなりません. ではそのクラスタを動かす環境として, どんな候補があって, それらの選択の指針について書いていきます.

社内か AWS か

Hadoop クラスタを動作させる環境ですが, 大きく分けて「社内環境」か「クラウド環境」かの選択肢があります. 「社内環境」というのは, データセンターや社内のマシンルームなどを想定しています. 実機であることが多いと思いますが, 実機の上で動く仮想マシンという可能性もあります. クラウド環境としては現状 AWS を想定しておきます. これは単に私が使っている環境が AWS である, という理由です.

この2種類の環境を比較したときに, 以下のような違いがあります. 個々個別に考えると, こうもはっきり言い切れないことはありますが, 大雑把に対比しています.

Hadoop 環境の比較
観点 社内 AWS
購入 購入計画を立ててハードウェアを購入する. 初期費用は AWS より高い 時間単位の従量課金のため初期費用が抑えられる
管理, 運用 ハードウェアまで管理する必要があるが, その分自由度は高い ハードウェアを管理しなくて良いが, サービス上の制約があり得る. 仮想化層の下の物理層は見られないことがある
インターネット 出れなくても良い 出られる必要がある
スケールアウト性 有. サイジングを遅らせられる (たぶん予算はスケールしないけど)

ここらへんは AWS さんが売り文句として繰り返していた内容なので, たいていの人は知っていると思います.

両者の違いは, 管理の手間と細かいところまで管理できることのトレードオフとなっています. 社内環境については会社ごとに, 出来ること出来ないこと, あれやこれやの個別の事情があると思います. クラウド環境については, 社外にデータを出すことに対する制約などもあるでしょう. それらを勘案して, どちらを選択するかを決めることになると思います.

社内環境にクラスタを構築する際のハードウェアの選定にあたっては, Cloudera 社のブログにこんな記事もあるので参考にしましょう. Hadoop クラスタ構成時のハードウェア選定の目安

EC2 か EMR か

AWS を使うと決めた場合, Hadoop クラスタ環境として EC2 クラスタで自作するか, EMR を利用するかの 2 つの選択肢があります. それらの特徴についても対比させておきましょう. (こっちが本題みたいなものです)

クラウド上の Hadoop 環境の比較
観点 EC2 EMR
料金 EC2 部分のみ ノード数分の EC2 料金 + EMR 料金
クラスタ作成 自前 (手作業なりツールなり) サービスとして API を通して作成できる
AMI 自前作成 EMR 用に用意されているものを使う, 必要なツールは起動時にインストール
インスタンスタイプ 全て使える (ただしリージョンごとに異なることもある) 使えるものが EC2 より少ない
VPC サブネット 任意 パブリックサブネットでないといけない
セキュリティグループ 任意 ある決まった名前のセキュリティグループが使われる
プライベート IP アドレス EC2 API から取得できる EMR の API では取得できない
クラスタ管理 インスタンス内部のプロセス管理に加え, 各ノードごとの起動/停止の管理も必要 クラスタ単位で起動/停止が行え, 基本的には使い捨てる (ようだ)
Hadoop プロセス群の起動とその確認 自前 自動で起動する
クラスタ起動速度 数分 インスタンスの作成から行っているせいなのか遅い (15分くらい)
起動失敗時のリトライ 無し ある程度やってくれる. ただし起動するインスタンス数が完全に保証されてるわけではない
Asakusa のデプロイ 事前にデプロイ済みの AMI を作成 起動時にデプロイ

基本的に EC2 はけっこうな作業とツール作りを自前でやらないといけません. それに対し EMR では, 細々とした部分がサービスとして提供されていて, 結局はここでも, 自由度と運用の負荷のトレードオフになるわけですね.

しかも AWS の API は基本的に非同期であり, API が成功を返した後も処理が一定時間内に問題無く完了したかを確認する必要があります. 失敗していたことが判明したら, 失敗した処理の後始末を行って, リトライを実行しなければいけません. リトライを無限に行うわけにはいかないので, リトライを行う回数や時間間隔についても決めておかねばなりません. AWS の API を呼び出したり, SSH で内部の操作を行う回数が多い分 EC2 クラスタは運用負荷が大きいです.

EMR はプライベート IP アドレスを取得する API が無く, SSH でインスタンスにログインすることが推奨されていないように感じます. 内部のコマンドを実行したいときはステップシェルスクリプトを用意して, それを順次実行させることになります. データなどの受け渡しも SCP を使うのではなく, S3 を介して他のインスタンスや外部のシステムとデータのやり取りをすることになると思います.

もちろん, EMR のノードはただの EC2 インスタンスなので, それに張られているタグを目安に各ノードのプライベート IP アドレスを EC2 の API を使って取得することは可能です. しかし, EMR クラスタとやり取りするマシン全てにプライベート IP アドレスを教えるのは手間なので, ステップという仕組みと S3 というグローバルなデータの保存場所を活用するのが筋です.

この小節を簡単にまとめると, 結局は「自由度」と「簡便さ」のトレードオフなので, EC2 クラスタコントローラーを作ることに価値を見出すなら EC2 クラスタ, 楽をしたければ EMR という結論になります.

クラスタの利用頻度

この小節ではクラスタを動かしておく頻度という視点で考えてみます. 別の言い方をすれば, 利用料金の観点です.

AWS は時間単位での従量課金制なので, 使うときにクラスタとその内部のプロセスを起動し, 使わないときはインスタンスとプロセスを停止する, という運用になります. ただ, プロセスが分散協調して動く Hadoop クラスタの起動は面倒です. プロセス単体は起動したとしても, 他のプロセスと上手く通信できなければならず, 設定の食い違いなどがあればプロセスが停止し, クラスタが機能しなくなります.

従って作業コストを考えれば, クラスタの利用時間が 1 日のうちほんのわずかな場合は EMR を利用するのが良いでしょう. 逆にほぼ 1 日中バッチが動いていてクラスタを立ち上げっぱなし, ということであれば手間はそう変わらないので EC2 クラスタでも構わないでしょう. EMR 料金は, EC2 インスタンスの利用料金に加え, わずかな額ではありますが EMR の料金が発生します. (Amazon Elastic MapReduce 料金表) わずかとは言え, 長時間動かす場合を考えているので, できるだけ安い方が良いでしょう.

EC2 ではなく EMR を使うのはクラスタ管理のコストを削減するためなので, その効果があるのか, それとも薄いのかを考慮して選択しましょう.

終わりに

クラウドサービスは自由度とお金を対価に楽するためのものです. その自由度とお金と利便性を天秤に掛けて, 最も良いと考えるものを選択してください.

Asakusa を動かすために前段で何を考えるかを書いていたら, Asakusa が全く登場しませんでした. 次回の全体構成の話からは Asakusa が登場する予定です.