メルペイのエンジニアが教えるマイクロサービスアーキテクチャを安全かつ継続的に運用する方法

自己紹介とアジェンダ

山下慶将氏（以下、山下）：「Open Policy AgentとSpinnakerで実現するマイクロサービスの安全な継続的デリバリー」というタイトルで発表いたします。よろしくお願いします。

はじめに自己紹介します。山下慶将と言います。Twitterは@_k_e_k_eでやっているので、よかったらフォローしてください。今はメルペイSREに所属していて、マイクロサービスプラットフォームのCI/CDチームで働いています。好きなプロダクトは、Kubernetesはもちろんですが、CI/CDに関連するプロダクトだったりサービスメッシュのプロダクトが好きです。

今日のスライドは後ほどTwitterでツイートするので、スライドだけご覧になりたい方はあとで見てください。

今日のアジェンダです。まずはじめにメルカリのマイクロサービスアーキテクチャの説明と、CI/CDの説明を最初にしたいと思います。そしてマイクロサービスアーキテクチャのCI/CDをしていく中でどのような問題があったのかを説明。その結果Open Policy AgentとSpinnakerの機能を導入することになった背景とその効果について説明して、最後にまとめをして終わりたいと思っています。

今日の発表のゴールとしては、マイクロサービスの継続的デリバリーの横断的な向上ができるようになることが目標です。今回トピックでOpen Policy AgentだったりSpinnakerのプロダクトがあるんですが、それに限らずマイクロサービスの継続的デリバリーの質が上げられればうれしいなと思っています。

メルカリのマイクロサービスアーキテクチャ

最初にメルカリのマイクロサービスアーキテクチャを説明します。メルカリのマイクロサービスはそれぞれKubernetes NamespaceとGoogle Cloud Platform、GCPのProjectとSpinnakerのアプリケーションをもっています。

すべてのマイクロサービスは1つのGKEクラスタの中に入っていて、先ほど説明しましたNamespaceごとにマイクロサービスがホスティングされています。デプロイメントに限らずJobだったりとかConfigMapとかの関連するリソースもそのNamespaceの中にデプロイされています。

GCP Projectは、それぞれのマイクロサービスがそれぞれのGCP Projectを持っていて、クラウドリソースを作って使ったりしています。

メルカリのCI/CD

次にメルカリのCI/CDについて説明しようと思います。メルカリのCIの対象は以下の2つに分けられます。まずマイクロサービスそのものであるアプリケーションコードのCI。そしてそれをGKEクラスタにデプロイするためのKubernetesマニフェストのCI、YAMLファイルのCIです。

ApplicationのCIはこのような構造になっています。それぞれのマイクロサービスがそれぞれのGitHubリポジトリにソースコードをプッシュ、レビューをしたりして開発をしています。そしてCircle CI上でテストをしたりコード解析したりして、GCPのCloud Buildを用いてマイクロサービスをビルドしています。その生成物であるDockerイメージをContainer Registryにプッシュしています。

次にKubernetes ManifestのCIです。Kubernetes Manifestには、すべてのマイクロサービスで使う1つのKubernetesリソースを置くリポジトリがあります。各マイクロサービスは、そのリポジトリにYAMLをプッシュして、それぞれのマイクロサービスでレビューしてCIを回しています。

実際に僕が2月にデプロイメントを作成したときのプルリクはこれです。自分のマイクロサービスのメンバーにレビューしてもらいました。

先ほどのアプリケーションのContainer RegistryとKubernetesリソースリポジトリにあるYAMLを使って、SpinnakerというCDプラットフォームを使ってKubernetes上にデプロイしています。これがメルカリのCDです。

それぞれのマイクロサービスはSpinnakerのアプリケーションを持っていて、それぞれのNamespaceにデプロイするという構成になっています。

デベロッパーは、それぞれのアプリケーションの中でパイプラインを定義して設定して、各マイクロサービスとしてデプロイしています。ここまでがメルカリのマイクロサービスアーキテクチャとCI/CDの簡単な紹介になります。

マイクロサービスアーキテクチャのCI/CDの問題点

このようなマイクロサービスアーキテクチャのCI/CDを行っていますが、いくつか問題点があります。そもそも大前提として、マイクロサービスアーキテクチャは各マイクロサービスが自律的に開発サイクルを回していくという理念に根ざしています。なので会社として横断的なテストエンジニアやリリースエンジニアが居なくて、マイクロサービスのデベロッパーが開発してテストしてリリースをするような流れになっています。

そしてそれぞれのマイクロサービスで自律的に開発サイクルを回すので、すべてのマイクロサービスが他のマイクロサービスと同じようなことを同じレベルでできることはなくて、例えばメルカリという大きなサービス全体の視点で見てみると、質の担保というのがすごく難しくなってきます。

例えばKubernetes Manifestの例を取ってみると、組織として、「Labelがマイクロサービスの名前と一致していること」とか「Memory Limitを設定していること」「それが例えば10ギガバイト以下に設定していること」などのルールを設けていたときに、すべてのマイクロサービスでそれができていることを保証するということはすごく難しいです。

先ほど紹介したKubernetes ManifestのCIの中で1つのサービスがルールにそぐわないようなYAMLを作っていたとします。例えばNamespaceがマイクロサービスの名前に合っていないとか、imageのタグにlatestを使っているとか、CPU limitが明らかにおかしいとか。

これらのルールというのはKubernetesのソースの記述としては間違っているわけではないので、チームのレビューが通ればこれらのKubernetes Manifestがプロダクション環境に出てしまうことになります。

そして次にデプロイについてです。デベロッパーがデプロイの手法であったりとかデプロイの設定をそれぞれで行ってデプロイしているということを紹介しました。例えばマイクロサービスAでカナリアデプロイをしている、マイクロサービスCでBlue-Greenデプロイをしている、マイクロサービスBで例えばリスクが高いような適当なデプロイをしていると、このデプロイの差が結局はメルカリとしてのサービス全体の質に影響してきます。

なのでこれを顧みてマイクロサービスアーキテクチャの根ざしている各デベロッパーが自律的な開発サイクルを回していくという視点と、プラットフォーム的な視点、サービス全体の質を担保したりとか、それをより向上していくというのはすごい相性が悪いものです。

これからマイクロサービスがどんどん増えていく中で、じゃあメルカリとしてはサービスの質がどんどん落ちていくかというと、そうではなくて、そのためにマイクロサービスプラットフォームチームがプロジェクトを作って取り組みました。

Open Policy Agentで問題点を解決する

問題点を整理すると、まずマイクロサービスがルール違反するようなリソースをKubernetesに対してApplyをしていたりとか、既にApplyされていたりして結果的にサービス全体の質が落ちてしまっているリスクを抱えてしまっているという問題点がありました。

そのようなことに対する解決策としては、デベロッパーがそれぞれ行うCI/CDサイクルの中でルール違反がないかを検証して、Applyを防ぐ仕組みを用意したりとか、Circle CIやSpinnakerがApplyリソースに限らずクラスタの上で違反しているリソースがないかをチェックする仕組み作り、そしてそれらのルールを定義して運用していく仕組みが必要だなと思っていました。

そのような背景からOpen Policy Agentというのを導入しました。