PHPからGoへの移行　メルカリのマイクロサービス化で直面した4つの課題と解決法

組織的な観点でスケーラブルなコードにする

森國泰平氏（以下、森國）：こんにちは。私はメルカリでマイクロサービスの開発をしている、森國と申します。今日は私が担当しているListing Serviceというサービスについて、どのようにマイクロサービス化を進めているかをお話いたします。

まず最初に、Listing Serviceについて簡単にご紹介します。

Listing Serviceは、メルカリのなかでも出品機能を担当するマイクロサービスとなっています。現在メルカリが進めているPHPのモノリスからGoのマイクロサービスへ移行する、最初のプロジェクトとなっています。

現在、Listing Serviceでは、1つのHTTPエンドポイントを対象として、マイクロサービス化を進めています。Listing Serviceが提供するのはHTTPのエンドポイントなんですが、Listing Serviceが他のサービスと通信する際には、gRPCを使用しています。

次に、メルカリのマイクロサービス化の進め方の戦略について、2つのポイントをお話します。

1つ目が、APIの互換性を保ちながらサービスを分割していくということです。APIの互換性を保つことによってカナリアリリース、つまりは段階的にPHPからGoのコードに移行していくことができます。

カナリアリリースをすることによって、万が一バグなどが最初に見つかった場合にも、PHPのコードに戻すこともできますし、そもそも影響範囲を少なくすることができるので、お客さまに対する負担というものも低下することができます。

2つ目の点として、チームとして独立した開発を可能にするということがあります。マイクロサービス化の目的は、ただコードを分割するということではなくて、長期的にスケール可能な組織を作り上げるということです。

そのため、Listing Serviceの開発を進めるなかでも、ただただ目の前の問題にとらわれすぎるのではなく、長期的な組織の在り方などを意識しながら、開発を進めていく必要があります。

3つのテストによって保たれる互換性、コードの再配置や移行について

これに対して、Listing Serviceがどのように実際に開発を進めているのかを紹介します。

まず、APIの互換性を保つということについては、3つのテストによって、互換性が保たれていることを保証しようとしています。

1つ目が、既存のAPIに対するアプリ、要するにiOSやAndroidの自動テストがあります。これをListing Serviceにもそのまま適用することによって、クライアントからの動作が変わっていないことを確認します。

2つ目のテストとして、QAチームによる手動の確認を行います。1つ目のアプリの自動テストだけではカバーしきれない範囲や細かいチェックなどを、QAチームの人の手によって行います。

3つ目は、AQAチームによるインテグレーションテストツールの開発と、それを使ったAPIの自動テストの構築を計画しています。

2つ目のチームとして独立した開発を可能にするという点については、そもそもListing Serviceで扱いづらいものは、出品に関するロジックだけなので、現在のエンドポイントに含まれているすべてのコードをListing Serviceに持ってくるというわけではなく、別のサービスに配置しなおしたりしています。

あるいは、そのままPHPのコードに残しておいて、Listing ServiceからWebhook経由でコードを実行するようなことにしています。そして、このPHPに残ったコードについては、適切なマイクロサービスが誕生した時に、コードの移行を考えています。

DB共有に関する安全面の課題

次に、Listing Serviceの開発を進めるにあたって直面した、4つの点について紹介します。

1つがGCPからさくらのMySQLへの接続、2つ目がトランザクションの分割、3つ目が機能追加・修正への追従、4つ目がPHPの例外との互換性です。それぞれについて、少し詳しく話していきます。

1つ目のGCPからさくらのMySQLへの接続についてです。

まず前提として、マイクロサービスというのは、ぞれぞれのサービスが独立したデータベースを持つべきだとは思います。ただし、今回のメルカリのようにモノリスからマイクロサービスに移行するという過程においては、どうしても一時的にデータベースの共有をしなければならない場合もあると思います。

メルカリのマイクロサービスは、基本的にはGCPの上で動いているんですが、既存のメルカリのPHPのコードであったりMySQLというのは、さくらのクラウド上で動いています。このGCPとさくらのMySQL間の接続をどうするかということが、課題になりました。

もちろんMySQLのポートを外部のインターネットに公開してしまえば、GCPから接続することは可能なんですが、それはセキュリティなどの要件的にあまりやりたくはないということで、課題となりました。

そこで我々がどのように進めているかというと、MySQLをgRPC経由で触るためのSQL on gRPCのようなサービスと、それを使うためのGoのクライアントライブラリを開発しています。gRPCを使ってMySQLを触ることによって、既存のgRPC上の認証・認可の仕組みに乗ることができるので、セキュアに通信を行うことができます。

この作成しているサービスでは、基本的にはCRUDの基本的な操作のみを提供し、JoinやTransactionといった複雑な処理は対応していません。実際にコードなどを見ていきます。

まず、こちらにはSELECT文に対応するProtocol Buffersのリクエストとレスポンスを載せています。

リクエストにはSQLで指定するカラム名だったりテーブル名、あるいは、WHERE句などが指定できます。

これをサービスに投げることによって、レスポンスにRowの配列が返ってきます。

このRowというのは、データベースの1行に相当する、カラム名とその値の配列のようなものとなっています。そして、このメッセージをうまく扱うために、Goのライブラリを開発しました。

Goのライブラリは、メソッドチェーンを使って、SQLのようにプロトバフのリクエストを組み立てることができます。

そして、このクライアントのもう1つの機能として、レスポンスのProtocol BuffersをGoのstructにマッピングするための、O/Rマッパーのような機能も備えています。これを使うことによって、Protocol Buffersというものをあまり意識せずに、SQLに近いかたちでMySQLを扱うことができるようになっています。

分割を前提に開発を進めていく

次に、トランザクションの分割についてお話します。Listing Serviceでは、基本的には出品に関する商品のデータの更新をメインとしたいんですけども、既存のAPIのコードには商品だけでなく、例えば配送情報だったり、分析用のデータなどが1つのトランザクションで更新されていました。

最終的にマイクロサービス化が進んでいくと、それぞれのサービスが独立したデータベースを持つことになるので、もちろんトランザクションは使えなくなります。そのため、この段階からトランザクションの分割っていうものを意識しながら、開発を進めていく必要があります。

そこで我々がどうしたかというと、まずどうしても商品に関連するようなデータについては、トランザクションが必要だと判断しました。そのため、さくら上にItem Serviceというサービスを作って、このItem Serviceはトランザクションを扱うようにしました。

それ以外についても、お客さまの目に直接触れるようなデータについては、できるだけリクエスト内で同期的に処理をするようにしています。それ以外の内部データなどについては、Cloud PubSubを使った非同期の結果整合性を受け入れるようにしています。

具体的に見ていくと、例えば、出品に関する機能があった時に、そのなかでトランザクションを貼って、例えば商品や画像、配送情報、分析用データなどが更新されていたとします。

その時に、商品についてはトランザクションが必要なので、Item Serviceが担保する。画像についてはお客さまの目に直接触れるものなので、トランザクションからは出すものの、できるだけ同期的に更新をする。

配送情報などについては、商品が売れるまでは配送されることもないので、例えば非同期の結果整合性を受け入れるようなかたちにする。そして、内部データについても、お客さまには意識してもらう必要はないので、非同期のデータ整合性を受け入れる、というふうに進めていきました。

機能追加・修正に対する追従

次に、機能追加・修正への追従についてです。

Listing Serviceは出品を扱うのですが、出品はメルカリのなかでもコアな機能の1つとなっているので、このマイクロサービス化を進める過程においても、機能の追加だったり修正が行われる場合があります。新しいマイクロサービスではAPIの互換性を保とうとしているため、この機能の追加や修正に対しても追従していく必要があります。

そこで我々がどうしたかというと、もとのPHPのリポジトリ上に変更追跡用のブランチというものを作成しました。そして、Goのコードに移行したコードについては、そのブランチ上から削除しています。

これによって、例えばPHPのmasterブランチに新しい変更が加えられた場合に、その変更追跡用のブランチにマージした際にコンフリクトが発生するので、新しい変更が行われたことに気付くことができます。そして、この変更追跡用ブランチからすべてのコードを削除することができれば、マイクロサービス化のコードの移行が完了したと判断することができます。具体的に見ていきます。