次の方法で共有


レプリケーション タスクを作成して Azure リソースをレプリケートする

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 エコシステムから継承されたその他の機能と利点も用意されています。

レプリケーションとフェデレーションの詳細については、次を参照してください。

レプリケーション タスク テンプレート

次の表に、 Azure Event HubsAzure 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 のメタデータとプロパティのマッピング

ターゲット Event Hubs 名前空間の新しいサービス割り当て値は、ソース名前空間の次の項目を置き換えます。

  • イベントのサービス割り当てメタデータ
  • 元のエンキュー時間
  • Sequence number
  • オフセット

ヘルパー 関数 と Azure 提供のサンプルのレプリケーション タスクの場合、元の値は次のユーザー プロパティに保持されます。

  • repl-enqueue-time (ISO8601文字列)
  • repl-sequence
  • repl-offset

これらのプロパティは string 型であり、それぞれの元のプロパティの文字列化された値が含まれています。 複数回イベントが転送される場合は、直接のソースのサービスによって割り当てられたメタデータが既存のプロパティに追加され、値はセミコロンで区切られます。 詳細については、「 サービス割り当てメタデータ」を参照してください。

Azure Event Hubs でのレプリケーションとフェデレーションの詳細については、次を参照してください。

Service Bus のレプリケーション トポロジ

次の図は、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 を使用して標準ロジック アプリ ワークフローを作成する」を参照してください。

  • 省略可能: ターゲット名前空間の接続文字列。 このオプションを使用すると、サブスクリプション間のレプリケーションを設定できるように、ターゲットを別のサブスクリプションに配置できます。

    ターゲット エンティティの接続文字列を見つけるには、これらの手順を実行します。

    1. Azure portal でターゲットの名前空間に移動します。

    2. 名前空間のサイドバー メニューの [設定] で、[ 共有アクセス ポリシー] を選択します。

    3. 開いた [共有アクセス ポリシー ] ページの [ ポリシー] で、 RootManageSharedAccessKey を選択します。

    4. [SAS ポリシー: RootManageSharedAccessKey] ウィンドウで、[プライマリ接続文字列] の値をコピーします。

    5. 後で使用してターゲット名前空間に接続できるように、接続文字列を保存します。

名前付け規則

レプリケーション タスクまたはエンティティに使用する名前付け戦略を慎重に検討してください。 名前の識別と区別が簡単であることを確認します。 たとえば、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 キューのレプリケーション タスクを作成する方法を示します。

  1. Azure portal で、ソースとして使用する Service Bus 名前空間を見つけます。

  2. 名前空間サイドバー メニューの [Automation ] セクションで、[ タスク] を選択します。

    [タスク] が選択された Azure Service Bus 名前空間が表示されている Azure portal のスクリーンショット。

  3. [タスク] ページで、[タスクの追加] を選択して、タスク テンプレートを選択できるようにします。

    [タスクの追加] が強調表示されている [タスク] ページを示すスクリーンショット。

  4. [ タスクの追加 ] ページの [ テンプレートの選択] で、作成するレプリケーション タスクのテンプレートで [選択] を選択 します。 次のページが表示されない場合は、[次へ: 認証] を選びます。

    この例では、 Service Bus キューからキューへのレプリケート タスク テンプレートを使用します。これにより、Service Bus キュー間でコンテンツがレプリケートされます。

    スクリーンショットは、[Service Bus キューからキューへのレプリケート] テンプレートが強調表示されている [タスクの追加] ページを示しています。

  5. [ 認証 ] タブの [ 接続 ] セクションで、タスクに表示されるすべての接続の 作成 を選択します。 すべての接続の認証資格情報を指定します。 各タスクの接続の種類は、タスクによって異なります。

    この例では、ターゲット キューが存在するターゲット Service Bus 名前空間への接続を作成するためのプロンプトを示します。 この接続は、ソース Service Bus 名前空間に存在します。

    スクリーンショットは、ターゲット Service Bus 名前空間への接続の [作成] オプションを示しています。

  6. ターゲットに関する必要な情報を指定し、[作成] を選びます。

    この例では、接続の表示名を指定し、ターゲット キューが存在する Service Bus 名前空間を選びます。

    指定された接続表示名と Service Bus 名前空間名を含む [接続] ペインを示すスクリーンショット。

    ヒント

    代わりに接続文字列を使用して接続を作成できます。 このオプションを使用すると、サブスクリプション間のレプリケーションを設定できるように、ターゲットを別のサブスクリプションに配置できます。 ターゲット (レプリケーション タスクの作成を開始した場所に基づくソース) は動的に構成されるため、ターゲットのみを接続する必要があります。 接続文字列を使用するには、次の手順を使用します。

    1. [接続] ペインで、[接続文字列を使用して接続する] を選びます。

    2. [接続文字列] ボックスに、ターゲットの名前空間の接続文字列を入力します。

    次の例は、正常に作成された接続を示しています。

    スクリーンショットは、Service Bus 名前空間への接続が完了した作業ウィンドウの追加を示しています。

  7. すべての接続を完了したら、[次へ: 構成] を選びます。

  8. [構成] タブで、タスクの名前と、タスクに必要なその他の情報を指定します。

    Note

    作成後にタスク名を変更することはできません。 基になるワークフローを編集する場合は、引き続き適用される名前を検討してください。 基になるワークフローに加えた変更は、タスク テンプレートではなく、作成したタスクにのみ適用されます。

    たとえば、タスクに fabrikam-rep-weu-wus という名前を付けた後で、基になるワークフローを別の目的で編集した場合、タスク名が一致するように変更することはできません。

    1. タスク ワークフローを既存の Standard ロジック アプリに追加するには、 ロジック アプリ の一覧からそのロジック アプリを選択します。 代わりに新しい Standard ロジック アプリ リソースを作成するには、 ロジック アプリ の一覧で [ 新規作成] を選択し、新しいロジック アプリに使用する名前を指定します。

      Note

      レプリケーション タスクの作成時に新しいロジック アプリ リソースを作成すると、ロジック アプリは ソース エンティティと同じリージョンに作成されます。 この状況は、ソース リージョンが使用できなくなり、フェールオーバー シナリオでは機能しない場合に問題になります。 ベスト プラクティスは、ソースとは異なるリージョンに Standard ロジック アプリを作成することです。 レプリケーション タスクを作成するときは、代わりに既存のロジック アプリを選び、基になるステートレス ワークフローを既存のロジック アプリに追加します。 詳細については、「 前提条件」を参照してください。

    2. 完了したら、[確認および作成] を選択します。

      スクリーンショットは、タスク名、ソースとターゲットのキュー名、およびロジック アプリ リソースに使用する名前を含む作業ウィンドウを追加するを示しています。

  9. [ 確認と作成 ] タブで、レプリケーション タスクで操作に必要な Azure リソースを確認します。

    • レプリケーション タスク用に新しいロジック アプリ リソースを作成することを選択した場合は、レプリケーション タスクが動作するために作成する必要な Azure リソースがタブに表示されます。

      たとえば、これらのリソースには、ロジック アプリ リソース、ワークフロー、およびその他のランタイム操作の構成情報を含む Azure Storage アカウントが含まれます。 Event Hubs では、このストレージ アカウントにはチェックポイント情報が含まれます。 また、ソース領域が中断された場合や使用できなくなった場合にソース エンティティが停止するストリーム内の位置または オフセット も含まれます。

      次の例は、新しいロジック アプリを作成することを選んだ場合の [確認と作成] タブを示しています。

      スクリーンショットは、新しいロジック アプリの作成時にリソース情報を含む [確認と作成] タブを示しています。

    • レプリケーション タスクに既存のロジック アプリ リソースを再利用することを選択した場合は、レプリケーションが動作するために再利用する Azure リソースがタブに表示されます。

      次の例は、既存のロジック アプリを再利用することを選んだ場合の [確認と作成] タブを示しています。

      既存のロジック アプリを再利用するときのリソース情報を含む [確認と作成] タブを示すスクリーンショット。

    Note

    ソース、ターゲット、またはその両方が仮想ネットワーク上にある場合は、タスクの作成後にアクセス許可とアクセスを設定する必要があります。 このシナリオでは、ロジック アプリのワークフローがレプリケーション タスクを実行できるように、アクセス許可とアクセスが必要です。

  10. 準備ができたら、[作成] を選択します。

    自動的にライブで実行されている作成したタスクが、[タスク] 一覧に表示されるようになりました。

    ヒント

    タスクがすぐに表示されない場合は、タスク一覧を最新の状態に更新するか、少し待ってから更新してください。 ツール バーの [更新] を選択します。

    作成されたレプリケーション タスクを含む [タスク] ページを示すスクリーンショット。

  11. 使用するリソースが仮想ネットワークの背後にある場合は、ロジック アプリのリソースとワークフローがそれらのリソースにアクセスするためのアクセス許可を忘れずに設定してください。

再試行ポリシーを設定する

レプリケーション関係の両側で可用性イベント中のデータ損失を回避するには、堅牢性を確保するために再試行ポリシーを構成します。 レプリケーション タスクの再試行ポリシーを構成するには、 再試行ポリシー、基になるワークフローを編集する手順を参照してください。

タスク履歴の確認

この例では、タスクのワークフロー実行履歴とその状態、入力、出力、およびその他の情報を表示する方法を示します。 Service Bus キュー レプリケーション タスクの例を引き続き使用します。

  1. Azure portal で、確認するタスク履歴がある Azure リソースまたはエンティティを見つけます。

    この例では、このリソースは Service Bus 名前空間です。

  2. リソース サイドバー メニューの [設定] の [ Automation ] セクションで、[ タスク] を選択します。

  3. [ タスク] ページで、確認するタスクを見つけます。 このタスクの [実行] 列で、[表示] を選択します。

    作成されたレプリケーション タスクと、実行を表示するためのリンクを含む [タスク] ページを示すスクリーンショット。

    この手順では、Standard ロジック アプリ リソースの基になるステートレス ワークフローのデザイナーを開きます。

  4. ステートレス ワークフローの実行履歴を表示するには、ワークフロー サイドバーの [ ツール] で [ 実行履歴] を選択します。

    [ 実行履歴 ] タブには、タスクの前の実行、進行中、待機中の実行と、その識別子、状態、開始時刻、実行時間が表示されます。

    タスクの実行、状態、およびその他の情報を示すスクリーンショット。

    次の表は、実行に対して可能性のある状態を示しています。

    状態ラベル 説明
    取り消し済み タスクは実行中に取り消されました。
    Failed タスクには少なくとも 1 つの失敗したアクションがありますが、失敗を処理するための後続のアクションが存在しませんでした。
    実行中 タスクは現在実行中です。
    Succeeded アクションはすべて成功しています。 アクションが失敗した場合でもタスクは正常に完了しますが、失敗を処理するための後続のアクションが存在していました。
    待機中 実行はまだ開始されていません。タスクの以前のインスタンスがまだ実行中であるため、一時停止しています。
  5. 実行の各ステップ、その状態、およびその他の情報を表示するには、その実行を選択します。

    実行の詳細ページが開き、基になるワークフローで実行された各ステップが表示されます。

    • ワークフローは、常にトリガーで開始されます。 このタスクでは、ワークフローは、ソース Service Bus キューにメッセージが到着するのを待機する Service Bus トリガーで開始されます。

    • 各ステップには、状態と実行継続時間が表示されます。 実行時間が0秒の手順は、実行に1秒未満かかりました。

    スクリーンショットは、ワークフローの実行、状態、実行期間の各ステップを示しています。

  6. 各ステップの入力と出力を確認するには、ステップを選択します。

    このアクションにより、そのステップの入力、出力、およびプロパティの詳細を表示するウィンドウが開きます。

    次の例は、Service Bus トリガーの入力、出力、およびプロパティを示しています。

    トリガーの入力、出力、およびプロパティを示すスクリーンショット。

Azure リソースのレプリケーション タスクのコンテキストとは別に、アプリ、データ、サービス、システムを統合するための独自の自動化されたワークフローを構築できます。 「標準ロジック アプリ ワークフローの作成」を参照してください。

レプリケーション タスクを監視する

レプリケーション タスクまたは基になるロジック アプリ ワークフローのパフォーマンスと正常性を確認するには、 Application Insights を使用します。 Azure Monitor には、この機能が用意されています。

アプリケーション マップは、レプリケーション タスクの監視に使用できる便利なビジュアル ツールです。 Azure Monitor は、キャプチャされた監視情報からこのマップを自動的に生成します。 レプリケーション タスクのソースとターゲットの転送のパフォーマンスと信頼性を調べることができます。 すぐに診断分析情報を取得し、ログの詳細を低待機時間で視覚化するには、 Live Metrics ポータル ツールを使用できます。 このツールは、Azure Monitor の一部でもあります。

タスクを編集する

タスクを変更するには、オプションを選択します。

タスクをインラインで編集する

  1. Azure portal で、更新するタスクを含むリソースを見つけます。

  2. リソース サイドバー メニューの [Automation ] セクションで、[ タスク] を選択します。

  3. [タスク] 一覧で、更新するタスクを見つけます。 タスクの省略記号 (...) メニューを開き、[インラインで編集] を選択します。

    開いているコンテキスト メニューと選択したオプションの [インラインで編集] を示すスクリーンショット。

    既定では、[認証] タブが表示され、既存の接続が表示されます。

  4. 新しい認証資格情報を追加したり、接続に対して別の既存の認証資格情報を選択したりするには、接続の省略記号 (...) メニューを開きます。 [ 新しい接続の追加] を選択するか、使用可能な場合は別の認証資格情報を選択します。

    Note

    編集できるのは、ソース接続ではなく、ターゲット接続のみです。

    [認証] タブ、既存の接続、選択したコンテキスト メニューを示すスクリーンショット。

  5. その他のタスクのプロパティを更新するには [次へ: 構成] を選びます。

    この例のタスクでは、異なるソースとターゲットのキューを指定できます。 ただし、タスク名、基になるロジック アプリとワークフローは同じままです。

    [構成] タブと編集できるプロパティを示すスクリーンショット。

  6. 終了したら、[保存] を選択します。

タスクの基になるワークフローの編集

レプリケーション タスクの背後にある基になるワークフローを編集できます。 編集によって、作成したタスクの元の構成が変更されますが、タスク テンプレート自体は変更されません。 変更を加えて保存すると、編集したタスクは元のタスクと同じ機能を実行しなくなります。 元の機能を実行するタスクが必要な場合は、同じテンプレートを使って新しいタスクを作成する必要が生じる場合があります。

元のタスクを再作成しない場合は、デザイナーを使用してタスクの背後にあるワークフローを変更しないでください。 代わりに、統合のニーズを満たす標準ロジック アプリ リソースとステートレス ワークフローを作成します。 詳細については、「 標準ロジック アプリ ワークフローの作成」を参照してください。

  1. Azure portal で、更新するタスクを含むリソースを見つけます。

  2. リソース サイドバー メニューの [ Automation] で、[タスク] を選択 します

  3. [タスク] 一覧で、更新するタスクを見つけます。 タスクの省略記号 (...) メニューを開き、[Open in Logic Apps]\(Logic Apps で開く\) を選択します。

    開いているコンテキスト メニューと選択したオプションの [Logic Apps で開く] を示すスクリーンショット。

    Azure portal は、ワークフローを編集できるデザイナーにコンテキストを変更します。

    基になるワークフローを含むワークフロー デザイナーを示すスクリーンショット。

    ワークフローのトリガーとアクションを編集できます。

  4. トリガーまたはアクションのプロパティを表示するには、そのトリガーまたはアクションを選びます。

    トリガーまたはアクションの情報ウィンドウが開きます。 トリガーまたはアクションのプロパティを編集できます。

    次の例では、ワークフローに関する説明をトリガーに追加します。

    [Service Bus トリガーのプロパティ] ウィンドウを示すスクリーンショット。

  5. 変更を保存するには、デザイナーのツール バーで [保存] を選択します。

    デザイナーのツール バーと [保存] アイコンを示すスクリーンショット。

  6. 更新されたワークフローをテストして実行するには、デザイナーのツール バーで [ 実行>実行] を選択します。

    実行が完了すると、デザイナーにワークフローの実行の詳細が表示されます。

  7. 各ステップの入力と出力を確認するには、ステップを選択します。これにより、そのステップの入力、出力、およびプロパティの詳細を示すペインが開きます。

    次の例は、選択した Service Bus トリガーの入力、出力、およびプロパティを示しています。

    ワークフローの実行の詳細と、トリガーの入力、出力、およびプロパティを示すスクリーンショット。

  8. タスクが引き続き実行されないようにワークフローを無効にするには、ワークフロー サイドバーの [構成][設定] を選択します。 [ワークフローの状態] ボックスの一覧から [無効] を選択します

    詳細については、「 デプロイされたロジック アプリを無効または有効にする」を参照してください。

Azure Event Hubs のフェールオーバーを設定する

同じエンティティの種類間の Azure Event Hubs レプリケーションの場合、geo ディザスター リカバリーでは、ソース エンティティからターゲット エンティティにフェールオーバーする必要があります。 その後、このプロセスは、影響を受けるイベント コンシューマーとプロデューサーに、ターゲット エンティティのエンドポイントを使用するように通知します。 ターゲット エンティティが新しいソースになります。

障害が発生し、ソース エンティティがフェールオーバーすると、コンシューマーとプロデューサー (レプリケーション タスクを含む) が新しいソースにリダイレクトされます。 レプリケーション タスクは、チェックポイント情報を含むストレージ アカウントを作成します。 ストレージ アカウントには、ソース リージョンが中断された場合や使用できなくなった場合にソース エンティティが停止するストリーム内の位置またはオフセットも含まれます。

元のソースからレガシ情報を手動でクリーンアップし、レプリケーション タスクを再構成します。 このアクションにより、ストレージ アカウントに元のソースからのレガシ情報が含まれていないことが保証されます。 また、レプリケーション タスクが新しいソース ストリームの先頭からイベントの読み取りとレプリケートを開始することも確認します。

  1. Azure portal でロジック アプリ リソースを開き、レプリケーション タスクの基になるワークフローを開きます。

    Note

    ロジック アプリ リソースには、レプリケーション タスク ワークフローのみを含める必要があります。

  2. ワークフロー サイドバー メニューの [ 構成] で、[ 設定] を選択します。 [ワークフローの状態] ボックスの一覧から [無効] を選択します

  3. レプリケーション タスクの基になるロジック アプリ リソースがソース エンティティからのチェックポイントとストリーム オフセット情報を格納するために使用するストレージ アカウントを見つけるには、次の手順に従います。

    1. ロジック アプリのサイドバー メニューの [設定] で、[ 環境変数] を選択します。

    2. [ 環境変数 ] ページの [ アプリ設定 ] タブで、 AzureWebJobsStorage アプリ設定を見つけて、[ 値の表示 ] を選択してストレージ アカウント名を表示します。

      この設定は、ロジック アプリ リソースによって使用される接続文字列とストレージ アカウントを指定します。

      次の例は、このストレージ アカウントの名前 ( storagefabrikamreplb0c) を検索する方法を示しています。

      スクリーンショットは、基になるロジック アプリの [環境変数] ページを示しています。このページには、アプリの設定と、ストレージ アカウント名を含む接続文字列が含まれています。

    3. ストレージ アカウント リソースが存在することを確認するには、Azure portal の検索ボックスに名前を入力します。 ストレージ アカウントを選択します。

      ストレージ アカウント名が入力された Azure portal の検索ボックスを示すスクリーンショット。

  4. 次の手順を使用して、ソース エンティティのチェックポイントとオフセット情報を含むフォルダーを削除します。

    1. 最新バージョンをお持ちでない場合は、最新の Azure Storage Explorer デスクトップ クライアントをダウンロードし、インストールして開きます。

      Note

      現時点では、削除のクリーンアップ タスクに Azure Storage Explorer クライアントを使用する必要があります。Azure portal の管理エクスペリエンス、ストレージ エクスプローラー、ブラウザー、エディターは "使用できません"。

      PowerShell Remove-AzStorageDirectory コマンドを使用してコンテナー フォルダーを削除することはできますが、このコマンドは のフォルダーでのみ機能します。

    2. まだサインインしていない場合は、Azure アカウントを使用してサインインします。 ストレージ アカウント リソースの Azure サブスクリプションが選択されていることを確認します。 詳細については、「Storage Explorer の概要」を参照してください。

    3. エクスプローラー ウィンドウで、該当する Azure サブスクリプション名から、[ストレージ アカウント]>[{your-storage-account-name}]>[BLOB コンテナー]>[azure-webjobs-eventhub] の順に移動します。

      Note

      azure-webjobs-eventhub フォルダーが存在しない場合、レプリケーション タスクがまだ実行されていません。 このフォルダーは、レプリケーション タスクが少なくとも 1 回実行された後にのみ表示されます。

      選択した azure-webjobs-eventhub フォルダーを表示するために、ストレージ アカウントと BLOB コンテナーが開かれた Azure Storage Explorer を示すスクリーンショット。

    4. 開いた azure-webjobs-eventhub ペインで、Event Hubs 名前空間フォルダーを選択します。 名前の形式は次のとおりです: <source-Event-Hubs-namespace-name>.servicebus.windows.net

    5. 名前空間のフォルダーが開いたら、[azure-webjobs-eventhub] ペインで <former-source-entity-name> フォルダーを選択します。 ツール バーまたはフォルダーのショートカット メニューから、[削除] を選択 します

      以前のソース Event Hubs エンティティ フォルダーが選択され、[削除] が強調表示されていることを示すスクリーンショット。

    6. フォルダーを削除することを確認します。

  5. レプリケーション タスクの背後にあるロジック アプリのリソースまたはワークフローに戻ります。 ロジック アプリを再起動するか、ワークフローを再度有効にします。

プロデューサーとコンシューマーは、新しいソース エンドポイントを使用する必要があります。 新しいソース エンティティに関する情報を、簡単にアクセスして更新できる場所で使用できるようにします。 プロデューサーまたはコンシューマーは、頻繁に発生するまたは永続的なエラーを検出した場合、その場所を確認し、それらの構成を調整する必要があります。 その構成を共有するには、いくつかの方法があります。 DNS 共有とファイル共有が例です。

geo ディザスター リカバリーの詳細については、次のドキュメントを参照してください。

ホスティング プランのスケールアウト設定を編集する

  1. Azure portal で、レプリケーション タスクの基になるロジック アプリ リソースを開きます。

  2. ロジック アプリのサイドバー メニューの App Service プランで、[ スケールアウト] を選択します。

    最大バースト、最小インスタンス、Always Ready インスタンス、スケールアウト制限の適用に関する App Service プランの設定を示すスクリーンショット。

  3. 実際のシナリオの要件に基づき、[プランのスケールアウト][アプリのスケールアウト] で、それぞれ最大バーストと常時使用可能なインスタンスの値を変更します。

  4. 完了したら、[ スケールアウト ] ページのツール バーで [保存] を選択 します

詳細については、次のドキュメントを参照してください。 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 バインド」を参照してください。