JBoss Fuseを使い倒す 〜その1：環境構築編〜

大規模な連携基盤導入時の課題

では、大規模な連携基盤として利用する場合、どのような課題があるかを見てみましょう。

課題1

サーバーインスタンス増設時、サーバーリソースを準備して割り当てる必要があります。一般的に、負荷分散・高可用性の検証済みシステム構成に対して増設する場合、同等のハードウェア・OSを選びます。そのため、利用可能なサーバーリソースが限られます。また増設時のインストール作業は、初期構築時と同等な作業量が発生してしまい、増設に伴い本番切り替えのためのリハーサルと綿密な計画が欠かせません。

課題2

サーバーインスタンスが増えるほど、設定の変更管理、プログラムのデプロイが煩雑になります。さらに、全社規模でシステム連携を担うシステムでは、連携の追加・改修が頻繁に発生するため、運用オペレーションのミスが発生しやすく、脆弱な基盤になってしまいます。

課題3

システム上の変更、例えば、サーバーインスタンスの増減、プログラムの再配置などにより、関連のアプリケーション（連携元・連携先システム）の接続情報変更などが発生してしまうと、運用・保守コストや運用リスクの増加になります。

これらの課題は、開発コストが安くなって、維持コストが相対的に高く見られる今の時代には、企業の情報システム部門の戦略上、大きな問題になっています。

これらの課題を解決するためには、以下の機能が連携基盤に必要となります。

• サーバーリソースを柔軟に拡張できる機能（プロビジョニング）をシステム要件に取り込む
• 設定内容やプログラムなどを個別のサーバーインスタンスに保持するのではなく、独立したリポジトリに管理するような設計
• サーバーインスタンスのランタイム情報の自動収集機能

これらの機能を提供するのが、JBoss Fuse v6.1に同梱されたFabricというコンポーネントです。Fabricは、コンテナを集中管理するフレームワークで、主な機能は以下の通りです。

• プロビジョニング機能
• コンフィギュレーション機能
• 集中管理機能

ここからはFabricによる具体的な解決方法を説明します。

プロビジョニング機能

Fabricの最小構成は、Fabric ServerとContainerとなります（図4）。

図4：Fabricの最小構成

Containerは、連携サービス（例えばCamelルート、メッセージキュー）などが稼働する実行環境です。一方Fabric Serverは、Containerの設定やランタイム情報を集中管理するサーバーです。また、Containerの設定とランタイム情報は、レジストリ（詳細は後述）に格納されます。

図5：Fabricの拡張

Fabricを拡張するには、まずFabric Serverを増やします。上図のように、複数のFabric ServerがEnsembleに構成され、互いにレジストリを複製・同期することにより、Fabric Serverの可用性が高められます。

次は、Containerを増やします。上図のように、多数のContainerを追加することによって、連携サービスなどの負荷分散および可用性が向上されます。

またContainer自体のフットプリントが非常に小さい（メモリ消費量256MB以下）ため、一台の物理サーバーに複数Containerの同居が可能です。各Containerを独立したプロセスに割り当てて、Containerで発生する障害を局所化することによって、可用性がさらに向上します。

Fabricでは、このようなContainerの追加をプロビジョニングと言います。Fabricがプロビジョニング可能なContainerは、以下の４種類になります。

Child Container（Fabric Serverと同一サーバー上のコンテナ）

• SSH Container（リモートSSH実行可能なLinux／Unix環境上のコンテナ）
• Fabric Container on Windows（Windows環境上のコンテナ）
• Cloud Container（クラウド環境上のコンテナ）

このうちCloud Containerは、Apache jcloudsのAPIを利用しています。jclouds APIがサポートするクラウドプロバイダの一覧は下記のURLでご参照ください。

Apache jclouds :: Providers

http://jclouds.apache.org/reference/providers/

コンフィギュレーション機能

Fabricに追加されたContainerにどのような設定、もしくは機能を持たせるかは「プロファイル」に定義されています。具体的に、「プロファイル」には以下の情報が格納されています。

コンテナレベルのシステムプロパティ情報

• Camelルート定義ファイル
• A-MQ設定ファイル
• MavenアーティファクトリポジトリのURL
• MavenアーティファクトのURL
• KarafフィーチャーリポジトリのURL
• KarafフィーチャーのURL
• ユーザー定義の各種リソースファイル（Java Properties、JSON、XML、YML）

代表的な「プロファイル」は以下の通りです。ユーザーはこれらのプロファイルを継承し、Containerの提供機能をカスタマイズできます。

karaf

コンテナとして動作する最小限の「karaf」と「fabric-agent」機能と設定が含まれる。

feature-camel

karafプロファイルから継承し、Camelルートに必須の「camel-core」と「camel-blueprint」機能と設定が含まれる。Camelルートをコンテナに配置する場合、このプロファイルを継承し、CamelルートのXMLファイルを置き換えることを推奨します。Camelルート用プロファイルの具体例は、本連載「第6回：JBoss Fuseを使ってみる その4：A-MQ」で紹介された”file-listener”をご参照ください。

feature-cxf

karafプロファイルから継承し、WEBサービス（CXFベース）に必要となるコア機能と設定が含まれる。

mq-base

karafプロファイルから継承し、メッセージキュー（A-MQ）の機能が含まれる。A-MQのカスタムには、このプロファイルを継承し、A-MQ設定ファイルを置き換えることを推奨します。A-MQ用プロファイルの具体例は、本連載「第6回：JBoss Fuseを使ってみる その4：A-MQ」で紹介された”mq-broker-default.mybroker”をご参照ください。

図6：Config Registryとプロファイルの管理

Fabric提供のプロファイル、およびユーザーがカスタマイズしたプロファイルは、Gitベースの「Config Registry」に格納され、バージョン管理されます。プロファイルは、Fabric Server上のRegistry Serviceによって、Container上のAgent経由でContainerへ展開されます。そしてContainerがプロファイルに含まれるプロパティを適用してサービス（例えば、Camelルート）を開始します。また、Fabric Serverは複数バージョンのプロファイルを管理しているため、Containerを特定バージョンに戻すことも容易です。

集中管理機能

Fabric Serverは、物理・仮想・クラウドのサーバーリソースをContainerとして追加し、プロファイルをContainerへ展開します。その後、Containerが機能を提供し始めます。また、Containerは自身のランタイム情報（ステータス、IP、リソース、エンドポイントなど）を常にFabric Serverへ更新します。Fabric Serverは、Runtime RegistryにContainerのランタイム情報を格納しながら、同じEnsembleにある他のFabric Serverへも複製を行います（図7）。

図7：Runtime Registryとランタイムの集中管理

このように、Fabricはランタイム情報をレジストリにて集中管理しており、新しくContainerが追加されても、その所在が分かります。そのため、Ensemble上のどのFabric Serverの管理コンソールへ接続しても、全てのコンテナ情報を取得／制御ができるようになります。

大規模な負荷分散とホットスタンバイ構成

ここまで、Fabricによる大規模な連携基盤が抱える課題の解決方法を説明してきました。このFabricを「負荷分散とホットスタンバイ構成」と組みあわせるとどのようになるか、以下にご説明します。

図8：大規模な負荷分散とホットスタンバイの構成例

図8の構成は、Fabric Serverによって集中管理されたコンテナ群へ、連携サービス（CXF、Camel）とメッセージングシステム（A-MQ）のプロファイルを割り当て、負荷分散とホットスタンバイを併用したシステム構成になります。

同様の連携サービスのプロファイルを適用したコンテナを、複数同時起動します。また、メッセージングシステムとして働き、「共有データストア」に設定されたA-MQコンテナも複数用意し、最初に起動されるA-MQコンテナがFabricのRuntime Registryへ自身のステータスを登録することによって、A-MQのMaster系として稼働します。Master系のコンテナが使用不可になった場合、Slave系が自動的にMaster系に昇格し、メッセージキューの滞留メッセージを継続処理させられる構成です。

「Fabric＋負荷分散とホットスタンバイ」の利点

1. Slave系A-MQが起動して待機するため、前述の「ホットスタンバイ構成」に比べ、サービスの停止時間が短縮されます。
2. オンプレミス環境、プライベートクラウド、パブリッククラウドにまたがるハイブリッドな連携基盤を構築できます。またシステム構成の変更に即座に対応でき、集中管理により運用・保守の効率が向上します。

「Fabric＋負荷分散とホットスタンバイ」の欠点

Fuse Fabricという新技術の習得が必要になります。