Kafka 上の非同期 API を使用した返金ツール サービスの開発経験

合理化されたプロセスと相互接続された多数のサービスを備えた Lamoda のような大企業に、アプローチの大幅な変更を強いるものは何でしょうか? 動機は、立法的なものから、すべてのプログラマーに内在する実験への欲求まで、まったく異なる場合があります。

しかし、これは追加のメリットを期待できないという意味ではありません。 Sergey Zaika が、Kafka にイベント駆動型 API を実装すると具体的に何が得られるのかを教えてくれます (少数派）。 また、大物や興味深い発見についての話題も必ずあります。実験はそれらなしでは成り立ちません。

免責事項: この記事は、Sergey が 2018 年 XNUMX 月に HighLoad++ で開催したミートアップの資料に基づいています。 Lamoda 氏による Kafka との共同作業のライブ体験は、スケジュール上の他のレポートと同様にリスナーを魅了しました。 これは、同じ考えを持つ人々を常に見つけることができ、またそうすべきであるという事実の好例であると私たちは考えています。HighLoad++ の主催者は、これを促進する雰囲気を作り出すよう引き続き努力していきます。

プロセスについて

Lamoda は、独自のコンタクト センター、配送サービス (および多くの関連会社)、写真スタジオ、巨大な倉庫を備えた大規模な電子商取引プラットフォームであり、これらすべてが独自のソフトウェアで実行されます。 支払い方法は数十あり、B2B パートナーはこれらのサービスの一部またはすべてを使用し、自社の製品に関する最新情報を知りたいと考えています。 さらに、Lamoda はロシア連邦以外の XNUMX か国で事業を展開していますが、そこではすべてが少し異なります。 新しい注文を構成するには、合計でおそらく XNUMX を超える方法があり、独自の方法で処理する必要があります。 これらすべては、時には非明確な方法で通信する数十のサービスの助けを借りて機能します。 注文ステータスを主な責任とする中央システムもあります。 私たちは彼女をBOBと呼び、私は彼女と一緒に働いています。

イベント駆動型APIを使用した返金ツール

イベント駆動という言葉は非常に陳腐なものですが、これが何を意味するのかについては、もう少し詳しく定義します。 Kafka でイベント駆動型 API アプローチを試すことにした背景から始めます。

どのお店でも、お客様がお金を払って注文するだけでなく、商品が合わなかったなどの理由でお店側から返金を求められることもあります。 これは比較的短いプロセスです。必要に応じて情報を明らかにし、送金します。

しかし、法律の変更によりリターンはより複雑になり、そのために別のマイクロサービスを実装する必要がありました。

私たちの動機:

1. 法律 FZ-54 - つまり、法律は、申告であろうと領収書であろうと、あらゆる金銭取引について、数分というかなり短い SLA 以内に税務署に報告することを義務付けています。 私たちは電子商取引企業として、非常に多くの業務を行っています。 技術的には、これは新しい責任 (したがって新しいサービス) と、関連するすべてのシステムの改善を意味します。
2. ボブ分割 は、BOB を多くの非中核的な責任から解放し、全体の複雑さを軽減するための社内プロジェクトです。

この図は、主要な Lamoda システムを示しています。 今、それらのほとんどはそれ以上です 縮小するモノリスの周りに 5 ～ 10 個のマイクロサービスを配置。 それらはゆっくりと成長していますが、中央で選択したフラグメントを展開するのは怖いため、より小さくしようとしています。これを落下させることはできません。 すべての取引所 (矢印) を予約し、そのうちのいずれかが利用できなくなる可能性があるという事実を考慮する必要があります。

BOB には、支払いシステム、配送システム、通知システムなど、非常に多くの取引所もあります。

技術的には BOB は次のとおりです。

• コードが約 150 行 + テストが約 100 行。
• php7.2 + Zend 1 & Symfony コンポーネント 3;
• 100 を超える API と最大 50 のアウトバウンド統合。
• 独自のビジネス ロジックを持つ 4 か国。

BOB の導入には費用と労力がかかり、解決されるコードと問題の量は誰も頭の中にすべてを入れられないほどです。 一般に、簡略化する理由はたくさんあります。

返品手続き

最初は、BOB と Payment という XNUMX つのシステムがプロセスに関与します。 さらに XNUMX つが表示されます。

• 財政化サービス: 財政化および外部サービスとの通信に関する問題に対処します。
• 返金ツール。BOB を膨らませないよう、単に新しい交換が含まれています。

プロセスは次のようになります。

1. BOB は返金のリクエストを受け取ります。
2. BOB がこの返金ツールについて語ります。
3. 返金ツールは支払いに「お金を返してください」と指示します。
4. 支払いはお金を返します。
5. Refund Tool と BOB はステータスを相互に同期します。これは、現時点では両方とも必要であるためです。 BOB には UI、会計用のレポート、および一般にそれほど簡単には転送できない大量のデータがあるため、まだ返金ツールに完全に切り替える準備ができていません。 ２つの椅子に座らなければなりません。
6. 財政化の要請はなくなる。

その結果、Kafka 上で一種のイベント バス、つまりすべてが始まるイベント バスを作成しました。 万歳、これで単一障害点ができました (皮肉)。

長所と短所は非常に明白です。 私たちはバスを作ったので、今ではすべてのサービスがバスに依存していることになります。 これにより設計は簡素化されますが、システムに単一障害点が生じます。 Kafka がクラッシュし、プロセスが停止します。

イベント駆動型APIとは

この質問に対する良い答えは、Martin Fowler によるレポート (GOTO 2017) にあります。 「イベント駆動型アーキテクチャのさまざまな意味」.

私たちがやったことを簡単に説明すると、

1. すべての非同期交換を次のようにまとめます。 イベントストレージ。 ステータスの変化について関心のあるすべての消費者にネットワーク経由で通知する代わりに、ステータスの変化に関するイベントを集中ストレージに書き込み、トピックに興味のある消費者はそこに表示されるすべてを読み取ります。
2. この場合のイベントは通知です (通知）どこかで何かが変わったということです。 たとえば、注文ステータスが変更されました。 通知に含まれていないステータス変化に伴うデータに興味のある消費者は、自らそのステータスを知ることができる。
3. 最大のオプションは本格的なイベント ソーシングです。 状態転送どのイベントには、処理に必要なすべての情報 (イベントがどこから来たのか、どのような状態になったのか、データがどのように正確に変更されたのかなど) が含まれています。唯一の問題は、実現可能性と保存できる情報の量です。

返金ツールの立ち上げの一環として、私たちは XNUMX 番目のオプションを使用しました。 これにより、詳細な情報を抽出する必要がなくなったため、イベント処理が簡素化され、さらに、新しいイベントが発生するたびにコンシューマーからの明確な取得リクエストが大量に生成されるというシナリオが排除されました。

返金ツールサービス 読み込まれていないしたがって、カフカには必要というよりもペンの味があります。 返金サービスが負荷の高いプロジェクトになったら、ビジネスは満足しないと思います。

現状のままの非同期交換

非同期交換の場合、PHP 部門は通常 RabbitMQ を使用します。 リクエストのデータを収集してキューに入れ、同じサービスのコンシューマーがそれを読み取って送信しました (または送信しませんでした)。 API 自体については、Lamoda は Swagger を積極的に使用しています。 API を設計し、Swagger で記述し、クライアントとサーバーのコードを生成します。 また、わずかに強化された JSON RPC 2.0 も使用します。

ESB バスが使用されている場所もあれば、activeMQ 上にある場所もありますが、一般的には、 RabbitMQ - 標準.

非同期交換の予定

イベントバスを介した交換を設計する場合、類似点をたどることができます。 同様に、イベント構造の記述を通じて将来のデータ交換についても説明します。 yaml 形式では、コード生成を自分たちで行う必要があり、ジェネレーターは仕様に従って DTO を作成し、クライアントとサーバーにそれらを操作するよう教えます。 世代は XNUMX つの言語に移行します - golangとphp。 これはライブラリの一貫性を保つのに役立ちます。 このジェネレーターは golang で書かれているため、gogi という名前が付けられました。

Kafka でのイベントソーシングは典型的なものです。 Kafka Confluent のメイン エンタープライズ バージョンからのソリューションがあります。 ナカディ、ドメイン兄弟 Zalando からのソリューションです。 私たちの バニラ Kafka を始める動機 - これは、最終的にどこでも使用するかどうかを決定するまでソリューションを無料のままにし、操作や改善の余地を残しておくことを意味します。 JSON RPC 2.0、XNUMXつの言語用のジェネレーター、そして他に何か見てみましょう。

皮肉なことに、このようなめでたいケースでも、ほぼ同様のソリューションを作成した Zalando というほぼ同様のビジネスが存在すると、それを有効に活用できないのです。

起動時のアーキテクチャ パターンは次のとおりです。Kafka から直接読み取りますが、書き込みはイベント バス経由でのみ行われます。 Kafka には、ブローカー、バランサーなど、すぐに読み取れるものがたくさんあります。また、多かれ少なかれ水平スケーリングの準備ができています。私はこれを保持しておきたかったのです。 私たちは XNUMX つのゲートウェイ、別名イベントバスを通じて録音を完了したいと考えていました。その理由は次のとおりです。

イベントバス

あるいはイベントバスとか。 これは単なるステートレス http ゲートウェイであり、いくつかの重要な役割を担います。

• 検証の作成 — イベントが仕様を満たしていることを確認します。
• イベントマスターシステムつまり、これは、どのイベントとどの構造が有効であると見なされるかという質問に答える、会社の主要かつ唯一のシステムです。 検証には、データ型と列挙型を使用してコンテンツを厳密に指定するだけです。
• ハッシュ関数 シャーディングの場合 - Kafka メッセージ構造はキーと値であり、キーのハッシュを使用してキーを配置する場所が計算されます。

なぜ

私たちは合理化されたプロセスを備えた大企業で働いています。 なぜ何かを変えるのでしょうか？ これは実験です、そしていくつかの利点が得られると期待しています。

1:n+1 交換 (XNUMX 対多)

Kafka を使用すると、新しいコンシューマーを API に接続するのが非常に簡単になります。

複数のシステム (およびいくつかの新しいシステム) で同時に最新の状態に保つ必要があるディレクトリがあるとします。 以前は、set-API を実装したバンドルを発明し、マスター システムにコンシューマー アドレスを通知しました。 これで、マスター システムがトピックに更新情報を送信し、興味のある人は全員それを読むようになります。 新しいシステムが登場しました - 私たちはそれをトピックに登録しました。 はい、バンドルも可能ですが、よりシンプルです。

BOB の一部である返金ツールの場合、Kafka を通じて同期を維持すると便利です。 支払いには、お金が返されたと記載されています。BOB と RT がこれを知り、ステータスを変更し、財政化サービスがこれを知り、小切手を発行しました。

注文/返品に関するニュースをクライアントに通知する統合通知サービスを作成する計画があります。 現在、この責任はシステム間で分散されています。 Kafka から関連情報を取得してそれに応答する (そして他のシステムでこれらの通知を無効にする) ように通知サービスを教えるだけで十分です。 新たに直接交換する必要はありません。

データ駆動型

どのような「血のにじむような企業」であっても、またバックログがどれほど大きくても、システム間の情報は透明になります。 Lamoda には、システムからデータを収集し、ビジネスとインテリジェント システムの両方で再利用可能な形式に変換するデータ分析部門があります。 Kafka を使用すると、大量のデータをすばやく提供し、その情報の流れを最新の状態に保つことができます。

レプリケーションログ

RabbitMQ のように、メッセージは読み取られた後に消えません。 イベントに処理に十分な情報が含まれている場合、オブジェクトに対する最近の変更の履歴が得られ、必要に応じてこれらの変更を適用することができます。

レプリケーション ログの保存期間は、このトピックへの書き込みの強度によって異なります。Kafka を使用すると、保存時間とデータ ボリュームの制限を柔軟に設定できます。 集中的なトピックの場合、たとえ短期間操作不能になった場合でも、情報が消える前にすべての消費者が情報を読む時間を確保できることが重要です。 通常は以下のデータを保存することが可能です 日の単位, サポートとしては十分です。

次に、Kafka に詳しくない人のためにドキュメントを少し再説明します (写真もドキュメントからのものです)

AMQP にはキューがあります。コンシューマー向けにメッセージをキューに書き込みます。 通常、XNUMX つのキューは、同じビジネス ロジックを備えた XNUMX つのシステムによって処理されます。 複数のシステムに通知する必要がある場合は、アプリケーションに複数のキューに書き込むように指示したり、キュー自体のクローンを作成するファンアウト メカニズムを使用して交換を構成したりすることができます。

Kafka にも同様の抽象化があります トピック、メッセージを書きますが、読んでも消えません。 デフォルトでは、Kafka に接続すると、すべてのメッセージを受信し、中断したところから保存するオプションが表示されます。 つまり、順番に読んでいきます。メッセージを既読としてマークすることはできませんが、ID を保存して、そこから読み続けることができます。 決定した ID はオフセットと呼ばれ、そのメカニズムはコミット オフセットです。

したがって、異なるロジックを実装することができます。 たとえば、さまざまな国の 4 つのインスタンスに BOB があります。Lamoda はロシア、カザフスタン、ウクライナ、ベラルーシにあります。 これらは別々にデプロイされるため、構成と独自のビジネス ロジックが若干異なります。 メッセージには、それがどの国を指すのかを示します。 各国の各 BOB 消費者は異なる groupId を使用して読み取り、メッセージが自分に当てはまらない場合はスキップします。 すぐにオフセット +1 をコミットします。 同じトピックが当社の支払いサービスによって読み取られる場合、別のグループで読み取られるため、オフセットは交差しません。

イベント要件:

• データの完全性。 イベントを処理できるように十分なデータが必要です。

• 誠実さ イベントに一貫性があり、イベントを処理できるかどうかの検証を Events-bus に委任します。
• 順序は重要です。 復帰の場合、私たちは歴史に対処することを余儀なくされます。 通知の場合、順序は重要ではありません。通知が同種の場合、どの順序が最初に到着したかに関係なく、電子メールは同じになります。 返金の場合には明確なプロセスがあり、注文を変更した場合は例外が発生し、返金は作成または処理されず、最終的には異なるステータスになります。
• 一貫性。 私たちはストアを持っており、現在は API の代わりにイベントを作成しています。 新しいイベントや既存のイベントの変更に関する情報を迅速かつ安価にサービスに送信する方法が必要です。 これは、別の git リポジトリとコード ジェネレーターの共通仕様を通じて実現されます。 したがって、異なるサービスのクライアントとサーバーが調整されます。

ラモーダのカフカ

XNUMX つの Kafka インストールがあります。

1. ログ;
2. 研究開発;
3. イベントバス。

今日は最後の点についてのみ話します。 events-bus では、それほど大規模なインストールはありません - 3 つのブローカー (サーバー) と 27 のトピックだけです。 原則として、XNUMX つのトピックが XNUMX つのプロセスになります。 しかし、これは微妙な点なので、これから触れていきます。

上はRPSグラフです。 返金プロセスは青緑色の線 (はい、X 軸上の線) でマークされており、ピンク色の線はコンテンツ更新プロセスです。

Lamoda のカタログには何百万もの製品が含まれており、データは常に更新されます。 一部のコレクションは時代遅れになり、それに代わる新しいコレクションがリリースされ、カタログには常に新しいモデルが登場します。 私たちは、お客様が明日何を興味を持つかを予測しようとしているため、常に新しいものを購入し、写真を撮り、陳列ケースを更新しています。

ピンク色のピークは製品のアップデート、つまり製品の変更です。 みんなが写真を撮り、写真を撮り、そしてまた写真を撮っていることがわかります。 — イベントのパックをロードしました。

Lamoda イベントの使用例

構築されたアーキテクチャを次の操作に使用します。

• 返品状況の追跡: 関連するすべてのシステムからの行動喚起とステータス追跡。 支払い、ステータス、会計処理、通知。 ここで私たちはアプローチをテストし、ツールを作成し、すべてのバグを収集し、ドキュメントを作成し、その使用方法を同僚に伝えました。
• 製品カードの更新: 構成、メタデータ、特性。 XNUMX つのシステムが読み取り (表示) を行い、複数のシステムが書き込みを行います。
• 電子メール、プッシュ、SMS：注文が集まりました、注文が到着しました、返品が受け付けられました、など、たくさんあります。
• 在庫・倉庫リニューアル — アイテムの定量的な更新、数値だけ: 倉庫への到着、返品。 商品の予約に関連するすべてのシステムが最新のデータで動作する必要があります。 現在、株価更新システムは非常に複雑ですが、Kafka によって簡素化されます。
• データ解析 (研究開発部門)、ML ツール、分析、統計。 私たちは情報の透明性を望んでいます。Kafka はこれに適しています。

ここで、過去 XNUMX か月間に起こった大きな変化と興味深い発見についてのさらに興味深い部分を説明します。

設計上の問題

新しいことをしたいとします。たとえば、配信プロセス全体を Kafka に転送します。 現在、プロセスの一部は BOB の注文処理に実装されています。 配送サービスへの注文の転送、中間倉庫への移動などの背後にはステータス モデルがあります。 モノリス全体 (場合によっては XNUMX つ) に加えて、配信専用の API が多数あります。 彼らは配達についてもっと詳しく知っています。

これらは似た領域のように見えますが、BOB の注文処理と出荷システムではステータスが異なります。 たとえば、一部の宅配便サービスは中間ステータスを送信せず、「配達済み」または「紛失」という最終ステータスのみを送信します。 逆に、商品の移動について詳細に報告する人もいます。 誰もが独自の検証ルールを持っています。電子メールが有効である、つまり処理されるという人もいます。 他の人にとっては、それは無効ですが、連絡先の電話番号があるため注文は引き続き処理され、誰かがそのような注文はまったく処理されないと言うでしょう。

データストリーム

Kafka の場合、データ フローを整理するという問題が生じます。 このタスクでは、いくつかのポイントに基づいて戦略を選択する必要があります。すべてを見てみましょう。

XNUMX つのトピック内でしょうか、それとも別のトピック内でしょうか?

イベント仕様書がございます。 BOB では、これこれの注文を配送する必要があることを記述し、注文番号、その構成、いくつかの SKU とバーコードなどを示します。 商品が倉庫に到着すると、配送業者はステータス、タイムスタンプ、その他必要なものすべてを受け取ることができます。 ただし、このデータの更新を BOB で受信したいと考えています。 配信からデータを受信する逆のプロセスがあります。 これも同じイベントですか？ それとも、これは独自のトピックに値する別のやり取りなのでしょうか?

ほとんどの場合、それらは非常に似ており、トピックを XNUMX つ作成したいという誘惑に根拠がないわけではありません。トピックが別であるということは、コンシューマが別、構成が別、これらすべての世代が別であることを意味するからです。 しかし、事実ではありません。

新しいフィールドか新しいイベントか？

しかし、同じイベントを使用すると、別の問題が発生します。 たとえば、すべての配信システムが BOB が生成できる種類の DTO を生成できるわけではありません。 ID を送信しますが、ID は必要ないため保存されません。また、イベント バス プロセスを開始する観点からは、このフィールドは必須です。

このフィールドが必須であるというイベント バスのルールを導入すると、BOB または開始イベント ハンドラーに追加の検証ルールを設定する必要があります。 検証はサービス全体に広がり始めますが、これはあまり便利ではありません。

もう XNUMX つの問題は、段階的な開発への誘惑です。 イベントに何かを加える必要があると言われていますが、考えてみれば、それは別のイベントであるべきだったのかもしれません。 しかし、私たちのスキームでは、別のイベントは別のトピックです。 上で説明したプロセス全体については、別のトピックで説明します。 開発者は、単に別のフィールドを JSON スキーマに追加して再生成したくなるでしょう。

返金の場合は半年後のイベント開催に至りました。 払い戻し更新と呼ばれる XNUMX つのメタイベントがあり、この更新が実際に何であるかを説明するタイプ フィールドがありました。 このため、このタイプでこのイベントを検証する方法を教えてくれるバリデーターを備えた「素晴らしい」スイッチがありました。

イベントのバージョン管理

Kafka でメッセージを検証するには、次を使用できます アブロ、しかし、すぐにそれに横たわり、Confluentを使用する必要がありました。 私たちの場合、バージョン管理には注意する必要があります。 モデルが「終了」しているため、レプリケーション ログからメッセージを再読み取りできるとは限りません。 基本的に、モデルが下位互換性を持つようにバージョンを構築することがわかります。たとえば、フィールドを一時的にオプションにします。 違いが強すぎる場合は、新しいトピックで書き始め、クライアントが古いトピックを読み終わったら転送します。

パーティションの読み取り順序の保証

Kafka 内のトピックはパーティションに分割されます。 これは、エンティティや取引所を設計している間はそれほど重要ではありませんが、それを使用および拡張する方法を決定する際には重要です。

通常の場合、Kafka で XNUMX つのトピックを作成します。 デフォルトでは XNUMX つのパーティションが使用され、このトピックのすべてのメッセージはそこに送られます。 したがって、消費者はこれらのメッセージを順番に読みます。 ここで、XNUMX 人の異なるコンシューマがメッセージを読めるようにシステムを拡張する必要があるとします。 たとえば、SMS を送信している場合、追加のパーティションを作成するように Kafka に指示できます。そうすると、Kafka はメッセージを XNUMX つの部分 (半分はここ、もう半分はここ) に分割し始めます。

カフカはそれらをどのように分割しますか? 各メッセージには本文 (JSON を保存します) とキーがあります。 このキーにハッシュ関数を付加すると、メッセージがどのパーティションに送信されるかが決まります。

払い戻しの場合、これは重要です。XNUMX つのパーティションを取る場合、並列コンシューマーが最初のイベントよりも前に XNUMX 番目のイベントを処理する可能性があり、問題が発生します。 ハッシュ関数により、同じキーを持つメッセージが同じパーティションに到達することが保証されます。

イベントとコマンドの比較

これも私たちが遭遇した問題です。 イベントとは特定のイベントです。たとえば、商品がキャンセルされた、返金が発生したなど、どこかで何かが起こった (something_happened) ことを言います。 誰かがこれらのイベントをリッスンすると、「商品がキャンセルされました」に従って返金エンティティが作成され、セットアップのどこかに「返金が発生しました」と書き込まれます。

しかし通常、イベントを企画するときは、無駄にイベントを書きたくはありません。誰かが読んでくれるという事実を頼りにします。 何かが起こった（アイテムがキャンセルされた、返金が返金された）のではなく、何かをすべきだということを書きたいという強い誘惑があります。 たとえば、商品は返品の準備ができています。

一方で、イベントがどのように使用されるかを示唆しています。 一方で、通常のイベント名とはあまり似ていません。 さらに、ここから do_something コマンドまではそれほど遠くありません。 ただし、誰かがこのイベントを読んでいるという保証はありません。 そしてそれを読めば、成功したことになります。 そして、それをうまく読み取れた場合、あなたは何かを行い、その何かが成功したことになります。 イベントが do_something になった瞬間にフィードバックが必要になり、それが問題になります。

RabbitMQ の非同期交換では、メッセージを読んで http にアクセスすると、少なくともメッセージが受信されたという応答が得られます。 Kafka に書き込むと、Kafka に書いたメッセージが存在しますが、それがどのように処理されたかについては何もわかりません。

したがって、私たちの場合は、応答イベントを導入し、非常に多くのイベントが送信された場合に、その後に同じ数の応答イベントが到着するように監視を設定する必要がありました。 これが起こらない場合は、何か問題が発生したようです。 たとえば、「item_ready_to_refund」イベントを送信した場合、払い戻しが作成され、お金がクライアントに返され、「money_refunded」イベントが送信されることが期待されます。 しかし、これは確実ではないため、監視が必要です。

ニュアンス

かなり明白な問題があります。トピックから順番に読んでいて、悪いメッセージがある場合、コンシューマーは落ちてしまい、先に進むことができなくなります。 必要です すべての消費者を止めてください、さらにオフセットをコミットして読み取りを続けます。

私たちはそれを知っていて、期待していましたが、それでもそれは起こりました。 そして、これは、イベントがイベントバスの観点からは有効であり、アプリケーションバリデータの観点からは有効でしたが、PostgreSQLの観点からは無効であったために起こりました。 UNSIGNED INT を備えた MySQL と、新たに作成されたシステムでは INT のみを備えた PostgreSQL がありました。 彼のサイズは少し小さくて、IDが合いませんでした。 Symfony は例外を除いて死亡しました。 もちろん、例外に依存していたため例外をキャッチし、このオフセットをコミットしようとしていましたが、メッセージの処理が失敗したため、その前に問題カウンターをインクリメントする必要がありました。 このプロジェクトのカウンターもデータベース内にあり、Symfony はすでにデータベースとの通信を閉じており、XNUMX 番目の例外によりオフセットをコミットする機会もなくプロセス全体が強制終了されました。

サービスはしばらく停止していましたが、幸いなことに、Kafka ではメッセージが残っているため、これはそれほど悪いことではありませんでした。 作業が再開されたら、読み終えることができます。 快適ですよ。

Kafka には、ツールを通じて任意のオフセットを設定する機能があります。 ただし、これを行うには、すべてのコンシューマーを停止する必要があります。この場合、コンシューマーが存在しない別のリリースを準備し、再デプロイします。 その後、Kafka でツールを使用してオフセットをシフトすると、メッセージが送信されます。

別のニュアンス - レプリケーション ログと rdkafka.so の比較 - 私たちのプロジェクトの詳細に関連しています。 私たちは PHP を使用します。PHP では、原則として、すべてのライブラリは rdkafka.so リポジトリを通じて Kafka と通信し、その後、ある種のラッパーが存在します。 おそらくこれらは私たち個人の困難ですが、すでに読んだ本の一部を単に再読することはそれほど簡単ではないことがわかりました。 一般的に、ソフトウェアに問題がありました。

パーティションの操作の詳細に戻ると、それはドキュメントに記載されています。 コンシューマ >= トピック パーティション。 しかし、私がこのことを知ったのは、思っていたよりもずっと後でした。 スケーリングして 20 つのコンシューマを持たせる場合は、少なくとも XNUMX つのパーティションが必要です。 つまり、XNUMX 件のメッセージが蓄積された XNUMX つのパーティションがあり、新しいパーティションを作成した場合、メッセージの数はすぐには均等になりません。 したがって、XNUMX つの並列コンシューマーを持つには、パーティションを処理する必要があります。

監視

それを監視する方法によって、既存のアプローチにどのような問題があるのか​​がさらに明確になると思います。

たとえば、最近ステータスが変更されたデータベース内の製品の数を計算し、それに応じてこれらの変更に基づいてイベントが発生するはずであり、この数値を監視システムに送信します。 次に、Kafka から XNUMX 番目の数値、実際に記録されたイベントの数を取得します。 明らかに、これら XNUMX つの数値の差は常にゼロでなければなりません。

さらに、プロデューサーがどのように動作しているか、イベントバスがメッセージを受信したかどうか、およびコンシューマがどのように動作しているかを監視する必要があります。 たとえば、以下のチャートでは、Refund Tool は好調ですが、BOB には明らかにいくつかの問題があります (青いピーク)。

消費者グループの遅れについてはすでに述べました。 大まかに言うと、これは未読メッセージの数です。 一般に、消費者は素早く作業するため、遅延は通常 0 ですが、場合によっては短期間のピークが発生することがあります。 Kafka はこれをそのまま実行できますが、一定の間隔を設定する必要があります。

プロジェクトがあります バローこれにより、Kafka についてさらに詳しい情報が得られます。 これは、コンシューマ グループ API を使用して、このグループの状況を示すだけです。 「OK」と「失敗」に加えて、警告も表示され、消費者が制作のペースに対応できていない、つまり書かれた内容を校正する時間がないことがわかります。 このシステムは非常にスマートで使いやすいです。

API の応答は次のようになります。 これはグループ bob-live-fifa、パーティションrefund.update.v1、ステータスOK、ラグ0 - 最後の最終オフセットなどです。

監視 updated_at SLA (スタック) すでに述べました。 たとえば、商品が返品可能なステータスに変更されました。 Cron をインストールすると、5 分以内にこのオブジェクトが返金されなかった場合 (支払いシステムを通じてすぐに返金されます)、間違いなく何か問題が発生したため、これは間違いなくサポート対象であると通知されます。 したがって、単純に Cron を使用してそのようなものを読み取り、それらが 0 より大きい場合にアラートを送信します。

要約すると、イベントを使用すると次のような場合に便利です。:

• 情報はいくつかのシステムで必要とされます。
• 処理の結果は重要ではありません。
• イベントがほとんどないか、小さなイベントがあります。

この記事には Kafka の非同期 API という非常に具体的なトピックがあるように見えますが、これに関連して一度に多くのことをお勧めしたいと思います。
まず、次 HighLoad ++ XNUMX月まで待つ必要があります。XNUMX月にはサンクトペテルブルクバージョンがあり、XNUMX月にはノボシビルスクでの高負荷について話します。
第二に、このレポートの著者であるセルゲイ・ザイカ氏は、ナレッジマネジメントに関する新しい会議のプログラム委員会のメンバーです。 ナレッジカンファレンス。 このカンファレンスは 26 月 XNUMX 日に開催される XNUMX 日限りのイベントですが、そのプログラムは非常に内容が濃いものです。
そしてXNUMX月になります PHP ロシア и RIT++ (DevOpsConf を含む) - そこでトピックを提案したり、自分の経験について話したり、詰め込まれたコーンについて文句を言ったりすることもできます。

出所： habr.com