Tweet
Tweet

Slide 1

Slide 1 text

Google Cloud Anthos Day NTTドコモ情報システム部におけるGKE導入事例 ～パーソナルダッシュボード開発～ 株式会社NTTドコモ プロダクトマネージャ 岸 祐太 Google Cloud Japan, Hawk Yasuhara

Slide 2

Slide 2 text

クラウド活用を検討中のお客様に対し、 デジタルトランスフォーメーションを 技術、戦略面より支援。 安原 "Hawk" 稔貴 Google Cloud Japan Infrastructure Modernization Specialist

Slide 3

Slide 3 text

NTTドコモ様との これまでの取り組み 1 2 3 4 Firestore チュー ニング GKE 基盤アーキテ クチャの検討 SRE ワークショッ プ GKEの 評価/PoC 5 サービスのロー ンチ ● 04’19 ● 12’19 約8ヶ月間

Slide 4

Slide 4 text

NTTドコモ様事例の特長 ● エンタープライズ企業における アプリケーションのモダナイズへの挑戦 ● レガシーシステムと連携するための アーキテクチャと工夫 ● 完全内製ではない組織でのコンテナ開発の取り組み

Slide 5

Slide 5 text

2014年4月、株式会社NTTドコモに入社 2017年7月に現在の所属先でもあるアジャイル開発 組織の前身となるチームを立ち上げ 現在は、プロダクトマネージャとしてWebアプリケーションの 企画・開発およびSREチームのリーダとして プロダクト全体のアーキテクチャ設計などを行う 岸 祐太 株式会社NTTドコモ プロダクトマネージャ @kishiyyyyy

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

当社について

Slide 8

Slide 8 text

情報システム部の役割 ● Bizと一緒にプロダクトを開発・提供すること ● 手がけるシステム群はSoR / SoEに大別 ○ SoR：顧客システムや料金計算システムといったいわゆる 基幹系のシステム ○ SoE：コンシューマ向けのサービス、社内向け業務支援システムといっ たフロントエンドのシステム ※SoR：System of Records、SoE：System of Engagement

Slide 9

Slide 9 text

情報システム部の戦略 SoR/SoEは疎結合にし、分離して考える SoRは標準技術へ移行、SoEは積極的に差別化

Slide 10

Slide 10 text

2018年7月 情報システム部内にSoE開発専門組織を新設 ● SoRに最適化されてきたやり方を抜本的に見直し ● 変化の激しい市場に対応するために ○ アジャイル的な開発 ○ すばやく、スケールする基盤　

Slide 11

Slide 11 text

本日お話しすること ● パーソナルデータダッシュボードを支える GCP基盤について ● GCP（GKE）導入の背景、決め手 ● エンタープライズ企業で新たな取り組みを 行う上でのポイントと、これからのチャレンジ

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

パーソナルデータを 取り巻く外部環境の変化 ● お客さまへ驚きと感動を提供するために、 5GやAIなどの最新技術を活用するとともに お客さまのパーソナルデータを活用 させていただくことが不可欠に ● 社会全般でパーソナルデータの活用が進展。個 人のプライバシーへの関心が高まっている

Slide 14

Slide 14 text

2019年8月 パーソナルデータ憲章の公表 お客さまのパーソナルデータを適切に取り扱うための 意思決定基準を6つの行動原則として明文化

Slide 15

Slide 15 text

2019年12月 パーソナルデータダッシュボードの提供 ● パーソナルデータの取扱いについて 同意いただいた内容を確認したり ● ドコモ内でのデータ利用目的や パートナーなど第三者提供を一定の範囲で お客さま自ら設定・変更できるように

Slide 16

Slide 16 text

本プロダクトを支えるGCP基盤 GKE コンテナ化したアプリケーションのデ プロイ環境としてk8sのマネージド サービスであるGKEを利用 Firestore 7,600万ものお客様データの格納先 としてNoSQLデータベース であるFirestoreを利用

Slide 17

Slide 17 text

アーキテクチャ全体像 Cloud Load Balancing Cloud Armor Cloud Firestore Kubernetes Engine SoR Systems Web Pod API Integration File Transportation Import Service Cloud Storage Cloud Dataflow Transfer Appliance Cloud Composer Cloud Load Balancing Web Pod Web Pod App Pod

Slide 18

Slide 18 text

GKE周辺のアーキテクチャについて ● 全てのアプリケーションをGKEに ● GitLab CI / Cloud Buildを使った継続的インテグレーション ● Argo CDを使った継続的デリバリー ● 監視ツールはDatadogを利用

Slide 19

Slide 19 text

Firestore周辺のアーキテクチャ ● SoR系システムから転送されたファイルをS3からGCSへ転送 ● Dataflowを並列で使いFirestoreへインポート ● Cloud Composerでこれらワークフローを管理 Cloud Firestore Cloud Storage Cloud Dataflow Transfer Appliance Orchestration Cloud Composer 7,600万件の レコードを日次 で洗い替え Import Service Cloud Dataflow

Slide 20

Slide 20 text

7,600万件のレコードを短時間でFirestoreに インポートするために実施したこと ● 並列処理の場合リクエストが正しくても エラー応答となる場合があるためリトライの機構が必須 ex. リクエスト上限超過、サーバ側過負荷 ● エラーを極力起こさないよう努めることが大事 ○ 500/50/5ルール ■ Firestoreは、リクエスト量に応じて段階的にスケール仕組み ■ スケールする時間を稼ぐために500/50/5ルールでリクエストを投げる ■ 新しいコレクションに対するオペレーションは、 毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やす 詳細はコチラ -> Firestoreの性能チューニング（ Qiita）

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

チーム発足当初〜 KubernetesベースのPaaSを利用してきた ● 当時、マネージドk8sを採用しなかった理由 ○ 社内のプライベートクラウド上へも移植可能なコンテナ プラットフォームであることが条件であったため ○ マネージドk8sの導入事例も少なかった ● あえてIaaSとPaaSを分離した構成を採用したが 運用面、機能面、コスト面で改善ポイントあり

Slide 23

Slide 23 text

当時の環境が抱えていた改善点 01 02 周辺機能も手軽に利用し たい CI／CD周りのサポートやロギ ング、モニタリング機能を実 装するには他製品を使わなく ては実現できない。商用利用 を想定すると周辺機能が心も とない もっと手間なく、楽に効率 的に運用したい 管理対象範囲はIaaSレイヤ 以上のすべてとなり、運用コ ストが大きかった。基盤のアッ プグレードやノードのオートス ケールも一苦労 03 必要な時に必要な分だけ 費用を払いたい ライセンスベースの課金体系 （コア数・年単位）のため、開 発ピークに合わせてライセン スの事前購入が必要だった

Slide 24

Slide 24 text

2019年4月 マネージドk8sのPoC/評価 ● ミッションクリティカルなシステムでのパブリッククラウド の導入実績が増えたことが後押しに ● GKEを含むマネージドk8sのPoCを実施し、評価 ○ マネージドk8sでも今までできていたことが実現できるか ○ 課題が解決できるか ○ 自分たちだけで構築、運用保守が賄えるか

Slide 25

Slide 25 text

GKE導入の決め手 ● ランニングコストが安い ○ master nodeの課金なし ● ドキュメントが豊富で分かりやすい ○ GKEを触ったことがあるメンバーはゼロだったが、 Qwiklabsや公式ドキュメントを参考にスキルを習得できた ● k8s生みの親である安心感

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

エンタープライズ企業ならではの事情 ● 社内にエンジニアリングリソースがない中で、 外部のパートナー企業と一緒にどのように アジャイルなマインドや文化を築いていくか？ ● これまでの実績や既存システムが多くある中で、 新しい取り組みをどう提案・導入していくのか？

Slide 28

Slide 28 text

大事だと思うポイント 内製開発チームに近い環境を作る 小さく始める、まずは試す

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

内製開発チームに近い環境を作る ● 全員が同じ拠点で、同じフロアで、一緒に働く ○ “チーム”になるにはまず会話量を増やすのが大事 ○ あらゆる情報をオープンする（情報の非対称性の解消） ● 会社の垣根を超えてコミュニケーションする ○ ex. バザー形式のプロダクトレビュー ○ ex. 週１回持ち回りで開催している勉強会 ● パートナーと一緒にスキルを伸ばす風土を作る ○ ex. チーム全員で社外の研修参加、外部講師を呼んで勉強会

Slide 31

Slide 31 text

● 新たな手法や技術は小さく試し徐々に範囲を広げる ○ われわれがアジャイル開発手法を導入した順 トライアル案件 ➡ 社内向けアプリ ➡ コンシューマ向けアプリ ● 机上での検討を頑張りすぎない ○ SoE領域は技術のトレンドが変わりやすい ○ 安価にすぐ試せる技術ばかりなので、まず試す 小さく始める、まずは試す

Slide 32

Slide 32 text

エンタープライズ企業のメンバーも エンジニアリングスキルを身に着ける ● ユーザ企業の役割は、 責任とスピード感を持って判断すること ● そのためにも、最低限のスキル習得は必要 ○ ex. 認定資格やカンファレンスを通して机上で学ぶ ○ ex. Webアプリケーションをひとりで作ってみる ○ ex. Qwiklabsなどのオンライン学習サイトでGCPの基礎を学ぶ

Slide 33

Slide 33 text

● Bizを巻き込み、会社全体でアジャイルなチームを 作るにはどうすればいいのか？ ● 大規模プロジェクトにおける最適な開発の進め方は？ ○ 基幹系システムの開発も伴うケース（手戻りが許容できない） ○ 多くの部署が絡むなど利害関係者が多いケース とはいえ、われわれも道半ば...

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

新たな価値創造と開発の最適化 ● データを活用しお客さまや社会へ新たな価値の 継続的な提供 ● 変化の早い市場に対応するためにサーバレスの活用 ○ GAE、CloudRunなど ● 情報システム部全体でシステムをモダナイゼーション ○ APIの拡充、SoRも標準技術へ移行

Slide 36

Slide 36 text

本日のまとめ ● 弊部ではSoEとSoRを分離し、SoEはアプリケーションをいかに早くできる かを追求し、アジャイルな開発体制を築いている ● SoRとの連携は、制約の中で最善なアーキテクチャを見つける ● エンジニアリングリソースを持たないエンタープライズ企業では ○ 内製開発組織に近づける環境づくりが第一歩 ○ パートナーと一緒にチーム全員でスキルアップをしていく ● Biz含め会社全体でアジャイルなチームを作るのが次のステップ

Slide 37

Slide 37 text

事例記事 近日公開予定！ cloud.google.com/blog/ja (Google Cloud Japan Blog)

Slide 38

Slide 38 text

Thank you