Rails + Kafkaでのサービス指向アーキテクチャの構築

こんにちは、Habr！ この投稿は、 RailsConf 2018でのStella Cottonのパフォーマンスのテキスト適応であり、 Stella Cottonによる記事「RailsとKafkaを使用したサービス指向アーキテクチャの構築」の翻訳です。

最近、モノリシックアーキテクチャからマイクロサービスへのプロジェクトの移行が明確に見られます。 このガイドでは、Kafkaの基本と、イベント駆動型アプローチがRailsアプリケーションを改善する方法を学習します。 また、イベント指向のアプローチで機能するサービスの監視とスケーラビリティの問題についても説明します。

カフカとは何ですか？

ユーザーがどのようにプラットフォームにアクセスしたのか、どのページにアクセスしたのか、どのボタンをクリックしたのかなどの情報が欲しいと思います。 本当に人気のあるアプリケーションは、数十億のイベントを生成し、分析サービスに大量のデータを送信する可能性があります。これは、アプリケーションにとって深刻な課題になる可能性があります。

原則として、Webアプリケーションの不可欠な部分には、いわゆるリアルタイムデータフローが必要です。 Kafkaは、 プロデューサー （イベントを生成するユーザー ）とコンシューマー （これらのイベントを受信するユーザー ）間のフォールトトレラントな接続を提供します。 1つのアプリケーションに複数のプロデューサーとコンシューマーがある場合もあります。 Kafkaでは、すべてのイベントが一定時間存在するため、複数の消費者が同じイベントを何度も読むことができます。 Kafkaクラスターには、Kafkaインスタンスであるブローカーがいくつか含まれています。



Kafkaの重要な機能は、イベント処理の高速性です。 AMQPなどの従来のキューシステムには、各コンシューマの処理済みイベントを監視するインフラストラクチャがあります。 消費者の数がまともなレベルまで増加した場合、システムは増加する状態を監視する必要があるため、負荷にほとんど対処し始めません。 また、コンシューマとイベント処理システムの一貫性には大きな問題があります。 たとえば、システムで処理されたメッセージをすぐに送信済みとしてマークする価値はありますか？ そして、消費者がメッセージを受信せずにもう一方の端に落ちたら？

Kafkaにはフェイルセーフアーキテクチャもあります。 システムは1つ以上のサーバー上でクラスターとして実行され、新しいマシンを追加することで水平方向に拡張できます。 すべてのデータはディスクに書き込まれ、複数のブローカーにコピーされます。 スケーラビリティの可能性を理解するために、Netflix、LinkedIn、Microsoftなどの企業を見てみる価値があります。 それらはすべて、Kafkaクラスターを介して1日に数兆のメッセージを送信します！

RailsでのKafkaのセットアップ

Herokuは、あらゆる環境で使用できるKafkaクラスターアドオンを提供します。 rubyアプリケーションの場合、 ruby-kafka gemの使用をお勧めします。 最小限の実装は次のようになります。

# config/initializers/kafka_producer.rb require "kafka" # Configure the Kafka client with the broker hosts and the Rails # logger. $kafka = Kafka.new(["kafka1:9092", "kafka2:9092"], logger: Rails.logger) # Set up an asynchronous producer that delivers its buffered messages # every ten seconds: $kafka_producer = $kafka.async_producer( delivery_interval: 10, ) # Make sure to shut down the producer when exiting. at_exit { $kafka_producer.shutdown } 

構成を構成したら、gemを使用してメッセージを送信できます。 イベントの非同期送信のおかげで、どこからでもメッセージを送信できます。

 class OrdersController < ApplicationController def create @comment = Order.create!(params) $kafka_producer.produce(order.to_json, topic: "user_event", partition_key: user.id) end end 

以下でシリアル化形式について説明しますが、ここでは、古き良きJSONを使用します。 topic引数は、Kafkaがこのイベントを書き込むログを指します。 トピックはさまざまなセクションに分散されているため、特定のトピックのデータをさまざまなブローカーに分割して、スケーラビリティと信頼性を向上させることができます。 また、トピックごとに2つ以上のセクションを用意することをお勧めします。セクションのいずれかが該当する場合、イベントは記録され、処理されます。 Kafkaは、トピック全体ではなく、セクション内のキューの順序でイベントが配信されるようにします。 イベントの順序が重要な場合、partition_keyを送信すると、特定のタイプのすべてのイベントが同じパーティションに保存されます。

あなたのサービスのためのカフカ

Kafkaを便利なツールにする機能の一部は、サービス間のフェールオーバーRPCにもなります。 eコマースアプリケーションの例を見てみましょう。

 def create_order create_order_record charge_credit_card # call to Payments Service send_confirmation_email # call to Email Service end 

ユーザーが注文すると、 create_order関数がcreate_orderます。 これにより、システムで注文が作成され、カードからお金が差し引かれ、確認のメールが送信されます。 ご覧のとおり、最後の2つのステップは別々のサービスで実行されます。



このアプローチの問題の1つは、階層内の上位サービスがダウンストリームサービスの可用性を監視する責任があることです。 手紙を送るサービスが悪い日であることが判明した場合、上位のサービスはそれについて知る必要があります。 また、送信サービスが利用できない場合は、特定のアクションセットを繰り返す必要があります。 この状況でカフカはどのように支援できますか？

例：



このイベント駆動型のアプローチでは、優れたサービスが注文が作成されたというイベントをKafkaで記録できます。 いわゆる少なくとも1回のアプローチにより、イベントは少なくとも1回Kafkaに記録され、下流の消費者が閲覧できるようになります。 メッセージ送信サービスが嘘をついている場合、イベントは、コンシューマーが立ち上がってそれを読み取るまでディスク上で待機します。

RPC指向のアーキテクチャのもう1つの問題は、急成長しているシステムにあります。新しいダウンストリームサービスを追加すると、アップストリームに変更が必要になります。 たとえば、注文を作成した後にもう1ステップ追加したいとします。 イベント駆動型の世界では、新しいタイプのイベントを処理する別のコンシューマーを追加する必要があります。

イベントをサービス指向アーキテクチャに統合する

Martin Fowlerによる「イベント駆動型 」 とはどういう意味ですかというタイトルの投稿では、イベント駆動型アプリケーションに関する混乱について説明しています。 開発者がそのようなシステムについて議論するとき、彼らは実際には膨大な数の異なるアプリケーションについて話しています。 そのようなシステムの性質を一般的に理解するために、ファウラーはいくつかのアーキテクチャパターンを定義しました。

これらのパターンが何であるかを見てみましょう。 もっと知りたい場合は、GOTO Chicago 2017で彼のレポートを読むことをお勧めします。

イベント通知

最初のFowlerパターンはEvent Notificationと呼ばれます。 このシナリオでは、プロデューサーサービスは、最小限の情報でイベントをコンシューマーに通知します。

 { "event": "order_created", "published_at": "2016-03-15T16:35:04Z" } 

消費者がイベントについてより多くの情報を必要とする場合、消費者は生産者にリクエストを行い、より多くのデータを取得します。

イベントを運ぶ状態転送

2番目のテンプレートは、 Event-Carried State Transferと呼ばれます。 このシナリオでは、プロデューサーはイベントに関する追加情報を提供し、コンシューマーは追加の呼び出しを行わずにこのデータのコピーを保存できます。

 { "event": "order_created", "order": { "order_id": 98765, "size": "medium", "color": "blue" }, "published_at": "2016-03-15T16:35:04Z" } 

イベントソース

Fowlerは、3番目のテンプレートをEvent-Sourcedと呼び、よりアーキテクチャ的です。 テンプレートのリリースには、サービス間の通信だけでなく、イベントのプレゼンテーションの保存も含まれます。 これにより、データベースを失っても、保存されたイベントストリームを実行するだけでアプリケーションの状態を復元できます。 つまり、各イベントは、特定の瞬間にアプリケーションの特定の状態を保存します。

このアプローチの大きな問題は、アプリケーションコードが常に変更され、プロデューサーが提供するデータの形式または量が変更される可能性があることです。 これにより、アプリケーションの状態の復元が問題になります。

コマンドクエリの責任分離

最後のテンプレートはCommand Query Responsibility SegregationまたはCQRSです。 アイデアは、オブジェクトに適用するアクション、たとえば、作成、読み取り、更新を異なるドメインに分割することです。 つまり、1つのサービスが作成を担当し、別のサービスが更新などを担当する必要があります。 オブジェクト指向システムでは、すべてが1つのサービスに格納されることがよくあります。



データベースに書き込むサービスは、イベントのストリームを読み取り、コマンドを処理します。 ただし、要求は読み取り専用データベースでのみ発生します。 読み取りおよび書き込みロジックを2つの異なるサービスに分割すると、複雑さが増しますが、これらのシステムのパフォーマンスを個別に最適化できます。

問題

Kafkaをサービス指向アプリケーションに統合するときに発生する可能性のあるいくつかの問題について話しましょう。

最初の問題は、遅い消費者のものかもしれません。 イベント指向システムでは、サービスは、優れたサービスからイベントを受け取ったときに即座に処理できる必要があります。 そうしないと、問題やタイムアウトに関するアラートが表示されずに単純にハングします。 タイムアウトを定義できる唯一の場所は、Kafkaブローカーとのソケット接続です。 サービスがイベントを十分に迅速に処理しない場合、接続はタイムアウトによって中断される可能性がありますが、そのようなソケットの作成には費用がかかるため、サービスの復元にはさらに時間がかかります。

コンシューマが遅い場合、イベント処理の速度をどのように上げることができますか？ Kafkaでは、グループ内の消費者の数を増やすことができるため、より多くのイベントを並行して処理できます。 ただし、1つのサービスに少なくとも2人の消費者が必要です。1つが落ちた場合、破損したセクションを再割り当てできます。

また、イベント処理の速度を監視するためのメトリックとアラートを用意することも非常に重要です。 ruby- kafkaはActiveSupportアラートと連携できます。また、StatsDおよびDatadogモジュールもあり、これらはデフォルトで有効になっています。 さらに、gemは、推奨される監視メトリックのリストを提供します。

Kafkaを使用してシステムを構築するもう1つの重要な側面は、障害を処理する能力を持つ消費者の設計です。 Kafkaは、少なくとも1回イベントを送信することが保証されています。 メッセージがまったく送信されなかった場合を除外しました。 ただし、消費者が繰り返し発生するイベントを処理する準備をすることが重要です。 これを行う1つの方法は、常にUPSERTを使用してデータベースに新しいレコードを追加することです。 同じ属性を持つレコードがすでに存在する場合、呼び出しは基本的に非アクティブになります。 さらに、各イベントに一意の識別子を追加し、以前に処理されたイベントを単にスキップすることができます。

データ形式

Kafkaを使用する際の驚きの1つは、データ形式に対する単純な態度です。 バイト単位で何でも送信でき、検証なしでデータが消費者に送信されます。 一方で、柔軟性を提供し、データ形式を気にしないようにします。 一方、プロデューサーが送信されるデータを変更することを決定した場合、一部のコンシューマーが最終的に破損する可能性があります。

イベント指向のアーキテクチャを構築する前に、データ形式を選択し、スキームの登録と開発が今後どのように役立つかを分析します。

もちろん、使用が推奨される形式の1つはJSONです。 この形式は人間が読める形式であり、既知のすべてのプログラミング言語でサポートされています。 しかし、落とし穴があります。 たとえば、JSONの最終データのサイズは恐ろしく大きくなる可能性があります。 この形式はキーと値のペアを保存するために必要です。これは十分な柔軟性がありますが、データは各イベントで複製されます。 フィールドの名前を変更する必要がある場合、あるキーを別のキーにオーバーレイする組み込みサポートがないため、スキーマの変更も難しいタスクです。

Kafkaを作成したチームは、シリアル化システムとしてAvroに助言します。 データはバイナリ形式で送信され、これは最も人間が読める形式ではありませんが、内部には回線のより信頼できるサポートがあります。 Avroの最後のエンティティには、スキーマとデータの両方が含まれます。 Avroは、数値などの単純型と日付、配列などの複雑な型の両方もサポートしています。さらに、スキーム内にドキュメントを含めることができます。これにより、システム内の特定のフィールドの目的を理解でき、スキームを操作するためのその他の多くの組み込みツールが含まれています。

avro-builderは、スキーマを作成するためのルビーのようなDSLを提供するSalsifyによって作成されたgemです。 この記事で Avroの詳細を読むことができます。

追加情報

Kafkaをホストする方法や、Herokuでの使用方法に関心がある場合は、興味のあるレポートがいくつかあります。

DataEngConf SF '17でジェフチャオが「 50,000パーティションを超える：Herokuが大規模にKafkaの限界を操作およびプッシュする方法 」

Dreamforce '16でのPavel Pravosud「 Dogfooding Kafka：Herokuのリアルタイムプラットフォームイベントストリームの構築方法 」カンファレンス

素敵な景色を！