「チームの分離」と「重力圏内にとどまる意識」がポイント　レジェンドのジレンマを脱出するためにクラウドネイティブの種をまく

セッションの概要

駒井直氏（以下、駒井）：「計画と統制の文化にクラウドネイティブの種をまく」というタイトルで、この時間はお送りしたいと思います。

ちょっと想像してください。あなたはこう言われます。「現状の決済システムには、キャパシティの硬直化や、密結合なモノリスのアプリなど、アーキテクチャに起因して、将来のスケールを阻害しそうな要因がある。これを、クラウドネイティブアーキテクチャのアプローチで解決できないか」と。「あなたが、そういうエンジニアリングをリードしてみないか？」と言われたとすると、このイベントに参加しているみなさんは、恐らく「挑戦したい」と言うでしょう。

そういう気概や、スキルを持つ方がここに集まっていると思っています。ただ、ここで上司が言い忘れていて、「このサービスは、年間6兆円の決済を扱うから」とか「事業は年25パーセント成長をコミットしているから、それを阻害しないでね」「もちろん、企業としてITの各種統制準拠は当然だし、クレジットカードを扱うので、PCI DSSも忘れないで。そんな中でのアーキテクチャの革新だけど、1つお願いしますね」と言われると、躊躇すると思います。

それは正しいと思います。そういう定量的、定性的な責任を見て、安請け合いはできません。どうしたって、変化の過程で考えられえるリスクを考えて、躊躇すると思います。ということで、このセッションの要旨は以下のとおりです。

現在、非クラウドネイティブなシステムに携わっていて、そこで起きる問題解決のアプローチとして、クラウドネイティブアーキテクチャに可能性を感じている。しかし、目先の責任と変化のリスクを考えて動けないジレンマに陥っている、と。

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

逆に、こういった方は向かないと思います。ビフォークラウドネイティブからクラウドネイティブが始まったという「from・to」の話なので、事業が生まれたときから文字どおりクラウドネイティブ派、Born with Cloudの方には、fromの課題がピンと来ないと思います。また進め方の話などで、実装技術の掘り下げは一切出てきません。

自己紹介

ここまで話したところで、遅ればせながら自己紹介します。駒井です。2009年から、GMOペイメントゲートウェイに所属しています。GMOペイメントゲートウェイは、決済サービスを提供する会社です。年間6兆円の決済金額を支えて、上場以来、25パーセント前後の営業利益成長を続けています。

そんな会社で、現在の主力サービスの立ち上げから6、7年関わった後、今は新規事業やサービスの立ち上げにおいて、システムだけでなく、プロダクトデザイン全体にエンジニアとして関わっているのが私の職責です。“サービスアーキテクト”と名乗ったりしています。エンジニアのスキルセットのベースとしては、Javaでサーバーサイドアプリケーションを書くことがあります。

そこをベースして、フロントエンド、インフラ、システム全体のアーキテクチャ、さらにはプロダクト全体と領域を広げたキャリアを描いてきました。そういう人間が話すと思ってください。

“クラウドネイティブ”とはどういうことか

今日のセッションで前提になる、2つのことを共有したいと思います。そもそも“クラウドネイティブ”はどういうことで、“クラウドネイティブではない”はどういうことかをいったん定義しておきたいと思います。（スライドを見て）この場では、こう定義します。

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

このあたりの、特に“クラウドネイティブとは”という定義は、CNCF（Cloud Native Computing Foundation）の定義にとどまらず、今回登壇している、あるいは視聴しているみなさんが、それぞれ一家言をもっていると思うので、あくまでこの場で私が定義していると理解してもらえればと思います。また、その枯れた技術を“レガシー”と呼ばないのは、“レジェンド”として結果を出し続けている事実があって、それがイコール高水準に完成されていった結果だと思います。そのため、リスペクトを込めて“レジェンド”と呼びたいと思います。

レジェンドを支えるシステム構成

では次に、当社のレジェンドを支えるシステムの構成を、ざっくりと説明します。ほぼ100%オンプレミスのデータセンターで、KVMのホスト300、ゲスト1,500。その上に、お客さんに提供するサービスとして、約60動いている。定量的には、ざっくりとこんな感じになります。中規模ぐらいですかね。2012年頃からこのかたちです。このインフラ上に、主にJavaで書かれたアプリケーションが動いています。

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

クラウドネイティブの芽を出すポイントの1つは「チーム作り」

そんな中で、なんとかクラウドネイティブの芽を出すポイントについて、2つ紹介します。1つ重要だと思っているのは、チームを分離して進めたことです。このレジェンドの部分については、どうしても6兆円の決済、25パーセント営業利益成長の責任を求められます。ちなみにこの“6兆円”は成長を続けていて、昨年別のイベントで登壇したときには5兆円と話していました。

精査したところ、今は6兆円が正しいので、6兆円にしました。それに対して、レジェンドのアーキテクチャで成果を出し続けている事実があります。この状況では足元の課題は認知していたとしても、変わるリスクのほうをどうしても大きく評価せざるを得ないことは、一定の想像ができると思います。

変わらないこと自体へのリスクはわかっていて。それは絶対にリスクですが、ただ、目の前の責任がどうしても先です。これが現場リーダーを躊躇させる要因です。そのため、チームを分離して進めました。幸いにも、ある新規事業の立ち上げ機会があり、その機会でレジェンドのチームからスピンアウトしたかたちで分離、独立したチームを作りました。

チームを分離することで、変わるリスクをほぼ無視し、変わらないことのリスクだけをピックアップしてどんどん突っ込んでいける。そのため、そのプロダクトではレジェンドの踏襲を考慮せずに、インフラは全クラウドに置くと。

その中で、ビルドonceがイミュータブルなコンテナイメージでライフサイクルを回せました。また、OpenAPI Specで定義された宣言的なAPI群が、マイクロサービスとして話し合っているようなクラウドネイティブの要素をふんだんに盛り込んで、ゼロベースのアーキテクチャでサービスを構築できました。

文字どおりのネイティブです。このサービスは、生まれたときからクラウドです。これを、もしレジェンドのチームの中に、例えば“クラウドネイティブ推進”みたいなメンバーを置いたとしても、現状の責任を果たすメンバーとの間で求められる責任や物事の判断の優先度が違ってしまい、お互いがブレーキをかけ合ってしまうと思います。

そうすると、革新するほどのスピードは出ません。「ちょっと部品としてクラウドサービスを使ってみました」にとどまってしまうので、いったん分離してゼロから出発してください。新しいアーキテクチャのチームには「前のめりに取り組んでください」と使命を与えることで、強力に大胆に推進できます。

「重力圏内にとどまる」意識も重要

しかし、あまり突っ込み過ぎてしまうと、別の課題が出てきます。その課題と進め方のポイント2つ目を話します。もう1つ重要だったことで「重力圏内にとどまる」と書きました。レジェンドは日々の責任を堅実に果たしています。一方で、スピンアウトしたクラウドネイティブのチームは、ひたすら先鋭的に磨き込みます。

これが続くとどうなるかと言うと、同じ1つの会社組織の中に、相互に無関係な2つのアーキテクチャ、2つのチーム文化がただそこに存在する状態になってしまいます。これだと、クラウドネイティブアーキテクチャで取り組んだ意味合いが薄れてしまうわけです。

なぜなら、この青い大きなレジェンドの部分である6兆円の責任を果たすために、問題解決のアプローチとしてクラウドネイティブを取り入れたはずなのに、レジェンドの現状とかけ離れてしまって、響かなくなってしまう。「あのオレンジの人たちはああだから、俺たちは違うんだ」ということになってしまいます。

そのため、チームを分離して突撃したといえど、クラウドネイティブのチームは、レジェンドの重力圏内にとどまっていてほしい。特に地道なオペレーションの要件です。アクセス証跡やモニタリング、デプロイ作業。弊社で言えば事業上切り離せないPCI DSS（Payment Card Industry Data Security Standard）などの地道なオペレーションは、イコールで事業の実行なわけです。

そこがクラウドネイティブになったとき、どういう姿になるのかを具体的にイメージさせることで、レジェンドに対して地続きになります。モニタリングやメトリクスの指標は、例えばレジェンドのアーキテクチャでは、基本Active/Standbyのローリングアップデートでデプロイしていますが、コンテナクラスタになると、基本的には全Activeのノードで、デプロイはブルーグリーンで作って捨てる考え方に変わります。

また、PCI DSSの要件に照らして、レジェンドではHSMはハードウェアで暗号化、鍵管理を行っていますが、クラウドネイティブであれば、そのクラウドの事業者が用意したマネージメントな鍵のサービスを使って、ハードウェアのマネージから解放されます。

日々回しているオペレーションが、クラウドネイティブになったときにどういう姿になるかを具体的に定義することで、レジェンドとクラウドネイティブを地続きにして、自分たちもあそこに行けるイメージを、よりクリアにもってもらえます。これは、スピンアウトしたクラウドネイティブのチームにとっては、ある意味個別最適が許されないことになります。

私は実際にこのスピンアウトしたチームのリードエンジニアで、今もそうです。あるサービスはクレジットカード番号を扱わないので決してPCI DSSに対して直接厳密な準拠は求められませんが、もしそのPCI DSSの審査を受けたらこういうことが指摘されるかな、とか、この要件は実装しておくべきかな、のようなことを想像しながらやらなければなりません。特定のサービスにはいらないものの、全体最適を考えないといけない。

最終的にこの成果はレジェンドに対して持って帰って、花を咲かせることが必要なので、そのくびきだけは意識する必要があります。これを一言で言うと、“レジェンドの重力圏内にとどまる”ということと思っています。

“花が咲く”までにはまだ時間が必要

まとめに入ります。大きく取り上げた2点を意識することで、チームを分離して、ジレンマから解放しつつ、レジェンドと地続きの部分を忘れないという取り組みを継続することで、クラウドネイティブアーキテクチャで構築されたサービスを2020年に当社は3つリリースしました。2021年には2つ以上のサービスもクラウドネイティブアーキテクチャによって構築して、プロダクションが開始されると思います。

以上が、当社でレジェンドのジレンマを脱出してクラウドネイティブの芽が出た体験談になります。まだ当社は、芽が出た段階です。レジェンドに書かれている60のサービスからクラウドネイティブにシフトが始まって、クラウドネイティブでレジェンドのサービスが提供できている状態が、本当に“花が咲く”ことだと思いますが、そこには若干の時間が必要かと思います。

しかし、確実に芽生えはもたらせました。本日の話が少しでもみなさんの参考になれば幸いと思います。以上、ご清聴ありがとうございました。