Azure サービスは、最大限の可用性と信頼性を優先します。 ただし、ランダム なイベントは引き続き通信を中断または停止する可能性があります。 たとえば、ネットワークや名前解決の問題やエラー、一時的な応答不能などが発生する可能性があります。 これらの条件は、ディザスター リカバリーの状況で行う可能性があるリージョンデプロイを破棄するのに十分な深刻さではありません。 ただし、数分または数秒続く可用性の中断は、引き続きビジネスに影響を与える可能性があります。
このようなイベントによる Azure リソースへの影響を軽減するには、 レプリケーション タスクを作成して、リソース内のコンテンツをある Azure リージョンから別のリージョンにレプリケートします。 レプリケーション タスクは、あるリージョンのソース リソースから別のリージョンのターゲット リソースにデータ、イベント、またはメッセージを移動します。 ソースがオフラインになった場合、ターゲットが引き継ぐ可能性があります。
レプリケーション タスクを使用して、同じリージョン内のリソース間でコンテンツを移動することもできます。 ただし、リージョン全体が使用できなくなったり、中断が発生した場合は、ソース リソースとターゲット リソースの両方が影響を受ける可能性があります。
このガイドには、Azure Logic Apps を利用したレプリケーション タスクの概要が含まれています。 このガイドでは、例として Azure Service Bus キューのレプリケーション タスクを作成する方法も示します。
レプリケーション タスクとは
レプリケーション タスクは、Service Bus キューなどのソース リソースから、データ、イベント、メッセージなどのコンテンツを受信します。 次に、このコンテンツをターゲット リソースに移動し、ソースが Azure Event Hubs エンティティである場合を除き、ソースからコンテンツを削除します。 レプリケーション タスクは通常、変更なしでコンテンツを移動します。 これらのタスクもステートレスであるため、タスクの並列実行または順次実行間で状態やその他の副作用を共有することはありません。
使用可能なテンプレートを使用してレプリケーション タスクを作成すると、各レプリケーション タスクにはシングルテナント の Azure Logic Apps が使用されます。 バックグラウンドでは、Standard ロジック アプリ リソース内の ステートレス ワークフロー によって各タスクが実行されます。 ロジック アプリには、レプリケーション タスク用の複数のワークフローを含めることができます。
Note
Azure Logic Apps を利用したレプリケーション タスクには 、レプリケーション プロパティが含まれます。 ソースプロトコルとターゲットプロトコルが異なる場合、タスクはソースとターゲットのメタデータ構造間のマッピングを実行します。
Azure Logic Apps プラットフォームは、レプリケーションやフェデレーション タスクなど、サーバーレス アプリケーションを構成および実行するためのスケーラブルで信頼性の高いプラットフォームです。 シングルテナントの Azure Logic Apps のランタイムは 、Azure Functions 拡張機能モデル を使用し、Azure Functions ランタイムの拡張機能としてホストされます。 この設計により、ロジック アプリ ワークフローの移植性、柔軟性、パフォーマンスが向上します。 シングルテナントの Azure Logic Apps には、Azure Functions と Azure App Service エコシステムから継承されたその他の機能と利点も用意されています。
レプリケーションとフェデレーションの詳細については、次を参照してください。
- Event Hubs のマルチサイトとマルチリージョンのフェデレーション
- イベント レプリケーション タスクのパターン
- Service Bus メッセージ レプリケーションとリージョン間フェデレーション
- メッセージ レプリケーション タスクのパターン
レプリケーション タスク テンプレート
次の表に、 Azure Event Hubs と Azure Service Bus で使用できるレプリケーション タスク テンプレートの例を示します。
| リソースの種類 | レプリケーションのソースとターゲット。 |
|---|---|
| Azure Event Hubs 名前空間 | - Event Hubs インスタンスから Event Hubs インスタンスへ - Event Hubs インスタンスから Service Bus キューへ - Event Hubs インスタンスと Service Bus の関係に関する記事 |
| Azure Service Bus 名前空間 | - Service Bus キューから Service Bus キューへ - Service Bus キューから Service Bus トピックへ - Service Bus トピックから Service Bus トピックへ - Service Bus キューから Event Hubs インスタンスへ - Service Bus トピックから Service Bus キューへ - Service Bus トピックから Event Hubs インスタンスへ 重要: キューがソースの場合、レプリケーション タスクはメッセージをコピーしませんが、メッセージをソースからターゲットに移動し、ソースから削除します。 代わりにメッセージをミラー化するには、"main" サブスクリプションがキュー エンドポイントのように機能するトピックをソースとして使用します。 そうすることで、ターゲットはソースから各メッセージのコピーを取得します。 異なるリージョン間でメッセージをルーティングするには、アプリからメッセージを送信するキューを作成します。 レプリケーション タスクは、そのキューから、別のリージョンにある名前空間内のターゲット キューにメッセージを転送します。 また、転送キューとして機能するエンティティとしてトピック サブスクリプションを使用することもできます。 詳細については、「 ServiceBusCopy のレプリケーション トポロジ」を参照してください。 |
レプリケーション トポロジとワークフロー
次の図は、Standard ロジック アプリ ワークフローを利用した場合のレプリケーション タスクの動作を視覚化するために、Event Hubs インスタンスと Service Bus キューのレプリケーション タスクの構造とワークフローを示しています。
Event Hubs のレプリケーション トポロジ
次の図は、Event Hubs インスタンス間のトポロジとレプリケーション タスクのワークフローを示しています。
Event Hubs のメタデータとプロパティのマッピング
ターゲット Event Hubs 名前空間の新しいサービス割り当て値は、ソース名前空間の次の項目を置き換えます。
- イベントのサービス割り当てメタデータ
- 元のエンキュー時間
- Sequence number
- オフセット
ヘルパー 関数 と Azure 提供のサンプルのレプリケーション タスクの場合、元の値は次のユーザー プロパティに保持されます。
-
repl-enqueue-time(ISO8601文字列) repl-sequencerepl-offset
これらのプロパティは string 型であり、それぞれの元のプロパティの文字列化された値が含まれています。 複数回イベントが転送される場合は、直接のソースのサービスによって割り当てられたメタデータが既存のプロパティに追加され、値はセミコロンで区切られます。 詳細については、「 サービス割り当てメタデータ」を参照してください。
Azure Event Hubs でのレプリケーションとフェデレーションの詳細については、次を参照してください。
Service Bus のレプリケーション トポロジ
次の図は、Service Bus キュー間のトポロジとレプリケーション タスクのワークフローを示しています。
Service Bus のメタデータとプロパティのマッピング
Service Bus の場合、ターゲット Service Bus キューまたはトピック内の新しいサービス割り当て値によって、ソース キューまたはトピックの次の項目が置き換えられます。
- メッセージのサービス割り当てメタデータ
- 元のエンキュー時間
- Sequence number
Azure 提供のサンプルの既定のレプリケーション タスクでは、元の値は次のユーザー プロパティに保持されます。
-
repl-enqueue-time(ISO8601文字列) repl-sequence
これらのプロパティは string 型であり、それぞれの元のプロパティの文字列化された値が含まれています。 複数回メッセージが転送される場合は、直接のソースのサービスによって割り当てられたメタデータが既存のプロパティに追加され、値はセミコロンで区切られます。 詳細については、「 サービス割り当てメタデータ」を参照してください。
Azure Service Bus でのレプリケーションとフェデレーションの詳細については、次を参照してください。
Service Bus と Event Hubs の間のメタデータとプロパティのマッピング
タスクが Service Bus から Event Hubs にレプリケートする場合、そのタスクは User Properties プロパティのみを Properties プロパティにマップします。 タスクが Event Hubs から Service Bus にレプリケートされると、タスクは次のプロパティをマップします。
| Event Hubs から | Service Bus へ |
|---|---|
| ContentType | ContentType |
| CorrelationId | CorrelationId |
| MessageId | MessageId |
| パーティション キー | パーティションキー セッションID |
| プロパティ | ユーザー プロパティ |
| ReplyTo | ReplyTo |
| ReplyToGroupName | ReplyToSessionId |
| サブジェクト | Label |
| ターゲット | ターゲット |
順序の維持
Event Hubs の場合、同じ数の パーティション 間のレプリケーションでは、イベントに変更を加えずに 1 対 1 の複製が作成されますが、重複を含めることもできます。 異なる数のパーティション間のレプリケーションでは、パーティション キーに基づいてイベントの相対順序のみが保持されます。 結果には重複を含めることもできます。 詳細については、「 ストリームと注文の保持」を参照してください。
Service Bus の場合は、セッションを有効にする必要があります。 ソースから同じセッション ID を持つメッセージ シーケンスは、バッチとしてターゲット キューまたはトピックに送信されます。 メッセージは元のシーケンスにあり、同じセッション ID を持ちます。 詳細については、「 シーケンスと注文の保持」を参照してください。
重要
レプリケーション タスクでは、ソースで破壊的なイベントが発生したときに以前に処理されたメッセージは追跡されません。 既に処理されたメッセージを再処理しないようにするには、既に処理されているメッセージを追跡し、未処理のメッセージで処理を再開する方法を設定します。
たとえば、各メッセージの処理状態を保存するデータベースをセットアップすることが考えられます。 メッセージが到着したら、その状態をチェックし、メッセージが未処理である場合のみ処理を行うようにします。 そうすることで、処理済みのメッセージは処理の対象から除外されます。
このパターンは アイデンポテンス の概念を表しています。 入力に対してアクションを繰り返すと、同じ結果が生成され、他の副作用が発生したり、入力の値が変更されたりすることはありません。
レプリケーション タスクを作成できる Azure サービスの複数サイト フェデレーションと複数リージョンフェデレーションの詳細については、次を参照してください。
- マルチサイトとマルチリージョンのフェデレーション
- イベント レプリケーション タスクのパターン
- メッセージ レプリケーションとリージョン間フェデレーション
- メッセージ レプリケーション タスクのパターン
前提条件
Azure アカウントとサブスクリプション。 無料の Azure アカウントを取得します。
ソースとターゲットのリソースまたはエンティティ。
ソースとターゲットが異なる Azure リージョンにあることを確認します。 そうすることで、地理的災害復旧のフェイルオーバーシナリオをテストできます。 これらのエンティティは、使用するタスク テンプレートによって異なります。 このガイドの例では、異なる名前空間と Azure リージョンにある 2 つの Service Bus キューを使用します。
レプリケーション タスクの作成時に再利用できる空の Standard ロジック アプリ リソース。 これにより、レプリケーション タスク用にこのリソースをカスタマイズできます。
ロジック アプリ リソースを事前に作成する理由とベスト プラクティスを次に示します。
容量、スループット、スケーリングなどのレプリケーション シナリオのニーズに基づいて、ロジック アプリの ホスティング プランと価格レベルを選択 できます。
レプリケーション タスクを作成するときにロジック アプリを作成することはできますが、タスクの作成時にリージョン、ホスティング プラン、価格レベルを変更することはできません。
レプリケーション タスクのソース エンティティとターゲット エンティティとは異なるリージョンにロジック アプリを作成できます。
現在、このガイダンスは、Azure リソース内のレプリケーション タスクのネイティブ統合に起因して提供されています。 エンティティ間のレプリケーション タスクを作成し、既存のロジック アプリ リソースを使用するのではなく、新しいものを作成することを選択すると、"新しいロジック アプリはソース エンティティと同じリージョンに作成されます"。 ソース リージョンが利用できなくなった場合、レプリケーション タスクも機能しなくなります。 フェールオーバーのシナリオでは、タスクは、以前はターゲット エンティティであった新しいソースからのデータの読み取りを開始することもできませんが、これは、アクティブ/パッシブ レプリケーション パターンが達成しようとするものです。
このロジック アプリ リソースは、既定の属性を使用するのではなく、ホスティング プランと価格レベルを選ぶことで、事前にカスタマイズできます。 そうすることで、レプリケーション タスクが 1 秒間に処理できるイベントやメッセージの数が増え、より高速なレプリケーションが実現します。 このリソースを作成すると、レプリケーション タスクを作成するときに、これらの既定の属性が固定されます。
特にアクティブ/パッシブのレプリケーション パターンを使用する場合は、このロジック アプリ リソースに "レプリケーション タスクのワークフローのみ" が含まれるようにすることができます。 既存のロジック アプリを使用してレプリケーション タスクを作成する場合、このオプションを使用すると、そのロジックアプリ リソースにタスク (ステートレス ワークフロー) が追加されます。
詳細については、「 Azure portal を使用して標準ロジック アプリ ワークフローを作成する」を参照してください。
省略可能: ターゲット名前空間の接続文字列。 このオプションを使用すると、サブスクリプション間のレプリケーションを設定できるように、ターゲットを別のサブスクリプションに配置できます。
ターゲット エンティティの接続文字列を見つけるには、これらの手順を実行します。
Azure portal でターゲットの名前空間に移動します。
名前空間のサイドバー メニューの [設定] で、[ 共有アクセス ポリシー] を選択します。
開いた [共有アクセス ポリシー ] ページの [ ポリシー] で、 RootManageSharedAccessKey を選択します。
[SAS ポリシー: RootManageSharedAccessKey] ウィンドウで、[プライマリ接続文字列] の値をコピーします。
後で使用してターゲット名前空間に接続できるように、接続文字列を保存します。
名前付け規則
レプリケーション タスクまたはエンティティに使用する名前付け戦略を慎重に検討してください。 名前の識別と区別が簡単であることを確認します。 たとえば、Event Hubs 名前空間を使用している場合、レプリケーション タスクは、ソース名前空間のすべての Event Hubs インスタンスからレプリケートを行います。 Service Bus キューを使用している場合は、次の表で、エンティティとレプリケーション タスクの名前付けの例を確認できます。
| ソース名 | 例 | レプリケーション アプリ | 例 | ターゲット名 | 例 |
|---|---|---|---|---|---|
名前空間: <name>-sb-<region> |
fabrikam-sb-weu |
ロジック アプリ: <name-source-region-target-region> |
fabrikam-rep-weu-wus |
名前空間: <name>-sb-<region> |
fabrikam-sb-wus |
キュー: <name> |
jobs-transfer |
ワークフロー: <name> |
jobs-transfer-workflow |
キュー: <name> |
jobs |
レプリケーション タスクを作成する
この例では、Service Bus キューのレプリケーション タスクを作成する方法を示します。
Azure portal で、ソースとして使用する Service Bus 名前空間を見つけます。
名前空間サイドバー メニューの [Automation ] セクションで、[ タスク] を選択します。
[タスク] ページで、[タスクの追加] を選択して、タスク テンプレートを選択できるようにします。
[ タスクの追加 ] ページの [ テンプレートの選択] で、作成するレプリケーション タスクのテンプレートで [選択] を選択 します。 次のページが表示されない場合は、[次へ: 認証] を選びます。
この例では、 Service Bus キューからキューへのレプリケート タスク テンプレートを使用します。これにより、Service Bus キュー間でコンテンツがレプリケートされます。
[ 認証 ] タブの [ 接続 ] セクションで、タスクに表示されるすべての接続の 作成 を選択します。 すべての接続の認証資格情報を指定します。 各タスクの接続の種類は、タスクによって異なります。
この例では、ターゲット キューが存在するターゲット Service Bus 名前空間への接続を作成するためのプロンプトを示します。 この接続は、ソース Service Bus 名前空間に存在します。
ターゲットに関する必要な情報を指定し、[作成] を選びます。
この例では、接続の表示名を指定し、ターゲット キューが存在する Service Bus 名前空間を選びます。
ヒント
代わりに接続文字列を使用して接続を作成できます。 このオプションを使用すると、サブスクリプション間のレプリケーションを設定できるように、ターゲットを別のサブスクリプションに配置できます。 ターゲット (レプリケーション タスクの作成を開始した場所に基づくソース) は動的に構成されるため、ターゲットのみを接続する必要があります。 接続文字列を使用するには、次の手順を使用します。
[接続] ペインで、[接続文字列を使用して接続する] を選びます。
[接続文字列] ボックスに、ターゲットの名前空間の接続文字列を入力します。
次の例は、正常に作成された接続を示しています。
すべての接続を完了したら、[次へ: 構成] を選びます。
[構成] タブで、タスクの名前と、タスクに必要なその他の情報を指定します。
Note
作成後にタスク名を変更することはできません。 基になるワークフローを編集する場合は、引き続き適用される名前を検討してください。 基になるワークフローに加えた変更は、タスク テンプレートではなく、作成したタスクにのみ適用されます。
たとえば、タスクに
fabrikam-rep-weu-wusという名前を付けた後で、基になるワークフローを別の目的で編集した場合、タスク名が一致するように変更することはできません。タスク ワークフローを既存の Standard ロジック アプリに追加するには、 ロジック アプリ の一覧からそのロジック アプリを選択します。 代わりに新しい Standard ロジック アプリ リソースを作成するには、 ロジック アプリ の一覧で [ 新規作成] を選択し、新しいロジック アプリに使用する名前を指定します。
Note
レプリケーション タスクの作成時に新しいロジック アプリ リソースを作成すると、ロジック アプリは ソース エンティティと同じリージョンに作成されます。 この状況は、ソース リージョンが使用できなくなり、フェールオーバー シナリオでは機能しない場合に問題になります。 ベスト プラクティスは、ソースとは異なるリージョンに Standard ロジック アプリを作成することです。 レプリケーション タスクを作成するときは、代わりに既存のロジック アプリを選び、基になるステートレス ワークフローを既存のロジック アプリに追加します。 詳細については、「 前提条件」を参照してください。
完了したら、[確認および作成] を選択します。
[ 確認と作成 ] タブで、レプリケーション タスクで操作に必要な Azure リソースを確認します。
レプリケーション タスク用に新しいロジック アプリ リソースを作成することを選択した場合は、レプリケーション タスクが動作するために作成する必要な Azure リソースがタブに表示されます。
たとえば、これらのリソースには、ロジック アプリ リソース、ワークフロー、およびその他のランタイム操作の構成情報を含む Azure Storage アカウントが含まれます。 Event Hubs では、このストレージ アカウントにはチェックポイント情報が含まれます。 また、ソース領域が中断された場合や使用できなくなった場合にソース エンティティが停止するストリーム内の位置または オフセット も含まれます。
次の例は、新しいロジック アプリを作成することを選んだ場合の [確認と作成] タブを示しています。
レプリケーション タスクに既存のロジック アプリ リソースを再利用することを選択した場合は、レプリケーションが動作するために再利用する Azure リソースがタブに表示されます。
次の例は、既存のロジック アプリを再利用することを選んだ場合の [確認と作成] タブを示しています。
Note
ソース、ターゲット、またはその両方が仮想ネットワーク上にある場合は、タスクの作成後にアクセス許可とアクセスを設定する必要があります。 このシナリオでは、ロジック アプリのワークフローがレプリケーション タスクを実行できるように、アクセス許可とアクセスが必要です。
準備ができたら、[作成] を選択します。
自動的にライブで実行されている作成したタスクが、[タスク] 一覧に表示されるようになりました。
ヒント
タスクがすぐに表示されない場合は、タスク一覧を最新の状態に更新するか、少し待ってから更新してください。 ツール バーの [更新] を選択します。
使用するリソースが仮想ネットワークの背後にある場合は、ロジック アプリのリソースとワークフローがそれらのリソースにアクセスするためのアクセス許可を忘れずに設定してください。
再試行ポリシーを設定する
レプリケーション関係の両側で可用性イベント中のデータ損失を回避するには、堅牢性を確保するために再試行ポリシーを構成します。 レプリケーション タスクの再試行ポリシーを構成するには、 再試行ポリシー と 、基になるワークフローを編集する手順を参照してください。
タスク履歴の確認
この例では、タスクのワークフロー実行履歴とその状態、入力、出力、およびその他の情報を表示する方法を示します。 Service Bus キュー レプリケーション タスクの例を引き続き使用します。
Azure portal で、確認するタスク履歴がある Azure リソースまたはエンティティを見つけます。
この例では、このリソースは Service Bus 名前空間です。
リソース サイドバー メニューの [設定] の [ Automation ] セクションで、[ タスク] を選択します。
[ タスク] ページで、確認するタスクを見つけます。 このタスクの [実行] 列で、[表示] を選択します。
この手順では、Standard ロジック アプリ リソースの基になるステートレス ワークフローのデザイナーを開きます。
ステートレス ワークフローの実行履歴を表示するには、ワークフロー サイドバーの [ ツール] で [ 実行履歴] を選択します。
[ 実行履歴 ] タブには、タスクの前の実行、進行中、待機中の実行と、その識別子、状態、開始時刻、実行時間が表示されます。
次の表は、実行に対して可能性のある状態を示しています。
状態ラベル 説明 取り消し済み タスクは実行中に取り消されました。 Failed タスクには少なくとも 1 つの失敗したアクションがありますが、失敗を処理するための後続のアクションが存在しませんでした。 実行中 タスクは現在実行中です。 Succeeded アクションはすべて成功しています。 アクションが失敗した場合でもタスクは正常に完了しますが、失敗を処理するための後続のアクションが存在していました。 待機中 実行はまだ開始されていません。タスクの以前のインスタンスがまだ実行中であるため、一時停止しています。 実行の各ステップ、その状態、およびその他の情報を表示するには、その実行を選択します。
実行の詳細ページが開き、基になるワークフローで実行された各ステップが表示されます。
ワークフローは、常にトリガーで開始されます。 このタスクでは、ワークフローは、ソース Service Bus キューにメッセージが到着するのを待機する Service Bus トリガーで開始されます。
各ステップには、状態と実行継続時間が表示されます。 実行時間が0秒の手順は、実行に1秒未満かかりました。
各ステップの入力と出力を確認するには、ステップを選択します。
このアクションにより、そのステップの入力、出力、およびプロパティの詳細を表示するウィンドウが開きます。
次の例は、Service Bus トリガーの入力、出力、およびプロパティを示しています。
Azure リソースのレプリケーション タスクのコンテキストとは別に、アプリ、データ、サービス、システムを統合するための独自の自動化されたワークフローを構築できます。 「標準ロジック アプリ ワークフローの作成」を参照してください。
レプリケーション タスクを監視する
レプリケーション タスクまたは基になるロジック アプリ ワークフローのパフォーマンスと正常性を確認するには、 Application Insights を使用します。 Azure Monitor には、この機能が用意されています。
アプリケーション マップは、レプリケーション タスクの監視に使用できる便利なビジュアル ツールです。 Azure Monitor は、キャプチャされた監視情報からこのマップを自動的に生成します。 レプリケーション タスクのソースとターゲットの転送のパフォーマンスと信頼性を調べることができます。 すぐに診断分析情報を取得し、ログの詳細を低待機時間で視覚化するには、 Live Metrics ポータル ツールを使用できます。 このツールは、Azure Monitor の一部でもあります。
タスクを編集する
タスクを変更するには、オプションを選択します。
タスクをインラインで編集 して、接続情報や構成情報などのタスクのプロパティを変更します。
デザイナーで、タスクの基になるワークフローを編集します。
タスクをインラインで編集する
Azure portal で、更新するタスクを含むリソースを見つけます。
リソース サイドバー メニューの [Automation ] セクションで、[ タスク] を選択します。
[タスク] 一覧で、更新するタスクを見つけます。 タスクの省略記号 (...) メニューを開き、[インラインで編集] を選択します。
既定では、[認証] タブが表示され、既存の接続が表示されます。
新しい認証資格情報を追加したり、接続に対して別の既存の認証資格情報を選択したりするには、接続の省略記号 (...) メニューを開きます。 [ 新しい接続の追加] を選択するか、使用可能な場合は別の認証資格情報を選択します。
Note
編集できるのは、ソース接続ではなく、ターゲット接続のみです。
その他のタスクのプロパティを更新するには [次へ: 構成] を選びます。
この例のタスクでは、異なるソースとターゲットのキューを指定できます。 ただし、タスク名、基になるロジック アプリとワークフローは同じままです。
終了したら、[保存] を選択します。
タスクの基になるワークフローの編集
レプリケーション タスクの背後にある基になるワークフローを編集できます。 編集によって、作成したタスクの元の構成が変更されますが、タスク テンプレート自体は変更されません。 変更を加えて保存すると、編集したタスクは元のタスクと同じ機能を実行しなくなります。 元の機能を実行するタスクが必要な場合は、同じテンプレートを使って新しいタスクを作成する必要が生じる場合があります。
元のタスクを再作成しない場合は、デザイナーを使用してタスクの背後にあるワークフローを変更しないでください。 代わりに、統合のニーズを満たす標準ロジック アプリ リソースとステートレス ワークフローを作成します。 詳細については、「 標準ロジック アプリ ワークフローの作成」を参照してください。
Azure portal で、更新するタスクを含むリソースを見つけます。
リソース サイドバー メニューの [ Automation] で、[タスク] を選択 します。
[タスク] 一覧で、更新するタスクを見つけます。 タスクの省略記号 (...) メニューを開き、[Open in Logic Apps]\(Logic Apps で開く\) を選択します。
Azure portal は、ワークフローを編集できるデザイナーにコンテキストを変更します。
ワークフローのトリガーとアクションを編集できます。
トリガーまたはアクションのプロパティを表示するには、そのトリガーまたはアクションを選びます。
トリガーまたはアクションの情報ウィンドウが開きます。 トリガーまたはアクションのプロパティを編集できます。
次の例では、ワークフローに関する説明をトリガーに追加します。
変更を保存するには、デザイナーのツール バーで [保存] を選択します。
更新されたワークフローをテストして実行するには、デザイナーのツール バーで [ 実行>実行] を選択します。
実行が完了すると、デザイナーにワークフローの実行の詳細が表示されます。
各ステップの入力と出力を確認するには、ステップを選択します。これにより、そのステップの入力、出力、およびプロパティの詳細を示すペインが開きます。
次の例は、選択した Service Bus トリガーの入力、出力、およびプロパティを示しています。
タスクが引き続き実行されないようにワークフローを無効にするには、ワークフロー サイドバーの [構成] で [設定] を選択します。 [ワークフローの状態] ボックスの一覧から [無効] を選択します。
詳細については、「 デプロイされたロジック アプリを無効または有効にする」を参照してください。
Azure Event Hubs のフェールオーバーを設定する
同じエンティティの種類間の Azure Event Hubs レプリケーションの場合、geo ディザスター リカバリーでは、ソース エンティティからターゲット エンティティにフェールオーバーする必要があります。 その後、このプロセスは、影響を受けるイベント コンシューマーとプロデューサーに、ターゲット エンティティのエンドポイントを使用するように通知します。 ターゲット エンティティが新しいソースになります。
障害が発生し、ソース エンティティがフェールオーバーすると、コンシューマーとプロデューサー (レプリケーション タスクを含む) が新しいソースにリダイレクトされます。 レプリケーション タスクは、チェックポイント情報を含むストレージ アカウントを作成します。 ストレージ アカウントには、ソース リージョンが中断された場合や使用できなくなった場合にソース エンティティが停止するストリーム内の位置またはオフセットも含まれます。
元のソースからレガシ情報を手動でクリーンアップし、レプリケーション タスクを再構成します。 このアクションにより、ストレージ アカウントに元のソースからのレガシ情報が含まれていないことが保証されます。 また、レプリケーション タスクが新しいソース ストリームの先頭からイベントの読み取りとレプリケートを開始することも確認します。
Azure portal でロジック アプリ リソースを開き、レプリケーション タスクの基になるワークフローを開きます。
Note
ロジック アプリ リソースには、レプリケーション タスク ワークフローのみを含める必要があります。
ワークフロー サイドバー メニューの [ 構成] で、[ 設定] を選択します。 [ワークフローの状態] ボックスの一覧から [無効] を選択します。
レプリケーション タスクの基になるロジック アプリ リソースがソース エンティティからのチェックポイントとストリーム オフセット情報を格納するために使用するストレージ アカウントを見つけるには、次の手順に従います。
ロジック アプリのサイドバー メニューの [設定] で、[ 環境変数] を選択します。
[ 環境変数 ] ページの [ アプリ設定 ] タブで、 AzureWebJobsStorage アプリ設定を見つけて、[ 値の表示 ] を選択してストレージ アカウント名を表示します。
この設定は、ロジック アプリ リソースによって使用される接続文字列とストレージ アカウントを指定します。
次の例は、このストレージ アカウントの名前 ( storagefabrikamreplb0c) を検索する方法を示しています。
ストレージ アカウント リソースが存在することを確認するには、Azure portal の検索ボックスに名前を入力します。 ストレージ アカウントを選択します。
次の手順を使用して、ソース エンティティのチェックポイントとオフセット情報を含むフォルダーを削除します。
最新バージョンをお持ちでない場合は、最新の Azure Storage Explorer デスクトップ クライアントをダウンロードし、インストールして開きます。
Note
現時点では、削除のクリーンアップ タスクに Azure Storage Explorer クライアントを使用する必要があります。Azure portal の管理エクスペリエンス、ストレージ エクスプローラー、ブラウザー、エディターは "使用できません"。
PowerShell
Remove-AzStorageDirectoryコマンドを使用してコンテナー フォルダーを削除することはできますが、このコマンドは 空 のフォルダーでのみ機能します。まだサインインしていない場合は、Azure アカウントを使用してサインインします。 ストレージ アカウント リソースの Azure サブスクリプションが選択されていることを確認します。 詳細については、「Storage Explorer の概要」を参照してください。
エクスプローラー ウィンドウで、該当する Azure サブスクリプション名から、[ストレージ アカウント]>[{your-storage-account-name}]>[BLOB コンテナー]>[azure-webjobs-eventhub] の順に移動します。
Note
azure-webjobs-eventhub フォルダーが存在しない場合、レプリケーション タスクがまだ実行されていません。 このフォルダーは、レプリケーション タスクが少なくとも 1 回実行された後にのみ表示されます。
開いた azure-webjobs-eventhub ペインで、Event Hubs 名前空間フォルダーを選択します。 名前の形式は次のとおりです:
<source-Event-Hubs-namespace-name>.servicebus.windows.net。名前空間のフォルダーが開いたら、[azure-webjobs-eventhub] ペインで <former-source-entity-name> フォルダーを選択します。 ツール バーまたはフォルダーのショートカット メニューから、[削除] を選択 します。
以前のソース Event Hubs エンティティ フォルダーが選択され、[削除] が強調表示されていることを示すスクリーンショット。
フォルダーを削除することを確認します。
レプリケーション タスクの背後にあるロジック アプリのリソースまたはワークフローに戻ります。 ロジック アプリを再起動するか、ワークフローを再度有効にします。
プロデューサーとコンシューマーは、新しいソース エンドポイントを使用する必要があります。 新しいソース エンティティに関する情報を、簡単にアクセスして更新できる場所で使用できるようにします。 プロデューサーまたはコンシューマーは、頻繁に発生するまたは永続的なエラーを検出した場合、その場所を確認し、それらの構成を調整する必要があります。 その構成を共有するには、いくつかの方法があります。 DNS 共有とファイル共有が例です。
geo ディザスター リカバリーの詳細については、次のドキュメントを参照してください。
ホスティング プランのスケールアウト設定を編集する
Azure portal で、レプリケーション タスクの基になるロジック アプリ リソースを開きます。
ロジック アプリのサイドバー メニューの App Service プランで、[ スケールアウト] を選択します。
実際のシナリオの要件に基づき、[プランのスケールアウト] と [アプリのスケールアウト] で、それぞれ最大バーストと常時使用可能なインスタンスの値を変更します。
完了したら、[ スケールアウト ] ページのツール バーで [保存] を選択 します。
詳細については、次のドキュメントを参照してください。 Workflow Standard プランは、Azure Functions Premium プランといくつかの側面を共有します。
レプリケーションの問題と失敗
このセクションでは、レプリケーションが失敗または動作しなくなる可能性のある状況について説明します。
メッセージ サイズの制限
レプリケーション タスクによってレプリケーション プロパティが追加されるため、メッセージは必ず 1 MB 未満で送信してください。 それ以外の場合、メッセージ サイズが、レプリケーション タスクがレプリケーション プロパティを追加した後に Event Hubs エンティティに送信できるイベントのサイズよりも大きい場合、レプリケーション プロセスは失敗します。
たとえば、メッセージのサイズが 1 MB であるとします。 レプリケーション タスクがレプリケーション プロパティを追加した後、メッセージ サイズは 1 MB を超えます。 メッセージの送信を試みる送信呼び出しが失敗します。
パーティション キー
イベントにパーティション キーが存在する場合、Event Hubs インスタンス間のレプリケーションは、それらのインスタンスのパーティション数が同じであれば失敗します。
課金モデル
レプリケーション タスクは、Standard ロジック アプリのステートレス ワークフローによって実行されます。 そのため、レプリケーション タスクを作成すると、料金が発生し始める可能性があります。 使用量、使用量計測、課金、価格モデルは、 Standard ホスティング プランと Standard プランの価格レベルに従います。
ホスティング プランは、Event Hubs が受信するイベントまたは Service Bus が処理するメッセージの数に基づいてスケールアップまたはスケールダウンできます。 このプランでは、アクティブなレプリケーション中に vCPU の最小使用量と低待機時間が維持されます。 この動作では、レプリケーション タスク用の Standard ロジック アプリ リソースを作成するときに、適切な Standard プラン価格レベルを選択する必要があります。 適切なレベルを選択すると、Azure Logic Apps は CPU 使用率を調整または最大化せず、高速レプリケーションを保証できます。
Note
アプリが WS1 プランの 1 つのインスタンスから始まり、2 つのインスタンスにスケールアウトされる場合、コストは WS1 のコストの 2 倍になります。 このシナリオでは、プランが終日実行されることを前提としています。 アプリを WS2 プランにスケールアップし、1 つのインスタンスを使用する場合、コストは 2 つの WS1 プラン インスタンスと同じです。 同様に、アプリを WS3 プランにスケールアップし、1 つのインスタンスを使用する場合、コストは 2 つの WS2 プラン インスタンスまたは 4 つの WS1 プラン インスタンスと同じです。
次の例は、特定のレプリケーション タスク シナリオに最適なスループットとコストを提供するホスティング プランの価格レベルと構成オプションを示しています。 シナリオは Event Hubs または Service Bus であり、構成値が異なります。
Note
次のセクションの例では、プリフェッチ数の既定値として 800、Event Hubs の最大イベント バッチ サイズ、Service Bus の最大メッセージ数を使用します。 イベントまたはメッセージのサイズが 1 KB であることを前提としています。 イベント サイズに基づいて、プリフェッチ数、最大イベント バッチ サイズ、または最大メッセージ数を変更できます。 たとえば、イベント サイズまたはメッセージ サイズが 1 KB を超えるような場合は、プリフェッチ数、最大イベント バッチ サイズ、メッセージ数を 800 より小さくした方がいいでしょう。
Event Hubs スケールアウト
次の例は、 同じリージョン内の 2 つの Event Hubs 名前空間間のレプリケーション タスクのホスティング プランの価格レベルと構成オプションを示しています。 パーティションの数、1 秒あたりのイベント数、およびその他の構成値に基づいて情報が表示されます。
| 価格階層 | [パーティション数] | 1 秒あたりのイベント数 | 最大バースト数* | 常時使用可能なインスタンス* | プリフェッチ数* | 最大イベント バッチ サイズ* |
|---|---|---|---|---|---|---|
| WS1 | 1 | 1,000 | 1 | 1 | 800 | 800 |
| WS1 | 2 | 2,000 | 1 | 1 | 800 | 800 |
| WS2 | 4 | 4,000 | 2 | 1 | 800 | 800 |
| WS2 | 8 | 8,000 | 2 | 1 | 800 | 800 |
| WS3 | 16 | 16,000 | 2 | 1 | 800 | 800 |
| WS3 | 32 | 32,000 | 3 | 1 | 800 | 800 |
* 価格レベルごとに変更できる値の詳細については、次の表を参照してください。
| 値 | 説明 |
|---|---|
| 最大バースト数 | 負荷がかかった状況下でスケールアウトするエラスティック ワーカーの "最大" 数。 基になるアプリに、"常時使用可能なインスタンス数" (この表の次の行を参照) を超えるインスタンスが必要な場合、インスタンスの数が最大バースト制限に達するまでアプリのスケールアウトを続けることができます。 この値を変更するには、この記事で後述 するホスティング プランのスケールアウト設定の編集 を参照してください。 注: プラン サイズを超えるインスタンスは、実行中の場合にのみ課金され、1秒単位で請求されます。 アプリは定義された上限まで、プラットフォームによりベスト エフォートでスケールアウトされます。 ヒント: 推奨として、プラットフォームがスケールアウトして大きな負荷を処理できるように、必要以上の最大値を選択します。 未使用のインスタンスは課金されません。 詳しくは、次のドキュメントを参照してください。 Workflow Standard プランは、Azure Functions Premium プランといくつかの側面を共有します。 - Premium プランの設定 - クラウド バーストについて |
| 常時使用可能なインスタンス | アプリのホストとして常時準備が整っていてウォーミングされた最小インスタンス数。 最小数は常に 1 です。 この値を変更するには、この記事で後述 するホスティング プランのスケールアウト設定の編集 を参照してください。 注: プラン サイズを超えるインスタンスは、割り当て時に実行されているかどうかに 関係なく 課金されます。 詳しくは、次のドキュメントを参照してください。 Workflow Standard プランは、Azure Functions Premium プラン ( Always Ready インスタンス) といくつかの側面を共有します。 |
| プリフェッチ数 | 基になるAzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__prefetchCount クラスによって使用されるプリフェッチ数を決定する、ロジック アプリ リソースのEventProcessorHostアプリ設定の既定値。 このアプリ設定に別の値を追加または指定するには、「 アプリ設定の管理 - local.settings.json」を参照してください。 例えば:- 名前: AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__prefetchCount - 値: 800 (上限なし) prefetchCount プロパティの詳細については、次を参照してください。- host.json 設定 - Azure Event Hubs - EventProcessorOptions.PrefetchCount プロパティ - 複数のインスタンス間でパーティションの負荷を分散する - イベント プロセッサ ホスト - EventProcessorHost クラス |
| 最大イベント バッチ サイズ | ロジック アプリ リソースのアプリ設定 AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__maxBatchSize の既定値。各受信ループで受信する最大イベント数を決定します。 このアプリ設定に別の値を追加または指定するには、「 アプリ設定の管理 - local.settings.json」を参照してください。 例えば:- 名前: AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__maxBatchSize - 値: 800 (上限なし) maxBatchSize プロパティの詳細については、次を参照してください。- host.json 設定 - Azure Functions における Azure Event Hubs のトリガーとバインド - EventProcessorOptions.MaxBatchSize プロパティ - イベント プロセッサ ホスト |
Service Bus スケールアウト
次の例は、同じリージョン内の 2 つの Service Bus 名前空間間のレプリケーション タスクのホスティング プランの価格レベルと構成オプションを示しています。 1 秒あたりのメッセージ数とその他の構成値に基づいて情報が表示されます。
このセクションの例では、メッセージ サイズが 1 KB であると仮定し、プリフェッチ数と最大メッセージ数の既定値として 800 を使用しています。
| 価格階層 | 1 秒あたりのメッセージ数 | 最大バースト数* | 常時使用可能なインスタンス* | プリフェッチ数* | 最大メッセージ数* |
|---|---|---|---|---|---|
| WS1 | 2,000 | 1 | 1 | 800 | 800 |
| WS2 | 2,500 | 1 | 1 | 800 | 800 |
| WS3 | 3,500 | 1 | 1 | 800 | 800 |
* 価格レベルごとに変更できる値の詳細については、次の表を参照してください。
| 値 | 説明 |
|---|---|
| 最大バースト数 | 負荷の下でスケールアウトするエラスティック ワーカーの最大数。 基になるアプリで、次の表の行の常時対応インスタンスを超えるインスタンスが必要な場合、インスタンスの数が最大バースト制限に達するまで、アプリは引き続きスケールアウトできます。 この値を変更するには、この記事で後述する ホスティング プランのスケールアウト設定の編集 を参照してください。 注: プラン サイズを超えるインスタンスは、1 秒あたりに実行され、割り当てられている場合にのみ課金されます。 アプリは定義された上限まで、プラットフォームによりベスト エフォートでスケールアウトされます。 ヒント: プラットフォームがスケールアウトして大きな負荷を処理できるように、必要以上に大きい最大値を選択します。 未使用のインスタンスについてはグラフ化されません。 Workflow Standard プランは、Azure Functions Premium プランといくつかの側面を共有します。 詳細については、以下を参照してください。 - Premium プランの設定 - クラウド バーストとは |
| 常時使用可能なインスタンス | アプリのホストとして常時準備が整っていてウォーミングされた最小インスタンス数。 最小数は常に 1 です。 この値を変更するには、この記事で後述する ホスティング プランのスケールアウト設定の編集 を参照してください。 注: プラン サイズを超えるインスタンスは、割り当て時に実行されているかどうかに関係なく課金されます。 Workflow Standard プランは、Azure Functions Premium プラン ( Always Ready インスタンス) といくつかの側面を共有します。 |
| プリフェッチ数 | 基になるAzureFunctionsJobHost__extensions__serviceBus__prefetchCount クラスによって使用されるプリフェッチ数を決定する、ロジック アプリ リソースのServiceBusProcessorアプリ設定の既定値。 このアプリ設定に別の値を追加または指定するには、「 アプリ設定の管理 - local.settings.json」を参照してください。次に例を示します。 - 名前: AzureFunctionsJobHost__extensions__serviceBus__prefetchCount - 値: 800 (上限なし) prefetchCount プロパティの詳細については、次を参照してください。- Azure Functions 用の Azure Service Bus バインド - ServiceBusProcessor.PrefetchCount プロパティ - ServiceBusProcessor クラス |
| 最大メッセージ数 | ロジック アプリ リソースのアプリ設定 AzureFunctionsJobHost__extensions__serviceBus__batchOptions__maxMessageCount の既定値。トリガー時に送信する最大メッセージ数を決定します。 このアプリ設定に別の値を追加または指定するには、「 アプリ設定の管理 - local.settings.json」を参照してください。次に例を示します。 - 名前: AzureFunctionsJobHost__extensions__serviceBus__batchOptions__maxMessageCount - 値: 800 (上限なし) maxMessageCount プロパティの詳細については、「Azure Functions の Azure Service Bus バインド」を参照してください。 |