運用維持コストを抑えられたか？ 次世代セキュリティDWHがもたらす効果と運用の泥臭い苦労話：セキュリティ組織にデータ民主化を――「次世代セキュリティDWH」大解剖（終）

マーケティング分析で用いられているデータ基盤サービスを活用した、リクルートの「次世代セキュリティDWH」の構築事例を中心に、最新のセキュリティログ基盤の動向を紹介する連載。最終回は、得られた効果、運用の泥臭い苦労話、今後の展望を紹介する。

[日比野恒，リクルート]

　マーケティング分析で用いられているデータ基盤サービスを活用した「次世代セキュリティDWH（データウェアハウス）」の構築事例を紹介する本連載「セキュリティ組織にデータ民主化を――『次世代セキュリティDWH』大解剖」も今回でいよいよ最終回です。

　連載第1回は、セキュリティ業務で利用するログ基盤に「BigQuery」「Looker」を採用した背景や“いきさつ”、どのような期待値があったのかを紹介しました。前回の第2回は、ローコードETL（Extract、Transform、Load）サービス「Cloud Data Fusion」とLookerの設計の考え方を中心に全体のシステムアーキテクチャについて解説しました。

　最終回は、導入してから約半年の間で得られた効果、運用フェーズにおける泥臭い苦労を総括として解説します。最後に今後の展望について少し触れます。

得られた効果

　第1回で「ログ基盤の抱える課題」として、次の3つの課題を紹介しました。

1. 運用維持コストにおける課題
2. データ活用におけるスキル格差の課題
3. DevOps人材確保における課題

　今回構築した次世代セキュリティDWHでこれらの課題がどの程度解決できたのかを紹介します。

ログ容量の増加に伴うコスト影響の極小化

　今回構築したシステム全体のコスト構造について説明します。課金対象の主なサービスはCloud Storage、Cloud Data Fusion、BigQuery、Lookerの4つです。Looker以外のサービスは利用したリソース分をGoogle Cloudの利用料として毎月請求されますが、Lookerは前払いで年間ライセンスを購入します。

　Lookerはベースとなるプラットフォームライセンスに、「Viewer」（ダッシュボード作成者用）10人、「Developer」（LookML開発者用）2人のユーザーライセンスが含まれます。足りない場合は追加で必要な役割のユーザーライセンスを購入する必要があります。

　これまで利用してきたSIEM（Security Information and Event Management）製品の課金体系と比べると、ログ容量のサイジング予想を外したとしてもストレージにかかるコストが非常に安価なので、コスト全体に与える影響が少なくて済みました。Cloud Storageは「Standard Storage」プランで1GBごとに月額0.023ドル、BigQueryは1GBごとに月額0.024ドルで、90日間更新されなければ、ほぼ半額の0.016ドルになります。

　また定常的な監視ではなくアドホックに分析しているので、クエリスキャン容量による課金体系は非常に都合が良く、こちらもコストメリットを感じています。スキャン容量は月1TBまで無料、1TBを超えてスキャンされたデータは1TBごとに月額6ドルのレートで課金されます。

　このスキャン容量を抑えるために設計や運用で次のように工夫しました。

• パーティション分割テーブルによるスキャン対象の絞り込み
• テーブルクラスタリングによる不要なデータのスキャンの省略
• カスタムコスト管理による制御とチューニング
• 「Cloud Monitoring」によるスキャンデータのモニタリング

　ログは時系列データです。ログのイベント発生日時フィールドで日別のパーティション分割テーブルを作成し、検索条件によく利用するフィールド（ユーザー名やIPアドレスなど）をテーブルクラスタリングに利用しています。ビジネスユーザーの分析作業にストレスを与えない範囲をうまくモニタリングしながら、カスタムコスト管理による制御をチューニングしています。

　ログ容量の増加によるコスト影響が「全くない」とは言いませんが、「1日に取り込んだログ容量」または「サーバの台数」による課金のSIEM製品と比べると、その影響は少なくて済むと考えています。またUEBA（User Behavior Analytics）製品に多い「利用している従業員数」による課金と比べても、メリットがあるといえます。

　コストに影響する大きなポイントはLookerのユーザー数の増加ですが、必ずしもデータを利用するメンバーがLookerにログインする必要はないと考えています。作成したダッシュボードのデータを「Googleドライブ」「Slack」にプッシュで配信できれば十分です。現時点では期待していたコスト計画通りに運用できていると考えています。

データ基盤に必要なエンジニアの技術スキルのハードルを下げられるのか

　「多くのSIEM製品では、監視ロジックを開発するためには専用のクエリ言語を習得する必要がある」と、これまでの連載でお伝えしました。

　Lookerではビジネスユーザーがクエリ言語を使わずにダッシュボードを作成できるようになっています。詳細については連載第2回を参照してください。SQLによる集計や加工処理は、事前にLookMLを用いて共通ロジックとしてコード化できるので、クエリ時点での属人的なロジックを排除できるようになりました。

　またLookMLのコードは「Git」の仕組みを用いて管理するので、過去の変更内容はコミットログから追えます。プルリクエスト／マージリクエストを使ってコードをレビューすることもできます。ソフトウェア開発の仕組みに乗っ取って運用できることにはメリットもありますが、その半面、別の意味で扱うメンバーの学習コストを上げてしまう可能性を考える必要もあります。

　LookMLを習得する学習コストについても考えておく必要があり、改めて「銀の弾丸はない」と思いました。先々の技術トレンドを理解しながら、自社組織で維持運用しやすい仕組みやツール、または技術を選定していくことが今後も重要だと考えています。

　今回のシステムでは、全てマネージドサービスを採用したことでインフラ運用にかかるコストをかなり抑えられたと考えています。半年間でのインフラに関する障害はなく、トラブルシューティングは定期的に発生する規約に沿っていない壊れたデータの取り込みエラー対応ぐらいです。

　このアーキテクチャでなければ、短期間かつ2人体制での開発と運用は難しかったと感じています。

苦労したポイント

　ここまでは良い面を中心に紹介しましたが、当然良いことばかりではありません。特にCloud Data Fusionの活用はチャレンジであり、「期待通りの効果が得られるのかどうか」はやってみなければ分からない要素が多かったと思います。ここからは、苦労したポイント、改善されるとうれしいポイントについて触れます。

トラブルシューティング時のデバッグ方法