編集部からのお知らせ
記事PDF集:官民意識のゼロトラスト
電子インボイスの記事まとめ

統合データ分析基盤にAWSとGoogle Cloudを併用するNTTドコモが目指すもの

阿久津良和

2021-09-08 07:30

 グーグル・クラウド・ジャパンは、9月7日からオンラインで「Data Cloud Summit」を開催。NTTドコモが自社データ分析基盤として「Google Cloud」を採用したことを受けて、概要などを紹介した。

 NTTドコモは、通信事業とスマートライフ事業でのデータ分析基盤を整備している。近年は対象データ量が1日あたり50TB以上になるなど増加しており、基盤構成の最適化を目標としてGoogle Cloudの利用を検証、2021年7月に本格導入した。同社サービスイノベーション部 エンジニア 林知範氏は「多くの部署でAWS利用が進んでいるが、(データ分析環境として)BigQueryの方が優秀なため、ユーザーの7割が利用している」と評価した。

「BigQuery ML」に多くの期待

 NTTドコモは社内データサイエンティスト(分析者)向けにデータマネジメントプラットフォーム(Data Management Platform:DMP)を用意し、その一機能としてビッグデータ分析基盤“統合データ分析プラットフォーム(Integrated Data Analytics Platform:IDAP)”を運用してきた。

 従来はオンプレミスとAmazon Web Services(AWS)という構成だったが、ここにGoogle Cloudを新たに加え、現在はマルチクラウド環境で運用している。

 IDAPを利用する分析者は約2500人、総データ量は5PBを超え、データ加工処理の対象となるデータ量は日に50TB超に達するという。AWSのデータウェアハウス(DWH)サービス「Amazon Redshift」とオブジェクトストレージサービス「Amazon Simple Storage Service(S3)」に3PB超、Google CloudのBigQuery上に2PB超を蓄積し、日々の分析作業に活用してきた。

 NTTドコモがGoogle Cloudの採用を最初に検討した時期は2017年1月までさかのぼる。林氏は当時のGoogle Cloudが「セキュリティ要件や性能要件を満たしていなかった」と振り返った。

(左から)NTTドコモ サービスイノベーション部 エンジニア 林知範氏、グーグル・クラウド・ジャパン ソリューション&テクノロジー部門 技術部長(アナリティクス/機械学習、データベース) 寳野雄太氏
(左から)NTTドコモ サービスイノベーション部 エンジニア 林知範氏、グーグル・クラウド・ジャパン ソリューション&テクノロジー部門 技術部長(アナリティクス/機械学習、データベース) 寳野雄太氏

 IDAPは情報漏洩を一切許さないセキュリティレベルが求められるため、オンプレミス+AWS環境でも閉域網環境で運用してきた。2018年12月に承認を受けたネットワーク以外からの接続を遮断する、Google Cloudのマネージドネットワークサービス「VPC Service Controls」が一般提供(GA)を迎えたことで、翌年の2019年3月からBigQueryの性能検証を開始した。

 その時点では性能面に難があったものの、「グーグル・クラウド・ジャパンと性能検証を行ったが、『あと一歩』だった。支障箇所を検討し、Googleのエンジニアに直接要望を出して、IDAPの性能要件を満たすに至った」と林氏は説明する。同社は現在、BigQuery上に機械学習(Machine Learing:ML)モデルを作成、実行できる「BigQuery ML」に多くの期待を寄せているという。

 BigQuery MLは「SQLの能力だけで機械学習を実行可能。BI(ビジネスインテリジェンス)ツールとの連携も容易」(グーグル・クラウド・ジャパン ソリューション&テクノロジー部門 技術部長 寳野雄太氏)にする機能だが、NTTドコモ内でも「従来はPythonというハードルが存在したものの、(弊社は)SQLが得意なユーザーが多い。気軽に機械学習を使ってもらえる」(林氏)と展望を述べた。

BigQuery MLの概要 BigQuery MLの概要
※クリックすると拡大画像が見られます

 現在NTTドコモは「7割のデータ処理がBigQuery、3割がRedshift。コストパフォーマンスを踏まえた構成を取っている」(林氏)

 当然ながらマルチクラウド環境への移行時はトラブルが付き物だ。AWS上に構築したデータソースをBigQueryに持ち込む際に読み取りエラーが多発する原因として、「RedshiftのNUMERIC型はBigQueryのNUMERIC型より高い精度に対応していたのがエラー原因。小数点以下最大76桁をサポートするBIGNUMERIC型を使うことで問題を解消した。かゆいところに手が届く機能」(林氏)だと評価している。

 また、機械学習モデル作成時の大規模データで読み取りに時間を要していたが、ストレージデータを直接利用する「BigQuery Storage API」を導入したところ、「読み取り時間が約30分から10分以下になり、現場からは喜びの声が多く届いた」(林氏)という。

BigQuery Storage APIの概要 BigQuery Storage APIの概要
※クリックすると拡大画像が見られます

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]