福田です。
ゆっくりとカモミールを飲みながらラップトップを叩いています。
3年間お世話になったデータセンターのHadoopクラスタをクラウド環境に移行しました。
クラウドでは従量課金を活かしてコストの最適化を図ることができます。
今回、Cloudera ManagerとJenkinsそれぞれのAPIを使用し、クラスタの起動状態を保証するラッパーと自動停止サイクルを実装することで、透過的なクラスタの起動と停止を実現しました。 *1
アーキテクチャ
全てを包むWraps
作業環境となるホストに、ラッパーコマンド（以下Wraps）をインストールします。 *2
Wrapsは、状況に応じてJenkins、Cloudera ManagerのAPIを呼び出し、VMインスタンスおよびCDHクラスタの起動状態を保証します。
また、後述する停止サイクルに対して使用中であることを通知するロックファイルの作成と削除を、開始時と終了時それぞれに行います。
hadoop、spark-shell、spark-submit、hive、hbaseなどクラスタを使用する任意のコマンドに対してエイリアスを設定し、Wraps経由で実行できます。
停止サイクル
クラスタとVMインスタンスの停止は、Jenkinsのジョブを定期的に実行することで行います。前述のロックファイルが存在しない場合にのみ停止します。 *3
Sparkシェルの意図しない繋ぎっぱなしや、接続断によるロックファイル残留によりクラスタが稼働し続けてしまうことへの対策として、Sparkシェルに読み込ませるスクリプト（アイドル検知し、自動的に終了する）や、親プロセスがいないロックファイルの定期削除などの仕組みも実装しました。
Wrapsデモ
実行イメージ：クラスタの起動を伴うsparkシェルの起動
稼働イメージ：テスト環境より
まとめ
クラスタの起動と停止の自動化により、調整のコミュニケーションや手動でクラスタを停止するという人的作業と使用していない時間のインスタンスコストが消滅しました。
空いた時間でハーブティーを入れています。
*1:実際には使用量に応じた割引などがあるため、利用状況に合わせて適切に見積もる必要があります。
*2:Pythonで実装。内部で、便利で気の利いたCloudera Manager API Clientを使用しています。注意点として、使用しているCloudera ManagerがサポートするAPIのバージョンに合ったクライアントを選択する必要があります。
*3:利便性を考慮して、Wrapsを経由したコマンドの実行完了後に一定のアイドル時間を保証するようにしています。これは、終了時のロックファイルの削除を、リネームによるサフィックスの付与とタイムスタンプの更新という実装に置き換え、一定時間以上経過したサフィックス付きのファイルを削除する処理を定期的に実行することで行います。
