計画と統制の文化にクラウドネイティブの種をまく【CNDO2021登壇レポート】

「計画と統制の文化にクラウドネイティブの種をまく」というタイトルでこの時間をお送りしたいと思います。

はじめに

--あなたがこう言われたら

早速ですが想像してみてください。ある日あなたは上司からこう言われます。

「現状の決済システムにはキャパシティの硬直化、密結合なモノリスのアプリなど、アーキテクチャに起因しで将来的なスケールを阻害する要因がある。クラウドネイティブアーキテクチャのアプローチで解決できないか。」

「君、エンジニアリングをリードしてみないか？」

といわれたとすると、CloudNative Daysに参加していただいているような皆さんは挑戦したいと回答するでしょう。そういう気概やスキルを持っていると認識しています。

--言い忘れたこと

しかし、上司は言い忘れていました。

「このサービスは年間6兆円の決済を扱うから。」
「あと、事業は年25％成長をコミットしているから、阻害しないでね。」
「もちろん、企業としてITの統制準拠は当然ね。クレジットカード扱うのでPCI DSSもよろしく」
「そんな中のアーキテクチャの革新だけど、お願いね。」

このように言われると、皆様躊躇すると思います。
それは正しいことです。定量的、定性的な責任を見て安請け合いはできないです。
どうしたって変化の過程で想定されるリスクを考えて躊躇してしまうと思います。

このセッションの要旨・対象

このセッションの要旨は、
・Notクラウドネイティブのシステムに携わっていて
・そこで起きている、問題解決のアプローチとして、クラウドネイティブアーキテクチャに可能性を感じている
・現業の責任とリスクを考え、動けないというジレンマに陥っている

このようなチームのアーキテクト、リードエンジニアの方に対して同じようなジレンマを抱えている当社において、クラウドネイティブアーキテクチャの種をまき、なんとか芽を出したアプローチをお話しします。

このセッションでは物足りない方

逆にこういった方は向かないと思います。
Beforeクラウドネイティブからクラウドネイティブが始まった、From Toの話ではなくて、事業が生まれたときからクラウドネイティブ、Born With Cloudという方には、Fromの課題がピンとこないと思います。
また、進め方の話のため、実装技術の話は出てきませんので、ご容赦ください。

自己紹介

ここまで話したところで、自己紹介させてください。
駒井と申します。
2009年からGMO-PGに所属しています。GMO-PGは、決済サービスを提供する会社です。年間6兆円の決済金額を支えて、上場以来25％前後の成長を続けている会社です。
そんな会社で現在の主力サービス立ち上げ時から設計、プログラミング、システム運用、セールス支援など6年程度携わった後に、現在新サービスのプロダクト設計、エンジニアリング支援全体に関わっているのが、私の職責となります。
サービスアーキテクトと名乗っています。
エンジニアのスキルセットのベースとしてはJavaでサーバーサイドアプリケーションを書くということがあります。そこをベースにして、フロントエンド、インフラ、システム全体のアーキテクチャ、そしてプロダクトと領域を広げてきました。
そういう人間がお話しするとお考え下さい。

クラウドネイティブの定義、そうでないことの定義

今日のセッションで前提になる2つの前提を共有します。

そもそも「クラウドネイティブとはどういうこと」で、「クラウドネイティブではないとはどういうことだろう」というのをいったん定義しておきたいと思います。

この場ではこう定義させていただきます。
「『クラウドネイティブ』とは、
変化に対する許容度をあらかじめ限定せず、形を変えて滑らかに変容していく性質を持つアーキテクチャや組織文化」

それに対するものとして
「クラウドネイティブではないということは、5年程度の変化やリスクを可能な限り事前に可視化・予測しつくし、コントローラブルなものととらえて解決するアーキテクチャや組織文化である。これに『レジェンド』というラベルを付けます。」

ここでいうクラウドネイティブとはCNCSの定義にとどまらず、あくまでこの場で私が定義しているということでご容赦願います。
また枯れた技術をレガシーと呼ばないのは、レジェンドの形でひたすら結果を出し続けている事実があるので、イコール高水準で完成されているため、リスペクト込めてレジェンドと呼びます。

当社の「レジェンド」を支える構成

当社のレジェンドを支えるシステム構成をざっくりとお伝えいたします。
ほぼ100％オンプレのデータセンターでKVMのホスト300、ゲスト1500、その上にお客様に提供しているサービスとして60くらいが動いている。ざっくり定量的にはこれくらいの規模になります。中規模くらいでしょうか。
2012年からこの形です。インフラ上に主にJavaで書かれたアプリケーションが動いています。

この構成で、年間6兆円を支えています。
この規模・金額をみると、この中でクラウドネイティブのアーキテクチャを革新していくことはかなり強いジレンマがあるだろうなというのは、ご想像いただけると思います。

クラウドネイティブの芽を出すポイント2つ

そんな中、何とかクラウドネイティブの芽を出した時の、ポイントについて2つご紹介いたします。

1．チームを分離して進める

1つ、重要だと思うのはチームを分離して進めたことにあります。
どうしても、このレジェンドの部分は6兆円の決済、25％成長の責任を求められます。6兆円というのは成長を続けています。昨年私が別のイベントに登壇した時、処理金額は5兆円と説明していましたが、先般精査したところ今は６兆円となっています。
その成長に対して、レジェンドのアーキテクチャで成果を出し続けているという事実があります。

この状況では、足元の課題は、認知していたとしても、変わるリスクの方をどうしても大きく評価せざるをないというのは、一定のご想像をいただけると思います。
変わらないことのリスクがあることは承知しているものの、目の前の責任があるため、現場リーダーを躊躇させる要因となっています。

そのため、進め方としてチームを分離して進めました。
幸いにも、ある新規事業を立ち上げる機会があり、その機会にレジェンドのチームからスピンアウトし、分離独立したチームを作りました。
チームを分離することで、変わるリスクをほぼ無視して、変わらないことのリスクだけをピックアップしてどんどん突っ込んでいけました。

そのプロジェクトではレジェンドを考慮せず、インフラは当然クラウドに置くよね。そのなかで、ビルドワンスはエミュータブルなコンテナイメージでライフサイクル回せるよねとか。Open APIスペックで定義された、宣言的なAPI群マイクロサービスがおしゃべりしあっている。
クラウドネイティブ要素を盛り込みゼロベースでサービスを構築することができました。

文字通りネイティブで、
生まれた時からクラウドです。

これをもし、レジェンドチームのなかに「クラウドネイティブ推進匿名」というメンバーを置いたとしても、現業の責任者のもとで求められる責任・判断・優先度が違い、お互いがブレーキをかけることが生じます。そうすると革新するほどのスピードはでません。
部品としてクラウドサービスをつかってみたという程度にとどまってしまうので、分離して進めてください。
新しいチームには前のめりに進むようにすることで、強力に大胆に推進することができます。しかしながら、あまりに突っ込みすぎてしまうと、別の課題が出てきます。

2．重力圏内にとどまる

もう1つ重要なのが、レジェンドの重力圏内にとどまることです。
レジェンドは責任を日々堅実に果たしています。一方でスピンアウトしたチームは、新しいことに先鋭的に磨き上げます。
そうすると何が起こるかというと、相互に無関係な2つのアーキテクチャ、2つのチーム文化がただ存在するという状態になってしまいます。

これだと、クラウドネイティブに取り組んだ意味が薄れてしまうのです。なぜかというと、6兆円のレジェンドの責任をはたすために、問題解決のアプローチとして、クラウドネイティブを取り入れたはずなのに、レジェンドの現状とかけ離れると、もう響かなくなってしまいます。

「あの人たちはあぁだから、我々は違うよね」ということになってしまう。

チームとして分離したとしても、クラウドネイティブのチームにはレジェンドの重力圏内にとどまってほしい。特に地道なオペレーションの要件です。アクセス証跡だったり、モニタリング、デプロイ作業、当社で言えば事業上切り離せないPCI DSSなどです。
このように地道なオペレーションは、イコールで事業実行なわけです。これがクラウドネイティブになった時にどういう姿になるのかを、具体的にイメージさせることで、レジェンドに対して地続きになるわけです。

例えば、レジェンドのアーキテクチャでは基本アクトスタンバイのローリングアップデートでデプロイしているわけですけど、コンテナクラスタになると、基本的には全アクトのノードで、デプロイはブルーグリーンで作って捨てる。考え方が変わります。
あるいは、モニタリングやメトリクスの指標はこう変わっていきます。
また、PCI DSSの要件に照らして、レジェンドではHSM、ハードウェアで暗号化カギ管理を行っているところを、クラウドネイティブではクラウド事業者が用意した、マネージメントな鍵のサービス、インクリプションのサービスを使って、ハードウェアのマネージから解放される、などがあります。

日々回せるオペレーションがクラウドネイティブになった時に、どういう姿になるかを具体的に提示することで、「自分たちもあそこに行けるのだ」というイメージをよりクリアに持ってもらうことが出きます。
これはスピンアウトしたクラウドネイティブのチームについては、ある意味個別最適が許されないということになるということです。
私は、実際にスピンアウトしたチームのリードエンジニアだったわけですが、このサービスはクレジットカード番号を扱わないので、決してPCI DSSへの直接厳密な準拠は求められないわけですが、もしもPCIの審査を受けた場合「こういうことを指摘されるかな」、「この要件は実装しておいた方がいいかな」と想像しておかないといけないので、このサービスにはいらないけれど、全体最適を考える必要があります。
なぜなら最終的に、このサービスはレジェンドに持って帰って花を咲かせることが必要なので、そのくびきだけは意識する必要があります。
これを一言でいうと、「レジェンドの重力圏内にとどまる」ということかなと考えています。

まとめ

まとめに入ります。

クラウドネイティブの芽生え

GMO-PGではエンジニアの仲間を募集しています。
ご興味がある方はこちらから詳細をご確認ください。

採用情報はこちら

（by あなたのとなりに、決済を編集チーム）

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。