コンテンツに移動
Google Cloud

株式会社メルカリの導入事例:Kubernetes を駆使したマイクロサービス化でグローバルサービスの開発効率を劇的に向上

2018年1月22日
Google Cloud Japan Team

https://storage.googleapis.com/gweb-cloudblog-publish/images/mercari.max-400x400.png

日本国内で圧倒的なシェアを誇り、今や知らない人はいないというほど認知度を増した「メルカリ」。その勢いは国内だけに留まらず、2014 年 9 月には米国に、2017 年 3 月には英国でのサービスを開始しています(世界累計 1 億ダウンロード。2017 年 12 月 16 日時点)。海外展開に消極的と言われる国内サービス事業者ですが、同社に関してはその常識は通用しないようです。今回は、そんなメルカリの米国における最新の取り組みについて、今春 CTO に就任した名村 卓さんと、SRE 中島 大一さんにお話をお伺いしました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/F1YW_RL5ecef84vvxlkoKKrgvE9znjjAkBOi2Rv50.max-1600x1600.JPEG

■ 写真左から
執行役員 CTO 名村 卓氏
SRE 中島 大一氏

■ 利用している Google Cloud Platform サービス
Google Kubernetes EngineCloud Dataflowなど

株式会社メルカリ
2013 年 2 月 1 日設立。同年 7 月に C to C 型のフリマアプリ「メルカリ」をリリースし、国内で未開拓だった同市場を切りひらく。現在は、地域の募集コミュニティアプリ「メルカリアッテ」や、本・CD・DVD に特化した「カウル」など、さまざまな姉妹サービスを展開中。現在の従業員数は約 400 名(グローバル合計)

ロードバランサーと Google Kubernetes Engine が GCP 導入の決め手


メルカリでは過去の取材記事でも語られたよう、リージョンごとに異なるクラウドプラットフォームを活用するマルチクラウド体制を敷いていました。しかし、その上で動くシステムに関しては原則として、日本で開発したものを共用。サービスの迅速な立ち上げという意味ではメリットがあったのですが、さらなる事業の拡大という観点では、これが足かせになりつつあったそうです。

「メルカリを米国でより一層普及させるには、現地の文化や風土にあった UI などを採用する必要があると考えました。そこで、2016 年末に米国版アプリの全面刷新を決定。国内版アプリのソースコードを流用せず、ゼロからフルスクラッチで新開発することになりました。そして、それに合わせてモノリシックだったサーバーサイド(メルカリ API)をマイクロサービス化しようということになったんです。このタイミングできちんと拡張性のある形に作り変えておこう、と。」(名村さん)

なお、マイクロサービス化は、拡張性の担保だけでなく、生産性の向上や現地での人材確保という面からも急務となっていました。サービス拡張に向けてローカル採用を進めようにも、米国では優秀なエンジニアほど、モダンな言語への指向性が強く、(従来システムで使われている)PHP を専門とするエンジニアの数が減少傾向にあるのだとか。

「最近は、 Go など、新しいことにチャレンジしてきたいという人が増えています。また、採用の面では、従来システムが巨大になりすぎて、新しく入ってきた人が全容を把握しきれないという問題も。米国チームで新しい機能を独自にどんどん開発していくという面でもマイクロサービス化は急務でした。」(名村さん)

もちろん、今ある全ての機能をいきなりマイクロサービス化するのには大変な労力がかかり、現実的ではありません。そこでメルカリ米国チームでは、従来システム(大手クラウドプラットフォーム上に構築されたメルカリ API)を、Gateway API(wrapper)で包み込み、段階的かつ効率的なマイクロサービス化を実施。そして、その Gateway は Google Cloud Platform(GCP)上に構築されることとなりました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/YeSntv9GJV5Ir2nKYVooGFwc6tVwgI5I9Er_h19f8Z.max-1000x1000.PNG
Microservices Architecture(米国)
https://storage.googleapis.com/gweb-cloudblog-publish/images/4AcYmeFif0ElAERBDP4eJ9Qj06-UOZAz0XivESN4FJ.max-1000x1000.PNG
GCP Architecture(米国)

「GCP を選んだのはいくつか理由があります。1 つは、ロードバランサーが非常に優秀なこと。また、大量のアクセスが予想される時や負荷試験の際などにも事前に予約をしておく必要のない使いやすさも気に入っています。そして、何より大きかったのが、Kubernetes との相性の良さ。Kubernetes は、コンテナを動かすランタイムとして、今、最も優秀なものの 1 つですから、今後はこれでインフラを管理していきたいという気持ちがありました。しかし、それをマネージドで動かせるクラウドプラットフォームは当時、GCP しかなかったんです。」(名村さん)

Kubernetes については、メルカリで SRE チームに所属する中島さんも次のように大絶賛しています。ちなみに SRE(Site Reliability Engineering) とは「サイト信頼性エンジニアリング」の略称で、メルカリではインフラチームがその活動範囲を拡大していくことを受けて改称。同社サービスの安定性と信頼性の向上に大きな貢献をしています。

「Kubernetes は全てがマニフェストで管理されていて、しかもその状態になるように自立的に動いてくれるのがありがたいですね。例えばコンテナが常に 3 つ動いていてほしいと定義すると、こちらが何も面倒を見なくても、その状態を保っていてくれます。」(中島さん)

結果、中島さん曰く、「Kubernetes を導入したおかげで、インフラのことをほぼ何も考えずに開発をスタートできた」とのこと。それによって開発も順調に進み、ある機能(後述のサーチ機能)の開発において、通常なら 2 か月かかるところを 1 か月足らずで完成できたそうです。「メルカリ米国チームには専従のインフラエンジニアが存在しないのですが、それでも何とかやっていけているのは Kubernetes のおかげでしょう。」(名村さん)

マイクロサービス化の推進でさらなる効率化を目指す


そして、2017 年 4 月、一部システムをマイクロサービス化した新システム、アプリが完成しました。その目玉はパーソナライズ化されたホーム画面。こうした機能は現在の国内版アプリには存在しません。

「米国版アプリの新しいホーム画面では、バックエンドで Cloud Dataflow が動いていて、閲覧したり、Like した履歴をほぼリアルタイムで解析して表示しています。ほか、サーチ機能を刷新したり、値引き交渉などをやりやすくするオファー機能などを、マイクロサービス化で実現しました。こうした機能を気軽に、品質を担保しつつ構築できるようになったのは、マイクロサービス化の大きな恩恵だと考えています。」(名村さん)

https://storage.googleapis.com/gweb-cloudblog-publish/images/3GhUBcZ4gg7CqwqT6Yq9DcUnWLdhhleH8dgbhR38c.max-1600x1600.JPEG

そのほか、細かな工夫としては、米国だけの独自機能として、Google のシリアライズフォーマット「Protocol Buffers」を採用。クライアントコードを厳密に管理できるようにすることで、後方互換を担保できるようにしているそうです。

もちろん、こうした工夫は米国チームだけが取り組んでいるわけではありません。米国リージョンのマイクロサービス化が一定の成果を上げたことを受けて、この夏からは日本リージョンでも、同様の手法を用いたマイクロサービス化が始まっています。

「最初は米国チームが採用した、Gateway API を使った方法ではなく、従来のモノリシックなメルカリ API から、マイクロサービス化された新機能を呼び出すという方式を採っていました。具体的には、商品の写真をアップロードすると、自動的に商品名やカテゴリーが入力される仕組みを、マシンラーニングの活用によって実現しています。ただ、実際にやってみると、やはりメルカリ API を経由させるやり方ではマイクロサービス化の恩恵を最大限に引き出すことができず……(苦笑)。結果、米国と同様、メルカリ API を Gateway API でラップする方式に移行することになりました。実は英国チームでも同様の問題を抱えているため、こちらは日英で共用できるものにしたいと考えています。」(中島さん)

https://storage.googleapis.com/gweb-cloudblog-publish/images/TnvsdpUiLwaTL_f57C1ZL8D2fA8J9lKCsaRzBLgf6.max-1600x1600.JPEG

なお、ここで米国チームの開発した Gateway API を採用しなかったのは、Protocol Buffers の導入にはアプリ側の強制アップデートが必要になるため。国内および英国チームでは従来アプリもそのまま使い続けられるよう、別の道を歩むことを選びました。こうした柔軟さを備えていることもメルカリの強さと言えるでしょう。

「もちろん、米国チームも今後、さらにマイクロサービス化を進めていく予定です。それらは当然コンテナで作ることになりますから、Kubernetes のポテンシャルをフルに引き出せる GCP の比重は今まで以上に高くなっていくはず。その上で、今後は、これまで以上にマネージドで、かつ面倒を見なくていいプロダクトを活用していきたいと考えています。例えば、Cloud Functions のようなサーバーレステクノロジーなどには特に興味がありますね。ログを BigQuery に流すのに、今は Cloud Dataflow を使っていますが、それを置き換えられるのではないかと考えています。また、人気の高い Google App Engine にも注目しています。これがもっとフレキシブルに使えるようになれば、それこそ Kubernetes を置き換えるなんてことができるかもしれませんね。期待しています。」(名村さん)

GCP のその他の導入事例はこちらをご覧ください。

投稿先