読者です 読者をやめる 読者になる 読者になる

エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

Building Modular Cloud Applications in Java : JavaOne2013 レポート3 #j1jp

JavaOne2013 Java

Bert Ertman氏とPaul Bakker氏による「Building Modular Cloud Applications in Java」のレポートです。
オランダの方の模様。

最近、PaaS上でのJavaアプリ開発に携わっているので、Cloudという単語に反応して聴きに行ったのですが、Modularityという単語や、Apache ACEによるデプロイ管理といった話を聴くことができ、有意義なものでした。

スライドはすでにSlide Shareで共有されていました。

モジュール化はアジャイルのための究極のツールである

アジャイルに限らずですが、サービスをインクリメンタルに拡張していくと、必ずぶち当たるのがアーキテクチャを「よしなに」変更すること。
クラスの再設計などを余儀なくされることが出てきます。このときに、アプリケーションの各パーツが蜜結合でごっそりくっついていると大変ですよね。

そこで、"Modularity". アプリケーションの各部分をなるべく小さなモジュールとして独立させ、インタフェースのみを共有してデータのやり取りを行うことで、内部が疎結合なアプリケーションを作ることができます。

Javaでモジュールシステムを作るならOSGi

OSGiは比較的古くからある、Javaモジュールの動的追加や実行を管理するツールです。OSGiが使われているもっとも代表的な例の一つは、IDEEclipseで、Eclipseに動的にプラグインを追加できるのは、OSGiを基盤にしているからだそうです。

OSGiでは、各モジュールがひとつのプロジェクト

セッションでは、実際にプレゼンターが作成したアプリケーションの内部設計の紹介がありました。

このように、RESTで受け取ったリクエストを処理してMongoDBに読み書きするというアプリケーションなのですが、特徴的なのはこの図の四角がすべて、独立したプロジェクトであることです。

f:id:taichiw:20130925022642j:plain
OSGiでは、このそれぞれのプロジェクトが一つ一つのモジュールとなり、Bundleと呼ばれています。そして、ひとつのアプリケーション内で、Bandleごとにバージョン管理ができます。
他Bandleにあるクラスは、プロジェクトが異なるので、たとえPublicなClassであっても実装を見ることができません。唯一、InterfaceのみをOSGi内部の仕組みで共有します。こうすることで、普通のアプリケーションより一段、部品の隠蔽化を進めているようです。

ひとつのアプリケーションを複数のプロジェクトに分割する方法としては他に、それぞれをJarにビルドして取り込む方法もあると思いますが、そういった方法よりも一段、結合の疎化を押し進めたものだと思います。

なお、OSGiに関してはよくわからなかったので、プレゼンの中で「本日発売!」と発表された二人の書籍「Modular Cloud Apps with OSGi」を購入して実際に試してみました。詳細はこちらの記事に書きました。。

Building Modular Cloud Apps with OSGi By: Bert Ertman,Paul Bakker

Apache ACEによるデプロイ管理

さて、アプリをモジュール化する方法がわかったところで、いよいよ本題のCloud Applicationです。

今回、プレゼンターが紹介してくれたアプリケーションは以下のような要件だそうです。

  • 学校で使うシステム(よく聞き取れなかったけど、学校で使う業務システム的なやつ?)
  • 「自分たちで構築したPaaS上にデプロイされている」
  • ノードクラスタは各学校ごとに用意されている。また、学校ごとに用件が違うため、使用するモジュールが異なるらしい

自分たちでPaaSを構築とは驚きですが、制約が無いことが何よりすばらしいこととか。

そのため、各ノードへのデプロイの仕組みも自分たちで構築しているそうなのですが、ここで使われているのがApach ACEという、デプロイ管理システムだそうです。
Apache ACEは、モジュールに分割した分、構成管理が複雑になりがちなOSGiのデプロイの管理を行うために、Apache Foundationで進められているプロジェクトで、

  • 複数のコンポーネントからなるアプリを
  • いくつかの環境にデプロイ、かつ環境によって構成を帰る必要がある

ようなときに力を発揮するツールとのこと。

このように、一度ACEにアプリをアップロードしたあと、設定にあわせて、ACEが各サーバへアプリケーションを配布していくことができるそうです。

時間帯に合わせてノード数、スペックを変更

さらに、本システムは学校用という要件上、アクセスは日中に集中し、夜間は殆ど使われないそうです。そこでリソースを効率的に使うため、夜間は小さなノードをひとつだけ上げ、朝になると強力なノードを一気に15台立ち上げるそう。

その際、立ち上がったサーバから順に、Apache ACEからアプリケーションを受け取り、デプロイされることでサービスできる状態にしているそうです。
(ノードは起動直後は、何も無い状態)

まとめ

技術的なこと

本セッションで、OSGiApache ACEという技術を知りました。OSGiはセッション内で「簡単になった」といわれていたものの正直まだ難しく、メリットもイマイチ腹落ちしていないのが実情です。

ただ、私が今担当しているプロダクトが各種APIの集合体のアプリケーションで、APIごとにバージョン管理をしたいと思っているもので、もしかしたらOSGiと相性がいいのかも、、と思いました。

思想的なこと

なるべく各部品は小さく、疎結合に というのは、アプリケーション開発における、共通項かと思います。

今回のセッションでは、改めてその方向性を確認しました。

さらに、夜間は1ノード、朝になったら15ノードあげてデプロイ!という一連のライフサイクルが自動で運用されていることに驚きました。
デプロイ改善はここ最近、必要性を感じてずっと取り組んできていることなのですが、いまだ解決できていないのが実情です。

本番反映の自動化、簡素化、見える化は今後も継続して取り組んでいく必要があると改めて感じました。