Platform Engineeringの先人に学ぶ──メルカリ中島さんインタビュー
インタビュー参加者
- メルカリ：中島大一（インタビュイー）
- Platform Engineering Meetup：四七秀貴（インタビュアー）・草間一人（インタビュアー、オブザーバ）
- CodeZine：近藤佑子（オブザーバ）
──PEK2024ではキーノートのご登壇ありがとうございました。まず率直に今回参加した感想を教えてください。
中島：メルカリでは、7年前よりPlatform Engineeringのような取り組みをしてきました。1年前にPlatform Engineering Meetupが始まり、Platform Engineeringという言葉が色々な記事やブログに書かれるようになりました。それがついにカンファレンスにまでなり、しかも大勢の参加者がいたことに驚いています。最初のカンファレンスでキーノートとして講演できたのは、自分としても非常に楽しかったし良かったです。
──ちなみに、他の講演で気になったことや参考になったものはありましたでしょうか。
中島：個人的に面白かったのはUbieさんの発表です。Ubieさんの、クラウドやアプリケーションなどいろんな設定ファイルを一箇所でテンプレートとして管理し、そのテンプレートを書いたらいろんな設定ファイルが生成され、それがインターナルのBackstageと連携される仕組みはかなり完成度が高いです。特にすごいのは、動いている既存のシステムに対して、新しいインターナルのプラットフォームに移行できていることです。新規サービスをそのシステムに乗せるのは簡単ですが、既存のものを移行するのは難しいものです。
メルカリにおけるプラットフォームチームの存在意義
──では、さっそくPlatform Engineeringの実践について、メルカリで7年間実践してきた今、メルカリにどう貢献できているでしょうか？
中島：いくつかピックアップして紹介します。「セルフサービス」については、実践できていると思います。例えば、開発者が新しくサービスを立ち上げたいと思ったとき、サービス開発のひな型から、レポジトリを書いて、それを本番にデプロイして、モニタリングして、オンコールを回す、といったことを全部一貫して、開発者自身がプラットフォームチームに頼らずにできるようになっています。他にも、メルカリでは年に一度、開発者サーベイをしているのですが、直近のサーベイ結果によると、バックエンドエンジニアとして新しく入社したほぼ全員が、2、3日～1週間のうちに本番に何かしらデプロイできるようになっています。
ビジネス的な観点では、メルカリハロのような新規サービスも同じプラットフォーム上にあり、新規サービスのリリースもしやすくなっています。今年はメルカリハロ、2023年はメルコインといった形でサービスを次々と出せているのも、プラットフォームチームが取り組んできた成果だと思います。
SREとプラットフォームエンジニア
──Platform Engineeringは、これまでのSREやインフラチームとは何が違うのかといったことがよく話題に上がります。中島さんはもともとSREとしてメルカリに入社されていますが、SREからPlatform Engineeringに移行されたきっかけは何だったのでしょうか？
中島：僕がメルカリに入社した時は、メルカリはまだオンプレミス上で、モノリスアーキテクチャーで動いている状態でした。当時のメルカリはUS進出から1年以上経ち、メルカリUKも始めようとしていた頃です。それに伴い開発者も増えている状況で、このオンプレミス上のモノリスのアーキテクチャで開発を続けていくのは、限界に来ていた時期でした。今後さらにスピード感を持って開発していくために、オンプレミスからクラウドへ、モノリスからマイクロサービスへと移行していくという意思決定をしました。
マイクロサービスへの移行は、アーキテクチャを変えるだけでなく、開発者がいかにマイクロサービスの開発フローを自分たちで回すかというプロセス自体も変えていく必要がありました。これまではバックエンドエンジニアがバックエンドの開発だけをして、SREがその後のデプロイから運用モニタリングを行うといった形で、プロセスが分断されていました。しかし、マイクロサービスのメリット（独立したサービス群として運用されるため、各サービスの開発・リリースのサイクルを短くできる）をちゃんと享受したい場合は、運用で得た情報をもとにすぐにサービスの改善や新機能の追加を行う必要があり、そのためには、開発者がサービス開発から運用まで全部自分たちで回せるのが理想だと思ったんです。それを実現していくためには、ツール基盤を準備していかなければならないと。
その基盤開発を始めたというのが、僕がSREからPlatform Engineeringに移行しプラットフォームチームを立ち上げた経緯です。
──アーキテクチャの変更だけでなくて、プロセスも変える必要があると気づいたことが、今の原型になっているんですね。
中島：そうですね。当時書いたブログでも、アーキテクチャの変更だけをしてもメリットはなく、組織と一緒に変えて初めてマイクロサービスのメリットを享受できるということを強調しています。
──ちなみに、SREチームとプラットフォームチームが分かれたり、もしくは合体したりなどの組織の変遷はあるのでしょうか？
中島：今でもSREとプラットフォームチームは分かれていて、違う組織となっています。特にPlatform Engineeringを始めたばかりの頃は、意識的にSREとは違うチームにしようとしていました。
なぜかというと、重要視するところがプラットフォームとSREで違うからです。SREはSLO（サービスレベル目標）をいかに良くするかという「信頼性」に責任を持ちます。一方で、Platform Engineeringにとっても信頼性は重要な観点なのですが、それよりもいかに「生産性」をよくするか、自動化などどう「効率化」するかという観点に重きを置いています。
SLOを良くしていくことと、みんなが使えるような自動化の仕組みを作るのは、スキルセットが違うと思っています。なので、チームを分けて、それぞれ違う目標を持って動いた方がうまくいくのではと思い、立ち上げの時から違うチームとして歩んできました。
基盤ができてきた今でも、SREチームとプラットフォームチーム分けているのは他にも理由があります。
プラットフォームチームは、組織全体のさまざまなユースケースの80%をカバーできるような基盤やツールを作るチームだと思っています。すべてのユースケースを想定して自動化やツール開発をするのは不可能ではないかと。
一方で、そのドメインや事業により、カバーしきれない特殊な要件が数多くあるので、ドメインに特化した信頼性の改善や自動化によるプロセスの改善を担うチームとしてSREがあると考えています。
全体を見て80％をカバーするプラットフォームチーム、ドメインに特化した残りの20%をカバーするSREチーム、という役割分担になっています。逆に、プラットフォームが特定のユースケースに寄りすぎてしまうと、そのユースケースでしか使えないものになってしまい、また別の基盤を作らなければならない……といった話にもなり得るんですよね。なので、プラットフォームチームが下にあり、プロダクトエンジニアリングチームが上にいて、その間にSREチームがいるというのが、今のメルカリでの組織体系です。
