この記事は MERPAY TECH OPENNESS MONTH の14日目の記事です。
メルペイSREの @tjun です。Engineering Managerをやっています。
先月行われた Mercari Meetup for Microservices Platform #2で、 Merpay Microservices on Microservices Platformというタイトルで、メルペイのマイクロサービスがどのようにMicroservices Platformを利用してサービスを開発・運用しているかを発表しました。
本記事は、そこでの発表内容をblogとして記事にしたものになります。
その他の発表については @masartz の記事 Mercari Meetup for Microservices Platform #2 を開催しました – Mercari Engineering Blog を参考にしてください。
メルペイのマイクロサービス
メルペイは、2019年2月にサービスがリリースされました。メルペイの各機能はマイクロサービスとして実装されていて、ほとんど全てがGoogle Cloud Platform(以下GCP)のKubernetesクラスタ(Google Kubernetes Engine）上で動いています。
アーキテクチャをざっくり書くと次のような形になります。
一番先頭に、merpay-gatewayと呼ばれるマイクロサービスがあり、その後ろにはAPIを実現するマイクロサービスやWebページを表示するマイクロサービスがあり、さらにその後ろにさまざまな機能を実現するためのマイクロサービスがいます。
例えば、以下のようなマイクロサービスがあります。
- NFC決済をするためのAPIを実現するnfc-apiサービス、その裏の処理を行うnfcサービス、さらにその後ろの決済を管理するPaymentサービス
- クーポン機能を実現するためのクーポンWebサービスと、クーポンの発行管理をするクーポンサービス
ほとんどのマイクロサービスはGoで書かれていますが、Webページを実現するためのサービスなどNode.jsで書かれているものもあります。
メルカリもマイクロサービス化を進めていますが、メルペイのマイクロサービスには以下のような特徴があります。
- バッチ処理が多い
- 金融サービスですので、日次の処理、月単位の処理などさまざまな単位の処理が各マイクロサービスで動いています
- 外部との接続が多い
- さまざまなパートナーと連携しながらサービスを実現しているため、外との接続が多くなっています
参考: iD決済を支える技術 / #merpay_techtalk – Speaker Deck
すでにメルペイだけでも数十のマイクロサービスがあり、これらはMicroservices Platformの上で開発・運用されています。
Microservices Platformとは
Microservices Platformは、メルカリのMicroservices Platform Teamが構築・運用しているマイクロサービスを動かすための基盤です。
Platformには、Kubernetesのクラスタやその周りのCI/CD、Infrastracture as a Codeのための仕組み、ログや監視など運用のための仕組みも含まれています。
これらは日々運用・改善されていて、メルペイの開発・運用の仕組みもこの１年で大きく改善されてきました。
Microservices Platformの取り組みは以下の発表資料などが参考になります。
以下では、そのMicroservices Platformの上でメルペイのマイクロサービスをどのように開発・運用しているかを紹介します。
メルペイのMicroservicesの開発
まず、新たなマイクロサービスを作ることが決まって名前などが決まったら、 microservices-terraform というレポジトリで新たなマイクロサービスを作成します。
そのためのスクリプトがあるので、サービス名などを入力するだけで新たなマイクロサービスを作成できます。
PullRequestがマージされると、そのマイクロサービス専用のGCPプロジェクト、共通GCPプロジェクトにあるKubernetes上に専用のnamespaceが自動的に生成され、Service AccountやKubernetes Secretなども合わせて生成されます。
また、合わせてそのマイクロサービスの担当Developerを設定すると、必要な各種の権限が付与されます。
microservices-terraform レポジトリでは、GCPのリソースがTerraformで管理されており、各Developerは必要なGCPリソースを必ずTerraform経由で作成することになります。
メルペイの場合は、Cloud SpannerやCloud Pub/Subなどのリソース、また必要なIAMを作成します。
microservices-terraform については、この資料が参考になります
コードを書いたら、次はアプリケーションを動かすためのKubernetesの設定を行います。
microservices-kubernetes というレポジトリで、各DeveloperはKubernetesのDeployment, Service, ConfigMap, CronJobなど必要なyamlを作成します。
これらはマージしてCI経由で自動反映するものもあれば、Spinnaker経由でデプロイするものもあります。
microservices-kubernetes については、この資料が参考になります
コードをデプロイするためのプロセスはCloudBuildでDocker Imageを作成して、Container RegistryへPush、そのイメージをSpinnakerを使ってリリースする、という流れになります。
このCI/CDパイプラインも以前に比べて整備され、SpinnakerのUIで設定していた部分がDeploymentのyamlとして管理できるようになったり、デプロイの速度が改善したり、よりセキュアな仕組みになってきました。
– 参考: Securing microservices continuous delivery using grafeas and kritis
メルペイのMicroservicesの運用
リリースしたマイクロサービスは、各Developerが責任を持って運用をしていくことになります。
具体的にはDatadogでTimeboardやSLO Boardを作成したり、APMでtracingしたりすることで各サービスをモニタリングし、アラートのためのMonitorを設定して問題に気づく仕組みを作っています。
Datadogを使った運用に関して、詳しくは以下の記事で紹介されています。
メルカリ・メルペイではGoの共通middlewareライブラリが共有されており、このライブラリを利用することで各サービスが比較的簡単に、共通の仕組みでmonitoring/tracingできるようになっています。
また、何か問題が起きた際には、DatadogのAlertがSlackやPagerDutyへ送られ、当番のDeveloperとSREが連携して対応しています。
マイクロサービスの運用まわりはまだまだ課題があり、より信頼できるサービスを目指してSRE、Developer、 Microservice Platform Teamが連携しながら改善を続けています。
おわりに
前述したように、メルペイではBackendやFrontendエンジニアもTerraformの設定を書いたりKubernetesのyamlを書いたりしています。
また、SREはそのマイクロサービスを支える仕組みをMicroservices Platform Teamと一緒に作り、その上のサービスを運用するさまざまな技術的チャレンジができる職場です。
各職種採用しておりますので、興味がある方は @tjun まで気軽にご連絡ください。
