TAKAが試したこと考えたこと

システム連携基盤としてのESBの意義を書いてきましたが、意義が大きくなればなるほど停止時の被害は大きくなります。そのため、冗長性をもつ構成となることが必須条件となります。また負荷が高くなった場合にスケールアウトできる構成となる拡張性を持たせることも重要になります。メッセージによって振り分けがされる分散も必要です。

その意味でESBの拡張性として
・リプリケートされた複数ノード
・メッセージの分担が決定されている複数ノード
に分かれます。後者の場合は振り分けをしてくれるノードも必要となります。

mediateできるにも通じますが、そのフローの中でメッセージの変換ができると言うのも重要な機能になります。サービスの呼び出し側と受け側でＩＦを統一するにはＮｘＭ（呼び出し側Ｎ種類、呼び出し先Ｍ種類）の数だけＩＦが必要になってしまいます。そこでそれぞれＮ個とＭ個のＩＦを定義して、ＮｘＭ個の変換をＥＳＢ側に持たせることで対応することで、各システムはその知識を必要としないことが可能となります。

当然、その知識がＥＳＢ側に移動するだけですが、変換の知識だけなので同じような内容を毎回作成する必要もなくなりますし、影響範囲をＥＳＢ内にとどめることもでき、バージョン管理もCBRを利用して可能なため、システム側にあるよりもESB側にあるほうがふさわしいと考えることができます。デメリットとしてはESBの負荷が高まるというのがありますが、スケールアウトできる構成であれば負荷をどこに置くかという問題にすり替わるので問題ないと考えています。

いくつかのサービスを束ねて一つのサービスと見せることができる。

サービスの粒度を柔軟に変更するために必要な機能でデータサービスのレベルからビジネスとして価値を生み出す業務サービスまでの粒度の違いを吸収します。同期・非同期の変換もこの中でやるとよいでしょう。

但し、 ＢＰＥＬが守備範囲とするような業務フローレベルでのｍｅｄｉａｔｅは守備範囲外とみた方がよく、人間系の含まないレベルの統合がＥＳＢにおけるmediateの範囲とみた方が良いと思います。

非同期メッセージ基盤の3つの機能としてあげるのが、CBRです。これは入ってきたメッセージによって処理コンポーネント（サービス）を変えることができる機能です。

よくあるパターンでは、商品や受注の内容によって、外注したり、売上の立て方といった違いをこの機能で吸収します。あるいはインプットデータの中にバージョン番号を含めて、バージョンアップに対する実装を変えるといった進め方をする場合もあります。

ここでいう接続方式とは、Webサービス、MQ（JMS）、SMTP、RESTなどの技術的な手段を表しています。接続方式から、連携元・先を独立させることで連携元・先が変更・増加した場合でも影響を少なくすることができます。

通常、この方式をコネクターのようなもので実装し、何らかの設定ファイルでサービスの実装コンポーネントと結びつけてこの内容を実現します。このようなコネクタの提供およびサービスとの連結を実現ｄけいることが非同期メッセージ連携基盤として重要なことです。

企業システムの全体アーキテクチャには、非同期分散メッセージ基盤を中央に入れてシステム・サブシステム間連携の礎とするべきだと思うようになった。連携先・元の稼働状態（SLA）や変更に対する対応（システムの統廃合による移行も含む）、NxMといった連携本数の増加してしまう問題を考慮に入れるとシステム間には一層、層を設けてその影響範囲を吸収すべきと思う。

そのような分散基盤にどのような機能が必要なのかを考えてみようと思い、このエントリを書きました。しばらく続けますのでよろしくお願いします。

プロキシサービス

まず最初にプロキシーサービスを実現できる機能が必要かと思います。システムそのものは、サービスとアプリケーションに分かれます。アプリケーションは自由に作成され、簡単に改廃されますが

サービスは業務ルールの変更による改修以外はあまり変更されず、標準的な内容に昇華していきます。そのため、サービスの配置は柔軟にすべきです。しかし、アプリはサービスを利用しているのでプロキシのようなサービスを用いることで、配置を変えても影響しなくなります。UDDIのような技術で配置場所を検索しても実現できますがあとの記事で書こうと思っているシーケンスサービスをプロキシサービスとすることで呼び出すサービスとIDやメッセージ形態の違いを変換するサービスを挟み込むことができるようになるため、このような機能が必要です。

移行というと、レガシーシステムから利用しているデータを抽出して、新システムへデータを投入する「データ移行」が代表的です。

データ移行は、既存システムのデータスキーマ（抽出するデータフォーマット）と新システムのデータスキーマの形式・意味上の差異を把握し、その変換をおこなうことが主たる表の作業となります。

表と書いたのには理由があって、いわゆるデータクレジングという地道な作業が裏の作業としてあります。抽出したデータが矛盾のない、整合性のある、同じデータが複数ない（名寄せ）といった状態にして、移行プログラムで移行します。（既存、新システムとも止められないとなるとその差分の移行中のトランザクションデータをどうするといった問題もあったり、移行は一発でうまくいかないといったいろいろな問題もありますが、主たるという意味では上記のようにとらえることができます。）

どうしても、データ移行に意識がいきがちな移行ですが、新システムを使った新しい業務がスムーズに実行できるように考える業務移行というのも一つの移行ですし、システム化計画を考える場合には、システムがどう移行させていくかという観点の「システム移行」が大事になります。システム移行は、システムをリプレースされていく中で安全にリプレースできる仕掛けを用意することを考える必要があります。システム間が複雑に関連しあっている場合にビッグバンでやらずに一部だけを置き換えて他のシステムに影響与えないように、一層、層を設けて影響をその層で吸収するように工夫します。

移行は難しいですね。

Cloudera Distribution for Hadoopのインストール方法を拝見した。

コンフィグレーションを管理サイトで登録して、コンフィグレーション済みのパッケージングされたソフトをRPMとしてダウンロードしてインストールする。

Hadoopだからということではなく、コンフィグレーション管理のサービスが生まれ、クラウド上にカスタマイズされたソフトウェアをダウンロードしてクラウド上のノードで実行する。クラウドを移設することも可能になるだろうし、発展すれば、コンフィグレーションがプロファイルのようなものになり、どこで実行するのかはクラウドの価格やリソースなどで動的に変更できる。（データ移行もあるのでそう簡単ではないが）

そういう新しい時代のソフトウェア管理方法を見たような気がして、はっとさせられた。もちろん、HPC的なクラウドも、ガｰトナーの言うところの、CDA（Context Deliver Achitecture）のコンテキスト情報を扱う上で、重要な要素であることは間違えないのでおろそかにできないのだが、今日は別のことを感じた。