
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
山下慶将氏(以下、山下):「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の対象は以下の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を行っていますが、いくつか問題点があります。そもそも大前提として、マイクロサービスアーキテクチャは各マイクロサービスが自律的に開発サイクルを回していくという理念に根ざしています。なので会社として横断的なテストエンジニアやリリースエンジニアが居なくて、マイクロサービスのデベロッパーが開発してテストしてリリースをするような流れになっています。
そしてそれぞれのマイクロサービスで自律的に開発サイクルを回すので、すべてのマイクロサービスが他のマイクロサービスと同じようなことを同じレベルでできることはなくて、例えばメルカリという大きなサービス全体の視点で見てみると、質の担保というのがすごく難しくなってきます。
例えばKubernetes Manifestの例を取ってみると、組織として、「Labelがマイクロサービスの名前と一致していること」とか「Memory Limitを設定していること」「それが例えば10ギガバイト以下に設定していること」などのルールを設けていたときに、すべてのマイクロサービスでそれができていることを保証するということはすごく難しいです。
先ほど紹介したKubernetes ManifestのCIの中で1つのサービスがルールにそぐわないようなYAMLを作っていたとします。例えばNamespaceがマイクロサービスの名前に合っていないとか、imageのタグにlatestを使っているとか、CPU limitが明らかにおかしいとか。
これらのルールというのはKubernetesのソースの記述としては間違っているわけではないので、チームのレビューが通ればこれらのKubernetes Manifestがプロダクション環境に出てしまうことになります。
そして次にデプロイについてです。デベロッパーがデプロイの手法であったりとかデプロイの設定をそれぞれで行ってデプロイしているということを紹介しました。例えばマイクロサービスAでカナリアデプロイをしている、マイクロサービスCでBlue-Greenデプロイをしている、マイクロサービスBで例えばリスクが高いような適当なデプロイをしていると、このデプロイの差が結局はメルカリとしてのサービス全体の質に影響してきます。
なのでこれを顧みてマイクロサービスアーキテクチャの根ざしている各デベロッパーが自律的な開発サイクルを回していくという視点と、プラットフォーム的な視点、サービス全体の質を担保したりとか、それをより向上していくというのはすごい相性が悪いものです。
これからマイクロサービスがどんどん増えていく中で、じゃあメルカリとしてはサービスの質がどんどん落ちていくかというと、そうではなくて、そのためにマイクロサービスプラットフォームチームがプロジェクトを作って取り組みました。
問題点を整理すると、まずマイクロサービスがルール違反するようなリソースをKubernetesに対してApplyをしていたりとか、既にApplyされていたりして結果的にサービス全体の質が落ちてしまっているリスクを抱えてしまっているという問題点がありました。
そのようなことに対する解決策としては、デベロッパーがそれぞれ行うCI/CDサイクルの中でルール違反がないかを検証して、Applyを防ぐ仕組みを用意したりとか、Circle CIやSpinnakerがApplyリソースに限らずクラスタの上で違反しているリソースがないかをチェックする仕組み作り、そしてそれらのルールを定義して運用していく仕組みが必要だなと思っていました。
そのような背景からOpen Policy Agentというのを導入しました。
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.07
なぜ日本企業のDXは世界の先端企業から3周遅れなのか? 『ゼロ秒思考』著者が指摘する経営者に足りない決断
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10