トップ > セキュリティ > BigQueryで毎月数十TB増えるセキュリティログのストレージコストを60％削減した方法

BigQueryで毎月数十TB増えるセキュリティログのストレージコストを60％削減した方法

セキュリティ ビッグデータ

サムネイル

はじめに

こんにちは。プラットフォーム開発本部 不正対策チームで開発や調査・運用をしている窪内です。

DMMのプラットフォーム全体像

DMMでは、多種多様な機能をプラットフォームとして提供しています。具体的には、認証や認可、決済、会員情報、ポイント管理、カスタマーサポート、さらには不正対策など、幅広いサービスが含まれています。これらの機能は、DMMのさまざまな事業部やプラットフォーム内の他サービスをはじめ、外部パートナー企業に対してAPIとして公開されています。

各チームは、それぞれが担うユースケースに合わせてAPIを追加・拡張しており、DMM全体で新機能の開発や既存機能の改善を継続的に進めています。

不正対策チームは、DMMプラットフォームを不正利用による被害から守るために、ログなどをもとに兆候を検知し、調査・対策につなげる仕組みを開発・運用しています。

本記事の概要

これまで不正対策チームでは、主にログインや購入といった特定の機能を保護対象としてきました。しかし現在では、API Gatewayを通じてDMMプラットフォーム全体を脅威から守る仕組みを構築しています。基本的なコンセプトは、日々のアクセスログを継続的に蓄積・分析し、平常時と比べて違和感のある兆候を早期に見つけて調査につなげる、というシンプルなものです。

しかし、この仕組みを実現するためには、すべてのログを精査する必要があり、膨大なデータを効率よく扱うことが求められます。そこで私たちはGoで構築したシステムと、そのデータストアとしてBigQueryを活用しています。 今回ご紹介するのは、大量のログをBigQueryに保存・分析するうえで直面したコストの課題と、それに対してどのような解決策を講じたのかという内容です。

API Gatewayの大規模トラフィックログの長期保管と分析体制の構築

API Gatewayでは日々膨大なトラフィックを処理しており、そのログは1か月単位で数百億件、データ量にして数十TBに達します。これらのログは、異常を検知するために保存され、随時分析される仕組みが整えられています。さらに、新しい分析手法を実装した際には、過去のログにさかのぼって再度分析できるようにしており、インシデント発生時には生ログへ迅速にアクセスしてフォレンジック調査を実施できる運用体制を整備しています。

このため、ログは長期間にわたって保管する必要があります。頻繁に参照する必要はないものの、必要なときにはスムーズにアクセスできるようにすることで、万が一のインシデント発生時に迅速な対応や詳細な調査が可能になります。

BigQueryによるログ蓄積と加工

ログの保存先としてのBigQueryのメリット

私たちは、大量のログを保存する手段としてBigQueryを選択しました。これは、次のような要素を考慮した結果です。

  • Google Cloudを利用しているチームであること
    DMMの不正対策チームはすでにGoogle Cloudを活用しており、その延長でBigQueryを選択するのは自然な流れでした。

  • 不正対策チームでの利用実績が豊富であること
    以前からBigQueryを使ってログ分析を行っていた経験があり、膨大なデータ量を扱うDWHとしての性能に信頼を寄せていました。

  • 大量のデータに対して複雑なクエリを実行しても高速な結果が得られること
    大規模なデータセットに対して複雑な分析をする際も、BigQueryの分散処理によって短時間で結果を得ることができます。

また、すべてのログデータを分析システム内で直接扱うのは現実的でないため、BigQueryを利用して事前に集計や加工をしたうえで分析に回す方法を採用しています。これにより、システムそのものはシンプルな構成を維持しつつ、複雑な分析を現実的な時間内に行うことができています。

ログの分析フロー

ログはまずGoで実装した自前のETL専用システムに渡し、次のような加工処理を実施します。

  1. デバイス分類や関連情報の収集
    アクセス元デバイスの種別を判定し、関連するユーザー情報と結びつけます。

  2. アクセス先APIの特定
    アクセスされたAPIエンドポイントを特定し、後段の分析に必要な識別情報を付与します。

  3. 分析用テーブルへの保存
    加工を終えたログを分析用テーブルに保存し、分析に最適なデータ構造へ整えます。

保存した分析用データは、その後分析システムから随時参照して分析されます。分析の結果、不審な挙動や重大なインシデントが疑われる場合は、Slackなどのコミュニケーションツールに通知を送ることで、チームが迅速に調査を行える体制を整えています。

ストレージコストの問題

ストレージ料金の問題発生

1か月あたり数十TBにも及ぶログデータを蓄積しているため、日々の蓄積が進むにつれてストレージコストが増大していく問題が発生しました。初期の段階で試算する際に、ログが累積していくことで生じる長期的なコストについて十分な検討ができていなかったことが原因のひとつです。とくに問題視されたのは、API Gatewayから出力される生のログでした。分析用に加工されたテーブル自体はそれほど大きくないものの、API Gatewayの生ログをそのまま保存する部分においては、コスト削減の必要性が高まっていました。

対策としては、以下のような方法が検討されました。

  • ログの内容を削る
    分析に不要な情報を取り除くことでデータ容量を減らす方法です。すでにある程度実施しており、これ以上削れる箇所がほとんど残されていない状況でした。

  • 保存するストレージの変更
    たとえばZstandardなどの圧縮形式を用いてオブジェクトストレージに保存する、といった方法も検討されました。圧縮によるデータ容量の削減に加え、オブジェクトストレージの料金体系を活用することでコストを抑えられる可能性があります。

従来のストレージモデルによる課題

BigQueryのコスト内訳を確認すると、Analysisと呼ばれるクエリ実行時の料金は想定の範囲内でした。しかし、Active Logical StorageやLong Term Logical Storageといった、データを保存していることに対して発生するストレージ料金が想定以上に大きくなっていたのです。大量のログを長期間にわたって保管し続ける必要があるため、この部分のコストが大きな課題となっていました。

BigQueryストレージモデルの変更

Physical Storage（物理ストレージ）への移行

調査を進めた結果、BigQueryには2種類のストレージ課金体系があるとわかりました。 1つは「Logical Storage」で、もう1つは「Physical Storage」です。通常はLogical Storageがデフォルトの課金体系となっており、論理バイト（圧縮前のサイズ）を基準に料金が発生します。 一方、Physical Storageはデータが圧縮された状態で課金されるモデルであり、Logical Storageに比べると1GiBあたりの課金単価は高めですが、圧縮率の高いデータであればコストを大幅に抑えられる可能性があります。

私たちが扱っているAPI Gatewayの生ログは、もともと一定の圧縮率を期待できる形式であることが推測されました。そのため、Physical Storageへの移行によってデータサイズを削減でき、結果としてストレージ料金を抑えられるのではないかと考えました。幸い、Google CloudのドキュメントにはLogical StorageからPhysical Storageへ移行した場合の料金差を試算するためのクエリ例が掲載されており、調査はスムーズに進みました。その結果、データ全体を見ても、元のおよそ20％程度のサイズまで圧縮できることがわかりました。これにより、コスト削減が大いに期待できます。

移行プロセスと運用上の留意点

移行にあたり、BigQueryのストレージモデルはデータセット単位で設定できることがわかりました。そこで、次のような手順を踏みました。

  1. 新しいデータセットをPhysical Storageとして作成する
    まず、既存のLogical Storageを利用するデータセットとは別に、新しくPhysical Storage用のデータセットを用意しました。

  2. 対象テーブルを段階的に移動する
    すべてのテーブルを一度に移行すると、もし想定外のコスト増が起きた場合にリスクが大きいため、まずはシステムで分析対象外となっているテーブルから順次Physical Storageデータセットへ移行しました。こうすることで、ストレージコストの実際の削減効果を小さな範囲から検証しつつ、問題発生時にも影響範囲を抑えられるようにしました。

  3. 分析システムとの連携・切り替え
    分析対象のテーブルについては、分析システム側のクエリ参照先を順次切り替えていく必要があります。切り替えタイミングを慎重に見極めることで、運用への影響を最小限に抑えています。

現在は、分析に頻繁に利用されるアクティブなテーブルを除いた多くのテーブルがPhysical Storageへ移行を完了しています。今後はシステムを改修するタイミングに合わせて、残りのテーブルもPhysical Storageを利用するデータセットで管理されるようにする予定です。これにより、大量のログを長期的に保管する必要がある状況でも、ストレージコストの1日あたりの金額を60％以上削減しつつ運用を継続できる見込みです。

コスト削減の成果と今後の展望

コスト削減のインパクト

Physical Storageへの移行を進めた結果、ストレージにかかる1日あたりのコストを移行前後で比較したところ、60％以上の削減が確認できました。

ストレージコストの推移 上図は、BigQueryのストレージモデルをLogical Storage（青・緑）からPhysical Storage（赤・オレンジ）へ移行した際の、1日あたりのストレージコスト推移です。移行前（左側）に比べて移行後（右側）は、Physical Storageを採用したことにより大幅にストレージコストが削減されていることがわかります。

これにより、従来の予算の範囲では保存しきれなかった追加データの収集・保管が可能となり、プロジェクトとして新たな施策に活用できる余力が生まれました。

今後の取り組み

今回の施策によって、ストレージコストを大幅に抑制することには成功しました。しかし、データが累積していく事実は変わらないため、以下のような点については今後の課題としています。

  • 適切なログの保存期間の検討
    どの程度の期間データを保持すべきか、セキュリティリスクやフォレンジック調査とのバランスを見極める必要があります。

  • より高効率なデータ構造への移行
    生ログと分析用ログをどう仕分け、どのような形で保存すべきか、より効率的なデータモデルを検討することで、さらにコストを抑えられる可能性があります。

現在はログを「ひとまず」保存している状況ですが、今後は生ログの用途や重要度を整理し、必要な情報を最適な形で保管する仕組みを整えていく予定です。これにより、セキュリティを維持しつつ、コスト面でも持続可能な運用を実現できると考えています。

まとめ

以上のように、私たちはAPI Gatewayを通じて膨大なログを収集し、それらを活用した異常検知の取り組みを進めています。しかし、1か月あたり数十TBという巨大なデータを長期間保管し続けるためには、コスト面が大きな課題となっていました。そこでBigQueryのストレージモデルをLogical StorageからPhysical Storageに移行し、圧縮率を高めて実際に保存するデータ量を削減することで、大幅なコスト削減に成功しました。

この結果、60％以上のコスト削減に成功し、ストレージ費用が予算を圧迫する状態を解消できました。これにより、今後はより多くのデータを蓄積・分析できる余力が生まれました。加えて、新たな施策や機能開発に予算を投資できるようになりました。一方で、データ量の累積は今後も続いていくため、適切なログの保存期間や最適化されたデータ構造への移行など、取り組むべき課題はまだ残されています。

今後も「必要な情報を必要な分だけ効率的に保存し、迅速に分析する」という方針を継続しながら、DMM全体のサービス品質とセキュリティをさらに高めていきたいと考えています。私たちの事例が、同様の課題に取り組む皆様の参考になれば幸いです。

おわりに

DMMでは最高水準のセキュリティ体制を目指して、不正対策チームをはじめとするさまざまなチームが日々努力を重ねています。私たちのチームでは、技術的な挑戦や新しい取り組みに積極的に取り組んでおり、共に成長しながらDMMのサービスを支えていく仲間を募集しています。興味をお持ちの方は、ぜひ採用情報をご覧ください。

dmm-corp.com