Asakusa Framework 勉強会 2014春に行ってきました

2014/4/7『Asakusa Framework 勉強会 2014春』に行ってきました。→Togetter 

最初は土佐さんの『Asakusa Framework はじめの一歩・改』。
前回のが『はじめの一歩』で、今回の『改』は、主にGUIを使うようになったことが違いでした。
前回はちょうどShafuが出たばかりでまだ認知されていなかった為、Mavenを使ったコマンドベースだったのが、今回はShafuでプロジェクト作成していました。
それどころか、拙作のDMDL EditorXのデータモデル作成ウィザードを使ってDMDLを生成していたのでびっくり＾＾；
結合モデルのキーの指定方法は、ペアとなる項目を2つ選択してからコピーするのですが、他のツールではそういう方法はしないので分かりにくいかもしれないですね＾＾； すみません。（今回の勉強会ではひっそりひそんでいようと思っていたのに、つい使い方を指摘してしまいました）
属性の追加ウィザードとかImporter/Exporterクラスの生成ウィザードも使われていて、フル活用でした。ありがとうございます。
生成したImporter/Exporterクラスでimport文がエラーになっていたのは、親クラスのimport文だと思われます。ウィザード内で想定しているパッケージ名と実際のパッケージが合っていないのだと思います。
ただ、build.gradle内のパッケージは変更していないようだったので、何が不一致になったのかよく分からないですが。
（追記：全然別のバグだと思われます＞＜→バグ修正） 

DMDLから生成されるクラスのパッケージ名は、build.gradle内に記述するようになっています。（AsakusaFWの仕様）
そこから「gradlew cleanEclipse eclipse」コマンド（あるいはShafu（Jinrikisha）の「Eclipseプロジェクト情報を再構成」メニュー）でEclipse用の定義を生成すると、一緒に.settings/com.asakusafw.asakusafw.prefsというファイルが作られます。
DMDL EditorXはそのファイル内に書かれているパッケージ情報を見ています。ただし、内部でキャッシュしているので、現状では、Eclipseを再起動しないと再読み込みしません＾＾；
このキャッシュ・再読み込みに関しては改善しないといけないなぁと思っています。

あと、Asakusa Toad Editorも使っていただいて、ありがたいことです。

これで、ほとんどの作業がGUIで出来るというデモでした！
が、（慣れるとDMDLを直接書く方が（コピペしやすくて）速いし、Java上のDSLも補完機能が使えるのでやりやすいと思いますので）Toad Editorはまだまだですorz 

---

2つめはCTCの中島さん・金子さん。
RACKというCTCさんが開発したミドルウェア上でAsakusaアプリケーションを動かしたという話でした。

RACKは（Rubyの同名の何かとは関係なくて）OpenStackのAPI呼び出しを抽象化するものらしいです。
Javaのプログラム内で「process[0] = new RACK("app1");」みたいにして仮想マシンを起動できるようです。
AWSで言えば、EC2インスタンス起動のAPIを呼んでいるようなものですかね。

Hadoopクラスター起動時にRACKのプロセス間通信でお互いのIPアドレスを通知して初期化しているとのことで、そういう初期化処理が簡単に書けるようだと嬉しいですね。
EMRは起動は簡単でも、Asakusaアプリケーションのデプロイ（配置）とかは何らかの手段で行う必要があってちょっと面倒なので。 

---

3つめは杵渕さんの『健全な睡眠のために』。
Asakusaアプリケーションの運用環境の話でした。
夜間に障害連絡で携帯電話が鳴ると子供が起きるので奥さんも不機嫌になる、というのは共感を集めているようでした(爆) 

当初（EMRが無かった頃）は「RDB→WindGate→EC2で作ったHadoopクラスター」という構成だったのを、「RDB→S3」+「S3→EMRのHadoopクラスター」という構成に変えたと。
前者の構成では、途中で落ちたらRDBの読み込みからやり直さざるを得なかったが、後者の構成では弱点だったオンプレミス⇔AWS間の通信障害も減ったようです。 

想定外データの扱いについては、AsakusaFW特有…なのかな？
AsakusaFWのOption系クラスでは、値がnullだとget()でNullPointerExceptionが発生するようになっているので、それを考慮してコーディングする必要があります。
面倒な仕様だ…とも思いますが、Java8のOptionalでもnullだとget()でNoSuchElementExceptionが発生するので、関数型言語界隈では当たり前の仕様のようです。
（Java8のOptionalはifPresentメソッドとかが便利なので、AsakusaFWもJava8対応してラムダ式が使えるようにならないかなぁ。過去の互換性を考えると難しいかなぁ？）

本番データをS3に配置するようになったので、CI環境からそれを読み込んでテストできる…という話は、想定外データを見つけるのには向いているかもしれないですが、CI環境から本番データにアクセスしてもよいというポリシーは一般的にはあまり無いのではないかと思います＾＾；

紹介されていたアドベントカレンダー2013のペンギンアイコンというのは、cocoatomoさんのAsakusaFWの運用に関するブログですね。 

---

最後はOSSラボの船井さんの『JobSchedulerを使ったAsakusaのジョブ管理』。

ドイツのSOS社が開発したJobSchedulerを使ってAsakusaアプリケーションを実行した話です。（JobSchedulerという名前は、Apache HTTP Server並に誤解を招く固有名詞ですね＾＾；）
JobSchedulerは2005年（JP1と同時期）から公開されており、ヨーロッパが中心だが、日本でも去年から本番業務で何社か使われ始めているそうです。

ジョブ定義（JobSchedulerではジョブチェーンと呼ぶ）はXMLファイルで書くのですが、YAESSの実行計画のJSONファイルを読み込んでXMLファイル（とイベントハンドラー）を生成したようです。
デモではafw2jos.shというシェルを実行していました。 

実際のAsakusaアプリケーションの実行には、yaess-phase.shを使ってフェーズ毎に実行しているようです。
ただ、フェーズ実行が失敗したときに途中のフェーズから再実行して大丈夫かどうかは何とも言えないので、JobSchedulerの再実行機能は使わない方が良さそうです。
そうなるとフェーズ単位で実行する意味はあまり無いので（どこまで進んだかの進捗状況は見られるけど）、普通にyaess-batch.shでバッチ単位で実行してもいいような気がしますが＾＾；
実際、複数バッチになる場合はバッチの呼び出しをスケジューリングする必要があるので、それだけでも充分役立ちます。

---

今回は運用周りの話が多かったですね。
なかなかAsakusaFWの運用を考えるところまでいかない（自分もやったことが無い＾＾；）ので、色々参考になったと思います。