Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。十分な理解に達したときに得られる大きな報酬、という面から、まさに小説家にちなんだその名に相応しいものです。はるかに効率的なものにすることができるのです。Kafkaのデプロイメントを最適化し、管理をより簡単にするための10のヒントをここで紹介しましょう。ZooKeeperを最大限活用するレプリケーションと冗長性を適切にセットアップするトピックの設定に注意する並列処理を使用するセキュリティに留意してKafkaの設定と分離を行なうシステム停止を回避するためにUlimitを高く設定するネットワークレイテンシを抑制するモニタリングとアラートを効果的に活用する関連スポンサーコンテンツこれらのベストプラクティスを詳しく見てみましょう。ログの管理がしやすいようにログ設定パラメータを設定するKafkaはユーザのために、ログ設定のオプションをたくさん提供しています。デフォルト設定は妥当なものですが、自身の特定の条件に合わせてログ動作をカスタマイズすれば、管理面での課題の発生を長期にわたって防止することができます。ログの保存ポリシ、クリーンアップ、コンパクト化、圧縮アクティビティなどがこれに含まれます。ログの動作は、log.segment.bytes、log.segment.ms、log.cleanup.policy(あるいはトピックレベルの同等の)パラメータを使ってコントロールすることができます。過去ログを必要としないユースケースの場合は、cleanup.policyを“delete”に設定することで、一定のファイルサイズあるいは設定した時間経過後にログファイルを削除することが可能です。必要ならば、ログの保持方法を“compact”とすることもできます。ログのクリーンアップはCPUとRAMを消費する、ということを理解しておく必要があります。Kafkaをコミットログとして長期間使用する場合、圧縮の頻度とパフォーマンス維持の必要性のバランスに注意してください。圧縮のプロセスでは、(単一トピックパーティション内のデータのログに対して)少なくともメッセージキーの最後の既知の値を保持することが保証されています。圧縮処理ではトピックの各キーに作用して最終値を保持し、それ以外の重複をすべてクリーンアップしています。削除する場合、キーは’null’値として残されます(削除の比喩的な表現として、’tombstone(墓碑)’と呼ばれています)。Kafkaのコミットログ圧縮プロセス(引用元)Kafkaコミットログのドキュメントは次のものです。BasicsKafkaのハードウェア要件(の低さ)を知るKafkaに不慣れなチームには、そのハードウェア要件を大きく見過ぎる傾向がありますが、実際のKafkaはオーバーヘッドが低く、水平スケーリング性に優れた設計がなされています。このため、価格の安いコモディティハードウェアを使用しても、Kafkaを運用することは十分可能です。SSLとログ圧縮を必要としない限り、強力なCPUは必要ありません。コア数が多いほど、並列性が向上します。圧縮が重要でなければ、ほとんどのシナリオにおいて、最高のパフォーマンスを得るためにLZ4コーデックを使用するべきです。ほとんどの場合、ヒープ領域に6GBのRAMがあれば最適な実行が可能です。運用負荷が大きい場合は、32GB以上のマシンを使用してください。余剰RAMはOSページキャッシュに使用され、クライアントのスループットが向上します。Kafkaは少ないRAMで動作可能ですが、使用可能なメモリが少ない場合は処理能力に影響があります。Kafkaは、複数のドライブによるRAIDセットアップを使用すると良好に動作します。KafkaのシーケンシャルなディスクI/Oパラダイムのため、SSDには大きなメリットはありません。NASは使用しないでください。状況が許せば、クラスタを単一のデータセンタに保つため、XFSを推奨します。ネットワーク帯域幅は可能な限り確保してください。KafkaのWebサイトには専用のハードウェアやOS設定のセクションがあって、貴重な助言が提供されています。その他、Kafkaロード/パフォーマンステストに関する有益なリンクとしては、以下のものがあります。ZooKeeperクラスタの実行は、Kafkaを実行するための重要な依存関係です。ZooKeeperをKafkaで使用する場合には、注意すべき重要なベストプラクティスがいくつかあります。ZooKeeperのノード数は最大で5つとする必要があります。開発環境ではひとつのノードが適切です。Kafkaクラスタの運用では、ほとんどの場合、3つで十分です。大規模なデプロイメントでは、レイテンシ低減のために5つのZooKeeperノードが必要になる場合もありますが、ノードの負荷を考慮する必要があります。7つ以上のノードでは同期や要求処理の負荷が大きくなるため、パフォーマンスが著しく低下する可能性があります。Kafkaの最近のバージョンでは、コンシューマオフセットの格納にZooKeeperを使用していた以前のバージョンに比較して、ZooKeeperの負荷がはるかに低くなっている点にも注意してください。最後に、Kafkaのハードウェア要件にもあるように、ZooKeeperに可能な限り強力なネットワーク帯域を提供してください。最高のディスクを使用する、ログを分割して格納する、ZooKeeperプロセスを分離する、スワップを無効にする、といったことによっても、レイテンシが低減されます。下の表は、ZooKeeperに依存するコンソール操作について、Kaflaのバージョン毎に示したものです。0.8.0以前のバージョンでは、コンソールで使用可能な機能は多くありませんでしたが、0.10.0.0以降では、いくつかの主要な機能がZooKeeperから移動しているのが分かります。その結果、ZooKeeperの利用度は低減しています。Kafkaデプロイメントのレジリエンスは、すべてが適切な管理に依存しています。重要なプラクティスのひとつは、Kafkaのデフォルトのレプリケーション係数を2から3に増やすことです。これはほとんどの運用環境で適切な値です。これによって、ひとつのブローカの損失は問題にならず、2つが失われても可用性の損なわれることが少なくなります。ひとつ考慮すべき点は、データセンタのラックゾーンです。AWSを使用する場合、複数のKafkaサーバが同じリージョンにあるかも知れませんが、複数のアベイラビリティゾーンを使うことで冗長性とレジリエンスが実現できます。レプリケーションと冗長性を適切にセットアップしてください。ラックのデプロイメントで考慮すべきKafkaの構成パラメータは次のものです。replication-factor)の異なるラックに分割されます)。例:3つのラックにまたがる、9つのKafkaブローカ(B1-B9)を考えてみましょう。ラックを考慮したKafkaクラスタこの場合、3つのパーティション(P1、P2、P3)と3のレプリケーション係数(R1、R2、R3)を持つひとつのトピックが、ラックごとにひとつのノードを割り当てたひとつのパーティションを保持します。このシナリオでは、ひとつのラックに障害が発生しても(図に示すように)、各パーティションの2つのレプリカによって高可用性が実現されます。トピックの設定に注意するトピックの設定は、Kafkaクラスタのパフォーマンスに極めて大きな影響を与えます。レプリケーション係数やパーティション数などの運用中の変更は困難な場合があるため、これらは最初に適切な設定をして、変更が必要な場合はトピックを新たに生成するのみにすることをお勧めします(新しいトピックはステージング環境で必ずテストしてください)。大きなメッセージの処理には注意してください。可能であれば、順序付けた部分に分割するか、データへのポインタ(S3へのリンクなど)を使いましょう。これらの方法が使用できない場合は、プロデューサ側で圧縮を有効にします。ログのセグメントサイズの既定値は1GBです。メッセージがこれより大きい場合は、ユースケースを詳しく調べる必要があります。パーティション数の設定も重要です。これについては、次のセクションで詳しく説明します。トピックの設定には“サーバデフォルト”プロパティがありますが、トピックの生成時またはその後でオーバーライドして、トピック固有の設定を行うことができます。これまで述べたように、レプリケーション係数は最も重要な設定値のひとつです。次の例では、3のレプリケーション係数と3つのパーティション、その他の“トピックレベル”の設定を指定して、コンソールからトピックを生成しています。flush.messages=1トピックレベルの設定値の全リストはこちらをご覧ください。並列処理を使用するKafkaは並列処理用に設計されています。並列化そのものの動作がそうであるように、完全に活用するにはバランスの取れた動作が必要です。パーティション数はトピックレベルの設定値であり、パーティションが多いほど並列化とスループットは向上しますが、それに伴ってレプリケーションのレイテンシ、再バランス、オープンするサーバファイルの数も増えます。最適なパーティション設定を見つけるには、現在のハードウェアで実現したいスループットを計算した上で、必要なパーティション数を求める算数を実行すればよいのです。控えめな見積によると、ひとつのトピックのひとつのパーティションは10MB/秒のデリバリが可能です。この見積値から外挿することで、必要なスループットの合計に到達することができます。テスト可能な別の方法として、ブローカ毎、トピック毎にひとつのパーティションを使用して結果を確認し、もっとスループットが必要ならば結果を確認し、パーティション数を2倍にするという方法もあります。全体として、ここでの有用なルールは、トピックの合計パーティション数を10未満に、クラスタ全体のパーティション総数を10,000以下にすることです。それ以上の場合は、極めて能力の高い監視機能が必要であると同時に、非常に困難な再調整やシステム停止を覚悟しなければなりません!パーティション数は次のように、Kafkaトピックの生成時に指定します。flush.messages=1パーティション数は作成後に増やすこともできますが、コンシューマに影響を与える可能性があるので、すべての結果に対処した上でこのオペレーションを行うようにお勧めします。9リリースには、Kafka/クライアントおよびKafka/ZooKeeprの認証サポートに加えて、公衆インターネットクライアントにおいてシステムを保護するためのTLSサポートなど、価値のあるセキュリティ機能が含まれていました。TLSにはスループットとパフォーマンス上のコストが伴いますが、Kafkaブローカとのトラフィックを効果的に分離し、保護します。セキュリティ上不可欠なのは、KafkaとZooKeeperを分離することです。レアケースを別にすれば、ZooKeeperは公衆インターネットには絶対に接続せず、Kafka(あるいは使用する他のソリューション)との通信に特化する必要があります。ファイアウォールあるいはセキュリティグループでは、kafkaとZooKeeperをブローカとともに隔離して、外部接続を拒否する単一のプライベートネット内に置くべきです。ミドルウェアあるいはロードバランシングレイヤによって、パブリックインターネットクライアントからKafkaを隔離することが必要です。カフカのセキュリティオプションとプロトコルは次のとおりです。クライアントからブローカ、ブローカ間、ブローカからツールへの認証。クライアントとブローカ間、ブローカ間、ツールからブローカへのデータの暗号化。クライアント認証(ブローカ、ツール、プロデューサ、コンシューマ)、ACLによる認証。Kafkaブローカ、プロデューサ、コンシューマ、その他のツール*認証はプラグ可能。SASL_SSLによるセキュリティ設定の設定例を示します。PASSWORD]";システム停止を回避するためにUlimitを高く設定する非常に頻繁に発生するシナリオとして、ブローカが負荷が過大と思われる状況から復帰したにも関わらず、実際には(これもストレスではありますが)“オープンファイルが多過ぎる”という穏便なエラーが通知される場合があります。/etc/sysctl.confを編集して、128,000以上のファイルのオープンが可能なようにUlimitを設定すれば、このエラーの発生を抑止することができます。CentOSでulimitを増やす例を示します。ファイル/etc/security/limits.d/nofile.confを新たに作成する以下の内容を入力する。ulimitを増やす方法は他にもあります。自身のLinuxディストリビューションに適した方法に従ってください。ネットワークレイテンシを抑制するKafkaデプロイメントのレイテンシを低減するには、ブローカをクライアントから地理的に最も近いリージョンに配置するとともに、クラウドプロバイダが提供するインスタンスを選択する際に、ネットワークパフォーマンスを考慮する必要があります。帯域幅が制限となっている場合は、大規模でパワフルなサーバへの投資が有効かも知れません。モニタリングとアラートを効果的に活用するKafkaクラスタの生成時に上記のプラクティスに従うことは、将来的にさまざまな問題からあなたを救うことになります。問題になる前に、障害を認識して適切に対処したいと思うかも知れません。GC停止およびヒープ使用量などJVM状態を監視することは、非常に重要です。ダッシュボードや履歴ツールはデバッグプロセスの短縮を可能にし、さまざまな価値を提供します。それと同時に、レイテンシの急増やディスク領域の低下といった現象の発生を警告するようにNagiosやPagerDutyといった警告システムを設定しておくことで、雪玉のように膨らむ前の小さな問題に対処できるようになります。Instaclustrコンソールを使用したKafkaの監視グラフの例を示します。Bromhead氏はInstaclustrのCTO(最高技術責任者)です。Spark、Elasticsearchといったオープンソース技術の管理サービスプラットフォームを提供しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。