データベースのチューニング:最適化の手法

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

このトピックでは、NetWitnessコア データベースの最適化の手法について説明します。デフォルトでは、NetWitnessコア データベースはさまざまなワークロードに対応するように構成されています。しかし、そのパフォーマンスは、取得されるデータの性質と、データベースに対して実行する検索の性質に大きく左右されることがあります。

閾値

閾値は、NetWitness Suiteの[ナビゲート]ビューの応答性能に大きな効果を与えることがあります。閾値は values の呼び出しに適用されます。 values の呼び出しの詳細については、「 クエリ 」を参照してください。

閾値は、カウントを生成するためにディスクから取得されるデータベースのデータ量に対する上限を定義します。大部分のクエリでは、 where 句に一致するセッションの数は膨大です。たとえば、1秒あたり30,000イベントのペースで実行される1時間のログ イベントをすべて抽出すると、108,000,000セッションになります。

RSAでは、セッションのカウントが必要となるほとんどの場合、最後のセッションまで正確な結果を得る必要がないという見解に基づいて、閾値機能を導入しました。たとえば、直近1時間の上位20個のIPアドレスを検索する場合、レポートに示されるIPのカウントが10,000,000セッションと一致するか、10,000,001セッションと一致するかは、あまり重要ではありません。推定値で十分です。これらのシナリオでは、カウントが閾値パラメータを超えた場合に、返されたカウントの推定値を出すことができます。閾値に達すると、残りのカウントは推定され、必要であれば、推定カウントに基づいて結果がソートされます。

複雑な where

NetWitnessコア データベースで結果が返されるまでにかかる時間は、クエリの複雑さによって異なります。メタに存在するインデックスと直接合致するクエリではすばやく結果が返されますが、多くの場合、すばやく結果が返されないクエリを作成してしまいがちです。場合によっては、クエリやインデックスを調整することによって、応答性能を改善できることがあります。

where 句の各部分の相対 コスト を把握すると便利です。高コストのクエリ操作は実行するのに長い時間がかかります。次の表に、相対コストの低いものから高いものの順で、クエリ操作を示します。

                         
操作 コスト
exists、!exists 一定
= , != メター キーの一意の値の数という点では対数的、範囲式と一致する一意の要素の数という点では直線的
< , > , <= , >= 一意の値の検索という点では対数的だが、式は広い範囲の値と一致するため、直線的となる可能性が高い
begins , ends , contains メター キーの一意の値の数という点で直線的
regex 値あたりのコストが高いメタ キーの一意の値の数という点で直線的

AND および OR

where 句を作成する場合は、 AND 演算子を使用して多くの条件を作ると、クエリのパフォーマンスに良い影響が出ることがあります。複数の条件を使用して、 where 句に一致するセッション数を絞り込むことができれば、クエリの実行内容が少なくなります。同様に、 OR 句を追加するごとに、各クエリで処理するセッション数が多くなります。

一般的には、クエリ内の AND 句が増えるほど、処理時間が短くなり、クエリ内の OR 句が増えるほど、処理時間が長くなります。

ユースケース:大きなサブネットとの一致

一般的に、あるクラスAサブネットを含む、または含まない、という条件のクエリを作成するケースがあります。このタイプのクエリが一般的なのは、ユーザが調査において内部ネットワークの一部分に対して、含む、含まない、という条件を指定するケースがあるためです。

クエリ エンジンが ip.src または ip.dst インデックスだけでこのクエリを解決しようとすると問題が生じる場合があります。この問題の原因としては、たとえば のような where 句を指定すると、

 ip.src = 10.0.0.0/8 

のようなwhere句を指定すると、実際には次のように解釈されるためです。

 ip.src = 10.0.0.0 || ip.src = 10.0.0.1 || ip.src = 10.0.0.2 || ... || ip.src = 10.255.255.255 

そのため、インデックスによって、1,600万以上の条件を伴う where 句が作成されることもあります。

この問題の解決策は、Decoderで、アプリケーション ルールを使用して対象の一般的なネットワークにタグをつけることです。たとえば、次のようなアプリケーション ルールでメタ アイテムを作成できます。

 name=internal rule="ip.src = 10.0.0.0/8" order=3 alert=network 

このルールは、10.0.0.0/8ネットワーク内のIPアドレスに対してnetworkメタ キーにinternalという値を持つメタ アイテムを作成します。

where 句は次のように表現できます。

 network = "internal" 

networkメタ データに value-level インデックスを構成することによって、クエリをより複雑なものに拡張せずに、目的のサブセットに一致するセッションを迅速に照合できます。

ユースケース:サブストリング一致

メタ キーの一意の値が多数ある場合、 where 句で beginsendscontainsregex の演算子を使用すると、非常に時間がかかることがあります。これらの各演算子は、それぞれの一意の値に対して個別に評価されます。たとえば、演算子が regex の場合、 regex はそれぞれの一意の値に対して個別に実行する必要があります。

これを回避する最も効果的な戦略は、ユーザがサブストリング一致を使用する必要がないようにメタ アイテムを再編成することです。

たとえば、ユーザがセッションのどこかでURL内のホスト名を見つけようとしているとします。ユーザは次のような where 句を作成することが考えられます。

 url contains 'www.rsa.com' 

このシナリオでは、 url メタ キーに、Decoderによって収集された一意の値がセッションごとに1つずつ含まれる可能性が高いため、一意の値は膨大な数になります。この場合、contains操作の処理時間は長くなります。

最善のアプローチは、照合しようとしているメタ データの部分を特定し、その照合部分をコンテンツParserに移動することです。

たとえば、URLごとに生成されているメタ データがある場合、ParserはURLを構成要素のコンポーネントに分解することもできます。たとえば、Decoderが http://www.rsa.com/netwitness という値を持つURLメタ データを生成する場合、 www.rsa.com という値を持つ alias.host メタ データも生成します。次のようにクエリを実行できます。

 alias.host = 'www.rsa.com' 

substring演算子が不要になるため、クエリははるかに高速になります。

インデックスのセーブ

コア インデックスはセーブ ポイント(スライスとも呼ばれる)によって分割されます。インデックスが保存(セーブ)されると、インデックス内のすべてのデータはディスクにフラッシュされ、インデックスのその部分は読み取り専用としてマークされます。セーブは2つの機能を果たします。

  • 各セーブ ポイントは、電源障害が発生した場合にインデックスをリカバリできる場所となります。
  • 定期的なセーブにより、アクティブに更新されているインデックス サイズがRAMより大きくならないようにすることができます。

セーブ ポイントには、インデックスを、独立した、重複しないセグメントに区分化する効果があります。クエリで複数のセーブ ポイントをクロスオーバーしなければならない場合は、クエリの一部を再実行し、結果をマージする必要があります。これによって、最終的に、クエリが完了するまでの時間が長くなります。

NetWitness Suite 10.5以降のインストール環境の場合、デフォルトでは、データベースに600,000,000セッションが追加されるたびに、コア インデックスに対してセーブが実行されます。この間隔は、インデックス構成パラメータ save.session.count によって設定されます。詳細は、「 インデックス構成ノード 」を参照してください。

旧バージョンのNetWitness Suite、または10.5より前のNetWitness Suiteバージョンからアップグレード済みのシステムは、8時間ごとにインデックスをセーブする時間ベースのセーブ スケジュールを使用します。サービスのNetWitness Admin UIでスケジューラ エディタを使用すると、セーブ間隔を確認できます。デフォルトのエントリーを次に示します。

 hours=8 pathname=/index msg=save 

間隔を調整することで、セーブが作成される頻度を制御できます。

セーブ間隔を長くすることの影響

セーブ間隔を長くすると、セーブ ポイントが作成される頻度が低くなるため、存在するセーブ ポイントの数は減ります。これはクエリのパフォーマンスにプラスの影響を与えます。クエリがスライスをまたがって実行される可能性が低くなり、スライスをまたがる必要があっても、スキャンされるスライスの数はあまり多くないためです。

ただし、セーブ間隔を長くすることにはマイナス面もあります。第1に、Concentratorが、いずれかのインデックスで設定された valueMax の上限に達する可能性が高くなります。第2に、強制シャットダウンや電源障害が発生した場合に復旧時間が長くなります。そして第3に、インデックス スライスが大きくなりすぎてメモリに収まらなくなった場合に、集計速度が遅くなる可能性があります。

セーブ間隔を短くすることの影響

セーブ間隔を短くすると、多数の一意の値が含まれるメタ データの完全な値のインデックスを維持しながら、 valueMax の上限に達することを回避できます。ただし、セーブ間隔を短くすると、作成されるスライスが多くなるため、クエリのパフォーマンスにマイナスの影響があります。

valueMax の使用

すべての一意のメタにインデックスをつけたいと考えているユーザは valueMax による上限は不要に思われるかもしれません。しかしながら、一般的にこうした構成は非現実的です。メタ キー値には、インターネット上のあらゆる場所のあらゆるランダムなデータが格納される可能性があるため、すべての一意の値にインデックスをつけることは不可能です。

ただし、値のインデックスの代わりにキー レベルのインデックスを使用することで、 valueMax の上限の一部を回避できます。キー レベルのインデックスは valueMax の影響を受けません。

キー レベルでインデックス付けされたメタ キーで[ナビゲート]ビューを使用できます。データベースは、可能な場合、 where 句に値レベルのインデックスを使用しますが、 values の呼び出しで一意の値を解決するために、メタ データベース スキャンが使用されます。 where 句が、検索範囲を少数のセッション(およそ10,000セッション未満)に制限する効果的なフィルタを提供する場合、このアプローチはうまく機能します。

valueMax に達した場合、ユーザはクエリでデータベース スキャンを実行し、関連する値がドロップされていないことを確認できます。Investigator 9.8クライアントでこの機能にアクセスするには、[ナビゲート]ビューの右クリック メニューを使用します。メタ データベース スキャンは長い時間がかかりますが、ユーザはレポートに欠落したデータがないことを確認できます。

ワークロードの並列処理

多くのレポートを使用している場合は、Reporting Engine内で並列実行オプションを有効活用していることを確認します。同様に、 max.concurrent.queries の数がハードウェアに適していることも確認します。

NetWitness Suiteの[ナビゲート]ビューでは、その出力のコンポーネントを並列処理できます。これは、NetWitnessコア サービスのパフォーマンスに大きなプラスの影響を与える可能性があります。

インデックスの再構築

まれに、コア サービスで、インデックスの再構築が効果を発揮することがあります。例:

  • NetWitnessコア サービスが、非常に古いバージョンの製品で作成されたインデックス スライスを持ち、6か月以上、どのデータもロールアウトしていない。
  • インデックスが不適切に構成されており、ユーザは新しいインデックス構成ですべてのメタのインデックスを再構築したいと考えている。
  • コア サービスへのトラフィック負荷が非常に軽く、セーブ間隔が長いため、必要以上に多くのスライスが生成された。

これらの場合、インデックスの再構築はパフォーマンスの向上をもたらす可能性があります。そのためには、Decoderの /decoder フォルダ、Concentratorの /concentrator フォルダ、Archiverの /archiver フォルダのいずれかで、パラメータ index=1 を指定して、 reset メッセージを送信する必要があります。

完全な再構築が完了するまで、完全にロードされたConcentratorでは数日、完全にロードされたArchiverではさらに時間がかかる場合があることに留意してください。

保存期間の延長

NetWitnessコア データベースの保存期間を改善する方法はいくつかあります。保存期間とは、データベースに格納されたデータが保持される期間のことです。

保存期間を分析する最初のステップは、保存期間の観点で、データベースのどの部分が制限要因であるかを判別することです。パケット、メタ、セッション データベースは、データベースで最も古いファイルの古さを示す packet.oldest.file.timemeta.oldest.file.timesession.oldest.file.time 統計データを /database/stats フォルダで提供します。インデックスは、インデックスに格納されている最も古いセッション時間を示す /index/stats/time.begin 統計データを提供します。

パケットとメタの保存期間を長くする

これらのデータベースで保存期間を長くするための主なメカニズムは、ストレージを追加することです。ストレージをNetWitnessコア サービスに追加できない場合は、パケットおよびメタ データベースで圧縮オプションを使用して、データベースで書き込まれるデータの量を減らすことが必要になる可能性があります。

メタの保存期間が懸念事項である場合は、Decoderが生成するメタから不要なコンテンツを削除することができます。多くのParserは、組織が長期間保存する必要がないメタを生成します。

インデックスの保存期間を長くする

通常、インデックスの保存期間はデータベースの保存期間より長いですが、複雑なカスタム インデックスの場合は保存期間が短くなることがあります。通常、最も簡単な方法は、カスタム構成から不要な値レベルのインデックスを削除するか、あるいはデフォルトの値レベルのインデックスの一部をキー レベルのインデックスで上書きすることです。

また、インデックス ストレージを追加して、インデックスを拡張することも可能です。ただし、インデックス ストレージは、SSD(ソリッド ステート ドライブ)を使用して拡張するようにしてください。

水平的な拡張

バージョン10.3以降、ConcentratorとArchiverは、グループ集計を使用してクラスタ化できます。グループ集計により、単一のDecoderが複数のConcentratorまたはArchiverに負荷が分散されるようにセッションをフィードできます。グループ集計では、必要に応じて大規模なハードウェアのプール内でクエリおよび集計ワークロードを分割できます。

詳細については、「 導入ガイド 」のトピック「グループ集計」トピックを参照してください。

ワークロードのグループ化

システムのすべてのユーザがデータベースの同じ領域で作業すると、NetWitnessコア データベースのパフォーマンスが向上することがあります。データベースには、先入れ先出し方式でDecoderからデータが供給されるため、データベース内のデータは通常、収集および格納された時間に基づいてクラスタ化されています。そのため、すべてのユーザが同じ期間のデータを使用すると、データベースのパフォーマンスが向上します。

すべてのユーザが同時に同じ期間のデータを使用できるとは限りません。NetWitnessコア データベースはそのようなケースにも対処できますが、RAM内で異なる期間のデータを順次入れ替える必要があるため、パフォーマンスが低下することがあります。RAM内に同時にすべての期間のデータを保持することはできません。通常、RAM内に収まるのは、データベースの1%未満とインデックスの10%未満です。

NetWitness Suiteのデータベース パフォーマンスを向上させるには、同じ範囲の期間のデータを使用する傾向があるユーザをグループにまとめるようにします。たとえば、最新のデータを毎日監視するユーザを1つのグループにまとめることができます。調査の一環で時間をさかのぼってクエリを実行するユーザを別のグループにし、長期間にわたるレポートを実行するユーザをさらに別のグループにします。単一のデータベースですべてのグループに対応しようとすると、結果が出るまでに長い時間がかかる可能性があります。しかし、ユースケースに応じてConcentratorのハードウェアを分けることによって、パフォーマンスが大きく向上する可能性があります。この場合、大規模で高価なConcentratorですべてのニーズに対応しようとするよりも、少ないRAMおよび低いCPU処理能力でも、より多くのConcentratorサービスを利用する方が得策かもしれません。

キャッシュ ウィンドウ

次の一連のイベントを考えてみます。

  1. 午前9時にユーザ「kevin」がConcentratorにログインし、収集時間の最後の1時間に関するレポートをリクエストします。
  2. Concentratorは、午前8時から午前9時までの時間範囲に関するレポートを取得します。
  3. 午前9時2分にユーザ「scott」が同じConcentratorにログインし、収集時間の最後の1時間に関するレポートをリクエストします。
  4. Concentratorは、午前8時2分から午前9時2分までの時間範囲に関するレポートを取得します。

両方のユーザが確認している時間範囲は近いものの、若干異なるため、ConcentratorがKevinのために生成したレポートをScottに再送信することはできませんでした。ConcentratorはScottのためにレポートの大部分を再計算する必要がありました。

/sdk ノードの cache.window.minutes 設定により、この状況を最適化できます。ユーザがログインすると、収集された最新のデータを表す時点が、この設定の分数だけ進みます。

たとえば、 /sdk/config/cache.window.minutes を10\と仮定します。前述のアクションを再評価すると、一連のイベントが変わります。

  1. 午前9時にユーザ「kevin」がConcentratorにログインし、収集時間の最後の1時間に関するレポートをリクエストします。
  2. Concentratorは、午前8時から午前9時までの時間範囲に関するレポートを取得します。
  3. 午前9時2分にユーザ「scott」が同じConcentratorにログインし、収集時間の最後の1時間に関するレポートをリクエストします。
  4. Concentratorは、午前8時から午前9時までの時間範囲に関するレポートを取得します。
  5. 午前9時10分にユーザ「scott」が収集時間の最後の1時間に関するレポートを再ロードします。
  6. Concentratorは、午前8時10分から午前9時10分までの時間範囲に関するレポートを取得します。

ステップ3のレポートは、キャッシュ ウィンドウ内に当たるため、即座に返されます。これは、Scottに、Concentratorの処理が非常に速いという印象を与えます。

そのため、 cache.window 設定の値を大きくすると、認識されるパフォーマンスが向上しますが、最新データを検索できるようになるまでに、若干の遅延が生じることになります。

時間制限

クエリがNetWitnessコア データベースで長時間実行されていると、コア サービスは、処理を迅速に完了するために、より多くのCPU時間とRAMをそのクエリに割り当てるようになります。これは、他のクエリや集計にマイナスの影響を与えることがあります。特定のユーザがコア サービス リソースを多大に消費することを防ぐには、クエリに時間制限を設けることを推奨します。

You are here
Table of Contents > 最適化の手法

Attachments

    Outcomes