集中か？ 分散か？ NTTドコモがDWH／データレイクから「データメッシュ」に移行したワケ

分散型アーキテクチャ「データメッシュ」への移行を決断

　この問題を解決するためにNTTドコモが取り組んだのは、分散型のアーキテクチャをもつデータメッシュへの移行だ。データメッシュでは、中心となるチームがすべてを担う代わりに、複数の“データオーナー”がデータを処理してからユーザーに提供する。このとき重要になるのは、データ品質の低下につながる“好き勝手”なデータのやり取りを許さないことだ。そのため移行においては、分散型でありながらも高度なガバナンスを担保したアーキテクチャ設計での基盤刷新を目指すことになった。

　そこで現在は、分散型のデメリットを補う「Snowflake Internal Marketplace」を通じて、ユーザーがデータを入手できるようにしており、各データオーナーは自身が提供しているデータの品質とROIに責任を持ち、“データの流通”を促す役割を担っている。Snowflakeを採用しての実装では、複数のドメインアカウントを一括管理できる組織アカウントを採用した。権限管理やデータプロダクトの開発、ユーザーへの提供をドメインアカウント単位で行うことで、ドメインアカウントごとにコストを管理できるようにもなった。さらに中央集権型から分散型へとアーキテクチャが変わったことで、中心となるチームの仕事内容は、データ基盤の自律性を維持するためのガイドライン整備とガバナンスのモニタリングに変わった。

　こうしてIDAPは刷新されたが、現場のデータニーズを社内のデータだけで満たせるとは限らない。ユーザーは、外部のパートナーが運用する環境にあるデータを使いたいこともあるだろう。そのとき外部パートナーが他社のテクノロジーを利用している場合、どうやって外部のデータウェアハウス／データレイクと連携するのか。データの相互コピーも検討すべき方法の一つだが、データの重複保持や鮮度の問題がある。また、クエリの実行スピードが劣化することも避けたい。NTTドコモ側で処理するデータ量が多い分、どのように性能要件を満たすかが新たな問題となった。

　この解決のために採用したのが「Apache Icebergテーブル」である。Apache Icebergのオープンテーブルフォーマットに準拠し、ACID特性（原子性、一貫性、分離性、耐久性）を担保したトランザクション処理を実行可能だ。松原氏は、多くの条件でApache Icebergテーブルの性能を検証し、変更にともなう性能劣化の懸念はないと判断できたと説明した。

データプロダクトとしての「ネットワークの体感品質スコア」

　続いて登壇したNTTドコモの成清修平氏は、IDAPを利用して“ネットワークの体感品質”の定量化と向上にかかわる事例を紹介した。その取り組みでは、NTTドコモの運用する大規模ネットワークから発生する膨大なデータを機械学習で処理し、ユーザーごと、基地局ごとのスコアを毎日算出し、Snowflake Internal Marketplaceで提供しているという。

　その手順は、接続の成功や失敗、通信の制御信号、基地局のリソース使用率など、ユーザー端末や基地局で集めている多様なネットワークデータを収集し、Snowflakeにロードすることからはじまる。次に、このデータをユーザーの属性情報をはじめとするサービス系のデータと掛け合わせ、機械学習でネットワーク品質の特徴量を作成する。最後にユーザー端末ごと、基地局ごとの品質スコアを算出してSnowflake Internal Marketplaceに公開する。簡単そうに聞こえるが、裏側では大規模で複雑なデータ処理が欠かせない。成清氏は、毎日の処理コストは莫大になり、定常運用のためにはコスト削減の取り組みが必要だと振り返った。

　一連の処理の中で、特にコストが大きいのがデータ結合のためのJOIN処理である。この処理では、1日あたり23TBのデータと、1日あたり243GBのデータを扱う。実際は複数のテーブルに分割して処理するが、非常に大きなテーブルであるため、処理コストが問題になっていた。また、この処理に続く約1.5TBの単一テーブルを集約する処理でも、メモリー不足によるエラー発生とリトライ処理の繰り返しで、処理が動かないことが頻繁に発生していた。

　改善のために実施した対策は、ウェアハウスのサイジングだ。この最適化によってJOIN処理の問題については、実行時間を30％短縮、クレジット換算でコストの40％を低減できるなどの改善効果を得られた。また、集約処理の問題についても、よりメモリーの多いウェアハウスに変更することで、意図しないコスト増を抑制できたとする。この他にも、CTEs（共通テーブル式）から実テーブルの参照への変更、パイプライン上流でのフィルタリングの実行などの対策を実施し、「最終的にデータパイプラインの処理コストは、当初と比べて65%低減できた」と成清氏は述べた。