AWS Elasticsearch後モード

そのため、たまたまSaaSバージョンのLogSentineで生産上の問題に遭遇しました.Elasticsearchは新しいデータのインデックス作成を停止しました.Elasticsearchはセカンダリストレージにすぎないため、データの損失はありませんが、ダッシュボードにリアルタイムのデータを表示できないという問題があります.次は事後分析です.何が起こったのか、何が起こったのか、私たちはそれをどのように処理し、どのように防止したのか.
システムがどのように動作するかの背景から始めましょう.RESTful API(またはsyslog)を通じて監査追跡エントリ(ログ)を受け取り、Kafkaトピックにプッシュします.次に、Kafkaトピックを使用してデータをプライマリストレージ(Cassandra)に格納し、Elasticsearchでよりよく可視化および分析できるようにインデックスします.管理するAWS Elasticsearchサービスを選択したのは、クラスタ管理のすべてのコストを節約し、起動会社としてインフラストラクチャ管理を最小限に抑えるためです.下に見えるように、これは祝福と呪いです.
Elasticsearchストレージスペースやログファイルのアプリケーションエラー数など、多くの要素でアラートを有効にしました.これにより、問題に迅速に対応できます.これにより、「多数のアプリケーション・エラー」アラートがトリガーされます.インデックスはFORBIDDEN/8/index writeによってブロックされます.システムコールを有効にしているので、実行しようとしましたが、1分もしないうちに再びブロックされました.これは、Kafkaユーザーがメッセージを処理できないことを意味します.これは、Kafkaに十分なメッセージ保持期間があるため、データが失われないため、良いです.
私はこのような阻止の可能性の原因を調べた.Amazonによると、JVMのメモリ圧力の増加とディスク容量の不足が2つあるという.指標を調べたところ、すべてがよく見えました.JVMのメモリ圧力はほとんど70%(しきい値は75%)に達しず、200 GiBを超える無料ストレージがあります.ElasticsearchアプリケーションログにはWARNが1つしかありません(これは「ノード障害」ですが、その後は何も報告されていません)
この問題にはもう一つの奇妙な側面があります.ノードの数は構成の2倍です.これは通常、AWSがElasticsearchの青/緑の導入を使用しているため、アップグレード中に発生しますが、最近はアップグレードされていません.これらの追加のノードは、通常、短い時間で消失します(再配置/アップグレードの準備が完了した後)、この場合は消失しません.
SSHで実際のマシンに接続することができず、Elasticsearchでインデックスのブロックを解除することができず、ノードを閉じたり再起動したりすることができず、サポートリクエストを提出しました.私たちが何度も何度も交流した後、問題はすでに明確に解決された.
この問題の主な原因は2倍です.まず、クラスタの状態を反映できない構成があります.より多くのノードがあると仮定しますが、共有とレプリカの構成は、レプリカが割り当てられていないことを意味します(こことここのフラグメントとレプリカはもっと多い).ベストプラクティスは、ノード>コピー数を使用して、各ノードに1つのコピー(プライマリスライスを加えた)を取得することです.割り当てられていないスライスコピーを持つこと自体が悪くなく、合理的な理由があります.構成エラーとみなされるかもしれませんが、すぐに悪影響を及ぼすものではありません.これらの設定を選択したのは、クラスタを作成した後、AWSで設定を変更できないためです.インデックスのオン/オフはサポートされていません.
2つ目の問題は、AWS Elasticsearchロジックであり、そのブレーカでインデックス作成を阻止する使用可能なストレージを計算するために使用されます.したがって、AWS Elasticsearchは、既存のノードごとに200+GiBの空き領域があるとしても、私たちのスペースが不足し、インデックス作成を阻止していると考えています.AWSが利用可能と考えているストレージは見られず、AWSが利用可能と考えているストレージは見られないため、この点は見られません.したがって、スライス+コピーの合計数が計算され、各共有ストレージに乗算されます.これは、割り当てられていないレプリカが実際のスペースを占有しないことを意味します.これは、それらが占有しているようにします.この論理は直感に反し(完全に間違っていなければ)、ほとんど予測できない.
青/緑の配置が発生すると、この論理がトリガーされます.したがって、通常の操作では、実際の残りのストレージ領域がチェックされますが、アップグレード中にスライスベースのチェックがトリガーされます.それはクラスタ全体をブロックしている.しかし、青緑色の導入プロセスをトリガーしたのは何ですか?
Kibanaにアクセスする必要があり、厳格なセキュリティルールのため、デフォルトでは誰もアクセスできません.そのため、オフィスのIPからアクセスできるように、アクセスポリシーを一時的に変更しました.この変更は、新しい導入をトリガーすることはなく、このような変化をもたらすことはありません.ただし、AWSドキュメントでは、
ほとんどの場合、次の操作では青緑色の配置は起こりません.アクセスポリシーの変更、自動スナップショット時間の変更、ドメインに専用のプライマリノードがある場合のデータ・インスタンス数の変更です.いくつかの例外がある.たとえば、3つの空き領域のサポートが開始されてからドメインが再構成されていない場合、Amazon ESでは、空き領域にプライベートプライマリノードを再割り当てするためのブルー/グリーン配置が実行される場合があります.
明らかに他の例外があります.その中の1つは私たちに起こっています.これにより、構成に欠陥があるため、割り当てられていないレプリカがストレージ領域を占有していると仮定する奇数論理に基づくインデックスブロックがトリガーされます.
修復方法-より少ないコピーでインデックスを作成し、プライマリ・ソースからデータを取得し、一括インデックスを作成する再インデックスを開始しました.これにより、スペースが削減され、AWSが手動で介入して青/緑の配置を「キャンセル」します.問題が分かったら、修復は簡単です(他のインデックス構成の変更により、インデックスを再作成する必要があります).(再度)問題解決とコミュニケーションの面でAWSのサポートがどれほど良いかをお話しします.
私が最初に言ったように、これはデータの損失を意味するものではありません.Kafkaにメッセージを十分な時間保持させたからです.ただし、インデックスが書き込み可能になると、ユーザーは前の成功したメッセージを引き続き使用することを望んでいます.トランザクション動作は、プライマリ・メモリに正常に格納され、インデックスが正常に確立された後にのみオフセット量をコミットするために作成されます.残念なことに、私たちが使用しているkafkaクライアントは、無視した自動コミット機能を開きました.そのため、消費者は失敗のニュースをスキップした.それらはまだKafkaの中で、私たちは単独のツールを使って処理していますが、これは私たちの仮定が間違っていることを示しており、コードが「commit」を呼び出しているという事実を示していますが、これは実際には何も意味しません.
だから、物語の寓意は:

すべてを監視します.悪いことが起こったら、すぐに理解するのはいいことです.

本番構成を確認し、現在の要件を満たすのに十分であることを確認します.コピー、JVMサイズ、ディスク容量、再試行回数、自動スケーリングルールなどです.

管理クラウドサービスに注意してください.彼らは多くの精力を節約しましたが、制御権を失いました.彼らが直面する可能性のある問題は、サポート部門に連絡することです.

管理サービスが提供されている場合は、潜在的なエッジ状況に関する十分な情報が表示されていることを確認します.エラー・コンソール、アクティブ・コンソールなど、お客様は何が起こっているのかを知ることができます.

ライブラリのデフォルト設定に関する仮定を検証します.(理想的には、現在の構成状態で何らかの予期せぬ操作を実行した場合、ライブラリは警告する必要があります)

アプリケーションがフォールトトレランスであることを確認します.つまり、1つのコンポーネントの障害が世界全体を停止したり、データが失われたりしないことを確認します.

従って、総じて、珍しいイベントが青緑色の導入を予期せぬトリガし、欠陥のある構成と欠陥のある利用可能な空間計算の組み合わせが書き込み不可能なクラスタをもたらした.幸いなことに、データの紛失はなく、少なくとも私はいくつかのことを学んだ.
翻訳:https://www.javacodegeeks.com/2020/03/an-aws-elasticsearch-post-mortem.html