コアDB:最適化の手法

Document created by RSA Information Design and Development on Feb 15, 2017
Version 1Show Document
  • View in full screen mode
  

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

閾値

閾値は、Security Analyticsのナビゲーション ツールの応答性能に大きな効果を与えることがあります。閾値はvaluesコールに適用されます。valuesコールの詳細については、以下を参照してください。 クエリー.

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

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

複雑なWhere句

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

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

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

AND、OR

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

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

使用例:大きなサブネットとの一致

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

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

 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メタに値レベルのインデックスを構成することによって、クエリーをより複雑なものに拡張せずに、目的のサブセットに一致するセッションを迅速に照合できます。

使用例:サブストリング一致

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

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

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

 url contains 'www.rsa.com' 

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

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

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

 alias.host = 'www.rsa.com' 

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

インデックスのセーブ

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

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

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

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

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

 hours=8 pathname=/index msg=save 

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

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

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

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

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

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

Value Maxへの対処

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

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

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

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

ワークロードの並列処理

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

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

インデックスの再構築

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

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

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

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

保存期間の延長

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

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

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

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

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

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

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

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

水平的な拡張

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

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

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

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

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

Security Analyticsのデータベース パフォーマンスを向上させるには、同じ範囲の期間のデータを使用する傾向があるユーザーをグループにまとめるようにします。たとえば、最新のデータを毎日監視するユーザーを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設定の値を大きくすると、認識されるパフォーマンスが向上しますが、最新データを検索できるようになるまでに、若干の遅延が生じることになります。

時間制限

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

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

Attachments

    Outcomes