Hadoopを使ったログ分析システムにおける開発、デプロイのフローについて

技術

Hadoopを使ったログ分析システムっていうのを何回か経験してて、そういえば開発、デプロイのフローがあんまりうまく回せなかったよなあと思ったのでそのあたりについて今日は書きたいと思います。

まずネットワーク周りの前提から書きます。

サーバーにログインするには踏み台を経由しなければなりません。

なので、まあ例えばHadoopクラスタを構築してて、betaとrealの2つ環境があったら以下のようにログインすることになります。まあよくある話ですよね。


ローカルPC -> 踏み台 -> beta環境
ローカルPC -> 踏み台 -> real環境


でもってローカルPCとbeta,real環境との間の通信は制限されています。これもよくあるパターンだと思います。

beta,real環境からインターネットに出れない場合なんかは、ローカルPCからインターネットにアクセスしてtar ballとかrpmを持ってきてそれを特殊なルートでbeta,real環境に持っていくなんてことになります。こういう場合に問われるのはIT技術ではなくてその特殊ルートを知っているかどうかという社内スキルの話になりますが、その話はここではおいときます。

ソースをリリースする場合は、なんらかのデプロイシステム経由でSubversionなりGitHub Enterpriseなりのソースリポジトリからソースを取得してbeta,real環境に配布するという流れになると思います。

一般的なWebアプリだとローカルにDBとか開発環境一式をセットアップしてまずローカルで開発する。
ローカルでの開発が環境したらbeta環境でテストして問題なかったらreal環境にリリースという流れになると思います。


ただしHadoopを使ったログ分析システムの場合はこのフローがあまりフィットしないんですよね。

まずローカルにHadoop環境作るんですかというところから始まる。ま、作ってもいいんですけど、データを準備するのが面倒だから結局サーバー上で直接開発して、動作確認した方が早いケースが多い。

そうなるとサーバー上で開発したソースはどうするんですかという話になる。ネットワークの関係上サーバー上からリポジトリに直接コミットできないケースだったりするとアレですね。

コミットできるようなケースでもGitHub Enterpriseだと鍵を生成して登録とかしないといけないです。それにGit弱者としてはSourceTreeでコミットしたいじゃないですか。それにサーバー上でvimで開発するんじゃなくてローカルでAtomで開発したいとかあるじゃないですか、たぶん。

そういうケースだとローカルでソース修正して動作確認しないでコミットしてデプロイシステムからbeta環境にデプロイして動作確認なんてことをやりがちです。ええ、僕はやりました。この場合に何が問題かというと動作確認がとれてないものがコミットされており、うっかりほかの人がrealにリリースしないとも限らない。まあこの辺はブランチ変えるとかすればいいと思いますが。

そんなこんなを考えるとやり方としては以下のパターンがあるかなあと思ってます。僕は2〜5のどれかにしようと思っています。

1. ローカルでHadoop環境を用意して開発
メリット：ローカルで開発して動作確認がとれる
デメリット：データを含めた環境構築が手間

2. ローカルでソース修正するけど動作確認しないでコミット
メリット：ローカルでソース修正できる
デメリット：動作確認とれていないソースがコミットされる

3. ローカルでソース修正するけどコミットしないでクリップボードなんかを使ってサーバー上のファイルを修正して動作確認
メリット：ローカルでソース修正してサーバーで動作確認がとれてローカルでコミットできる
デメリット：複数のソースファイルをいじる場合は面倒だし、編集ミスとかもありそう。

4. ローカルでソース修正するけどコミットしないで多段SSHとかしてサーバーにファイルを送って動作確認
メリット：ローカルでソース修正してサーバーで動作確認がとれてローカルでコミットできる
デメリット：多段SSHの設定とかサーバーにソース修正のたびにファイルを送るのが面倒

5. サーバー上で直接開発
メリット：環境構築の手間が少ない
デメリット：リポジトリへのコミットが面倒かも。