From ELK to EFK, combined with the new features of Flink and Elasticsearch to reconstruct the full observation plan

上の図はログ活用のいくつかの段階を示しています。現在、多くの企業はレベル 3 とレベル 4 の段階にあり、そのうちレベル 3 がより大きな割合を占めている。取得レベルでは、ログはほとんど構造化されておらず、単一のプラットフォームを通じてすべての運用保守データのグローバル検索を実現しているが、相関分析は行われていない。分析レベルには前提条件があり、原文ログを適切に処理し、非構造化情報から有用な構造化情報を抽出する必要があるが、大量のログが発生する状況では、この対応はより困難になる。

企業が十分に構造化されたログを実装し、多くの有意義な列を生成できれば、分析に対して良好なサポートを提供できる。しかし、構造が不十分な場合は、簡易検索しか行えない。

多くの企業ではログ量が膨大である一方、品質は低い。無意味なログが大量に存在するか、アプリケーション上で意味のあるログが完全には記録されておらず、可観測性を確保できていない。さらに、ログ出力は非常に非構造的で、完全に非構造化されており、テキストを直接出力することさえある。重要な情報を抽出する際は、正規表現で抽出するしかない。最後に、運用保守と開発は分断されており、運用保守側は開発側が出力するログを理解していない。

多くの運用保守担当者の目標は、まずログを収集することである。収集されたログには非常に限られた構造化フィールドしか含まれておらず、コレクターが提供する構造化フィールドのみをインデックス化しており、重要な情報を抽出できない。しかし、ログの要件がこれほどシンプルになると、ログにインデックスを貼る必要はなくなり、全文インデックスのみで十分である。

エラーコードや時間帯に基づく検索など、事後診断では、全数走査を使用しても迅速に結果を得られる。

こうした背景から、業界ではコスト削減を核心とした「新しい」ロギングの潮流が生まれた。たとえば、インデックスを貼らずに直接全数走査を実行する、クラウド上で最も安価なストレージオブジェクトを使用し、SSD やディスクの代わりに圧縮率を高めるといった方法である。ただし、クエリ時に解凍が必要になるため、パフォーマンスはある程度犠牲になる。

しかし、上記のアプローチには明らかな欠点がある。インデックスなしで大量のログをスキャンするには時間がかかるため、タイムスタンプにインデックスを作成し、原文にタグを付ける必要がある。

上記の要件に対応するため、Elasticsearch (ES) は非同期検索を公式にリリースした。検索を分散処理した後、バックグラウンドで検索をゆっくり実行し、結果をバッチで取得できる。たとえば、エラーログを検索する際、まず最初の 100 件の結果を返し、一定時間経過後に次の 100 件を返すことができる。

ES のもう一つの新機能が Runtime Field である。これはインデックスを構築せずに、多様な検索をサポートする。

スクリプトを定義して文字列から必要な情報を取得する (全数走査) ことで、仮想的なフィールドと同等の役割を果たす。仮想フィールドがあれば、すべての ES クエリ文で通常のフィールドと同様に検索できるが、本質的には依然として全数走査である。検索期間を絞れば、実行速度はユーザーの要件をおおむね満たせる。

かつてコミュニティでは、長期保存ログをオブジェクトストレージにスナップショット化していたが、これはバックアップ目的のみで、クエリはできなかった。クエリするには、オブジェクトをクラスターにリストアする必要があり、大量の手作業が必要となる。期待する理想的な状況は、オブジェクトストレージ上で直接クエリを実行することである。そこで、ES は Searchable Snapshot という公式機能をリリースし、ログをオブジェクトストレージに保存できるようにした。ログはライフサイクルとともにコールド化していくが、直接クエリできる。ただし、結果は迅速には返されないため、通常は非同期検索を通じてクエリを行う。この機能は、大企業が非常に長期間のログを検索するのに最適である。

Alibaba Cloud にも同様の機能である OpenStore が提供されている。これは Alibaba Cloud 独自の開発であり、そのインフラに基づいてより強力な最適化を実現できる。マルチレベルキャッシュの実装メカニズムは ES 公式のものとは異なり、SSD やスピニングディスクを使用したマルチレベルキャッシュにより、ES 公式よりも優れた検索速度を実現している。

Flink はタグインデックスで重要な役割を果たす。ES の公式は Logstash だが、現在は EFK スタックで Logstash を Flink で代替できる。Logstash はクラスター構成ではなく、マルチインスタンスのロードバランサーである。一方、Flink のクラスターパフォーマンスや Exactly-Once 配信などの機能は Logstash を上回っている。

そのため、Flink は多くのシナリオで優位性を持つ。たとえば、Flink のウィンドウ機能で複数行のログを 1 行に統合できる。また、ディメンションを追加する際、Flink が大量の構造化データをクエリしてログストリーム上で補完し、最終的に構造化情報を生成できる。ラベルとディメンションが充実して初めて、全数走査のスキャンを最小限に抑えられ、パフォーマンスを大きく犠牲にすることなく、大幅なコスト削減を実現できる。

Flink は指標の保存やサンプリング削減においても優れた選択肢である。

EFK は Elasticsearch + Flink + Libana である。Flink が従来の Logstash を置き換え、リンク全体がフルマネージド化されており、ログフルオブザーバビリティソリューションを迅速に構築できる。

大量のログ書き込み時、Flink はラベル抽出などの処理を担う。Flink の性能は他の類似製品を上回っている。大量の同時書き込みが発生する際、その耐性も大きな課題であるが、ES は専用ソリューションを提供している。さらに、OpenStore はログストレージコストの問題を解決するのに役立つ。同時に、このオープンソースエコシステムはスケーラビリティが非常に高く、上下游の連携能力も優れている。

現在の IoT シナリオでは大量のログが生成され、書き込みとストレージは大きな負荷に直面する。

Alibaba Cloud はこれに対応するソリューションを提供しており、移行コストは低い。ES と Flink を基盤とし、クラウド間をシームレスに接続できる。Alibaba Cloud ES OpenStore は長期ログを OSS に保存し、コストを効果的に削減できる。さらに、Flink の高並発書き込み時の処理能力も優れたサポートを提供する。

大規模な加速時には、書き込みトラフィックにピークと谷が必ず発生するが、クラウド上ではピークシェービングとバレーフィリングを容易に実現できる。

Alibaba Cloud ES Indexing Service は大規模な ES プールを提供し、トラフィックをそのプールに受け入れることで大量書き込みをサポートする。ES Indexing Service はインデックスを構築して ES クラスターに転送し、ES クラスターは検索機能のみに専念できる。ES Indexing Service はピーク値により柔軟に対応できるため、多数の ES コンピューティングインスタンスを事前に確保する必要がない。