Google Cloud

Anthos Day

NTTドコモ情報システム部におけるGKE導入事例～パーソナルダッシュボード開発～

株式会社NTTドコモ プロダクトマネージャ 岸 祐太Google Cloud Japan, Hawk Yasuhara

クラウド活用を検討中のお客様に対し、デジタルトランスフォーメーションを技術、戦略面より支援。

安原 "Hawk" 稔貴

Google Cloud JapanInfrastructure

Modernization Specialist

NTTドコモ様とのこれまでの取り組み

1 2 3 4

Firestoreチューニング

GKE基盤アーキテクチャの検討

SREワークショッ

プGKEの

評価/PoC

5

サービスのローンチ

●

04’19●

12’19

約8ヶ月間

NTTドコモ様事例の特長

● エンタープライズ企業における

アプリケーションのモダナイズへの挑戦

● レガシーシステムと連携するための

アーキテクチャと工夫

● 完全内製ではない組織でのコンテナ開発の取り組み

2014年4月、株式会社NTTドコモに入社

2017年7月に現在の所属先でもあるアジャイル開発組織の前身となるチームを立ち上げ

現在は、プロダクトマネージャとしてWebアプリケーションの企画・開発およびSREチームのリーダとしてプロダクト全体のアーキテクチャ設計などを行う

岸 祐太

株式会社NTTドコモ

プロダクトマネージャ

@kishiyyyyy

　スライド、原稿はWEB公開します💪

当社について

情報システム部の役割

● Bizと一緒にプロダクトを開発・提供すること🤝

● 手がけるシステム群はSoR / SoEに大別

○ SoR：顧客システムや料金計算システムといったいわゆる

基幹系のシステム

○ SoE：コンシューマ向けのサービス、社内向け業務支援システムといっ

たフロントエンドのシステム

※SoR：System of Records、SoE：System of Engagement

情報システム部の戦略

SoR/SoEは疎結合にし、分離して考える

SoRは標準技術へ移行、SoEは積極的に差別化

2018年7月情報システム部内にSoE開発専門組織を新設

● SoRに最適化されてきたやり方を抜本的に見直し

● 変化の激しい市場に対応するために

○ アジャイル的な開発 ○ すばやく、スケールする基盤　

本日お話しすること

● パーソナルデータダッシュボードを支える

GCP基盤について

● GCP（GKE）導入の背景、決め手

● エンタープライズ企業で新たな取り組みを

行う上でのポイントと、これからのチャレンジ

01パーソナルデータダッシュボードを支えるGCP基盤について

パーソナルデータを取り巻く外部環境の変化

● お客さまへ驚きと感動を提供するために、

5GやAIなどの最新技術を活用するとともに

お客さまのパーソナルデータを活用

させていただくことが不可欠に

● 社会全般でパーソナルデータの活用が進展。個

人のプライバシーへの関心が高まっている

2019年8月 パーソナルデータ憲章の公表

お客さまのパーソナルデータを適切に取り扱うための

意思決定基準を6つの行動原則として明文化

2019年12月パーソナルデータダッシュボードの提供

● パーソナルデータの取扱いについて

同意いただいた内容を確認したり

● ドコモ内でのデータ利用目的や

パートナーなど第三者提供を一定の範囲で

お客さま自ら設定・変更できるように

本プロダクトを支えるGCP基盤

GKE

コンテナ化したアプリケーションのデ

プロイ環境としてk8sのマネージド

サービスであるGKEを利用

Firestore

7,600万ものお客様データの格納先

としてNoSQLデータベース

であるFirestoreを利用

アーキテクチャ全体像

Cloud LoadBalancing

Cloud Armor

CloudFirestore

KubernetesEngine

SoR Systems

WebPod

API Integration

File Transportation

Import ServiceCloudStorage

CloudDataflow

Transfer Appliance

CloudComposer

Cloud LoadBalancing

WebPod

WebPod

AppPod

GKE周辺のアーキテクチャについて

● 全てのアプリケーションをGKEに● GitLab CI / Cloud Buildを使った継続的インテグレーション

● Argo CDを使った継続的デリバリー

● 監視ツールはDatadogを利用

Firestore周辺のアーキテクチャ

● SoR系システムから転送されたファイルをS3からGCSへ転送● Dataflowを並列で使いFirestoreへインポート● Cloud Composerでこれらワークフローを管理

CloudFirestore

CloudStorage

CloudDataflow

Transfer Appliance

Orchestration

CloudComposer

7,600万件のレコードを日次で洗い替え

Import Service

CloudDataflow

7,600万件のレコードを短時間でFirestoreにインポートするために実施したこと

● 並列処理の場合リクエストが正しくてもエラー応答となる場合があるためリトライの機構が必須ex. リクエスト上限超過、サーバ側過負荷

● エラーを極力起こさないよう努めることが大事○ 500/50/5ルール

■ Firestoreは、リクエスト量に応じて段階的にスケール仕組み■ スケールする時間を稼ぐために500/50/5ルールでリクエストを投げる■ 新しいコレクションに対するオペレーションは、

毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やす

詳細はコチラ -> Firestoreの性能チューニング（Qiita）

02GCP (GKE) 導入の背景、決め手

チーム発足当初〜KubernetesベースのPaaSを利用してきた

● 当時、マネージドk8sを採用しなかった理由○ 社内のプライベートクラウド上へも移植可能なコンテナ

プラットフォームであることが条件であったため

○ マネージドk8sの導入事例も少なかった

● あえてIaaSとPaaSを分離した構成を採用したが

運用面、機能面、コスト面で改善ポイントあり

当時の環境が抱えていた改善点

01 02 周辺機能も手軽に利用し

たい

CI／CD周りのサポートやロギ

ング、モニタリング機能を実

装するには他製品を使わなく

ては実現できない。商用利用

を想定すると周辺機能が心も

とない

もっと手間なく、楽に効率

的に運用したい

管理対象範囲は IaaSレイヤ

以上のすべてとなり、運用コ

ストが大きかった。基盤のアッ

プグレードやノードのオートス

ケールも一苦労

03 必要な時に必要な分だけ

費用を払いたい

ライセンスベースの課金体系

（コア数・年単位）のため、開

発ピークに合わせてライセン

スの事前購入が必要だった

2019年4月 マネージドk8sのPoC/評価

● ミッションクリティカルなシステムでのパブリッククラウド

の導入実績が増えたことが後押しに💪

● GKEを含むマネージドk8sのPoCを実施し、評価○ マネージドk8sでも今までできていたことが実現できるか

○ 課題が解決できるか

○ 自分たちだけで構築、運用保守が賄えるか

GKE導入の決め手

● ランニングコストが安い

○ master nodeの課金なし

● ドキュメントが豊富で分かりやすい

○ GKEを触ったことがあるメンバーはゼロだったが、

Qwiklabsや公式ドキュメントを参考にスキルを習得できた

● k8s生みの親である安心感

03エンタープライズ企業で新たな取り組みを行う上でのポイント

エンタープライズ企業ならではの事情

● 社内にエンジニアリングリソースがない中で、

外部のパートナー企業と一緒にどのように

アジャイルなマインドや文化を築いていくか？

● これまでの実績や既存システムが多くある中で、

新しい取り組みをどう提案・導入していくのか？

大事だと思うポイント

内製開発チームに近い環境を作る

小さく始める、まずは試す

内製開発チームに近い環境を作る 💪● 全員が同じ拠点で、同じフロアで、一緒に働く

○ “チーム”になるにはまず会話量を増やすのが大事

○ あらゆる情報をオープンする（情報の非対称性の解消）

● 会社の垣根を超えてコミュニケーションする○ ex. バザー形式のプロダクトレビュー

○ ex. 週１回持ち回りで開催している勉強会

● パートナーと一緒にスキルを伸ばす風土を作る○ ex. チーム全員で社外の研修参加、外部講師を呼んで勉強会

● 新たな手法や技術は小さく試し徐々に範囲を広げる○ われわれがアジャイル開発手法を導入した順

トライアル案件 ➡ 社内向けアプリ ➡ コンシューマ向けアプリ

● 机上での検討を頑張りすぎない○ SoE領域は技術のトレンドが変わりやすい

○ 安価にすぐ試せる技術ばかりなので、まず試す

小さく始める、まずは試す 💪

エンタープライズ企業のメンバーもエンジニアリングスキルを身に着ける 💪

● ユーザ企業の役割は、

責任とスピード感を持って判断すること

● そのためにも、最低限のスキル習得は必要○ ex. 認定資格やカンファレンスを通して机上で学ぶ

○ ex. Webアプリケーションをひとりで作ってみる

○ ex. Qwiklabsなどのオンライン学習サイトでGCPの基礎を学ぶ

● Bizを巻き込み、会社全体でアジャイルなチームを

作るにはどうすればいいのか？

● 大規模プロジェクトにおける最適な開発の進め方は？○ 基幹系システムの開発も伴うケース（手戻りが許容できない）

○ 多くの部署が絡むなど利害関係者が多いケース

とはいえ、われわれも道半ば... 😥

04NTTドコモ、自組織のこれからのチャレンジ

新たな価値創造と開発の最適化

● データを活用しお客さまや社会へ新たな価値の

継続的な提供

● 変化の早い市場に対応するためにサーバレスの活用○ GAE、CloudRunなど

● 情報システム部全体でシステムをモダナイゼーション○ APIの拡充、SoRも標準技術へ移行

本日のまとめ

● 弊部ではSoEとSoRを分離し、SoEはアプリケーションをいかに早くできる

かを追求し、アジャイルな開発体制を築いている

● SoRとの連携は、制約の中で最善なアーキテクチャを見つける

● エンジニアリングリソースを持たないエンタープライズ企業では

○ 内製開発組織に近づける環境づくりが第一歩

○ パートナーと一緒にチーム全員でスキルアップをしていく

● Biz含め会社全体でアジャイルなチームを作るのが次のステップ

事例記事 近日公開予定！

cloud.google.com/blog/ja (Google Cloud Japan Blog)

Thank you👋