Elasticsearch クラスター 200 TB+

多くの人が Elasticsearch に苦労しています。しかし、「特に大量の」ログを保存するためにそれを使用したい場合はどうなるでしょうか?また、複数のデータセンターのいずれかで障害が発生しても、痛みは感じられないのでしょうか?どのようなアーキテクチャを作るべきか、そしてどんな落とし穴に遭遇するでしょうか?

私たち Odnoklassniki は、ログ管理の問題を解決するために elasticsearch を使用することに決め、現在、アーキテクチャと落とし穴の両方についての経験を Habr と共有しています。

私は Pyotr Zaitsev です。Odnoklassniki でシステム管理者として働いています。その前は、私は管理者でもあり、Manticore Search、Sphinx Search、Elasticsearch を担当していました。おそらく、別の ...検索が表示されたら、私もおそらくそれを使用するでしょう。私はまた、自主的に多くのオープンソース プロジェクトに参加しています。

オドノクラスニキに来たとき、私は面接で無謀にも Elasticsearch を使えますと言いました。コツを掴んで簡単な作業を終えた後、当時存在していたログ管理システムを刷新するという大きな仕事が与えられました。

必要条件

システム要件は次のように定式化されました。

• Graylog がフロントエンドとして使用される予定でした。同社にはすでにこの製品の使用経験があり、プログラマーやテスターはそれを知っており、彼らにとって馴染みがあり便利でした。
• データ量: 平均で 50 秒あたり 80 ～ 2 メッセージですが、何かが壊れた場合、トラフィックは何にも制限されず、3 秒あたり XNUMX ～ XNUMX 万行になる可能性があります
• 検索クエリの処理速度の要件についてお客様と話し合った結果、このようなシステムの使用の典型的なパターンは次のとおりであることがわかりました。人々は過去 2 日間のアプリケーションのログを探しており、1 日以上待ちたくないのです。 2 番目は、定式化されたクエリの結果です。
• 管理者は、システムがどのように機能するかを深く調べる必要がなく、必要に応じてシステムを簡単に拡張できると主張しました。
• したがって、これらのシステムが定期的に必要とする唯一のメンテナンス作業は、一部のハードウェアを交換することです。
• さらに、Odnoklassniki には優れた技術的伝統があります。つまり、私たちが立ち上げるサービスはすべて、データセンターの障害 (突然、計画外、いつでも絶対に) に耐えなければなりません。

このプロジェクトの実施における最後の要件が最も費用がかかりましたが、これについては後ほど詳しく説明します。

水曜日

私たちは 4 つのデータセンターで作業していますが、Elasticsearch データ ノードは (技術的以外のさまざまな理由により) 3 か所にしか配置できません。

これら 18 つのデータ センターには、ハードウェア、コンテナ、仮想マシンなど、約 XNUMX の異なるログ ソースが含まれています。

重要な機能: クラスターはコンテナーで開始されます ポッドマン 物理マシン上ではなく、 独自のクラウド製品 ワンクラウド。コンテナーには 2Ghz v2.0 と同様に 4 つのコアが保証されており、アイドル状態の場合は残りのコアをリサイクルする可能性があります。

言い換えれば：

トポロジー

最初に私が見たソリューションの一般的な形式は次のとおりです。

• 3 ～ 4 の VIP が Graylog ドメインの A レコードの背後にあり、これがログの送信先アドレスです。
• 各 VIP は LVS バランサーです。
• その後、ログは Graylog バッテリーに送られ、データの一部は GELF 形式、一部は syslog 形式になります。
• 次に、これらすべてが大きなバッチで一連の Elasticsearch コーディネーターに書き込まれます。
• そして、次に、書き込みおよび読み取りリクエストを関連するデータ ノードに送信します。

用語

おそらく誰もがこの用語を詳しく理解しているわけではないので、少し詳しく説明したいと思います。

Elasticsearch には、マスター、コーディネーター、データ ノードなど、いくつかのタイプのノードがあります。異なるログ変換と異なるクラスター間の通信用に他に 2 つのタイプがありますが、リストされているもののみを使用しました。

Master
クラスター内に存在するすべてのノードに ping を送信し、最新のクラスター マップを維持してノード間で配布し、イベント ロジックを処理し、クラスター全体のさまざまな種類のハウスキーピングを実行します。

コー​​ディネーター
単一のタスクを実行します。つまり、クライアントからの読み取りまたは書き込みリクエストを受け入れ、このトラフィックをルーティングします。書き込みリクエストがある場合、ほとんどの場合、関連するインデックスのどのシャードに書き込みリクエストを配置するかをマスターに問い合わせ、リクエストをさらにリダイレクトします。

データノード
データを保存し、外部から到着する検索クエリを実行し、その上にあるシャードに対して操作を実行します。

グレイログ
これは、ELK スタックにおける Kibana と Logstash の融合のようなものです。 Graylog は、UI とログ処理パイプラインの両方を組み合わせています。 Graylog は内部で Kafka と Zookeeper を実行し、クラスターとして Graylog への接続を提供します。 Graylog は、Elasticsearch が利用できない場合にログ (Kafka) をキャッシュし、失敗した読み取りおよび書き込みリクエストを繰り返し、指定されたルールに従ってログをグループ化してマークすることができます。 Logstash と同様に、Graylog には、Elasticsearch に書き込む前に行を変更する機能があります。

さらに、Graylog にはサービス ディスカバリが組み込まれており、利用可能な 1 つの Elasticsearch ノードに基づいてクラスタ マップ全体を取得し、特定のタグでフィルタリングできるため、リクエストを特定のコンテナに送信できるようになります。

視覚的には次のようになります。

これは特定のインスタンスのスクリーンショットです。ここでは、検索クエリに基づいてヒストグラムを作成し、関連する行を表示します。

索引

システム アーキテクチャに戻って、すべてが正しく機能するようにインデックス モデルを構築した方法について詳しく説明したいと思います。

上の図では、これは最下位レベルの Elasticsearch データ ノードです。

インデックスは、Elasticsearch シャードで構成される大きな仮想エンティティです。それぞれのシャード自体は、Lucene インデックスにすぎません。そして、各 Lucene インデックスは 1 つ以上のセグメントで構成されます。

設計時に、大量のデータの読み取り速度の要件を満たすには、このデータをデータ ノード全体に均等に「分散」する必要があると考えました。

その結果、インデックスごとのシャード数 (レプリカを含む) はデータ ノードの数と厳密に等しくなければならないという事実が生じました。まず、レプリケーション係数が 2 になるようにするためです (つまり、クラスターの半分を失う可能性があります)。次に、クラスターの少なくとも半分で読み取りおよび書き込みリクエストを処理するためです。

まず保管期間を 30 日間と決定しました。

シャードの分布は次のようにグラフで表すことができます。

濃い灰色の長方形全体がインデックスです。その中の左側の赤い四角はプライマリ シャードであり、インデックスの最初にあります。そして青い四角はレプリカの破片です。これらは異なるデータセンターにあります。

別のシャードを追加すると、3 番目のデータセンターに移動します。そして最終的には、データの一貫性を失わずに DC を失うことができる次の構造が得られます。

インデックスのローテーション、つまり新しいインデックスを作成して最も古いインデックスを削除するため、これを 48 時間にしました (インデックスの使用パターンに従って、最後の 48 時間が最も頻繁に検索されます)。

このインデックスのローテーション間隔は、次の理由によるものです。

検索リクエストが特定のデータ ノードに到着した場合、パフォーマンスの観点から見ると、1 つのシャードをクエリする場合、そのサイズがノードのヒップのサイズに匹敵する場合、より収益性が高くなります。これにより、インデックスの「ホット」部分をヒープに保持し、迅速にアクセスできるようになります。 「ホットな部分」が多くなると、インデックス検索の速度が低下します。

ノードが 1 つのシャードで検索クエリの実行を開始すると、物理マシンのハイパースレッディング コアの数と同じ数のスレッドが割り当てられます。検索クエリが多数のシャードに影響を与える場合、スレッドの数も比例して増加します。これは検索速度に悪影響を及ぼし、新しいデータのインデックス作成にも悪影響を及ぼします。

必要な検索遅延を提供するために、SSD を使用することにしました。リクエストを迅速に処理するには、これらのコンテナをホストするマシンに少なくとも 56 コアが必要でした。 56 という数字は、Elasticsearch が動作中に生成するスレッドの数を決定する条件付きで十分な値として選択されました。 Elasitcsearch では、多くのスレッド プール パラメーターが利用可能なコアの数に直接依存し、その結果、「コアが減ってノードが増える」という原則に従って、クラスター内で必要なノードの数に直接影響します。

その結果、平均してシャードの重さは約 20 ギガバイトで、インデックスごとに 1 個のシャードがあることがわかりました。したがって、360 時間ごとに 48 回ローテーションすると、15 個になります。各インデックスには 2 日分のデータが含まれています。

データ書き込み・読み出し回路

このシステムにデータがどのように記録されるかを見てみましょう。

Graylog からコーディネーターに何らかのリクエストが届いたとします。たとえば、2 ～ 3 行のインデックスを作成したいとします。

Graylog からリクエストを受け取ったコーディネーターは、マスターに次のように質問します。「インデックス作成リクエストでは、インデックスを具体的に指定しましたが、それをどのシャードに書き込むかが指定されていませんでした。」

マスターは「この情報をシャード番号 71 に書き込んでください」と応答し、その後、プライマリ シャード番号 71 が配置されている関連データ ノードに直接送信されます。

その後、トランザクション ログは別のデータ センターにあるレプリカ シャードに複製されます。

Graylog からコーディネーターに検索リクエストが届きます。コーディネーターはインデックスに従ってリクエストをリダイレクトしますが、Elasticsearch はラウンドロビン原則を使用してプライマリ シャードとレプリカ シャードの間でリクエストを分散します。

180 個のノードの応答は不均等であり、ノードが応答している間、コーディネーターは、より高速なデータ ノードによってすでに「吐き出された」情報を蓄積しています。この後、すべての情報が到着するか、リクエストがタイムアウトに達すると、すべてをクライアントに直接渡します。

このシステム全体は、先頭にワイルドカードが含まれるクエリを除き、過去 48 時間の検索クエリを平均して 300 ～ 400 ミリ秒で処理します。

Elasticsearch を使用した花: Java セットアップ

すべてを当初の希望通りに動作させるために、クラスター内のさまざまなものをデバッグするのに非常に長い時間を費やしました。

発見された問題の最初の部分は、Elasticsearch で Java がデフォルトで事前設定される方法に関連していました。

最初の問題
Lucene レベルで、バックグラウンド ジョブの実行中に Lucene セグメントのマージがエラーで失敗するという非常に多くのレポートが確認されています。同時に、これが OutOfMemoryError エラーであることはログで明らかでした。遠隔測定により股関節が自由であることが分かりましたが、なぜこの手術が失敗したのかは不明でした。

Lucene インデックスのマージは股関節の外側で発生することが判明しました。また、コンテナーは、消費されるリソースに関して非常に厳密に制限されています。これらのリソースに収まるのはヒープのみであり (heap.size 値は RAM とほぼ同じです)、何らかの理由で制限の前に残っていた ~500MB に収まらなかった場合、一部のオフヒープ操作はメモリ割り当てエラーでクラッシュしました。

修正は非常に簡単でした。コンテナで使用できる RAM の量が増加しました。その後、そのような問題があったことさえ忘れていました。

問題 XNUMX
クラスターの起動から 4 ～ 5 日後、データ ノードが定期的にクラスターから外れ、10 ～ 20 秒後にクラスターに入り始めていることに気付きました。

私たちがそれを理解し始めたところ、Elasticsearch のこのオフヒープ メモリはまったく制御されていないことが判明しました。コンテナにさらに多くのメモリを与えると、ダイレクト バッファ プールにさまざまな情報を入れることができ、Elasticsearch から明示的な GC が起動された後でのみクリアされました。

場合によっては、この操作には非常に長い時間がかかり、その間にクラスターはこのノードをすでに終了しているとマークすることができました。この問題はよく説明されています ここに.

解決策は次のとおりです。これらの操作にヒープ外のメモリの大部分を使用する Java の機能を制限しました。これを 16 ギガバイト (-XX:MaxDirectMemorySize=16g) に制限し、明示的な GC がより頻繁に呼び出され、より高速に処理されるようにしました。これにより、クラスターが不安定になることはなくなりました。

問題 3
「予期せぬ瞬間にノードがクラスターから離脱する」という問題は解決したと考えているなら、それは間違いです。

インデックスを使用した作業を構成するときに、mmapfs を選択しました。 検索時間を短縮する 優れたセグメンテーションを備えた新鮮なシャード上で。 mmapfs を使用する場合、ファイルは RAM にマップされ、マップされたファイルを操作するため、これはかなりの間違いでした。このため、GC がアプリケーション内のスレッドを停止しようとすると、非常に長い間セーフポイントに移動し、そこに向かう途中で、アプリケーションが生存しているかどうかに関するマスターのリクエストへの応答を停止することがわかります。 。したがって、マスターはノードがクラスター内に存在しなくなったと認識します。この後、5 ～ 10 秒後にガベージ コレクターが動作し、ノードが動作し、再びクラスターに入り、シャードの初期化を開始します。それはすべて「当然の作品」のように感じられ、深刻なものには適していませんでした。

この動作を解決するために、最初に標準の niofs に切り替え、次に Elastic の第 5 バージョンから第 6 バージョンに移行するときに、hybridfs を試しましたが、この問題は再現されませんでした。ストレージの種類について詳しく読むことができます ここで.

問題 4
次に、別の非常に興味深い問題があり、記録的な速さで処理されました。パターンがまったく理解できなかったので、2〜3か月かけて捕まえました。

時々、コーディネーターがフル GC に行き、通常は昼食後、そこから戻ってこなかったことがあります。同時に、GC 遅延をログに記録すると、次のように見えました。すべてが順調に進んでいたのに、突然すべてが非常に悪くなりました。

最初、私たちは、コーディネーターを作業モードから外す何らかのリクエストを開始する邪悪なユーザーがいると考えました。私たちは、何が起こっているのかを解明するために、非常に長い間リクエストを記録しました。

その結果、ユーザーが巨大なリクエストを開始し、それが特定の Elasticsearch コーディネーターに到達した瞬間に、一部のノードが他のノードよりも応答に時間がかかることが判明しました。

そして、コーディネーターはすべてのノードからの応答を待っている間に、すでに応答したノードから送信された結果を蓄積します。 GC の場合、これはヒープの使用パターンが非常に急速に変化することを意味します。そして、私たちが使用した GC はこのタスクに対応できませんでした。

この状況でクラスターの動作を変更するために見つかった唯一の修正は、JDK13 への移行と Shenandoah ガベージ コレクターの使用です。これで問題は解決し、コーディネーターの落下は止まりました。

ここで Java の問題は終わり、帯域幅の問題が始まりました。

Elasticsearch を使用した「ベリー」: スループット

スループットに問題があるため、クラスターは安定して動作しますが、インデックス付きドキュメント数のピーク時や操作中にパフォーマンスが不十分になります。

最初に発生した症状は、本番環境での「爆発」中に、非常に多くのログが突然生成され、インデックス作成エラー es_rejected_execution が Graylog で頻繁に点滅し始めることです。

これは、Elasticsearch がインデックス作成リクエストを処理してディスク上のシャードに情報をアップロードできるようになるまで、200 つのデータ ノード上の thread_pool.write.queue がデフォルトで XNUMX リクエストしかキャッシュできないという事実によるものです。そして、 Elasticsearch ドキュメント このパラメータについてはほとんど語られていません。スレッドの最大数とデフォルトのサイズのみが示されています。

もちろん、この値を変更して次のことがわかりました。具体的には、この設定では、最大 300 のリクエストが非常によくキャッシュされ、値が高くなると、再びフル GC に突入するという事実が発生します。

さらに、これらは 3 つのリクエスト内で到着するメッセージのバッチであるため、頻繁に小さなバッチで書き込むのではなく、大きなバッチで書き込むか、バッチがまだ完了していない場合は XNUMX 秒に XNUMX 回書き込むように、Graylog を調整する必要がありました。この場合、Elasticsearch に書き込んだ情報は XNUMX 秒ではなく XNUMX 秒で利用可能になることがわかります (これは私たちにとって非常に適しています)。情報の山が減ります。

これは、どこかで何かがクラッシュし、それについて猛烈に報告するような瞬間に、完全にスパムメールが送信された Elastic や、しばらくするとバッファの詰まりにより動作不能になる Graylog ノードが発生しないようにするために特に重要です。

さらに、本番環境で同様の爆発が発生したとき、プログラマーやテスターから苦情を受けました。ログが本当に必要なときに、ログが提供されるのが非常に遅かったのです。

彼らはそれを理解し始めました。一方で、検索クエリとインデックス作成クエリの両方が基本的に同じ物理マシン上で処理され、何らかの形で一定のドローダウンが発生することは明らかでした。

しかし、Elasticsearch の 6 番目のバージョンでは、ランダムなラウンドロビン原則 (インデックス付けを実行し、プライマリ データを保持するコンテナ) に従わずに、関連するデータ ノード間でクエリを分散できるアルゴリズムが登場したという事実により、これは部分的に回避される可能性があります。 -シャードは非常にビジーである可能性があり、すぐに応答する方法はありません)、このリクエストをレプリカシャードを備えた負荷の少ないコンテナーに転送すると、応答がはるかに速くなります。つまり、use_adaptive_replica_selection: true に到達しました。

読書の絵は次のようになります。

このアルゴリズムへの移行により、大量のログを書き込む際のクエリ時間を大幅に短縮できるようになりました。

最後に、主な問題は、データセンターの苦痛を伴わない撤去でした。

1 つの DC との接続が失われた直後にクラスターに求めていたものは次のとおりです。

• 障害が発生したデータセンターに現在のマスターがある場合、それが再選択され、ロールとして別の DC の別のノードに移動されます。
• マスターは、アクセスできないすべてのノードをクラスターから迅速に削除します。
• 残りのシャードに基づいて、彼は理解するでしょう。失われたデータ センターにはこれこれのプライマリ シャードがあり、残りのデータ センターで補完的なレプリカ シャードをすぐに昇格させ、データのインデックス作成を続行します。
• この結果、クラスターの書き込みおよび読み取りのスループットは徐々に低下しますが、一般的には、ゆっくりではありますが、すべてが安定して動作します。

結局のところ、私たちは次のようなものを望んでいたのです。

そして、次のものが得られました。

それはどうしたのですか？

データセンターがダウンしたとき、マスターがボトルネックになりました。

なぜですか？

実際、マスターには、クラスター内の特定のタスクとイベントを分散する役割を担う TaskBatcher があります。ノードの終了、レプリカからプライマリへのシャードの昇格、どこかにシャードを作成するタスク - これらすべては最初に TaskBatcher に送られ、そこで 1 つのスレッドで順次処理されます。

1 つのデータセンターが撤退した際、生き残ったデータセンターのすべてのデータ ノードがマスターに「これこれのシャードとこれこれのデータ ノードが失われました」と通知することが自分たちの義務であると考えていたことが判明しました。

同時に、生き残ったデータ ノードはこれらすべての情報を現在のマスターに送信し、マスターがそれを受け入れたという確認を待機しようとしました。マスターは答えるよりも早くタスクを受け取ったので、彼らはこれを待ちませんでした。ノードは繰り返しのリクエストでタイムアウトになり、この時点のマスターはリクエストに応答しようともせず、リクエストを優先度によって分類する作業に完全に没頭していました。

最終的な形式では、データ ノードがマスターにフル GC に至るまでスパム送信を行っていたことが判明しました。その後、マスターの役割が次のノードに移動しましたが、まったく同じことがそのノードでも発生し、その結果クラスターが完全に崩壊しました。

測定を行ったところ、この問題が修正されたバージョン 6.4.0 より前では、クラスターを完全にシャットダウンするには、10 個のデータ ノードのうち 360 個だけを同時に出力するだけで十分でした。

次のような感じでした。

このひどいバグが修正されたバージョン 6.4.0 以降、データ ノードはマスターを強制終了しなくなりました。しかし、それで彼は「賢くなった」わけではありません。つまり、2、3、または 10 (XNUMX 以外の任意の数) のデータ ノードを出力すると、マスターはノード A が離脱したという最初のメッセージを受け取り、ノード B、ノード C、ノード D にそのことを伝えようとします。

そして現時点では、これに対処するには、誰かに何かを伝えようとする試みに約 20 ～ 30 秒のタイムアウトを設定し、データセンターがクラスターから外に移動する速度を制御することによってのみ対処できます。

原則として、これはプロジェクトの一部として最終製品に最初に提示された要件に適合しますが、「純粋な科学」の観点から見ると、これはバグです。ちなみに、これは開発者によってバージョン 7.2 で正常に修正されました。

さらに、特定のデータ ノードが停止したとき、そのノードにこれこれのプライマリ シャードがあることをクラスター全体に伝えるよりも、その終了に関する情報を広めることの方が重要であることがわかりました（別のデータのレプリカ シャードを昇格させるため）プライマリの中心、および情報にそれらを書き込むことができます）。

したがって、すべてがすでに停止している場合、解放されたデータ ノードはすぐには古いものとしてマークされません。したがって、解放されたデータ ノードへのすべての ping がタイムアウトになるまで待つことを余儀なくされ、その後になって初めて、クラスターがそこかしこで情報の記録を続ける必要があることを通知し始めます。これについて詳しく読むことができます ここで.

その結果、今日のデータセンターの撤退作業には、ラッシュアワー時に 5 分ほどかかります。このような大きくて不器用な巨像にしては、これはかなり良い結果です。

その結果、次のような決定に至りました。

• 360 ギガバイトのディスクを備えた 700 のデータ ノードがあります。
• これらの同じデータ ノードを介してトラフィックをルーティングするための 60 のコーディネーター。
• 40 より前のバージョンから一種の遺産として残した 6.4.0 個のマスター - データセンターの撤退後も生き残るために、たとえデータセンターの撤退であってもマスターのクォーラムを確保するために数台のマシンを失うことは覚悟していました。最悪のシナリオ
• 1 つのコンテナーでロールを結合しようとすると、遅かれ早かれ負荷がかかるとノードが壊れるという事実が発生します。
• クラスター全体で 31 ギガバイトの heap.size が使用されます。サイズを削減しようとすると、先頭にワイルドカードを使用した大量の検索クエリで一部のノードが強制終了されるか、Elasticsearch 自体でサーキット ブレーカーが発生するかのどちらかになります。
• さらに、検索パフォーマンスを確保するために、マスターで発生したボトルネックで処理するイベントをできるだけ少なくするために、クラスター内のオブジェクトの数をできるだけ少なく保つようにしました。

最後にモニタリングについて

これらすべてが意図したとおりに機能することを確認するために、以下を監視します。

• 各データ ノードは、それが存在し、その上にこれこれのシャードがあることをクラウドに報告します。どこかで何かを消滅させると、クラスタは 2 ～ 3 秒後に、センター A でノード 2、3、および 4 を消滅させたと報告します。これは、他のデータ センターでは、いかなる状況においても、シャードが XNUMX つしかないノードを消滅させることはできないことを意味します。左。
• マスターの行動の性質を理解しているので、私たちは保留中のタスクの数を注意深く調べます。なぜなら、スタックしたタスクが 1 つでも時間内にタイムアウトしないと、理論的には緊急事態が発生し、たとえばプライマリでのレプリカ シャードの昇格が機能しなくなり、インデックス作成が機能しなくなる原因となる可能性があります。
• また、最適化中にすでに大きな問題が発生しているため、ガベージ コレクターの遅延についても非常に注意深く観察しています。
• スレッドごとに拒否することで、ボトルネックがどこにあるのかを事前に把握します。
• そうですね、ヒープ、RAM、I/O などの標準的なメトリクスです。

モニタリングを構築するときは、Elasticsearch のスレッド プールの機能を考慮する必要があります。 Elasticsearch ドキュメント 検索とインデックス作成の構成オプションとデフォルト値について説明していますが、thread_pool.management については完全に沈黙しています。これらのスレッドは、特に _cat/shards やその他の同様のクエリを処理します。これは、監視を記述するときに使用すると便利です。クラスターが大きくなるほど、単位時間あたりに実行されるそのようなリクエストの数も多くなります。前述の thread_pool.management は公式ドキュメントに記載されていないだけでなく、デフォルトで 5 つのスレッドに制限されており、実行後にすぐに破棄されます。どの監視が正しく機能しなくなりますか。

結論として言いたいのは、「やった！」ということです。私たちはプログラマーと開発者に、ほぼどのような状況でも、本番環境で何が起こっているかに関する情報を迅速かつ確実に提供できるツールを提供することができました。

はい、結果的には非常に複雑であることが判明しましたが、それでも私たちは自分たちの希望を既存の製品にうまく適合させることができ、自分たちでパッチを当てたり書き直したりする必要はありませんでした。

出所： habr.com