最終更新日 2021年11月30日(火)

Apache Kafka on Heroku​ は、サービスとしての Kafka を Heroku プラットフォームに完全に統合するためのアドオンです。

Apache Kafka は、メッセージベースのトピックを使用したプロデューサーとコンシューマー間の高速でフォールトトレラントな通信用の分散コミットログです。Kafka は、数十億のイベントと数百万のトランザクションを処理できる新世代の分散アプリケーションを構築するためのメッセージングバックボーンを提供し、高度な信頼性とフォールトトレランスのもと大量の一時的なデータを移動させるように設計されています。

Kafka を使用すると、次のような多くの重要なユースケースのアーキテクチャを簡単に設計し実装できます。

弾性キューイング

Kafka は、システムが、変動の大きいスケーリング需要をダウンストリームサービスに置かずに、大量の着信イベントを簡単に受け入れられるようにします。これらのダウンストリームサービスは、イベントの「プッシュ」に反応するのではなく、容量があるときには Kafka のイベントストリームからプルできます。これにより、スケーリング、負荷の変動の処理、および全般的な安定性が向上します。

データパイプラインおよび分析

大規模なアプリケーションは多くの場合、データから最大の価値を引き出すために分析や ETL パイプラインを必要とします。Kafka の不変のイベントストリームにより、開発者は、データの変換および集計用の高度な並列データパイプラインを構築できます。したがって、開発者は、バッチシステムや変動しやすいデータで可能であったものよりもはるかに高速で安定したデータパイプラインを実現できます。

マイクロサービスの調整

多くのアプリケーションは、規模が大きくなると、マイクロサービススタイルのアーキテクチャに移行し、サービスディスカバリ、サービス可用性の依存関係と順序付け、サービスの相互作用など、マイクロサービスに伴う課題に直面します。サービス間の通信に Kafka を使用するアプリケーションであれば、これらの設計問題を大幅に簡単なものにできます。Kafka は、サービスが自ら簡単にマイクロサービスネットワークになり、メッセージの送受信を行うときの Kafka トピックを検出できるようにします。サービス間のメッセージが Kafka で永続的に管理されると、順序付けや依存関係の問題は軽減し、トピックベースの調整によってサービスディスカバリのオーバーヘッドが低減します。

Kafka の概念

Kafka クラスターは、多数のブローカー​、つまり Kafka を実行するインスタンスから構成されています。クラスタ内のブローカーの数は、容量、障害許容力、並列処理を高めるために増大させることができます。

プロデューサー​は、Kafka ブローカーに書き込むクライアントであり、コンシューマー​は Kafka ブローカーから読み取るクライアントです。

ブローカーは、トピック​内のメッセージ​ (Kafka に送信されたイベント) のストリームを管理します。トピックは、サポートすることになるデータに応じて、さまざまなオプション (保持、圧縮、複製因子など) で設定されます。

トピックは、並列処理や順序付けの問題のバランスをとるために使用されるトピックの個別のサブセットである多数のパーティション​から構成されます。パーティション数を増やすと、特定のトピックを扱うプロデューサーおよびコンシューマーの数が増加し、並列処理やスループットが増えることがあります。パーティション内のメッセージは順序付けられますが、パーティション間のメッセージの順序付けは保証されていません。並列処理と順序付けのバランスをとる必要性は、トピックの適切なパーティション設定にとって重要です。

パーティション内の各メッセージにはオフセット​、つまり数字の識別子があり、シーケンス内のその位置を示します。Kafka 0.10 以降、メッセージには、オプションのタイムスタンプ​も含まれることがあり、これにはメッセージが作成された時間か、メッセージが Kafka に書き込まれた時間が反映されます。

Apache Kafka プロジェクトについては、概要ドキュメント​で詳細に説明しています。

開発環境の準備

Apache Kafka on Heroku は、Heroku の CLI プラグインを使用する必要があります。この機能は、将来 Heroku CLI にまとめられますが、当面は次のコマンドを実行してください。

$ heroku plugins:install heroku-kafka

ローカルテストおよび開発

Kafka によるローカルテストおよび開発は、そのクラスター設定のために、何らかの注意を必要とすることがあります。kafka-docker​ セットアップは、ローカルで快適に操作できるように、十分に低いメモリフットプリントで設定されている限り、ローカルクラスターを実行する適切な方法をもたらします。Heroku は、近い将来にさまざまな開発中心プランを提供することに取り組んでいます。

プランと設定

現在、さまざまなプランをプラットフォームのランタイムに使用できます。現在利用できるプランは、クラスターが割り当てられており、高スループットおよび高ボリュームに最適化されています。幅広い一連のニーズに対応するためにこのプランの範囲を拡張し、イベント化されたアーキテクチャを開発の全ステージでアプリケーションに使用できるようにし続けます。

一般的なランタイムプラン

Private Spaces プラン

Shield Spaces プラン

アドオンのプロビジョニング

Apache Kafka on Heroku は、プラットフォームの他のアドオンと同じように​管理されます。Kafka クラスターは、CLI を介して Heroku アプリケーション用にプロビジョニングできます。

$ heroku addons:create heroku-kafka:standard-0 -a kafka-demo
Creating kafka-animated-39618... done
Adding kafka-animated-39618 to kafka-demo... done
The cluster should be available in 15-45 minutes.
Run `heroku kafka:wait` to wait until the cluster is ready.

Use `heroku addons:docs heroku-kafka` to view documentation.

Shield Space で、Zookeeper アクセスは許可されません。

Kafka がプロビジョニングされたら、Kafka 環境設定をアプリ設定で使用できます。これは heroku config:get KAFKA_URL​ コマンドを使用して確認できます。 クラスターへの接続方法については、「Kafka クラスターへの接続​」を参照してください。

$ heroku config:get KAFKA_URL

Kafka は、Common Runtime、Private Space、および Shield Space で使用できます。Private Space または Shield Space でのアプリケーション用に Kafka をプロビジョニングすると、その Space にアタッチされた分離データリソースネットワーク内に Kafka クラスターが作成されます。

アプリケーション間での Kafka の共有

Kafka は、同じグループ内の多数の異なるコードベースおよびプロジェクトで共有されるときに、非常にうまく機能します。独立したプロデューサーおよびコンシューマーのセットとして Kafka の使用法を構築することをお勧めします。複数のアプリケーションとしてか、1 つ以上のアプリケーションのプロセスタイプ​として設定してください。

$ heroku addons:attach my-originating-app::KAFKA -a this-app

クラスター情報の表示

次のように入力して、クラスターの現在の状態を調べることができます。

$ heroku kafka:info

このコマンドにより、リソースの名前、作成日、プラン、バージョン、ステータス、トピック、トラフィック、およびアクティブコンシューマーに関する情報が表示されます。

クラスターの詳細なトピックごとのスループット情報は、次のようにして入手できます。

$ heroku kafka:topics

Kafka の管理

トピックは、メッセージの構造化された表現であり、プロデューサーとコンシューマーとの媒介役として機能します。Kafka でのトピックの名前とは別に、データがどのようにトピックを流れるかを定義する設定可能なプロパティがいくつかあります。

プロパティには、複製因子、論理パーティションの数、および圧縮または時間ベースの保持が含まれます。Heroku 提供のデフォルト設定は、多くのアプリケーションに適していますが、1 日に数十億のイベントを処理することが予想されるトピックの場合、本番環境に移る前にさらなる調査を検討してください。

設定のデフォルトと限度

トピックについて

Kafka トピックは、Web ダッシュボードと CLI を使用して作成および管理できます。このセクションは、CLI ベースのトピック管理の基本を取り上げます。

Heroku CLI 自体から完全な CLI ドキュメントに常にアクセスできます。

$ heroku help kafka

次の CLI コマンドを使用してトピックを作成および破棄できます。

$ heroku kafka:topics:create my-cool-topic --partitions 100
$ heroku kafka:topics:destroy my-cool-topic

次の CLI コマンドを使用してクラスター上のすべてのトピックを一覧表示できます。

$ heroku kafka:topics

次の CLI コマンドを使用してトピックに関する情報を確認できます。

$ heroku kafka:topics:info my-cool-topic

トピックのテストおよび調査を円滑に行うために、CLI からトピックに書き込むことも、トピックの末尾につなげることもできます。

次の CLI コマンドを使用して、トピックに新しいメッセージを書き込むことができます。

$ heroku kafka:topics:write my-cool-topic MESSAGE

次の CLI コマンドを使用して、トピックをサブスクライブし、そこから新しいメッセージを読むことができます。

$ heroku kafka:topics:tail my-cool-topic

パーティションについて

Kafka トピックは、多数の論理パーティションで設定されます。これらはログをシャードに分割します。それぞれのシャードは、クラスター内で独立して分散され消費できます。

ただし、Kafka の順序付けの保証は、個々のパーティション内でのみ適用されます。つまり、メッセージは生成された順序で消費されますが、複数のパーティションにわたる場合はインターリーブされる可能性があります。

ほとんどのコンシューマーライブラリは、パーティションあたり単一のコンシューマースレッドを割り当てるので、トピックに選択するパーティションの数と、それらにメッセージを配信する方法が、アプリケーションのスケーラビリティにとって重要になります。

コンシューマーがプロデューサーと比べて比較的「低速」である場合は (外部データベースに書き込んでいる場合など)、パーティションの数を増やすことをお勧めします。デフォルトと制限に関する上記のセクションのとおり、現在のプランでは、トピックあたりのデフォルトのパーティション数は 32、トピックあたりの最大のパーティション数は 256、クラスター内の最大のパーティション数は 4000 x ブローカー数になります (たとえば、standard​ プランクラスターでは 12000 のパーティション、extended​ プランクラスターでは 32000 のパーティション)。

クリーンアップポリシー

Kafka は、トピックでのクリーンアップに、時間ベースの保持とログ圧縮の 2 つのプライマリモードをサポートしています。バージョン 0.10.1.0 現在、Kafka は、これらのモードの混合使用をサポートしています。たとえば、トピックは、時間ベースの保持、圧縮、または両方のモードを有効にしてる場合があります。

時間ベースの保持

これは、Kafka トピックのクリーンアップのデフォルトモードです。メッセージは、トピックのパーティションに書き込まれると、時間値が注釈として付けられ、ログセグメントに書き込まれます。ログセグメントは続いて定期的に処理され、保持期間を超えたメッセージは、クリーンアップされ、削除されます。

$ heroku kafka:topics:retention-time my-cool-topic '18 hours'

現在、Apache Kafka on Heroku は、最低の保持期間が 24 時間で、最大の保持期間が standard​ プランでは 2 週間、extended​ プランでは 6 週間です。

ログ圧縮

Kafka は、ログ圧縮​と呼ばれる、トピックでの代替設定をサポートしています。この設定は、所定のキーの最新のメッセージのみを保持し、以前のものはツームストーンするように、トピックのセマンティックスを変更します。これは、バリューストリーム、つまりデータのテーブル様のビューの作成を可能にし、データおよびシステムのモデリングにおける非常に強力な構成概念になります。

圧縮されたトピック (時間ベースの保持を有効にしない) が、時間の経過とともにすべての記憶域を自動的に解放するわけではないことに注意してください。所定のキーに関する最新版のメッセージは、そのキーの新しいメッセージがトピックに書き込まれるか、またはそのキーに対して明示的なツームストーンが書き込まれるかによって、能動的にツームストーンされるまで存続します。このために、無限のキー空間で圧縮されたトピックが、時間の経過とともに無限に増大し、予想外のリソースの使用が促進される場合があります。圧縮したトピックは、プランの限度内に収めるために、慎重に使用し監視する必要があります。

$ heroku kafka:topics:compaction my-cool-topic enable

複製

トピックの複製因子によって、クラスター内のブローカーにわたって維持されるレプリカまたはコピーの数が決まります。複製によって、Kafka クラスター内のデータの耐久性とフォールトトレランスが高まり、クラスターで管理されるデータの量も増大します。

Kafka は、standard​ および extended​ プランで最低 3 の複製因子が必要になるように設定されています。複製は、Kafka クラスター内のブローカー数と同じ値に設定できます。

$ heroku kafka:topics:replication-factor my-cool-topic 3

プロデューサーの承認の設定

プロデューサーの承認設定、つまりプロデューサー acks​ が、レプリカの数に関連しています。これにより、成功したと見なされるまでに、同期レプリカのうち書き込みを承認する必要のあるものの数が決まります。この設定は、複製因子とともに、書き込みのレイテンシーおよび耐久性の保証に影響します。この設定は、Kafka へ生成するために使用するアプリケーションコードに存在しますが、複製と一緒に考慮することが重要です。

acks=0​ の設定は、プロデューサーが、書き込もうと試みたブローカーからの確認を待たずに続行するということを意味します。これによりプロデューサーのレイテンシーが低減することはありますが、サーバーがメッセージを記録したという保証はなされず、クライアントは書き込みを再試行できなくなります。

acks=1​ の設定は、プロデューサーが、メッセージが最初に書き込まれたブローカーだけからの書き込みの確認を待機するということを意味します。プロデューサーの再試行は、この設定でも行われることがありますが、他のトピックのレプリカにデータが同期される前にブローカーインスタンスが失敗した場合、データの損失も引き続き起きる可能性があります。

acks=all​ または acks=-1​ の設定は、続行する前に、すべてのレプリカが同期され、書き込みを承認していることを要求します。複製因子が高いと、これに伴うレイテンシーが増大することがありますが、書き込みに対するデータ障害許容力の保証が最も強力になります。

ACL について

単一テナント (standard​ および extended​) の Apache Kafka On Heroku プランを使用しているお客様に対して、発行済みのサポート対象の ACL ポリシーが用意されています。今後、新しい Changelog の更新なしにこれらの ACL を変更することはありません。

お客様は次の内容にアクセスできます。

• リソースタイプ Topic​ の名前 *​ に対する Read,Write,Describe
• リソースタイプ Group​ の名前 *​ に対する Read,Write,Describe,Delete
• リソースタイプ TransactionalId​ の名前 *​ に対する Describe,Write

Kafka バージョンとクライアント

Heroku は、デフォルトで Apache Kafka バージョン 2.8.1​ を提供しています。

使用可能な Kafka バージョン

Kafka は、接続の暗号化および認証に SSL をサポートし、これが Common Runtime でサポートされる唯一の接続モードになります。このため、SSL 暗号化およびクライアント証明書をサポートするライブラリを使用する必要があります。Private Space では、下記のように、プレーンテキスト接続をオプションで使用できます。Shield Space では、プレーンテキスト接続は許可されません。

バージョンのライフサイクル

Apache Kafka プロジェクトは、約 4 か月​ (3 回/年) で新しいメジャーバージョンをリリースします。このリリーススケジュールに従って、昨年発行したすべてのバージョンを新しいアドオンで使用できるようにします。最新のポイントリリースが使用できるようになった 1 年後、メジャーバージョンを廃止とマークし、新しいアドオンでのこのバージョンの許可を停止します。

バージョンが廃止された後、クラスターは通常どおり動作し続けます。ただし、廃止されたバージョンはバグ修正プログラムやセキュリティパッチを受信せず、コミュニティでサポートされなくなるため、以前のバージョンを実行するには危険が伴うことがわかっています。

Kafka バージョンのアップグレード

専用の Kafka クラスターのバージョンをアップグレードするには、コマンドラインから次のコマンドを使用します。

$ heroku kafka:upgrade --version MAJOR_VERSION_NUMBER

このコマンドは、クラスター内の Kafka ブローカーを新しいバージョンにアップグレードします。クラスターのアップグレードには、ブローカーのプロセス再起動が数回行われますが、これらの再起動は一度に 1 回ずつ行われます。アプリケーションがブローカーの再起動を処理できるとすれば、アップグレードは比較的シームレスに行われます。

ブローカーの再起動を適切に処理できるように、Kafka の堅牢な使用に関する記事​を一読することをお勧めします。アップグレード期間中、クラスターではさまざまなバージョンが実行します。たとえば、0.10.2.1 で 1 つのブローカーが、1.0.2 で 2 つのブローカーがあるとします。

Kafka は、プロトコルの後方互換性を完全に約束しています。つまり、常に、クラスターが実行しているバージョンよりも古い​クライアントプロトコルバージョンを使用できます。ただし、クラスターが実行しているものよりも新しいクライアントバージョンは使用できません。

アップグレード中、アップグレード前​のバージョン以下のバージョンにクライアントを保持しておく必要があります。アップグレードが終わったら (heroku kafka:wait​ にステータスで表示)、新しいプロトコルバージョンとそれがサポートする新しい機能を使用して開始できます。クラスターが実行しているものと同じプロトコルバージョンでクライアントを保持しておく必要はありません (ただし推奨)。

Heroku の最新の推奨バージョン (現時点では 2.8.1​) で、クラスターを最新の状態に保つことをお勧めします。Heroku では、すべての新しい Kafka リリースに対して、アップグレード手順のテストを含めた大量のテストおよび検証作業を実行し、信頼できるバージョンだけを注意深く推奨しています。

言語サポート

多数の言語にわたる数多くの Kafka のクライアントライブラリがあります。下記に一覧表示したものは、Heroku が改善を支援したライブラリか、SSL のサポートのような重要な機能を含む、Kafka 機能の最新のサポートを持っていると思われるライブラリです。

Ruby アプリケーションでの Kafka の使用

Ruby から Kafka に接続するときには、ruby-kafka​ を使用することをお勧めします。

この単純な例​には、Ruby でメッセージを書き込んで消費する方法が示されています。

最新バージョンの ruby-kafka​ では、クライアントを作成するときに ssl_verify_hostname: false​ を指定する必要があります。

Java アプリケーションでの Kafka の使用

Java から Kafka に接続するときには、kafka-clients​ を使用することをお勧めします。

詳細については、『Kafka プロジェクトドキュメント​』を参照してください。

この単純な例​には、Java でメッセージを書き込んで消費する方法が示されています。デモアプリのこのセクション​では、JVM アプリケーション用の TrustStore および KeyStore を扱う適切な例を示しています。

Java Kafka クライアントの最新のバージョンでは、Heroku 上の Apache Kafka に接続する ssl.endpoint.identification.algorithm=​ (空の文字列) を指定する必要があります。

Go アプリケーションでの Kafka の使用

Go から Kafka に接続するときには、sarama​ を使用することをお勧めします。

この単純な例​には、Go でメッセージを書き込んで消費する方法が示されています。

Go での tls​ パッケージの厳密さのため、InsecureSkipVerify​ を true に設定する必要があることに注意​してください。したがって、ブローカー証明書を明示的に確認できます。デモアプリのこのセクション​には、その方法についての適切な例が示されています。

Python アプリケーションでの Kafka の使用

Python の Kafka に接続するときには、confluent-kafka-python​ を使用することをお勧めします。このクライアントライブラリは、C/C++ Kafka ライブラリ​をラップし、バージョン 0.10 に従います。

特に理想より少ない C/C++ ライブラリをラップするシナリオには、kafka-python​ ライブラリもお勧めします。Heroku は、kafka-python​ をより使いやすくするために、kafka-helper​ ライブラリを作成しました。

Node.js アプリケーションでの Kafka の使用

Node.js アプリケーションから Kafka に接続するときには、no-kafka​ を使用することをお勧めします。このライブラリは SSL をサポートするようになり、アクティブに使用され、コミュニティからの寄稿がなされています。

PHP アプリケーションでの Kafka の使用

PHP 用の rdkafka​ 拡張を Heroku で使用できます​。librdkafka​ ライブラリのバインドを提供し、SSL をサポートします。

他の言語またはフレームワークでの Kafka の使用

Confluent Client wiki​ は、他の言語およびフレームワークのクライアントおよびコード例の適切なソースです。

Kafka クラスターへの接続

Kafka へのすべての接続は、SSL 暗号化および認証をサポートします。クラスターが Private Space でプロビジョニングされている場合、プレーンテキストを介して接続するオプションがあります。Shield Space では、プレーンテキスト接続は許可されません。

SSL による接続は、SSL クライアント証明書を介してすべてのトラフィックが暗号化され認証されていることを意味します。

SSL で接続するには、次の環境変数を使用します。

• KAFKA_URL​: クラスターを構成する Kafka ブローカーへの SSL URL のカンマ区切りのリスト。
• KAFKA_TRUSTED_CERT​: 正しいサーバに接続していることを確認するためのブローカーの SSL 証明書 (PEM 形式)。
• KAFKA_CLIENT_CERT​: ブローカーに対してクライアントを認証するための必須クライアント証明書 (PEM 形式)。
• KAFKA_CLIENT_CERT_KEY​: ブローカーに対してクライアントを認証するための必須クライアント証明書キー (PEM 形式)。

Kafka クラスターは、提供されたクライアント証明書を使用した認証を必要とします。 クライアント証明書を使用しないリクエストはすべて、拒否されます。

証明書のローテーション

セキュリティ上、重要なサービスの資格情報は定期的に変更することをお勧めします。Apache Kafka on Heroku でこれを行うには heroku kafka:credentials --reset​ を使用します。

$ heroku kafka:credentials HEROKU_KAFKA_GRAY_URL --reset

このコマンドを発行すると、次のステップが実行されます。

1. クラスターの新しい資格情報が生成されます。
2. 既存のトピックとコンシューマーグループは、新しい ACL を受け取って、新しいクライアント証明書の資格情報を可能にします。
3. 新しい資格情報の準備ができたら、Heroku アプリケーションで関連する環境設定を更新します。
4. 5 分間にわたって、古いクライアント証明書と新しいクライアント証明書の両方が有効なままです。これにより、新しいクライアント証明書がアプリに組み入れられる時間が得られます。
5. 5 分後、古いクライアント証明書資格情報は期限切れになり、有効でなくなります。

外部リソースから Private または Shield の Kafka クラスターに接続する

「外部リソースから Private または Shield の Kafka クラスターに接続する」の記事​を参照してください。

ログを介したモニタリング

専用クラスタープラン (standard​ または extended​ プラン) の場合、Kafka アクティビティは、Heroku ログストリーム内で観察できます。basic​ プランタイプのログ記録オプションは、将来配信されます。

Kafka 自体からの出力は、ログストリームに書き込まれ、[heroku-kafka] の接頭辞が付けられます。クラスター内のホストからのシステムメトリクスは、[heroku-kafka.N] と書き込まれます。ここで N は、ログ行の原因のノードのブローカー ID です。

$ heroku logs --tail --ps heroku-kafka

ログメトリクス

Kafka はログを介してメトリクスを提供します。これらのメトリクスは、ブローカーごとに基づいて、次のようなログ行に表示されます。

2016-06-20T22:46:31+00:00 kafka[kafka-globular-94829.0]: pri=WARN  t=Controller-0-to-broker-0-send-thread at=RequestSendThread [Controller-0-to-broker-0-send-thread], Controller 0 epoch 3 fails to send request {controller_id=0,controller_epoch=3,partition_states=[{topic=topical,partition=12,controller_epoch=3,leader=1,leader_epoch=0,isr=[1,0],zk_version=0,replicas=[1,0]},{topic=topical,partition=23,controller_epoch=3,leader=0,leader_epoch=0,isr=[0,1],zk_version=0,replicas=[0,1]},{topic=topical,partition=15,controller_epoch=3,leader=0,leader_epoch=0,isr=[0,1],zk_version=0,replicas=[0,1]},{topic=topical,partition=4,controller_epoch=3,leader=1,leader_epoch=0,...

さらに、次の形式で Zookeeper のログ行も利用できます。

2016-06-20T19:34:49+00:00 zookeeper[kafka-encircled-70706.0]: pri=WARN  t=main at=QuorumPeerConfig No server failure will be tolerated. You need at least 3 servers.
2016-06-20T19:34:49+00:00 zookeeper[kafka-encircled-70706.1]: pri=WARN  t=main at=QuorumPeerConfig No server failure will be tolerated. You need at least 3 servers.

Kafka メトリクス

これらのメトリクスは、クラスター内の個々のノードに適用されます。

• sample#bytes-in-per-second​: クラスターにより取り込まれる秒あたりのバイト数。これは複製を考慮に入れることに注意してください。したがって、プロデューサーが送信するよりも多くの秒あたりのバイト数がここに表示されます。
• sample#bytes-out-per-second​: クラスターにより出力される秒あたりのバイト数。これは複製を考慮に入れることに注意してください。したがって、コンシューマーが読み取るよりも多くの秒あたりのバイト数がここに表示されます。

サーバーメトリクス

これらのメトリクスはサーバーオペレーティングシステムから直接得られます。

• sample#load-avg-1m​、sample#load-avg-5m​、および sample#load-avg-15m​: 1 分、5 分、および 15 分の期間での平均システム負荷。これらは使用可能な CPU の数で分けられます。1.0 の負荷平均は、プロセスが平均で 100% のタイムスパンに CPU リソースを要求していたことを示します。この数値には I/O の待機が含まれます。
• sample#read-iops​ および sample#write-iops​: 16 KB ブロックの I/O サイズでの読み取りまたは書き込み操作の数。
• sample#memory-total​: 使用中のサーバーメモリの合計量 (KB 単位)。これには、すべての Kafka プロセス、OS メモリ、およびディスクキャッシュで使用されるメモリが含まれます。
• sample#memory-free​: 使用可能な空きメモリの量 (KB 単位)。
• sample#memory-cached​: ページキャッシュに OS で使用されているメモリの量 (KB 単位)。

地域固有のガイダンス

Kafka は、Heroku により現在サポートされている​すべての地域で使用できます。

Heroku は、Kafka ブローカーをネットワーク可用性ゾーンにわたって配信し、システムまたはハードウェアの障害に対する障害許容力を高めるために、Kafka のラック対応パーティション割り当て​を利用します。一部の地域には、さまざまな数のネットワーク可用性ゾーンがありますが、目的のフォールトトレランスを達成するにはさらに慎重になる必要があります。

フランクフルト、シドニー、および東京の地域

フランクフルト、シドニー、および東京の地域には、ネットワーク可用性ゾーンが 2 つだけあります。この設定を考慮すると、これらの地域で使用される Kafka アドオンを、少なくとも複製因子 4 の extended​ プランにすることをお勧めします。3 ブローカー standard​ プランは、最終的に 2 つのブローカーが 1 つのネットワーク可用性ゾーンに含まれることになり、そのゾーンで障害が発生した場合、3 つのレプリカのうち 1 つのレプリカだけがそのプランレベルで使用され続けます。8 ブローカー extended​ プランでは、各ゾーンに障害に耐えられる十分なブローカーがあり、4 つのレプリカの設定は、各ゾーンで 2 つのレプリカを提供します。

ノード障害の課題

分散データベースは、ノードに障害が生じても操作できるように設計されています。残念ながら、ノードの障害中、データベースは使用可能なままであっても、パフォーマンスや他の特性は低下することがあります。データが新しいノードに複製される間に負荷を受けるので、負荷の高いクラスターにノードを追加すると、同様の動作になる可能性があります。Apache Kafka on Heroku は、クラスタ内のノードの 1 つに障害を引き起こすために使用できる CLI ツールを用意しています。

$ heroku kafka:fail

障害時、自動化されたシステムは、通常の操作を回復するように機能します。障害の発生したノードで多大な負荷がかかった状態で、アプリケーションが正常に動作するか検証することをお勧めします。これはステージング環境で検証することをお勧めします。

catastrophic​ フラグは、ノードを単に再起動するのではなく、実際にノードを破棄してクラスター内でそれを置き換えます。これにより、置換ノードがその状態を再同期している間、十分な追加の読み取りトラフィックが他のノードに配置されます。

$ heroku kafka:fail --catastrophic

アドオンの削除

Kafka は CLI を使用して削除できます。

$ heroku addons:destroy heroku-kafka
-----> Removing heroku-kafka from kafka-demo... done, v20 (free)