CloudNative Days Tokyo 2019：あえてK8sを選ばなかったSoftBankペイメント

CloudNative Days Tokyo 2019では、クラウドネイティブなシステムがメインとなってツールやプラットフォームの紹介がなされたが、エンタープライズにおいては無条件にKubernetesが選択されるわけではない。

今はコンテナとそのオーケストレーションソフトウェアであるKubernetesが多くの注目を集めているが、まだDockerを始めとするコンテナが注目される以前、アプリケーションを開発してそれを実行するためのプラットフォームとして、PaaS（Platform as a Service）に関心が集まっていた時期がある。

PivotalのSenior VPでCloud Foundryに永く関わっているOnsi Fakhouri氏がCloud Foundryの真髄を表現するために書いた

here is my source code
run it on the cloud for me
i do not care how

という2015年5月のツイートが残っている。

cf push haiku

here is my source code
run it on the cloud for me
i do not care how

— Onsi Fakhouri (@onsijoe) May 12, 2015

この言葉、コミュニティではCloud Foundry Haikuと紹介されており、アプリケーションを開発するデベロッパーにとって開発したソースコードがクラウド上で実行されることこそが重要で、その形式やインフラストラクチャーには注意を払う必要がない。そしてそれを体現しているのがCloud Foundryである。筆者はそのような意味であると捉えている。また先日、インタビューを行ったCNCFでServerless WGのCo-Chairを務めるIBMのDoug Davis氏も、PaaS、CaaS（Container as a Service）、Serverlessの区分けにはあまり意味がなく、必要な機能がどのように実行されるか、それが仮想マシンを要求するものか、コンテナで実行されるものか、サーバーレスとして実行可能なものか、それはユーザーが決めるべきという発言をしている。

コンテナの再発見からKubernetesに至るここまでのクラウドネイティブなシステムよりも以前に、デベロッパーに利便性を与えること目指してPaaSを作り上げたHerokuがSalesforceに買収された後に減速し、Cloud Foundryに遅れをとったRed HatのOpenShiftはv3で方向転換を行い過去のコードを全て捨ててKubernetesのプラットフォームとして再出発し、大成功している。そしてアプリケーション開発の大原則としてHerokuが提案した12ファクターアプリケーションを提唱するPivotalは、Cloud Foundry Foundationを創設、その後、Linux Foundationのコラボレーションプロジェクトとして活動を続けている。Cloud Foundry自体はオープンソースソフトウェアとしてのCloud FoundryとPivotalがサービスを提供する商用版のPivotal Cloud Foundry、そしてCloud Foundry上でKubernetesを実行するPivotal Kubernetes Servicesに発展を遂げている。ある意味、Cloud Foundryはクラウドネイティブが目指していたものを早い段階で実現していたとも言える。

そんな前口上はこのぐらいにして、2日目のセッションで発表されたSoftBankペイメントサービスのシニアアーキテクト、鈴木順也氏の講演内容を紹介しよう。

プレゼンテーションを行う鈴木順也氏

「決済システムの内製化への旅 ～SpringとPCFで作るクラウドネイティブなシステム開発～」と題されたセッションである。

鈴木氏の講演の主な内容

2016年に設定されたチームとしての最初のゴールは「システム運用の効率化」であったという。つまり2016年の段階では開発チームはSBペイメントの中にあったのではなく、外注化されており、開発は外部のベンダー、運用だけは社内チームという体制をとっていた。それを社内の開発チームに移管していくというのが、今回のタイトルの「内製化への旅」の意味するところだろう。

これは日本の多くの事業会社が抱える共通の課題で、仕様策定は外部と社内の協業、開発は外部に委託、運用は社内の運用チームという体制でこれまで多くのシステム開発が行われてきたと思われるが、SBペイメントはそれを変えることに成功したという内容だ。

最初の目的は運用作業の自動化

そして2017年の段階で、Springをベースに開発を行うためのツール群の導入が終わり、これで開発の内製化、CIを回す体制が出来上がったという段階になった。

Spring BootとSpring Cloudを導入

そして2年の準備の後、2018年に開発の内製化がスタートしたという。

開発の内製化スタート

開発したのは、決済システムの加盟店と決済機関の中間のハブとなる部分で、APIによって実装されるWebベースのシステムである。

加盟店と決済機関の中間のシステムを開発

開発に際しては、かつてのベンダーに任せる形から自社での開発、開発～リリースのサイクルの高速化、監視が容易で障害に強いことなどが要点として挙げられていたという。

内製化のポイント

結果としてPivotal Cloud Foundry（以下、PCF）とその純正CIツールであるConcourseを選択し、導入したと語った。ここでの選択肢には当然のようにKubernetesが入っていたという。そしてKubernetesではなくPCFを選んだ理由として、当時のKubernetesの学習コスト、メンテナンスコストの高さ、構築に必要な時間、小さな規模のチームでは運用が困難という理由を解説した。

KubernetesではなくPCFを選択

冒頭に紹介したCloud Foundry Haikuのように、コードを書いてすぐに実行できる環境というポイントで、PCFがKubernetesに比べて優れていたことを紹介した。

コードの開発に集中し、すぐにコードを実行できることが重要

これは、Kubernetesを導入したいが自社のIT部門がそれほど大きくない中小企業には参考になるアプローチだ。つまりビジネスロジックを実装することに100％注力するのか、インフラストラクチャーを整備することに力を注いでその後でコードを書くことに注力するのか？　という選択肢だろう。

組織によってはまずインフラストラクチャーからという選択肢があっても良いし、それはその企業の優先順位に依存すると言える。ただ、SBペイメントのように数名のエンジニアしか資源がないのであれば、選択肢は自明だろう。

重要なのは導入と運用のサポートがあるかどうか

そしてその少数のエンジニアの配分を解説したのが次のスライドだ。

アプリ開発とインフラ担当の責任分担

6名のうち2名をPCFの運用に、4名をアプリケーション開発に配分していることがわかる。また開発するアプリケーションも、Pivotalが推奨する12ファクターアプリケーション、つまりKubernetesのようなステートレスなアプリケーションだけを開発するということが明記されている。またベンダーロックインを排除するということも書かれており、開発チームの強い意志を感じることができる。

全体のアーキテクチャーもクラウドネイティブなコンポーネントで構成

このアーキテクチャー図を見ると、中心となるプラットフォームのPCFをKubernetesに置き換えればそのままKubeConのユースケースと言っても通るくらいほどに、オープンソースソフトウェアで構成されている。

また加盟店と決済機関の中間に存在するシステムであることから、外的要因によってシステム障害が伝搬することを防ぐために、Hystrixが使われていることを紹介し、ここでも障害に強いシステムとなっていることが紹介された。Hystrixは、Netflixが開発し公開しているCircuit Breakerのためのライブラリーだ。

Netflix製のCircuit BreakerであるHystrixを使用

CIについてはPivotalがCloud Foundryの開発に使っていることで有名なConcourseを使っており、この辺りもPCFとの相性の良さを重視した結果だと思われる。

CIはパイプラインで管理できるConcourseを使用

パイプラインはテスト環境と本番環境がキレイに分離されており、ここでも12ファクターアプリケーションの原則に則った運用が行われていることがわかる。

Concourseによるパイプライン処理。テストと本番を分離

システムの監視についてはPrometheus、Grafana、Zipkinなどを利用して、システム目線だけではなくサービス目線でのモニタリングが可能になっているという。これも参考にすべきポイントだろう。

サービス目線のモニタリング

最後に、内製化によって決済プラットフォームの構築が可能になったこと、そのためにPCFというすでに完成されたアプリケーション実行プラットフォームとサービス・サポートが重要と語って講演を終えた。

短い期間でアプリケーションの内製化という目的を達成するために、学習コストの高いKubernetesを諦めてPivotal Cloud Foundryを選んだことで目的を達成したというユースケースは、内製化を含むクラウドネイティブなシステムに移行したくても躊躇している企業のIT部門にとって非常に参考になる内容となった。PaaS、Kubernetes、そして今後はサーバーレスまで、多くの選択肢があることで悩むIT部門は多いだろう。

メルペイが開発部門の効率を上げることを優先してマイクロサービス化したように、まずは開発運用部門の最適化を目指して選択を行うというのも一つの考え方である。

参考：CloudNative Days Tokyo 2019：メルペイのマイクロサービス化の目的とは？