突然の停止が発生した場合、Kafka によって書き込まれたデータが失われないようにするにはどうすればよいですか?

先週、「Kafka はどのようにして 1 秒あたり数百万件という超高速同時書き込みを実現するのか?」というタイトルの記事を共有しました。 Kafka に書き込まれたデータはディスクに書き込まれることは誰もが知っていると思います。この記事では、Kafka に書き込まれたデータが失われないようにする方法について説明します。

今のところはディスクへの書き込みの具体的なプロセスについては考えませんが、まずは Kafka のコアとなるアーキテクチャ原則を表す次の図を見てみましょう。

Kafka 分散ストレージ アーキテクチャ

ここで問題になるのは、毎日数十 TB のデータが生成される場合、そのすべてを 1 台のマシンのディスクに書き込むかどうかです。これは明らかに信頼できない！

したがって、ここではデータの分散ストレージを考慮する必要があります。カフカの具体的な状況と組み合わせて話してみましょう。

Kafka には、「トピック」と呼ばれる中核概念があります。このトピックはデータのコレクションと考えることができます。

たとえば、Kafka に書き込みたい Web サイトのユーザー行動データがある場合、「user_access_log_topic」というトピックを作成し、そこにすべてのユーザー行動データを書き込むことができます。

次に、電子商取引 Web サイトの注文データの追加、削除、変更レコードを Kafka に書き込む場合は、「order_tb_topic」というトピックを作成し、そこに注文テーブルのすべての変更レコードを書き込むことができます。

それでは、ユーザー行動のトピックを例に挙げてみましょう。毎日数十 TB のデータが書き込まれる場合、そのすべてを 1 台のマシンに置くことは信頼できると思いますか?

これは明らかにあまり信頼性が高くないので、Kafka にはパーティションと呼ばれる概念があります。これは、トピック データ セットを複数のデータ パーティションに分割するものであり、複数のデータ シャードと考えることができます。各パーティションは、データの一部を異なるマシンに保存できます。

この方法では、非常に大きなデータセットを複数のマシンに分散して保存することはできないでしょうか?下の写真を見て一緒に体験してみましょう。

Kafka 高可用性アーキテクチャ

しかし、このとき、別の問題に遭遇することになります。マシンがクラッシュした場合、このマシン上のパーティションで管理されているデータは失われませんか?

そのため、冗長性のために複数のコピーを作成する必要があります。各パーティションは別のマシンにコピーを保存できます。この方法では、マシンがクラッシュしても、パーティションのコピーが 1 つだけ失われます。

パーティションに複数のコピーがある場合、Kafka はパーティション コピーの 1 つをリーダーとして選出し、他のパーティション コピーはフォロワーになります。

リーダー パーティションのみが外部への読み取りおよび書き込み操作を提供し、フォロワー パーティションはリーダー パーティションからのデータを同期します。

リーダー パーティションがダウンすると、他のフォロワー パーティションが新しいリーダー パーティションとして選出され、外部に読み取りおよび書き込みサービスを提供します。これにより、高可用性アーキテクチャが実現されるのではないですか?

このプロセスを確認するには、下の図をご覧ください。

Kafka 書き込みデータ損失の問題

それでは、どのような状況で Kafka に書き込まれたデータが失われるのかを見てみましょう。実のところ、それは非常に簡単です。書き込まれたデータはパーティションのリーダーに書き込まれ、その後そのパーティションのフォロワーがリーダーからのデータを同期することは誰もが知っています。

しかし、データがリーダー パーティションに書き込まれたばかりでフォロワーにまだ同期されていない場合、リーダー パーティションが配置されているマシンが突然クラッシュするとどうなるでしょうか。

次の画像をご覧ください。

上図に示すように、この時点で Partition0 の Follower に同期されていないデータがあり、その後 Partition0 の Leader が配置されているマシンがクラッシュします。

この時点で、Partition0 のフォロワーが新しいリーダーとして選出され、外部にサービスを提供します。そうすると、ユーザーは書き込んだばかりのデータを読み取ることができなくなってしまうのでしょうか?

Partition0 の Follower 上の *** に同期されたデータがないためです。これにより、データ損失の問題が発生します。

Kafka の ISR メカニズムとは何ですか?

さて、この問題はそのままにして、解決方法については議論しないことにしましょう。まず、Kafka のコアメカニズムである ISR メカニズムを振り返ってみましょう。

簡単に言えば、このメカニズムは各パーティションの ISR リストを自動的に維持します。このリストには、リーダーと、リーダーと同期するフォロワーが含まれている必要があります。

つまり、リーダーのフォロワーがデータを同期させている限り、ISR リストに存在します。

ただし、フォロワーが自身の問題によりリーダーからのデータをタイムリーに同期できない場合、フォロワーは「同期していない」とみなされ、ISR リストから除外されます。

したがって、まず誰もがこの ISR が何であるかを理解する必要があります。簡単に言えば、Kafka はどのフォロワーがリーダーのデータ同期にタイムリーに対応しているかを自動的に維持および監視します。

Kafka に書き込まれたデータが失われないようにするにはどうすればよいですか?

したがって、Kafka に書き込まれたデータが失われないようにするには、次の点に注意する必要があります。

• リーダーのデータ同期を維持するには、各パーティションに ISR リスト内に少なくとも 1 つのフォロワーが必要です。
• データが書き込まれるたびに、書き込みが成功したと見なされるためには、少なくともパーティション リーダーが正常に書き込まれ、ISR 内の少なくとも 1 つのフォロワーも正常に書き込まれる必要があります。
• 上記の 2 つの条件が満たされない場合、書き込みは常に失敗し、実稼働システムは上記の 2 つの条件が満たされるまで再試行を続け、その後書き込みは成功したとみなされます。
• 上記の考え方に従って対応するパラメータを設定することによってのみ、Kafka に書き込まれたデータが失われないことを保証できます。

わかった！それでは、上記の要件を分析してみましょう。

***、少なくとも 1 人のフォロワーが ISR リストに含まれている必要があります。

それは必須です。リーダーにフォロワーがいない場合、またはフォロワーがリーダーのデータを時間内に同期できない場合、この問題は確実に進行できなくなります。

2 番目に、データが書き込まれるたびに、リーダーが正常に書き込みを行うことに加えて、ISR 内の少なくとも 1 つのフォロワーも正常に書き込みを行う必要があります。

下の図に示すように、この要件により、データが書き込まれるたびに、リーダーとフォロワーの両方が正常に書き込みを行って初めて、書き込みが成功したとみなされます。これにより、1 つのデータに 2 つ以上のコピーが存在することが保証されます。

このとき、リーダーがダウンした場合はフォロワーに切り替えることができます。するとフォロワーには新しく書き込まれたデータが格納されるので、データが失われることはありません。

上の図に示すように、リーダーにフォロワーがいない場合、またはリーダーが書き込まれたばかりの場合、リーダーはすぐにクラッシュし、フォロワーと同期する時間がありません。

この場合、書き込みは失敗し、Kafka が正常に戻り、上記の条件を満たすまでプロデューサーが再試行を続け、その後書き込みを続行します。この方法では、Kafka に書き込まれたデータが失われることはありません。

要約する

***まとめると、Kafka のデータ損失の問題は、実際にはあらゆる側面に関係しています。

たとえば、コンシューマー側の問題を含むプロダクション側のキャッシュの問題や、Kafka 自体の基盤となるアルゴリズムやメカニズムによっても、データ損失が発生する可能性があります。

ただし、データの書き込み時に発生する大きな問題は、リーダーが切り替わるとデータが失われる可能性があることです。したがって、この記事では、実稼働環境におけるこの問題の解決策についてのみ説明します。