オンプレミスとクラウドの導入比較
オンプレミスの IBM® App Connect Enterprise 環境から、 IBM の App Connect （ webMethods Hybrid Integration ）へワークロードを移行する前に、責任の所在、アーキテクチャ、構成、および実行時の動作の違いについて理解しておく必要があります。
責任
App Connect これは、完全に管理されたSaaS（ SaaS ）サービスです。 IBM インフラの提供および保守を担当しています。 App Connect のユーザーとして、統合ランタイムやメッセージフローの設計およびデプロイを含む、統合コンテンツについては、ユーザー自身の責任となります。 統合ランタイムの作成、設定、およびアップグレードについては、 IBM と共同で責任を負います。 この責任分担モデルにより、これまでユーザーが管理していた運用タスクの一部が、サービスによって自動的に処理されるようになります。 その他のタスクは、サービスAPIおよびユーザーインターフェースを通じて管理されます。
詳細については、 「 webMethods Hybrid Integration の責任の概要」を参照してください。
ソリューション・アーキテクチャー
App Connect Amazon Web Services ( AWS ) および Microsoft Azure に展開されており、管理機能と統合ワークロードを分離しています。 本サービスは、管理および作成のためのマルチテナント型コントロールプレーンを提供します。 データプレーンは、テナントごとに専用のランタイムコンポーネントを提供することで、ワークロードの分離を実現します。 このサービスは3つのアベイラビリティゾーンに展開されており、高可用性と自動フェイルオーバーを実現しています。
実行時モデル
App Connect Enterprise のオンプレミス展開では、通常、統合機能は統合ノードが管理する統合サーバーに展開されます。 App Connect では、1つ以上の統合ランタイムを作成します。これらは機能的には統合サーバーと同等です。
App Connect の統合ランタイムはコンテナベースかつ宣言型であり、定義されたランタイム構成を通じて管理されます。 ランタイムを作成または更新する際は、適切な構成を定義します。 その後、このサービスはブルー・グリーン ・デプロイメントの手法を用いて、ランタイムのプロビジョニングまたは更新を行います。 このアプローチでは、サービスはランタイムの新しいバージョンを作成し、処理を中断させることなくトラフィックをそちらに切り替えます。
詳細については、 「ランタイムの作成」 を参照してください。
実行時の再起動と調整
App Connect 統合ランタイムの更新や新しい統合のデプロイを行う際、ダウンタイムゼロの照合プロセスを採用しています。
ランタイム構成を更新したり、別の統合機能をデプロイしたりすると、システムは更新された構成を持つランタイムの新しいインスタンスを作成します。 新しいインスタンスが起動している間も、既存の実行環境はリクエストの処理を継続します。 新しいインスタンスの準備が整うと、システムは新しいリクエストをそのインスタンスに転送し、以前のインスタンスを正常にシャットダウンします。 シャットダウン中、システムは直前のランタイムインスタンスにシグナルを送信し、終了する前に処理中のリクエストを完了できるようにします。 この動作により、既存のフローが中断されることなく処理を完了できるようになります。 ほとんどの流れは、正常なシャットダウン期間内に完了します。 ただし、長時間実行される処理は、完了する前に中断される可能性があります。
コンテナー・ベースのデプロイメント
- デプロイメントの分離
- コンテナ展開では、通常、統合機能のグループは、従来の単一で一元化された
ブローカー
展開ではなく、それぞれ独自のコンテナランタイムに個別に展開されます。 このアプローチには利点がある一方で、計画上の配慮も必要となる。 - リソース割り振り
- CPUとメモリは、各ランタイムごとに設定されます。 ランタイムは、ワークロードの要件に合わせて個別に構成およびスケーリングされ、リソース消費を管理します。
- 実行時のバージョン管理
- 各ランタイムには独自の製品ランタイムが含まれているため、サポート対象の異なるバージョンでランタイムを作成し、それぞれを個別にアップグレードすることができます。
- 宣言型設定
- 統合機能をランタイムにデプロイする前に、デプロイ後のコマンドを使用するのではなく、ランタイムの設定を行います。
既存の統合機能を移行する際は、 App Connect の統合ランタイムに対して、それらをどのようにグループ化し、デプロイするかを決定してください。 一般的な出発点として、既存のオンプレミス環境をミラーリングすることが挙げられます。 たとえば、統合サーバーや実行グループから、単一のランタイムに統合機能をデプロイすることができます。
App Connect また、より柔軟な導入パターンも可能にします。 ワークロードの特性、可用性の要件、アップグレードの頻度、コスト面などの要因に基づいて、統合機能を複数のランタイムに分割することができます。 各ランタイムにはコストがかかるため、運用上の分離とリソースの効率的な利用とのバランスをとることが必要です。
構成のマッピングと依存関係
オンプレミス環境では、統合ランタイムは、 ODBC の設定ファイルやキーストアなど、ホストシステム上に存在するファイルを利用し、`` mqsichangeproperties などのコマンドを使用して設定されることがよくあります。
- mqsichangeproperties
server.conf.yamlApp Connect Enterprise コマンドを使用して設定する項目のほとんどを設定します。例えば、 setdbparms.txt統合ランタイムで実行するコマンドの mqsisetdbparms 詳細を説明します。Policy projectポリシープロジェクト内でポリシーを作成し、実行時にメッセージフローやノードの動作を制御します。KeystoreまたTruststore、ランタイムやメッセージフローが使用するためのキーストアとトラストストアを提供します。Generic filesランタイムやメッセージフローが参照するための汎用ファイルを提供します。
移行前に、外部ファイルへの依存関係やランタイムプロパティを特定し、それらが適切な App Connect の設定タイプにマッピングされていることを確認してください。
詳細については、 「構成タイプ」 を参照してください。
オンプレミスシステムとの連携
- ポート転送
- ポートフォワーディングを設定することで、プライベートネットワーク内のアプリケーションやシステムへの安全な接続を実現できます。 App Connect の各テナントには専用のスイッチサーバー が割り当てられており、これは App Connect 内のランタイムと通信を行います。 プライベートネットワーク内でセキュアエージェントをダウンロードして実行します。 エージェントは、お客様のサービスインスタンスに関連付けられているスイッチサーバーへのアウトバウンド接続を確立します。 この接続により、ファイアウォールで受信ポートを開く必要なく、双方向の通信が可能になります。 接続は、双方の TLS によって保護されています。
ポート転送の一般的な用途として、オンプレミスのデータベースや IBM MQ と通信することが挙げられます。 ただし、ポートフォワーディングを利用すれば、他のネットワークやパブリッククラウド上のアプリケーションやシステムと連携させることも可能です。
詳細については、 「スイッチサーバー経由でプライベートネットワークに接続する」 を参照してください。
- 呼び出し可能なフロー
- Callable Flowsでは、オンプレミスおよび App Connect 上で実行されているフローを接続するために、Switch Serverも使用されます。 たとえば、プライベートネットワーク上で App Connect Enterprise フローを実行し、 App Connect でホストされているフローからそのフローを直接呼び出すことができます。 フローに「Callable Flow Input」ノードを追加し、スイッチサーバーへの接続情報を指定して、そのフローをランタイムにデプロイすることができます。 その後、そのフローは登録され、同じスイッチサーバーに接続されている他のフローから利用可能になります。 App Connect Designer および IBM App Connect Enterprise Toolkit では、呼び出し可能なフローノードとコネクタが利用可能であり、DesignerのフローからToolkitのフローを呼び出したり、その逆を行ったりすることができます。 コール可能なフローは、 SAP との連携や、アプリケーションに近い場所でデータを処理したい場合に一般的に使用されます。
詳細については、 「Callable flows の概要」 を参照してください。
- AWS PrivateLink
- AWS PrivateLink App Connect と、お客様の Amazon Web Services （ AWS ）アカウント内のVirtual Private Cloud（VPC）との間で、パブリックIPアドレスやインターネットを経由せずに、プライベートネットワーク接続を提供します。 AWS PrivateLink を使用するには、インターフェース型 Virtual Private Cloud (VPC) エンドポイントと、Amazon Route 53 のプライベートホストゾーンを作成します。 データは、インターネットではなく AWS ネットワークを利用して、非公開で転送されます。 App Connect AWS PrivateLink を使用した送受信通信に対応しています。 通信は一方向であるため、受信トラフィックと送信トラフィック用にそれぞれ個別の接続を作成する必要があります。 AWS PrivateLink の一般的な利用シナリオとして、Virtual Private Cloud（VPC）内で AWS サービスを有効化し、インバウンドのプライベートリンクを介して App Connect との連携をトリガーすることが挙げられます。 同様に、 App Connect の統合機能では、アウトバウンドのプライベートリンクを介して AWS のサービスにアクセスすることができます。
詳細については、 「 AWS PrivateLink を使用した AWS サービスへの接続 」を参照してください。
セキュアエージェントを使用しない場合は、ファイアウォールを設定して、プライベートネットワークへの接続を許可したり、IP許可リストを使用するアプリケーションへの接続を許可したりすることができます。 App Connect が外部への接続に使用するIPアドレスの一覧については、 『 webMethods Hybrid Integration 』のドキュメントにある 「Outbound IP addresses」 を参照してください。
可用性とスケーラビリティ
App Connect 各リージョン内の複数のアベイラビリティゾーンに展開され、高可用性と自動フェイルオーバーを実現しています。 耐障害性を高めるために、統合ランタイムのレプリカを複数設定することができます。 このサービスは、レプリカをアベイラビリティゾーン全体に分散させ、あるゾーンが利用できなくなった場合にランタイムを自動的に再スケジュールします。
移行を計画する際は、連携機能の可用性要件を確認し、必要に応じて、それらの要件を満たすよう複数のランタイムレプリカを設定してください。
アップグレードの動作とバージョン管理
IBM 基盤となる App Connect プラットフォームのインストールおよびアップグレードを管理します。 ランタイムを作成する際に、サポートされているランタイムのバージョンから選択することで、各統合ランタイムが使用するバージョンを制御できます。
選択したバージョンオプションによっては、新しいフィックスパックや修正リリースが利用可能になった際に、ランタイムが自動的にアップグレードされる場合があります。 本番環境に適用する前に、自動アップグレードを行うか、それとも新しいバージョンをテストするためのより詳細な制御を行うかを選択してください。
詳細については、 「統合ランタイムのバージョンの更新」 を参照してください。
CI/CDパイプライン
App Connect APIは、統合機能やランタイムのデプロイおよび管理に必要なすべての機能を提供します。 詳細については、 「APIの概要」 をご覧ください。
製品の制限事項と動作の違い
App Connect Enterprise のオンプレミス展開で利用可能な機能の一部は、 App Connect では利用できないか、動作が異なります。 その一例として、コンテナベースのデプロイメントにはデフォルトのローカルキューマネージャーが存在しないことが挙げられます。 詳細については、 「インポートされたBARファイルの既知の制限事項 」および「サポートされているリソース」を参照してください。