Databricksで構築するログ検索基盤とアーキテクチャ設計

Databricksを活用したログ検索基盤の構築と運用についての実践資料です。

AWS WAFのログ基盤において、
従来のOpenSearch構成で発生していた課題（Write飽和・コスト・スケーラビリティ）を踏まえ、
Databricksへの移行とアーキテクチャ設計について解説しています。

本資料では、
・ログ基盤の要件設計（リアルタイム取り込み / 高速検索 / コスト最適化）
・Databricksを用いたログ処理アーキテクチャ
・OpenSearchの限界と移行理由
・実運用でのトラブルと改善（Auto Loader / コスト最適化）
について紹介しています。

S3ベースのストレージとServerless構成により、
高速性・拡張性・コストのバランスを実現した実例です。

#Databricks #ログ基盤 #データ基盤 #AWS #OpenSearch #S3 #データエンジニアリング

Transcript

1. ログ検索基盤として使う Databricks 株式会社サイバーセキュリティクラウド WAF自動運用サービスグループ 寺田 怜真
2. 2 ©Cyber Security Cloud , Inc. 2026 自己紹介 寺⽥ 怜真 TERADA Reima 所属 株式会社サイバーセキュリティクラウド 役職 WAF⾃動運⽤サービスグループ マネージャー 職務内容 WafCharm 開発‧運⽤保守 / SRE プロジェクトマネジメント / スクラムマスター ‧ ‧ WAFルール運⽤‧セキュリティ ‧
3. 3 ©Cyber Security Cloud , Inc. 2026 世界中の人々が安心安全に使える サイバー空間 を創造する すべてはお客様が安心してビジネスに向き合い、 挑戦できる環境を守るため。 CSCは日本発のグローバルセキュリティカンパニーとして、 ますます巧妙化するサイバーセキュリティの脅威から、世界中のお客様を守ります。 ミッション CSC Mission
4. 4 ©Cyber Security Cloud , Inc. 2026 会場の情報を見まして、目黒の駅の近くか、近そうだなと思ってはいたのです が 実は同じビルの13F でした GoogleMap上では外に出る事になってますが、 ビル内でエレベータに2回乗れば つきました CSC のオフィスの場所
5. 5 ©Cyber Security Cloud , Inc. 2026 Webセキュリティにおける当社プロダクトの役割 当社は企業の Webサイトや Webサービスをハッカーの攻撃から「守る手段」、脆弱性を「直す手段」 およびクラウド環境のセキュリティを包括的に「管理・運用する手段」を提供 ハッカーからの サイバー攻撃を防ぐ AWS WAF Managed Rules オンプレミス／クラウド向け クラウドプラットフォーム特化 ハッカーから狙われる 脆弱性情報の収集・管理 900以上のソフトウェアが対象 クラウド環境の セキュリティを包括的に 管理・運用 3大クラウドに対応
6. 6 ©Cyber Security Cloud , Inc. 2026 パブリッククラウド WAF自動運用ツール「 WafCharm」 世界3大プラットフォームに対応した、防御ルール・ブロックリストの自動調整などの WAF運用を簡単にする 国内シェア No.1のパブリッククラウド WAF自動運用サービス 24時間365日の グローバルサポート お客様の環境に最適な ルールの作成・設定が可能 ※1 ITR「ITR Market View：ゲートウェイ・セキュリティ対策型SOCサービス市場2025」 ※2 WafCharm for AWS Marketplaceが対象 ※3 Amazon Web Service、Microsoft Azure、Google Cloud（Canalys “Canalys Newsroom- Global cloud services spend hits record US$49.4 billion in Q3 2021”） 3大クラウド プラットフォーム ※3 に対応 攻撃遮断くんで培った防 御ノウハウを適用 ✔ 国内売上高シェア No.1 ※1 ✔ 数ステップで導入可能 ✔ AWS/Azure/Google Cloud 対応 ✔ 世界220ヵ国以上で販売 ※2
7. 7 ©Cyber Security Cloud , Inc. 2026 AWS WAF自動運用と Databricksによるログ活用フローの最適化 WafCharmの実際の動き 画面 WAFの管理 ログ活用 AWS WAF User
8. 8 ©Cyber Security Cloud , Inc. 2026 ログ機能を用している箇所 (基本は実際の画面で ) WafCharmの実際の動き
9. 9 ©Cyber Security Cloud , Inc. 2026 WafCharmでのログ基盤の要件 CONFIDENTIAL | Requirements Definition Document WAF Log Management Platform v1.0 継続的収集と原型保持 サマリー‧統計分析 特定属性の⾼速検索 保存ポリシーの柔軟性 解析機能の継続的拡張 将来的な「解析アルゴリズムのアップデート」や新機能追加を⾒据え、ログ収集層と解析層を 分離した疎結合なアーキテクチャを採⽤する。 • ログのリアルタイム順次取り込み • 調査に不可⽋な「ログの原型」を最 終的に確認できる状態 • WAF状態の全体像が出せるように • 任意期間（時間/⽇/⽉）での集計情報 を動的に表⽰‧確認できる • IPアドレス、国名などの主要キーに よる検索を可能に • 検索対象項⽬のみを取り込み、速度 とコストを最適化 • 重要度に応じたユーザー定義の保存 ⽇数設定 •「保存ログ数」に基づく従量課⾦によるコスト最適化。 • 最⼤720⽇のログ保持
10. 10 ©Cyber Security Cloud , Inc. 2026 Databricksがどう動いているか ログサマリ Dashboard Page ログサマリ 生ログ Amazon S3 user WAFlog bucket Amazon S3 DatabricksData bucket Serverless SQL Warehouse 2XS x1 Serverless Job w/ autoloader ログカウント ログ削除 analitics page Amazon S3 CSC WAFlog bucket 月間 100TB データの整 形 マテリアライズドビュー job 生ログの 取り出し 保持データ 数の確認 保持期間切れの データの削除 Autoloader のトリガー AWS WAF
11. 11 ©Cyber Security Cloud , Inc. 2026 OpenSearchでの限界とログ基盤の要件 OpenSearchの選定理由 システム上のボトルネック 刷新したいこと • ⾼速な検索性能: トラブルシューティングに おけるリアルタイムなログ調査を優先 • 強⼒な集計機能: Aggregationによる柔軟な統 計分析 • スキーマレスな柔軟性: WAFログのjson形式 の直接取り込みと、変更時の柔軟性 • Write飽和: ログ流⼊増に伴い、書き込み処理 だけでリソースが限界。検索性能に影響が発 ⽣する状態 • DDoSリスク: スパイク耐性がなく、異常流 ⼊時にクラスタが確実にパンク‧停⽌する • メタデータ上限: シャード数が上限に達し、 柔軟な追加‧削除が論理的に拡張不能 • R/Wの完全分離: 書き込みと読み込みを分離 し、データ流⼊と検索‧分析がそれぞれを阻 害しない構成 • ストレージ費⽤の削減: SSDベースから安価 なS3ベースが望ましい • サーバーレス運⽤: クラスタ管理を排除し、 運⽤コスト（OpEx）を最⼩化できること OpenSearch採⽤の背景 直⾯していた限界 次期基盤の要件
12. 12 ©Cyber Security Cloud , Inc. 2026 Databricks に移行してよかったこと スピード 十分なに高速な検索・集計性能を実現 拡張性 運用負荷の極小化とアーキテクチャの 柔軟性 コスト 安価なストレージと効率的なコンピュー ティングコストの両立 • 10秒以内の検索結果: ログ検索基盤 としてストレスのないレスポンス • 集計の速さ: Dashboardでの集計表 示に対してもストレスなし • 十分なデータ取り込みスピード: ユー ザー側でのイベント発生から 10分以 内での検索が可能 • Serverlessの採用: インフラ管理の完 全な撤廃。運用工数の大幅削減 • R/Wの完全分離: 読み取りと書き込 みが干渉しないアーキテクチャ • 耐障害性: スパイクやDDoS等への耐 性が高い疎結合な設計 • S3ベースの保存: 膨大なデータ量に 対してもストレージ費用を低く維持 • 最適化されたTCO: サーバーレスによ りデータ流入が少ない時間の無駄な コストを排除 • 見積もり通りのコスト: 実績ベースで 初期試算に収まる高い予見性
13. 13 ©Cyber Security Cloud , Inc. 2026 移行時に発生したトラブル 01. Auto Loader パラメータミス 事象と原因 対応と教訓 02. ログ集計によるコスト肥⼤化 事象と原因 対応と教訓 異常動作: 1ファイルにつき「1⾏」しかデータが読み 込まれない現象が発⽣ 原因分析: テスト⽤の設定（file size関連パラメータ = 1）が残ったまま本番リリース直前まで到達。Auto Loaderが1⾏読み込みで処理を終了 対応: リリース直前にテーブルを全⾯物理削除‧再作成 し、正しいパラメータで再ロードを実施 教訓: AutoLoaderに取り込む際は正しいイベントを⼊ れる必要あり 異常動作: ランニングコストが当初予算の2倍以上に 原因分析: ログカウント処理が「全件スキャン」になっ ていた。処理時間が30分と短かったため、⾼負荷であ ることに気づけなかった。 最適化策: 「マテリアライズド‧ビュー」を採⽤。増分 計算（Incremental Refresh）により、差分のみを処理 教訓: 「早い＝安い」ではない。Sparkの並列処理によ る「⾒かけ上の速さ」の裏にあるDBU消費（スキャン 量）の確認が必要 ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪
14. 14 ©Cyber Security Cloud , Inc. 2026 まとめ AWS WAF自動運用「 WafCharm」のログ検索基盤 にDatabricksを全面採用した S3をストレージとして利用してコスト削減をしつつ、 十分に高速なレスポンスタイムが得られた Read/Write分離とサーバーレスにより、大規模な Writeヘビー負荷を効率的に運用可能になった