はじめに 構築が完了し、いざ疎通確認。 しかし、なぜかヘルスチェックが通らない——。（SGは空いているのにNACLで落ちていた、401が正常なのにMatcher未設定だったetc） 誰しも一度はこういう経験をしたことがあるのではないでしょうか。 かくいう私もその一人で、今回はALBのヘルスチェックに注目したいと思います。 疎通できない場合の原因は様々なところにあると思いますが、私はALBのヘルスチェックに苦しんだ経験があります。特に、WAFやOS・ミドルウェア（Apache等）、SSL/TLS等の設定が絡むと、どこでヘルスチェックが詰まっているのかを判断するのが困難になりがちです。本

本記事は 2026 年 3 月 3 日 に公開された「 Building a modern lakehouse architecture: Yggdrasil Gaming’s journey from BigQuery to AWS 」を翻訳したものです。 本記事は、AWS パートナーである GOStack の CEO 兼創設者 Edijs Drezovs、データアーキテクト Viesturs Kols、シニアデータエンジニア Krisjanis Beitans によるゲスト投稿です。 Yggdrasil Gaming は、カジノゲームをグローバルに開発・配信しており、ゲームパフォーマンス分析、プレイヤー行動分析、業界インテリジェンスのために大量のリアルタイムゲームデータを処理しています。システムの成長に伴い、デュアルクラウド環境の管理が運用負荷を増大させ、高度な分析への取り組みを制約していました。マルチクラウド運用の課題は、データ量と複雑性の増加をもたらす Game in a Box ソリューションの AWS Marketplace でのローンチを控え、特に重要になりました。 Yggdrasil Gaming は Google BigQuery から AWS 分析サービスへ移行し、マルチクラウドの複雑性を解消してスケーラブルな分析基盤を構築しました。本記事では、Yggdrasil Gaming がビジネスの成長に対応するためにデータアーキテクチャをどのように変革したかを紹介します。ビジネス継続性を維持しながら、プロプライエタリなシステムから Apache Iceberg などのオープンテーブルフォーマットへ移行する実践的な戦略を学べます。 Yggdrasil は AWS パートナーの GOStack と連携し、Apache Iceberg ベースの レイクハウスアーキテクチャ へ移行しました。レイクハウスへの移行により運用の複雑性が軽減され、リアルタイムのゲーム分析と 機械学習 が可能になりました。 課題 Yggdrasil が AWS への移行を決断した背景には、いくつかの重要な課題がありました。 マルチクラウドの運用負荷 : AWS と Google Cloud にまたがるインフラ管理が大きな運用負荷を生み、俊敏性を低下させ、メンテナンスコストを増加させていました。データチームは両環境の専門知識を維持し、クラウド間のデータ移動を調整する必要がありました。 アーキテクチャの制約 : 既存の構成では高度な分析や AI の取り組みを効果的に支えられませんでした。さらに重要なのは、Yggdrasil の Game in a Box ソリューションのローンチに、データ量の増加に対応でき高度な分析を実現できる、近代的でスケーラブルなデータ環境が必要だったことです。 スケーラビリティの制約 : オープン標準と自動化を備えた統合データ基盤がなく、効率的なスケーリングが困難でした。データ量の増加に比例してコストも増加し、大規模な分析に対応できる環境が求められていました。 ソリューション概要 Yggdrasil は AWS APN パートナーの GOStack と連携し、新しいレイクハウスアーキテクチャを設計しました。以下の図はアーキテクチャの全体像を示しています。 Yggdrasil は Google BigQuery から、 Amazon Athena 、 Amazon EMR 、 Amazon Simple Storage Service (Amazon S3)、 AWS Glue Data Catalog 、 AWS Lake Formation 、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS Lambda を活用したデータレイクハウスアーキテクチャへの移行に成功しました。マルチクラウドの複雑性を軽減しつつ、Game in a Box ソリューションや、パーソナライズされたゲームレコメンデーション、不正検知といった AI/ML に向けたスケーラブルな基盤の構築を目指した移行です。 Amazon S3、Apache Iceberg、Amazon Athena の組み合わせにより、Yggdrasil はプロビジョニング済みの常時稼働コンピューティングモデルから脱却できました。Amazon Athena のクエリ単位課金はスキャンしたデータ量のみに課金されるため、オフピーク時のアイドルコンピューティングコストがなくなります。評価フェーズで実施した内部コストモデリングでは、特にゲームローンチ、トーナメント、季節的なトラフィックによるバースト型ワークロードにおいて、コンピューティングベースのウェアハウス課金モデルと比較して分析システムコストを 30〜50% 削減できる見込みが示されました。AWS ネイティブの分析サービスを採用することで、 AWS Identity and Access Management (AWS IAM)、Amazon EKS、AWS Lambda とのネイティブ統合を通じて運用の複雑性が軽減され、分析システム全体のセキュリティ、ガバナンス、自動化が簡素化されました。 ソリューションの中心は、Amazon S3 上に構築されたレイクハウスアーキテクチャです。Amazon S3 は Iceberg テーブルを Apache Parquet 形式 で格納する耐久性とコスト効率に優れたストレージを提供します。Apache Iceberg テーブルフォーマットは、オープン標準を維持しながら ACID トランザクション、スキーマエボリューション、タイムトラベル機能を提供します。AWS Glue Data Catalog は技術メタデータの一元リポジトリとして機能し、Amazon Athena は dbt-athena やアドホックなデータ探索に使用されるサーバーレスクエリエンジンです。Amazon EMR は Yggdrasil のレガシー Apache Spark アプリケーションをフルマネージド環境で実行し、AWS Lake Formation はデータレイクの一元的なセキュリティとガバナンスを提供して、データベース、テーブル、列、行レベルでの きめ細かなアクセス制御 を実現します。 移行は段階的に進められました。 レイクハウス基盤の構築 – Amazon S3 と AWS Glue Data Catalog を使用した Apache Iceberg ベースのアーキテクチャをセットアップ リアルタイムデータ取り込みの実装 – EKS および Google Kubernetes Engine (GKE) クラスターからのリアルタイム変更データキャプチャ用に Debezium コネクタをデプロイ 処理パイプラインの移行 – AWS Lambda を使用した ETL パイプラインの再構築、レガシーデータアプリケーションの Amazon EMR への移行 変換レイヤーの近代化 – モジュール式で再利用可能なモデルのために dbt と Amazon Athena を導入 ガバナンスの有効化 – データガバナンス全体を AWS Lake Formation で管理 レイクハウス基盤の構築 移行の最初のフェーズでは、AWS 上の新しいデータレイクハウスアーキテクチャの基盤構築に注力しました。目標は、オープンデータフォーマットとサーバーレスクエリ機能を備えた、スケーラブルで安全かつコスト効率の高い環境を構築することでした。 GOStack は中央ストレージレイヤーとして Amazon S3 ベースのデータレイクをプロビジョニングし、高いスケーラビリティときめ細かなコスト管理を実現しました。ストレージとコンピューティングの分離により、取り込み、変換、分析の各プロセスを切り離し、それぞれが最適なコンピューティングエンジンを使用して独立にスケーリングできます。 データセットの相互運用性と発見性を確立するため、チームは AWS Glue Data Catalog を統合メタデータリポジトリとして採用しました。カタログは Iceberg テーブル定義を格納し、Amazon Athena や Amazon EMR 上の Apache Spark ワークロードなどのサービス間でスキーマにアクセスできるようにします。バッチとストリーミングの両方を含むほとんどのデータセットがここに登録され、レイクハウス全体で一貫したメタデータの可視性を実現しています。 データは Amazon S3 上の Apache Iceberg テーブルに格納されます。Iceberg はオープンテーブルフォーマット、ACID トランザクションサポート、柔軟なスキーマエボリューション機能を理由に選定されました。Yggdrasil は、一貫した財務レポートと不正検知のための ACID トランザクション、急速に変化するゲームデータモデルに対応するスキーマエボリューション、規制監査要件に沿ったタイムトラベルクエリを必要としていました。 GOStack はカスタムのスキーマ変換・テーブル登録サービスを構築しました。スキーマ変換・テーブル登録サービスはソースシステムの Avro スキーマを Iceberg テーブル定義に変換し、raw レイヤーテーブルの作成とエボリューションを管理します。スキーマ変換とテーブル登録を直接制御することで、メタデータがソースシステムと一貫性を保ち、取り込みニーズに沿った予測可能でバージョン管理されたスキーマエボリューションを実現しています。 初期セットアップでは以下のコンポーネントを構成しました。 Amazon S3 バケット構造の設計 : データライフサイクルのベストプラクティスに沿ったマルチレイヤーレイアウト (raw、curated、analytics ゾーン) を実装しました。 AWS Glue Data Catalog の統合 : Athena のパフォーマンスに最適化されたパーティショニング戦略でデータベースとテーブルスキーマを定義しました。 Iceberg の設定 : ストレージ効率とクエリの柔軟性のバランスを取るため、バージョニングとメタデータ保持ポリシーを有効化しました。 セキュリティとコンプライアンス : AWS Key Management Service (AWS KMS) による保存時の暗号化を設定し、AWS IAM と Lake Formation によるアクセス制御を適用し、最小権限の原則に従った Amazon S3 バケットポリシー を実装しました。 以前の GCP 構成の再設計により、コストパフォーマンスが向上しました。Yggdrasil は、より直接的なイベント駆動パイプラインへの移行を通じて、取り込みと処理のコストを約 60% 削減し、運用負荷も軽減しました。 リアルタイムデータ取り込みの実装 レイクハウスアーキテクチャの構築後、次のステップでは Yggdrasil のオペレーショナルデータベースからレイクハウスの raw データレイヤーへのリアルタイムデータ取り込みの実現に注力しました。目的は、トランザクションの変更を発生時にキャプチャして配信し、下流の分析やレポートに最新の情報を反映させることでした。 GOStack は Debezium Server Iceberg をデプロイしました。これは変更データキャプチャ (CDC) を Apache Iceberg テーブルに直接統合するオープンソースプロジェクトです。Amazon EKS 上に Argo CD アプリケーションとしてデプロイされ、Argo の GitOps ベースモデルにより再現性、スケーラビリティ、シームレスなロールアウトを実現しています。 Debezium Server Iceberg のアーキテクチャは効率的な取り込み経路を提供します。ソースシステムの アウトボックステーブル からデータ変更を直接ストリーミングし、AWS Glue Data Catalog に登録され Amazon S3 に物理的に格納された Apache Iceberg テーブルに書き込みます。中間ブローカーやステージングサービスが不要です。Iceberg テーブルフォーマットでデータを書き込むことで、取り込みレイヤーはトランザクション保証と Amazon Athena による即時クエリ可用性を維持しました。 Yggdrasil のソースシステムは Avro レコードを含むアウトボックスイベントを発行していたため、チームは Debezium 内にカスタムのアウトボックスから Avro への変換を実装しました。アウトボックステーブルには 2 つの主要コンポーネントが格納されていました。 Avro スキーマ定義 各レコードの JSON エンコードされたペイロード カスタム変換モジュールは Avro スキーマ定義とペイロードを有効な Avro レコードに結合してから、ターゲットの Iceberg テーブルに永続化しました。Avro からの変換によりスキーマの忠実性が保たれ、下流の処理ツールとの互換性が確保されました。 受信した変更イベントを動的にルーティングするため、チームは Debezium のイベントルーター 設定を活用しました。各レコードはトピックとメタデータルールに基づいて適切な Apache Iceberg テーブル (Amazon S3 上) にルーティングされ、テーブルスキーマとパーティショニングは AWS Glue 側で管理され、レイクハウスのデータ編成標準との安定性と整合性が維持されました。 Debezium と Iceberg の組み合わせにより、 低レイテンシーの取り込み と データベースアウトボックス から S3 ベースの Iceberg テーブルへのほぼリアルタイムの エンドツーエンドストリーミング が実現しました。チームは Amazon EKS 上で Helm チャートを使用し、 GitOps モデル で Argo CD 経由でデプロイすることで、完全に宣言的でバージョン管理された運用を実現しました。ACID 準拠の Iceberg 書き込みにより、部分的に書き込まれたデータが下流の分析を破損することはありません。モジュール式の変換ロジックにより、取り込みパイプラインを再設計することなく、将来的に新しいソースシステムやイベントフォーマットへの拡張が可能です。 Debezium Server による高速なリアルタイムデータ取り込みは、GOStack が暫定的なアーキテクチャと位置付けています。長期的には、取り込みパイプラインは Amazon Managed Streaming for Apache Kafka (Amazon MSK) を中央イベントバックボーンとして使用する形に進化する予定です。Debezium コネクタがプロデューサーとして変更イベントを Apache Kafka トピックに発行し、 Apache Flink アプリケーションがデータを消費、処理して Iceberg テーブルに書き込みます。 Kafka ベースのストリーミングアーキテクチャへの計画的な進化により、Yggdrasil のレイクハウスは現在スケーラブルでコスト効率が高いだけでなく、将来にも対応できます。組織の成長に伴い、より高度なストリーミング分析や幅広いデータ統合シナリオをサポートできる構成です。 処理パイプラインの移行 リアルタイムデータ取り込みの確立後、GOStack はデータ変換レイヤーの近代化に注力しました。目標は変換ロジックの簡素化、運用負荷の軽減、新しい AWS ベースのレイクハウス内での分析ワークロードのオーケストレーション統合でした。 GOStack は GCP からの迅速かつ低リスクな移行を支えるため、Yggdrasil の一部のデータパイプラインにリフトアンドシフトアプローチを採用しました。ファイル共有、SharePoint、Google Sheets、各種サードパーティ API からのデータ抽出を担っていた軽量な Cloud Run functions は、AWS Lambda で再実装されました。再実装した Lambda 関数は同じ外部システムと連携し、データを直接 Iceberg テーブルに書き込みます。 より複雑な処理については、 Dataproc 上で実行されていた Apache Spark アプリケーションを最小限のコード変更で Amazon EMR に移行しました。既存の変換ロジックを維持しながら、EMR のマネージドスケーリング機能と AWS でのコスト管理の向上を活用できるようになりました。 今後、移行したパイプラインは段階的にリファクタリングされ、EKS クラスター上のコンテナ化されたワークフローに統合され、 Argo Workflows で完全にオーケストレーションされる予定です。段階的な移行により、Yggdrasil はワークロードを迅速に AWS に移行して GCP リソースを早期に廃止しつつ、データシステムの継続的な改善と近代化の余地を残しています。 最後に、以前 BigQuery のストアドプロシージャやスケジュールクエリとして存在していた多くの分析変換は、dbt-athena で実行されるモジュール式の dbt モデルとして再構築されました。dbt への移行により変換ロジックの透明性、保守性、バージョン管理が向上し、開発者体験と長期的なガバナンスの両方が改善されました。 変換レイヤーの近代化 取り込みパイプラインの AWS への移行が完了し、GOStack は Yggdrasil の分析変換の簡素化と近代化に注力しました。以前のストアドプロシージャ駆動のアプローチを再現するのではなく、保守性、リネージの可視性、オーケストレーション、長期的なガバナンスの向上のために dbt を使用して変換レイヤーを再構築しました。再設計の一環として、いくつかのデータモデルは新しいレイクハウスアーキテクチャに合わせて再構成されました。最も大きな取り組みは、重要な Spark ベースの財務変換を SQL 駆動の dbt モデルセットに書き換えることでした。SQL 化によりロジックがレイクハウス設計に沿うだけでなく、長時間稼働する Spark クラスターが不要になり、運用とコストの削減につながりました。レガシーウェアハウスに代わるキュレーションデータレイヤーでは、GOStack は多数のスケジュールクエリとストアドプロシージャを構造化された dbt モデルに統合しました。分析スタック全体で標準化されバージョン管理された変換と明確なリネージが提供されます。 オーケストレーションも簡素化されました。以前は Spark ワークロード用の Apache Airflow と分析変換用の スケジュールクエリ に分かれており、運用上の摩擦と依存関係のリスクが生じていました。新しいアーキテクチャでは、Amazon EKS 上の Argo Workflows が dbt モデルを一元的にオーケストレーションし、変換ロジックを単一のワークフローエンジンに統合しています。現在ほとんどの変換はタイムベースのスケジュールで実行されていますが、 Argo Events によるイベント駆動実行もサポートしており、変換レイヤーの進化に合わせてトリガーベースのワークフローを段階的に採用できます。 統合オーケストレーションフレームワークのメリットは次のとおりです。 一貫性 : 取り込みと変換にまたがるデータワークフローを単一のオーケストレーションレイヤーで管理。 自動化 : イベント駆動の dbt 実行により手動スケジューリングが不要になり、運用負荷が軽減。 スケーラビリティ : Argo Workflows は EKS クラスターとともにスケーリングし、並行する dbt ジョブをシームレスに処理。 可観測性 : 一元化されたログとワークフローの可視化により、ジョブの依存関係とデータの鮮度の把握が向上。 dbt と Argo Workflows の導入を通じて、Yggdrasil はデータレイクとウェアハウスを、オープンデータフォーマット、サーバーレスクエリエンジン、モジュール式の変換ロジックを活用したレイクハウスアーキテクチャに統合しました。dbt と Athena への移行は運用を簡素化しただけでなく、データ環境全体でのイテレーションの高速化、ガバナンスの簡素化、開発者の生産性向上への道を開きました。 レイクハウスのパフォーマンス最適化 パフォーマンスチューニングは継続的な取り組みですが、変換の再設計の一環として、GOStack は Athena クエリの高速化とコスト効率の向上のためにいくつかのパフォーマンス調整を行いました。Apache Iceberg テーブルは ZSTD 圧縮 の Parquet で格納され、優れた読み取りパフォーマンスと Athena がスキャンするデータ量の削減を実現しています。 パーティショニング戦略も Iceberg のネイティブパーティショニング を使用して実際のアクセスパターンに合わせました。raw データゾーンは取り込みタイムスタンプでパーティショニングされ、効率的な増分処理を実現しています。キュレーションデータはプレイヤーやゲーム識別子、日付ディメンションなどのビジネス駆動のパーティションキーを使用し、分析クエリの最適化に役立てています。パーティショニング設計により、Athena は不要なデータを刈り込み、関連するパーティションのみを一貫してスキャンできます。 Iceberg のネイティブパーティショニング機能 (バケッティングやタイムスライスなどの変換を含む) は、従来の Hive パーティショニングパターンに代わるものです。Iceberg はメタデータレイヤーでパーティションを内部的に管理するため、Glue や Athena のパーティション構成がすべて適用されるわけではありません。Iceberg のネイティブパーティショニングに依存することで、レガシーな Hive の動作を導入することなく、レイクハウス全体で予測可能なプルーニングと一貫したパフォーマンスが得られます。 リアルタイム取り込みで生成される大量の小さなファイルに対処するため、GOStack は AWS Glue Iceberg コンパクション を有効化しました。小さな Parquet ファイルを自動的に大きなセグメントにマージし、手動介入なしでクエリパフォーマンスの向上とメタデータ負荷の削減を実現しています。 ガバナンスの有効化 チームはレイクハウスのキュレーションゾーンの主要なガバナンスレイヤーとして AWS Lake Formation を採用し、 Lake Formation ハイブリッドアクセスモード を活用して、既存の IAM ベースのアクセスパターンと並行してきめ細かな権限を管理しています。ハイブリッドアクセスモードは、レガシー権限や内部パイプラインロールの完全な移行を強制することなく Lake Formation を段階的かつ柔軟に採用できるため、Yggdrasil の段階的な近代化戦略に最適です。 Lake Formation は一元的な認可を提供し、データベース、テーブル、列、そして Yggdrasil にとって特に重要な行レベルの権限をサポートしています。行レベルの権限は、同社のマルチテナント運用モデルで特に重要です。 ゲーム開発パートナー は 自社のゲームに関するデータとレポートのみ にアクセスでき、パートナー契約に沿ったセキュリティとコンプライアンスを実現しています。 Yggdrasil のシステムと統合する iGaming オペレーター は、キュレーションされた Iceberg テーブルに基づくレポートツールを通じて、 自社データに限定した運用・財務インサイト を自動的に受け取ります。 Lake Formation ハイブリッドアクセスモードにより、テナント固有の行レベルアクセスポリシーが Amazon Athena、AWS Glue、Amazon EMR 全体で一貫して適用され、既存の IAM ベースのワークロードに破壊的な変更を加えることはありません。Yggdrasil は外部コンシューマーに対して適切なガバナンスを実装しつつ、内部運用の安定性と予測可能性を維持できました。 内部的には、Lake Formation は分析チームと BI ツールにキュレーションデータセットへの対象を絞ったアクセスを付与するためにも使用されています。シンプルですが一元管理されており、一貫性の維持と管理負荷の軽減に役立っています。 取り込みと変換のワークロードについては、チームは引き続き IAM ロールとポリシー を使用しています。Debezium、dbt、Argo Workflows などのサービスは raw および中間ストレージレイヤーへの広範だが制御されたアクセスを必要とし、IAM は内部パイプラインパスに Lake Formation を関与させることなく、最小権限で必要な権限を付与する簡潔なメカニズムを提供します。 Lake Formation をハイブリッドアクセスモードで採用し、内部サービスには IAM を組み合わせることで、Yggdrasil はセキュリティと運用の柔軟性を両立するガバナンスモデルを確立しました。ビジネスの成長に伴い、レイクハウスを安全にスケーリングできる構成です。 成果とビジネスへの影響 Amazon Athena、Amazon S3、AWS Glue Data Catalog 上に構築された新しいレイクハウスは、プレイヤー行動モデリング、予測的なゲームレコメンデーション、不正検知といった高度な分析や AI/ML のユースケースを支えています。 最適化されたレイクハウス設計により、Yggdrasil は新しい分析ワークロードやビジネスユースケースを迅速にオンボードでき、測定可能な成果を実現しています。 運用の複雑性の軽減 : AWS 分析サービスへの統合による簡素化 コスト最適化 : データ処理コストの 60% 削減 データ鮮度の向上 : 分析結果のレイテンシーが 75% 改善 (2 時間から 30 分に短縮) ガバナンスの強化 : AWS Lake Formation のきめ細かな制御の活用 将来に対応したアーキテクチャ : オープンフォーマットとサーバーレス分析の活用 まとめ Yggdrasil Gaming の移行事例は、プロプライエタリな分析システムからオープンで柔軟なレイクハウスアーキテクチャへの移行を成功させる方法を示しています。 AWS Well-Architected Framework の原則に基づいた段階的なアプローチにより、Yggdrasil はビジネス継続性を維持しながらデータニーズに対応する基盤を構築しました。 Yggdrasil の移行から、レイクハウス構築に役立つ教訓が得られました。 現状を評価する : 既存のデータアーキテクチャの課題を特定し、近代化の明確な目標を設定します。 小さく始める : AWS 分析サービスを使用したパイロットプロジェクトから始め、特定のユースケースでレイクハウスアプローチを検証します。 オープン性を重視した設計 : Apache Iceberg などのオープンテーブルフォーマットを活用し、柔軟性を維持してベンダーロックインを回避します。 段階的に実装する : Yggdrasil と同様の段階的な移行戦略に従い、価値の高いワークロードを優先します。 継続的に最適化する : Amazon Athena のパフォーマンスチューニング手法を活用し、効率の最大化とコストの最小化を図ります。 レイクハウスアーキテクチャ構築に関する詳細は、 Amazon SageMaker のレイクハウスアーキテクチャ を参照してください。 著者について Edijs Drezovs Edijs は、AWS パートナーの GOStack の CEO 兼創設者で、クラウドネイティブインフラストラクチャ、データシステム、分析アーキテクチャの近代化を専門としています。12 年以上にわたり、複雑なクラウド変革とデータエンジニアリングの取り組みを推進してきました。 Viesturs Kols Viesturs は、GOStack のデータアーキテクトで、レイクハウスアーキテクチャとリアルタイム分析に深い専門知識を持っています。Yggdrasil Gaming の AWS 分析サービスへの移行の技術実装をリードし、Apache Iceberg とストリーミングデータシステムを専門としています。 Krisjanis Beitans GOStack のシニアデータエンジニアで、レイクハウスアーキテクチャ、Apache Iceberg、Amazon Athena、dbt ベースの変換フレームワークを専門としています。Yggdrasil Gaming の AWS への移行では、Iceberg テーブル構造の設計、Athena パフォーマンスの最適化、dbt 駆動の変換パイプラインの実装を通じて分析レイヤーを再構築しました。 Alvaro Guerrero Alvaro は、AWS のソリューションアーキテクトで、AWS 分析サービスを専門とし、お客様のクラウドソリューション構築を支援しています。 Aleksandra Zgnilec Aleksandra は、AWS のアカウントエグゼクティブで、ベッティング＆ゲーミングのお客様のクラウドおよびビジネス変革を支援しています。 Zahi Njeim Zahi は、AWS のビジネスデベロップメントマネージャーで、ベッティング＆ゲーミング、メディア、エンターテインメント、ゲーム、スポーツを担当しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

こんにちは、イノベーションセンターのNetwork Analytics for Security（NA4Sec）プロジェクトの山門です。 この記事では、2025年12月18日-19日に開催されたカンファレンスNCA Annual Conference 2025へ登壇してきた模様を紹介します。 組織におけるドメイン名の「終活（廃棄）」に伴うリスクをテーマに、利用終了ドメイン名に対する2.3億件のログ分析結果を説明しました。ECS（EDNS-Client-Subnet）を用いた分析により、「利用終了後も攻撃・スキャンが絶えない」という実態や、観測行為自体が攻撃を誘発する「観察者効果」といった興味深い知見を解説します。 NCA Annual Conferenceとは NA4Secプロジェクトとは 講演内容 ドメイン名の「終活」という課題 ECSの活用 観測・分析環境 分析結果 結論 おわりに NCA Annual Conferenceとは NCA Annual Conferenceは、一般社団法人 日本シーサート協議会が主催する年次カンファレンスです。 本イベントは、企業や組織内でセキュリティインシデントに対応するCSIRT（Computer Security Incident Response Team）のメンバーが一堂に会する、国内でも大規模なコミュニティイベントの1つです。最新のサイバー攻撃動向や技術情報の共有にとどまらず、組織の枠を超えたCSIRT間の連携や、各組織が抱える課題解決のヒントを得ることを目的として開催されています。 特に、現場の実務者による知見の共有やワークショップを通じた「共創」の精神が重視されており、日本のサイバーセキュリティ対応能力の底上げを図る重要な場として位置づけられています。 NA4Secプロジェクトとは 私の所属するNA4Secプロジェクトについて紹介させてください。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指すプロジェクトです。 NTTドコモビジネスグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ(攻撃者の管理するマルウェアや C&Cサーバ など)を追跡しています。 講演内容 NA4Secプロジェクトの神田と、私（山門）の2名で、「『君の名は』と聞く君の名は。」というタイトルで、安易なドメイン名放棄に潜むリスク、観測から得られた知見、そして新しい管理アプローチについて講演しました。 登壇資料はこちらにアップロードしておきましたので、よろしければご覧ください。 ドメイン名の「終活」という課題 企業がかつて利用していたドメイン名を悪意を持つ第三者が取得した場合、フィッシングサイトに悪用されたり、ブランドイメージを失墜させたり、Search Engine Optimization（SEO）を悪用したりできるため、攻撃者にとって価値があります。そのためドメイン名の放棄後に第三者によって悪用される「ドロップキャッチ」のリスクが存在します。実際に「ドコモ口座」など複数事例でも問題が顕在化しています。 その対策として、当社ではドメイン名の永年保有ポリシーを策定していますが、「いつまでも持ち続ける」以外の選択肢を探るべく、利用終了ドメイン名に対する「アクセス実態」の観測と分析しています。 ECSの活用 今回発表した中では、「EDNS-Client-Subnet（ECS）」の挙動を調査しました。ECSとはRFC 7871で定義されており、DNS問い合わせにクライアントのIPサブネット情報を付加し、権威DNSサーバがユーザの地理的・ネットワーク的な位置をより正確に把握できるようにする仕組みです。DNSリゾルバの裏に存在する、実際に名前解決しようとしたクライアントのサブネットを意味します。 観測・分析環境 ログ収集環境を下図に示します。 利用終了したドメイン名宛のDNSクエリログ、Webアクセスログ、受信メール・DMARCレポートの3点をAWS上で収集およびJSON化し保管しています。今回はその中のDNSクエリログとWebアクセスログの2点に注目しています。 今回は、NA4Secプロジェクトの利用終了ドメイン名関連の施策の中で、初めてDNSクエリログとWebアクセスログを突合させることでアクセスの正体と目的の分析を試みました。DNSクエリログのECSをキーにWebアクセスログの送信元IPアドレスと突合し、DNSクエリログとWebアクセスログのタイムスタンプの差に着目しました。タイムスタンプの差が小さいと、当該ECSがWebアクセスのためにDNS名前問い合わせをした可能性が高いためです。 分析結果 以下のグラフは、各日付のDNSクエリのカウントをその日調査対象になっていたドメイン名の数で平均した値の遷移です。 以下の事柄が、分析により判明しました。 ログ分析から、利用終了後も大量のクエリが継続している 約2.3億件のDNSクエリログのうちGoogle / Cisco / Akamai など大規模DNSの resolver-ip からのクエリが9割以上を占める DNSで名前問い合わせ直後（24時間以内）に Webへアクセスしてきたものを調査した結果112リクエスト中、90件以上が攻撃またはスキャンである WordPress や Apache の既知脆弱性を狙ったアクセスが多数確認されました。Shellshock（CVE-2014-6271）、WebLogic RCE（CVE-2017-10271）、MobileIron RCE（CVE-2020-15505）、D-Link NAS のバックドア脆弱性（CVE-2024-3272）など、古い脆弱性も依然として集中的に狙われている 今回の分析から明らかになった問題の1つは、観測行為そのものがアクセスを誘発してしまうというジレンマです。 DNSレコードを返すことでサブドメイン探索が行われ、HTTP応答を返すことで脆弱性スキャンが始まるなど、観測行為が攻撃者を誘引し、その行動を変えてしまっている実情が見えてきました。 いわば「観察者効果」です。 その一方で、DNSクエリログ・Webアクセスログ単体だけではアクセスの目的や意図、アクセス元の素性を推し量ることは難しく、適切なアクションに結び付けることは困難です。 より正確に状況を把握し、利用終了ドメイン名に残存するリスクへ効果的に対応するためには、不要な「ノイズ」を除去して、本来残っているアクセスを見分けることが重要となります。 結論 これらの調査から得られた知見として下記のようにまとめられます。 DNSクエリログの一部の送信元のアクセス意図は攻撃やスキャンであることが、今回初めてDNSクエリログとWebアクセスログの2つを突合することで判明した 利用終了ドメイン名であっても攻撃・スキャンは日常的に行われる（今回の調査の対象は24年8月以前に利用終了したドメイン名） 2つのログ突合により、名前問い合わせをしてきた送信元のアクセス意図の理解が高まる（今回の調査では大半がスキャンや攻撃） おわりに 月日が経ってもアクセス数は減らず、「減少＝ドメイン名を安全に手放せる」の単純な判断材料にはならないことがわかりました。 また、現用ドメイン名にも同様の脅威が常に存在するため、サイバーハイジーン（基本的なサイバーセキュリティ対策を平時より実施すること）の徹底が不可欠だと言えます。 講演後の反応として、「同じくドメイン名の終活に悩みを抱えているが、運用・廃止ポリシーはまだ策定していない。今回の講演は、月日が経ってもアクセス数が減らない点や、曖昧な運用が悪意ある第三者によるドロップキャッチの原因になる点など、改めて組織内での運用ポリシーを策定するためのきっかけになった」というご意見もいただきました。 本カンファレンスを通じて、最新の技術動向や脅威情報を習得できたことはもちろんですが、同じ課題を持つ他社CSIRTとの「共創」のネットワークを再確認できたことが最大の収穫でした。一度取得したドメイン名の管理という地味ながらも避けては通れない課題が、いかに多くの実務者の皆さまの共通の悩みとなっているかを痛感しました。 「いつ、どうやってドメインを手放すべきか」という問いに対する最適解はまだありません。しかし、今回ご紹介したログ分析の手法や観測結果が、皆さまの組織における運用ポリシー策定の一助となれば幸いです。 NA4Secプロジェクトでは、今後もこうした観測と分析を継続し、インターネットをより安心・安全なものにするための知見を発信してまいります。 記事を最後までお読みいただきありがとうございました。