Merpay Tech Fest 2022 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2022年8月23日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「メルペイの不正対策を支えるマイクロサービス群をcloud to cloudで移行している話」の書き起こしです。
皆さん、こんにちは。それでは「メルペイの不正対策を支えるマイクロサービス群をcloud to cloudで移行している話」と題しまして、これからお話ししていきたいと思います。メルペイTnS Engineering Managerの浅野から発表いたします。
自己紹介
私は2019年12月にメルペイにEngineering Managerとして入社し、いくつかのチームを兼務し、現在はメルペイTnSチーム専任となっています。今日は、私がTnSを担当するようになってからの不正対策システムの変遷もあわせてお話しできればと思います。
Agenda
このセッションは、Introduction、Migrations、Issues and Measures の3部構成です。チームとシステムの紹介、移行の内容について、なぜ移行したのか、最後に移行プロジェクトにおいて直面した問題とその対応について話していきます。
Introduction
まず、私たちのチームについて簡単に紹介させてください。
私たちはメルペイ Trust and Safety（TnS）チームとしてメルペイの不正対策を担当し、お客さまの安心・安全な取引、メルペイの利用のために、日々激化する不正にエンジニアリングによって対処しています。詳細は、弊社の記事をご覧ください。
https://mercan.mercari.com/articles/31223/
systems and history
私たちのチームはざっくり分けると、こちらの4種類のシステムを扱っています。こちらの表は、それぞれのシステムとその歴史をまとめたものになります。
rule based fraud detection systemは、クエリによるルールを設定して不正を検知する仕組みで、Splunkを使っています。立ち上げ当初はAWSに自分たちでインストール設定して運用していましたが、2021年にSplunk cloudに移行しています。
data aggregation systemはメルペイ、メルカリShopsなど、メルカリグループ内の検知対象のサービス群からデータを収集する仕組みです。いくつかのマイクロサービスやバッチが稼働しています。rule based fraud detection systemとの連携が多いため、こちらも元々AWS上で稼働していました。これらをこの春にGCPへ、他のメルペイのマイクロサービスと同じインフラに移行しています。
operational systemは日々の不正を監視しているチームによって利用される社内ツールのシステム群です。data aggregation systemと同じく、この春にGCPへ移行しました。
realtime fraud detection systemは、構築当初からGCP上にメルペイの他のマイクロサービスと同じ構成で構築しているため、今日の移行の話では触れません。この春のMerpay Tech Openness Monthの記事でもrealtime fraud detection systemの仕組みを紹介しています。
https://engineering.mercari.com/blog/entry/20220419-14cfb92734/
この表で赤く示したように、私たちのチームは去年と今年にかけて2種類のクラウド移行を経験しています。
Migrations
では、なぜ私たちはこれらシステム群の移行を進めたのかを説明したいと思います。
1st migraton
一つ目の移行は、昨年のrule based fraud detection system、つまりSplunkの移行でした。AWS上に構築したSplunkクラスタをSplunk社が提供するSplunk cloudに移行しています。
私たちのサービス構築当初、つまりメルペイの立ち上がりのタイミングでは、SplunkがAWSでの動作を主に保障していたことや構築の柔軟性といった理由から、AWS上に自分たちで構築する方針を選び、運用を続けてきました。
しかし運用を続けていく中で、AWSとSplunkの両方とも私たちのチームが主に使っている状況で、運用負荷が増えてきました。
具体的には、3つあります。クラスタを構成する数十台の高スペックなインスタンスを管理するinfrastructure cost、SplunkとAWSそれぞれともに、それなりの専門知識が必要なサービスでこれらに対応できるエンジニアを常に確保する必要があり、そのことに伴うmaintenance cost、そして、scalability、durability、securityといった、金融サービスとしてそれぞれにおいて高い基準が要求される中で、私たちのチームのみで、これらの基準を担保し続ける難しさです。
これらの要素に対して、rule based fraud detection systemをSplunk cloudに移行することで軽減できると判断し、昨年の移行を実施しました。
2nd migration
二つ目の移行は、今年AWSに残っていたdata aggrication system やoperational system
をGCPに移行するものでした。移行の理由としては、先ほどの1st migrationでお話ししたSplunk cloudへの移行と同じように、さまざまな観点でのmaintenance costが多くあります。
また、Splunkとは違ってこれらのシステム部分は私たちのチームで開発しているマイクロサービスやバッチとなります。メルペイのバックエンドチームでマイクロサービスを開発する場合、通常は社内の専門チームであるSREやアーキテクトといったチームによって提供されている仕組みを活用して、開発を進めています。
しかし、これまで私たちはこれらのシステムをAWS上で独自に開発してきたため、社内チームが提供してくれている仕組みを利用することはできず、同等の仕組みをわざわざ自分たちで開発して揃えていました。このような車輪の再発明はせず、横断的な仕組みを活用していくべきと判断したことが二つ目の理由です。
昨今、不正対策の優先度・緊急度が高まっていることもあり、私たちの本来のドメインである不正対策の開発対応にチームとして専念できる状態を整備すべきと判断したこともあります。
以上の理由から、GCPへの移行を進めてきました。
Issues and Measures
続いて、移行プロジェクトにおいて直面した問題と対応についてお話しします。
Issues
Issuesとして、プロジェクトを通じて直面した問題を3つ挙げています。priorities / direction、project management、uncertainty。それぞれどのようなことなのか、どのように対応していったのかを話していきます。
Priorities / Direction
まずPriorities / Directionです。移行プロジェクトは、それぞれ1年ほどの期間がかかります。社内外ともに状況変化が激しい中で、それなりに期間がかかるプロジェクトを一定して進めるために、常に優先度や方向性を整理しながら進める必要がありました。
メルペイでは、Q毎にプロダクト組織としてどのようなプロジェクトを進めるのかを定期的に見直しています。つまり、社内の変化に伴う優先度の変化があります。
とくにコロナ以降はオンラインにおける購買行動が増えるに従って不正も増加しており、我々不正対策チームとしてもやるべきことの優先度・緊急度が高まりました。これは、社外要因を伴う優先度の話です。
最後に方向性として、我々のシステムをどこまでの範囲に移行するのか、また移行をきっかけに仕組みを見直すべきかなどの判断もありました。
それぞれこのように対応してきました。社内の優先度変更においてはプロジェクトが停止してしまわないように、プロジェクトの必要性や現状の整理、停止した場合のリスクなどを提示して優先度を維持し、プロジェクトの状況を保ちました。
社外要因に伴う不正対策の実施については、アサインを整理して不正対策に従事するメンバーと移行プロジェクトに参加するメンバーをある程度分離し、不正対策に遅れが出ないように調整しました。同時に採用も進めて、チーム全体の強化を進めました。
方向性判断としては、移行とリアーキテクチャのバランス。こちらも優先度から整理して検討しました。つまり、移行先で代用できないものや確実に構成を変更する必要があるものはマストとして、最優先で代替案を検討・設計しました。
移行先でも同じ構成を保てるが、できれば移行をきっかけにまとめていく方が開発運用の観点で効率的と判断できるものは、nice to haveとして以降の開発コストや運用コスト、プロジェクトのスケジュールを踏まえて総合的に判断しました。
Project Management
次にProject Managementです。この移行プロジェクトは、チームのエンジニアとエンジニアリングマネージャーで協力してプロジェクトマネジメントをしてきました。
GCPへの移行プロジェクトは、大別すると、data aggregation systemとoperational systemの2種類になります。中身は10個以上のレポジトリにわたるマイクロサービスやバッチが稼働しました。これらのシステムに1名以上のエンジニアをアサインし、インフラとしてDBなどのインフラ構築、リアーキテクチャの検討といった対応で総勢15名以上のエンジニアが参加するプロジェクトになっていました。
これらのシステム構築当初からこれまでの運用の過程で、システムの全体像や依存関係が不明確になってしまっている部分があり、整理が必要でした。また、プロジェクトの当初から段階的な移行ができるようにフェーズを区切っていましたが、当初想定していたスケジュール通り進まない部分も多く、フェーズ自体や移行の対応範囲の見直しが必要でした。
それぞれこのように対応しました。タスク管理については、当初はチーム全体で集まって進捗確認をしていました。しかし個々のシステムにおける進捗が見えにくい状況だったため、各システムそれぞれ個別で集まって進捗確認をし、細かい相談やブロッカーの把握がしやすいようにしました。
また、システム連携が必要なフェーズに近づいてきたら、関係するシステム同士で集まって進捗確認をするなど、プロジェクトの状況に応じて進捗確認の粒度を変えて対応していました。
システムの全体像・依存関係の整理では、個別の開発を進める前に移行の全体像のDesign Documentを作成し、チーム全体の認識を統一した上で各システムのDesign Document作成に移る形をとりました。
依存関係の整理ではエンジニアが専門で入って集中して対応し、段階的な移行に必要となる各システムの依存関係要素を洗い出してもらいました。10個以上のシステムがあるので当初から段階をある程度区切って移行する予定でしたが、開発者の進捗状況に応じて当初の方針に固執せず見直しながら進めました。
たとえば当初の予定では年末までにデータベースとdata aggregation systemの移行を終える予定でした。しかしデータベースの移行検証が難航したため移行検証を最優先とし、年末の移行は中止しました。年末の移行スケジュールがずれることで、春までの移行計画への影響がありました。
このため、対象とするシステムの範囲を洗い、見直す。つまり、スコープを調整することによって、移行計画を適宜修正していきました。
Uncertainty
最後にUncertainty、不確実性への対処です。プロジェクトの成功確率を高めるために、不確実性をいかに減らすか、どのように対応していくかという観点です。
こちらも3つあり、はじめに不確実性が高い状態を検知する・把握する必要、そして難易度が高いために不確実性が高いままとなっている問題。これらは後回しにすると、プロジェクトの進捗に大きな影響を与えるため、早期に対処する必要があります。
そして、環境起因によって再現が難しいために、不確実性が高いままの問題。つまり、本番相当の環境でないとわからない問題も、とくに移行の作業のタイミングや移行後のトラブルを避けるために、できるだけ事前に把握して潰しておく必要がありました。
それぞれどのように対応したのか。不確実性が高い状態をどのように検知・把握していたかは、いくつかあります。まず各システムごとのタスクを並べたときに、明らかにタスクが少ないものやタスクの洗い出しが完了していないものがないか確認していました。
また、それぞれのタスクについて細かく見積もりはしなかったものの、担当しているエンジニアにとって全く見通しが立っていないタスクはないかを常に確認するようにしていました。システム間・マイクロサービス間を連携していくフェーズでは、それぞれのシステム担当者間で認識齟齬はないか、あるいは担当が抜け漏れている部分がないかを確認していました。
難易度が高い問題については、チームのTechLeadにも協力してもらいました。各システムで難易度が高い問題が発覚した場合には、即優先的にTechLeadをアサインして、解決への道筋をつけてもらうようにしていました。
とくにプロジェクトの途中からはTechLeadを2名体制にし、広範囲・多数のシステムで同時多発的に問題が起きてもTechLead間で協力して問題に対処できるようにしていました。
最後に環境起因について、私たちのシステムは多くのデータを扱うので、本番相当の環境を用意する対応を行いました。そして、本番相当のデータで負荷検証やデータの整合性検証を事前に入念に行い、移行によるデータへの影響がないように注力しました。また移行作業についても、移行手順および問題が発生した場合の切り戻し手順それぞれにおいて、リハーサルを何度も繰り返し、移行作業の確度を上げるようにしていました。
systems and history
このようにして、この2年間複数の問題に直面しつつも、私たちメルペイTnSチームは2種類のクラウド間移行を進め、不正対策基盤を改善できました。
Summary
最後にSummaryです。このセッションでは、メルペイTnSチームとシステム構成、その歴史を最初に紹介しました。そしてこの2年間で実施した2種類のcloud間移行をなぜ行ったのかを説明しました。
最後に移行プロジェクトで直面したpriorities direction、project management、uncertaintyの3つの問題と、それぞれへの対応について話しました。
References
最後に私たちのチームの基準について、リファレンスを載せています。チームの紹介やrule based fraud detection system、今回話にあまり出てこなかったrealtime fraud detection systemの記事のリンクとなります。よろしければこちらもご覧になってみてください。
about Merpay Tns team
https://mercan.mercari.com/articles/31223/
about rule based fraud detection system
https://engineering.mercari.com/blog/entry/2019-05-27-112028/
about realtime fraud detection system
https://engineering.mercari.com/blog/entry/20220419-14cfb92734/
以上で、メルペイの不正対策を支えるマイクロサービス群をcloud to cloudで移行している話の発表を終えたいと思います。本日はご清聴ありがとうございました。
