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

2019年1月30日に開催されたGoogle Cloud Anthos Dayで発表したセッション「NTTドコモ情報システム部におけるGKE導入事例　～パーソナルダッシュボード開発～」のスライドです。

Transcript

1. Google Cloud Anthos Day NTTドコモ情報システム部におけるGKE導入事例 ～パーソナルダッシュボード開発～ 株式会社NTTドコモ プロダクトマネージャ 岸 祐太 Google Cloud Japan, Hawk Yasuhara
2. クラウド活用を検討中のお客様に対し、 デジタルトランスフォーメーションを 技術、戦略面より支援。 安原 "Hawk" 稔貴 Google Cloud Japan Infrastructure Modernization Specialist
3. NTTドコモ様との これまでの取り組み 1 2 3 4 Firestore チュー ニング GKE 基盤アーキテ クチャの検討 SRE ワークショッ プ GKEの 評価/PoC 5 サービスのロー ンチ • 04’19 • 12’19 約8ヶ月間
4. NTTドコモ様事例の特長 • エンタープライズ企業における アプリケーションのモダナイズへの挑戦 • レガシーシステムと連携するための アーキテクチャと工夫 • 完全内製ではない組織でのコンテナ開発の取り組み
5. 2014年4月、株式会社NTTドコモに入社 2017年7月に現在の所属先でもあるアジャイル開発 組織の前身となるチームを立ち上げ 現在は、プロダクトマネージャとしてWebアプリケーションの 企画・開発およびSREチームのリーダとして プロダクト全体のアーキテクチャ設計などを行う 岸 祐太 株式会社NTTドコモ プロダクトマネージャ @kishiyyyyy
6. 　スライド、原稿はWEB公開します
7. 当社について
8. 情報システム部の役割 • Bizと一緒にプロダクトを開発・提供すること • 手がけるシステム群はSoR / SoEに大別 ◦ SoR：顧客システムや料金計算システムといったいわゆる 基幹系のシステム ◦ SoE：コンシューマ向けのサービス、社内向け業務支援システムといっ たフロントエンドのシステム ※SoR：System of Records、SoE：System of Engagement
9. 情報システム部の戦略 SoR/SoEは疎結合にし、分離して考える SoRは標準技術へ移行、SoEは積極的に差別化
10. 2018年7月 情報システム部内にSoE開発専門組織を新設 • SoRに最適化されてきたやり方を抜本的に見直し • 変化の激しい市場に対応するために ◦ アジャイル的な開発 ◦ すばやく、スケールする基盤　
11. 本日お話しすること • パーソナルデータダッシュボードを支える GCP基盤について • GCP（GKE）導入の背景、決め手 • エンタープライズ企業で新たな取り組みを 行う上でのポイントと、これからのチャレンジ
12. 01 パーソナルデータ ダッシュボードを支える GCP基盤について
13. パーソナルデータを 取り巻く外部環境の変化 • お客さまへ驚きと感動を提供するために、 5GやAIなどの最新技術を活用するとともに お客さまのパーソナルデータを活用 させていただくことが不可欠に • 社会全般でパーソナルデータの活用が進展。個 人のプライバシーへの関心が高まっている
14. 2019年8月 パーソナルデータ憲章の公表 お客さまのパーソナルデータを適切に取り扱うための 意思決定基準を6つの行動原則として明文化
15. 2019年12月 パーソナルデータダッシュボードの提供 • パーソナルデータの取扱いについて 同意いただいた内容を確認したり • ドコモ内でのデータ利用目的や パートナーなど第三者提供を一定の範囲で お客さま自ら設定・変更できるように
16. 本プロダクトを支えるGCP基盤 GKE コンテナ化したアプリケーションのデ プロイ環境としてk8sのマネージド サービスであるGKEを利用 Firestore 7,600万ものお客様データの格納先 としてNoSQLデータベース であるFirestoreを利用
17. アーキテクチャ全体像 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
18. GKE周辺のアーキテクチャについて • 全てのアプリケーションをGKEに • GitLab CI / Cloud Buildを使った継続的インテグレーション • Argo CDを使った継続的デリバリー • 監視ツールはDatadogを利用
19. 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
20. 7,600万件のレコードを短時間でFirestoreに インポートするために実施したこと • 並列処理の場合リクエストが正しくても エラー応答となる場合があるためリトライの機構が必須 ex. リクエスト上限超過、サーバ側過負荷 • エラーを極力起こさないよう努めることが大事 ◦ 500/50/5ルール ▪ Firestoreは、リクエスト量に応じて段階的にスケール仕組み ▪ スケールする時間を稼ぐために500/50/5ルールでリクエストを投げる ▪ 新しいコレクションに対するオペレーションは、 毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やす 詳細はコチラ -> Firestoreの性能チューニング（ Qiita）
21. 02 GCP (GKE) 導入の 背景、決め手
22. チーム発足当初〜 KubernetesベースのPaaSを利用してきた • 当時、マネージドk8sを採用しなかった理由 ◦ 社内のプライベートクラウド上へも移植可能なコンテナ プラットフォームであることが条件であったため ◦ マネージドk8sの導入事例も少なかった • あえてIaaSとPaaSを分離した構成を採用したが 運用面、機能面、コスト面で改善ポイントあり
23. 当時の環境が抱えていた改善点 01 02 周辺機能も手軽に利用し たい CI／CD周りのサポートやロギ ング、モニタリング機能を実 装するには他製品を使わなく ては実現できない。商用利用 を想定すると周辺機能が心も とない もっと手間なく、楽に効率 的に運用したい 管理対象範囲はIaaSレイヤ 以上のすべてとなり、運用コ ストが大きかった。基盤のアッ プグレードやノードのオートス ケールも一苦労 03 必要な時に必要な分だけ 費用を払いたい ライセンスベースの課金体系 （コア数・年単位）のため、開 発ピークに合わせてライセン スの事前購入が必要だった
24. 2019年4月 マネージドk8sのPoC/評価 • ミッションクリティカルなシステムでのパブリッククラウド の導入実績が増えたことが後押しに • GKEを含むマネージドk8sのPoCを実施し、評価 ◦ マネージドk8sでも今までできていたことが実現できるか ◦ 課題が解決できるか ◦ 自分たちだけで構築、運用保守が賄えるか
25. GKE導入の決め手 • ランニングコストが安い ◦ master nodeの課金なし • ドキュメントが豊富で分かりやすい ◦ GKEを触ったことがあるメンバーはゼロだったが、 Qwiklabsや公式ドキュメントを参考にスキルを習得できた • k8s生みの親である安心感
26. 03 エンタープライズ企業で新 たな取り組みを行う上での ポイント
27. エンタープライズ企業ならではの事情 • 社内にエンジニアリングリソースがない中で、 外部のパートナー企業と一緒にどのように アジャイルなマインドや文化を築いていくか？ • これまでの実績や既存システムが多くある中で、 新しい取り組みをどう提案・導入していくのか？
28. 大事だと思うポイント 内製開発チームに近い環境を作る 小さく始める、まずは試す
30. 内製開発チームに近い環境を作る • 全員が同じ拠点で、同じフロアで、一緒に働く ◦ “チーム”になるにはまず会話量を増やすのが大事 ◦ あらゆる情報をオープンする（情報の非対称性の解消） • 会社の垣根を超えてコミュニケーションする ◦ ex. バザー形式のプロダクトレビュー ◦ ex. 週１回持ち回りで開催している勉強会 • パートナーと一緒にスキルを伸ばす風土を作る ◦ ex. チーム全員で社外の研修参加、外部講師を呼んで勉強会
31. • 新たな手法や技術は小さく試し徐々に範囲を広げる ◦ われわれがアジャイル開発手法を導入した順 トライアル案件 ➡ 社内向けアプリ ➡ コンシューマ向けアプリ • 机上での検討を頑張りすぎない ◦ SoE領域は技術のトレンドが変わりやすい ◦ 安価にすぐ試せる技術ばかりなので、まず試す 小さく始める、まずは試す
32. エンタープライズ企業のメンバーも エンジニアリングスキルを身に着ける • ユーザ企業の役割は、 責任とスピード感を持って判断すること • そのためにも、最低限のスキル習得は必要 ◦ ex. 認定資格やカンファレンスを通して机上で学ぶ ◦ ex. Webアプリケーションをひとりで作ってみる ◦ ex. Qwiklabsなどのオンライン学習サイトでGCPの基礎を学ぶ
33. • Bizを巻き込み、会社全体でアジャイルなチームを 作るにはどうすればいいのか？ • 大規模プロジェクトにおける最適な開発の進め方は？ ◦ 基幹系システムの開発も伴うケース（手戻りが許容できない） ◦ 多くの部署が絡むなど利害関係者が多いケース とはいえ、われわれも道半ば...
34. 04 NTTドコモ、自組織の これからのチャレンジ
35. 新たな価値創造と開発の最適化 • データを活用しお客さまや社会へ新たな価値の 継続的な提供 • 変化の早い市場に対応するためにサーバレスの活用 ◦ GAE、CloudRunなど • 情報システム部全体でシステムをモダナイゼーション ◦ APIの拡充、SoRも標準技術へ移行
36. 本日のまとめ • 弊部ではSoEとSoRを分離し、SoEはアプリケーションをいかに早くできる かを追求し、アジャイルな開発体制を築いている • SoRとの連携は、制約の中で最善なアーキテクチャを見つける • エンジニアリングリソースを持たないエンタープライズ企業では ◦ 内製開発組織に近づける環境づくりが第一歩 ◦ パートナーと一緒にチーム全員でスキルアップをしていく • Biz含め会社全体でアジャイルなチームを作るのが次のステップ
37. 事例記事 近日公開予定！ cloud.google.com/blog/ja (Google Cloud Japan Blog)
38. Thank you