Apache Kafkaを使用したストリーミングの概念
Apache Kafkaを使用したOCIストリーミングをよりよく理解するには、いくつかの用語と概念を確認してください。
条件
- Apache Kafka
- Apache Kafkaはオープン・ソースのイベント・ストリーミング・プラットフォームです。サーバーとクライアントで構成される分散システムとして動作します。OCI Streaming with Apache Kafkaを使用すると、Apache Kafkaとの100%の互換性を持つテナンシで完全管理型のKafkaクラスタを実行できます。
OCIコンソール、APIまたはCLIを使用して、クラスタおよびブローカを作成および更新します。
- クラスタ
- ストリーミング・データを格納および管理するApache Kafkaサーバーまたはブローカの分散システム。Apache Kafkaを使用したOCIストリーミングでは、スタータ・クラスタまたは高可用性クラスタという2つのクラスタのタイプを作成できます。
- ブローカー
- データを格納し、クライアント・リクエストを処理するKafkaサーバー。ワークロードに応じて、各クラスタに1-30のブローカを作成できます。クラスタ内の各ブローカは、トピックの格納に使用される計算ノードです。
Apache Kafka APIまたはCLIを使用して、トピック、パーティション、レコード、プロデューサおよびコンシューマ操作を作成および更新します。
- トピック
- データが格納されるブローカ内のユーザー定義カテゴリ。各トピックには、データ分散およびパラレル処理のための多数のパーティションを含めることができます。
- パーティション
- トピックは、レコードを格納するユーザー指定のパーティション数に分割されます。レコードは各パーティション内で順序付けされ、各レコードには一意の順次増加するオフセットが割り当てられます。
- レコード
- トピックに書き込まれ、トピックから読み取られるキー値データのペア。
- プロデューサ
- トピックにレコードを書き込むアプリケーション。
- 消費者
- トピックからレコードを読み取るアプリケーション。
- コーディネータ・クラスタ
- パーティションなど、クラスタ内のアクティビティを追跡する各クラスタ内の内部コーディネータ・インスタンス。2個以下のブローカを持つクラスタは、単一ノード・コーディネータ・クラスタを取得します。大きいクラスタでは、3つのノード・コーディネータ・クラスタが取得されます。コーディネータ・クラスタの詳細を表示できません。
サービスの制限
| 制限 | 値 |
|---|---|
| テナンシ当たりのクラスタ | 5 |
| クラスタ当たりのブローカ | 30 |
| テナンシ当たりのブローカ | 150 |
| ストレージ |
ブローカ当たり最小50 GBから最大5 TB クラスタ当たり最大150TB |
| クラスタ構成 | 100 |
|
構成のバージョン (各クラスタ構成のバージョン数) |
10 |
| クラスタ当たりのイングレス | 制限はありません |
| クラスタ当たりのエグレス | 制限はありません |
| パーティション当たりのイングレス | 制限はありません |
| パーティション当たりのエグレス | 制限はありません |
| パーティション | 制限はありません |
| 最大クライアント接続数 | 制限はありません |
| 最大接続試行数 | 制限はありません |
| 最大リクエスト数(/秒) | 制限はありません |
| 最大メッセージ・サイズ(MB) | 制限はありません |
| 最大リクエストサイズ(MB) | 制限はありません |
| 最大フェッチ・バイト(MB) | 制限はありません |
| APIキー | 該当なし |
| ACL | 制限はありません |
| 構成 | テナンシ当たり100 |
| 構成更新 | 制限はありません |
機能制限
| 機能 | サポート |
|---|---|
| 1回のみのセマンティクス | はい |
| キーベースのコンパクト・ストレージ | はい |
| カスタム・コネクタ | いいえ |
| ネイティブのksqlDBサポート | いいえ |
| パブリック・ネットワーキング | いいえ |
| プライベート・ネットワーキング | はい |
| OAuth | いいえ |
| 監査ログ | はい |
| 自己管理暗号化キー | いいえ |
| 自動弾性スケーリング | いいえ |
| ストリーム共有 | いいえ |
| クライアント割当て | はい |
クラスタタイプ
Apache Kafkaを使用したOCIストリーミングでは、2種類のクラスタを作成できます。
- スタータ・クラスタ
- 高可用性が重要な要件ではないテストおよび開発目的で設計されています。スタータ・クラスタは、クラスタが1から30のブローカを持つことができる柔軟なセットアップを提供します。
- 高可用性クラスタ
- 高可用性が不可欠な本番環境を対象としています。これらのクラスタは、冗長性とフォルト・トレランスを確保するために、複数の可用性ドメインまたはフォルト・ドメインに分散された少なくとも3つのブローカで構成されます。このクラスタは、最大30のブローカまでスケール・アップできるため、ミッションクリティカルなワークロードの信頼性と耐障害性を実現できます。
クラスタのデフォルト・オプション
Kafkaクラスタの次のデフォルト・オプションを確認します。
- 接続性
- デフォルトでは、すべてのKafkaクラスタはプライベート接続で作成され、クラスタの作成時に指定されたVCNおよびサブネット内からアクセスできます。If more VCNs need access to the Kafka cluster, configure VCN peering.
- ブローカ・ディスク割当て
- デフォルトでは、ブローカ・ディスク割当て制限は、安定性を確保し、ディスク・リソースの過剰使用を防ぐために適用されます。ブローカ・ディスクの容量が97%に達すると、プロデューサ操作はレート制限されますが、コンシューマ操作には影響がなく、想定どおりに機能し続けます。ブローカ・ディスクの容量が98%に達すると、すべてのプロデューサ操作がブロックされますが、コンシューマ操作では、中断することなくイベントの消費とオフセットのコミットを続行できます。このデフォルトの動作を変更し、クラスタ構成ファイルでカスタムストレージ割り当て制限を定義できます。
- クラスタ構成ファイル
- Kafkaクラスタを作成すると、クラスタ・タイプに応じて、クラスタ構成ファイルがデフォルトのプロパティで作成されます。プロパティ設定は、信頼性、耐久性および使いやすさのバランスを取るように設計されています。デフォルト・ファイルを使用するか、カスタム・ファイルを作成できます。構成可能プロパティおよび構成不可プロパティのリストは、クラスタ構成の管理を参照してください。
高可用性クラスター
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=3 offsets.topic.replication.factor=3 min.insync.replicas=2 transaction.state.log.min.isr=2 transaction.state.log.replication.factor=3プロパティ デフォルト値 目的 allow.everyone.if.no.acl.found真 リソースのACLが見つからない場合、すべてのユーザーがクラスタにアクセスできます。 auto.create.topics.enable誤り トピックは自動的に作成されず、より適切に制御するために明示的に作成する必要があります。 leader.imbalance.per.broker.percentage1 リバランスのためにブローカごとにリーダーの不均衡しきい値を制御します。 default.replication.factor3 耐久性を高めるために、3つのレプリカで新しいトピックが作成されます。 offsets.topic.replication.factor3 内部オフセット・トピックは、自己回復性のために3回レプリケートされます。 min.insync.replicas2 少なくとも2つのレプリカは、永続性の書込みを確認する必要があります。 transaction.state.log.min.isr2 トランザクション状態ログの最小同期レプリカ。 transaction.state.log.replication.factor3 トランザクション状態ログのレプリケーション係数。 スターター・クラスタ
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=1 offsets.topic.replication.factor=1 min.insync.replicas=1 transaction.state.log.min.isr=1 transaction.state.log.replication.factor=1プロパティ デフォルト値 目的 allow.everyone.if.no.acl.found真 リソースのACLが見つからない場合、すべてのユーザーがクラスタにアクセスできます。 auto.create.topics.enable誤り トピックは自動的に作成されず、より適切に制御するために明示的に作成する必要があります。 leader.imbalance.per.broker.percentage1 リバランスのためにブローカごとにリーダーの不均衡しきい値を制御します。 default.replication.factor1 1つのレプリカで新しいトピックが作成されます(冗長性なし)。 offsets.topic.replication.factor1 内部オフセット・トピックには1つのレプリカがあります。 min.insync.replicas1 書込みを確認する必要があるレプリカは1つのみです。 transaction.state.log.min.isr1 トランザクション状態ログの最小同期レプリカ。 transaction.state.log.replication.factor1 トランザクション状態ログのレプリケーション係数。
クラスタ・サイズおよびストレージの計画
Apache Kafkaクラスタを使用したOCIストリーミングを最適化および最大限に活用するためのクラスタ・サイジング・ガイドラインを確認します。
一般的なガイドライン
- クラスタ内のブローカの数を増やす
- クラスタ内のパーティションの数を増やす。
- 1ブローカ当たりのOCPUの増加
- メモリーが大きいサイズのブローカを使用します。
- 小さいバッチを使用し、
linger.msを短くして、ネットワーク・パスを最適化します。
永続性がレイテンシよりも重要な場合は、プロデューサ構成パラメータacksをallに設定することを検討してください。
クラスタを計画および構成しないと、クラスタのパフォーマンスに影響します。
- ブローカを少なくすると、スループットが低下し、待機時間が長くなり、ブローカが過負荷になります。
- パーティションを少なくすると、並列度が低下し、コンシューマ使用率が低くなります。
- 不足しているブローカを構成すると、フェッチまたは生成のレイテンシ、GCの問題および不安定なブローカが発生します。
- 小規模なブローカで構成するパーティションが多すぎると、メモリー使用量、メタデータ・ブルートおよび不安定なリバランスが高くなります。
パフォーマンス・ベンチマーク
Armベースのプロセッサ、レプリケーション・ファクタが3に設定され、プロデューサ構成パラメータacksが1に設定されたKafkaクラスタのパフォーマンス・メトリックを確認します。
| ブローカ構成 | パーティション | 最大プロデューサ・スループット | 最大コンシューマ・スループット | レイテンシ |
|---|---|---|---|---|
3ブローカー。それぞれに次の構成があります。
|
1000 | 161.21 MB/秒 | 394.38 MB/秒 | 50.70ミリ秒 |
3ブローカー。それぞれに次の構成があります。
|
2000 | 368.76 MB/秒 | 678.39 MB/秒 | 27.79ミリ秒 |
3ブローカー。それぞれに次の構成があります。
|
2000 | 505.13 MB/秒 | 710.82 MB/秒 | 21.11ミリ秒 |
18のブローカー。それぞれに次の構成があります。
|
2000 | 379.39 MB/秒 | 690.27 MB/秒 | 80.18ミリ秒 |
18のブローカー。それぞれに次の構成があります。
|
4000 | 788.73 MB/秒 | 998.11 MB/秒 | 74.53ミリ秒 |
18のブローカー。それぞれに次の構成があります。
|
4000 | 1.08 GB/秒 | 1.15 GB/秒 | 71.29ミリ秒 |
30のブローカー。それぞれに次の構成があります。
|
4000 | 617.60 MB/秒 | 1.02 GB/秒 | 98.27ミリ秒 |
30のブローカー。それぞれに次の構成があります。
|
6000 | 1.65 GB/秒 | 1.34 GB/秒 | 65.81ミリ秒 |
30のブローカー。それぞれに次の構成があります。
|
6000 | 2.41 GB/秒 | 2.09 GB/秒 | 56.82ミリ秒 |
パフォーマンス・メトリックはいくつかの要因に依存し、1つの構成の改善によって他の構成のトレードオフにつながる可能性があります。
たとえば、スループット番号は、メッセージ・サイズ、圧縮タイプ、バッチ・サイズ、linger.msなどの要因によって異なります。バッチ・サイズが大きいとスループットが向上しますが、待機時間が長くなることもあります。
通常、パーティションの数を増やすとスループットが向上し、プロデューサのパフォーマンスが向上します。ただし、プロデューサとコンシューマのリソース使用量も増加し、メタデータのオーバーヘッドが増加します。これにより、リーダー選択および同期レプリカ(ISR)管理が遅くなり、生成およびフェッチ・リクエストの待機時間が長くなる可能性があります。
要件に基づいて、これらのパラメータを調整する必要があります。
- 低レイテンシのために最適化するには、
batch.sizeおよびlinger.msを減らし、高圧縮を回避します。 - スループットを最大化するには、
batch.sizeを増やし、圧縮を有効にし、より多くのパーティションおよびブローカを使用して水平方向にスケーリングします。
レイテンシおよびスループットのメトリックを常に監視し、実際のワークロード・パターンに基づいてクラスタを繰り返しチューニングします。
移行
自己管理型のApache Kafkaクラスタから、Apache Kafkaクラスタを使用したOCIストリーミングにデータを移行できます。
この移行ユースケースの推奨される解決策は、接続クラスタにMirrorMaker 2.0コネクタを作成することです。
client.properties構成のサンプルを示します。security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=</path/to/truststore.jks>
ssl.truststore.password=<truststore-password>
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";