Powered by

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

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

本記事では2021年3月12日にGMOペイメントゲートウェイ(以下、GMO-PG)のエンジニアが登壇した、「CloudNative Days Spring 2021 ONLINE」のセッションの内容をお届けいたします。

※本セッションはエンジニア向けイベントに特化した書き起こしメディア「ログミーTech」にも掲載されました。

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

article-016_thumb01.jpg

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

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

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

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

article-016_thumb02.jpg

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

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

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

article-016_thumb03.jpg

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

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

article-016_thumb04.jpg

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

article-016_thumb05.jpg

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

article-016_thumb06.jpg

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

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

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

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

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

article-016_thumb07.jpg

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

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

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

article-016_thumb08.jpg

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

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

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

article-016_thumb09.jpg

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

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

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

article-016_thumb10.jpg

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

article-016_thumb11.jpg

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

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

article-016_thumb12.jpg

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

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

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

まとめに入ります。

article-016_thumb13.jpg

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

以上が、当社でレジェンドのジレンマを脱出して、芽が出た体験談になります。
まだ当社では芽が出た段階です。最終的に花が咲くというのは、レジェンドで書かれている60のサービスからクラウドネイティブにシフトが始まって、クラウドネイティブでレジェンドのサービスが提供できている状態になった時が、本当に花が咲いたということだと思います。
まだそこには若干の時間が必要だと思います。
ですが確実に芽生えはもたらすことができました。
今回の話が皆様の参考になれば幸いです。

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

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

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

SSL GMOグローバルサインのサイトシール