Java開発者のためのcloud-foundry講座【Part 2 AUTO-RECONFIGURATION編】

USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 2 – AUTO-RECONFIGURATION(意訳)

(Posted on November 4th, 2011 by Ramnivas Laddad in Cloud ComputingCloud FoundrySpringSpring Data)

Cloud Foundry launch eventのビデオをご覧になればわかると思いますが、Spring Web FlowのサンプルからSpring TravelをダウンロードしてきたWebアプリケーションをEclipseベースの開発ツールSTSに展開し、Cloud FoundryプラグインからMySQLサービスをアプリケーションにバイディングし、ドラック&ドロップでCloud Foundryサーバへデプロイする。これでCloud Foudry上へのアプリケーションの配布が終了。ダウンロードしたSpring Travelアプリケーションには、何一つ、一行たりとも変更を行っていません。では、ローカルのデータベースを使用するためにコンフィグレーションされたアプリケーションの設定はCloud Foudry上へ配布するときにはどうなったのだろうか? 実はこのタイミングでauto-reconfiguration機能が関与します。Cloud Foundryは、1ドルでも1セントでも初期の投資コストを低く抑えるために常に努力し続けていますが、実際のところ投資言うものは、開発者がどれだけ時間を費やしたかに依存します。そのような意味で、このauto-reconfigurationは、Cloud Foundryで開発をはじめるにあたり、開発者の費やす時間を短縮し、初期の投資コストを削減するための機能と言えます。 このブログでは、SpringアプリケーションをCloud Foundryへ展開する際に、auto-reconfigurationがどのように機能しているかを説明したいと思います。

DI機能を活かした AUTO-RECONFIGURATION

アプリケーションがビジネスロジックから構成され、データベースあるいはメッセージングなどのサービスと連携されている場合、典型的なSpringアプリケーションとしてDI(Dependcy Injection)フレームワークの恩恵を受けることができます。典型的なSpringアプリケーションがリレーショナルデータベースを使用する場合、次のようなデータソースのbean定義がされます。直接、auto-reconfigurationの仕組みには関係はないのですが、データベースのアクセスに必要な認証情報、ユーザ名、パスワードを別ファイルとして外出しすることができます。

<bean class="org.apache.commons.dbcp.BasicDataSource" id="dataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/inventory-db"/>
    <property name="username" value="myuser"/>
    <property name="password" value="mypass"/>
</bean>

下記のbean定義は、他のbeanへの依存注入(JPA entity managerへの依存注入の例)を記述しています。

<bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory">
    <property name="persistenceUnitName" value="persistenceUnit"/>
    <property name="dataSource" ref="dataSource"/>
</bean>

上記の見方は簡単です。データベースのURLはlocalhost上に存在し、ユーザ名に”myuser”、パスワードに”mypass”が設定されます。アプリケーションをCloudFoundry上に展開し、MySQLもしくはPostgresサービスをバインドするとJDBCのURLが”jdbc:mysql://localhost:3306/inventory-db”、ユーザ名が”myuser”、パスワードが”mypass”に設定が適用できなくなります。このまま状態ではアプリケーションのスタートアップが失敗してしまいます。ここでauto-reconfiguration機能が関与いたします。auto-reconfigurationはDI機能を活かした仕組みで、Spring アプリケーション・コンテキストファイルを参照し、サービスと通信するbeanを検索し、CloudFoundry上でアプリケーションにバイディングするサービスをベースとした新たなBeanに置き換えることをいたします。この結果、アプリケーション開発者はローカルで展開したコンフィグレーションのまま、CloudFoundry上にアプリケーションを展開できます。
以下の表は、auto-reconfiguration機能が置換え対象となるBeanタイプ(マッチングタイプのBean)を示します。

Service Type Replaced bean type
Mysql, Postgres javax.sql.DataSource
Redis org.springframework.data.redis.connection.RedisConnectionFactory
MongoDB org.springframework.data.document.mongodb.MongoDbFactory
RabbitMQ org.springframework.amqp.rabbit.connection.ConnectionFactory

auto-reconfiguration機能を支援するための内部的な仕組みとしてBeanFactoryPostProcessorを利用いたします。このBeanFactoryPostProcessorはBeanを作成する前に、アプリケーションコンテキストファイルを調査し、アプリケーションにバイディングするサービスをベースしたBeanとそれとマッチしたタイプの既存Beanをスワップいたします。また、リレーショナルデータベースの場合、使用されている方言的な違いも調整するためにJPA entity manager factory もしくはHibernate session factoryに再構成いたします。

Cloud Foundryへのアプリケーションのデプロイメント過程において、アプリケーションがステージングされているときに、CloudFoundryは、以下の二つの変更を実施いたします。

  1. デプロイするアプリケーションにBeanFactoryPostProcessorと付加的なリソースを含んだjarファイルを追加します。ここで注目すべきは、このjarファイルにauto-reconfigurationで使われるcloudfoundry-runtimeの特定バージョンも含まれていることです。共有機能によって、変更が必要な特定のjavaクラスは別のパッケージに置換えられます。このことから違うcloudfoundry-runtimeのバージョンを使用しているアプリケーションをデプロイしたとしてもコンフリクトを起こすことはありません。
  2. 次にSpring アプリケーション・コンテキストに BeanFactoryPostProcessorを追加したかたちにするため、web.xmlに書換えを行います。

制限事項

Auto-reconfiguration機能は、以下の条件でのみ有効となります。

  1. 与えられたサービスタイプから一つのサービスだけのとき有効になります。例えば、アプリケーションが一つのリレーショナルデータベースサービス(MySQLもしくはPostgres)だけをバイディングするとき。
  2. マッチングタイプのbeanから一つのbeanだけのとき有効になります。例えば、Spring アプリケーション・コンテキストが一つのデータソースbeanだけを使っているとき。

AUTO-RECONFIGURATION機能を使わない選択

これからAuto-reconfiguration機能使わない選択をすべき状況をいくつかご説明します。例えば、アプリケーションがCloudFoundryのサービスにないインメモリデータベースを使っている場合など、Cloud Foundryは、いくつかAuto-reconfiguration機能使わない選択の方法を提供します。

  1. Spring frameworkを使ったSpringアプリケーションでない”JavaWeb”のアプリケーションをCloudFoundry上にデプロイするとき、このときはAuto-reconfiguration機能は有効でなくなり、アプリケーションの変更も行われません(アプリケーションにJarファイルも付加されず、web.xmlの書換えもありません)。ここでprofile機能と関わるところがあるのですが、改めて後のブログで説明いたします。
  2. サービスを定義するbeanに<cloud> のエレメントが使われている場合。現状では、<cloud:data-source>、<cloud:mongo-db-factory>、<cloud:rabbit-connection-factory>、<cloud:redis-connection-factory>及び<cloud:service-scan>があります。これらのネームスペースエレメントをベースとしたBeanがアプリケーションに含まれていた場合、Auto-reconfiguration機能は適用外となります。アプリケーションにAuto-reconfiguration機能の振舞を持たせたいか、あるいは、サービス生成の単純な制御を完全に持たせたいかによって、Cloud Foundryはこの機能を適用しない選択を行うことができます。

結論

Cloud FoundryのAuto-reconfiguration機能は、はじめのころのアプリケーション開発には素晴らしい機能ですが、同時に複数のサービスを利用するなどアプリケーションが成熟すると、アプリケーション側で、きめ細かくサービスのオブジェクト接続を制御してやる必要があります。ここで<cloud>ネームスペースの話がでましたが、次のブログでThomas Risbergが紹介いたします。


本ブログの記事は、USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 2 – AUTO-RECONFIGURATIONの意訳であり、完全な翻訳ではございません。所々、翻訳を省略しているところや、原本にはない文を追加しているところもございます。また、翻訳の正確性が欠ける可能性もございますので、原文にも目を通すことを推奨いたします。ご了承ください。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。