※ この記事はお客様に寄稿いただき、AWS が加筆・修正したものとなっています。

本稿は株式会社 NTT ドコモ モバイル空間統計 における AWS Glue を活用したリアルタイムストリーミング処理の取り組みについてご紹介します。取り組みのご紹介は全二回となっており、第一回の本編ではモバイル空間統計で Glue が採用された背景とストリーミング ETL アプリにおけるコスト削減についてご紹介します。

第二回では Glue Streaming ジョブのパフォーマンス改善についてご紹介します。

はじめに

NTTドコモは「つなごう。驚きを。幸せを。」をブランドスローガンとして掲げながら、通信事業、金融決済サービス、動画・音楽・電子書籍等配信サービス、マーケティングソリューション、あんしん系サポートなど多岐にわたる事業を展開しています。

本記事ではその中から「モバイル空間統計®」^※1での取り組みを紹介します。

「モバイル空間統計」とは、ドコモの携帯電話ネットワークのしくみを使用して作成される人口の統計情報です。1 時間ごとの人口を、24 時間 365 日把握することができます。また、「性別」「年代」「居住エリア」「国・地域」などの切り口から人口を分析することができます。エリアの特徴（分布）や人々の動き（移動）を、時間帯ごと（推移）に継続して把握できるのが最大の特徴です。具体的には、携帯電話の基地局がエリア内に存在する携帯電話の位置を周期的に把握し、その情報をもとに推計される人口統計データを生成します。この仕組みにより、特定エリアの人口や人の流れを明らかにすることが可能です。また、国内居住者だけでなく、訪日外国人の動向も把握できます。

ドコモが提供する「モバイル空間統計」は、大きなサンプルサイズによって高い信頼性を誇り、プライバシーにも配慮された安全な統計情報として評価されています。そのため、官公庁、自治体、研究機関、民間企業など、幅広い分野でマーケティングや防災計画のために活用されています。

※1 モバイル空間統計は株式会社 NTT ドコモの登録商標です。

システム概要

モバイル空間統計は、オンプレミスとクラウド(国内リージョンを利用)を融合させたハイブリッド型システムです。モバイル空間統計は集団の人数のみをあらわす人口統計情報であるため、お客様個人を特定することはできません。お客様のプライバシーを保護するために、個人識別性を除去する「非識別化処理」、ドコモの携帯電話普及率を加味して人口を拡大推計する「集計処理」、さらに少人数を除去する「秘匿処理」を適切に実施しています。上記の処理では、ビッグデータ（国内居住者については約 8900 万台^※2、訪日外国人に関しては約 1200 万台^※3の運用データ^※4）を活用しています。

モバイル空間統計では、日本全国の携帯電話ネットワークの運用データをモバイル空間統計の統計作成システムへ高い信頼性でリアルタイムに取り込んでおり、その処理には、オンプレミスサーバーを活用してきました。今回の取り組みでは、クラウドシフトの試金石として、国内居住者の分布統計等で利用するデータを統計システムへ取り込む部分（下図参照）について、PoC（概念実証）の一環としてマネージドサービスを活用することを検証しました。

処理のイメージは下図の通りです。大量の位置情報データ（ストリームデータ）を Amazon Kinesis Data Streams で取り込み、AWS Glue でリアルタイムにストリーミングデータを変換し、Amazon S3 を経由して各種統計処理システムに取り込みます。

※2 2024 年 3 月（本台数より法人名義の契約データ等を除去して推計）
※3 2019 年実績
※4 携帯電話をいつでも接続可能な状態に保つために必要なデータ

現状認識とクラウドシフトにおけるアーキテクチャ選定について

昨今のハードウェアと電気代の高騰により、オンプレミスの利用はコストリスクとなっています。データ処理の需要増が予想される中、安価にスケーラビリティを確保するため、クラウドへの移行を検討しています。特に、マネージドサービスを利用することで、メンテナンスの手間を省きながら、スケーラビリティを高めつつコストの削減が可能と考えています。マネージドサービスの選定において、他の選択肢（Amazon EMR、AWS Lambda 等）含めて検討した結果、最終的に AWS Glue Streaming（以下 Glue）^※5 を選びました。

（※5）AWS Glue Streaming は Apache Spark Streaming フレームワークを活用した、ストリーミングデータを大規模に分散処理可能なサーバレスサービスです。Kinesis Data Streams や Amazon MSK といったデータソースからストリーミングデータの ETL 処理を行い、Amazon S3 や Amazon Redshift、Amazon Aurora など様々なデータターゲットにデータの取り込みが可能になっています。

選択理由はいくつかありますが、まず、Kinesis Data Streams からのデータの取り込みに加えて、データ変換処理を実施する必要があったことから AWS Glue Streaming が有力と考えました。その上で、メンテナンス性については Glue はフルマネージドのサーバレスサービスで、インフラ管理の負担を大幅に軽減できる点が魅力でした。また、オートスケール機能についても Glue は処理負荷の変動に合わせて自動的にリソースの調整を行い、コストを抑えることができるため、長期で利用するのに適していると判断しました。

既存のプラットフォームから AWS Glue への移行を進める中でいくつかの課題が発生しました。ここではコスト削減の取り組みについて説明します。

コスト削減

Glue ストリーミングジョブにおけるコスト削減には「Glue ストリーミングの Auto Scaling の活用」と「S3のコスト削減」の二つのアプローチを取りました。それぞれについて説明します。

Glue ストリーミングの Auto Scaling 機能の活用

Glue の課金体系と Auto Scaling

Glue は東京リージョンで 1時間・1DPU あたり 0.44 USDのコスト (2025 年 3 月時点)がかかる時間従量制の課金体系となっています。そのため、処理負荷に応じて必要以上の DPU を使用しないようにすることでコスト削減につながります。Glue ストリーミングジョブにもこのようなコスト削減の要望に答えてくれる Auto Scaling 機能が備わっていますので、これを採用できるか検証を行いました。Glue ストリーミングジョブの Auto Scaling は、Job details 画面にてスケールアウトする最大のワーカー数を指定するだけで、後は Glueが自動で処理状況を見ながらスケーリングを実行します。

負荷環境における Auto Scaling の検証、効果確認

Auto Scalingが処理対象のストリームからのデータ流入量の変動に応じて適切にスケーリングするかどうかは、実際に稼働させて検証しました。商用環境相当の負荷がなければ、実際の運用において必要なDPUを見極めることが難しく、実際のスケーリングの挙動が把握することができないため、スモールデータではなく商用環境相当の負荷のある環境下で検証を実施しました。Active なワーカー数の推移は Glue のジョブメトリクスから把握できるため、ストリーミングジョブを実行中にこれを確認します。傾向としては、起動時に最大数のワーカーが立ち上がり（下図赤枠①緑線)、その後負荷状況に応じてスケールイン・スケールアウト（下図赤枠②緑線）していく形でした。

Auto Scaling の内部的な仕組みとそれを意識した対応

Glue Streaming では、ジョブメトリクスの一つである batchProcessingTimeInMs でマイクロバッチの処理時間が取得可能です。自動スケールでは設定された windowSize （マイクロバッチの起動間隔）内でジョブが完了しているかどうかを判断し自動スケーリングに活用しています。Spark アプリケーションのパフォーマンスを改善すると batchProcessingTimeInMs が短くなるため結果的に必要なワーカー数が少なくなり、コスト削減に繋がります。

そこからは第二回の記事で述べるパフォーマンスの改善を進め、稼働時間に対する平均的な単位時間あたりの DPU(DPU hours を稼働時間で割った値) が減少することを確認しました。

S3 のコスト削減

コスト削減ポイント

S3 の料金には、ストレージ容量とリクエスト数が大きく影響します。そのほかにもデータ転送量も従量課金の対象ですが、今回はこれらの要素のうち、 ストレージ容量とリクエスト数に焦点を当ててコスト削減に取り組みました。今回のシステムにおいて S3 コストが増加する原因は、S3 へ書き込むファイル数が膨大となっていることでした。このため、 PUT リクエスト数が増加し、多くの小さいファイルがストレージ容量を使用するため、データのオーバーヘッドが大きくなりました。ファイル数が膨れ上がっているのは、Spark でデータ処理をしており、出力データも分散された状態で出力されるからです。

具体的な対応内容

今回の対応では、分散されたデータを事前に結合し、出力ファイル数を減らしました。具体的には、Spark の API である coalesce() や repartition() を用いて、分割されたデータを出力直前に結合し直す対応を行いました。ファイルの結合数に関する検証を複数のパターンで行いましたが、結合数が多すぎると、結合処理自体にかかる時間が増加し、その結果マイクロバッチ処理時間が延長され 、DPUの消費量が増大することが判明しました。パフォーマンスに影響しない範囲で出力ファイル数を適切にコントロールし、S3 のストレージ容量と PUT リクエスト数を減らすことが重要です。今回の S3 コスト削減では、分割されたままのデータを書き出していた時の S3 リクエストコストに対して repartition()を用いた結合を行うことにより検証当初と比較して約 9 割ものコスト削減が達成できることが確認されました。

まとめ

本記事では AWS Glue への移行に伴うコスト削減の課題と、Glue と S3 の二つのサービスでコスト削減の対応についてご紹介しました。

Glue については、実行時間ベースの料金体系と Auto Scaling の仕組みを利用することで、パフォーマンスの向上がコスト削減につながりました。また、Glue のマネージドサービスとしての強みを活かし、データの流入量に応じてワーカー数が自動で最適な数にコントロールされてランニングコストの最小化を行うことができ、Kinesis Data Streams からのデータ流入量の増減に対する十分な柔軟性を確保することができました。

S3 については、ストレージ容量とPUT リクエスト回数の削減のため、Spark アプリケーションから分散データを結合して出力することで約 9 割のコスト削減に成功しました。

第二回では Glue ストリーミング のパフォーマンス改善についてご紹介します。

著者

株式会社 NTT ドコモ コンシューマサービスカンパニー 第一プロダクトデザイン部 マーケティングイノベーション・カスタマーサクセス 土屋 慶和

株式会社NTTドコモでクライアントサーバシステムやspモード^®の大規模NWのアーキテクト検討やスーパー販促プログラム^®の立ち上げ・プロジェクトマネージャーを担当し、現在はモバイル空間統計・di-PiNK^® DMPのプロジェクトマネージャーとして従事しています。

NTT コムウェア株式会社 NTT IT 戦略事業本部 DigitalDesign&DevelopmentCenter DataManagementPartner部門 データビジネス担当 市川 大助

NTT コムウェアにて IT アーキテクトを中心にフルスタックエンジニアとしてシステムの開発、更改、運用に従事してきました。現在はマネージャーとして、ドコモグループの様々なデータ分析業務チームを統括しています。

NTT テクノクロス株式会社 IOWN デジタルツインプラットフォーム事業部 第二ビジネスユニット 岳野裕也

NTT テクノクロスにて、Python エンジニアとしてデータ分析システムの PoC・開発等に従事してきました。現在はモバイル空間統計関連システムの開発リーダー兼リードエンジニアとしてチーム管理や技術面の課題解決等を担当しています。

アマゾン ウェブ サービス ジャパン合同会社 平川大樹

ソリューション アーキテクトとして通信業界のお客様の AWS 活用 を支援しています。