Kafka API を使用してトピックの作成と削除を行うにはどうしたらよいか?

0.11 以降の Kafka クライアントまたは 0.10.2.0 以降の Kafka Streams を使用している場合、API を使用してトピックの作成と削除を行うことができます。 トピック作成時に許可される設定には、いくつかの制限があります。 現在のところ、変更できるのは以下の設定のみです。

cleanup.policy

delete (デフォルト)、compactまたはdelete,compactに設定します。

retention.ms

デフォルトの保存期間は 24 時間です。 最小は 1 時間、最大は 30 日間です。 時間の倍数でこの値を指定してください。

注: エンタープライズ・プランでは、これを任意の値に設定できます。

retention.bytes

スペースを解放するために古いログが廃棄されるまでの、パーティション (ログ・セグメントからなる) を拡張できる最大サイズ。

注: エンタープライズ: 100 KiB から 2 TiB までの任意の値に設定します。 標準: 100 KiB から 1 GiB までの任意の値に設定します。

segment.bytes

ログのセグメント・ファイル・サイズ。

注: エンタープライズ: 100 KiB から 2 TiB までの任意の値に設定します。 標準: 100 KiB から 512 MiB までの任意の値に設定します。

segment.index.bytes

オフセットをファイル位置にマップする索引のサイズ。

注: エンタープライズ: 100 KiB から 1 TiB までの任意の値に設定します。 標準: 100 KiB から 100 MiB までの任意の値に設定します。

segment.ms

この期間を過ぎると、セグメント・ファイルが満杯になっていなくても Kafka がログを強制的にロールする期間。

注: 5 分から 30 日までの任意の値に設定します。

以下のデフォルト値設定の例を参照してください。

 Details for topic testit
Topic name   Internal?   Partition count   Replication factor   
testit       false       1                 3   

Partition details for topic testit
Partition ID   Leader   Replicas   In-sync   
0              1        [1 5 0]    [1 5 0]   

Configuration parameters for topic testit
Name                  Value   
cleanup.policy        delete   
min.insync.replicas   2   
segment.bytes         536870912   
retention.ms          86400000   
segment.ms            604800000   
retention.bytes       1073741824   
segment.index.bytes   10485760  

Event Streams がコンシューマー・オフセット・トピックのためにログ保存ウィンドウを設定する期間はどれだけの長さか?

Event Streams はコンシューマー・オフセットを 7 日間保存します。 これは Kafka 構成 offsets.retention.minutes に対応します。

オフセット保存はシステム全体が対象であるため、個々のトピック・レベルで設定することはできません。 すべてのコンシューマー・グループは、ログ保存を最大 30 日に増やしたトピックを使用する場合でも、保管されるオフセットは 7 日間のみです。

エンタープライズ・プランの場合、内部 Kafka __consumer_offsets トピックは読み取り専用として表示されます。 このトピックは、いかなる場合も絶対に管理しようとしないでください。 標準プランの場合、__consumer_offsets トピックにアクセスできる手段はいっさいありません。

コンシューマーのないコンシューマー・グループをクリーンアップするには、どのようにすればよいですか?

コンシューマーが抜けた後も、グループはオフセットがある場合にのみ存在し続けます。 コンシューマー・オフセットは、非アクティブで 7 日経過すると削除されます。 したがって、グループで最後にコミットされたオフセットの有効期限が切れると、そのコンシューマー・グループは削除されます。

任意のタイミングでグループを明示的に削除したい場合は、 deleteConsumerGroups( ）API または ibmcloud es group-deleteコマンド を使用できます

メッセージの保存期間は？

デフォルトでは、Kafka ではメッセージは最大 24 時間保存され、各パーティションは 1 GB が上限です。 この 1 GB という上限に達したら、この限界を超えないよう、最も古いメッセージが破棄されます。

ユーザー・インターフェースまたは管理 API のいずれかを使用して、トピックを作成するときにメッセージ保存の時間制限を変更できます。 時間制限は、最小 1 時間、最大 30 日間です。

Kafka クライアントまたは Kafka Streams を使用してトピックを作成するときに許可される設定の制限については、Kafka API を使用してトピックの作成と削除を行うにはどうしたらよいか? を参照してください。

Event Streams の可用性の性質は?

Event Streams アプリケーションを作成する場合、以下の情報を使用して、Event Streams の通常の可用性がどのような性質なのか、および、アプリケーションに要求される処理内容を理解してください。

Event Streams の最大メッセージ・サイズはいくつですか?

Event Streams の最大メッセージ・サイズは 1 MB であり、これは Kafka デフォルトです。

Event Streams のレプリケーション設定はどのようになっていますか?

Event Streams は強力な可用性および耐久性を提供するように構成されています。 以下の構成設定はすべてのトピックに適用され、変更することはできません。

• replication.factor = 3
• min.insync.replicas = 2

トピックおよびパーティションの制約事項とデフォルトは何ですか?

• トピック名は最大 200 文字に制限されています。
• トピックのデフォルトのパーティション数は 1 つです。
• 各 IBM Cloud スペースのパーティションは 100 までに制限されています。 それより多くのパーティションを作成するには、新しい IBM Cloud スペースを使用する必要があります。

どの Event Streams プランでプロビジョンしたのかを確認するには、どのようにすればよいですか?

プロビジョンした Event Streams プランのタイプ (ライト、標準、またはエンタープライズ) を確認するには、以下の手順を実行します。

1. IBM Cloud コンソールで、確認する Event Streams のインスタンスに移動します。
2. 左側のナビゲーション・ペインで**「プラン」**タブをクリックします。 **「現在のプラン」**セクションに、プラン・タイプが表示されます。

Event Streams コンソールを使用して、自分の IBM Cloud プランを変更できますか?

はい。ただし、ライト・プランから標準プランに移行する場合にのみ変更できます。

1. IBM Cloud コンソールで、変更する Event Streams ライト・プランのインスタンスに移動します。

2. 左側のナビゲーション・ペインで**「プラン」**タブをクリックします。

3. **「料金プランの変更」セクションで、「標準」**ボックスにチェック・マークを付けます。 **「アップグレード」**をクリックします。

   標準プランの限度である 100 パーティションを利用できるようにするために、ライト・プランでのキャッシュされる限度である 1 パーティションをクリアするのに数分かかります。

   ただし、このオプションは現在 IBM Cloud コンソールで、他のプランの組み合わせに対しては機能しません。 例えば、異なるプランの組み合わせを試した場合、以下のようなエラーメッセージが表示されます

   Could not find VCAP::CloudController::ServicePlan with guid: ibm.eventstreams.standard
   

Event Streams 標準プランと Event Streams エンタープライズ・プランの違いは何ですか?

異なる Event Streams プランについて詳しくは、プランの選択を参照してください。

災害復旧は、どのようにすればよいですか?

現時点では、ユーザーが自分の Event Streams 災害復旧を管理する必要があります。Event Streams データは、あるロケーション (リージョン) の Event Streams インスタンスと別のロケーションの別のインスタンスとの間で複製できます。 ただし、リモートの Event Streams インスタンスのプロビジョンとレプリカ生成はお客様の責任です。

クラスター間のデータの複製には、Kafka MirrorMaker などのツールをお勧めします。 MirrorMaker の実行方法については、以下を参照してください。 Event Streams kafka-mirrormaker リポジトリー。 リカバリー・プロセスの例については、 災害復旧シナリオでのミラーリングの使用 を参照してください。

また、メッセージ・ペイロード・データのバックアップもお客様の責任です。 このデータはクラスター内の複数の Kafka ブローカー間でレプリカ生成されますが、大部分の障害を防ぐため、このレプリカ生成では、ロケーション全体の障害をカバーしません。 トピック名とそれらのトピックの構成データをバックアップすることは、ユーザーにとって推奨される適切な方法です。

マルチゾーン・リージョンで Event Streams インスタンスを構成していると、リージョン災害が発生する可能性は非常に低くなります。 しかし、このような状況に備えた計画を立てることをお勧めします。 災害によってユーザーのインスタンスが使用できなくなった場合 (およびリモート DR インスタンスがまだセットアップされていない場合)、ユーザーは新しいリージョンで新規インスタンスを構成し、使用できるようであればバックアップからそのトピックとデータを復元することを検討する必要があります。 その後で、アプリケーションが新規インスタンスを指すことができます。