300人から1000人へ――メルカリは開発組織を拡大するため「マイクロサービスアーキテクチャ」を採用した（前編）：Mercari Tech Conf 2018（3/5 ページ）

[新野淳一，Publickey]

APIゲートウェイアーキテクチャへの移行

　われわれが達成してきたことを一言で言うと、「何もないところにベースとなる道を整えた」ということです。具体的には、基礎となるマイクロサービスのためのアーキテクチャの構築、そして基本的な“DevOps文化”の醸成といったところです。

　アーキテクチャとして整えたことは大きく次の4つです。

• APIゲートウェイアーキテクチャへの移行
• サービス間コミュニケーションプロトコルの統一化
• 新規のマイクロサービスを作るためのテンプレートプロジェクトの提供
• 開発者のインフラへのアクセス制限の管理

　まずは、APIゲートウェイアーキテクチャへの移行について紹介します。

　これが1年前のメルカリのメインアーキテクチャです。モノリスのAPIとそれが使うデータベースがあり、全ての開発がこの中で行われていました。

　まずは、この全体に内製のAPIゲートウェイを配置し、メルカリへの全リクエストがAPIゲートウェイ経由になるようにしました。新サービスを作る際には、そのサービスをAPIゲートウェイ配下に作ることができるようになり、モノリスのコードとはある程度独立して、新規マイクロサービスの開発を行えるようになったわけです。

　また、既存機能をマイクロサービス化してモノリスと切り離していくときも、このAPIゲートウェイ配下に配置し、APIゲートウェイレベルでリクエストの振り替えを行うことで、段階的にマイクロサービスへ移行できるようになりました。このAPIゲートウェイはGoogle Cloud Platform（GCP）上にデプロイしており、クラウドへの移行も開始しています。

　これによって、サービスAが何かデータベースを使いたいときには、クラウドのマネージドサービスのデータベースを使えるようになりました。

内製のAPIゲートウェイを配置し、メルカリへの全リクエストがAPIゲートウェイ経由になるようにした

　また、新しいサービスはコンテナとしてKubernetes上にデプロイしています。Kubernetesを使うことで、コンテナが死んでしまったときに自動的に再起動してくれるセルフヒーリングの機能や、リクエストがたくさん来たときにコンテナを自動的に増やしてくれるオートスケール機能などを使うことができ、オペレーションコストを劇的に減らすことができます。