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

CloudNative Days Tokyo 2019では、ベンダーだけではなくユーザーの事例を紹介するセッションが数多く開催された。今回は、その中からメルペイのセッションを紹介する。これはメルペイをマイクロサービスとして開発した概要を紹介したもので、発表者はメルペイのSRE（Site Reliability Engineering）チームの高木潤一郎氏だ。「メルペイにおけるマイクロサービスの構築と運用」と題されたセッションで、テーマは「『マイクロサービス、実際にやってみてどう？』に答えたい」という直球のものであり、メルペイをマイクロサービスとして開発した経験を共有するということが目的のセッションとなった。当日は多くの参加者が詰めかけ、席が足らない状態となるほどの人気のセッションで、事後のアンケートでもこのセッションがカンファレンスのベストスピーカーに選ばれたことからも、内容が期待以上のものであったことがわかる。

満員のセッション会場。立ち見の参加者も

高木氏はまずメルペイの概要を紹介。2019年から開始したメルペイがiD、QRコード、あと払い、ネット決済対応と着実に進化していることがわかる。

メルペイのSRE、高木氏

メルペイの概要

2019年の現時点で1400億円以上の決済を実施し、200万人以上が利用するサービスとなったことを紹介。そして、このサービスが内側では40以上のマイクロサービスで実装されているという。

メルペイの規模はこれくらい

そして次のスライドがこのセッションの核心的な内容となった。つまりメルペイがマイクロサービスを使うことにした目的が「複数のサービスを短期間で立ち上げるため」だというのだ。

マイクロサービスを推進するベンダーなどのプレゼンテーションでは、「ビジネスの変化に対応するため」や「急激なアクセス増などに対してスケールアウトするため」にマイクロサービスを訴求することが多い。ビジネスサイドの要求によるマイクロサービスの採用といったことは往々にしてあるが、メルペイの場合はあくまでも開発サイドの要求として、「小さなグループが小さなモジュールの開発を行うことで開発期間が短縮できること」、他にも「リソース管理も障害時の対応もラクになる」という開発及び運用サイドの要因が挙げられていた。

マイクロサービス化の理由はサービスを短期間で立ち上げるため

そしてその開発サイドのニーズであることがよくわかるのはこのスライドだ。ここにはマイクロサービス単位で自由に開発言語やプラットフォームを選択できないということが明記されている。つまりマイクロサービス化を推進するために、開発言語やプラットフォームを統一して、デベロッパーが他のサービス開発に移ったとしてもすぐに開発が行えるようにしてあるのだ。

マイクロサービス化に際して「やっていない」こと

また開発チームをビジネスが要求する機能を実装するマイクロサービス開発チームと、プラットフォームとシステム全体を横串で見通すSREやプラットフォームのチームに分割しているというのも特徴である。その上ですべてのサービスをGoogle Cloud Platform（GCP）上に構築することで、すべてのデベロッパーは常に同じ環境で新しいサービスの開発を始められるという。

マイクロサービスに特化した組織体制

このスライドは典型的なマイクロサービスのCI/CDの側面から見た概念図だが、GCPに特化してなるべくシンプルになるように考えられていることがわかる。

メルペイの概念図

またマイクロサービス化することによって難しくなったポイントについても解説を行った。最初のポイントは「データの一貫性」だ。モノリシックなアプリケーションに比べて複数のプロセスによって全体が構成されている場合、トランザクションがどこかのプロセスで何らかの要因によって失敗することは想像できるだろう。その場合、利用するデータが成功や失敗に関わらず一貫していることが必要だ。また冪等性についても、何回実行しても結果が同じになることをマイクロサービスの処理の中に取り込んでいることも特徴的だろう。

マイクロサービスにおける一貫性問題

これに関してはメルペイのブログ記事に詳しく書かれているので、参照されたい。

参考：「マイクロサービスにおける決済トランザクション管理」

そしてGoを開発言語として選択したこと、マイクロサービスを開発する際に必要な社内プロセスなどについても解説を行った。

マイクロサービス開発のためのレビュープロセス

次に開発を加速する仕組みとしてのチームの役割や特徴を解説。ここではサービスの担当チームは開発から構築、運用までに責任を持つことが記されている。

メルペイのマイクロサービスチームの特徴

「各チームがOwnershipを持ってサービスを構築・運用する」という一文でもわかるように、ここではいわゆるDevOpsが実現されていると言える。しかしそれはDevとOps、開発と運用の別チームが一緒に働くというものではなく、開発がGCPをフル活用して運用まで責任を持つというスタイルである。またGoogleが開発するgRPCの肝であるProtocol Buffersを使って、サービス間のIDL（Interface Description Language）をフルに使っていることなどがわかる。

マイクロサービスの運用体制

マイクロサービスの運用体制というスライドでは「元から運用経験があるエンジニアは多くない」と書かれていることでもわかるように、マイクロサービス自体はデベロッパーが運用を行い、共通部分に関してはプラットフォームチームが担当するという分担のようだ。

マイクロサービス運用の苦労を語る

このスライドでは運用の手間を減らすために構成を揃える、オートスケールや自己修復というKubernetesの基本機能、そしてマネージドサービスを使って無駄な手間の減少を目指していることがわかる。そしてまとめとして、ここでも「短期間でサービスをリリースするためにマイクロサービスを実装した」ことがトップに紹介されている。

メルペイのマイクロサービスのまとめ

マイクロサービスによって短期間にサービスを開発し、リリースするという目的は達成したものの、同時に新たな課題も出てきたことを解説した。

マイクロサービスの課題

ここで紹介された「一部のマイクロサービスが肥大化しモノリシックなプログラムになってしまう」という状態が、メルペイのように徹底的に環境や開発言語を統一したとしても発生してしまうことを考えると、クラウドネイティブな分散システムの開発においては、従来の情報処理の考え方を根底から変えないといけないのではないかという暗澹たる気持ちになってしまう。

この後は、マイクロサービスの開発の際に発生したトラブルについて、例を挙げて紹介する内容となった。

Deploy時にリクエストの一部がエラー

その対処方法

Kubernetes配下のPodは、起動時や終了の際にその処理に必要な時間を想定して扱ってやる必要があるというのは「ペットと家畜」に例えられるクラウドコンピューティングにおいては皮肉であろう。家畜のようにサーバーやプロセスを扱えとは言われても、家畜でさえ正しく死ぬまでちゃんと確認をする必要があるということだ。

それ以外に、常に開発がUpstreamで進んでいるKubernetesとそれをマネージドで提供するGCPをプラットフォームとして利用する場合には、これくらいのトライアンドエラーは必要悪であるという覚悟が要るのかもしれない。そう言えるくらいには多くの予期しないトラブルに見舞われたというのが、高木氏のプレゼンテーションの最後のパートとなった。

ちなみに高木氏が利用したスライドは以下から参照されたい。

メルペイのマイクロサービスの構築と運用

このセッションがベストスピーカーに選ばれた要因は、マイクロサービスというトレンドなシステムのリアルな開発運用体験に基づいていること、失敗談のパートがあったことなどが挙げられるが、ユースケースが成功体験だけを共有するものではないというのは、KubeConのキーノートなどでも見られる傾向である。日本国内のユースケースにもこの「失敗を公開する」という傾向を引き継いで欲しいと切に願う。成功の影には数多くの失敗が必要なのだから。