Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kishi Yuta
January 30, 2020

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

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

Kishi Yuta

January 30, 2020
Tweet

Other Decks in Programming

Transcript

  1. NTTドコモ様との これまでの取り組み 1 2 3 4 Firestore チュー ニング GKE

    基盤アーキテ クチャの検討 SRE ワークショッ プ GKEの 評価/PoC 5 サービスのロー ンチ • 04’19 • 12’19 約8ヶ月間
  2. 情報システム部の役割 • Bizと一緒にプロダクトを開発・提供すること • 手がけるシステム群はSoR / SoEに大別 ◦ SoR:顧客システムや料金計算システムといったいわゆる 基幹系のシステム

    ◦ SoE:コンシューマ向けのサービス、社内向け業務支援システムといっ たフロントエンドのシステム ※SoR:System of Records、SoE:System of Engagement
  3. アーキテクチャ全体像 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
  4. 7,600万件のレコードを短時間でFirestoreに インポートするために実施したこと • 並列処理の場合リクエストが正しくても エラー応答となる場合があるためリトライの機構が必須 ex. リクエスト上限超過、サーバ側過負荷 • エラーを極力起こさないよう努めることが大事 ◦

    500/50/5ルール ▪ Firestoreは、リクエスト量に応じて段階的にスケール仕組み ▪ スケールする時間を稼ぐために500/50/5ルールでリクエストを投げる ▪ 新しいコレクションに対するオペレーションは、 毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やす 詳細はコチラ -> Firestoreの性能チューニング( Qiita)
  5. 当時の環境が抱えていた改善点 01 02 周辺機能も手軽に利用し たい CI/CD周りのサポートやロギ ング、モニタリング機能を実 装するには他製品を使わなく ては実現できない。商用利用 を想定すると周辺機能が心も

    とない もっと手間なく、楽に効率 的に運用したい 管理対象範囲はIaaSレイヤ 以上のすべてとなり、運用コ ストが大きかった。基盤のアッ プグレードやノードのオートス ケールも一苦労 03 必要な時に必要な分だけ 費用を払いたい ライセンスベースの課金体系 (コア数・年単位)のため、開 発ピークに合わせてライセン スの事前購入が必要だった
  6. 内製開発チームに近い環境を作る • 全員が同じ拠点で、同じフロアで、一緒に働く ◦ “チーム”になるにはまず会話量を増やすのが大事 ◦ あらゆる情報をオープンする(情報の非対称性の解消) • 会社の垣根を超えてコミュニケーションする ◦

    ex. バザー形式のプロダクトレビュー ◦ ex. 週1回持ち回りで開催している勉強会 • パートナーと一緒にスキルを伸ばす風土を作る ◦ ex. チーム全員で社外の研修参加、外部講師を呼んで勉強会
  7. • 新たな手法や技術は小さく試し徐々に範囲を広げる ◦ われわれがアジャイル開発手法を導入した順 トライアル案件 ➡ 社内向けアプリ ➡ コンシューマ向けアプリ •

    机上での検討を頑張りすぎない ◦ SoE領域は技術のトレンドが変わりやすい ◦ 安価にすぐ試せる技術ばかりなので、まず試す 小さく始める、まずは試す