CIAN がテラバイト規模のログをどのように管理したか

皆さん、こんにちは。私の名前はアレクサンダーです。私は CIAN でエンジニアとして働いており、システム管理とインフラストラクチャ プロセスの自動化に携わっています。 以前の記事の 4 つへのコメントで、XNUMX 日あたり XNUMX TB のログをどこで入手し、そのログをどう扱うかについて尋ねられました。 はい、大量のログがあり、それらを処理するために別のインフラストラクチャ クラスターが作成されているため、問題を迅速に解決できます。 この記事では、増大し続けるデータ フローを処理するために、XNUMX 年をかけてそれをどのように適応させたかについて説明します。

どこから始めたのでしょうか？

ここ数年、cian.ru の負荷は急速に増加し、2018 年の第 11.2 四半期までに、リソース トラフィックは月間 40 万ユニーク ユーザーに達しました。 当時、重要な瞬間に最大 XNUMX% のログが失われていたため、インシデントに迅速に対処できず、解決に多大な時間と労力を費やしていました。 また、問題の原因が見つからず、しばらくすると再発することもよくありました。 それは地獄だったので、それについて何かをしなければなりませんでした。

当時、ログを保存するために標準のインデックス設定を備えた ElasticSearch バージョン 10 を備えた 5.5.2 個のデータ ノードのクラスターを使用しました。 これは、人気があり手頃なソリューションとして XNUMX 年以上前に導入されました。当時はログのフローがそれほど大きくなかったため、非標準の構成を考え出す意味がありませんでした。 

受信ログの処理は、100 つの ElasticSearch コーディネーターの異なるポートで Logstash によって提供されました。 サイズに関係なく、XNUMX つのインデックスは XNUMX つのシャードで構成されます。 時間ごとおよび日ごとのローテーションが組織されました。その結果、XNUMX 時間ごとに約 XNUMX 個の新しいシャードがクラスターに出現しました。 ログはそれほど多くありませんでしたが、クラスターはうまく対処し、誰もその設定に注意を払いませんでした。 

急速な成長の課題

XNUMX つのプロセスが互いに重複するため、生成されるログの量は非常に急速に増加しました。 一方で、サービスの利用者数は増加しました。 その一方で、私たちはマイクロサービス アーキテクチャに積極的に切り替え始め、C# と Python で古いモノリスを解体しました。 モノリスの一部を置き換えた数十の新しいマイクロサービスにより、インフラストラクチャ クラスターに対して大幅に多くのログが生成されました。 

クラスターが事実上管理不能になるまで私たちを導いたのはスケーリングでした。 ログが 20 秒あたり 6 メッセージの速度で到着し始めたとき、無駄なローテーションが頻繁に行われたため、シャードの数は 600 に増加し、ノードごとに XNUMX を超えるシャードが存在しました。 

これにより RAM の割り当てに問題が発生し、ノードがクラッシュするとすべてのシャードが同時に移動し始め、トラフィックが増大して他のノードに負荷がかかるため、クラスターにデータを書き込むことがほぼ不可能になりました。 そしてこの期間中、私たちはログなしで放置されました。 そして、サーバーに問題があった場合、基本的にクラスターの 1/10 が失われます。 多数の小さなインデックスにより複雑さが増しました。

ログがなければ、私たちはインシデントの理由を理解できず、遅かれ早かれ同じ熊手を再び踏む可能性がありました。私たちのチームのイデオロギーでは、これは容認できませんでした。なぜなら、私たちのすべての作業メカニズムはまったく逆のこと、つまり二度と繰り返さないように設計されているからです。同じ問題があります。 これを行うには、全量のログとその配信をほぼリアルタイムで行う必要がありました。これは、勤務中のエンジニアのチームがメトリクスだけでなくログからもアラートを監視していたためです。 問題の規模を理解するために、当時のログの総量は 2 日あたり約 XNUMX TB でした。 

私たちは、ログの損失を完全に排除し、不可抗力時の ELK クラスターへの配信時間を最大 15 分に短縮するという目標を設定しました (後でこの数値を内部 KPI として利用しました)。

新しいローテーションメカニズムとホットウォームノード

ElasticSearch バージョンを 5.5.2 から 6.4.3 に更新することで、クラスターの変換を開始しました。 またしてもバージョン 5 クラスターが停止したため、クラスターをオフにして完全に更新することにしました。ログはまだありません。 したがって、この移行はわずか数時間で完了しました。

この段階で最も大規模な変換は、コーディネーターを中間バッファとして使用する 2 つのノード上での Apache Kafka の実装でした。 メッセージ ブローカーのおかげで、ElasticSearch で問題が発生したときにログが失われることがなくなりました。 同時に、クラスターに 24 つのノードを追加し、データセンター内の異なるラックに XNUMX つの「ホット」ノードを配置するホット/ウォーム アーキテクチャに切り替えました。 アプリケーション エラー ログだけでなく、いかなる状況でも失われないマスクを使用して、ログを nginx にリダイレクトしました。 デバッグ、警告などのマイナー ログが残りのノードに送信され、XNUMX 時間後に「ホット」ノードからの「重要」ログが転送されました。

小さなインデックスの数を増やさないために、時間回転からロールオーバー機構に切り替えました。 フォーラムでは、インデックス サイズによるローテーションは非常に信頼できないという情報が多かったので、インデックス内のドキュメントの数によるローテーションを使用することにしました。 各インデックスを分析し、ローテーションが機能するまでに必要なドキュメントの数を記録しました。 したがって、最適なシャード サイズ (50 GB 以下) に達しました。 

クラスターの最適化

しかし、問題を完全に解決したわけではありません。 残念ながら、小さなインデックスが依然として表示されていました。それらは指定されたボリュームに達しておらず、ローテーションされておらず、日付によるローテーションを削除したため、600 日より古いインデックスのグローバル クリーニングによって削除されました。 これにより、クラスターからのインデックスが完全に消失し、存在しないインデックスに書き込もうとしたため、管理に使用していたキュレーターのロジックが壊れ、データ損失が発生しました。 書き込み用のエイリアスがインデックスに変換され、ロールオーバー ロジックが壊れ、一部のインデックスが制御不能に最大 XNUMX GB まで増加しました。 

たとえば、ローテーション構成の場合:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

ロールオーバー エイリアスがない場合は、エラーが発生しました。

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

この問題の解決策は次のイテレーションに残し、別の問題に取り組みました。つまり、受信ログを処理する (不要な情報を削除して強化する) Logstash のプル ロジックに切り替えました。 これを docker に配置し、docker-compose 経由で起動します。また、ログ ストリームの運用監視のために Prometheus にメトリクスを送信する logstash-exporter もそこに配置しました。 このようにして、各タイプのログの処理を担当する logstash インスタンスの数をスムーズに変更する機会が得られました。

クラスターを改善している間、cian.ru のトラフィックは月間 12,8 万ユニーク ユーザーに増加しました。 その結果、私たちの変換は運用環境の変更よりも少し遅れていることが判明し、「ウォーム」ノードが負荷に対処できず、ログの配信全体が遅くなるという事実に直面しました。 「ホット」データは障害なく受信できましたが、インデックスを均等に分散するために残りのデータの配信に介入し、手動でロールオーバーを行う必要がありました。 

同時に、クラスター内の logstash インスタンスの設定のスケーリングと変更は、ローカルの docker-compose であり、すべてのアクションが手動で実行されたため複雑でした (新しいエンドを追加するには、すべてのアクションを手動で実行する必要がありました)サーバーにアクセスし、どこでも docker-compose up -d を実行します)。

ログの再配布

今年の 30 月、私たちはまだモノリスを分割しており、クラスターの負荷は増加しており、ログのフローは XNUMX 秒あたり XNUMX メッセージに近づいていました。 

ハードウェアのアップデートから次のイテレーションを開始しました。 私たちはコーディネーターを XNUMX 人から XNUMX 人に切り替え、データ ノードを置き換え、金額とストレージ スペースの面で勝利を収めました。 ノードには XNUMX つの構成を使用します。 

• 「ホット」ノードの場合: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 に 1 つ、Hot3 に 2 つ)。
• 「ウォーム」ノードの場合: E3-1230 v6 / 4Tb SSD / 32 Gb x 4。

この反復では、フロントラインの nginx ログと同じスペースを占有するマイクロサービスのアクセス ログを含むインデックスを、20 つの「ホット」ノードからなる XNUMX 番目のグループに移動しました。 現在、データを「ホット」ノードに XNUMX 時間保存し、その後、残りのログを「ウォーム」ノードに転送します。 

小さなインデックスが消える問題は、インデックスのローテーションを再構成することで解決しました。 現在は、データがほとんどない場合でも、インデックスは 23 時間ごとにローテーションされます。 これにより、シャードの数がわずかに増加しました (シャードの数は約 800 でした) が、クラスターのパフォーマンスの観点からは許容範囲です。 

その結果、クラスター内には「ホット」ノードが XNUMX つあり、「ウォーム」ノードは XNUMX つだけになりました。 これにより、長い時間間隔でリクエストにわずかな遅延が発生しますが、将来的にノードの数を増やすことで、この問題は解決される予定です。

この反復により、半自動スケーリングがないという問題も修正されました。 これを行うために、実稼働環境に既にデプロイしたものと同様のインフラストラクチャ Nomad クラスターをデプロイしました。 今のところ、負荷に応じて Logstash の量が自動的に変化するわけではありませんが、これについては考えていきます。

将来の計画

実装された構成は完全に拡張され、現在、アラートの緊急分析に必要な 13,3 TB のデータ (4 日間のすべてのログ) が保存されています。 ログの一部をメトリクスに変換し、それを Graphite に追加します。 エンジニアの作業を容易にするために、インフラストラクチャ クラスターのメトリクスと、一般的な問題を半自動修復するためのスクリプトが用意されています。 来年予定しているデータノード数の増加後は、データストレージを4日から7日に切り替える予定です。 インシデントをできるだけ早く調査するよう常に努めており、長期的な調査にはテレメトリ データがあるため、運用作業にはこれで十分です。 

2019 年 15,3 月の時点で、cian.ru へのトラフィックはすでに月間 XNUMX 万ユニーク ユーザーに増加していました。 これは、ログを配信するためのアーキテクチャ ソリューションの重大なテストとなりました。 

現在、ElasticSearch をバージョン 7 に更新する準備をしています。ただし、このためには、ElasticSearch の多くのインデックスのマッピングを更新する必要があります。これらのインデックスはバージョン 5.5 から移行され、バージョン 6 で非推奨として宣言されたためです (バージョンには存在しないだけです)。 7）。 これは、更新プロセス中に何らかの不可抗力が確実に発生し、問題が解決されるまでログが残らないことを意味します。 バージョン 7 の中で、私たちが最も期待しているのは、改良されたインターフェースと新しいフィルターを備えた Kibana です。 

私たちは主な目標を達成しました。ログの損失をなくし、インフラストラクチャ クラスターのダウンタイムを週に 2 ～ 3 件のクラッシュから月に数時間のメンテナンス作業に短縮しました。 制作中のこうした作業はすべて、ほとんど目に見えません。 ただし、サービスで何が起こっているかを正確に判断できるようになり、サイレント モードですぐに実行できるようになり、ログが失われることを心配する必要がなくなります。 一般に、私たちは満足しており、満足しており、後で説明する新しいエクスプロイトの準備をしています。

出所： habr.com