2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
山下慶将氏(以下、山下):「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というのを導入しました。
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略