リアルタイムのログ分析について語るとき、人々は ELK(Elastic、Logstash、Kibana)を使用してそれを実装することを考えます。 ELK Stack は、コミュニティで豊富なコンテンツとユースケースを蓄積してきたオープンソースのソリューションです。

Alibaba Cloud Log Service の新バージョンには、LogSearch / LogAnalytics の拡張機能が追加され、ログデータのリアルタイムのインデックス作成、クエリ、および分析をサポートし、さまざまな面でクエリのパフォーマンスとデータ量の計算を最適化します。 このドキュメントでは包括的な比較を行い、お客様の関心を持つ点を分析します。

  • 使いやすさ:機能を使い始めたときのコスト。
  • 機能(重要):クエリと分析。
  • パフォーマンス(重要):単位データ量に対するクエリと分析の要件と遅延状況。
  • スケール(重要):処理可能なデータ量及びスケーラビリティ。
  • コスト(重要):同じ機能とパフォーマンスを使用するためのコスト。

使いやすさ

ログ分析システムは、以下の手順で使用されます:

  1. 収集:安定した方法でデータを書き込みます。
  2. 構成:データソースを構成する方法。
  3. 拡張:より多くのデータソースとマシンにアクセスし、 ストレージスペースとマシンを拡張できます。
  4. 使用:機能セクションに説明があります。
  5. エクスポート:ストリーミングコンピューティングやバックアップ用 OSS への格納などの操作のためにデータを他のシステムに便利にエクスポートできるかどうか。
  6. マルチテナント:データを他人と共有する方法、およびデータを安全に使用できるかどうか。
比較結果
項目 サブ項目 自己構築 ELK LogSearch/Analytics:
収集 プロトコル Restful API Restful API
エージェント Logstash / Beats / Fluentd、豊かなエコシステム Logtail(メイン)+ その他(Logstash など)
構成 ユニット 索引を使用してログを区別する Project + Logstore。 2 つのレベルの概念を提供。 Project は名前空間と見なされ、1 つの Project に複数の Logstore を作成できます。
属性 API + kikana API + SDK + コンソール
拡張 ストレージ マシンを追加してクラウドディスクを購入 操作は必要ありません
マシン マシンを追加 操作は必要ありません
構成 構成管理システムを使用して Logstash を構成し、マシンに適用 構成管理システムを使用せずに、コンソールまたは API を使用して操作を実行
収集ポイント 構成管理システムを使用して構成と Logstash をマシングループにインストール 構成管理システムを使用せずに、コンソールまたは API を使用して操作を実行
エクスポート 方法 API / SDK API/SDK + ストリームコンピューティングエンジン(Spark、Storm、Flink、CloudMonitor)+ ストレージ(OSS)
マルチテナント 安全性 なし(非商用版) HTTPS + 送信署名 + マルチテナント隔離 + アクセス制御
使用 同一アカウント サブアカウント、ロール、製品、および一時的な権限付与

結論:

ELK には多くのエコシステムと書込みツールがあり、多くのインストールと設定ツールをサポートしています。 LogSearch / Analytics は、アクセス、構成、および使用法に関して高度な統合性を備えたホスティングサービスです。 通常のユーザーは、容量と並行処理問題を気にすることなく、5 分で LogSearch / Analytics にアクセスできます。 請求方法は従量課金で、自動スケーリングがサポートされています。

機能(クエリと分析)

クエリ機能により、検索条件を満たすログをすばやく検出します。 分析機能はデータの統計と計算を実行します。

たとえば、ステータスコードが 200 を超えるすべての読み取りリクエストの数とトラフィックに関する統計を IP アドレスで収集することを目的とした分析要件があるとします。 この分析要件は、2 つの操作に変換できます。指定された結果のクエリと結果に対する統計分析です。 場合によっては、クエリなしですべてのログを直接分析できます。

1. Status in (200,500] and Method:Get* 
 2. select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip

クエリ機能の比較

種類 サブ項目 自己構築 ELK LogSearch/Analytics
テキスト インデックスクエリ サポート サポート
単語分割 サポート サポート
中国語の単語分割 サポート 未サポート
プレフィックス サポート サポート
TLD サポート
ファジー サポート サポート
Wildcast サポート 未サポート
数値 long サポート サポート
double サポート サポート
Nested JSON クエリ サポート
Geo Geo クエリ サポート 直接サポートしていません。 指定範囲クエリを使用して同じ効果を得ることができます。
IP IP アドレスクエリ サポート 直接サポートしていません。 文字列クエリを使用しても同じ効果が得られます。
コンテキスト コンテキストクエリ サポート
コンテキストフィルタ サポート

Elasticsearch は、より多くのデータ型とより高度なクエリ方法をサポートしています。 LogSearch/Analytics は独自の機能(たとえば、コンテキストクエリやプログラムログの拡張)を持つ一般的なクエリのほとんどをサポートします。

分析能力の比較

種類 サブ項目 自己構築 ELK LogSearch/Analytics
インターフェイス 方法 API/SDK API/SDK + SQL92
その他のプロトコル JDBC
Agg Bucketing サポート サポート
Metric サポート サポート
Matrix サポート サポート
Pipeline 一部サポート フルサポート
算術演算 数値 サポート
String サポート
推定 サポート
数理統計 サポート
日付変換 サポート
GroupBy Agg サポート サポート
Having コンディション サポート
ソート ソート サポート
Join 複数テーブルの Join サポート

LogSearch / LogAnalytics は Elasticsearch と比較して優れた機能のセットを提供し、SQL-92 を完全にサポートします。 LogSearch / LogAnalytics は、SQL 記述シナリオで直接使用できます。

パフォーマンス

同じデータセットを使用して、データの書き込み、データクエリ、集計の観点から、自己構築の ELK と LogSearch / Analytics を比較します。

実験環境
  1. テストの構成
    種類 自己構築 ELK LogSearch/Analytics
    環境 Elastic Compute Service(ECS)インスタンス(4 コア, 16 GB)x 4 + 効率的な SSD クラウドディスク -
    シャード 10 10
    コピー数 2 3(既定の構成、ユーザーには表示されません)
  2. テストデータ
    • 5 列の double 型データ
    • 5 列の long 型データ。
    • それぞれ 256、512、768、1024、および 1280 の辞書サイズを持つ 5 列のテキスト型データ。
    上記のフィールドはランダムです。 テストログの例は次の通りです。
    timestamp:August 27th 2017, 21:50:19.000 
      long_1:756,444 double_1:0 text_1:value_136
      long_2:-3,839,872,295 double_2:-11.13 text_2:value_475 
     long_3:-73,775,372,011,896 double_3:-70,220.163 text_3:value_3
     long_4:173,468,492,344,196 double_4:35,123.978 text_4:value_124 
     long_5:389,467,512,234,496 double_5:-20,10.312 text_5:value_1125
  3. データセットのサイズ
    • 生データのサイズ:50 GB
    • キーを削除した生データのサイズ:27 GB(LogSearch / Analytics は、このサイズをストレージの請求単位として使用します)。
    • ログ行数:162,640,232(約 1 億 6000 万ログ)

テスト結果を書き込む

Elasticsearch は Bulk API を使用してデータをバッチで書き込み、LogSearch / LogAnalytics は PostLogstoreLogs API を使用してバッチ書き込みを実行します。 各機能の詳細は次の通りです:

種類 項目 自己構築 ELK LogSearch/Analytics
待ち時間 平均書き込み待ち時間 40 ms 14 ms
ストレージ 一度にコピーされたデータボリューム 86 GB 58 GB
拡張率:データ量/生データサイズ 172% 121%
請求書を生成する LogSearch / Analytics のストレージサイズには、書き込まれた圧縮生データの量(23 GB)とインデックス作成トラフィック(27 GB)が含まれ、合計で 50 GB になります。

テスト結果によると:

  • LogSearch / Analytics(14 ms) は、Elasticsearch(40 ms)より書き込み待ち時間が短くなっています。
  • スペース:生データのサイズは 50 GB です。 テストデータがランダムであるため、ストレージスペースが拡張してしまいます。 (ほとんどの実際のシナリオでは、圧縮後のストレージスペースは生データのサイズよりも小さくなります。) Elasticsearch が占有するストレージ容量は 86 GB まで拡張され、拡張率は 172% です。 LogSearch / Analytics が占有するストレージ容量の 58% 以上あります。

読み取り(クエリ + 分析)テスト

テストシナリオ

例として 、2 つの一般的なシナリオを使用します:ログクエリと集計。 並行性がそれぞれ 1、5、および 10 の場合の 2 case の平均待ち時間をカウントします。

  1. 全データの任意の text 列に対して GROUP BY 計算を実行します。 5 つの列の avg/min/max/sum/count を計算し、値を count 順に並べ替えます。 最初の 1000件 の結果を取得します。 例:
    select count(long_1) as pv,sum(long_2),min(long_3),max(long_4),sum(long_5) 
    group by text_1 order by pv desc limit 1000
  2. 完全なデータの場合は、次のようなキーワードを使用してログをランダムにクエリします。 value_126。 クエリ条件と最初の 100 ログ行を満たすログの数を取得します。 例:
    value_126
試験結果
種類 並行数 Elasticsearch の待ち時間(単位:秒) LogSearch / Analytics の待ち時間(単位:秒)
case 1:解析クラス 1 3.76 3.4
5 3.9 4.7
10 6.6 7.2
case 2:クエリ 1 0.097 0.086
5 0.171 0.083
10 0.2 0.082
結果分析
  • テスト結果によると、1 億 5 千万データの規模で、Elasticsearch と LogSearch / Analytics の両方が数秒以内にデータのクエリと分析を行うことができます。
  • case 1(統計)では、Elasticsearch と Log Service は待ち時間に関して同じパフォーマンスレベルにあります。 SSD クラウドディスクを使用した Elasticsearch は、大量のデータを読み取るときに LogService よりもI/O が速いです。
  • case 2(クエリ)では、 LogSearch / Analytics は Elasticsearch よりも待ち時間がはるかに短いです。 並行性の増加につれて、ELK の待ち時間は増加しますが、LogSearch / Analytics の待ち時間は安定したままか、もしくは減少する傾向です。

スケール

  1. LogSearch / Analytics は、1 日に数 PB のデータをインデックス付けし、一度に数秒以内に数十 TB のデータをクエリすることができ、データ量の自動スケーリングおよび水平方向のスケーリングをサポートします。
  2. Elasticsearch は、1 日に GB-TB レベルのデータを書き込み、TB レベルのデータを保存するのに適用できます。主な制限は以下のとおりです:
    • 単一クラスタスケール:理想的な条件は、1 つのクラスタに約 20 台のマシンが含まれていることです。 業界では、1 つのクラスタに最大 100 のノードを含めることができます。
    • 書き込み機能の拡張:シャードの作成後に書き込み機能を変更することはできません。 スループット率が上がると、ノードは動的に拡張されます。 使用できる最大のノード数は、シャードの数です。
    • ストレージ拡張:シャードが一度にディスク容量の上限に達すると、それをより容量の大きい別のディスクにマイグレーションするか、より多くのシャードを割り振る必要があります。通常は、インデックスを作成し、さらにシャードを指定して、既存のデータを再作成することができます。

      各シャードは分散ストレージにあるため、LogSearch/Analytics には拡張の問題がありません。 スループット率が上がると、処理能力の水平方向の拡大縮小のためにシャードを動的に分割することができます。

コスト

このセクションでは、前述のテストデータに基づいて、50 GB のデータが毎日書き込まれ、90 日間保存された場合の平均月額コストを計算します(実際のデータサイズは 27 GB です)。

  1. 1. Log Service LogSearch / Analytics の請求額には、読み書きトラフィック、インデックストラフィック、およびストレージスペースが含まれます。 クエリ機能は無料です。 詳細は、次をご参照ください: Billing method
    請求項目 単価 費用(USD)
    書き読みトラフィック 23 GB x 30 USD 0.2/GB 138
    ストレージスペース(90 日間保管されたデータ) 50 GB x 90 USD 0.3/GB x Month 1350
    インデックストラフィック 27 GB x 30 USD 0.0875/GB 283
    合計 - - 1771
  2. Elasticsearch のコストには、マシンのコストとデータストレージに使用される SSD クラウドディスクのコストが含まれます。
    • 通常、クラウドディスクは高い信頼性を提供します。 そのため、コピーの保管には請求しません。
    • ストレージディスクの場合は通常、書き込まれたデータによる全容量の占有を避けるために、15 % の使用可能容量を確保する必要があります。 そのため、係数 1.15 が掛けられます。
    請求項目 単価 費用(USD)
    サーバー 4 コア、16 GB x 4(3 ヶ月)(ecs.mn4.xlarge) 毎月または年間サブスクリプションの費用:USD 675 /月 2021
    ストレージ 86 * 1.15 * 90(ここでは 1 つのコピーのみが計算されます) SSD:1 USD / GB / 月 8901
    - SATA:0.35 USD / GB / 月 3115
    合計 12943 (SSD)
    5135 (SATA)

同じパフォーマンスで、LogSearch / Analytics と ELK(SSD)のコスト比は 13.6% です。 テストプロセス中、SSD を SATA に置き換えるとコストが削減されます(LogSearch / Analytics と ELK の SATA とのコスト比は 34 % です)。 ただし、待ち時間は 40ms から150ms に増加します。長期間の読み取りおよび書き込みの後、クエリおよび読み取り/書き込みの待ち時間が大幅に増加し、クエリおよび分析機能が異常になります。

最後に

オープンソースの ELK と比較して、LogSearch / Analytics は同じクエリ速度を提供する上、より高いスループット、より強力な分析能力、及び 87% のコスト削減を提供します。 それ以外にも、従量課金と O&M 不要に対応しているため、ビジネス分析に集中できます。

LogSearch / Analytics に加えて、Log Service は LogHub と LogShipper 機能も提供し、リアルタイムのデータ収集、ストリームコンピューティングシステム(Spark、Storm、Flink)およびオフライン分析システム(E-MapReduce、Presto、Hive)との互換をサポートし、 ワンストップのリアルタイムデータソリューションを提供しております。