BizTalk Server から Azure Logic Apps Standard に移行する理由

Azure Logic AppsはBizTalk Serverの後継です。 Azure Logic Apps Standardは、クラウドおよびハイブリッドソリューション向けのワークフローオーケストレーション、エンタープライズ統合、拡張性を提供します。 この記事では、移行の理由、利用可能なホスティングオプション、そして評価すべきBizTalkの機能をまとめています。

移行戦略、計画上の考慮事項、納品ガイダンスについては、「Azure Logic Apps Migration AgentでBizTalk Serverを移行する」をご覧ください。

BizTalk Serverのライフサイクル

BizTalk Server 2020はBizTalk Serverの最終リリースです。 MicrosoftはBizTalk Server 2020の販売が2027年3月31日に終了すると見込んでいます。 主流のサポートは2028年4月12日まで続き、その後も製品はMicrosoftの固定ライフサイクルポリシーの対象となります。

Microsoftはまた、対象顧客に対して2028年4月13日から2030年4月10日まで、オプションで有料の拡張メインストリームサポートを提供する計画です。 この提供は一時的な移行補償を意図しており、一部のBizTalk機能は除外される予定で、最終的な適格性、補償内容、価格設定、購入条件の対象となります。

特に、ビジネスアクティビティモニタリング(BAM)、Enterprise Service Bus(ESB)ツールキット、業界アクセラレーター、レガシーエンタープライズアダプター、BizTalk専用のアプリケーションライフサイクル管理ツール、またはVisual Studio 2022以降のVisual Studioバージョンに依存している場合は、移行計画を早めに始めましょう。 これらの機能は有料の拡張メインストリームサポートから除外されるか、再設計が必要になる可能性があります。

最新の日付と用語については、以下をご覧ください:

• Microsoft BizTalk Server 製品ライフサイクルアップデート
• BizTalk Server 2020 終了発表
• Microsoft固定ライフサイクルポリシー

なぜLogic Apps StandardがBizTalkのワークロードに適合するのか

BizTalkアプリケーションは、耐久性のあるオーケストレーション、メッセージング、変換、B2B(企業間)処理、カスタムコード、プライベートシステムへのアクセスを組み合わせていることが多いです。 Azure Logic Apps Standardは、これらの統合機能をシングルテナントのランタイムで提供し、ステートフルおよびステートレスの両方のワークフローをサポートします。 消費ロジックアプリとは異なり、標準ロジックアプリは複数のワークフローを含み、計算、ストレージ、ネットワーク、設定を共有することができます。

以下の機能により、StandardはほとんどのBizTalk近代化プロジェクトで推奨されるLogic Appsリソースタイプとなっています:

Logic Apps Standardは、BizTalkソリューションの近代化に必要なほとんどのコア機能を提供し、Azure上でホストされる場合でもハイブリッド環境で展開される場合でも、ターゲットアーキテクチャの主要なオーケストレーションおよび統合プラットフォームとして機能します。 他のサービスはデフォルトで必須ではありません。 Azureホスティング型ソリューションの場合、リファクタリングされたソリューションが独立したメッセージブローカー、APIライフサイクル管理、イベント配信を必要とする場合にのみ、Azure Service Bus、Azure API Management、Azure Event GridなどのAzureサービスを追加してください。 ハイブリッド展開では、Logic Apps Standard以外の機能やアーキテクチャの境界に対して、互換性のある顧客管理サービスを使用してください。

移住の理由

コスト効率の良いターゲットアーキテクチャを構築する

コスト効率は作業量、必要な隔離、既存インフラ、コネクタの使用状況、運用上の責任によって異なります。 Logic Appsのホスティング料金だけでなく、総所有コストを比較してください。 BizTalkのベースラインには、BizTalk Server、Windows Server、SQL Serverライセンス、計算およびストレージ、高可用性および災害復旧、パッチ適用、監視、展開ツール、専門的な運用サポートが含まれます。

目標コストモデルを作成する際には以下の実践を用いてください:

• 互換性のあるセキュリティ、ライフサイクル、スケーリング要件を持つ関連ワークフローを同一のStandardロジックアプリにまとめ、予約済みの計算資源やサポートリソースを共有できるようにします。 独立したスケーリング、分離、デプロイ、または所有が必要なワークロードは、それぞれ分けておきましょう。
• 要件に合う内蔵コネクタ操作を好むのが良いでしょう。 標準モデルは無制限の組み込み操作実行を含み、管理されたコネクタ操作は通話ごとに請求されます。
• 適切な場合はワークフロースコープの.NETコードをローカル関数に残してください。 ローカル関数はLogic Apps Standardのアプリケーション境界を使用し、別途関数アプリ、エンドポイント、認証フロー、デプロイメントパイプライン、監視境界を必要としません。 標準プランでもコードは容量を消費しています。
• Workflow Service Plan の容量を適正化し、移行ウェーブが本番環境へ移行するに従って利用状況を確認します。 ワークフローが休止中でも、プランは予約容量に対して請求されます。
• 隔離、専用ネットワーク、コンプライアンス、統合の要件がアイソレーテッドv2 App Service Planを正当化する場合は、App Service Environment v3を使用してください。 ASE v3が小規模な作業負荷にとって最も低コストな選択肢だとは思わないでください。
• ローカル実行、データレジデンシー、または既存インフラが十分な価値を提供する場合にハイブリッドを活用しましょう。 計算にはAzure Arc対応のKubernetes環境、SQL Serverライセンス、SMBストレージ、ネットワーク、運用、Logic Apps vCPUの使用状況を含めてください。
• ストレージ運用、統合アカウント、ネットワーク、監視、そして移行中のBizTalkとLogic Appsを並行して実行する一時的なコストを考慮します。

価格の詳細については、Azure Logic Appsの価格設定および請求モデルおよびAzure Logic Appsの価格ページをご覧ください。

ホスティング オプションを選択する

Azure Logic AppsはConsumptionリソースタイプとStandardリソースタイプを別々に持っています。 BizTalkの移行には、Azure Logic Apps Standardの機能を使い、要件に応じてAzureホストかハイブリッドホスティングのどちらかを選択してください。

ハイブリッド展開の考慮事項

ハイブリッド展開は部分的に接続されており、エアギャップされていません。 この環境はAzure ArcおよびAzure管理運用のためにアウトバウンド接続を必要とします。 クラウドホストのマネージドコネクタもAzureへの接続が必要です。 一時的な接続中断は必ずしもローカルのワークフロー処理を停止させるわけではありませんが、管理、テレメトリ、クラウド依存の運用に影響を与える可能性があります。

必要なインフラストラクチャ、対応設定、価格設定、現在の制限については、「 ハイブリッド展開を使った標準ロジックアプリの自前のインフラを設定する」をご覧ください。

BizTalkの機能をロジックアプリにマッピング

BizTalk ServerとAzure Logic Appsは異なるアーキテクチャを使用しています。 Migration Agentを使って各BizTalkアプリケーションをインベントリ化し、そのアーティファクトや統合パターンをLogic Appsの機能にマッピングし、再利用、リファクタリング、置き換え、再設計が必要なコンポーネントを特定しましょう。

以下の図は、一般的なBizTalk Serverの機能とAzureホストのモダナイゼーション経路の別の視点を示しています:

詳細な機能の利用可能性については、Azure Logic Appsコネクター、エンタープライズ統合の概要、Azure Logic Appsの制限と設定を参照してください。

主な移住の考慮点

アーキテクチャと信頼性

• まずはAzure Logic Apps Standardをターゲットアプリケーションとして始めましょう。 適切な場合はネイティブワークフロー機能、組み込みコネクタ、ローカル機能を使い、特定のアーキテクチャ要件が正当化される場合にのみ他のAzure統合サービスを追加してください。
• 公開・購読パターンでは、ワークフロー内でBizTalkメッセージボックスを再現するのではなく、Azure Service Bus、RabbitMQ、Apache Kafkaなどのメッセージブローカーを使用してください。
• 再試行と少なくとも一度の処理を設計する。 冪等性、重複除去、セーフ書き込みを用いて、操作の再試行や実行の再提出時に重複効果を防ぎます。
• メッセージとコネクタの制限を確認してください。 大規模なペイロードの場合は、サポートされている場合はコネクタチャンクを使用するか、 クレームチェックパターンを実装してください。
• オンプレミスネットワークをAzureに接続するには、VPN Gateway、ExpressRoute、またはその他のハイブリッド接続設計を使用してください。 仮想ネットワークピアリングはAzureの仮想ネットワークを接続しますが、オンプレミスのネットワークをAzureに単独で接続するわけではありません。

カスタム コード

BizTalkソリューションにカスタムコードがあるからといって、ターゲットアーキテクチャに別途Azure Functionsリソースが必要になるわけではありません。 統合ワークフローに属するコードには.NETローカル関数を使いましょう。 ローカル機能はワークフローと同じプロジェクト内にあり、Logic Apps Standardのアプリケーション境界内で動作します。 ワークフロー、コネクター、設定、コードは一体化、展開、拡張、運用可能です。

ローカル関数はワークフロースコープに基づくメッセージ検証、強化、計算、カスタム解析、フォーマット作成、ビジネス固有の処理に適しています。 また、特定の統合アプリケーションに属するコードであれば、BizTalkのヘルパーアセンブリ、オーケストレーションユーティリティ、パイプラインに隣接するロジックの近代化も支援できます。 このアプローチは、ワークフロー固有のコードを実行するために、別途エンドポイント、認証フロー、ホスティングリソース、デプロイメントパイプライン、監視境界を導入するのを避けられます。

適切なコードホスティングモデルを選択するには、以下のガイダンスに従ってください:

ローカル関数は標準論理アプリに割り当てられた計算容量を消費し、すべての独立した機能やサービスの代替ではありません。 コストと運用上の優位性は、コードがワークフローの一部である場合に不要なリソースの境界を回避することにあります。 標準ワークフローは、短時間のコードのためにインラインJavaScript、C#、PowerShellをサポートし、カスタムコネクタや外部APIへの呼び出しも可能です。 アーキテクチャの指針については、「 Coding with Logic Apps Standard: Local Functions」を参照してください。

セキュリティと ID

Microsoft Entra ID、Azure RBAC、Azure Key Vault、プライベートネットワーキング、安全な入出力を使ってワークフローとデータを保護しましょう。 OAuth接続はトークンベースの認可を使用し、インタラクティブなサインインと同意が必要な場合があります。 OAuthをワークフローにユーザーのメールアドレスやパスワードを保存しているものとして扱わないでください。

Azureホスト型標準ワークフローでサポートされているコネクタでは、マネージドIDによって認証情報やアクセストークンの保存が不要になります。 ローカル開発中、Azure Logic Apps Standard拡張機能はサインインした開発者IDをAzure Identityの認証チェーンを通じて使用でき、展開されたワークフローはシステム割り当てまたはユーザー割り当てのマネージデンティティIDを使用します。 両方のアイデンティティはターゲットリソースに対して適切な権限を必要とします。 このVisual Studio Code機能は、コネクタ操作における管理ID認証の現在のハイブリッド制限を変えません。 詳細については、 Logic Apps Standard拡張機能の「Use connectors with managed identity(管理型識別元)」をご覧ください。

デプロイと運用

ワークフローの定義、設定、アーティファクトをソース管理に保存し、自動化されたビルドおよびデプロイパイプラインを使用します。 BicepはAzure Resource Managerテンプレートにコンパイルします。 TerraformとPulumiは、それぞれのプロバイダーを通じてAzureリソースを管理する代替インフラストラクチャ・アズ・コードツールです。

最初の本番移行の波に備えて、モニタリング、アクセス制御、環境設定、災害復旧、所有権のサポートを計画しましょう。 敏感なアクションの入力と出力を保護し、ラン履歴やテレメトリに表示されないようにしましょう。

次のステップ

インベントリ依存関係の反復的移行アプローチを用い、ワークロードの優先順位付け、ターゲット設計の検証、管理可能な段階でのリリース。 Azure Logic Apps Migration Agentは、アーキテクチャや実装の決定権を保持しながら、発見、分析、計画、変換、検証、展開を支援します。