メルコインにおけるシステム間のデータ分離を実現するための通信アーキテクチャ / Communication Architecture for Implementing Data Separation Between Systems at Mercoin

メルコインでは、データプライバシーの観点からメルカリ・メルペイと異なるユーザーIDを用いています。しかし同時に、メルコインのシステムはメルカリ・メルペイのシステムに依存しており、ユーザーを特定してシステム間の通信を行う必要があります。これらの制約の中で私たちがどのようにシステム間通信のアーキテクチャを設計したのかについてお話しします。

When dealing with Mercoin, from the perspective of protecting data privacy, Mercoin uses different user IDs than Mercari or Merpay. At the same time, Mercoin’s system depends on Mercari and Merpay’s systems, and it’s necessary to specify the user in order to communicate between the different systems. In this session, we’ll talk about how we designed the system architecture for communicating between systems amid these restrictions.

------
Merpay & Mercoin Tech Fest 2023は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイ・メルコインの技術スタックに興味がある方々を対象に2023年8月22日（火）、23日（水）、24日（木）の3日間、開催します。 Merpay & Mercoin Tech Fest は事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りです。

今年のテーマは「Unleash Fintech」。 メルペイ・メルコインのこれまでの技術的な取り組みはもちろん、メルカリグループのFintech事業における新たな挑戦をお伝えします。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチなど多面的にご紹介予定です。

メルペイ・メルコインが今後どのようにUnleash（解放）していくのか、ぜひ見に来てください。

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2023/
- 申し込みページ：https://mercari.connpass.com/event/286670/
- Twitterハッシュタグ： #MerpayMercoinTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Session Title メルコインにおけるシステム間の データ分離を実現するための通信 アーキテクチャ Kohei Noda Backend Architect / Fintech Architect
2. Kohei Noda / @pobo380 2014年に株式会社MIXIに入社後、クライアントエン ジニア・バックエンドエンジニア・エンジニアリングマ ネージャー等、様々のポジションでゲーム開発に従 事。その後、2022年4月にメルコインに入社しアーキ テクトとして仕事をしている。2023年1月からFintech Architect としてメルペイに合流。 株式会社メルペイ Fintech Architect (Backend)
3. 今日話すこと メルコインにおけるシステム間のデータ分離とは 01 開発者体験を損なわずにデータ分離を実現するアーキテクチャ 02 まとめ 03
4. メルコインにおける システム間のデータ分離
5. メルコインにおけるデータ分離とは メルコイン ⇔ メルカリ/メルペイのシステム間で お客さまのデータを容易に紐づけられないようにする
6. システムの分離 従業員 従業員 メルコイン メルカリ/メルペイ お客さまデータ お客さまデータ
7. システムの分離 従業員 従業員 メルコイン メルカリ/メルペイ お客さまデータ お客さまデータ
8. システムの分離 従業員 インシデント発生 😭 メルカリ/メルペイ お客さまデータ 流出したメルコインのお客さまデー タ
9. ユーザーIDの分離 システム間で異なるお客さまのID (ユーザーID) を使うことで データの紐付けを防ぐ
10. ユーザーIDの分離 従業員 データが紐づけられない 😃 メルカリ/メルペイ お客さまデータ 流出したメルコインのお客さまデー タ
11. システムの連携はどうする？ サービス サービス メルコイン メルカリ/メルペイ お客さまデータ お客さまデータ
12. システムの連携はどうする？ サービス サービス メルコイン メルカリ/メルペイ お客さまデータ お客さまデータ IDを変換してから送受信
13. 内部用IDと外部用ID サービス サービス メルコイン メルカリ/メルペイ 内部用ID (UserID) 内部用ID (UserID) 外部用ID (PPID) 外部用ID (PPID) Mercari Engineering Portal: Applying OAuth 2.0 and OIDC to first-party services (https://engineering.mercari.com/en/blog/entry/20230130-applying-oauth-2-0-and-oidc-to-first-party-services/)
14. 内部用IDと外部用ID サービス サービス メルコイン メルカリ/メルペイ Mercari/Merpay UserID Mercoin UserID Mercoin PPID Mercari/Merpay PPID Mercari Engineering Portal: Applying OAuth 2.0 and OIDC to first-party services (https://engineering.mercari.com/en/blog/entry/20230130-applying-oauth-2-0-and-oidc-to-first-party-services/)
15. ID変換のステップ 1. メルコインのサービス側で Mercoin UserID を Mercoin PPID に 変換してリクエストを送る。 2. メルカリ/メルペイのサービスでは、受け取った Mercoin PPID を Mercari UserID に変換して処理する。 3. 処理結果に含まれる Mercari UserID を Mercoin PPID に変換し てレスポンスを返す。 4. レスポンスを受け取ったメルコイン側のサービスは Mercoin PPID を Mercoin UserID に変換してから処理を行う。
16. ユーザーIDの分離によって生まれる複雑さ ID体系そのものが複雑でID変換のステップが多い ID変換を各サービスで実装するのはコストがとても大きい
17. ここまでのまとめ これらを同時に満たすアーキテクチャを作りたい システム間で 異なるユーザーIDを用いる 開発者体験を損なわない
18. 開発者の体験を損なわずデー タ分離を実現する アーキテクチャ
19. 目指す開発者体験 マイクロサービスの実装者がID変換を意識する必要がなく、内部のマ イクロサービスへの通信と同じように扱える • 外部ID (PPID) の存在を意識せず、これまで通り内部ID (UserID) のみを扱う。 • 外部ID への変換が必要になるシステム間通信の場合は、通信経路で自動的に変換され る。
20. 方針 メルコインおよびメルカリ/メルペイでは ほとんどのマイクロサービス間の通信を Protocol Buffers で定義している ⬇ Protobuf メッセージに含まれるIDを 通信経路上で自動的に変換する
21. Protobuf メッセージに含まれるIDの変換 • Protobuf のメッセージとID変換の向きを渡すと ◦ メッセージの中に含まれるすべてのIDを変換して値を置き換える。 • 「どのフィールドに値が含まれるか」は Custom Option を使って proto ファ イルの中でアノテーションを行う。 func (c *ProtoMessageConverter) ConvertPPIDsToUserIDs( ctx context.Context, message proto.Message ) error func (c *ProtoMessageConverter) ConvertUserIDsToPPIDs( ...
22. CustomOption によるアノテーション package microservice_a; message GetUserRequest { string user_id = 1 [ (user_id.conversion).enable = true ]; } message GetUserResponse { string user_id = 1 [ (user_id.conversion).enable = true ]; string name = 2; int32 age = 3; ... } • IDを含むフィールドにアノテーションを行う。
23. Protobuf の Custom Option 定義 package user_id; message IDConversion { bool enable = 1; } extend google.protobuf.FieldOptions { IDConversion conversion = 60000; }
24. 通信経路上での変換 Protobuf メッセージに含まれるIDの変換を経路上で行いたい • Caller (呼び出し側) → gRPC Client Interceptor • Callee (呼び出される側) → Gateway
25. 通信の全体図
26. ID Provider ID Provider • UserID と PPID のマッピングを持つサービス。 ◦ UserID と PPID を相互変換するAPIを提供する。 ◦ gRPC Interceptor と Gateway からこのAPIを利用する。
27. Caller のID変換 gRPC Client Interceptor • gRPC Call 時に Request/Response を Modify するフィルタの ようなもの。 ◦ gRPC Client の初期化時にセットアップする。 • 以下の変換を行う ◦ リクエスト送信 : Caller UserID → Caller PPID ◦ レスポンス受信 : Caller PPID → Caller UserID
28. Callee のID変換 Gateway • 外部からのリクエストの入り口となる既存サービス。 ◦ いわゆる API Gateway の実装。 ◦ 内部のマイクロサービスへルーティングを行う。 • 以下の変換を行う。 ◦ リクエスト受信 : Caller PPID → Callee UserID ◦ レスポンス送信 : Callee UserID → Caller PPID
29. Callee のID変換 Gateway なぜ Callee MS ではなく Gateway でID変換を行うのか • Caller PPID → Callee UserID への変換は各MSで行うのではな く、限られたコンポーネントで行いたい 。 ◦ 任意の PPID を自身の UserID に変換できるため権限を 悪用されると、外部の PPIDを持った攻撃者による紐付けが 可能になる。 • Callee に gRPC Server Interceptor を導入する手間がなくなる。
30. 通信とID変換のフロー
31. 得られた開発者体験 開発者が行うこと 1. Caller Microserive への gRPC Client Interceptor の導入 ◦ 一度だけセットアップすればよい。 2. Protobuf メッセージへのアノテーションの記述 ◦ 新規に通信を行う場合、既存の通信にIDフィールドを追加する場合に 記述する。 ID変換を意識することなく 内部通信と同じようにAPI呼び出しが可能
32. 非同期通信のケース (Cloud Pub/Sub)
33. Publisher 側のID変換 PubSub Pusher 元々の責務 • Cloud Pub/Sub の トピック からメッセージを Pull Subscription で 受け取り gRPC リクエストに変換する。 ◦ Gateway を介さず直接マイクロサービスにリクエストを送 る。 • Subscribe する Topic、Push 先などの設定は kubernetes の manifest として記述する。
34. Publisher 側のID変換 PubSub Pusher システム連携のための拡張 • 受け取ったメッセージに含まれる IDを変換する。 ◦ Publisher UserID → Subscriber PPID ▪ 同期呼び出しの場合と違い、通信相手の PPID (Publisher PPID) に変換している。 • Gateway に対してリクエストを送信する。 Mercari Engineering Portal: Applying OAuth 2.0 and OIDC to first-party services (https://engineering.mercari.com/en/blog/entry/20230130-applying-oauth-2-0-and-oidc-to-first-party-services/)
35. Subscriber 側のID変換 Gateway • 同期的なAPI呼び出しとまったく同じ処理を行う。 ◦ リクエスト受信 : Caller PPID → Callee UserID ◦ レスポンス送信 : Callee UserID → Caller PPID Mercari Engineering Portal: Applying OAuth 2.0 and OIDC to first-party services (https://engineering.mercari.com/en/blog/entry/20230130-applying-oauth-2-0-and-oidc-to-first-party-services/)
36. 得られた開発者体験 開発者が行うこと 1. PubSub Pusher の設定ファイルを記述する。 ◦ ID変換とGatewayへのPushを有効にする。 ◦ マイクロサービス側の実装は変更する必要がない。 ID変換を意識することなく PubSub を使った非同期通信が可能
37. まとめ
38. まとめ 1. システム間でユーザーIDを分離することで高いレベルのデータプラ イバシー保護を実現した。 2. 透過的にID変換を行うアーキテクチャを導入することで効率的に開 発ができるようにした。 ◦ マイクロサービスの開発者は実装時にID変換を意識する必要 がない。 ◦ Go, gRPC (protobuf) で統一された環境だから実現すること ができた。
39. gRPC Interceptor の実装が Go しかない 01 不具合調査時の Traceability 02 UserID 以外のデータによる紐付けをどのように防ぐか 03 残っている課題