はじめに
本記事は2020年1月30日に開催されたGoogle Cloud Anthos Dayで発表したセッション「NTTドコモ情報システム部におけるGKE導入事例 ～パーソナルダッシュボード開発～」でお話しした内容を文字に起こしたものです🎉
スライドだけをご覧になりたい方はこちらへ💪
スライドと原稿をWebで公開した理由は、
- セッション中、話に集中してもらえるように
- わざわざ私が話したことをメモしなくて済むように
- カンファレンスに参加できなかった人にも聞いて欲しかったため
出来るだけ多くの方（特にエンタプライズ企業に関わっている方）にこの記事が届くと嬉しいです。
本セッションで伝えたいことサマリ
- パーソナルデータダッシュボードを支えるGCP基盤について
- GCP（GKE）導入の背景、決め手
- エンタープライズ企業で新たな取り組みを成功させるポイントと、これからのチャレンジ
表紙
自己紹介、会社紹介
NTTドコモでプロダクトマネージャをやっている岸と申します。
Twitterはこちら。
これまでの経歴と今やっていることを簡単に。
- 2014年4月にドコモ入社
- 入社してから4年ほどは基幹系のシステム開発に従事
- 2017年10月に現在の所属先でもあるアジャイル開発組織の前身となるチームの立ち上げを行いました
- 現在は、プロダクトマネージャとしてWebアプリケーションの企画・開発およびSREチームのリーダとしてわれわれチームで扱うプロダクトのアーキテクチャ設計などを行ってます
NTTドコモは1992年に設立された移動体通信事業を生業とする会社、いわゆる通信キャリアです。われわれは通信事業とスマートライフ領域の２つの事業を手がけています。
- 通信事業では、お客さまとのつながりを強固にし顧客基盤の拡大を目指し
- スマートライフ事業では、外部のパートナーとの協創を行い非通信事業の成長を図っています。
その中で、私が所属する情報システム部の役割は、これら事業に必要となるプロダクトをBizと共に開発して、お客さまへ届けることです。手がけるシステムは SoR / SoE の２種に大別されます。
- SoRとは顧客システムや料金計算システムといったいわゆる基幹系のシステム
- SoEとはコンシューマ向けのサービス、あるいは社内向けの業務支援システムといったフロントエンドのシステム
それぞれの特徴を一言で表すと、SoRは変わりにくくSoEは変わりやすい。全く特性が違うものです。そこで弊部ではこちらの戦略を取っています。
- SoR/SoEは疎結合にし分離して考える
- SoRは標準技術に徐々に移行しSoEは積極的に差別化をしていく
その戦略の一環で、われわれは2018年7月に情報システム部内にSoE開発を担う専門チームを新設しました。これまでSoRに最適化されてきたやり方を抜本的に見直し、変化の激しい市場に対応するために、アジャイル的な開発、すばやく・スケールする基盤を活用しています。後者はいわゆるクラウドネィティブと総称される技術たちのことです。
改めまして本日お話することは３点です。
- パーソナルデータダッシュボードを支えるGCP基盤について
- GCP（GKE）導入の背景、決め手
- エンタープライズ企業で新たな取り組みを成功させるポイントと、これからのチャレンジ
パーソナルデータダッシュボードを支えるGCP基盤
まずは、パーソナルデータダッシュボードを支えるGCP基盤について。
プロダクトを紹介する前に、そもそもなぜこのようなプロダクトを提供するに至ったのかという背景を簡単に。
現在、パーソナルデータを取り巻く外部環境が大きく変化しています。パーソナルデータとはお客様の個人情報や位置情報などイメージしていただけると分かりやすいかと。
ドコモしてはお客さまへ驚きと感動を提供するために、5GやAIなどの最新技術を活用するはもちろんのこと、お客様それぞれに合ったサービスを提供するにはパーソナルデータを活用させていただくことが必要不可欠となります。
さらに、社会全般でパーソナルデータの活用が進展し、個人のプライバシーへの関心が高まっております。
そのような背景を踏まえ、ドコモは2019年8月にパーソナルデータ憲章を公表しました。お客さまのパーソナルデータを適切に取り扱うための意思決定基準を6つの行動原則として表したものです。
例えば、
- コミュニケーションを大切にし、透明性を確保する
- お客さま一人ひとりの意思を尊重する
こちらの行動原則を形にしたものの１つが、2019年12月、昨年末に提供を開始したパーソナルデータダッシュボードです。コンシューマ向けサービスなので、弊社のお客さまであればどなたでもご利用いただけます。
具体的にダッシュボードではどんな機能を提供しているのかというと、
- パーソナルデータの取扱いについて同意いただいた内容を確認したり、
- ドコモ内でのデータ利用目的、パートナーなどへの第三者提供を一定の範囲でお客さま自ら設定・変更できるようになりました
これまでは個別サービスごとに機能や情報を管理していたのですが、お世辞にも利便性が高いものではありませんでした。そこで、これら情報を一元管理し、お客様自身で設定変更できるようにしたことで利便性はもちろんのこと、透明性の確保に貢献しております。
では、本プロダクトを支えるGCP基盤について、具体的なアーキテクチャも紹介しつつお話していきます。
GCP基盤の中心となっているのがこの２つのコンポーネントです。
- コンテナ化したアプリケーションのデプロイ環境としてk8sのマネージドサービスであるGKE
- 7,600万ものお客様データの一時的な格納先としてNoSQLデータベースであるFirestore
こちらがアーキテクチャ全体像です。単なるWebアプリケーションなので構成図自体はとてもシンプルです。アプリケーションは全てGKE上で稼働しています。
特徴的なのがSoR系システムとの連携です。
本プロダクトは複数のSoRシステムとの連携のもと成り立っていまして、API連携とファイル連携の２つの連携方式を採用しています。
そのほぼ全てがAPI連携なのですが、一部でファイル連携を採用したのは
- データ鮮度が最新であることが業務上必須でなく
- SoR側のAPI開発コストが多くかかるためでした。
ファイル連携で受領したデータをわれわれのFirestoreに格納し利用しております。データインポート処理の解説はまた後ほど。
では続いてGKE、Firestore周りについてもう少し詳細に解説していきます。
先ほど述べた通り、全てのアプリケーションはGKE上で稼働しています。GitLab CI / Cloud Buildを使い継続的インテグレーションを、Argo CDを使った継続的デリバリーを実装しています。なお、商用環境の監視ツールとしてDatadogを使っています。
続いて、Firestore周辺のアーキテクチャです。SoR系システムからファイル転送されたデータをどのように扱っているか。処理の流れとしては、SoRのシステムがS3にデータを置いてくれた後、われわれの手でS3からGCSへ転送し、Dataflowを並列で使いFirestoreへインポートしています。これらワークフローのオーケストレーションとしてCloud Composerを利用しています。
このインポート処理がなかなか曲者でして。今回はSoRの制約上、お客様総数にあたる7,600万件のレコードを日次で洗い替える必要がありました。障害復旧の観点からすると差分より全件の方が楽なのですが、気になるのは処理の時間です。
Google社とも議論した結果、あらゆる業務要件を加味するとデータベースとしてFirestoreを利用するのがベストと決めたものの、いざ実際構築してからの性能チューニングが今回一番苦労した点です。
短時間でFirestoreにデータをインポートするために実施したことをご紹介します。
まず、今回Dataflowを並列で走行させデータを流し込んでいるのですが、並列処理の場合、リクエストが正しくてもエラー応答となる場合があるためリトライの機構が必要です。例えばリクエストの上限数超過、Firestore側が過負荷によってたまたまエラーになることが起きえるので。
とはいえ、リトライ処理だけに頼ればいいかというとそうではなく、短時間で処理は済ませるためには、エラーを極力起こさないよう努めることが大事です。
工夫した処理のうちもっとも印象的だったのが、「500/50/5ルール」です。Firestoreはリクエスト量に応じて段階的にスケールする仕組みなため、一度に多くのリクエストを送るとスケールが間に合わずエラーとなります。これはFirestoreの仕様です。もっとも効率よくFirestore側が処理できるように、この「500/50/5ルール」に乗っ取りリクエストを投げることが肝です。
具体的には新しいコレクションに対するオペレーションは、毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やすという考えです。公式ドキュメントにはちゃんと書いてあるものの、初めて知ったルールだったので驚きでした。
それを知らずに無邪気に大量のリクエストを投げてしまいですねGoogle社のSREチームをびっくりさせてしまったので、みなさんも大量のリクエストを投げる際はぜひこのルールを覚えておいてください。
この性能チューニングの工夫話はもっと色々あるのですが時間がないため割愛します。詳細は私たちのチームのSMがQiitaにまとめてくださったので興味ある人はぜひご覧になってください。
Firestoreの性能チューニング(Qiita)
Cloud Firestoreのベストプラクティス
今回お伝えしたかったのが、SoRとの連携は制約の中で最善を探し求めるということが大事ということ。SoRのシステムは標準技術に移行できていないことも多く、制約がつきものです。そうなると完璧なアーキテクチャは組めないかもしれませんが、その中で最善を見つけるのがアーキテクトとしての腕の見せ所なのかなと思います。
GCP (GKE) 導入の背景と決め手
続いて、GCP (GKE) 導入の背景と決め手です。われわれのチームは今回のプロダクトではじめてGKEを利用しました。そもそもなぜ使うに至ったのかをお話していきます。
Kubernetes自体は初めてではなく、2017年10月に組織が発足してからKubernetesベースのPaaSをずっと利用してきました、パブリッククラウド上に構築して。
当時、マネージドk8sを採用しなかった理由は、構築中であった社内のプライベートクラウド上の存在によるところが大きいです。将来的にはパブリッククラウドではなくできるだけ自社のクラウドへお引越することという大前提があったため、IaaSと疎な製品を採用しました。
注意して欲しいのでが、パブリックかプライベートかどちらか一方が正義という話ではなく、安心感のためか当時はできるだけプライベートに載せたいという考えの方が多勢だっただけです。あと、マネージドk8sの導入事例自体も少なかったかなと。
その結果、あえてIaaSとPaaSを分離した構成を採用したのですが、１年半の運用を経て、運用面、機能面、コスト面で改善ポイントが浮き彫りになっていました。
当時の環境が抱えていた改善点は大きく３点です。
もっと手間なく、楽に効率的に運用したい
管理対象範囲はIaaSレイヤ以上のすべてとなり、運用コストが大きかったです。基盤のアップグレードやノードのオートスケールするのも一苦労な状況でした。周辺機能を手軽に利用したい
CI／CD周りのサポートやロギング、モニタリング機能を実装しようと思うとどうしても他製品を使わなくては実現できないことが多く、商用利用を想定すると周辺機能が心もとない印象でした。
３. 必要な時に必要な分だけ費用を払いたい
ライセンスベースの課金体系（コア数・年単位）のため、開発ピークに合わせてライセンスの事前購入が必要なため、遊びが発生している状況で。
これら課題はPaaSとIaaSが分離しているが故なことが多かったため、改めて2019年4月からマネージドk8sのPoC/評価を実施しました。
第一に、そもそもPoCすることができたのは、ミッションクリティカルなシステムでのパブリッククラウドの導入実績が増えたことが後押しがあったからです。あらゆるものを自社で持つのではなく、オンプレとパブリッククラウドを使い分けようという時代の流れに乗れたのはあります。
われわれはGKEを含むマネージドk8sをいくつかPoCしたのでしが、大きな観点は３つ。
- マネージドk8sでも今までできていたことが実現できるか
- 課題が解決できるか
- 自分たちだけで構築、運用保守が賄えるか
細かな評価観点は割愛します。正直、よっぽど特殊な要件がない限り、マネージドk8sのサービスの何を選んでも間違いではないです。大きな機能的な差異もないと思っています。
ではなぜ、われわれはGKEを選んだのか？決め手はこちらです。
-
ランニングコストが安いこと
GKEはmaster nodeにお金がかからないため、他製品と比べて安価に維持できました。 -
ドキュメントが豊富で分かりやすいこと
実はGKEを触ったことがあるメンバーはゼロだったが、Qwiklabsや公式ドキュメントを参考にスキルを習得できたのは大きな自信にもなりました。 - （ミーハーではあるが）k8s生みの親である安心感
このような理由からわれわれはこのプロダクトにおいてGKEを採用しました。
今現在、他のプロダクトでもGKEを基本使うことにしていますが、今後はGKEだけではなくGAEやCloudRunといったより運用が楽に手間なくできる基盤も採用していきたいと思っています。
エンタープライズ企業で新たな取り組みを行う上でのポイント
続いて、われわれのようなエンタープライズ企業で新たな取り組みを成功させるポイントについて経験談交えてお話していきます。
この中でにもエンタープライズ企業に勤めている人、もしくはその人たちを支援するいわゆるSIの方多くいますよね。エンタープライズ企業でアジャイルやDevOpsといった新しい概念や文化を導入するのは難しいなというイメージを持たれているんじゃないかなと。その原因って何だろうかすこし頭の中で考えてみてください。
私が考えるエンタープライズ企業ならではの事情、壁はこちらです。
もっとも大きいのがエンジニアリングリソースがないことかなと。アジャイルやDevOpsの文脈では、ユーザ企業やSIといった会社の垣根なんて関係なく１チームであることが大前提です。会社が分断されている方が望ましいと思う人はこの会場に誰もいないと思います。この前提のもと、外部のパートナー企業の力を借りてどのようにアジャイルなマインドや文化を築いていくか？
もうひとつが、これまでの実績や既存システムが多くある中で、新しい取り組みをどう提案・導入していくのかです。同規模の他社事例も多くはない中で、どう合意形成していくのか。
他にも色々あると思いますが、間違いなく当てはまる２つかなと。
私が大事だと思うのは、「内製開発チームに近い環境を作る」ことと「小さく始める、まずは試す」を実践することです。
具体的に何を意味するのかをを話す前に、まずはこちらの写真をご覧ください。
左の大きな写真は私たちの組織が発足した当時の使っていた小部屋です。机とイス、パソコンしかなく、メンバーもたった5人でして、この部屋の中でスタートしました。POが私、パートナーからSM1名、Devloper3名という体制です。
小さく写っているのが現在のフロアで、パートナー含めメンバーは100名弱にも拡大しました。本プロダクト含め、複数のスクラムチームで複数のプロダクトを開発、運用しています。
歴史とともにチームの人数も環境も変わってきましたが、内製開発に出来るだけ近づけるためにやってきたことがこちらです。
全員が同じ拠点で、同じフロアで、一緒に働く
超基本的な考えですが、全員が同じ拠点で、同じフロアで、一緒に働くことです。会社間の壁などなく、違いは首から下げているストラップの色ぐらい。会話量がチームの結束力を高める、意思疎通がスムーズになることは間違いないです。組織が成熟してきたらリモート開発も良いかもしれませんが、まずは対面で働くことを優先しました。また、秘匿情報を除き、あらゆる情報をオープンし情報の非対称性をなくすことも大事です。会社の垣根を超えてコミュニケーションする
パートナーも１社だけではなく多くの会社からきてくれているので、会社の垣根を出来るだけなくすようコミュニケーションの回数も意図的に増やしてきました。バザー形式のプロダクトレビューを開催したり、週１回持ち回りで開催している勉強会をやったりですね。パートナーと一緒にスキルを伸ばす風土を作る
正直な話、われわれはもちろんのことパートナーもアジャイルやDevOpsにチャレンジしている最中で、スキルをもっているひとばかりではありません。なので、パートナーと一緒にスキルを伸ばす風土も大事です。例えば、生々しい話をすると、われわれの予算でチーム全員で社外の研修を受けたり、外部講師を呼んで勉強会したり。このようなバックアップをしてくれている組織、上位層にとても感謝してます。
２つ目が小さく始める、まずは試すことです。
今まで組織に無い技術なので、使って試して効果を見せるしかないです。われわれは新たな手法や技術は小さく試し徐々に適用範囲を広げていきました。
われわれがアジャイル開発手法を導入した際は
- トライアル案件
- 社内向けアプリ
- コンシューマ向けアプリ
という順に適用しました。並行して社内のルールなども整備してきたため、ここに至るまで＊＊約2年半**かかっています。＊＊根気のいる工程ですが合意形成のためには避けられない＊＊こともあります。
また、机上検討で頑張りすぎないことですね。技術の移り変わりも早いことと、安価にすぐ試せる技術ばかりなので、まずはやってみる精神が大事です。
加え、会社が複数にまたがる状況を踏まえ、私個人が重要だと感じたのがエンタープライズ企業のメンバーも最低限のエンジニアリングスキルを身に着けることです。
パートナーにはできない社員しかできない役割は、スピード感を持って判断し、説明責任を果たすこと。裏を返すと、これができず意思決定をのんびりしていたら今までの話は水の泡です。社員がボトルネックになってはダメです。
そのためにも、最低限のスキル習得は必要だと思います。恥ずかしいかな、私自身チームを立ち上げた際はアジャイルのアの字も知らない、プログラミングもしたことのない状態でした。私がやった具体的な学習方法はこちらです。やり方は何でもいいです。
- 認定資格やカンファレンスを通して机上で学ぶ
- Webアプリケーションをひとりで作ってみる
- Qwiklabsなどのオンライン学習サイトでGCPの基礎を学ぶ
決して、社員がエンジニアになれといっているわけでなく、パートナーと対等に会話をし、意思決定さえできる状態であれば十分です。意思決定するには当然権限も必要なので、上位層の方々はちゃんと現場に権限を移譲してくださいね。
とはいえ、われわれも道半ばで、やることは盛りだくさんです。
Bizを巻き込み、会社全体でアジャイルなチームを作るにはどうすればいいのかは模索中です。われわれはたかが開発部でしく、Bizもセットでアジャイルなチームにならないと片手落ちです。彼らをどう巻き込んでいくのかが今後の課題です。
また、大規模プロジェクトにおける最適な開発の進め方も模索中です。
例えば
- 基幹系システムの開発も伴うケース（手戻りが許容できない）や
- 多くの部署が絡む利害関係者が多いケース
において、意思決定をどうデザインするのがいいかの解をまさに今探している最中です。
こう見ると、エンタープライズ企業ではいわゆるWeb系企業にはない課題や壁が多くあります。ただ、まず最初の第一歩さえ踏めれば先が見えてきますし、伸び代しかないです。こういうカンファレンスでもユーザ企業の事例発表がどんどん増えると嬉しいなと思います。
NTTドコモ、自組織のこれからのチャレンジ
最後に、NTTドコモ、自組織のこれからのチャレンジです。
パーソナルデータダッシュボードは新たな価値をお客様に提供するするための第一歩です。これからデータを活用しお客さまや社会へ新たな価値の継続的な提供をしていきます。
開発組織としては、変化の早い市場に対応するためにサーバレスも活用していきたいと思います。
あとは、情報システム部全体でシステムをモダナイゼーションですね。SoEだけでなくSoRも含めて最適化する必要があるので、APIの拡充、SoRの標準技術移行も行なっている最中です。
本日の講演のまとめです。
- 当社情報システム部ではSoEとSoRを分離し、SoEはアプリケーションをいかに早くできるかを追求し、アジャイルな開発体制を築いています
- SoRとの連携は制約の中で最善なアーキテクチャを見つけることが大事
- エンジニアリングリソースを持たないエンタープライズ企業での工夫点
- 内製開発組織に近づける環境づくりが第一歩
- パートナーと一緒に社員自身のスキル向上も必須
- Biz含め会社全体でアジャイルなチームを作るのが次のステップ
エンタープライズ企業でこれからチャレンジしようとしている方へ、少しでも前に進むきっかけとなる話ができていたのなら嬉しいです。本日お話した話はGoogle社の事例インタビュー記事にもしていただいたので、もしよろしければこちらもご覧いただければと思います。2月中旬公開予定とのこと。
あとがき
登壇後、多くの方に声をかけていただいたりTwitterでもコメント頂いたりと反響が大きく、みな同じ悩みを抱えながら前に進もうとしているんだなぁと実感しました。発表の中でも述べたように、エンタープライズ企業で新たな取り組みをしようと思うと壁やハードルが多いのは否めません。ただその中でも模索しながら前に進むことが大事であるし、大変だからこそのやりがいもあるのかなと。
今回のカンファレンスでは主にGCP周りについてお話ししましたが、今回のプロダクト開発は他にも話すネタはたくさんあるのでどこかでいつか話してみたい。
- ステークホルダーが多く意思決定のデザインに超絶苦労した話
- Bizと一緒にワークショップ形式で仕様を徐々に固めていった話
- ウォータフォールで開発するSoRと足並みを揃えて無事サービス開始までこぎつけた話
- LeSSという大規模スクラムを組織として初導入した話
- アジャイルにおける品質の考え方、担保の仕方を真面目に考えてみた話
最後に、チーム発足からこれまでに関わってくれたメンバー全員に感謝です。何もないところから組織を一緒に作り上げてくれたみなの頑張りをこうやって日の目を見させることができて本当に嬉しいです。僕らのやるべきことはいいプロダクトを作ることです。まだまだやることは盛り沢山、引き続きチャレンジしていきましょう。