駒井と申します。
サービスアーキテクトと名乗っておりますけれど、ベースとしては、JavaでWEBサービスを書くエンジニアというところから、フロントエンド、インフラ、システム全体のアーキテクチャ、更にシステムだけではなくサービスの在り方みたいなところから設計していく、今はそういうポジションで仕事をしています。

「決済サービスをコンテナ＋クラウドで運用するということ（運用半年編）」というタイトルで、基本的にオンプレKVMというアーキテクチャで構築してきたエンジニアチームが、クラウド＋コンテナというアーキテクチャでプロダクションサービスを運用し始めて半年が経ちました。その中で実体験として、本当にこれは良かったなと思うところ、悪くはなかったが大変だったなと思う体験談をそれぞれ1つずつ絞ってお話しいたします。

さて、早速ですがみなさんがお仕事でコンテナをどれくらい利用されているのか、アンケートを取らせてください。

• コンテナの導入がどの程度進んでいるのか、
• ミッションクリティカルなところでご利用されている
• そうではないけれどもプロダクションで使っている
• そういうところを目指して検証している
• 試した結果辞めた
• そもそも取り組んでない、知りません。

など、どの程度お使いなのかということを教えてください。

どうしてもアンテナを張っていると、多くの人がこぞってコンテナを使っているように見えます。はじめに、今日ご参加いただいているみなさんはどのような状況なのかというところを知りたいのです。

ありがとうございます。
結果は回答が150近くある中で4分の1くらいの方が、ミッションクリティカルなところでご利用されているようです。導入を検討して辞めた方もいるとのことで、どういう経緯で辞めたのか興味があります。では、次に進みます。

前提

今日お話しする前提として、まず、当社のベースアーキテクチャは上図のような段階を踏んできています。基本的にはオンプレミスのデータセンターにKVMのホスト、ゲスト。だいたい1,500強のゲストOSがあります。その上で大小60のお客様へサービスを提供しています。並行して、まさに今年2020年から、3つのサービスをクラウドAWSにコンテナクラスタで提供するということを相次いで始めています。

こういうKVMで資産を積み上げてきたエンジニアチームが、クラウドコンテナに取り組んだ、そういう段階の人たちの感想であるという前提で聞いていただければと思います。

次に、今回私が直接かかわって題材にするサービスは、「こんど払い byGMO」というサービスです。これは住所不要で、電話番号・メールアドレス認証だけで可能な後払いサービスです。
GMO-PGの自社提供決済サービスです。これは、今年の5月にサービスを開始しています。クラウド＋コンテナクラスタで稼働しています。サービスの成熟度としては、2、3のお客様に使っていただいて一通りのビジネスケースにおいて、本番環境における実績ができ、いよいよ面積を広げるぞというフェーズにあります。

こんど払いは、だいたいこのような技術スタックで構成されています。コントロールブレーンは、ECSを選択しました。コンピューターリソースはファーゲートです。ファーゲートを選択したのが結構大きいのですが、その上にスプリングブートで書かれたマイクロサービスAPIのコンテナクラスタが、それぞれメッシュ状に通信しています。
WEB UIは、Vue.jsのSPAを提供していますので、それを提供するコンテナもあります。右下は通り一辺倒の、ユーザーベースなら誰しもが使うリソースが並んでいます。

pros.

では、プロコンのプロスのところをご紹介します。

1番今大きなものとして感じているのは、構成管理がすごく安定するという点です。
こんど払いのデプロイは、テスト済みdockerイメージを環境から、デベロップメント→ステージング、ステージング→プロダクションというように、テスト済みの同じイメージを吸い上げて、それをデプロイしていくという作りになっています。
さらにそのデプロイ、各環境のデプロイも新しいイメージが、イメージ環境のイメージリポジトリにプッシュされることをトリガーに、ブルーグリーンデプロイのテスト画面に新しいコンテナを作ります。そこで最終確認して問題なければトラフィックを切り替え、古い現行コンテナを切り替え、旧コンテナになります。
作って捨てるデプロイをしています。

これをすることによってオンプレ、特に素のOSにログインして運用しているとありがちな、

• 本番で動いているそれそのものが資産になってしまって、再現性がすごく難しい
• 作業を何か戻さなきゃいけない時にリカバリープランをすごく練ったりしなきゃいけない
• 同じことをやって、同じオールフォワードをする手順もしっかり考えていかないといけない

という点があると思いますが、その作って捨てる乱暴なやり方をすることで、そこから解放された、という感覚を今は持っています。

chef/ ansibleの構成管理はよくできているのですが、あくまで組み立て図であって、作業対象は本番リソースです。しかし、コンテナイメージをコーティングすると、完成品に持ってきて電源を入れ、今動いているものはもう捨てちゃおう、という乱暴な考え方です。
運用の強度としては一段上になるのではないか、と考えています。5月のリリース以降、述べ回数で、マイクロサービスに対しておそらく数十回アップデートをかけているなかでも、オペレーション事故は1つもなく遂行できています。
ちなみにansibleはオンプレでもインフラレベルのOSやOSパッチのアルヘイムリポジトリなどの管理では引き続き重宝して使っています。
いずれにしろ、この構成管理はコンテナクラスタで運用することですごく安定したなという実感があります。

cons.

続いて、プロコンのコンスです。
「オンプレ勢はクラウドリフトに迫られる（かも）」と書いたのですが基本的にはオンプレのインフラの上でサービスを提供していて、それは今後も全部なくすことはないため、むしろそのコア資産とクラウドリフト可能資産を色分けできるのではないかと考えています。

もしもオンプレでインフラを利用しているチームが、オンプレを変えずにコンテナクラスタを運用してみたいといった場合、アプリケーションのコンテナだとCPUやメモリー程度のリソースは問題ないのですが、その下のネットワークやストレージまで含めて、べた塗りされたリソースを抽象化しうまくコンテナクラスタに見せてあげるということを行う必要がでるため、セルフマネージをしなくてはならない責任が発生します。

エンジニアとして、取り組み自体はすごく面白いと思うし、やれたらエキサイティングかなと思う一方で、当社はあくまで決済を中心に世の中に価値を提供している会社です。コンピューターリソースのクラウドインフラの会社ではありません。
そうすると事業の中で、今それに力を割くべきだろうか、というとそれは違うのではないか、だったらそこはクラウドに任せよう。ということで、こんど払いはクラウドを選択したわけです。しかし、その時にはやはりコンテナを使う前に、クラウドを使う上での作法を整理しなければならないということに迫られます。

作法というのはアカウント管理だったり、証跡の払拭だったり、コスト管理、セキュリティ設定など、すごく基本のところです。オンプレを選択すればもう既に出来上がった仕組みがあって、当たり前に使えるので、そこをある意味省けるわけです。しかし、その部分を1から準備して、その後にコンテナにたどり着かなければならないため、学習コストは決して安くないな、と思いました。これがプロコンのコンです。

まとめ

まとめにはいります。「運用の強度化万歳」と書いてありますけれども、これはプロスで述べたままです。ただ構成管理の強化の価値観はコンテナがでてきて、コンテナという技術が全くゼロから世の中に生み出した価値ではありません。
それまでそれこそ手製のツールだったり、あるいはそれを実現してくれる裏のソリューションがあって、それらは既に実現できていたわけです。それと比べるとより軽く、スピーディにより強度のある構成管理ができるということを感じています。

ただしコンスで述べましたように、その恩恵にあずかるための学習コストはあまり安いとは思いません。クラウドを当たり前に使っていたとしても、今後はAWSだったらEC２やOSマネージの世界をやっていた人たちがコンテナになるぞというと、少しアプリケーションの作りを含めて、考え、学ばなければいけないことが増えます。そのため、学習コストが安くはないのです。
我々のように決済や金融領域、コンプライアンスの強度とサービスの柔軟性を両立しなければならないという必要性に常に迫られている事業者であれば、その学習コストを払ってもこれは取り組む価値はあると、今振り返っても思います。

今後です。これは再三申し上げている通り、プロダクションで半年しかやっていない人たちの感想です。
この先に、一定の幻滅期が訪れると思っています。それはありがたいことにサービスが広まっていくとランニングコストも増えていくので、それをその使っていただいているビジネスサイズに比例させないようなコスト抑止の策ですとか、コンテナタスクが足りないから2から4にしようというような、そんな単純な世界で都合よくスケールアウトできるとは思っていません。実際にできるかどうかというところです。
そのmsecレベルの応答性能要求されるような本当にクレジットカード決済の本丸に取り組むようなときに、また考えてみようと。
最後に、佐久間の説明にあったオンプレでやっているような資産の中からできるものを移すフェーズに入りたい。それはそのコンテナありきではなく、オンプレのスタイルで作られたもののギャップの一段上のチャレンジになります。
当社でこのコンテナクラスタの恩恵の最大化をしようとしたら、そこにも取り組む必要があり、なかなかハードルが高いもののやりがいはあるかなと思います。

私からは以上です。ご清聴ありがとうございました。

GMOペイメントゲートウェイでは、エンジニアを募集しています。募集概要は以下からご確認ください。

GMOペイメントゲートウェイ株式会社「採用情報」

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

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