ミラーリングの使用
ミラーリングにより、1 つの Event Streams サービス・インスタンス内のメッセージを 2 番目のインスタンスに継続的にコピーすることができます。 最初のサービス・インスタンスが使用不可になったかのようにミラーリングを使用することで、アプリケーションの回復力を向上させることができます。アプリケーションは 2 番目のインスタンスに再接続して、通常の操作を続行することができます。
この機能は完全に管理されたサービスの一部であり、 Event Streams エンタープライズ・プランを使用するサービス・インスタンス間でのみ使用できます。
ミラーリングの機能:
- 異なる IBM Cloud アカウントでプロビジョンできる 2 つの Event Streams サービス・インスタンス間のトピック、メッセージ・データ、およびコンシューマー・グループ・オフセットをミラーリングします。
- Event Streams サービスと整合した 99.99% の可用性の SLA。
- IBM Cloud® Monitoringを使用してモニターできます。
ミラーリングの制限:
- 単一方向: データは、サービス・インスタンスのペア間で一度に 1 方向にのみミラーリングできます。 これは、ミラーリングが「アクティブ-アクティブ」ではなく、「アクティブ-パッシブ」スタイルの高可用性を提供することを意味します。
- 非同期: メッセージは、ターゲット・インスタンスにミラーリングする前に、ソース・インスタンスに正常に生成されている必要があります。 これは、障害が発生した場合、レプリケーションの遅延により、ターゲットクラスタには障害発生の正確な時点までのすべてのメッセージが存在しない可能性があり、一部のメッセージデータが失われる可能性があることを意味します。
- At-least-once message consumption: コンシューマーがインスタンス間を移動するときに、既に処理したメッセージを再処理する必要がある場合があります。
ミラーリングを開始する前に、以下の点を考慮してください。
- アプリケーションは、 ミラーリングを最大限に活用するために変更 する必要がある場合があります。
- インスタンス間でデータをミラーリングするために使用されるネットワーク・トラフィック用に 使用可能な十分な容量 があることを確認します。
ミラーリングを有効にするには、ミラーリングのセットアップ・ガイドを参照してください。
ミラーリングの概要
選択したトピックのミラーリングは、2 つのクラスター間で単一方向に発生します。つまり、データは単一のソース・クラスターから単一のターゲット・クラスターに 1 方向でミラーリングされます。 各クラスターにはミラーリング別名があります。 本書では、 A はソース・クラスター別名に使用され、 B はターゲット・クラスター別名に使用されます。 別名は、ミラーリングが有効になっているときに構成可能であるため、例えば、「us-south」や「us-east」などにすることができます。
ソースクラスタ (A) の mytopic というトピックが、ターゲットクラスタ (B) に mytopic.A として表示され、 A から発信されたことを示します。 このタイプのトピックはリモート（ソース）クラスタから発信されるため、 _リモート・トピックと_呼ばれます。 一方、ユーザがターゲットクラスタ上で直接作成したトピックは_ローカルトピックと_呼ばれる。
ミラーリングするトピックを選択するには、 [ミラーリング ユーザー コントロール] を使用して正規 表現パターンを構成します。
ミラーリングにより、ソース・インスタンスとターゲット・インスタンスの間のコンシューマー・オフセットが自動的に変換されます。 以前のバージョンの Event Streamsでは、コンシューマーは A.checkpoints.internal という特別なトピックを使用する必要がありました (ここで、 A はソース・クラスターの別名です)。 これはもう必要ありませんが、チェックポイント・トピックは、既存のアプリケーションとの後方互換性のために、ミラーリング・プロセスによって引き続き作成および更新されます。
チェックポイント・トピックを利用したいアプリケーションは、 Kafka MirrorClient を使用して、このトピックに保持されているデータへのアクセスを単純化することができます。
最後に、リモート・トピックの命名により、以下のようになります。
- Kafka リソース名の一部としてクラスター別名を使用しないでください。
- リモート・トピック名 (ソース・トピックやソース・クラスター別名など) が Kafka トピックの長さ制限 (249 文字) を超えないようにしてください。 リモート・トピック名がこの制限を超えると、そのトピックのメッセージはミラーリングされません。
キャパシティー・プラン
キャパシティを計画する際には、ソースおよびターゲット・サービス・インスタンスのネットワーク使用量と地理的位置の両方を考慮する必要があります。
ネットワーク帯域幅
選択したトピックのミラーリングに必要なネットワーク帯域幅は、ソースとターゲットの両方のサービスインスタンスの帯域幅許容量で考慮する必要があります。 たとえば、ソースサービスインスタンスのアプリケーションからミラーリングされたトピックに10 MB/秒のメッセージトラフィックが発生した場合、これらのメッセージをターゲットインスタンスにミラーリングするには、10 MB/秒の送信帯域幅が余分に必要になる。 これは、消費アプリケーションによってすでに使用されている既存の発信帯域幅と並行して許容されなければならない。 モニター・ダッシュボードを使用して、サービス・インスタンスのネットワーク使用量を判断できます。 詳しくは、Event Streams メトリックのモニタリングを参照してください。
地理的位置
他のネットワーキングと同様に、達成可能な最大スループットは、(待ち時間とパケット・ロスの増加により) データ送信距離の要因となります。 これは、ソースインスタンスとターゲットインスタンス間で達成できる最大スループットに影響する。 ターゲット・サービス・インスタンスは、ソースにできるだけ地理的に近い場所に配置する。
次の表は、150 MB/sの容量を持つソースインスタンスからミラーリングを行う場合の達成可能なスループットの指針を示しています。
| リージョン | パーティション当たりの最大スループット | 最大合計スループット |
|---|---|---|
| us-south <-> us-east | 1.5 MB/s | 35 MB/s |
| eu-gb <-> eu-de | 2.5 MB/s | 35 MB/s |
| au-syd <-> jp-tok | 0.4 MB/s | 12 MB/s |
| 同じリージョン内で eu-gb <-> eu-gb | 2.5 MB/s | 35 MB/s |
数値は以下のことを示しています。
- 最大合計スループット: 選択されたすべてのトピック間でミラーリングできる最大合計 MB/秒。
- パーティション当たりの最大スループット: 単一パーティション内でミラーリングできる最大 MB/秒。 ソース・トピック用に構成されているパーティションの数を選択して、パーティションごとのロードがこの制限内に収まるようにします。
制限を超えると、ソース・インスタンスとターゲット・インスタンスのデータ間のラグが大きくなる。 データ・ラグが大きいと、ソース・インスタンスに障害が発生した場合に大量のメッセージ・データが失われる可能性があります。 インスタンス間のラグがゼロの場合でも、ミラーリングは非同期であるため、ソース・インスタンスに障害が発生した場合に一部のデータが失われる可能性があると予想する必要があります。 モニター・ダッシュボードを使用して、各トピックの待ち時間を判別できます。 詳しくは、 ミラーリングのモニタリングを参照してください。
達成可能なスループットに関するガイダンスは、50 個のトピック区画にわたって生成された 100K メッセージを使用して生成されました。 ワークロードで使用されるメッセージ・サイズが小さい場合 (例えば、 1Kの下)、または使用される区画の数が少ない場合、ミラーリングはこれらのレベルのスループットを達成できない可能性があります。
冗長ターゲット・トピックの削除
ターゲット・インスタンス内のデータが誤って削除されないように、ソースから削除されたトピックはターゲット・インスタンスから自動的に削除されません。 ターゲット・インスタンスのトピックを削除するのは、ユーザーの責任です。 ミラーリングされたトピックが頻繁に削除および作成される場合は、ターゲット・クラスターでより多くのディスクおよびパーティションの許容量が消費される可能性があります。 使用量は、ターゲット・クラスター内のモニター・ダッシュボードでモニターできます。 Event Streams メトリックのモニター を参照してください。 CLI、UI、または管理インターフェースを使用して、不要になったトピックを削除できます。
ミラーリング用の IAM アクセス・ポリシー
アプリケーションはソースクラスタとデスティネーションクラスタにアクセスする必要があるため、IAMアクセスポリシーを両方のクラスタで設定し、ポリシーがアタッチされているサービスIDのAPIキーを使用する必要があります。 ワイルドカード・ポリシーを使用したアクセスの割り当てという IAM ワイルドカード機能を使用して、ミラーリングされたリソースへのアクセスを制御するアクセス・ポリシーを単純化できます。
IAM アクセス・ポリシーを初めて使用する場合は、詳しくは、 How IBM Cloud IAM works および Managing authentication to your Event Streams instances を参照してください。
両方のクラスタで以下のIAMアクセスポリシーを定義します。
A.checkpoints.internal です。
| リソース・タイプ | リソース ID | 役割 |
|---|---|---|
| クラスター | リーダー | |
| グループ | <RESOURCE_NAME>.* | アプリケーションの要求に応じて |
| トピック | <RESOURCE_NAME>.* | アプリケーションの要求に応じて |
| txnid | <RESOURCE_NAME>.* | アプリケーションの要求に応じて |
| トピック (チェックポイント・トピックに固有) |
|
リーダー |
個々のアプリケーションに詳細なアクセス・ポリシーを付与します。 例えば、単に読み取り権限のみを使用するアプリケーションの場合は、読み取り権限のみを付与します。
ミラーリング・ユーザ・コントロールでは、ターゲット・クラスタで以下の権限が必要です。
| リソース・タイプ | リソース ID | 役割 |
|---|---|---|
| クラスター | マネージャー |
ミラーリングによるコンテキストベースの制限とネットワークセキュリティ制御
ミラーリングはプルベースのモデルに従い、ターゲットクラスタが接続を開始してソースクラスタからデータをプルします。 ミラーリングにおけるこのプルベースのモデルは、ソースクラスタでのネットワーク制御を強制し、許可されたターゲットクラスタのみがソースクラスタのデータにアクセスできるようにします。
コンテキストベースの制限（CBR）やCSE許可リストなどのネットワークセキュリティ制御が有効になっている場合、ターゲットクラスタのミラーリングポッドIPを含むサービスエンドポイント許可リストをソースクラスタに追加することで、ネットワークおよびセキュリティIDレベルでの安全なパスが定義されます。 この設定により、インフラストラクチャレベルできめ細かいアクセス制御が実施され、許可されたミラーリングエンドポイント（ターゲットクラスタ）のみがソースクラスタからデータを引き出すことができます。
ソースクラスタとターゲットクラスタの間で共有される認証情報は、厳密にミラーリング処理のためのものであり、 Event Streams デプロイメント間で他のリソースへのアクセスを許可するものではありません。 これは、ミラーリングプロセスが分離され、他のリソースへの不正アクセスを防止して安全であることを意味する。
ミラーリングを設定する前に、これらのネットワークセキュリティ制御を有効にする必要があります。 ミラーリングのセットアップ後にコンテキストベースの制限が適用された場合、クラスタが更新されるまでミラーリングは開始されません。
ミラーリング後にCBRが有効になっている場合：
- サポートチケットを 発行する。
- 変更が有効になるまで、次のクラスタ更新サイクル（少なくとも24時間）まで待ちます。
- ミラーノードのアドレスをCBRルールに含める。
- ターゲットクラスタでミラーリングを無効化および再有効化します。
複数のエンティティ間でクラスタを共有する場合の考慮事項
異なる事業部など複数の事業体がインスタンスを共有し、互いに分離する必要がある場合は、命名ガイドラインに従ってミラーリングされたクラスタの管理と運用を簡素化します。
以下のテンプレートを使用して、 Kafka リソースに名前を付けます。 <ENTITY_PREFIX>
ここで、
- < ENTITY_PREFIX> は、このトピックを使用するエンティティーの接頭部です。
-
は任意の文字で、エンティティ名とリソース名を簡単に区切るために使われる。 -
は Kafka リソースの名前である。
たとえば、経理業務部門で請求書というトピックが必要な場合、 accounting.invoices と呼ぶことができます。
必要なアクセス・ポリシーを調整する必要があります。 例えば、会計ビジネス・ユニットの場合、クラスター B では以下のポリシーが必要です。
| リソース・タイプ | リソース ID | 役割 |
|---|---|---|
| クラスター | リーダー | |
| グループ | accounting.* | アプリケーションの要求に応じて |
| トピック | accounting.* | アプリケーションの要求に応じて |
| txnid | accounting.* | アプリケーションの要求に応じて |
| トピック (これはチェックポイント・トピックに固有であることに注意してください) | A.checkpoints.internal | リーダー |
クラスタAは、最後のアクセスポリシーが B.checkpoints.internal。
ユーザー制御のミラーリング
CLI または 管理 REST API を使用して、ミラーリングを構成できます。 すべてのユーザー制御のミラーリングは、ターゲット・クラスターで実行されます。
トピック選択の設定
ミラーリングの選択は、正規表現（regex）パターンを使用して、ソースクラスタ上のトピック名に基づいて行われます。 「複数のエンティティー間でクラスターを共有する際の考慮事項」 セクションのアドバイスを考慮して、ソース・クラスター上のトピックの名前を慎重に選択してください。
同じグループまたはアプリケーションの一部であるトピックに接頭部を追加するなど、適切に構造化されたトピック名を使用すると、ミラーリングの制御が容易になります。 このような命名規則があれば、今後そのパターンに一致するトピックがあれば、変更することなく自動的にミラーリングされる。
トピックの選択は、1つ以上の正規表現パターンのリストの形で与えられる。 トピックは、リスト内のいずれかのパターンと一致する場合に選択されます。
ミラーリングするトピックを選択するパターンの例をいくつか示します。
| パターンの例 | 説明 |
|---|---|
^topic1$ |
完全なトピック名。 これは、 topic1 という名前の単一のトピックにのみ一致します。 |
^topic1$,^topic2$ |
完全なトピック名に一致するパターンのリスト。 これは、 topic1 および topic2 という名前の 2 つのトピックに一致します。 |
^aaa.* |
接頭部に一致します。 これは、 aaa で始まるすべてのトピック名と一致します。 |
^aaa.*,^bbb.* |
接頭部でのパターン・マッチングのリスト。 これは、 aaa または bbb で始まるすべてのトピック名と一致します。 |
^branch_[0-9]{3}_[a-z]*$ |
トピック名と突き合わせるより複雑な正規表現パターン。 これは、 branch_ で始まり、その後に正確に 3 桁、その後に _ と任意の数の小文字が続くすべてのトピック名と一致します。 |
.* |
すべてのソース・トピックをミラーリングします。 |
CLI を使用する場合、パターンはコンマ区切りリストとして指定されます。 例えば、以下のコマンドは、名前に接頭部 accounting または hr が付いているすべてのトピックを選択します。
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
以下のコマンドは、管理 REST API を使用して同じ選択を行う方法を示しています。 パターンは、 "includes" という名前の JSON 配列の形式になります。
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
トピックの選択を更新すると、現在のパターン セットが置き換えられます。
トピックがミラーリングされないように選択を解除するには、以下のように CLI で --none オプションを使用するか、管理 REST API で空のパターンを使用します。
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
選択的にミラーリングを無効にするには、無効にするパターンを除いてトピックの選択を再度適用します。 例えば、 topic1、 topic2、 topic3 が現在ミラーリングされている場合、以下のコマンドは topic2 のミラーリングを無効にするが、他の2つは有効のままにする。
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
トピック選択の取得
ミラーリングの選択は、以下のインターフェイスを使って取得できる：
CLI：
ibmcloud es mirroring-topic-selection
REST API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
アクティブ・トピックの取得
以下のインターフェイスを使用して、アクティブにミラーリングされているトピックを取得できます：
CLI：
ibmcloud es mirroring-active-topics
REST API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
ミラーリング対応アプリケーションの構築
プロデューサー
プロデューサーはローカル・トピックに対してのみ作成することをお勧めします。 インスタンス間でプロデューサーを切り替えるには、通常、接続に正しいエンドポイントと資格情報を使用するように構成を変更する必要があります。
コンシューマー
コンシューマーは、ローカル・トピックとリモート・トピックの両方をサブスクライブおよびコンシュームする必要があります。 これは、1 つのワイルドカード・サブスクリプションで実行できます。 例えば、accounting.invoiceとaccounting.invoice.<ALIAS>の両方からコンシュームするには、accounting.invoice.*へのサブスクリプションを使用します。
ローカル・トピックとリモート・トピックの両方をコンシュームする場合は、アプリケーションで厳密な順序付けが必要かどうかを確認してください。 このような場合、ローカルトピックからの消費を開始する前に、まずリモートトピックを完全に消費する必要がある。 このようにして、メッセージはプロデュースされた順序で処理されます。
コンシューマー・オフセット
メッセージ・データが 2 つのインスタンス間でミラーリングされる場合、ソース・インスタンス内のメッセージに割り当てられたオフセットが、ターゲット・インスタンスで使用されるオフセットと一致しない理由がいくつかあります。 以下に例を示します。
- ソース・インスタンス内で同じ名前のトピックを削除して再作成する。
- コンパクト・クリーンアップ・ポリシーを使用したトピックのミラーリング。
- トランザクションを使用したメッセージの生成。
メッセージ・ミラーリング・プロセスの一部は、ソース・インスタンス内のどのオフセットがターゲット・インスタンス内のどのオフセットと同等であるかを追跡します。 効率を向上させるために、少数の同等のオフセットのみが追跡され、トピックの先頭近くのロケーションが優先されます。 ソース・インスタンス内のコンシューマー・グループに対してオフセットがコミットされると、それらのオフセットはターゲット・インスタンス内の最も近い同等のオフセットに変換され、ターゲット・インスタンス内のグループに対して対応するオフセットがコミットされます。 この変換は、ターゲット・クラスターに切り替えるコンシューマーが、ミラーリングされたメッセージをスキップしないようにするためのものです。 ただし、すべての同等オフセットがミラーリング・プロセスによって追跡されるわけではないため、コンシューマーがターゲット・インスタンスに切り替えると、ソース・インスタンスで既に消費されているデータが再処理される可能性があります。
オフセットをコミットすることによってコンシューマーの進行状況を追跡するアプリケーションを作成する際には、以下の点を考慮してください。
- コンシューマー・オフセットは、対応するコンシューマー・グループがターゲット・インスタンスでアクティブに使用されていない場合にのみミラーリングされます。
- コンシューマーがターゲット・インスタンスに移動したときに、一部のメッセージ・データが再処理されることを予期します。
- コンシューマーがターゲット・インスタンスに移動すると、トピックの先頭からさらに後ろにあるほど、再コンシュームが必要になる可能性のあるデータが多くなります。
- 再利用されるデータの量を最小化し、インスタンス間のアプリケーションの切り替えを慎重に管理できるようにするには、以下の手順を実行することをお勧めします。
- ソース・インスタンスへのメッセージの生成を停止します。
- コンシューマーがトピックの先頭に追いつくまで待ちます。
- このロケーションでオフセットをコミットします。
- コンシューマーをターゲット・インスタンスに切り替えます。
ミラーリングのモニタリング
IBM Cloud Monitoring を使用してミラーリングを監視できます。 モニターを有効にするには、Event Streams メトリックのモニタリングを参照してください。 **「モニタリング」**ダッシュボードは、ターゲット・クラスターで使用可能です。
**「Event Streams ミラーリング (Event Streams Mirroring)」**ダッシュボードには、以下のメトリックが表示されます。
- ミラーリング・スループット: ソース Event Streams インスタンスからのミラーリング・スループットの秒当たりのバイト数。 これは、ミラーリングが有効かどうかを確認したり、キャパシティプランニングをするのに便利である。
- ミラーリング待ち時間: ソース Event Streams インスタンスからのトピックごとのミラーリング待ち時間 (秒)。 これは、ターゲット・クラスター上のトピックがどれだけ遅れているかを判断するのに役立ちます。
レイテンシウィンドウ内に生成されたデータはまだターゲットクラスタ上に存在しないかもしれないし、ソースクラスタ上で災害が発生した場合にも失われる可能性がある。 ただし、ミラーリングが最新の場合、両方のクラスターが正常である間のフェイルオーバーは、データ損失なしで実現できます。
ミラーリングによるリカバリー目標について
ミラーリングなどのデータ保護計画では、目標復旧時点 (RPO) および目標復旧時間 (RTO) がキー・パラメーターです。 これらの目標に関連する決定を理解しなければならない。
ミラーリング・ダッシュボードで提供されるミラーリング待ち時間メトリックを使用して、リカバリポイント目標を監視できます。 このメトリックは両方のクラスター間のラグを示すため、災害が発生した場合のデータ損失の量を見積もることができます。 あなたは、その値をモニタリングし、RPOに適合するようにする責任がある。
目標復旧時間はユーザーによって完全に制御され、以下のタイミング・ウィンドウで構成されます。
- ユーザーがフェイルオーバーを決定するまでの時間。
- ユーザーがアプリケーションをフェイルオーバーするのにかかる時間。
テスト
アプリケーションのミラーリングを認識させたときに、フェイルオーバーとフェイルバックをテストします。 災害復旧のシナリオ例 で概説されているステップを実行し、 「モニター」 ダッシュボードを使用して、すべてのステップが予期したとおりに完了することを確認します。
ソース クラスタ上の同じ名前のトピックの削除と再作成
ソース・クラスターでトピックが削除されても、ターゲット・クラスター上の対応するトピックは自動的に削除されません。 その後、ソース・クラスターでトピックを再作成すると、ソース・クラスター内の新規トピックのデータが、ターゲット・クラスター内の既存のトピックの末尾に追加されます。
Kafka Streams と Kafka Connect に関する考慮事項
Kafka Streams と Kafka Connect は、状態と構成を保管するために特定の名前を持つ内部トピックを使用します。 これらのトピックは、ミラーリングされると、ターゲット・クラスター上で名前変更されます。 このため、 Kafka Streamsと Kafka Connectアプリケーションは、クラスタ間でフェイルオーバーやフェイルバックを行うことができません。 このようなアプリケーションの災害復旧を計画する際には、この点を考慮してください。