ログクエリと分析で LogSearch/Analytics とELKを比較する

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

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

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

使いやすさ

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

1. 収集：安定した方法でデータを書き込みます。
2. 構成：データソースを構成する方法。
3. 拡張：より多くのデータソースとマシンにアクセスし、 ストレージスペースとマシンを拡張できます。
4. 使用：機能セクションに説明があります。
5. エクスポート：ストリーミングコンピューティングやバックアップ用 OSS への格納などの操作のためにデータを他のシステムに便利にエクスポートできるかどうか。
6. マルチテナント：データを他人と共有する方法、およびデータを安全に使用できるかどうか。

結論：

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

クエリ機能の比較

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

分析能力の比較

• ES 5.5 aggregation
• 分析文法

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 を使用してバッチ書き込みを実行します。 各機能の詳細は次の通りです：

テスト結果によると：

• 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

• テスト結果によると、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）との互換をサポートし、 ワンストップのリアルタイムデータソリューションを提供しております。