株匏䌚瀟メルカリのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟メルカリ

株匏䌚瀟メルカリ の技術ブログ

å…š292ä»¶

こんにちはメルペむ Growth Platform Frontend チヌムのむンタヌン生の @uta です。 この蚘事は、 Merpay & Mercoin Tech Openness Month 2025 の2日目の蚘事です。 はじめに 私は3月から5月末たでの3ヶ月間、フロント゚ンド゚ンゞニアずしおメルペむのむンタヌンに参加したした。今回は、むンタヌン期間䞭に取り組んだタスクに぀いお振り返り、そこで埗た孊びや気づきに぀いお以䞋の内容をたずめたいず思いたす。 取り組んだタスク チヌムに぀いお Engagement Platformカレンダヌの開発 クヌポン怜玢機胜の開発 むンタヌンで埗た孊びず気付き メルカリカルチャヌの䜓隓 初めおの実務から孊んだ゚ンゞニア像 この蚘事が、メルペむのむンタヌンに挑戊しようず考えおいる方や、興味を持っおいる方の参考になれば幞いです 取り組んだタスク チヌムに぀いお 私が配属された Growth Platform Frontend チヌムは、Engagement Platform通称EGPずいう瀟内向けマヌケティングツヌルを開発しおいたす。このツヌルを䜿うず、マヌケタヌや PMプロゞェクトマネヌゞャヌがポむントやクヌポンなどのむンセンティブ配垃、LPランディングペヌゞの䜜成・公開、キャンペヌン䜜成ずいった CRM業務をコヌディング䞍芁で簡単に行えたす。 EGPに぀いおの詳现は䞋蚘ブログもあわせおご確認ください。 WYSIWYGりェブペヌゞビルダヌを支える技術ずSever Driven UIぞの拡匵 Enhancing Collaboration and Reliability: The Journey of Version History in our Page Editor Tool 【曞き起こし】WYSIWYGりェブペヌゞビルダヌを支える技術的マゞックの裏偎 – Hal Amano / Arvin Huang / Ben Hsieh / Jas Chen【Merpay & Mercoin Tech Fest 2023】 Engagement Platformカレンダヌの開発 むンタヌン期間䞭、最も泚力したタスクがEGPカレンダヌ画面の開発です。 問題点 EGPではキャンペヌンの䜜成および管理を行うこずができたす。これたでは、䜜成されたキャンペヌンの確認のために怜玢機胜を備えたテヌブルが提䟛されおいたした(図1.1)。 図1.1 キャンペヌンリストテヌブル しかし、この衚瀺方法ではキャンペヌンのスケゞュヌルを䞀元的に把握するこずができたせん。キャンペヌンに䌎う通知の重耇や、システムのキャパシティを超える可胜性が可芖化されおいないずいう問題がありたした。 改善策 そこで、私はキャンペヌンのスケゞュヌルを可芖化するカレンダヌの開発に取り組みたした(図1.2)。このプロゞェクトはPMの@ChloeさんがPRDプロダクト芁求仕様曞に起こしたもので、@Chloeさんやチヌムメンバヌにサポヌトをいただき぀぀、芁件の確認・Figmaによるデザむンの䜜成から実装・リリヌスたで取り組みたした。 図1.2 キャンペヌンカレンダヌ 苊劎した点 このプロゞェクトの䞭で最も苊劎した郚分が、キャンペヌンの仕様理解ずUIの考案です。 キャンペヌンには䜜成画面からもわかるように、さたざたな蚭定事項がありたす(図1.3)。これらの倉数がどのような操䜜を決定しおいるのか、たた、それをどのようにカレンダヌ䞊のUIに萜ずすかずいう郚分に悩みたした。 図1.3 キャンペヌン䜜成画面 キャンペヌンの仕様理解 キャンペヌンには倧きく分けお、real-timeずbatchの2皮類が存圚し、それぞれで配垃条件やタむミングが異なりたす(図1.4)。 図1.4 キャンペヌンの皮類 たた、キャンペヌンの配垃タむミングを決定づける重芁な倉数が2皮類存圚したす。1぀目は配垃期間を定めるcampaign schedule、぀目は配垃察象を評䟡するク゚リに関する条件を定めるsegmentationsです。さらに、キャンペヌンの皮類によっお、これらの倉数が実際の配垃スケゞュヌルにどのように関䞎するかも、それぞれ異なりたす(図1.5)。 図1.5 キャンペヌンの配垃タむミング䟋 カレンダヌUIの考案 このような仕様の違いを、次のようにUIに萜ずし蟌みたした(図1.6)。real-timeキャンペヌンは期間䞭に配垃資栌を満たしたタむミングで配垃されるキャンペヌンであるため、キャンペヌン期間を1日単䜍で可芖化したした。䞀方、batchキャンペヌンは単発もしくは定期的に配垃されるキャンペヌンです。そのため、キャンペヌン期間はラベルに蚘茉するのみに留め、カレンダヌでは時間単䜍で実際に配垃されるタむミングを可芖化したした。 図1.6 キャンペヌン皮別のカレンダヌぞの衚瀺方法 孊んだこず このcampaign scheduleずsegmentationsの耇雑さは、campaign scheduleが過去のむンシデントを受けお埌から远加された機胜であるこずに由来しおいるず䌺いたした。これたで私は、このような歎史的経緯を持぀プロゞェクトに取り組んだ経隓がなかったため、倧芏暡なプロゞェクトにおけるコヌドや仕様の理解の難しさを実感したした。たた、このような状況で自ら質問するこずの重芁性を孊びたした。キャンペヌンの理解からデザむン考案、実装に至るたで、チヌムメンバヌをはじめ、PMの方や他のチヌムの方々から倧倉貎重なサポヌトをいただきたした。 クヌポン怜玢機胜の開発 むンタヌン期間䞭、最も技術的に挑戊したタスクがクヌポン怜玢機胜の開発です。 問題点 EGPではクヌポンの䜜成および管理を行うこずができたす。これたでは、䜜成されたクヌポンを確認するためのテヌブルが提䟛されおいたしたが、怜玢機胜は存圚しおいたせんでした(図2.1)。たた、キャンペヌンのリワヌドずしおクヌポンを遞択する際にも、怜玢機胜がないこずで効率が悪く、この機胜は倚くの堎面で長らく埅望されおいたした。 図2.1 クヌポンリストテヌブル デヌタフロヌ これたでのクヌポンテヌブルでは、他のチヌムが開発したAPIからデヌタを取埗しおいたした。怜玢機胜の実装においお、たずそのAPIを利甚するこずを考えたす。しかし、クヌポンは歎史的に叀いペヌゞであり、APIにもフィルタヌや怜玢機胜が実装されおいないずいう問題がありたした。 そこで、既存のデヌタベヌスに加えおSpannerを甚いる新しいデヌタフロヌを採甚したした(図2.2)。新たにクヌポンのデヌタを既存のデヌタベヌスずSpannerの䞡方に保存し、SpannerずGraphQLを掻甚しお怜玢機胜を実装したした。これにより、より効率的で拡匵性の高いデヌタ取埗が可胜ずなりたした。 図2.2 クヌポン怜玢機胜のデヌタフロヌ デヌタの移行やリリヌスはむンタヌン期間内に間に合いたせんでしたが、テキストによるクヌポン名の怜玢機胜や、リタヌンタむプに基づく絞り蟌み機胜を実装するこずができたした(図2.3)。 図2.3 クヌポン怜玢画面 孊んだこず SpannerやGraphQLずいったバック゚ンド領域の技術に挑戊する機䌚を埗られたこずは、倧きな孊びずなりたした。私はこれたで䞻にフロント゚ンドの技術を扱っおきたしたが、バック゚ンド領域にも觊れるこずで、自分の芖野を広げるこずができたした。たた、チヌム党䜓を芋枡しおも、フロント゚ンドチヌムでありながら、必芁に応じおバック゚ンド領域のタスクにも積極的に取り組んでおり、その姿勢にプロフェッショナル性を匷く感じたした。こうした環境でむンタヌンができたこずは非垞に刺激的で、自分自身の成長に぀ながったず思いたす。 むンタヌンでの孊びず気付き メルカリカルチャヌの䜓隓 このむンタヌン期間䞭には、メルカリカルチャヌを感じられる機䌚がたくさんありたした。 たず驚いたこずは、 倧量の情報にアクセスできる環境です。ほが党おのSlackチャンネルやドキュメントぞのアクセスが蚱可されおおり、それらの情報を自由に閲芧できるこずに驚きたした。こうしたアクセスの範囲は、瀟員ずほずんど同じであり、むンタヌン生であっおも「䌚瀟の䞀員」ずしお扱われおいるように感じたした。 たた、印象的だったのがAll Hands です。これは各郚眲が定期的に開催するミヌティングで、むンタヌン生も自由に参加できるものでした。この堎では、チヌム倖の取り組みや䌚瀟党䜓の目暙に぀いお詳しく知るこずができ、普段接する機䌚の少ない他郚眲の掻動にも觊れるこずができたした。ミヌティング䞭にはSlackの random チャンネルが掻発に䜿われおおり、メンバヌが所属郚眲や圹職に関係なく意芋を亀換し合ったり、気軜にリアクションを飛ばし合う姿が非垞に印象的でした。 これらの䜓隓を通じお、メルカリが耇数の事業領域を抱える倧芏暡な組織であるにもかかわらず、䞀䜓感のあるワンチヌムずしお進んでいる文化を匷く感じたした。たた、むンタヌン生であっおも瀟員ず同じ情報にアクセスし、実際にメルカリで働くむメヌゞをリアルに描くこずができたした。䌁業の珟実的な働き方や意思決定のプロセスに觊れるこずができ、非垞に貎重な経隓でした。 初めおの実務から孊んだ゚ンゞニア像 今回のむンタヌンは、私にずっお初めおの実務経隓でしたが、゚ンゞニアずしおの䟡倀を考える倧きなきっかけずなりたした。これたでは、゚ンゞニアずしおキャリアを築くためには、機胜を実装するコヌディングスキルを高めるこずが重芁だず考えおいたした。しかし、実務を通じお、技術力だけではなくチヌム党䜓ぞの貢献が䞍可欠であるこずを孊びたした。 特に印象に残っおいるのは、EM゚ンゞニアリングマネヌゞャヌの@ben.hsiehさんずの関わりです。@ben.hsiehさんは定期的に1on1を実斜し、私の状況や目指したい方向性に぀いお䞁寧に聞いおくださいたした。そしお、それらを螏たえた䞊で適切なタスクを割り振っおいただきたした。䟋えば、EGP内で䜿甚されるLP䜜成ツヌルの䜿い方を知りたいず盞談した際、そのツヌルを掻甚した実際のタスクを割り圓おおいただき、実践的な孊びを埗る機䌚ずなりたした。 こうした環境の䞭で私は、ただコヌドを曞く力を高めるだけでなく、チヌムの䞀員ずしおプロダクトや目暙に貢献できる゚ンゞニアでありたいず考えるようになりたした。゚ンゞニアずしお目指すべき圚り方や方向性をより明確にするこずができたず感じおいたす。 EM の@ben.hsiehさんが蚘事を公開しおいたすので、あわせおご確認ください。 「 Rethink Tool’s UI/UX – Human-Centric to AI-Driven 」 おわりに 本蚘事では、メルペむのむンタヌンで取り組んだタスクや、そこから埗た孊びず気づきに぀いおお話したした。技術的なスキルを磚くだけでなく、メルカリグルヌプの文化に觊れ、゚ンゞニアずしおの䟡倀を考えるきっかけを埗るこずができた、ずおも貎重な3ヶ月間でした。 このような充実した経隓が埗られたのも、メンタヌの@togamiさんをはじめ、チヌムメンバヌや関わっおくださった党おの方々の手厚いサポヌトのおかげです。この堎をお借りしお改めお感謝を申し䞊げたす。ありがずうございたした 珟圚、メルカリではむンタヌンを募集しおいたす。このブログを読んで「自分も挑戊しおみたい」ず思った方は、ぜひ䞀歩を螏み出しおみおください。きっず玠晎らしい経隓が埅っおいるず思いたす Students | 採甚情報 明日の蚘事は メルコむン Opsチヌム @toshinaoさんです。匕き続きお楜しみください。
はじめに こんにちは。メルペむVPoEの @keigow です。 この蚘事は、 Merpay & Mercoin Tech Openness Month 2025 の初日の蚘事です。 これたでもメルペむ及びメルカリグルヌプでは、瀟内向けChatGPTずも蚀える Ellie の取り組みや、LLMをプロダクトや業務効率化に掻かすためのハッカ゜ンむベント ぐげん䌚議 の開催、プロダクトぞのLLM利甚も含め、AI/LLMの掻甚を掚進しおきたした。 AI/LLMの進化のスピヌドは想像以䞊に早く、毎日のように新しいアップデヌトがありたす。最近ではこれたで以䞊にAI Nativeな組織、プロダクトに生たれ倉わっおいくべくさたざたな取り組みを進めおおり、その䞀郚をご玹介できればず思いたす。 AI Coding Assistant Toolの掻甚 元々2023幎の6月に GitHub Copilot の利甚を開始し、瀟内での利甚も埐々に増えおいたしたが、 Cursor の利甚開始に䌎い、瀟内での掻甚が倧きく進みたした。珟圚CopilotずCursorだけでも、Engineering組織党䜓の玄8割のメンバヌが利甚しおいたす。たたCoding Agentずしお Devin の利甚も広がっおいたす。 Engineering組織ずしおも今QのOKRの䞭で䞀番重芁なKR1ずしお、党おの゚ンゞニアが100%䜕らかのAI Coding Assistant Toolを掻甚し、生産性を高めるこずを目暙に蚭定したした。生産性を蚈枬する仕組みずしおこれたで瀟内では独自で Four Keys などを取埗しおいたしたが、新たに DX を党瀟で導入したした。こちらの詳现に぀いおは17日目のntkさんの蚘事で玹介予定です。 目暙の蚭定ず党瀟員向けにツヌルを提䟛する予算の確保、䞖の䞭の盛り䞊がりも盞たっお急速に導入が進み、各チヌム単䜍でAI掻甚のオフサむトを実斜したり、䞀週間Vibe Codingのみの期間を蚭定するなど瀟内でも盛り䞊がりを芋せおいたす。それぞれのむベントに぀いおの取り組みの様子も今埌の蚘事で玹介予定なので、ぜひ埡芧ください。 MCPサヌバによる瀟内ツヌル連携 Model Context Protocol (MCP)を掻甚した瀟内ツヌルの連携も急速に進んでいたす。MCPサヌバに぀いおはセキュリティの芳点から安党性が確認されおいるものを掻甚するため、瀟内でMCPサヌバの実装をたずめたRepositoryが䜜られおいたす。JIRA、Confuluence、Slack、Google Driveを始めずした3rd Party補のツヌルや、内補のMicroservicesの管理ツヌル、Google SpannerやBigQueryなどのMCPサヌバが䜜られ、Cursorなどを利甚しお䞻にLocal環境で掻甚されおいたす。これらのツヌルの利甚者ぱンゞニアに限らないため、さたざたな職皮のメンバヌが自身の業務に合わせおツヌルの掻甚方法を怜蚎するようになりたした。 䞊行しお各ツヌル自䜓にもEmbedされたAI Chat機胜が導入されおくるようになっおいるため、今埌もベストプラクティスの怜蚎をしおいきたす。MCPサヌバの掻甚に぀いおは7日目のseitauさんの蚘事でも觊れられる予定です。 Merpay AI Labsの取り組み 業務フロヌの改善におけるAI/LLMの掻甚を掚進するため、メルペむにはAI Labsずいう専門のチヌムがありたす。 日毎にアップデヌトされるモデルやツヌルの進化に合わせお、各チヌムでのAI掻甚ニヌズが増すなか、AI掻甚による業務フロヌの改善を進めたいが、どのように進めればよいのかわからないずいった声を聞く機䌚が増えおきたした。 実際に郚眲内で行われおいる業務のフロヌは耇雑か぀、ステヌクホルダヌも倚く、さたざたな課題があったずしおも、それが業務フロヌを改善すべき問題なのか、単にシステム化をすればいいだけなのか、あるいはAIを掻甚するこずで倧きなアりトカムを埋める領域なのかの刀断自䜓も難しいずいう問題がありたした。 Engineeringの郚眲ずしおもそれをサポヌトし、AI掻甚を掚進するこずが組織ずしおのむンパクトが倧きいず考え、今幎の1月に改めおチヌムのMissionやVisionを蚭定したした。以䞋は抜粋になりたすが、䌚瀟党䜓のAI掚進を行うこずをMissionずしお定矩しおいたす。 Mission AI LabsはFintechのAI掻甚ず開発をEnable/Driveしたす。AI Labsはそのための、実践者であり、䌝道者であり、觊媒になりたす。 FintechにおけるAI Nativeなアプリケヌション開発/業務蚭蚈のCenter of Excellence䞭栞ずなる組織ずしおの胜力を確立し、AI Nativeな事業掚進に貢献したす。 このチヌムで取り組んだプロゞェクト䟋ずしおは以䞋のようなものがありたす。成果が出たもの出なかったものなど含め、結果はさたざたですが、着実に知芋を貯めるこずができおいるず思いたす。 コンセプトからのアプリのデザむンの自動生成 仕様からのQAのテストケヌスの自動生成 画像生成AIを甚いたキャンペヌンのキヌビゞュアル生成 お客さた問い合わせの芁因分析 専門チヌムの問い合わせ工数削枛のための察応効率化Botの䜜成 画像生成の䟋 特にアプリのデザむンの自動生成に぀いおは、珟圚進行系で面癜い取り組みになっおきおいたす。こちらは18日目のhiroさんの蚘事で詳现をご玹介予定です。 おわりに これたで取り組みの䞀郚をご玹介しおきたしたが、䞖の䞭の盛り䞊がりず勢い同様に、瀟内でも各チヌム、各メンバヌが次々ず新しくAI掻甚に取り組み、さたざたなツヌルが䜜られるずいう状況が続いおおり、その党おを把握するこずも困難な状態になっおいたす。キャッチアップだけでも倧倉な時代になっおきたしたが、この熱狂の䞭で仕事に取り組めおいるこずは幞せな状況だなず感じおおり、この目たぐるしい倉化を楜しんでいければず思いたす。 明日の蚘事はbenさんによる「Rethink Tool’s UI/UX – Human-Centric to AI-Driven」ずutaさんによる「メルペむむンタヌン䜓隓蚘実務の䞭での孊びず気付き」の2本です。匕き続きお楜しみください。
こんにちは。メルペむ Engineering Engagement チヌムの @mikichin です。 メルカリグルヌプは「あらゆる䟡倀を埪環させ、あらゆる人の可胜性を広げる」をミッションに、さたざたなサヌビスを展開しおいたす。 メルペむは単なる決枈サヌビスではなく、新しい「信甚」を基盀ずしお、それに基づく埪環型瀟䌚、なめらかな瀟䌚を創るこずを、メルコむンはテクノロゞヌによっお、さたざたな䟡倀芳の境界線を打ち砎り、誰もが暗号資産・デゞタル資産などあらゆる䟡倀を簡単に亀換できる䞖界の実珟を目指しおいたす。 そのためには、お客さた・䌁業・金融機関など、さたざたなステヌクホルダヌに察しお「OPENNESS」な姿勢で向き合うこずで、もっず身近なものに倉えおいきたいず考えおいたす。 本䌁画は、技術も「OPENNESS」にしおいこうずいう考えのもず、2019幎にスタヌトしたした。 今回から「Merpay & Mercoin Tech Openness Month」ずリニュヌアルし、よりパワヌアップした圢でお届けしたす。 「Merpay & Mercoin Tech Openness Month 2025」では、メルペむ・メルコむン・メルカリモバむルの開発をしおいる゚ンゞニアたちの取り組みをご玹介したす。 各゚ンゞニア組織がテクノロゞヌでお客さたの課題解決を実珟するこずを倧切にし、その挑戊の䞭で埗た知芋を6月2日から玄1ヶ月間に枡り毎日公開しおいきたす技術、開発蚭蚈や思想、組織ストラクチャヌ、Tips、その他最近の取り組みなど、幅広くお䌝えしたす。 2019幎は こちら 2020幎は こちら 2021幎は こちら 2022幎は こちら 2023幎は こちら ▌公開予定衚 こちらは、埌日、各蚘事ぞのリンク集になりたす Title Author メルペむにおけるAI掻甚の取り組み @keigow Rethink Tool’s UI/UX – Human-Centric to AI-Driven @ben.hsieh メルペむむンタヌン䜓隓蚘実務の䞭での孊びず気付き @uta メルコむンでSystem Design Interviewを導入したした @toshinao PCP LLM Week レポヌト @komatsu (ä»®) チェックアりトの゜リュヌション開発 @foghost チェックアりト゜リュヌションのアヌキテクチャ呚りの話 @susho Cursorぞの瀟内ツヌル知識の効率的な泚入: MCPサヌバヌ掻甚事䟋 @seitau 生成AI時代の゚ンゞニアの生き残り戊略に぀いお @Joraku GASを぀かっお効率をあげたしたmvnoダミヌ事業者ずjira䜜成補助 @toshick Devin にE2Eテストの実装を任せる @anzai 仮むンタヌンレポヌト @Soma Nakao SRE2.0: LLMサヌビスの信頌性を枬る新しい品質指暙の玹介 @T メルカリモバむル Dev OffsiteでAI Hackathonをした話 @k_kinukawa Checkout frontend design @David, @anzai gRPC Federationで3rd party向けAPIを実装する @fivestar 6幎間のむンシデント察応/管理で盎面した課題ず改善 @foostan Mercari Pipeline (旧Mercari Dataflow Template) v1をリリヌスしたした @orfeon (仮AI関連でなにか or Universal link関連 @takeshi in iOS WWDC2025参加レポヌト @Shunta TBD: Dev Ex Improvement Cycle using DX @ntk1000 仮AI Creator @hiro TBD: AI関連 @abcdefuji Integration of AppIntents to a Project That Uses Bazel Build System @cyan メルカリWebにメルコむンを組み蟌む怜蚌をした話 @y-arima kubecon参加レポヌト @keitasuzuki どんな知芋が埗られるのか、毎日が楜しみです。 Merpay & Mercoin Tech Openness Month 2025 の1日目は、メルペむ VPoE @keigow が執筆予定です。 ひず぀でも気になる蚘事がある方は、この蚘事をブックマヌクしおおくか、 ゚ンゞニア向け公匏Twitter をフォロヌチェックしおくださいね
はじめに こんにちはメルカリのヘルプセンタヌチヌムで、2025幎の2月䞭旬から5月䞭旬たでの3か月間むンタヌンをしおいた@markunです。私は普段、蚎論の構造を可芖化するシステムに぀いお研究しおいるのですが、システムの䜿いやすさを改善するなかで、ナヌザヌのニヌズを的確に反映するスキルを䌞ばしたいず感じおいたした。そこで今回、お客さたの䜓隓を重芖し、倧芏暡なナヌザヌを抱えおいるメルカリでどのようにプロダクト開発が行われおいるかを孊ぶべく、フロント゚ンド゚ンゞニアずしおむンタヌンに参加したした チヌムに぀いお ヘルプセンタヌチヌムは、お客さたが疑問や問題を自己解決するためのヘルプコンテンツの提䟛ず、解決が難しい堎合のメルカリ事務局ぞの問い合わせのためのプラットフォヌムの構築を行っおいたす。たた、ガむドコンテンツやお問い合わせフォヌムを管理する瀟内向けシステムの開発・運甚を通じお、お客さたのサポヌト䜓制を支えおいたす。 アゞャむル開発に぀いお アゞャむル開発ずは、ナヌザヌのニヌズに柔軟に察応しながら迅速に改善を重ねる開発スタむルの䞀皮です。ずいっおも、コヌディング芏玄などの具䜓的なルヌルがあるわけではありたせん。ここで鍵ずなるのは、チヌムの䞀人ひずりが「 アゞャむル゜フトりェア開発宣蚀 」に代衚される数々の原則を実践する意識を持぀こずです。 アゞャむル開発はお客さたの満足床を効果的に高められたすが、経隓がない方にずっおは䞭々むメヌゞが掎みにくいず思いたす。そこで本蚘事では、むンタヌンで䜓隓したヘルプセンタヌチヌムでのアゞャむル開発の実践䟋をご玹介したいず思いたす。アゞャむル開発ぞの理解を深められたら幞いです ガむド蚘事線集甚の瀟内ツヌルの倚蚀語察応 メルカリは、今幎3月に 囜際メルカリ䟿 ずいう海倖のお客さたが日本囜内で出品されおいる商品を賌入できるサヌビスをリリヌスしおいたす。これを受けお、ヘルプセンタヌでは海倖のお客さた向けのガむドの提䟛が始たりたした。そこでメンタヌず盞談しお、瀟内向けの蚘事線集ツヌルの倚蚀語察応の改善点に぀いお、実際にツヌルを䜿甚しおいる方に盎接話を聞くこずにしたした。 話し合いの結果、日本語話者も倚蚀語に察応した蚘事䞀芧ペヌゞをよく䜿うこず、その際に蚘事䞀芧が垞に䞭囜語で衚瀺され、目的の蚘事を探しにくいずいうこずが明らかになりたした。この課題を解決するため、フロント゚ンドに蚘事䞀芧画面の衚瀺蚀語を切り替える機胜を远加するこずにしたした。 取り組んだこず いざ実装に取り掛かるず、倧きな課題に盎面したした。蚘事䞀芧を衚瀺する際、指定された蚀語の翻蚳デヌタが甚意されおいない蚘事は取埗されない仕様だったこずが刀明したのです。そのためフロント゚ンド偎で蚘事䞀芧の衚瀺蚀語に日本語を指定するだけでは、䞀郚の蚘事が欠けおしたうずいう問題が生じたした。そこで、翻蚳が存圚しない堎合は他の蚀語の蚘事を埋めお返す、蚀語フォヌルバックず呌ばれる凊理䞋図参照をバック゚ンド偎に実装するこずで察応したした。 アゞャむルなポむント アゞャむル開発には、ナヌザヌを第䞀に考えるずいう原則がありたす。この原則に沿っお、実際にツヌルを䜿う人たちに盎接話を聞いたり、担圓しおいたフロント゚ンドだけでなくバック゚ンドにも積極的に挑戊したこずで、最初に仕様が決たった時からの状況や芁望の倉化に柔軟に察応できたした。たた、ヒアリングから玄1か月ずいう短期間で、今必芁ずされおいる機胜をリリヌスするこずができたしたこの成果は、たさにメルカリのバリュヌである「Move Fast」を䜓珟したものだったず感じたす。 この経隓を通じお、開発者の䞻䜓性ずナヌザヌずの継続的な察話を重芖するアゞャむル開発の匷みを実感したした。たた、自分がこれたでに経隓しおきたこずに瞛られずにナヌザヌを最優先する姿勢が、メルカリの特城であるGo Boldなプロダクト開発に繋がるこずが分かりたした お困りの商品遞択画面のリファクタリング ヘルプセンタヌ では、商品を遞択するず関連するガむドのペヌゞに遷移する機胜がありたす。サヌビスの運甚を続ける䞭でこの仕組みに関する凊理が耇雑化しおいたのですが、ペヌゞ遷移を制埡するロゞックがフロント゚ンド偎に実装されおいたため、今埌拡匵する際に開発のボトルネックになるのではないかずいう懞念がありたした。そこで、そのロゞックをバック゚ンドぞ移行するこずを怜蚎したした。 取り組んだこず この機胜を実装するうえで、様々な遞択肢がありたした。䟋えば、デヌタベヌスに新たなテヌブルを远加する、テヌブル構造は倉えずにバック゚ンドのロゞックのみ倉曎する、あるいはそもそも倉曎を芋送るずいう遞択肢もありたした。そこで私は、考えられる党おの遞択肢ずそのメリット・デメリットを詳现に蚀語化しおドキュメントに敎理し、それをもずにチヌムで実装の方針を議論したした。最終的に、バック゚ンドのロゞックのみを倉曎する方針で実装を進めたした。 アゞャむルなポむント アゞャむル開発では、課題解決に䞻䜓的に取り組むこずが重芖されおいたす。このケヌスでは、APIのむンタヌフェヌスやテヌブル構造の倉曎などのあらゆる可胜性を培底的に議論し、実装の方針決めからリリヌスたで裁量を持っお掚し進めるこずができたした。 この経隓を通じお、自分で最初から最埌たでやり遂げるアゞャむル開発の難しさを実感するず同時に、責任を持っおやり通す楜しさずやりがいを身に染みお感じられたした。たた、同じ凊理でも曞き方は想像以䞊に数倚く存圚するこず、その䞭で広い芖野を持っお䜕故その凊理をそこに曞くのかを垞に考えるこずが倧切であるず孊びたした。 むンタヌンで埗た孊び これたで玹介したこず以倖にも、゜フトスキルずハヌドスキルの䞡面で倧きく成長するこずができたした。 ゜フトスキルの面では、盞手の意芋をうたく聞き出すには質問の範囲を絞った方がよいずいうこずを孊びたした。私は最初、タスクの方針に぀いお盞談する際に「どんな機胜があるず良いですか」「解決策は䞉぀ありたすが、どれが良いですか」ずいった挠然ずした聞き方をしおいたした。これは䞀芋幅広く意芋を匕き出せるようにみえたすが、実際には混乱を招いおしたうこずがよくありたした。盞手の意思を尊重し぀぀、自分の考えや質問の目的を明確にした䞊で話を聞いた方が円滑に議論を進めやすいずいうこずが分かりたした。 たた、チヌムワヌクの倧切さを再認識したした。私たちのチヌムでは2週間に1回、レトロスペクティブず呌ばれる振り返り䌚を行っおいたす。このミヌティングでは毎回感謝のコメントが枠をはみ出すぐらい盛り䞊がり、そこで生たれたモチベヌションや連垯感が私のむンタヌンでの取り組みの原動力になっおいたした。チヌムワヌクの重芁性は圓たり前すぎお芋過ごしがちですが、その䟡倀を改めお深く実感したした。 ハヌドスキルの面では、レむダヌごずの圹割を把握するこずの重芁性を孊びたした。取り組んだタスクの䞭には、機胜自䜓はスムヌズに実装できたものの可読性や拡匵性などの芳点からレビュヌを受け、関数の蚭蚈から芋盎すずいったこずもよくありたした。むンタヌンであっおも察等に接しおもらえたおかげで、䜕故そのコヌドをそこに曞いたのかを明確にする、様々な職皮の方に䌝わるような倉数名を考えるなどの基瀎的な工倫に䞀切の劥協を蚱さないこずがいかに重芁かずいうこずが分かりたした。 たた、テストに関しおも倧きな孊びがありたした。私は、むンタヌンに参加するたでテストを曞いたこずがなく、単にバグを発芋するための手段だず思っおいたした。もちろんそれも重芁ですが、特にナニットテストのコヌドは仕様曞ずしおの圹割も果たしおおり、どの関数に䜕が期埅されおいるかが䞀目でわかるよう培底的にシンプルに曞くべきだずいうこずを孊びたした。たた、そのためにfor文やif文さえ可胜な限り䜿わないようにしおいるこずを知り、驚くず同時にテストコヌドの奥深さに感銘を受けたした。 こうした経隓を通じ、コヌドの質を高めるには高床なテクニックを䜿いこなすこずよりも、シンプルさや目的に即した曞き方になっおいるかを考える力を磚くこずが重芁だずわかりたした。実際の珟堎では䜕が求められるのかを身をもっお知るこずができ、自分のコヌドの保守性や可読性だけでなく、システム開発の姿勢そのものぞの意識も倧きく倉わりたした。 犏岡合宿の話 むンタヌン開始から1か月が経った頃、犏岡で開催されたオフサむトに参加したした。ヘルプセンタヌチヌムは犏岡や倧阪など日本各地を拠点ずしおいるメンバヌが倚く、普段はオンラむンでのコミュニケヌションが䞭心なため、察面での顔合わせも兌ねお䌁画されたした。ミヌティングでは、珟状の共有やヘルプセンタヌの今埌の展望に぀いお議論が癜熱したした その埌はみんなで倕食をずり、普段なかなか顔を合わせられないチヌムでの芪睊を深められたしたずりたぶし、絶品でした。ただ、残念ながらずりたぶしは気が぀いたら食べ終わっおいお写真を撮り忘れおしたったので、代わりに締めで頂いたラヌメンを茉せたす。こちらも同じぐらい矎味でした おわりに 本蚘事ではメルカリのむンタヌンで取り組んだこずず、アゞャむル開発の経隓を通しお孊んだこずをご玹介したした。フロント゚ンド゚ンゞニアずしお参加しながら、バック゚ンドのコヌディングにも積極的に取り組み、課題を芋぀けおは玠早く改善するずいうサむクルを繰り返し回すこずができたした このように倧胆に挑戊できたのは、お客さたのニヌズを培底的に考え抜き、チヌムずの綿密な議論を通じお䜕故その課題に取り組むのかを明確にできたこず、その䞭で責任ず裁量を持っおタスクをやり遂げるアゞャむル開発の原則を実践できたこず、そしお䜕より挑戊を歓迎しおくれる環境があったからだず匷く感じたす。 メンタヌの@monkukuiさんはじめ、お䞖話になった皆さたに、この堎を借りお感謝させおいただきたす。ありがずうございたした 本ブログがメルカリのむンタヌンや入瀟を怜蚎しおいる皆様の参考になれば幞いです。この蚘事を読んで興味が湧いた方は、ぜひメルカリにチャレンゞしおください https://careers.mercari.com/jobs/
はじめに こんにちは北陞先端科孊技術倧孊院倧孊修士1幎の@midorinです。 メルペむのBalanceチヌムにお1月から3月にかけおの2ヶ月間、バック゚ンドのむンタヌンに参加したした。 今回は、むンタヌンで䞻に取り組んだ通知の改善ずメルペむで孊んだこずを本ブログに蚘茉したす。 メルペむ Balanceチヌムに぀いお メルペむはメルカリの売䞊金や銀行口座のお金が䜿える決枈サヌビスです。Balanceチヌムでは売䞊金などの残高やポむント、債暩を管理するサヌビスを開発しおいたす。 ポむント倱効通知 メルペむではポむントの倱効期限が近づいた際に通知が届くようになっおいたす。 具䜓的には圓日から起算しお1日埌、7日埌、30日埌のいずれかに倱効するポむントがあれば通知が届く仕様ずなっおいたす。この通知は毎朝11時に実行されるバッチ凊理により実珟されおおり、このバッチ凊理はBalanceチヌムが管理しおいたす。 珟行のポむント倱効通知は付䞎されたポむント量に関わらず通知が届くため、1Pの付䞎のみでも倱効期限の30日前、7日前、1日前の蚈3回届く煩わしさがありたした。これにより、少額付䞎のキャンペヌンが実斜しづらいずいう匊害が生じおいたした。 本むンタヌンでは䞻にこの通知の改善に取り組みたした。 改善の流れ 今回の改善は䞻に以䞋のような流れで行いたした。 仕様の確認 改善案の提案 実装〜リリヌス 順に説明したす 仕様の確認 実装を芋ながら珟状の仕様を確認し、ドキュメントにたずめたした。結果、以䞋のような仕様であるこずがわかりたした。 1, 7, 30日埌に倱効期限がくるポむントが存圚するか確認する あれば、それらのうち最も盎近の日付に぀いお倱効するポむントの通知を送る たずえば、1, 7日埌それぞれに倱効期限がくるポむントが存圚すれば1日埌が優先される 改善案の提案 仕様を確認したのち、珟状の通知の総数、消費されたポむント額が通知のタむミングでどれだけ増えおいるか、参考ずなる他瀟の事䟋などを調べたした。調査結果ずしお、珟状の仕様における通知の効果はそこたで倧きくなく、お客さた䜓隓向䞊のために枛らしおも良いだろう、ずいう結論に至りたした。 チヌムの方ず協力しお改善案を考えたした。ミヌティングを重ねる䞭で「少額のポむントに関しおは通知の䟡倀が䜎く煩わしく感じおいるのではないか」ずいう仮説が浮かび䞊がりたした。これを受け、以䞋のような案を候補ずし、PMなどが参加しおいる、プロダクトずしおの仕様を決定するミヌティングにお話し合いたした。 各日に閟倀を蚭け、倱効するポむントが閟倀を超えない堎合は通知しない 定期䟿のように決たった期間の倱効するポむントをたずめお通知する ミヌティングにお合意がずれ、リヌガルから法的な問題がないこずも確認いただけたため、閟倀を蚭ける案で実装を進めるこずにしたした。 珟状ずのギャップが小さいずころから段階的に導入するために、1日埌の通知には閟倀を蚭けず、7日埌には100、30日埌には500の閟倀を蚭けたした。閟倀の根拠ずしお、付䞎しおいるポむントは100ポむントず500ポむントが特に倚いずいう点があげられたす。傟向ずしお額が倧きくなるほど付䞎数は枛っおいるのですが、100ポむントず500ポむントの付䞎だけがキャンペヌンで付䞎するこずが倚く、䟋倖的に増えおいたした。ここがお客さたの䜓感が倉わる境界であり、効果的に煩わしさが解消できるず考え、ここに閟倀を蚭けるこずにしたした。 この仕様により、以䞋の図のように1P付䞎の際は通知が䞀回のみになる改善がなされたす。予枬ずしお、ポむントの倱効に関する通知が30%以䞊枛少するこずを芋蟌んでいたす。 △保有ポむントが1Pのお客さたが受け取る倱効通知(閟倀導入埌) 実装〜リリヌス ここたでで提案した仕様を実装したした。単玔に閟倀の远加をするだけでなく、新たにテストを蚘述し、QAを経おリリヌスぞ持ち蟌みたした。 テストの蚘述ではテストケヌスの远加しやすさや意味など、さたざたな指導をいただきながら実装を進めたした。 QAでは担圓の方に仕様を䌝えテストケヌスの挏れがないかを確認しお、リリヌス時に問題が起きないように努めたした。 むンタヌン期間の最終週にリリヌスをし、問題なく通知量を枛少させるこずができおいるこずを確認したした。 今埌は倱効総額が䞊がらないこずを目暙に掲げ、リリヌス埌も通知数や消費タむミングなどのデヌタを芋ながら継続的に改善しおいくのがベスト、ずいう話に萜ち着きたした。 孊び 今回のむンタヌンではデヌタを元に仕様を策定し、実プロダクトに適甚するずいう貎重な経隓をさせおいただくこずができたした。この経隓を通しおいく぀かのこずを孊びたした。 コヌド品質を担保する仕組み テストをただ曞くだけでなく、远加しやすく品質を保蚌するようなものを曞いたり、バグを生みにくいコヌドを曞いたりなど、普段曞いおいるようなコヌドからさらに深く考えお進められおおり、さたざたな発芋がありたした。Balanceチヌムが管理しおいるサヌビスは䞀぀バグが起きるだけでも臎呜的になり埗るため他よりもコヌド品質に重点が眮かれおいるずいう話を䌺い、サヌビスの目的によっおコヌドの良さの指暙が倉わるずいう孊びを埗たした。 効率的にReviewを進める心がけ いく぀かのタスクを進める䞭で速床は良いが芋萜ずしがある旚のフィヌドバックがありたした。自身でも課題に感じおおり、改善方法を盞談したずころ他の人のPRをReviewしたり、Self-Reviewしたりするのが良さそう、ずいう䞀぀の解決策を提瀺いただけたした。これを実践したずころ、芋萜ずしは少なくなり、新たな知識を埗られるような本質的な指摘、議論ぞず玠早く移動できるようになり、有意矩に時間を䜿うこずができるようになったず感じおいたす。 デヌタ駆動の改善プロセス ポむント倱効通知の改善は以前から課題ずしお認識されおいたしたが、具䜓的なデヌタが䞍足しおおり、着手できずにいたした。今回、チヌム党䜓でデヌタを甚意しPMらに提案するこずで実装を進めるこずが可胜になりたした。 甚意したデヌタに぀いお、Balanceチヌムで管理しおいるサヌビスではDBにSpannerを利甚しおおり、このデヌタは定期的にBig Queryに同期されおいたす。今回はBig QueryのデヌタをLooker Studioにお可芖化し、分析したした。これにより、PMらにもわかりやすいデヌタの提瀺をするこずができ、スムヌズに議論を進めるこずができたした。客芳的な議論、方針の策定をするためにデヌタが圹立぀こずを改めお実感したした。 お客さた䜓隓の考え方 今回の改善は通知を枛らすものであるため、短期的に芋るずアプリを開く確率が枛り、利甚率などに圱響しおしたう可胜性はありたす。しかし、お客さた䜓隓を向䞊させるこずで長期的には利甚を継続しおいただいたり、䟡倀の高い通知に絞る事で通知をオンのたたにしおいただいたりずいうデヌタに珟れにくいメリットも存圚したす。お客さた䜓隓を䞊げるビゞネス的な良さを話し合えたのはずおも良い経隓だったず感じおいたす。 むンタヌン実務以倖の話 今回のむンタヌンではタスクを進める以倖にもいろいろな経隓があり、どれも玠晎らしい䜓隓だったため共有したす。 開発合宿 むンタヌン開始埌すぐに合宿があり、さたざたな方ず亀流したり、Swiftを曞いたりしたした。業務的なコミュニケヌションを始める前に瀟員さんのあたたかい雰囲気をしるこずができたため、ずおも良い経隓でした。 開発合宿初日に財垃を萜ずしたのですが、期間䞭に戻っおきお日本のあたたかさを感じるこずもできたした。届けおくださった方、ありがずうございたす。。。 開発合宿の様子は、こちらをご確認ください。 勉匷䌚 チヌム内だけでなく、有志で集たった勉匷䌚が定期的に開催されおおり、技術に察するモチベの高さを䌺うこずができたした。 Tech Talkず呌ばれるゆるめのLTも存圚しおおり、こちらでは業務内倖のさたざたな知芋を埗るこずができたした。 mertip メルカリではmertipず呌ばれるピアボヌナスの仕組みが存圚したす。むンタヌン生でもこれを利甚するこずができ、自身も積極的に利甚しおいたした。他の方に貢献するこずが奚励されおいる、ずいうのが目に芋えおわかるこず、質問などをする際に気埌れしないこずなどがずおもよかったず感じおいたす。 たずめ 本ブログではメルペむのむンタヌンで取り組んだポむント倱効通知の改善ずその経隓を通しお孊んだこずを蚘述したした。今回の経隓で、バグの生みにくいコヌドの曞き方などのようなハヌドスキルず、いかにしおタスクを進めおいくかなどのような゜フトスキルを埗るこずができ倧きく成長できたず感じおいたす。 たた、むンタヌン参加前埌で䌚瀟の印象に倉化がありたした。参加前は技術力が匷い方々が黙々ず䜜業をしおいる印象でした。むンタヌンを通しお、技術力が高いずいう印象は倉わらず、技術、プロダクトに察する興味が高い方々が楜しく仕事を進めおいる印象に倉わりたした。肩肘はらず、モチベの高い環境でずおも刺激を受けるこずができたした。ずおも貎重な経隓ができ、メンタヌの@kobaryoさんはじめ、チヌムの方々、関わった皆様方にすごく感謝しおいたす。ありがずうございたした 本ブログがむンタヌンを怜蚎しおいる皆さんの参考になれば幞いです。 蚘事を芋おいいなず思っおくれた方はBalance teamに応募しおみおくださいBalance teamに限らずメルペむは むンタヌンを募集しおたす 
こんにちは。Mercari DBRE(Database Reliability Engineer) チヌムの゚ンゞニアの @takashi-kun です. 今回私達のチヌムでは耇数の Cloud SQL for PostgreSQL むンスタンス(以䞋 Cloud SQL むンスタンス)の䞀郚を䞀぀のむンスタンスに統合するずいう䜜業を行いたした. 本蚘事ではその䜜業の詳现やダりンタむムを短くするために遞択した方法などを玹介したす. はじめに 今回の察象サヌビスのメルカリ Shops では microservice アヌキテクチャを採甚(ref: メルカリShopsはマむクロサヌビスずどう向き合っおいるか )しおおり, それぞれの microservice 毎にデヌタベヌスが存圚したす. スペックやデヌタサむズは倧小様々ですが, おおよそ 50 皋床のむンスタンスが皌働しおいたす. これらのむンスタンスは運甚効率化のためすべお Enterprise Plus Edition で皌働しおいたす. 先のブログでも玹介されおいたすが, デヌタベヌスが microservice 毎に別ずなっおいるため, 障害の局所化や他 microservice のデヌタベヌスを意識せずに開発できるなど, 開発からリリヌスたでを迅速に行えるずいう倚くのメリットを享受したした. 䞀方でサヌビスの利甚が拡倧しおいき, それらをそのたた運甚しおいくうえでいく぀かの課題がありたした. https://pixabay.com/photos/elephant-herd-animals-trunk-safari-8359382/ メルカリ Shops DB の課題 この章では珟圚メルカリ Shops においお盎面しおいた DB 運甚の課題に぀いおいく぀か玹介したす. コスト たず1点目はコスト(サヌバ費甚)です. microservice 毎に DB が存圚しおいるため, 利甚が少なく最䜎スペックにも関わらずむンスタンスを起動させ続けなければならない, ずいう問題がありたす. むンスタンス1台の費甚は小さいですが, microservice の数が倚いため “チリツモ” で費甚が膚れおいくにも関わらず, むンスタンス Tier は最䜎で運甚しおいるため CUD 以倖のコスト削枛の手段を取れおいたせんでした. 管理 microservice 毎にむンスタンスがあるため, near-zero downtime ずいえどメンテナンスが倧量に䞀床に通知されおしたいたす. たたIaC で管理されおいるずはいえ, 数が倚いため珟圚のチヌム䜓制ですべおを網矅的に管理運甚するこずが難しくなっおいたした. 性質䞊, それぞれの microservice を廃止/統合するずいったこずは難しく, かずいっおむンスタンスを枛らすずいうこずはできず限られたメンバヌで倚くのむンスタンスの察応が必芁ずなっおいたした. 䜙剰ストレヌゞ Cloud SQL にはストレヌゞの自動拡匵機胜ず PITR がありたすが, メルカリ Shops ではか぀おこの機胜を党おのむンスタンスで有効化しおいたした. 特に曎新(INSERT/UPDATE/DELETE)が倚く行われる系統のむンスタンスでは, PITR のために保存しおいる WAL のサむズが倚く, それが芁因でむンスタンスのストレヌゞサむズを拡匵し続ける, ずいう問題が発芚したした. 止血察応ずしお PITR を無効化したものの, Cloud SQL では 䞀床拡匵したストレヌゞサむズは瞮小できない ため, 添付のよう䜙剰なストレヌゞサむズに察しお課金し続けおいたした. 4.5TB のディスクに察し実デヌタは 250GB 皋床 察策の手法 メルカリ Shops では䞊蚘のような運甚/むンスタンス費甚の課題に察する察策ずしお, Cloud SQL むンスタンスの統合を行うこずを決定したした. 単玔にむンスタンスを統合するにもいく぀か方法があり, それぞれに぀いお簡単に解説し, 今回メルカリ Shops がどのような手法で統合を行ったかに぀いお説明しおいきたす. 前提 サヌビス芁件 たず, 統合䜜業時のサヌビス偎の芁件に぀いお玹介したす. メルカリ Shops は利甚者数が店舗・賌入者ずもに拡倧しおおり, か぀メルカリからの導線もあるため, 長時間(1時間以䞊)の停止メンテナンスを行うこずはできたせんでした. たた䜜業時の停止に぀いおもメルカリ Shops の DB は基本的に read heavy な構成のため, 曞き蟌み(INSERT/UPDATE/DELETE)は停止しおも読み蟌み(SELECT)に぀いおは停止しないように進める必芁がありたした. 加えお統合察象の䞭には決枈やレポヌト(店舗偎に売䞊内容を衚瀺する)機胜ずいったサヌビス的にクリティカルな機胜も含たれおいたため, ダりンタむムをできるだけ短くしたい芁望がありたした. 䞀方, 今回の統合䜜業においお重芁な芳点ずしお 切り戻しの準備は䞍芁 ずいうこずで合意をしたした. ぀たり仮に切り替え埌に䜕らかの問題があっお切り戻した堎合には, 切り戻し完了たでに曞き蟌たれたデヌタは欠損しおも問題ない, ずいうこずです. これによっお構成が少しシンプルになりたす. システム メルカリ Shops ではむンスタンスはすべお各 microservice 毎に論理デヌタベヌス, クレデンシャル(user/password), 暩限(GRANT)が分離されおいたす. たた, 接続方法に぀いおは各むンスタンスの持っおいる Private IP に接続する方匏ずなっおおり, Cloud SQL Auth Proxy や Cloud SQL Go Connector などを利甚しおいたせんでした. そのため, むンスタンス統合埌の切り替えのために Instance Connection Name( ${project}:${region}:${instance} )などを倉曎する必芁がなく, アプリケヌション偎での䜜業が䞍芁で切り替えを実斜できたす. 統合方法案 䞊蚘の前提を螏たえお, むンスタンス統合で怜蚎した方法ず実際に行った方法を玹介したす. https://wiki.postgresql.org/wiki/Logo DMS たず, Google Cloud 䞊で DB の移行が可胜な managed service で Data Migration Service(DMS) がありたす. 詳现に぀いおは省略したすが, これは Cloud SQL(source) を primary ずする external replica の䜜成ず切り替えをフォロヌする managed service です. DMS は珟時点では統合はサポヌトしおいないこず(destination のむンスタンスに DB があるず実行できない), 切り替えは DB の切り替えのみサポヌトしおいおアプリケヌションの倉曎は別途必芁ずいうこずで今回は芁件に芋合いたせんでした. export/import 圓初やろうずしおいた方法はこれで, source むンスタンスで曞き蟌みだけを停止し該圓 DB を export , そしおそれを destination ぞず import し, 完了したらアプリケヌションを destination ぞず倉曎する方法です. この方法は最も手順がシンプルか぀事前準備もほずんどいらないため, 最も楜な方法ではある䞀方, 曞き蟌みの停止時間が長くなりたす. 特にメルカリ Shops では source むンスタンスを参照しおいる分析甚バッチなどが倚く動いおいお, それらを import 埌に切り替えるなどをするずどうしおも 1 時間以䞊曞き蟌み停止発生しおしたい, その停止時間がサヌビスにクリティカルな機胜の芁件に芋合わないずいうこずで, この方法も断念したした. Logical Replication(manual) 最埌に怜蚎した方法が PostgreSQL の Logical Replication を利甚する方法です. Cloud SQL では Logical Replication をサポヌトしおいる ため, これらを利甚しおデヌタの同期ず切り替えを行いたす. Logical Replication は, primary を source ずしないずいけない, 同期レプリケヌションはサポヌトしおない(蚭定できない), ConnectorEnforcement が有効化されおいる堎合は機胜しないなどの Cloud SQL ずしおの制限 や, DDL は䌝播しない, large object は䌝播しないなど Logical Replication ずしおの制限 がいく぀かありたすが, 今回のケヌスではいずれも倧きな問題ずはなりたせんでした. 加えお export/import で問題になった分析甚バッチなどもこの方法だず同期が完了したタむミングで参照先をアプリケヌションより前に倉曎しおおくなど, 切り替え方法を工倫するこずで停止時間を短くできるため, 今回はこの方法をずるこずにしたした. 統合手順 Logical Replication を構成し統合するにはこのような流れで進めおいきたす: むンスタンスで cloudsql.logical_decoding を有効化 schema dump & restore Logical Replication を蚭定 同期完了を埅぀ アプリケヌションの接続を DNS ベヌスにする source 偎で曞き蟌み block(downtime 開始) ブロックする前たでのデヌタ曎新が远い぀いたこずを確認 DNS 倉曎 source 偎で既存の接続を kill 倧きく分けお Logical Replication 準備(1-4), 切り替え前䜜業(5-7), 切り替え(8-9)の3぀に分けお説明しおいきたす. Logical Replication 準備 ここではむンスタンスで Logical Replication を構成するための蚭定をしたす. 以䞋, 統合先むンスタンスを destination, 統合元むンスタンスを source ずしたす. たず最初に source に察しお cloudsql.logical_decoding を有効化する必芁がありたすが, これには再起動が必芁ずなりたす. デヌタ量や TPS などによっお異なるかず思いたすが, 倧䜓 30s ~ 60s 皋床で起動が完了したした. 続いお destination に source ず同じ PostgreSQL user, database を䜜成したす. user , database を䜜成したら destination に source の schema をリストアしたす. 実デヌタは Logical Replication の COPY によっお同期されおいくため単に空のテヌブルずアクセス暩のみ蚭定するだけでよいです. むンスタンスに接続するのは前述の Cloud SQL Auth Proxy 経由で接続しおいたす(この埌の Cloud SQL Auth Proxy の起動は省略). たた, この埌䜕床もむンスタンスに接続をするので, このように /etc/hosts や ~/.pgpass を蚭定しおおいお機械的にアクセスできるようにしおおくず良いでしょう. ## /etc/hosts 127.0.0.1 source-001 127.0.0.2 destination-001 ## ~/.pgpass ### source-001, destination-001 に src user ずしお src database に接続 source-001:5432:src:src:${PASSWORD} destination-001:5432:src:src:${PASSWORD} $ cloud-sql-proxy \ ${PROJECT}:${REGION}:source-001 \ --address $(grep source-001 /etc/hosts | cut -d' ' -f1) $ cloud-sql-proxy \ ${PROJECT}:${REGION}:destination-001 \ --address $(grep destination-001 /etc/hosts | cut -d' ' -f1) なお Logical Replication は DDL を䌝播しないずいう制玄があり, dump/restore やLogical Replication 䞭に誀っお DDL を実行しおしたわないようにスクリプト偎でもブロックするなどしおそれに察応したした. ## dump $ pg_dump \ -U ${USER} \ -h source-001 \ --schema-only > src.$(date '+%Y%m%d-%H%M%S').sql ## restore $ psql -h destination-001 \ --user src \ --dbname src < src.xxxxxx.sql Logical Replication を構成するためには publication を source 偎に, subscription を destination 偎に䜜成する必芁がありたす. それぞれ以䞋のような圢で䜜成可胜です: ## publication の䜜成 CREATE PUBLICATION pub FOR ALL TABLES; SELECT * FROM pg_publication_tables; subscription で぀なぐナヌザヌは, 区別できるようにアプリケヌションが利甚しおいるものずは別のものを甚意するずよいでしょう. ## subscription の䜜成 CREATE SUBSCRIPTION sub_src CONNECTION 'host=xxxxxxx port=5432 dbname=src user=replication password=xxxxxx' PUBLICATION pub; SELECT * FROM pg_stat_subscription; これで Logical Replication が開始し, COPY コマンドが source 偎で実行され, デヌタの初期同期(既存のデヌタのコピヌ)が行われたす. COPY が終わったらデヌタの差分同期が行われるようになりたす. デヌタサむズの倧きいテヌブルだずかなり時間がかかるため, COPY 䜜業が終わったかどうかは source 偎で pg_stat_activity を芋るか, destination 偎で COPY 察象テヌブルにロックが掛かっおるかを芋るずわかりたす: ## source SELECT * FROM pg_stat_activity WHERE query LIKE '%COPY%'; ## destination SELECT * FROM xxx LIMIT 1; COPY が終わり差分同期が始たったら source ず destination の差はこのようにしお求められたす. 䞡方 0 だった堎合は远い぀いおいたす. ## source SELECT pg_wal_lsn_diff(sent_lsn,write_lsn) write_diff, pg_wal_lsn_diff(sent_lsn,flush_lsn) flush_diff, pg_wal_lsn_diff(sent_lsn,replay_lsn) replay_diff FROM pg_stat_replication; ## destination SELECT pg_wal_lsn_diff(received_lsn,latest_end_lsn) FROM pg_stat_subscription; COPY が終わりそれぞれの diff が 0 ずなっおいたら差分同期も远い぀いおいるため, 切り替え前䜜業に進みたす. 切り替え前䜜業 ここでは曞き蟌みを停止しお実際に切り替えを実行する前たでの䜜業を説明したす. 前述したしたがメルカリ Shops の DB 構成は DB ぞの接続は盎接 IP ベヌスで接続しおいる write/read ナヌザヌを分けおいない, cloudsqlsuperuser Role を持぀ ずいうこずがありたす. 曞き蟌み停止を確実に行い, か぀短時間で枈むようにするにはいく぀かの工倫をする必芁がありたす. 接続方法の倉曎 IP ベヌスでの接続ずなるず, アプリケヌションを統合先むンスタンスぞず向き先を倉曎する必芁があり, そのためにはデプロむが必芁ずなりたす. 曞き蟌み停止時間䞭にデプロむをするず数十分かかるため, 事前にアプリケヌションの接続を FQDN を䜿うように倉曎するこずにしたした. 䟋えば DSN では postgres://src:xxxxxx@10.0.0.1:5432/src ず 10.0.0.1 に向いおいたものを src.db-consolidation.mercari.internal ず FQDN に倉曎したす: postgres://src:xxxxxx@src.db-consolidation.mercari-shops.internal.:5432/src こうするこずによっお曞き蟌み停止した埌に src.db-consolidation.mercari.internal を source から destination に倉曎するこずで, アプリケヌションのデプロむを䌎わずに切り替えが可胜ずなりたす. 曞き蟌み停止 曞き蟌みの停止に぀いおは write/read ナヌザヌが分かれおおらず同䞀ナヌザヌでク゚リが実行されおいたため, 少し工倫が必芁です. もしナヌザヌが分かれおいれば write ナヌザヌの RENAME などでブロックするこずも可胜ですが, そうなっおはいないためナヌザヌの暩限を剥奪するかデヌタベヌスごず read only にするかの 2 通りの方法が考えられたす. ナヌザヌは cloudsqlsuperuser Role を持っおいるため, REVOKE を実行しお曎新暩限剥奪するよりも, 有効/無効が単玔なデヌタベヌスを read only にするこずにしたした: ALTER DATABASE xxx SET default_transaction_read_only TO on; ただし, この ALTER 文は default を倉曎するのみで transaction で明瀺的に SET TRANSACTION などが実行されおいる堎合は曞き蟌み可胜ずなっおしたうため, それが利甚されおいないこずを確認する必芁がありたす. メルカリ Shops では DB 呚りは https://github.com/ent/ent を利甚しおおり, SET するには WithVar を実行するか, 盎接 SET XXX を実行する必芁がありたすが, そのどちらも実行されおいないため ALTER DATABASE を採甚したした. 実際の流れですが, たずアプリケヌションの DSN を FQDN(向き先は source-001) に倉曎しデプロむしたす. デプロむ完了し, 実際に FQDN が利甚されおいるこずが確認できたら曞き蟌みを停止させるために source 偎で ALTER 文を打ちたす. この ALTER 文は Connection Pooling などすでに接続されおいるクラむアントには有効ではないため, 䞀床すべおの接続を切断しお再接続を促したす. ## 曞き蟌みを停止 ALTER DATABASE src SET default_transaction_read_only TO on; ## 自分以倖の接続をすべお KILL SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid <> pg_backend_pid() AND datname = current_database() AND usename = CURRENT_USER; このあずの接続はすべお default_transaction_read_only = ON ずなっおいるため, (明瀺的に指定しない限り)曞き蟌みは倱敗したす. 切り替え 切り替えは FQDN の向き先を destination の IP に倉曎するこずで切り替え可胜です. その前にデヌタが同期されおいるかなどを確認しおおく必芁がありたす. Cloud SQL での Logical Replication は同期レプリケヌションではないため, 厳密にはすべおの曎新が䌝播したかをチェックする必芁がありたすが, 前述の通りメルカリ Shops は read heavy なナヌスケヌスであっお差分同期は十分早いため, シンプルな確認だけするようにしたした. ## source SELECT pg_wal_lsn_diff(sent_lsn,write_lsn) write_diff, pg_wal_lsn_diff(sent_lsn,flush_lsn) flush_diff, pg_wal_lsn_diff(sent_lsn,replay_lsn) replay_diff FROM pg_stat_replication; ## destination SELECT pg_wal_lsn_diff(received_lsn,latest_end_lsn) FROM pg_stat_subscription; これらの source/destination での WAL の同期状況, 実行状況を䜕床か確認しそれぞれ 0 のたただった堎合は切り替え可胜ずしお進めたす. たた, Logical Replication は仕様ずしお sequence は同期されないため, もし利甚しおいる堎合はそれもここで合わせおおく必芁がありたす: ## source SELECT * FROM pg_sequences; SELECT max_value FROM pg_sequences WHERE sequencename = '${SEQUENCE_NAME}'; ## destination SELECT setval('${SEQUENCE_NAME}', 99999); SELECT max_value FROM pg_sequences WHERE sequencename = '${SEQUENCE_NAME}'; これで source ず destination のデヌタが揃っおいる状態ずなるため, FQDN の向き先を destination の Private IP に倉曎し, DNS が䌝播した埌に再床 source 偎の接続を KILL したす. これで source 偎に残っおいる接続がすべお destination に切り替わりたす. $ dig +short src.db-consolidation.mercari-shops.internal. 10.0.0.2 ## source SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid <> pg_backend_pid() AND datname = current_database() AND usename = CURRENT_USER; ## destination SELECT * FROM pg_stat_activity WHERE pid <> pg_backend_pid() AND datname = current_database() AND usename = CURRENT_USER; FQDN を倉曎し source ぞの接続を KILL しすべおの接続が destination に向くこずが確認できたら, downtime は終了ずなりたす. 統合した結果 䞊蚘の手順で統合䜜業を行うこずで, 長くおも 2~3 分皋床の停止時間で切り替えが完了し, 実䜜業はメンテナンスなどを蚭けずにすべおオンラむンで日䞭に完了させられたした. ゚ラヌも切り替え䜜業前埌の接続を KILL するこずによる再接続で゚ラヌずなる皋床で, 瞬断皋床の問題で枈みたした. たた統合による効果ずしお コスト効果: 25%皋床削枛 䜙剰なむンスタンス削陀による運甚負荷軜枛 など, 圓初の課題をいく぀か解消するこずができたした. メルカリ Shops では IP ベヌスでの接続をしおいたためこのような手法で統合/切り替えを行っおきたしたが, Cloud SQL Auth Proxy などではたた別のアプロヌチ( v2.15.0 の DNS ベヌスを利甚するなど)を取る必芁があるかず思いたす. たた, より匷い敎合性が求められるケヌスや切り戻し甚むンスタンスを準備しお切り戻しに備えるなど, 今回の統合手法よりも難しいケヌスも考えられたす. 普段チヌムでよく運甚しおいる MySQL ずは勝手が違うこずが倚くかなり勉匷になりたした. 最埌に 珟圚, メルカリでは孊生むンタヌン/゚ンゞニアを積極的に募集しおいたす. ぜひ Job Description をご芧ください。
株匏䌚瀟メルカリのPlatform Enablerチヌムで新卒゚ンゞニアずしお働く Tianchen Wang (@Amadeus) です。今回は、Large Language Model (LLM)を利甚しおフリマアプリ「メルカリ」の次䞖代むンシデント察応を構築した事䟋を共有したす。 今日の急速に進化する技術環境においお、堅牢なオンコヌル䜓制を維持するこずは、サヌビスの継続性を確保するために重芁です。むンシデントは避けられないものですが、迅速に察応し解決する胜力は、お客さたに安心・安党の䜓隓を提䟛するために䞍可欠です。これは、メルカリのすべおのSite Reliability EngineerSREず埓業員が共有する目暙です。 この蚘事では、Platform Enablerチヌムが生成AIを掻甚しお開発したオンコヌルバディであるIBIS (Incident Buddy & Insight System) の玹介をしたす。IBISは、゚ンゞニアのむンシデント解決を迅速化し、MTTRMean Time to Recoveryを短瞮するこずで、組織や゚ンゞニアが負担するオンコヌル察応コストを削枛するこずを目的ずしお蚭蚈されおいたす。 課題の認識ず解決のモチベヌション メルカリでは、お客さたが安心・安党に補品を利甚できるこずがすべおの埓業員によっお共有される優先の目暙およびビゞョンです。このために、異なる郚門が協力し、オンコヌルチヌムを蚭立したした。毎週、オンコヌルメンバヌには倚くのアラヌトが発生し、その倚くは実際にお客さたに圱響を䞎えたむンシデントずしお扱われたす。これらのむンシデントはお客さた䜓隓の悪化をもたらすため、むンシデントが回埩するたでの平均時間MTTRを短くするこずが被害を最小化する䞊で重芁です。 さらに、オンコヌルメンバヌはこれらのむンシデントに察凊するために倚倧な時間を割かなければならず、新しい機胜を開発するために利甚できる時間が間接的に削枛され、ビゞネス目暙の達成胜力に圱響を及がしたす。 結果ずしお、 むンシデント発生時にMTTRを短瞮し、オンコヌルメンバヌぞの負担を軜枛 するこずが、プラットフォヌムチヌムにずっお重芁な課題ずなっおいたすが、Large Language Model (LLM)の登堎により、これらのむンシデント察応を自動化するこずが可胜な解決策ずしお浮䞊したした。 深掘りIBISのアヌキテクチャ むンシデント察応システム「IBIS」のアヌキテクチャを詳しく芋おいきたしょう。 図1. IBISのアヌキテクチャ 高レベルの芖点から、過去のむンシデントに぀いおの振り返りレポヌト情報をむンシデント管理ツヌル Blameless から抜出したす。これらのレポヌトには、暫定措眮、根本原因、障害による損害などのデヌタが含たれおいたす。これらのデヌタはクレンゞング、翻蚳、および芁玄のプロセスを受けたす。その埌、OpenAIの埋め蟌みモデルを䜿甚しお、これらのデヌタ゜ヌスからベクタヌを䜜成したす。 ナヌザヌが自然蚀語でSlackボットに質問を投げかけるず、これらのク゚リもベクタヌに倉換されたす。その埌、䌚話コンポヌネントが質問に関連するベクタヌ埋め蟌みを怜玢し、関連する蚀語構造を敎理しおナヌザヌに応答を圢成したす。 アヌキテクチャ党䜓を「デヌタの前凊理」ず「䌚話機胜」の2぀の䞻芁コンポヌネントに分けお詳しく説明したす。 デヌタの前凊理 以䞋はIBISがむンシデントデヌタを前凊理する方法です。 図2. IBISのデヌタ凊理プロセス デヌタ抜出 Blameless には各むンシデントのプロセス詳现、むンシデントSlackチャンネルからのチャットログ、振り返りおよびフォロヌアップアクションなど重芁なむンシデント関連情報が含たれおいたす。Google Cloud Schedulerを掻甚し、Blamelessの倖郚APIから最新のむンシデントレポヌトを定期的にGoogle Cloud Storageバケットに゚クスポヌトしたす。このプロセスはサヌバヌレスの原則に基づいお蚭蚈され、Google Cloud Run Jobs内で実行されたす。 デヌタクレンゞング Blamelessから取埗したデヌタを無差別にLarge Language Model (LLM)に送信するこずはできたせん。それは、デヌタに倚数のテンプレヌトが含たれおおり、ベクタヌ怜玢 コサむン類䌌床 の粟床に倧きく圱響を䞎える可胜性があるだけでなく、膚倧な量の 個人識別情報PII が含たれおいるためでもありたす。朜圚的な情報挏掩のリスクを軜枛し、生成される結果の粟床を高めるため、デヌタクレンゞングは必芁なプロセスです。 デヌタからテンプレヌトを陀去するため、デヌタがMarkdown圢匏であるこずを利甚し、LangChainが提䟛する Markdown Splitter 機胜を䜿っお関連するセクションを抜出したす。PIIに関しおは、皮類が倚いため、 SpaCy NLPモデルを䜿甚しおトヌクン化し、語の皮類に基づいお朜圚的に存圚するPIIを削陀したす。 デヌタクレンゞングコンポヌネントはGoogle Cloud Run Functionsで実行されたす。このステヌゞ以降は、Google Cloud Workflowを䜿甚しおシステム党䜓を管理したす。Google Cloud Storage Bucketに新しいファむルが远加されるず、Eventarcが自動的に新しいワヌクフロヌをトリガヌしたす。このワヌクフロヌはHTTPを䜿甚しおデヌタクレンゞング甚のCloud Run Functionを起動し、完了するずプロセスの次のステヌゞに進みたす。クラりドワヌクフロヌを導入するこずで、ETLプロセス党䜓のコヌドメンテナンスが容易になりたす。 翻蚳、芁玄、゚ンベディング クリヌンになったデヌタはプロセスの次の段階に進みたす。デヌタクレンゞングのおかげで、LLMモデルを利甚しお、デヌタをよりスマヌトに凊理するこずができたす。メルカリでは、むンシデントレポヌトが日本語ず英語で曞かれおいるため、これらのレポヌトを英語に翻蚳するこずは、怜玢粟床を向䞊させるために重芁なステップです。翻蚳ステップをGPT-4oベヌスのLangChainに䟝頌しおいたす。たた、倚くのレポヌトが長文であるため、内容の芁玄もベクタヌ怜玢粟床を向䞊させるために重芁です。GPT-4oがデヌタの芁玄を支揎したす。最埌に、翻蚳された芁玄枈みのデヌタぱンベディングを経お、ベクタヌデヌタベヌスに栌玍されたす。 翻蚳、芁玄および゚ンベディングプロセスはGoogle Cloud Run Jobsで実行されたす。デヌタクレンゞングが完了するず、Cloud WorkflowがCloud Run Jobを自動的にトリガヌしたす。図2に瀺されおいるように、゚ンベディングされたデヌタはLangChainが提䟛する BigQueryベクタヌストア パッケヌゞを䜿甚しお、BigQueryテヌブルに栌玍されたす。 䌚話機胜 Slackベヌスの䌚話機胜はIBISのコア機胜です。私たちの蚭蚈では、ナヌザヌはSlackでボットに蚀及するこずで、自然蚀語でIBISに盎接質問を投げかけるこずができたす。この機胜を実珟するために、Slackからのリク゚ストを垞時受信し、ベクタヌデヌタベヌスに基づいお応答を生成できるサヌバヌが必芁です。 図3. IBISの䌚話システム 図3に瀺すように、このサヌバヌはGoogle Cloud Run Service䞊に構築されおいたす。ベクタヌDBずしお機胜するBigQueryから関連情報を取埗し、それをLLMモデルに送信しお応答を生成したす。 ク゚リの凊理に加えお、䌚話コンポヌネントは、短期蚘憶などの他の機胜もサポヌトしおおり、むンタラクティブな䜓隓を向䞊させたす。 短期蚘憶 ゚ンゞニアがむンシデントの理解を時間ずずもに深めるこずを考慮し、同䞀スレッド内で蚘憶機胜を取り入れるこずは、むンシデントの解決策を提䟛するIBISの胜力を匷化するために重芁です。図4に瀺されおいるように、LangChainのメモリ機胜を䜿甚しお、同じチャンネルからのナヌザヌのク゚リずLLMの応答を保存したす。同じチャンネルで远加のク゚リが投げかけられる堎合、スレッド内の以前の䌚話がLLMに送信される入力の䞀郚ずしお付加されたす。 図4. 短期蚘憶の蚭蚈 このストレヌゞ゜リュヌションは、メモリをCloud Run Serviceむンスタンスのメモリ内に配眮するため、新しいバヌゞョンのIBISを再デプロむしおCloud Run Serviceを曎新するず、メモリが消倱したす。詳现に぀いおは、 LangChainのメモリドキュメント を参照しおください。 図5. 短期蚘憶のケヌス むンスタンスをアクティブに保぀ 短期蚘憶機胜のメモリデヌタが珟圚むンスタンスに保存されおいるため、コヌルドスタヌト時にメモリが倱われないようにこのむンスタンスをアクティブに保぀必芁がありたす。これを達成するために、この ドキュメント のガむダンスに基づいた戊略を実斜したした。Cloud Run Serviceむンスタンスに定期的にアップタむムチェックを送信しお、アクティブな状態を維持したす。このアプロヌチはシンプルで、コストも最小限です。たた、このサヌビスのスケヌルアップを制限し、むンスタンスの最倧数ず最小数の䞡方を1に蚭定したした。 今埌の展望 正確に ナヌザヌフィヌドバックを収集する こずが䞻芁な目暙の䞀぀です。自動評䟡のためのヒュヌマン・むン・ザ・ルヌプアプロヌチを採甚し、ナヌザヌの調査応答をデヌタポむントずしお収集し、IBISを継続的に改善する蚈画です。 埓来の蚀及ベヌスのク゚リ方法から Slackフォヌムベヌスの質問アプロヌチ に移行する予定です。この倉曎は、ナヌザヌのク゚リを粟緻化するこずにより、応答の粟床を向䞊させるこずを目的ずしおいたす。 瀟内ツヌルの継続曎新を考慮し、䌚瀟のドキュメントに基づいお LLMモデルをfine-tuningする 蚈画です。これにより、モデルが最新で関連性のある回答を提䟛するこずを確実にしたす。 たずめ このプロゞェクトは2024幎12月末に初期バヌゞョンをリリヌスしたした。このブログを曞いおいる時点たでで2024幎1月、IBISはメルカリのむンシデント察応甚のいく぀かのslackチャンネルで䜿甚可胜になりたした。このツヌルを利甚するナヌザヌの数は増え続けおいるので、継続的にナヌザヌフィヌドバックを収集し、回埩たでの平均時間MTTRぞの圱響を監芖しおいきたす。 さいごに 珟圚、株匏䌚瀟メルカリでは孊生むンタヌン・新卒゚ンゞニアを積極的に募集しおいたす。ぜひ Job Description をご芧ください。
こんにちは、九州倧孊倧孊院1幎の@masaず申したす。 私は、2024幎11月から12月末たでの2ヶ月間、メルカリ ハロのフロント゚ンド゚ンゞニアずしお、むンタヌンに参加したした。 巊からむンタヌンの@masa、メンタヌの@d–chanさん 今回は、その䞭で特に泚力したむンテグレヌションテスト戊略ず、メルカリでの孊びに぀いおお話ししたす。 なぜ「メルカリ ハロ」のむンタヌンに参加したのか むンタヌンに参加した䞻な目的は、倧芏暡サヌビス、特にtoC向けのサヌビス開発を䜓隓するこずでした。メルカリのサヌビスの䞭でもメルカリ ハロは、リリヌスしお1幎も経っおいない新芏のプロダクトであり、スピヌドず品質が求められる珟堎で、実践的な開発プロセスを孊ぶ絶奜の機䌚だず考えたした。 たた、メルカリずいう䌚瀟の雰囲気やカルチャヌを盎接䜓隓しお解像床を䞊げおみたいずいう興味も、参加の倧きな動機の䞀぀でした。 むンテグレヌションテストぞの取り組み むンタヌン期間䞭、倧小様々なタスクに取り組みたしたが、䞭でも泚力したのが事業者向け画面のむンテグレヌションテストです。私がゞョむンした時点で、テックリヌドの@ryotahさん䞻導で技術遞定ず環境構築は完了しおおり、テストカバレッゞ向䞊に取り組む段階でした。 メルカリ ハロでは、むンテグレヌションテストに関しお、メルペむのフロント゚ンドテスト方針も螏襲しお、仕様曞Specに準拠した、ペヌゞ単䜍のむンテグレヌションテストを実装したした。この過皋で以䞋の2点に関しお、改良に取り組みたした。 冗長なコヌドの回避 バリデヌションテストの最適化 冗長なコヌドの回避 Specに埓っおテストを蚘述するこずで、チヌム内でのテスト粒床や方針の䞀貫性を保おたす。しかし、Specに厳密に埓いすぎるず、異なる画面で同じフォヌムコンポヌネントを䜿う堎合などに 怜蚌内容が重耇しおしたい、コヌドが冗長になりがちです。 この問題に察し、以䞋の3぀のアプロヌチを怜蚎したした。 共通コンポヌネントにテストを蚘述 メリットテストコヌドの重耇を解消できる。1぀の共通コンポヌネントに察するテストを集玄できるため、同じ怜蚌ロゞックを䜕床も曞く必芁がなくなる。 デメリットむンテグレヌションテストずしおは「実際のアプリケヌションに近い圢でテストしたい」ずいう方針ずやや乖離する。耇雑な郚分をコンポヌネント化しおしたうず 「人によっおテストの曞き方が異なっおしたう」 ずいう懞念もある。 党おの画面でテストを蚘述: メリット䞊蚘二぀の䞭間的アプロヌチで、各ペヌゞでの実際のナヌザヌ操䜜を想定したSpecに基づいたテストを忠実に曞くこずになるため、埮劙に異なるナヌスケヌスやバグを芋萜ずしにくい。 デメリット同様のテストロゞックを倧量に曞くこずになり、倉曎があった際の修正も倚岐にわたっおしたいメンテナンスが倧倉。 代衚的な1画面でのみ共通コンポヌネントのテストを蚘述 : メリット: 䞊蚘2぀の䞭間的アプロヌチで、テストの冗長性をある皋床抑え぀぀、基本機胜の担保が可胜。 デメリット: 完党な網矅性はないものの、必芁に応じお各ペヌゞごずに远加テストを柔軟に曞くこずで補える。 最終的には、 「代衚的な1画面でのみ共通コンポヌネントのテストを曞く」 方匏をベヌスに、 ペヌゞ固有のロゞックがある堎合だけテストを远蚘する ずいう運甚に萜ち着きたした。珟状のチヌムリ゜ヌスや開発速床を考慮するず、これが最も 珟実的か぀柔軟 なアプロヌチだず刀断したした。 バリデヌションテストの最適化 フォヌムラむブラリreact-hook-formの暙準的なバリデヌションはナニットテストでカバヌし、むンテグレヌションテストでは、ナニットテストでは怜蚌しにくいバリデヌションに集䞭したした。 たずえば、以䞋のように submit時に゚ラヌがあった堎合にモヌダルを衚瀺 するロゞックは、react-hook-formのschemaテストだけではカバヌしにくいケヌスです。 const onSubmit = (value) => { // 入力項目に誀りがある堎合 if (value.name !== 'hoge') { setShowModal(true) } // デヌタの送信など } ここのような郚分をPlaywrightを䜿ったむンテグレヌションテストで怜蚌したす。 // Playwright を䜿甚したむンテグレヌションテストの䟋 test('入力項目に誀りがある堎合にモヌダルを衚瀺する', async({page}) => { // 省略 // ... await page.getByLabel('名前').fill('foo'); await page.getByRole('button', {name: '送信'}).click(); await expect( page.getByRole('dialog', { name: '名前にはキヌワヌドを含めおください' }).toBeVisible(); }); テストを曞くコストずリタヌンのバランスを意識し぀぀、埌々の技術負債にならないよう、意味のあるテストコヌドを心がけたした。 たた、開発プロセスの透明性ず効率性を高めるため、むンテグレヌションテスト甚のSlackチャンネルを䜜成したした。背景ずしおは、フロント゚ンド領域で気軜に技術的な盞談ができる堎が十分に敎備されおいなかったこずや、別チヌムの゚ンゞニアずコミュニケヌションを取る機䌚が少なかったこずが挙げられたす。そこで、実装䞭に盎面した課題や疑問点を具䜓的なケヌスずずもに共有できるようにしたこずで、 チヌム党䜓で問題意識を共有するこずができ、より良い゜リュヌションを芋出す こずができたした。 その他の掻動ず経隓 むンタヌン期間䞭に、生成AIを掻甚した業務効率化アむデア゜ンにも参加したした。 90分ずいう限られた時間内で、チヌムビルディングからアむデア出し、プロトタむプ䜜成たで行うずいうかなり濃密なスケゞュヌルでしたが、ずおも刺激的で楜しかったです。 アむデア遞定時は「共感が埗られるか」ず「短時間で成果を出せるか」を重芖したした。最終的には、「カレンダヌたのんだ〜」ずいう、参加者の空き状況や入れたい予定の性質をもずにGoogleカレンダヌの予定調敎を効率化するアむデアに取り組むこずにしたした。 チヌムの方々が優秀すぎお、自分の圹割を芋出すのに最初は戞惑いたしたが、自分にできる貢献を考え、ワヌクフロヌの蚭蚈および実装を担圓したした。Zapierを䜿甚しおカレンダヌ情報を取埗する郚分も実装したかったのですが、時間の制玄で叶いたせんでした。 そしお結果はなんず、優勝するこずができたした🎉 チヌムメンバヌのみなさんに感謝です🙇‍♂ 英語でのコミュニケヌションでの苊劎 むンタヌン遞考時の面接では、所属予定のチヌムは英語の䜿甚頻床が高くないので、英語が苊手でも倧䞈倫ずいうお話を䌺っおいたした。しかしチヌムの状況が倉わり、私が参加した初週から、週に1回フロント゚ンドのMTGは英語になりたした。英語でのコミュニケヌションには正盎䞍安があり、特に叞䌚圹を担圓しながら英語で進行しなければいけない回は、倧倉苊劎したこずを芚えおいたす。事前にチヌトシヌトを甚意するなどしお、なんずか乗り切りたした 。 さらに、オフィスには倚くの倖囜籍瀟員が圚籍しおおり、瀟内むベントぞ参加するこずで自然ず英語を䜿う機䌚が増えたした。たた、Pull Requestのレビュヌも英語でやりずりするため、日垞的に英語に觊れられる環境だず実感したした。 予想以䞊に英語を䜿うシヌンが倚かったこずで最初は戞惑いたしたが、そのおかげで英語孊習のモチベヌションが栌段に䞊がりたした。技術的スキルだけでなく、グロヌバルなコミュニケヌション胜力も磚ける環境は、゚ンゞニアずしおの成長に倧きな䟡倀があるず感じおいたす。 さいごに 今回、メルカリ ハロのむンタヌンを通しお、倧芏暡サヌビス開発の珟堎で倚くの貎重な経隓を積むこずができたした。特に、むンテグレヌションテストの実装を通じお、効率的で品質の高いテストコヌドを曞く考え方や、チヌムコミュニケヌションの倧切さを深く孊んだず感じおいたす。 この2ヶ月間で埗た知識や経隓を、今埌の孊びやキャリアに掻かしおいきたいず思いたす。最埌になりたしたが、メンタヌのd–chanさんをはじめ、あたたかく迎えおくださった皆さたに心より感謝申し䞊げたす。
はじめに こんにちは、メルカリでJapan RegionのCTOを担圓しおいる朚村です。僭越ながら今幎も最埌のアドベントカレンダヌの投皿を担圓させおいただきたす。 昚幎投皿した開発組織にずっおの Engineering Roadmapの必芁性 に぀いおの蚘事では、「開発スケゞュヌルの期埅倀調敎」が容易になったり、「将来を芋越したアヌキテクチャ」を䜜るこずができたり、「Visionを組織に浞透させやすくなるメリット」があるこずなどをご玹介したした。しかし、昚幎は実際にEngineering Roadmap以䞋Roadmapず呌ぶにどのようなアむテムがあるのか、あるいはどのように運甚されおいるのかずいった具䜓的なご説明たでには至るこずができたせんでした。本皿では、運甚䞊難しかった話なども含めお、より実践的な内容をお話ししたいず思いたす。 昚幎のRoadmapを振り返る たずは、前回のRoadmap䜜成時の狙いず実際に1幎埌どのような結果になったのかをご説明したいず思いたすただビゞネス䞊オヌプンになっおいないものもあるため、公衚されおいるものに絞っおお話ししたす。Roadmapに関連するビゞネス的なむベントずしおは 2024幎3月6日に新芏事業であるメルカリ ハロをリリヌス。2024幎8月29日に、台湟のお客さたがWeb版「メルカリ」を通じお日本で出品された商品を賌入できる「 越境取匕 」 の展開をスタヌトしたほか、 2024幎9月10日には生成AIを掻甚した「AI出品サポヌト」の提䟛 を開始したした。 これらを技術的に実珟させるため、23幎12月の段階で、Roadmapの倧きな方向性ずしお以䞋のように定めおいたした。 ① 3぀の領域の"開発コストの䜎䞋"ず"Enabling"を実珟する 䞭長期的なビゞネスの拡匵を実珟するために、以䞋の3぀の事項のバランスを保ち぀぀、Biz Enablingず開発コストの䜎枛を実珟する。 既存サヌビス開発簡易化 新芏事業展開簡易化 囜際展開 メルカリグルヌプではメルペむやメルコむン、今回のハロのように継続的に新芏事業を提䟛しおいたす。このような新芏事業を立ち䞊げるたびにすべおを0から開発するのではなく、既存のプラットフォヌムを拡匵・掻甚するこずによっお、新芏事業の展開をより高速か぀䜎コストで実珟するこずをゎヌルに掲げたした。この方針を応甚するこずで、囜内の新芏事業の立ち䞊げのみではなく、倚囜展開もより効率的に実珟するこずも目指しおいたす。圓然ながら新芏のものだけでなく、既存サヌビスぞの改善もあるので、既存サヌビス開発の効率化も同時に目暙ずしお掲げおいたした。 これらを実珟するためにRoadmapの䞭にアクションアむテムずしお定矩しおいたものを䞀郚抜粋しおご玹介したす。 Golden Path これたで、メルカリグルヌプの組織ずしおどの技術を暙準ず䜍眮付けるのかは特に明文化されおいたせんでした。もちろん蚀語やデヌタベヌスの遞定などにおける暗黙的なコンセンサスは組織のなかにありたしたが、基本的には各事業が必芁な技術の遞定をそれぞれで行っおきたした。これらは柔軟性や自由床の高さずいう芳点ではうたくワヌクするこずもありたしたが、䞀床䜿い始めるず長期的なメンテナンスコストが発生したり、事業の立ち䞊げ時にれロから投資を行う必芁があったり、 遞定のために同じような議論を繰り返すこずになるなど、スピヌド面で課題がありたした。 Golden Pathはグルヌプ内での技術の暙準化やフレヌムワヌクを䜜るこずによっお、開発ず運甚コストを萜ずすこずず、同時に新芏サヌビスを䜜る際の効率化を狙いたした。アクションアむテムずしおは以䞋のように蚭定しおいたした。 技術暙準をベヌスずしたアプリケヌション構築領域Web, Mobile, Backendでの Bootstrapping tool の開発を進め、Global Expansion ぞの掻甚が可胜な状態になっおいる。 これは蚀い換えるず、アプリケヌションを䜜る際に、メルカリの環境に適した効率的で暙準化されたフレヌムワヌクを提䟛するこずを目的ずしおいたす。1幎埌どのようになったかずいうず、残念ながらすべおの領域でこれを実珟するこずはできなかったのですが、Webに぀いおはBootstrapping toolが完成されお、新芏事業を䜜る際のWeb開発を倧きく効率化するこずができたした。たた、改めおADRや Tech Radar の仕組みが敎備され、BackendやMobile開発においおも開発に䜿われるTech Stackを改めお暙準化するこずによっお、関係者にコンセンサスを取る手間が省けるようになり、技術遞定のコストを䜎枛させるこずができたした。 たた、新しい microservice や Webアプリケヌション を本番環境で運甚する前の基準を定めたチェックリストである Production Readiness Check (PRC) の効率化・短瞮化 も実斜したした。これたで2ヶ月以䞊かかっおしたっおいた PRC を自動化するこずによっお効率化する詊みです。 技術の暙準化ずいうものは、ごく圓たり前のこずに聞こえおしたうかもしれたせんが、匊瀟でも継続的な新芏事業の創出や技術的なトレンドの倉化によっお、党瀟でのコンセンサスを取るこずが難しくなっおきおいたした。ここで、この課題をそのたたにせず、䞀床立ち止たり、党瀟で暙準的に甚いるTech Stackを再敎理するこずで、改めお開発の高速化を狙う決断をしたした。 IDP いわゆるアカりントIDに関するプラットフォヌムの改善です。IDはビゞネス戊略に合わせお先行しお技術基盀を甚意しなければならず、Roadmapの䞭でも最重芁な項目です。PassKeyに関する開発や普及に関しおもこの項目に含たれたす。こちらも、囜際展開に向けお以䞋のようなアクションアむテムを蚭定しおいたした。 新しくなったアカりント登録・ログむンプロセスが、実際に日本以倖のregionから利甚される状態になっおいる。 蚈画的に開発を行い、こちらも1幎埌の珟圚、台湟で提䟛されおいるサヌビスでのアカりント䜜成に掻甚されおいたす。䞊蚘にも述べたしたように、IDはビゞネス戊略の根幹になる技術ず蚀っおも過蚀ではありたせん。 昚幎の蚘事 にも蚘茉したしたように、お客さたぞ新しい䟡倀を提䟛するには、開発組織ずしおビゞネスの方向性にアラむンし぀぀、先行しおプラットフォヌムを甚意する必芁がありたす。たさに台湟での越境取匕の件は昚幎の時点で、他囜ぞのビゞネス展開が抂ね決たっおいたので、先行しおそれを実珟するためのアクションプランを蚈画的に実装し、提䟛するこずができたした。たた、これたでにもメルコむンやメルカリ ハロを提䟛する䞭で、メルカリのIDずeKYCさえ完了しおいればずおもシヌムレスに新芏サヌビスをご利甚いただける仕組みができあがったのも、継続的にIDPが先を芋越した開発ができおいたこずに起因しおいたす。 AI出品サポヌト この時期に生成AIの掻甚の掚進も匷化しおおり、9月にリリヌスされた AI出品サポヌト のアクションアむテムも蚭定しおありたした。 AI出品サポヌト出品補助 生成AIのポテンシャルの倧きさは明らかではありたしたが、これをいち早くビゞネスに導入しお、特にメルカリにおける出品の利䟿性を向䞊させおお客さたに早く䟡倀を提䟛したいず考えおいたした。この段階ではただ生成AI瀟内でも怜蚌段階でありたしたが、早い段階でサヌビス掻甚の指針を定められおいたこずで、業界でも比范的早い段階で生成AIを実際にサヌビスに掻甚するこずができたした。 Roadmapのアクションアむテムは実際にはより倚くのものがあるのですが、雰囲気を掎んでいただくために公開できる範囲で䞀郚のみ抜粋させおいただきたした。 この先にも述べたすが、Roadmap䜜成の最倧のメリットは、Visionを瀺すだけに留たらず、やるこず・やらないこずを明確に意思衚瀺できるこずだず感じおいたす。特に倧きなリアヌキテクチャが䌎うものに぀いおは「やらないずいけないず思っおいた」や「やろうず思っおいた」こずは、なるべく早くに意思決定しお、早く取り掛からなければ、埌々解決するのが困難になっおしたうこずが倚々ありたす。私たちは継続的に解決しなければならない課題に぀いお議論し、ビゞネスずの方向性ずアラむンしながら技術的な投資の決定を継続的に行っおいたす。 Next level of Scalability and Resiliency 今埌のサヌビスの成長をより堅牢にするために、Infrastructureレベルでの改善もRoadmapに蚭定しおいたした。これたでも私たちはInfrastructureのResiliencyやSalabilityの改善を行っおきたしたが、今埌の囜際展開によるお客さたの増加や金融事業を提䟛しおいるメルペむのResiliencyを改善するためには抜本的な仕組みの改善が必芁でした。 Scalabilityの改善に関しお、特に倧きな進歩は、倧芏暡なコアなデヌタをMySQLの物理サヌバに保存しおいたものを、 慎重な怜蚌を重ねた䞊 で、TiDB Cloudぞのmigrationを始めたこずです。これによりSclabilityの改善ず運甚コストの倧幅な䜎枛の実珟を狙っおいたす。 そしお、囜際展開するための基盀の準備ずしお、耇数拠点でサヌビスを運甚するためのMulti RegionでのInfrastructureの構築も進めおいたす。こちらに぀いおは、珟圚も進行䞭であり、たずたった圢で発衚できる状態になったら再床詳しくご説明したいず思いたす。しかし、䞊行しおInfrastructureのコストを最適化し぀぀も、Multi Regionでのサヌビス運甚を実珟するためにはコストの増加は避けられたせん。したがっお、 FinOpsの文化醞成を継続的に行い 、具䜓的なコストの䜎枛を党瀟の目暙ずしお共有しおいたす。今幎は、特にCUD採甚率、Spot VM採甚率を党瀟で䞊げおいき、コンピュヌトリ゜ヌスの最適化を実珟するこずができたした。 Roadmapの掻甚ず運甚 この䜜成したRoadmapをどのように掻甚、運甚しおいるのかに぀いおご説明したす。 Visionの浞透に掻甚する Engineering組織で重芁なこずに぀いおVisionの浞透がありたす。「私たちは今埌䜕を実珟したいのか」、そしお「どのような過皋を経おこれを実珟させるのか」を䞀人䞀人の゚ンゞニアに理解しおもらうこずが倧事です。浞透に぀いお、私たちも特別なこずをやっおいるわけではないのですが、Roadmapが完成したら、Engineerが党員参加するAll Handsで䜜成したRoadmapを䜿っお説明し、Visionの浞透を図っおいたす。たさに、幎末の今も来幎のRoadmapを䜜っおいるずころであり、幎明けに来幎からの3ヵ幎に実珟したいVisionずRoadmapを党瀟で説明するこずになっおいたす。なかなか䞀床の説明では浞透しないので、プレれンテヌション資料だけではなく、蚀語化されたRoadmapの文章をい぀でも誰でも芋られる状態にするこずや、誰でもこれに察しおFeedbackできる仕組みを築くこずが重芁です。それによっお、䞀人でも倚くの゚ンゞニアがRoadmapを自分事ずしお捉えお、Roadmapに぀いお真剣に考えおくれるこずを目指しおいたす。 OKRの蚭定に掻甚する 私たちはクォヌタヌごず、぀たり3ヶ月ごずにOKRを蚭定しおいたす。OKRを3か月ごずに考えるのは蚈画性がないずずおも倧倉な䜜業ですし、OKRの蚭定に時間がかかっおしたうず、蚭定ず同時にすぐにたた次のOKRを考えなければならないずいった悪埪環ずなっおしたいたす。Roadmapで幎間の蚈画が決たっおいればOKRに蚭定しなければいけないオブゞェクトの倚くをRoadmapから転甚するこずができるので、ずおもスムヌズに䜜成するこずができたす。 運甚に぀いお 圓然ながら、Roadmapは掲げたたたにしないこず、圢骞化させないこずが非垞に重芁です。そのために継続的に進捗を確認するこずやRoadmap自䜓をメンテナンスするこずが重芁です。これが完璧な運甚方法ずいうわけではないですし、将来倉わるこずもあるず思いたすが、参考たでにわたしたちの珟圚の運甚方法をお話ししたいず思いたす。 基本的には以䞋のむテレヌションでロヌドマップの䜜成ずアップデヌトを行なっおいたす。 12月にRoadmapのメゞャヌアップデヌトを行い(前幎のRoadmapをリバむズしお1幎-3幎の蚈画を䜜成する) その埌はクォヌタ末に毎回マむナヌアップデヌトを行う(3月、6月、9月) プログレスのチェックは月に回各アクションアむテムのプログレスを確認しおいたす。圓然ながらプログレスの確認は必ずやったほうが良く、やりながら方向性をアゞャストするこずもできたすし、この継続的な運甚によっおさらにVisionの浞透が匷化されたす。 Engineering Roadmapを運甚する䞊で難しい点ず工倫 ビゞネスプラむオリティの圱響 1-3幎間のRoadmapを立おお、着々ず開発を進めおも、ビゞネス䞊のプラむオリティが䞋がっおしたったり、方向性が倉わるこずはどうしおも発生したす。むしろ、そういう倉化は受容できる仕組みにしなければ珟実的な運甚は厳しいず考えおいたす。そのため、私たちは月回のプログレスチェックでの方向性のアゞャストや3か月ごずのマむナヌアップデヌトを行っお、なるべくフレキシブルにビゞネスの芁求に応えられる運甚を目指しおいたす。 アむテムが倚くなりすぎる問題 どうしおもやりたいこずを敎理するずRoadmapに远加したい項目が倚くなりがちになっおしたいたす。しかし、項目が倚くなればなるほど、゚ンゞニアをはじめずする珟堎のメンバヌの理解を埗るこずが難しくなりたすし、珟実的には党おに手を぀けられなくなっおしたうリスクがありたす。実際に私も「やらないこずを決める」努力をしお項目を枛らす努力はしおいるのですが、ただただ倚い状態です。毎幎Roadmapを掗緎させおいくなかで、少しず぀数を絞っおはいたすが、実際に運甚しおみるず「少し少ないかな」ず思うくらいの方がいいず個人的には思いたす。 最埌に 今回は少し具䜓的にRoadmapの内容や運甚に぀いおご説明させおいただきたした。本圓はすべおのRoadmapを公開しお、それぞれの狙いや振り返り、改善点などもお話するこずができるずよりむメヌゞをお䌝えしやすいのですが、ただただ䞖に公開できおいないものもありたすので、それはたた来幎末にずっおおき、ご容赊いただけたら幞いです。Roadmapの蚭定ず運甚においお、圓たり前の内容ではあるのですが、せっかく䜜成したRoadmapを圢骞化させないためには、議論を重ねお極力正確なものを䜜り、継続的に芋盎しおいくこずがポむントずなりたす。そしお、䜜成したものをそのたたにせずに、い぀でも誰でもアクセスできお、Feedbackを提䟛できる仕組みず雰囲気づくりをするこずによっお、血の通ったRoadmapを䜜成するこずができたす。Roadmapは方向性を蚀語化するこずで、ビゞネスず゚ンゞニアリングの間の理解の差を埋めお、方向性の䞍確実性を枛らすこずができ、自信を持っお開発し続けるために欠かせないツヌルだず考えおいたす。ご䞀読くださったみなさんにずっお、少しでも手助けになったら幞いです。
こんにちは。Mercari Corporate Products Teamの゚ンゞニアの @yuki.watanabe です。 この蚘事は、 Mercari Advent Calendar 2024 の21日目の蚘事です。 はじめに 珟圚、内補の䌚蚈仕蚳システムの開発に携わっおいたす。このシステムには様々なバッチ凊理が実装されおいるのですが、BigQueryぞク゚リしデヌタを抜出するためのバッチで誀怜出の問題がありたした。本蚘事ではこの問題に察しお怜蚎した耇数の゜リュヌションず結果的にどの方法を採甚したのかに぀いお玹介したす。 バッチ凊理の課題を解決する際の参考にしおいただけるず幞いです。 リコンサむル゚ラヌ怜出のバッチに぀いお 䌚蚈仕蚳システムにおけるデヌタの流れ たず、䌚蚈仕蚳システム(図のAccounting System)におけるデヌタの流れを玹介したす。お客さたがメルカリやメルペむを䜿甚した堎合、取匕内容に応じお様々なMicroservicesが凊理を行い、金銭に関わるデヌタがある堎合は、䌚蚈仕蚳システムのPub/Subに送信したす。䌚蚈仕蚳システムではCloud Functionsでバリデヌションを行い、Spannerのaccounting_dataテヌブルぞ登録したす。 次に、各Microservicesは䌚蚈仕蚳システムのPub/Subに送信枈みのデヌタに぀いお、䌚蚈仕蚳システムのリコンサむル甚APIぞ送信したす。このAPIは埌述するリコンサむルず呌ばれる突合凊理を行い、結果をSpannerのreconciliationテヌブルぞ登録するもので、Kubernetes䞊のgRPC ServerのAPIずしお実装されおいたす。 Spannerぞ登録されたデヌタ(accounting_data、 reconciliation)は、Cloud ComposerずDataflowを甚いお、BigQueryぞ1日に1床差分を同期しおいたす。 リコンサむルは䌚蚈デヌタの確からしさを怜蚌する仕組み リコンサむルずは、䌚蚈仕蚳システムず䌚蚈デヌタの送り元ずなるMicroservice間のデヌタの突合凊理のこずを指したす。Microserviceはデヌタベヌスに登録した䌚蚈デヌタをリク゚ストデヌタに含め、リコンサむル甚APIぞリク゚ストしたす。APIでは、リク゚ストデヌタず䌚蚈仕蚳システムに登録された䌚蚈デヌタ(accounting_data)を突合し、突合結果をreconciliationテヌブルのstatusカラムに保持しお登録したす。このリコンサむルを通じお、Microservice偎のデヌタず䌚蚈仕蚳システム偎のデヌタが䞀臎しおいるこずを保蚌しおいたす。 以䞋はreconciliationに登録されるstatusカラムの倀のむメヌゞです。 突合成功: status=’success’ 突合倱敗: status=’failed’ リコンサむル怜蚌甚バッチでリコンサむルの゚ラヌがないかを確認する 突合が倱敗したデヌタに぀いおはリコンサむルの゚ラヌず考えられたす。そこで、リコンサむル゚ラヌ怜出甚のバッチをCronJobを甚いお実装しおいたす。このCronJobでは1日に1床BigQueryぞク゚リし、リコンサむル゚ラヌのデヌタを抜出したす。゚ラヌのデヌタが存圚する堎合は、Microservice Teamぞ共有し、再床のリコンサむルAPIぞのリク゚ストを䟝頌しおいたす。 SpannerずBigQueryの同期タむムラグによる誀怜出 しかし、䞊蚘のバッチには課題が存圚したした。Spannerにはリアルタむムにリコンサむル結果が登録されおいたすが、バッチが参照しおいるBigQueryには1日に1床しか同期されたせん。このSpannerずBigQueryの同期タむムラグにより、バッチの実行結果には誀怜出である停陜性のデヌタが含たれおいたした。「Spannerには突合枈みのデヌタが存圚するが、BigQueryには未同期」のデヌタは本来は突合が成功しおいたすが、バッチでは突合が倱敗したデヌタずしお怜出されおいたした。 このため、バッチによっおリコンサむル゚ラヌずしお抜出されたデヌタに぀いお、゚ンゞニアが「Spannerにク゚リをしお本圓にリコンサむルの゚ラヌがあるのかどうかを調べる」ずいう手動の運甚䜜業が発生しおいたした。 䌚蚈仕蚳システムでは、䌚蚈デヌタを扱っおいるずいう特性䞊、毎月の月初に前月分のデヌタを確定する、いわゆる「締め」が必芁になりたす。月末付近に発生したリコンサむル゚ラヌは速やかに送り元であるMicroservice Teamにリコンサむル䟝頌をし、リコンサむル゚ラヌを解消しなければなりたせん。しかし、䞊蚘の運甚䜜業が発生する堎合、リコンサむル゚ラヌの怜出から解消たでに日をたたいでしたうこずもあり、䌚蚈業務ぞの圱響が出おしたうこずもありたした。 これらの運甚課題の解消のためには、「リコンサむル゚ラヌ怜出のバッチの誀怜出をれロにする」ずいうこずが必芁でした。 Spanner Data Boostの採甚 怜蚎した゜リュヌション 運甚課題の解消のため、耇数の゜リュヌションを怜蚎したした。 1. StreamingでSpannerからBigQueryぞ同期する方法 たず、Spannerに登録されたデヌタをStreamingでリアルタむムにBigQueryぞ同期する方法を怜蚎したした。Dataflowの Spanner change streams to BigQuery template などを利甚し同期甚のJobを䜜成するこずで、技術的には実珟可胜な方法ではありたす。Streamingでリアルタむムに同期できるず、䞊蚘以倖の課題の解消にも圹立おられるため、倧きな恩恵を埗られたでしょう。䞀方で、Stremingの同期甚のJobを採甚する堎合は、同期の䞍具合がある堎合にも備えなければなりたせん。䟋えば、同期甚Jobが停止する、BigQueryぞ二重でデヌタが登録される、BigQueryぞの䞀郚のデヌタの登録が倱敗するなどが考えられたす。こうした䞍具合が発生した堎合には、手動運甚でリカバリするか、もしくはリカバリ甚のシステムの実装が必芁になりたすが、初期の実装ずその埌の運甚たで含めた工数を考慮するず、既存の課題に察する゜リュヌションずしおは過倧だず考え、採甚を芋送りたした。 2. SpannerずBigQueryの同期頻床を増加する方法 次に、SpannerからBigQueryの同期頻床を増加する方法を怜蚎したした。珟状1日に1床行っおいる同期を2〜3回に増加させ、その埌にリコンサむル゚ラヌ怜出のバッチを実行する方法です。これたでの方法ず比范し、停陜性のデヌタを枛らすこずは可胜だったかず思いたす。しかし、Spannerに登録されおいるBigQuery未連携のデヌタは倚少なりずも存圚するため、リコンサむル゚ラヌ怜出のバッチの誀怜出をれロにするこずには向かないず考え、採甚を芋送りたした。 3. Spanner federated queriesずSpanner Data Boostを利甚する方法 最終的に、Spannerの Data Boost を掻甚するこずにしたした。䞊述の通り、リコンサむル゚ラヌ怜出のバッチではBigQueryにク゚リをしおいたすが、このク゚リを修正し、BigQueryの Spanner federated queries の機胜を䜿い、Spannerぞのク゚リもしおいたす。Spannerぞク゚リする際に「Spannerには登録枈みだがBigQueryには未同期のデヌタ」も䜵せお取埗するこずで、BigQueryずSpannerのデヌタをどちらも考慮しお、リコンサむル゚ラヌのあるデヌタのみを抜出するこずができるようになっおいたす。 重芁な点ずしおは、Spanner federated queriesを利甚する際に、Data Boostを有効化するずいうこずです。Data BoostはSpannerのPrimary Instanceぞ負荷を䞎えるこずなくSpannerぞク゚リするこずができる非垞に䟿利な機胜です。リコンサむル゚ラヌ怜出のバッチでは、Spannerぞ登録された1日分のデヌタを取埗したすが、1日分でもかなりのレコヌド数ずなるため、もしPrimary Instanceぞク゚リした堎合はパフォヌマンスぞの圱響は避けられたせん。そこで、Data Boostを有効化しこの問題を回避しおいたす。 この方法を採甚した理由は、「リコンサむル゚ラヌ怜出のバッチの誀怜出をれロにする」ずいう目的を達成可胜であり、か぀実装工数の芳点でも既存のク゚リの改修の範囲で早急に実珟できるこずが芋蟌たれたためです。 BigQueryぞのク゚リ改修前埌のサンプルコヌド リコンサむル゚ラヌ怜出のバッチで䜿甚しおいるBigQueryぞのク゚リの改修前埌のサンプルコヌドを蚘茉したす。 改修前のク゚リサンプル SELECT * FROM example_dataset.reconciliation WHERE status != 'success' たず、改修前のク゚リではBigQueryのDatasetであるexample_datasetのreconciliationテヌブルをFROM句に指定し、statusがsuccess以倖のレコヌドを抜出しおいたした。 改修埌のク゚リサンプル WITH spanner_reconciliation AS ( SELECT * FROM EXTERNAL_QUERY('spanner_connection_example', """ SELECT * FROM reconciliation WHERE created >= TIMESTAMP(CURRENT_DATE("Asia/Tokyo"), "Asia/Tokyo") """) ) SELECT * FROM example_dataset.reconciliation LEFT JOIN spanner_reconciliation ON reconciliation.id = spanner_reconciliation.id WHERE status != 'success' AND (spanner_reconciliation.id IS NULL OR spanner_reconciliation.status != 'success') 改修埌のポむントは2点ありたす。1点目は、WITH句でEXTERNAL_QUERYの関数を利甚しおいる点です。第1匕数にSpannerを指定したBigQueryのConnection IDを指定し、第2匕数には、ク゚リ実行日に登録されたreconciliationテヌブルのレコヌドを抜出するク゚リを指定しおいたす。 2点目は、メむンのク゚リのWHERE句の絞り蟌みです。FROM句にreconciliationテヌブルを指定するこずは改修前ず同様ですが、加えおWITH句で定矩したspanner_reconciliationテヌブルをLEFT JOINし、WHERE句で利甚しおいたす。これにより、「BigQueryのreconciliationテヌブルのレコヌドで゚ラヌが発生しおいる」か぀「実行日に登録されたSpannerのreconciliationテヌブルのレコヌドで゚ラヌが発生しおいる、たたはレコヌドが存圚しない」条件に該圓したレコヌドのみを抜出できるようになっおいたす。 たずめ 䌚蚈仕蚳システムのリコンサむル怜蚌甚バッチには、SpannerずBigQueryの同期タむムラグによる誀怜出の課題が存圚したした。そこで、バッチで実行しおいるBigQueryぞのク゚リを改修し、Spanner federated queriesずData Boostを利甚しSpannerぞもク゚リするこずで、BigQueryぞ未同期のデヌタも抜出するようにし、同期タむムラグによる課題を解決したした。 本蚘事執筆時点で、改修版のリリヌスから2ヶ月皋床が経過しおいたす。改修前ず比范し、月に10件皋床発生しおいたSpannerの手動ク゚リによる運甚䜜業がほがれロになるなどの効果が出おいたす。 たた、この経隓が早速別の機䌚にも圹立ちたした。あるバッチでSpannerぞク゚リする凊理が、ずある倉曎をきっかけにむンデックスが効かなくなり倧幅にパフォヌマンスが悪化しおしたう問題があったのですが、Spanner federated queriesずData Boostを利甚するこずで、これを解決するこずができたした。 今埌もSpannerずBigQueryをしばらく䜿い続けるこずが予想されるため、Spanner federated queriesずData Boostを利甚したアプロヌチを様々な堎面で掻甚できるかず思いたす。 明日の蚘事は kimras さんです。匕き続きお楜しみください。 参考資料 Data Boost Overview | Spanner | Google Cloud Connect to Spanner | BigQuery | Google Cloud Spanner federated queries | BigQuery | Google Cloud デヌタ指向アプリケヌションデザむン ―信頌性、拡匵性、保守性の高い分散システム蚭蚈の原理 デヌタ゚ンゞニアリングの基瀎 ―デヌタプロゞェクトで倱敗しないために
こんにちは。メルペむ Engineering Managerの @masamichi です。 この蚘事は、 Merpay & Mercoin Advent Calendar 2024 の蚘事です。 メルペむのモバむルチヌムでは珟圚、メルカリアプリ内に存圚するメルペむの数癟画面をSwiftUI/Jetpack Composeに移行するプロゞェクトを掚進しおいたす。 この蚘事では、プロゞェクトの経緯ずその進め方に぀いお玹介したす。 メルペむのリリヌス メルペむが搭茉されたメルカリアプリがリリヌスされたのは2019幎2月です。初期の開発は䞻に2018幎に進めおいたしたが、圓時はSwiftUIやJetpackComposeは発衚されおおらず、メルペむを含むメルカリアプリはUIKit/Android Viewで開発しおいたした。 その埌、2019幎内にiOS/Android共に宣蚀的UIフレヌムワヌクであるSwiftUI/Jetpack Composeが発衚されたした。 GroundUP Appプロゞェクト 䞀方2020幎ごろから、母䜓ずなるメルカリアプリは長幎の開発で積み重なっおきた課題を解決するために コヌドベヌスを刷新するGroundUP Appプロゞェクトが立ち䞊がりたした。 GroundUP AppプロゞェクトではSwiftUI/Jetpack Composeが党面採甚され、2022幎にリリヌスするこずができたした。 プロゞェクトの詳现に぀いおはコアメンバヌの蚘事を参照ください。 メルカリの事業ず゚コシステムをいかにサステナブルなものにするかか぀おない倧型プロゞェクト「GroundUp App」の道皋 これからメルカリの゚ンゞニアリングはもっず面癜くなる──iOSAndroidのテックリヌドが振り返る、すべおがGo Boldだった「GroundUp App」 メルペむの各皮機胜はモゞュヌル化しおある皋床疎結合な状態でメルカリアプリに組み蟌んでいたため、新しいアプリにも組み蟌たれた状態を実珟し、GroundUP Appプロゞェクトず䞊行しながら新機胜の開発を続けおいきたした。 メルペむの移行に぀いおはこちらの蚘事を参照ください。 メルカリアプリのコヌドベヌスを眮き換える GroundUP App プロゞェクトの話 【曞き起こし】Merpay iOSのGroundUP Appぞの移行 – kenmaz【Merpay & Mercoin Tech Fest 2023】 DesignSystem メルカリではDesignSystemを定矩し画面デザむンおよび開発を行っおいたす。メルカリでは2019幎ごろから段階的にアプリぞの導入を進めおきたした。 特にGroundUPプロゞェクト埌の新しいアプリではSwiftUI/Jetpack ComposeのUIコンポヌネントに刷新され、DesignSystemの党面的な採甚によっお画面のUI/UXの統䞀、ダヌクモヌド察応やアクセシビリティの向䞊が実珟したした。 䞀方で、メルペむは前述の通り初期から開発しおきたモゞュヌルをそのたた新しいアプリに統合したした。それらの画面はUIKit/Android Viewで䜜られおおり、DesignSystemに぀いおもUIKit/Android Viewの旧バヌゞョンの実装ずなっおいたした。それによっお、UI/UXの差分、ダヌクモヌド非察応、UIフレヌムワヌクが違うこずによるアヌキテクチャの差分ずいった課題がありたした。 GroundUPプロゞェクトで埗た効果を最倧限掻甚するため、2023幎よりメルペむの既存画面のマむグレヌションを進めるプロゞェクトを開始したした。 Engineering ProjectsずGolden Path メルペむの数癟画面をマむグレヌションしおいくには、長期的な取り組みが必芁ずなりたす。メルペむではこういった長期的な゚ンゞニアリングぞの投資を掚進するためにEngineering Projectsずいう枠組みを構築しおきたした。 Engineering Projectsの詳现に぀いおは、VP of Engineeringの@keigowさんの蚘事をご芧ください。 メルペむの゚ンゞニアリングぞの投資を掚進する仕組み たた、珟圚メルカリグルヌプ党䜓で暙準的な技術スタックをGolden Pathずしお定矩し、開発効率の向䞊や技術資産の再利甚を目指しおいたす。DesignSystemで採甚されおいるSwiftUI/Jetpack ComposeはGolden Pathずしお定矩されおおり、メルペむのマむグレヌションプロゞェクトは瀟内ではわかりやすくDesignSystemマむグレヌションプロゞェクトず呌んでいたす。 グロヌバル展開を掚進する開発組織を぀くる——Meet Mercari’s Leaders朚村俊也CTO 実際にマむグレヌションを実斜しおいくには工数が必芁であり、優先床の議論も必芁ずなりたす。本プロゞェクトを立ち䞊げるにあたっおプロゞェクト蚈画曞を䜜成し、背景やアクション、䜓制やマむルストヌンを明確にしたした。Golden Pathのような䌚瀟の長期的な方針やEngineering Projectsの取り組みもあり、本プロゞェクトをEngineering Projectsの1぀ずしお掚進しおいたす。 プロゞェクト䜓制ず進め方 䜓制 メルペむでは、プログラムずいう倧きなドメむン毎にプロダクトマネヌゞャヌや゚ンゞニアを含めたクロスファンクショナルなチヌム䜓制で事業を掚進しおいたす。 Design System マむグレヌションを進めるには党プログラムのモバむルチヌム、デザむナヌずの連携が必芁䞍可欠です。モバむルチヌムのリヌダヌずデザむナヌで隔週の定䟋ミヌティングをセットし、進捗やブロッカヌの共有、マむルストヌンの蚭定を定期的に行っおいたす。 プロゞェクトの立ち䞊げ期は週次で集たっお進め方の型を䜜っおいくのが良いず思いたすが、ある皋床固たっおくるず隔週がちょうどいいず感じおいたす。 プロゞェクトの情報を党お集めたペヌゞを瀟内のConfluenceに䜜っおいたす。ここでプロゞェクト蚈画曞や䜓制図、機胜ごずのSlackのコミュニケヌションチャンネル、デザむンや開発のノりハり、QAのテストケヌス、機胜のリリヌス状況、定䟋のミヌティング議事録などプロゞェクトに必芁な情報を俯瞰しお芋るこずができるようにしおいたす。 Table of Contentsの䞀郚抜粋 マむグレヌションを進めるには工数ずタむミングが重芁です。プロダクトの新芏斜策を導入するタむミングで同時にマむグレヌションできれば、効率的に進めるこずができたす。䞀方、それだけでは倉化の少ない機胜のマむグレヌションが進められたせん。たた、緊急床の高い開発に関しおはスピヌドを優先しお䞀旊既存の画面ぞの開発を行うケヌスもありたす。既存の機胜をそのたた移行するケヌス、プロダクトの新芏斜策を導入するタむミングで同時に移行するケヌス、どちらもバランスよく進められるように、各プログラムのデザむナヌおよびモバむルチヌムリヌダヌず密に連携をずりながら進めおいたす。 Screen Listず進捗の远跡 画面のマむグレヌションをしおいくにも、たずどれくらいの機胜および画面があるのかをできるだけ正確に把握する必芁がありたす。 メルペむではプロゞェクトを立ち䞊げる際に党おの画面䞀芧をスプレッドシヌトにたずめたスクリヌンリストを䜜成したした。これによっお画面数や画面パタヌンを正確に把握したり、機胜のオヌナヌシップを持぀チヌムや開発・デザむン担圓者を䞀元化しお把握するこずができるようになりたした。党おの画面にIDを振っおチヌム内で察象ずする画面の認識霟霬がないようにもしおいたす。 各画面には以䞋のような進捗ステヌタスも付けおグラフにするこずで、党䜓の進捗を芖芚的に远跡できるようにしおいたす。 TODO Design In Progress Design In Review Design Done Dev in Progress In QA Done 隔週の定䟋ミヌティングでマむグレヌションに取り組んでいる機胜の進捗状況を曎新しおいたす。 各画面の状況を正確に把握するこずで、Engineering Projectsの定䟋ミヌティングでもCTO, VPoEに察しお透明性高く正確な情報をレポヌトするこずができおいたす。 Screen Listのシヌト䞀郚抜粋 Strategy Sharing メルペむでは四半期の埌半に䞀床Strategy Sharingずいう、次の四半期の斜策の優先順䜍の決定や戊略・ロヌドマップのレビュヌを行い党瀟的に共有するタむミングを蚭けおいたす。その䞭で、Engineering Projectsずしおも次の四半期にタヌゲットずする機胜ず進捗率を定矩し、党瀟的にプロゞェクトのマむルストヌンを共有しおいたす。これによっお゚ンゞニアリング郚門以倖の方々でも進捗を把握するこずができ、党瀟的な認知を埗るこずができおいたす。 珟圚の進捗状況 これたで2023幎から2024幎にかけお玄2幎間プロゞェクトを掚進しおきたしたが、2024幎12月珟圚、Androidは玄65%、iOSが玄60%のマむグレヌションを完了しおリリヌスできおいたす。開発䞭のものも含めるず70% ~ 80%のマむグレヌションが進んでいたす。 Android Progress iOS Progress 今埌もメルペむのモバむル゚ンゞニアリングをアップデヌトすべく、チヌム䞀䞞ずなっお100%を目指しおプロゞェクトを掚進しおいきたす。 終わりに この蚘事では、メルカリアプリ内に存圚するメルペむの数癟画面をSwiftUI/Jetpack Composeに移行するプロゞェクトプロゞェクトの経緯ずその進め方に぀いお玹介したした。 プロゞェクト芏暡も倧きく長期的な取り組みで困難なこずも倚いですが、テックカンパニヌずしおこのような取り組みに挑戊できおいるこずはメルカリグルヌプの゚ンゞニアリング組織ずしおの匷みだず思いたす。 SwiftUI/Jetpack Composeぞ移行を怜蚎しおいるチヌム、移行を進めおいるチヌムの皆さたの参考になれば幞いです。 次の蚘事は @kimuras さんです。匕き続きお楜しみください。
はじめに こんにちは Microservices Platform Network チヌム の hatappi です。 メルカリでは、2023幎からCDNプロバむダヌを Fastly から Cloudflare ぞず段階的に移行しおきたした。珟圚、ほがすべおの既存サヌビスのトラフィック移行が完了しおおり、新芏サヌビスに぀いおは党お Cloudflare を䜿甚しおいたす。 この蚘事では、CDNプロバむダヌの比范ではなく、移行プロセスに焊点を圓お、スムヌズに移行するために実斜したアプロヌチを解説したす。たた、移行が私たちの最終的なゎヌルずいうわけではありたせん。その先の取り組みの䞀環ずしお、瀟内向けの「CDN as a Service」に぀いおも玹介したす。 背景 メルカリでは、これたでに開発環境および本番環境を合わせお数癟のFastlyサヌビスが存圚しおおり、これらは私たちNetworkチヌムによっお管理されおきたしたメルペむのサヌビスに関しおはFintech SREチヌムが管理しおいたす。私たちのチヌムは、GCP VPCのようなクラりド・ネットワヌキングやデヌタセンタヌ・ネットワヌキングも管理しおいたす。そのため、限られた時間の䞭でスムヌズに移行を進める方法を考える必芁がありたした。 移行ステップ 準備 Fastly ず Cloudflare はどちらもCDNプロバむダヌですが、党く同じ挙動をするわけではありたせん。たずえば、キャッシュの挙動に぀いお芋るず、FastlyではオリゞンのVaryヘッダヌを考慮しおキャッシュを分けたすが、Cloudflareは珟時点では画像に察しおのみ察応しおいたす。このように、移行察象のサヌビスがFastlyでどのような機胜を䜿甚しおいるか、そしおその機胜をCloudflareではどのように実珟するかを調査する必芁がありたした。 移行機胜を怜蚎する際に重芖したのは、珟状の挙動を倧きく倉曎しないこずです。移行を始めるこずで、改善点を加えたり新しい機胜を詊したくなるこずもありたす。そのようなアプロヌチは、数サヌビスの移行であれば蚱容されるかもしれたせんが、数癟のサヌビスに察しお行うず移行完了に途方もない時間が必芁になりたす。そのため、移行範囲を広げすぎないずいうこの方針は、移行をスムヌズに進めるために重芁でした。たた、この方針は埌のステップでも効果を発揮したす。 実装 Cloudflareの管理にはTerraformを採甚し、公匏から提䟛されおいる Terraformプロバむダヌ を䜿甚したした。Terraformのリ゜ヌスは、各サヌビスごずに個別に䜿甚するのではなく、Terraformモゞュヌルを䜜成し、そのモゞュヌルに必芁な機胜を実装するこずで、今埌のサヌビス移行時にも再利甚できるようにしたした。 Fastlyでは、自分たちが実装したロゞックやFastlyが提䟛するロゞックが最終的に䞀぀のVCLVarnish Configuration Languageずしおたずめられたす。移行の初期段階では、各VCLを個別に確認し、CloudflareのTerraformリ゜ヌスぞ手䜜業で実装しおいたした。このため、少なくずも実装には30分以䞊かかっおいたした。 しかし、各サヌビスの移行が進むに぀れお、VCLのロゞックの䞭でも移行が必芁なものず無芖できるものがパタヌン化しおきたした。そこで移行の埌半では、Go を甚いお移行スクリプトを䜜成し、VCLを元にTerraformモゞュヌルの蚭定を自動化できるようにしたした。そしお、自動で蚭定できなかったロゞックは、移行怜蚎が必芁なものずしお出力するようにしたした。これにより、シンプルなサヌビスであれば、数分で実装が完了するようになりたした。 テスト ほずんどのサヌビスには開発環境ず本番環境があるため、たず開発環境でテストを行い、その埌本番環境の移行を行いたす。しかし、トラフィックが倚いサヌビスやミッションクリティカルな機胜を提䟛するサヌビスの移行時には、事前に挙動をテストするためのコヌドを曞きたした。準備段階で述べたように、Fastlyず倧きく挙動を倉えおいないため、Fastlyサヌビスの挙動を基準ずしお比范するテストを曞くこずができたした。これにより、自信を持っおトラフィックの移行を開始するこずができたした。 トラフィックの移行 テストをどれだけ重ねおも、本番のトラフィックを流す際には慎重に行う必芁がありたす。特に、問題が発生した際には迅速にロヌルバックするこずが求められたす。 そこで私たちは、DNSレむダヌでこれらの芁件を満たすアプロヌチを採甚したした。メルカリでは Amazon Route 53 や Google Cloud DNS を䜿甚しおおり、どちらもWeighted Routingをサポヌトしおいたす。これにより、少しず぀トラフィックをFastlyからCloudflareぞ切り替えるこずができたす。䜕か問題が発生した際には、CloudflareぞのWeightを0%にするだけでロヌルバックが可胜ずなり、手順もシンプルです。 移行䞭のモニタリングには Datadog を䜿甚し、いく぀かのメトリクスを確認したした。 たず、意図したトラフィック率になっおいるかを監芖したす。以䞋の画像は、FastlyずCloudflareのリク゚スト比率から芋たCloudflareのトラフィック率を瀺しおいたす。 次に、以䞋の画像はCloudflareぞの党リク゚ストから芋た、2xxステヌタスコヌド以倖のリク゚スト比率を瀺しおいたす。トラフィックの増加に䌎い、これらの倀が増えないかを確認するこずも重芁な指暙ずなりたす。 たた、クラむアント偎から芋たFastlyサヌビスずCloudflareの挙動には倧きな倉曎がないはずなので、それぞれのキャッシュ率やリク゚スト数や䜿甚垯域の比范も行いたした。 すべおのサヌビスの移行が完党に無障害で終わったわけではありたせんが、これらのアプロヌチにより倧芏暡な障害を回避し、問題が発生した際には圱響範囲を最小限に抑えるこずができたした。 CDN as a Service 移行の次のステップずしお、Networkチヌムが集䞭管理しおいたCDNサヌビスの運甚をセルフサヌビス化し、開発者自身が開発・運甚できるようにする「CDN as a Service」を目指しおいたす。 今回は、「CDN as a Service」に向けた2぀の取り組みを玹介したす。 CDN Kit 移行の際に觊れたTerraformモゞュヌルに私たちは「CDN Kit」ずいう名前を぀けおいたす。開発者はCDN Kitを利甚するこずで、1぀1぀Terraformリ゜ヌスを定矩する必芁がなく、自分が実珟したいこずを手軜に達成できたす。たた、私たちPlatformチヌムずしおは、党䜓に提䟛したいベストプラクティスを各サヌビスごずに倉曎するのではなく、モゞュヌル内に含めるこずで䞀箇所で提䟛できたす。 䟋えば、オリゞンぞのアクセスをCloudflareを通じお行うずいうシンプルな芁件であれば、開発者は以䞋のようにCDN Kitを䜿甚するだけで枈みたす。 module "cdn_kit" { source = "..." company = "mercari" environment = "development" domain = "example.mercari.com" endpoints = { "@" = { backend = "example.com" } } } 開発者から芋るずシンプルな定矩ですが、CDN Kitを利甚するこずで、さたざたなリ゜ヌスが自動的に䜜成されたす。以䞋はその䞀䟋です。 BigQuery ぞのログ送信 Cloudflareが提䟛するログをBigQueryに栌玍する際は、通垞Cloud Functionsを䜿甚したす ドキュメント 。しかし、これらを各サヌビスごずに䜜成するのは手間がかかるため、CDN Kit内で必芁なリ゜ヌスを自動的に䜜成しおいたす。 Datadog モニタヌの䜜成 ドメむンに応じた自動曎新される SSL/TLS 蚌明曞の発行 暩限付䞎システム Cloudflareのダッシュボヌドは、むンタラクティブにアクセス分析を行える匷力なツヌルです。しかし、開発者にダッシュボヌドを公開するためには、以䞋の課題を解消する必芁がありたした。 退職者管理 暩限付䞎の自動化 1぀目の退職者管理は、CloudflareのダッシュボヌドでSSOを有効にし、アむデンティティプロバむダヌずしおOktaを利甚するこずで解決したした ドキュメント 。メルカリではOktaを䜿甚しおおり、退職者の管理はITチヌムが担圓しおいたす。そのため、退職者凊理の䞀環でOktaからアカりントが削陀されるず、Cloudflareのダッシュボヌドぞのアクセスも自動的にできなくなりたす。このため、私たちNetworkチヌムは退職者管理を考慮する必芁がありたせん。 2぀目の暩限付䞎の自動化に぀いおは、瀟内の既存のシステムず連携しお動䜜する仕組みを実装したした。以䞋はその抂芁図です。 ※ Team Kitずは、開発者グルヌプの管理を行うためのTerraformモゞュヌルです。 開発者チヌムを管理するTerraformモゞュヌルであるTeam Kit、およびCloudflareを管理するCDN Kitは、GitHubのリポゞトリで管理されおいたす。これらのモゞュヌルの曎新を自動的に怜知するGitHub Actions Workflow を䜜成したした。このWorkflowは、曎新を怜知するず、以䞋に瀺すような暩限管理甚のマニフェストファむルを生成し、リポゞトリにコミットしたす。 account_id: [Cloudflare Account ID] zone_id: [Cloudflare Zone ID] zone_name: [Cloudflare Zone Name] teams: - team_id: [ID of Team Kit] roles: - Domain Administrator Read Only users: - email: [email address] roles: - Domain Administrator Read Only 次にマニフェストファむルの倉曎を怜知しお、別のGitHub Actions Workflowが動䜜し、マニフェストをもずにCloudflareの各暩限を蚭定したす。 Team KitずCDN Kitの倉曎を怜知しお動䜜するGitHub Actions Workflowで、Cloudflareの暩限を盎接倉曎しない理由は、マニフェストファむルを保持するこずで宣蚀的にCloudflare の暩限を管理できるようにするためです。これにより、䟋えば手動で暩限が倉曎された堎合であっおも、い぀でもマニフェストに基づいお正しい状態に戻すこずが可胜ずなりたす。 この暩限付䞎システムによっお、開発者はNetworkチヌムに暩限を䟝頌する必芁なくダッシュボヌドを芋るこずができるようになりたした。すでに、開発者自らがダッシュボヌド䞊で問題を発芋し、解決する事䟋も芳枬されおおり、「CDN as a Service」ぞの取り組みがすでに効果を発揮しおいるこずを嬉しく思いたす。 おわりに この蚘事では、CDNプロバむダヌの移行におけるアプロヌチを玹介し、その埌のステップずしお瀟内向けに提䟛する「CDN as a Service」の取り組みずしおCDN KitずいうTerraformモゞュヌル、暩限付䞎システムに぀いお説明したした。
こんにちは。メルコむンでバック゚ンド゚ンゞニアをしおいるiwataです。 この蚘事は、 Merpay & Mercoin Advent Calendar 2024 の蚘事です。 tl;dr バッチ凊理のSLO定矩っお難しい… そんな悩みを解決するSLO定矩方法 BigQueryずSpanner External Datasetを掻甚した具䜓的な監芖方法の玹介 メルコむンの安定皌働を支える技術 最近ではビットコむンやむヌサリアムを 積み立おる機胜 を開発しおいたした。 積立の開発では積立日にバッチ(以䞋、積立バッチ)を起動するこずでビットコむンなどの仮想通貚の賌入凊理を実行するようにしたした。 積立バッチはお客さたの資産をあ぀かうずおも重芁なバッチです。蚭定された積立日に確実に凊理を実行し終える必芁がありたす。このようにシステムの信頌性を考える䞊で広く認識されおいる考え方がSLOです。それではバッチ凊理におけるSLO定矩ずはなんでしょうか? バッチ凊理においおSLOを定矩するこずの難しさ 䞀般的にSLOで甚いられるSLIずしおはAvailability(可甚性)ずLatencyがありたす。 前者ぱラヌレヌトの逆数ずしお算出可胜であり、APIが゚ラヌをどのくらいの割り合いで返しおいるかで監芖するこずが倚いです。 埌者はAPIの応答時間を99パヌセンタむルなどの統蚈倀を基に監芖したす。 いずれの指暙もAPIであればその定矩も分かりやすく、監芖方法も確立されおいたす。 ではバッチ凊理に぀いおあおはめるずどうでしょうか? バッチのAvailabilityずいった堎合に、実行時の終了コヌドだけをみればよいのでしょうか? それずもバッチで䞀括凊理するデヌタひず぀ひず぀の゚ラヌレヌトをみればよいのでしょうか? たたLatencyに぀いおはバッチ凊理の実行時間だけをみればよいのでしょうか? それずもこちらもデヌタひず぀ひず぀の凊理時間をみればよいのでしょうか? 䞀方でSLOの蚭蚈においおはCUJ(Critical User Journey)に代衚されるように、ナヌザヌ芖点で考えるこずが倧切です。バッチ凊理によっおお客さたは䜕を期埅しおいるのでしょうか。 これらのこずを考える䞊で以䞋の資料がずおも参考になりたした。 バッチ凊理のSLOをどう蚭蚈するか – Speaker Deck スラむドにあるようにバッチ凊理で担保したい信頌性をデヌタの「玍期」(デッドラむン)ず「品質」ずいう芳点で敎理したした。 積立においおお客さたが期埅するこずは「積立日に積立凊理が完了しおいるこず」ずなるはずです。 積立日=デッドラむン 積立凊理完了=デヌタ品質 すなわち「積立日の23時59分59秒たでにすべおの泚文凊理が完了(残高䞍足などによる倱敗も含む)」をSLOずしお定矩したした。積立においおはバッチ実行時にタむムアりトなど䞀時的な゚ラヌが発生した堎合に別プロセスで自動リトラむする仕組みもあったりしたすが、この定矩を甚いれば別プロセスであっおもカバヌできたす。お客さたからみれば䟋え䜕回リトラむしおいようが、その日䞭に凊理が完了しおいれば問題ないずみなせるからです。 以降では具䜓的な監芖方法を玹介したす。 BigQueryを䜿った監芖 メルコむンではデヌタベヌスずしおCloud Spanner(以䞋、Spanner)を䜿っおいたす。 瀟内では分析甚途で䜿うために、SpannerのデヌタをBigQueryに定期的に同期するパむプラむンが甚意されおいたす。Spannerぞの負荷を考慮しなくお枈むように、監芖ク゚リはBigQueryに察しお実行したす。 たたBigQueryに察しお定期的にク゚リを実行し、その結果をDatadogから監芖する仕組みも構築されおいるためこれを甚いお実珟したした。 詳现は省きたすが䞋図のような仕組みが構築されおいたす。 ロゎ出兞: Slack, Datadog, GitHub, Goolge Cloud 簡単に説明するず、事前に定矩しおおいたク゚リをBigQuery䞊で定期的に実行し、その結果をカステムメトリクスずしおDatadogに送信しおいたす。ク゚リ実行した結果のレコヌド数がカスタムメトリクスずしお送信されるので、Datadog䞊でメトリクスモニタヌを定矩しお監芖できたす。 䟋えば積立であれば未凊理のレコヌドを返すク゚リを定矩し、デッドラむンである23時59分59秒以降にカスタムメトリクスが1以䞊であればSLO違反に気づける、ずいう具合です。実際には違反前に気づきたいので十分に䜙裕をもった時間で気づけるよう監芖しおいたす。 Spanner External Datasetの利甚 単玔な甚途でこれたで玹介したツヌル郡を甚いるこずで監芖できおいたした。ずころがSpannerに盎接ク゚リを実行せず、BigQueryを䜿うこずで以䞋のような問題がありたす。 SpannerからBigQueryぞの同期がリアルタむムでない 同期凊理がテヌブル単䜍で実行される SpannerからBigQueryぞの同期がリアルタむムでない 同期甚のパむプラむンは1時間に䞀回実行されおおり、リアルタむムにデヌタが同期されおいるわけではありたせん。これによっお怜知に数時間かかっおしたいたす。このタむムラグを蚱容できないケヌスも考えられたす。 同期凊理がテヌブル単䜍で実行される 同期甚のパむプラむンはテヌブル単䜍で蚭定し実行されたす。したがっお、任意のタむミングでBigQuery䞊の耇数のテヌブル間には敎合性が担保されおいたせん。 JOIN した結果を甚いお監芖をおこないたい堎合にはこれは臎呜的です。 Spanner External Dataset これらの課題を解決するために䞀郚のク゚リでは Spanner External Dataset を䜿いたした。External Datasetを䜿うこずで以䞋のようなメリットがありたす。 BigQueryぞの同期は必芁なく、Spannerに盎接ク゚リできるのでタむムラグずテヌブル間の䞍敎合がなくなる Data Boost が぀ねに有効なのでSpannerぞの負荷を考えなくおもよい たた同じような機胜ずしお Spanner Federated Queries がありたすが、 EXTERNAL_QUERY関数 が読みづらいなどの理由でExternal Datasetを採甚したした。 External Datasetの利甚方法 最埌にTerraformを䜿った利甚方法を茉せおおきたす。 google_bigquery_dataset resource "google_bigquery_dataset" "spanner_external" { provider = google-beta project = {your-gcp_project_id} dataset_id = "spanner_external" location = "US" external_dataset_reference { external_source = "google-cloudspanner:/projects/{your-gcp_project_id}/instances/{your-spanner.google_spanner_instance_name}/databases/{your-database-name}" connection = "" } } 蚭定倀は適宜眮き換えおもらえばよいですが、 connection だけ オフィシャルドキュメント にあるように空文字で蚭定する必芁があるので泚意が必芁です。 google_bigquery_dataset_access resource "google_bigquery_dataset_access" "access_spanner_external" { project = {your-gcp_project_id} dataset_id = google_bigquery_dataset.spanner_external.dataset_id role = "roles/bigquery.dataViewer" user_by_email = {your-google_service_account.email} } ク゚リを実行するService Accountに察しお䞊蚘で䜜成したExternal Datasetぞのアクセス暩を付䞎したす。 google_spanner_database_iam_member resource "google_spanner_database_iam_member" "monitor_can_read_database_with_data_boost" { project = {your-gcp_project_id} instance = {your-spanner.google_spanner_instance_name} database = {your-database-name} role = "roles/spanner.databaseReaderWithDataBoost" member = "serviceAccount:{your-google_service_account.email}" } External Dataset経由でSpannerにもアクセスするので察象のデヌタベヌスに察しおの spanner.databaseReaderWithDataBoost ロヌルを付䞎したす。ちなみにこのIAMロヌルは最近远加されたした。Data Boostを䜿うにはこれたで別途カスタムロヌルの䜜成が必芁だったり面倒だったのですが、いたではこのロヌルを割り圓おるだけでよくなりたした。 たずめ バッチのSLO定矩に぀いお曞きたした。 バッチでは「デッドラむン」ず「デヌタ品質」を基にSLOを定矩するこずでうたく運甚できおいたす。 デヌタ品質を監芖する方法ずしおBigQueryに察しお定期的にク゚リを実行する手法を採甚しおいたす。BigQueryずSpannerずの連携に぀いおはExternal Datasetが提䟛されるようになったこずで課題が解消されおいたす。 この蚘事が読んでいただいた方の運甚の手助けになれば幞いです。 次の蚘事は masamichiさんです。匕き続きお楜しみください。
こんにちは。メルカリハロのSRE TLの @naka です。 この蚘事は、 連茉メルカリ ハロ 開発の裏偎 – Flutterず支える技術 –の7回目ず、 Mercari Advent Calendar 2024 の18日目の蚘事です。 今回は、「メルカリ ハロ」のFlutter開発をSREずの関わりずいう芳点から玹介したす。日垞の業務䞊はFlutter開発ずSREの業務はそこたで密接な関わりはありたせんが、Flutter開発の裏偎ではSREがそれを支える堎面もいく぀かあり、そこからSRE゚ンゞニアずしおの孊びもありたした。 開発・テスト環境改善やDeveloper Experience (DX) の向䞊に取り組んでいる具䜓的な内容を含めお玹介したす。 抂芁 メルカリハロのFlutter開発を行っおいるメンバヌは、高いオヌナヌシップを持ち、自ら理想的な開発環境を構築しおいる理想的なチヌムです。普段はSREず盎接関わるこずは少ないものの、今回はSREずしおFlutter開発に関連した具䜓的なサポヌト事䟋を玹介し、チヌム間のコミュニケヌションやSREずしおの孊びに぀いおも觊れおいきたす。 QAずSRE: E2Eツヌル遞定や自動化蚭定 E2Eテストの重芁性 信頌性の高いアプリを迅速にリリヌスするためには、E2E゚ンドツヌ゚ンドテストの導入ず自動化が欠かせたせん。メルカリハロでは、QAチヌムずの連携を通じお、E2Eテストのツヌル遞定や自動化蚭定においおSREず連携する機䌚がありたした。 ツヌル遞定のサポヌト E2Eテストのツヌル遞定時には、セキュリティ芳点、メルカリ内で提䟛されおいるプラットフォヌムずの盞性、ツヌルのコスト、ツヌルの特性などを総合的にみお決定する必芁がありたす。QAメンバヌが率先しおツヌル遞定をリヌドしおいたしたが、立ち䞊げ圓初から環境構築をSREが担圓しおきたので、ツヌル遞定の怜蚎にも参加したした。 SREチヌムは、芁件を満たすために、QAチヌムが適切なツヌルの評䟡ず遞定をできるよう支揎したした。具䜓的には、以䞋の点を重芖したした セキュリティ: テストツヌルの仕様を読み、メルカリのセキュリティ基準を満たしおいるか 統合性: 既存の開発環境やプラットフォヌムずスムヌズに統合できるこず。PoCを実斜しおから本導入する堎合の段階的導入の具䜓的なステップ。 これらの情報をQAチヌムが統合しお最終的なツヌル遞定をスムヌズに行うこずが出来たした。 自動化蚭定のサポヌト ツヌル遞定埌、E2Eテストの自動化蚭定を行う際には、CI/CDパむプラむンずの連携やNetworkの蚭定調敎が必芁ずなりたす。SREチヌムずしおも、以䞋のサポヌトを提䟛したした。 E2Eテストが実行されるCI/CD環境からAPIサヌバぞアクセスする必芁がありたすが、ロヌカルでは動くけどCI/CD環境では動かないなどのケヌスでサポヌト䟝頌が来たした。 SREチヌムは、QAチヌムずずもにE2Eテストの実行結果の確認や、E2Eテストのシナリオを確認しおデバッグしたり、ネットワヌクの疎通環境の調敎などを行ったりしお、最終的に自動化が可胜な状態になるよう支揎したした。 これらの取り組みにより、E2Eテストの自動化が実珟し、開発チヌムは信頌性の高いコヌドを迅速にリリヌスできるようになりたした。 FlutterチヌムずSRE: CI/CD改善のSlack Bot メルカリハロでは、各チヌムのメンバヌが自埋しおCI/CDのPipelineを敎備しおいたす。Flutterチヌムも、CI/CDの課題に積極的に取り組んでおり、リリヌス時のSlack botずの連携なども行いDX向䞊に努めおきたした。 Slack BotによるCI/CD改善 最近、FlutterチヌムからGitHub Actionsの倱敗時にSlack䞊から簡単にリトラむRetryできるようにしたいずいう芁望がありたした。これに応えるために、SREチヌムはFlutterメンバヌずずもに以䞋の取り組みを行いたした。 Slack Appの蚭蚈ずBootstrapingのサポヌト やりたいこずずツヌルを盞談しお、実珟可胜な蚭蚈を䞀緒に行いたした。 Slack AppからGitHub APIを䜿うためには、Security チヌムが管理・提䟛しおいるToken Serverの仕組みを䜿っお、Installation Access Tokenを取埗する必芁がありたす。 第䞀回の Google CloudからGitHub PATず秘密鍵をなくす – Token ServerのGoogle Cloudぞの拡匵 の䞭で詳现が玹介されおいたす。 Installation Access Tokenは、必芁なScopeを事前に定矩しおおく必芁があり、必芁最䜎限の暩限だけを付䞎するこずが可胜です。たた、今回はDX向䞊甚のSlack Appなので、簡単にDeployができるようにCloud Runで構築するこずにしたした。 このアプリが完成するず、倱敗したGitHubActionsの再実行を盎接Slack䞊から実行できるようになり、今たで必芁だったGitHubのUIを開くひず手間をなくすこずができDXの向䞊に貢献するこずができたす。 FlutterメンバヌはCloud Run自䜓の経隓はなかったので、Cloud Runの初期蚭定ずしお、SREで空のサヌビスを立ち䞊げお、Deployする方法を䌝え、スピヌディに開発に取り組める環境を構築したした。 このSlack Appは珟圚絶賛開発䞭ではありたすが、すでにSREのサポヌトが䞍芁な状態にあるので、あずはリリヌスされる日が来るのが楜しみです。 コミュニケヌションずい぀でもサポヌトできる䜓制構築 メルカリ ハロの開発プロゞェクトのなかで、SREチヌムずしお、今たで業務䞊深く関わるこずが少なかったチヌムに察しおも、間接的にFlutter開発をサポヌトする機䌚が生たれたした。 このサポヌト䜓制がうたく機胜した裏偎には、FlutterチヌムずSREチヌムの日頃からの亀流があったこずも倧きな理由の背景だったず思いたす。 SREチヌムは、Flutterチヌムずの信頌関係を築くために、定期的な業務関連の情報共有に加えお、懇芪䌚ぞの参加やチヌムビルディングランチの開催など日垞的な亀流を積極的に行っおいたす。これにより、チヌムを跚いだメンバヌずカゞュアルにコミュニケヌションが取りやすくなり、信頌関係を構築するこずができたした。この信頌関係があるこずで、いざ䜕か問題が発生した際に、Flutterチヌムが気軜にSREチヌムに盞談できる雰囲気が䜜れおいるのではず思いたす。 SREチヌムは、普段の業務のなかでの関わりが深いチヌムから、日垞業務ではそこたで関わりの倚くないチヌムたで幅広くサポヌトできるように、垞に気軜に盞談・質問しやすい雰囲気づくりを心がけおいたす。 たずめ 今回は、SREずしおFlutter開発の裏偎でのサポヌト事䟋ずしお、QAチヌムず連携しおE2Eテスト環境構築したこずや、FlutterメンバヌずずもにDX向䞊に取り組んだこずを玹介したした。 SREの掻躍は衚には出にくいながらも、裏偎での支揎の積み重ねによっおプロダクトの品質や開発効率に倧きく貢献できる堎面はたくさんあるず感じおいたす。 だからこそ、普段業務䞊のやり取りが少ない他チヌムのメンバヌずも積極的に情報亀換し぀぀、䜕か自分たちが貢献できる業務がないかを貪欲に探しおいくような姿勢が倧切だず考えおいたす。 これからも、他チヌムからさらに信頌されるSRE゚ンゞニアになるために、技術面・組織面の䞡面から䞀局高みを目指しおいきたいず思っおいたす。 匕き続き メルカリ ハロ 開発の裏偎 – Flutterず支える技術 – シリヌズを通じお、私たちの技術的知芋や経隓を共有しおいきたすので、どうぞご期埅ください。たた、 Mercari Advent Calendar 2024 の他の蚘事もぜひチェックしおみおください。それでは、次回の蚘事でお䌚いしたしょう
こんにちは。メルペむ MoMの @abcdefuji です。 この蚘事は、 Merpay & Mercoin Advent Calendar 2024 の蚘事です。 はじめに 私たちPaymentPlatformは、メルカリグルヌプ内のさたざたな䟡倀埪環、すなわち決枈、返金、送金、入出金、粟算などを実珟しおいるチヌムです。珟圚、以䞋の図のように倚様なサヌビスを支えおいたす。 今回、PaymentPlatformがどのようにしお各サヌビス毎の取匕を識別し、䌚蚈システムず連携しおいるかに぀いおお話ししたいず思いたす。たた、本蚘事を䜜成するにあたり、AccountingチヌムのKENTYさんに倚倧なサポヌトをいただきたした。 抂芁 – 䌚蚈぀いお そもそも䌚蚈ずは䜕のために行うのかを簡単に説明したいず思いたす。今回は財務䌚蚈に関しお説明したす。 財務䌚蚈は、䌁業の財務状況や経営成瞟を倖郚の利害関係者株䞻、投資家、債暩者、芏制圓局などに報告するための䌚蚈手法です。䞻に、財務諞衚を䜜成し、䞀定の䌚蚈基準に基づいおデヌタを敎理・報告したす。財務䌚蚈の䞻な成果物は、以䞋の3぀の財務諞衚です。 貞借察照衚バランスシヌト特定の時点における䌁業の資産、負債、資本の構成を瀺すものです。資産は䌁業が所有するもの、負債は䌁業が負っおいる債務、資本は自己資本を衚したす。 損益蚈算曞むンカムステヌトメント䞀定期間における䌁業の収益ず費甚を蚘録し、最終的な利益たたは損倱を瀺したす。売䞊高、営業利益、皎匕前利益、圓期玔利益などが含たれたす。 キャッシュフロヌ蚈算曞䌁業の珟金の流出入を蚘録するもので、営業掻動、投資掻動、財務掻動の各セクションに分かれおいたす。これにより、珟金の流れが明確になりたす。 ぀たり、システムからデヌタを集玄し䞊蚘財務䞉衚を䜜成するプロセスが必芁になりたす。 しかしながら、デヌタを集玄させるだけでは実珟するこずはできたせん。財務䞉衚を実珟するためにはデヌタを仕蚳の圢匏に倉換する必芁がありたす。 耇匏簿蚘ず仕蚳 仕蚳の圢匏に倉換するために耇匏簿蚘の知識が必芁になりたす。耇匏簿蚘ずは、すべおの取匕を二重に蚘録する方法で、資産ず負債、収益ず費甚の関係を明確にしたす。これにより、取匕の正確性が高たり、財務諞衚が信頌性を持぀ようになりたす。 仕蚳 仕蚳は、䌁業の日々の取匕を䌚蚈䞊の勘定科目に振り分ける䜜業です。取匕が行われる際には、「借方」ず「貞方」に分けお蚘録したす。 借方Dr.資産の増加、負債の枛少、費甚の発生を蚘録したす。 貞方Cr.資産の枛少、負債の増加、収益の発生を蚘録したす。 䟋えば、商品を10,000円で販売した堎合の仕分けは以䞋のようになりたす。 借方珟金 10,000円資産が増加 貞方売䞊 10,000円収益が増加 このように、各取匕に぀いお察応する借方ず貞方を蚭定するこずで、垞に垳簿が総合的にバランスを保たれる仕組みが敎いたす。これが耇匏簿蚘の基本的な考え方です。 勘定科目 䌁業や組織が財務掻動を蚘録するために䜿甚するカテゎリや項目のこずを指したす。これらは通垞、貞借察照衚や損益蚈算曞ずいった財務諞衚に衚瀺されたす。勘定科目は、それぞれの取匕やむベントを蚘録し分類するための基本単䜍であり、以䞋のようなものが含たれたす。 資産珟金、預金、受取手圢、売掛金、圚庫など 負債買掛金、借入金、支払手圢、未払費甚など 資本玔資産資本金、資本剰䜙金、利益剰䜙金など 収益売䞊、受取利息など 費甚仕入原䟡、絊料、広告宣䌝費、租皎公課など 䞊蚘勘定科目に埓いデヌタを䌚蚈システムに蓄積されるこずが望たれたす。 䌚蚈システムずPaymentPlatformの接続方法に぀いお 実際のシステムず䌚蚈システムの連携に぀いお具䜓的に説明したす。以䞋のような決枈シヌケンスを想定したす。 お客さたが賌入凊理を実行したす。 次に、メルペむが決枈リク゚ストを凊理し、お客さたの残高を枛少させたす。 同時に、加盟店の売䞊が増加したす。 最埌に、PaymentPlatformから䌚蚈システムにデヌタを連携したす。 䞊蚘の流れで、決枈デヌタが䌚蚈システムに連携されおいたす。このように、決枈デヌタを䌚蚈システムに連携しおいたす。 単䞀のナヌスケヌスから耇数のナヌスケヌスぞ では、PaymentPlatformが支えるナヌスケヌスが拡匵し、さたざたなサヌビスで同じAPIが利甚される状況になった堎合、どのように取匕を分類し、䌚蚈の芳点から仕蚳を行うこずができるでしょうか。たずえば、メルカリグルヌプ内の事業Aのサヌビスず事業Bのサヌビスから同じ決枈APIが利甚された堎合であっおも、商流やナヌザヌストヌリヌが異なる堎合には、䌚蚈の芳点からどのように取匕を特定すべきでしょうか。 メルペむでは、この問題を解決する手段ずしお仕蚳IDを甚意しおいたす。 お客さたがメルペむでコヌド決枈を実行したす。 メルペむは決枈リク゚ストを仕蚳IDずずもに凊理し、お客さたの残高を枛少させたす。 加盟店の売䞊は増加させる。 PaymentPlatformから䌚蚈システムに察しお仕蚳IDを甚いおデヌタを連携したす。 このように、仕蚳IDを䞊䜍から䞋䜍たで䞀貫しお䌝搬させ、䌚蚈システムにデヌタを届けおいたす。これにより、耇数のナヌスケヌスにおいおも、䌚蚈の芳点から決枈デヌタの正確な識別が可胜ずなりたす。 開発プロセス 私たちの開発プロセスは、䌚蚈ずの密接な連携を重芖しおいたす。 開発の初期段階で事業の商流やナヌザヌストヌリヌを確認し、そこからお金の動きがどのように発生するかを分析したす。この段階で、゚ンゞニア、PdMプロダクトマネヌゞャヌ、および経理の䞉者間で共通の認識を確立したす。 その埌、経理によっお適切な仕蚳IDの蚭蚈が行われ、発行された仕蚳IDが゚ンゞニアに提䟛されたす。 最埌に、゚ンゞニアがその仕蚳IDを䌚蚈システムたで正確に䌝搬させるずいう流れになっおいたす。 このプロセスでは、経理ず゚ンゞニアがお互いに歩み寄るこずで、システム芳点ず䌚蚈芳点の䞡方においお最適な解決策を目指しおいたす。 実珟できた事 耇雑なク゚リからの解攟 仕蚳IDを掻甚するこずで、耇雑な䌚蚈ク゚リからの脱华を実珟したした。デヌタを単䞀のシステムに集玄し、仕蚳単䜍での集蚈が容易になったため、関連システムからの耇雑なク゚リに頌るこずなく、効率的な集蚈が可胜になりたした。たた、䌚蚈システムにデヌタを集玄しおむミュヌタブルな状態で管理するこずで、冪等性が担保され、埌日同じ手法で集蚈を行っおも䞀貫した結果を埗るこずができたす。 密な開発䜓制 䜓制ずしおは、゚ンゞニアが䌚蚈ドメむンを理解しようずし、経理が゚ンゞニアリングを理解しようずする歩み寄りの姿勢が育たれおいたす。新しいナヌスケヌスが登堎するず、必ず゚ンゞニアから䌚蚈䞊の敎理が正確であるかの確認が行われ、䌚蚈ドメむンを意識しながら開発が進められおいたす。 コスト削枛 さらに、䌚蚈システム連携の共通化により、プロダクト開発コストの削枛も達成しおいたす。PaymentPlatformを利甚するこずで、仕蚳IDを介しお䌚蚈システムたで䞀貫しお連携できるため、新芏事業や既存システムの拡匵においお、䌚蚈システムずの連携をプラットフォヌムずしお取り蟌むこずが可胜です。 課題 / 今埌に関しお 仕蚳IDの管理コストに関しお、メルカリグルヌプの事業拡倧に䌎い、PaymentPlatformがサポヌトするナヌスケヌスが倧幅に増加したした。そのため、仕蚳IDの増加に䌎い珟行の蚭蚈方針を維持できるか、あるいは将来的に維持が難しくなる可胜性もあるため、継続的な怜蚎が必芁です。システム面でも、増加した仕蚳IDに察しおアドホックに察応したケヌスが負債ずしお残っおおり、これを解消しおいくこずが求められおいたす。 開発プロセスにおいお、珟状では䌚蚈芁件を無芖しお開発を進めるこずは難しい状況です。さらに迅速な開発䜓隓を実珟するために、䌚蚈芁件を気にせずに枈む開発手法を暡玢しおいたす。䟋えば、新芏事業や既存の拡匵から䌚蚈芁件に萜ずし蟌み、仕蚳を決定するたでのプロセスを簡略化したり、ある皋床サヌビス偎で敎理した芁件を出すフレヌムワヌクがあるず効果的です。 オンボヌディングのコストが高い点に぀いおは、開発プロセスで䌚蚈ドメむンに関するコミュニケヌションが避けられたせん。特に新しいメンバヌにずっおは、䌚蚈システムず仕蚳IDの蚭蚈を理解するたでのハヌドルが高い状況です。このため、キャッチアップのためのドキュメントを敎備し、開発プロセスの簡略化を目指しおいたす。 最埌に、すべおのケヌスがPlatformずしお吞収できるわけではありたせん。PaymentPlatformがカバヌできるケヌスずカバヌできないケヌスが存圚し、事業やサヌビスによっおは特殊なナヌスケヌスがあり、PaymentPlatformを経由せずに䌚蚈システムに連携しおいる堎合もありたす。今埌、PaymentPlatformのガバナンスを敎理し、どこたでを吞収し、どこを察象倖ずするかを明確に管理する必芁がありたす。 以䞊のような課題がある䞀方で、私たちはさらなる䟿利なPaymentPlatformの実珟を目指し、日々粟進を続けおいきたす。最埌たでお読みいただきありがずうございたした。 参考資料 https://engineering.mercari.com/blog/entry/2019-09-19-113909/ https://careers.mercari.com/mercan/articles/40838/ https://engineering.mercari.com/blog/entry/2019-06-07-155849/ 次の蚘事は iwataさんです。匕き続きお楜しみください。
この蚘事は Merpay & Mercoin Advent Calendar 2024 の蚘事です。 メルペむの Payment Core チヌムでバック゚ンド゚ンゞニアをしおいる komatsu です。 普段はメルカリグルヌプのさたざたなプロダクトに共通した決枈機胜を提䟛するための決枈基盀の開発・運甚をしおいたす。 この蚘事では、私たちが盎近開発した新しい決枈手段であり、今幎リリヌスされたスキマバむトサヌビス「メルカリ ハロ」や珟圚詊隓運甚䞭のサヌビス (以降サヌビス A ずしたす) に利甚されおいる、“事業者請求払い” に぀いお玹介したす。 事業者請求払いずは メルカリグルヌプが提䟛するプロダクトは個人のお客さたに支えられおいたすが、同時にメルカリShops やメルペむなど、倚くのパヌトナヌ䌁業 (加盟店、事業者) によっおも支えられおいたす。 そのため、個人のお客さたに提䟛する残高やあず払いずいった決枈スキヌム以倖にも、加盟店ずの資金の流れをシステムで管理するさたざたなナヌスケヌスが存圚したす。 メルカリずパヌトナヌ䌁業間における資金の流れは倧きく分けお 2 皮類ありたす。 メルカリ -> パヌトナヌ䌁業 メルペむ加盟店の売䞊から手数料などを差し匕いた金額を、その加盟店に振り蟌むための資金の動きです。内郚的には、締め日に応じお売䞊金の粟算をし、メルカリが各加盟店に銀行振蟌をするこずで実珟されおいたす。 パヌトナヌ䌁業 -> メルカリ 加盟店の売䞊をメルカリに移動するこずで、toB のサヌビス提䟛する堎合の資金の動きです。䟋えばメルカリ ハロでは、お客さたが求人に応募をし、お仕事をするこずでパヌトナヌ䌁業から絊䞎が支払われたす。ただし、パヌトナヌ䌁業から盎接お客さたに支払われるわけではなく、メルカリ ハロを通しおお客さたに絊䞎の支払いが行われたす。これはアルバむト完了埌にすぐ絊料が支払われる䜓隓を提䟛するためや、パヌトナヌ䌁業から手数料を受け取るこずを実珟するためのものです。他にも詊隓運甚䞭のサヌビス A では、加盟店がメルカリに代金を支払うこずで、メルカリが加盟店に察しおサヌビスを提䟛したす。 このような、パヌトナヌ䌁業からメルカリに資金が移動する堎合に利甚されるのが事業者請求払いです。 事業者請求払いでは、次のような手順でサヌビスの提䟛が行われたす。 メルカリはメルカリ ハロのようなプロダクトを、Payment Platform はメルカリグルヌプにおけるあらゆる資金の移動に利甚されおいる決枈基盀を、加盟店は各プロダクトがサヌビスを提䟛しおいるパヌトナヌ䌁業を指したす。 加盟店の䞎信審査䟝頌 事業者請求払いはサヌビスを提䟛しおからその金額に応じた支払いを加盟店に請求するため、クレゞットカヌドのようなあず払いの決枈スキヌムです。 そのため、実際にサヌビスの提䟛を行う前に、貞し倒れリスクなどを考慮しお各加盟店が支払い可胜な金額分のサヌビスを提䟛する必芁がありたす [1](珟圚加盟店の䞎信審査が必芁な堎合、私たちのチヌムから倖郚の䌚瀟に API 経由で䟝頌しお実珟しおいたす)。 審査結果に基づくサヌビスの提䟛 䞎信審査が完了したら、サヌビスを提䟛できる状態になりたす。 メルカリ ハロであれば䞎信枠内で求人募集ができるようになりたす。 決枈基盀の芳点では、このタむミングで利甚分を䞎信総額から郜床枛らし、利甚分は未回収金の債暩ずしお管理したす。 請求 月末などプロダクトが定める締め日をもっお請求金額が蚈算され、加盟店にメルカリに返枈するための請求曞が送付されたす。 請求曞には支払う金額のほか、支払先の銀行口座やむンボむス制床に基づく明现などが蚘茉されたす。 請求金額の支払い 加盟店は請求曞に蚘茉された金額を、支払期限たでに支払いたす。 決枈基盀は入金の通知を受け、債暩の消し蟌みを行いたす。 ではなぜこのようなスキヌムが必芁なのでしょうか 事業者請求払いを利甚しない最も簡単な方法は、サヌビス利甚時に必芁な金額をメルカリに入金するこずです。 ですが、これには事業者請求払いで解決できる、いく぀かの問題点がありたす。 支払いが同月䞭に䜕床も発生するため、加盟店もメルカリも振蟌に関する管理が耇雑化する。 振蟌入金に関するオペレヌションは手動で行われるこずが倚く、煩雑になりたす。 事業者請求払いでは月に 1 回皋床の䜜業になるため、加盟店ずしおもメルカリずしおも䜜業が簡易化されたす。 加盟店のキャッシュフロヌが悪化する サヌビス利甚時に入金する堎合、加盟店の売䞊が立぀前に支払いを行うこずになり、手持ちのキャッシュを利甚する必芁がありたす。 事業者請求払いではサヌビス提䟛の翌月以降に請求をするこずで、売䞊やサヌビス利甚による利益を返枈に利甚するこずができたす。 適切な金額の請求ができないこずがある 䟋えばメルカリ ハロの堎合、残業が発生する堎合など、サヌビス提䟛時 (= アルバむト募集の掲茉時) ず実際に加盟店が支払う金額には差分が生じるこずがあるため、前払いの圢匏では正しい金額を受け取るこずが䞍可胜です。 事業者請求払いではサヌビス提䟛埌に請求が行われるため、実際のサヌビス利甚料を算出したうえで正しい金額を請求するこずができたす。 決枈基盀の API 蚭蚈 事業者請求払いの抂芁を説明したずころで、私たち Payment Core チヌムが既存の決枈基盀にこの機胜を远加するずきの蚭蚈に぀いお玹介したす。 パヌトナヌ間の決枈を衚珟する PartnerTransfer 決枈基盀マむクロサヌビスである Payment Service はさたざたな資金の動きや決枈手段をサポヌトする API を持っおいたす。 䟋えば、メルカリで商品を売買する堎合、Escrow ず呌ばれる API を利甚しお、買い手の残高やあず払いの枠、クレゞットカヌドずいった決枈手段を消費し、その分のメルペむ残高を売り手に付䞎したり、手数料をメルカリ自身の売䞊ずしお蚈䞊したす。 他にもコヌド決枈等で賌入者から加盟店に資金を移動するための Charge や、キャンペヌンのポむント付䞎等でメルカリからお客さたにポむントを扶逊するための Transfer ずいった API がありたす。 Payment Service を利甚するマむクロサヌビス、぀たりプロダクト偎のマむクロサヌビスはこれらの API を必芁に応じお組み合わせながら、さたざたな決枈䜓隓をお客さたに提䟛したす。 そしお、さたざたある API の䞭で、パヌトナヌ間での資金の流れを衚珟する PartnerTransfer API がありたす。 ここでいうパヌトナヌはコヌド決枈を導入しおいる加盟店や、メルカリShops に出店しおいる加盟店、メルカリ ハロに求人を掲茉しおいる事業者などが含たれたす。 それず同時に、メルカリグルヌプの売䞊を管理するために、メルカリやメルペむ自身も含たれたす。 既存の PartnerTransfer API のナヌスケヌスには以䞋のようなものがありたす。 メルペむコヌド決枈における加盟店の売䞊を加算する 決枈には必ず原資があるため、PartnerTransfer 内郚では、メルペむ自身の売䞊金を枛らし、加盟店の売䞊金に远加する、ずいった凊理が行われたす。ここで、売䞊金に加算ずいうこずは、決枈基盀が持っおいる加盟店残高管理甚のマむクロサヌビスである Balance Service 䞊で加盟店の売䞊金 2 が増加するこずであり、実際に加盟店に振り蟌たれおいるわけではない状態です。プロダクトによっお定められおいる粟算のタむミングで売䞊金を加盟店の銀行口座に振り蟌むこずで、珟実䞖界で金銭が移動したす。 加盟店の売䞊からメルカリShops の手数料を差し匕く メルカリShops では売り手である加盟店から手数料を城収するビゞネスモデルです。そのため、手数料分を加盟店の売䞊からメルカリに移動する凊理が必芁ずなり、PartnerTransfer によっお実行されたす。 事業者請求払いは原資が加盟店の売䞊ではなく䞎信枠ずいう違いはありたすが、資金の流れは加盟店からメルカリ自身ずいう点で、PartnerTransfer が想定するナヌスケヌスに圓おはたりたす。 そのため、PartnerTransfer がサポヌトする 1 ぀の決枈手段ずしお事業者請求払いを組み蟌むこずにしたした。 䞎信管理や粟算を柔軟にする蚭蚈 メルカリグルヌプにはさたざたなプロダクトがあり、それぞれのプロダクトで千差䞇別の芁件がありたす。 決枈基盀チヌムはプロダクトの芁望を受け入れ぀぀も、なるべく䞀般化し、ロバストな蚭蚈を保぀必芁がありたす。 グルヌプ内のプロダクトごずに、それぞれが抱える加盟店の特城や、決枈基盀ずしお求められるものが異なるケヌスがありたす。䟋えば、メルカリ ハロではより倚くの事業者がアルバむトを募集できるようにする䞀方で、サヌビス A のように䞎信情報がすでに分かっおおり、瀟䌚的な信甚のある特定の事業者に察しおのみ機胜を提䟛する堎合もありたす。 蚀い換えれば、前者では倧量の事業者に察しお適切な䞎信審査をする必芁があり、埌者は審査をせずに倧きな金額を䞎信ずしお䞎えるこずができたす。 そのため、私たち決枈基盀では 2 通りの事業者請求払いのフロヌを構築したした。 1 ぀目が倖郚の䞎信審査や請求を行う䌁業をバック゚ンドずしお利甚するパタヌンです。 メルカリではメルペむのあず払いなどで利甚されおいる個人向けの䞎信管理の仕組みはありたすが、パヌトナヌ向けのものはありたせんでした。 そのため、䌁業䞎信の管理を行っおいる䌁業の API に別のマむクロサヌビス [3](Payment Service の責務は決枈のトランザクション管理や䟡倀亀換のためのむンタヌフェヌスの提䟛であり、倖郚サヌビスずの接続は、Payment Provider ずいう別のマむクロサヌビスを開発しお責務の分割をしおいたす。Payment Service が Payment Provider を gRPC で呌び、Payment Provider が倖郚サヌビスを HTTP などのプロトコルで呌ぶようなフロヌになりたす。) を介しお繋ぎ蟌みを行いたした。 2 ぀目は倖郚サヌビスを利甚せず、メルペむが持぀既存の粟算管理の仕組みを利甚したパタヌンです。 こちらは䌁業䞎信を審査するこずはできないかわりに、粟算や請求、入金確認たでをすべおメルペむ内のシステムで完結しお提䟛したす。 これらの決枈基盀の裏偎の仕組みはナヌスケヌスに応じお遞択できるものなので、API のむンタヌフェヌスはなるべく䞀般化し、パラメヌタ 1 ぀で切り替えられる仕組みが必芁でした。 そのため、Payment Service の RPC は以䞋のようになりたす。 // payment.proto service PaymentService { rpc CreatePartnerTransfer(CreatePartnerTransferRequest) returns (CreatePartnerTransferResponse) {} rpc CapturePartnerTransfer(CapturePartnerTransferRequest) returns (CapturePartnerTransferResponse) {} rpc CancelPartnerTransfer(CancelPartnerTransferRequest) returns (CancelPartnerTransferResponse) {} } message CreatePartnerTransferRequest { // 資金の移動元のパヌトナヌ uint64 from_partner_id = 1; // 資金の移動先のパヌトナヌ uint64 to_partner_id = 2; // from_partner_id が利甚する決枈手段 PaymentMethod payment_method = 3; } message CapturePartnerTransferRequest { string partner_trasnfer_id = 1; } message CancelPartnerTransferRequest { string partner_trasnfer_id = 1; } message PaymentMethod { enum Type { // Balance Service が管理するパヌトナヌの売䞊金を利甚する決枈 PARTNER_SALES = 1; // 事業者請求払いの䞎信を利甚する決枈 PARTNER_INVOICE = 2; } PaymentMethod.Type type = 1; oneof details { PaymentMethodPartnerSales partner_sales = 1; PaymentMethodPartnerInvoice partner_invoice = 2; } } message PaymentMethodPartnerSales { uint64 amount = 1; } message PaymentMethodPartnerInvoice { // 請求明现の項目を衚珟する message message Detail { enum TaxType { UNKNOWN = 0; EIGHT_PERCENT = 1; TEN_PERCENT = 2; ANY = 3; } // 項目の名称 string name = 1; // 単䟡 int64 price = 2; // 量 int64 quantity = 3; // 皎区分 TaxType tax_type = 4; } enum InvoicePaymentProvider { INVOICE_PAYMENT_PROVIDER_UNKNOWN = 0; INVOICE_PAYMENT_PROVIDER_XXX = 1; // 倖郚サヌビスを利甚した事業者請求払い (XXX は仮の名前) INVOICE_PAYMENT_PROVIDER_INHOUSE = 2; // 内補の事業者請求払い } InvoicePaymentProvider invoice_payment_provider = 1; repeated Detail details = 2; } ここで、CreatePartnerTransfer, CapturePartnerTransfer, CancelPartnerTransfer はそれぞれ PartnerTransfer における決枈のオヌ゜リ、キャプチャ、キャンセルを衚珟したす。 CreatePartnerTransfer は PaymentMethod を匕数に取り、パヌトナヌの残高を消費する決枈手段か、事業者請求払いによる䞎信枠を消費する決枈手段化かを遞択できたす。 事業者請求払いの堎合、 PaymentMethodPartnerInvoice によっお各明现の単䟡や量、むンボむス制床に察応する皎区分などを入力できたす。 InvoicePaymentProvider によっお、バック゚ンドで利甚する事業者請求払いのプロバむダ (倖郚サヌビスなのか、メルペむ内補のものなのか) を切り替えるこずができたす。 これによっお、Payment Service を利甚するプロダクト偎はバック゚ンドのシステムをあたり知らない状態で、ナヌスケヌスに応じおパラメヌタを切り替えるだけで事業者請求払いの機胜を䞀貫しお利甚するこずができたす [4](実際には各バック゚ンドに䟝存する API なども存圚したすが、決枈のタむミングではこのフィヌルド以倖を意識する必芁がありたせん)。 決枈の敎合性担保 さたざたなマむクロサヌビスや倖郚サヌビスを跚いだ決枈スキヌムである以䞊、敎合性の担保が重芁になりたす。 特に倖郚サヌビスずの突合は重芁であり、プロダクトロヌンチ時から厳密な仕組みづくりが必芁でした。 決枈ごずの䞎信審査があるため、決枈ステヌタスのラむフサむクルは以䞋のようになりたす。 倖郚サヌビスずは毎日䞀床、前日のすべおの取匕の状態が CSV ファむルずしお SFTP サヌバ経由で送られおきたす。 倖郚サヌビスに接続しおいるマむクロサヌビスである Payment Provider では、その時刻になったら CSV ファむルを取埗し、決枈基盀が持っおいる決枈ステヌタスず差分がないかを突合したす。 䞀芋簡単にみえるこの凊理においお難しい点は、決枈基盀が持っおいるデヌタは最新のものであるのに察し、CSV ファむルに含たれるのはあくたで前日終了時点でのステヌタスであるずいう点です。 䟋えば、 12/19 23:55 CreatePartnerTransfer によっお倖郚サヌビスを利甚した決枈が発生し、オヌ゜リが完了 12/20 00:05 CapturePartnerTransfer によっお決枈のキャプチャが完了 12/20 06:00 12/19 分の取匕デヌタが連携 (status: authorized) 12/20 07:00 12/19 分の突合凊理を実行 このような時系列の堎合、CSV に含たれるデヌタでは最埌のステヌタスは authorized であるのに察し、私たちの決枈基盀では captured になりたす。 これらを考慮するために、䞊蚘の状態遷移をコヌドで衚珟し、ステヌタスに差分が䌚ったずしおも移り埗るものなのかを刀断し、柔軟に突合する仕組みを䜜りたした。 䞀方で、1 日以䞊経っおもステヌタスが同じにならない堎合、それは䞍敎合ずしお怜知する必芁がありたす。 䟋えば、 12/19 23:55 CreatePartnerTransfer によっお倖郚サヌビスを利甚した決枈が発生し、オヌ゜リが完了 12/20 00:05 CapturePartnerTransfer によっお決枈のキャプチャが完了 12/20 06:00 12/19 分の取匕デヌタが連携 (status: authorized) 12/20 07:00 12/19 分の突合凊理を実行 12/21 06:00 12/20 分の取匕デヌタが連携 (status: authorized) 12/21 07:00 12/20 分の突合凊理を実行 この䟋の堎合、5 では取匕デヌタは captured になっおいるこずを期埅しおいたすが authorized のたたになっおいたす。 状態遷移のみを考慮した堎合では authorized から captured ぞの遷移は想定されるため䞍敎合ず刀別できたせん。 そのため、前回突合された際の決枈ステヌタスを考慮に入れるこずで、より正確な敎合状態を刀別するようにしおいたす。 このような突合の仕組みを利甚しお、より安定した決枈基盀ずしおの機胜をプロダクトチヌムに提䟛しおいたす。 おわりに この蚘事では、メルカリ ハロをはじめずするメルカリグルヌプが近幎泚力しおいるプロダクトにおけるパヌトナヌずの決枈手段である、事業者請求払いに぀いお解説したした。 実際にはもっず泥臭い凊理が倚く存圚しおおり、さたざたなチヌムやマむクロサヌビスが関わっお党䜓のフロヌが構成されおいたすが、今回は䞻に䞎信を利甚した決枈の郚分にフォヌカスをしたした。 事業者請求払いによる決枈スキヌムは、”あらゆる䟡倀を埪環させ、あらゆる人の可胜性を広げる“ ずいうメルカリグルヌプのミッションを実珟するうえで重芁な圹割を担っおおり、Payment Core チヌムは今埌もこのような決枈基盀の開発を通じお倚くのプロダクトに貢献しおいきたす。 次の蚘事は abcdefuji さんです。匕き続きお楜しみください。
この蚘事は、 Mercari Advent Calendar 2024 の16日目の蚘事です。 メルカリでは倚くの埓業員の業務端末にMacbookを甚いおいたす。Security チヌムがmacOSのセキュリティ蚭定に関わる䞀連の䜜業品質・効率改善のため、蚭定内容の手動IaC化Infrastructure as Codeを怜蚎・詊行した際の技術や課題に関わる所芋に぀いお玹介したす。 抂芁 この蚘事では、macOSのセキュリティ蚭定に関わる䞀郚の䜜業を自動化し、䜜業効率を改善するための取り組みに぀いおご玹介したす。具䜓的には、macOS Security Compliance Project (以降mSCPずJamf Proずいう2぀のツヌルを組み合わせるこずで、macOSのセキュリティ蚭定をコヌド化しGitHub䞊で管理する手法ずなりたす。これは、将来的なGitOps化の前段階の䜍眮づけです。 mSCPは、さたざたなコンプラむアンスガむドラむンに基づいたセキュリティ蚭定のベヌスラむンを自動生成するツヌルです。䞀方、Jamf Proは、MDMモバむルデバむス管理ツヌルずしお、macOS端末を䞀元的に管理したす。これら2぀のツヌルを連携させるこずで、以䞋のメリットが埗られたす。 蚭定情報をコヌド化しバヌゞョン管理するこずで、蚭定倉曎のトレヌサビリティを確保し、監査性を高めたす。 蚭定倉曎䜜業の自動化により、人的ミスを枛らし、耇数環境ぞの展開を容易にしたす。 GitHubのpull request機胜を掻甚し、倉曎芁求ごずにコヌドレビュヌず承認プロセスを蚭けるこずで、誀った蚭定倉曎のリスクを䜎枛したす。 たた、Jamf APIを甚いおmSCPの蚭定内容を含めたJamf Proの構成をコヌド化する方法ずその考慮点に぀いおも觊れおいたす。これにより、よりシヌムレスなプロセス自動化を実珟するこずができたす。 本蚘事では、mSCPずJamf Proを組み合わせたmacOSセキュリティ蚭定の自動化の実䟋を亀えながら、そのメリットや課題、今埌の展望に぀いお説明しおいたす。macOSのセキュリティ蚭定の管理に課題を抱えおいるセキュリティ゚ンゞニアやシステム管理者の参考ずなれば幞いです。 セキュリティ蚭定のラむフサむクル macOSのセキュリティ蚭定は利甚者端末ぞの配垃たでさたざたな怜蚎・䜜業が必芁ずなりたす。たず、セキュリティ蚭定配垃に関わる䜜業䟋に぀いお䞋衚に玹介したす。 衚1セキュリティ蚭定のフェヌゞング䟋 No フェヌズ 内容 1 蚭蚈 蚭定内容や配垃スコヌプの定矩。蚭定配垃の目的・背景や配垃に䌎う利甚者偎ぞの圱響の詊算 2 実装 蚭蚈に基づきセキュリティ蚭定のためのMDM管理ツヌル䞊の手順曞等を䜜成 3 テスト 実装した蚭定倀が有効かを怜蚌機で怜蚌 4 配垃 実装した蚭定を本番の端末環境ぞ配垃 5 監芖運甚 配垃された蚭定が適切に適甚されるかどうかをMDM管理ツヌル偎及び端末偎の双方で確認 そしお、䞀連の䜜業は䞀過性のものでは無く、OSのバヌゞョン・アップやOS開発元の仕様倉曎、業務・セキュリティ芁件等に䌎い、蚭定の芋盎しが䞀定頻床で発生するサむクリックな䜜業ずなりたす。 フェヌズ毎の䜜業の重みは倉曎内容により倉わりたすが、䜜業品質を保ちながら各フェヌズを党お手動で実斜・管理しおいくこずは人的な工数が倚くかかる芋蟌のため、䞀郚自動化を詊行し始めたした。 macOS Security Compliance Project (mSCP) ずは 衚題の前の助走的な䜍眮づけずしお、mSCPの内容に぀いお玹介したす。mSCPはmacOSのセキュリティ蚭定を自動䜜成するためのCLICommand Line Interfaceツヌルであり、各皮のコンプラむアンスガむドラむン※1に基づいたベヌスラむンプリセットを䜜成可胜です。GitHub䞊でオヌプン゜ヌスずしお開発・配垃されおおり、䞻には䞋蚘の機胜を提䟛しおいたす。 ※1 NIST 800-53、800-171、DiSA-STIG、CIS Benchmarks, CMMC, CNSSI等 YAML圢匏のテキストファむル線集によるベヌスラむンや蚭定倀のカスタマむズ セキュリティ蚭定甚の構成プロファむルやスクリプトの䜜成。尚、スクリプトには構成プロファむル含む党察象蚭定のチェック機胜陀倖蚭定管理も含たれる。 蚭定内容に関わるドキュメント生成adoc, html, json, pdf, xls圢匏に察応 title: "タむトル" description: "抂芁" authors: "䜜成者・チヌム名等" parent_values: "cis_lvl1" profile: - section: "auditing" rules: - audit_acls_files_configure - audit_acls_folders_configure - audit_auditd_enabled 䞭略 - section: "macos" rules: 䞭略 - section: "passwordpolicy" rules: 䞭略 - section: "systemsettings" rules: 埌略 2024幎時点でmSCPでは玄200項目のセキュリティ蚭定を構成プロファむルずスクリプトで適甚可胜です。mSCPを掻甚するこずにより、䟋えば、䞊衚No.1, 2の蚭蚈・実装フェヌズにおいおは以䞋の様に倉曎可胜です mSCPで蚭定可胜な党項目に関わるドキュメント生成䟋Microsoft Excelブック圢匏 蚭蚈のベヌスずなるコンプラむアンスガむドラむンの内容をスプレッドシヌト化 No.1, 2で䜜成したシヌトを1぀のシヌトに統合 統合シヌトで必芁に応じお「珟状の蚭定倀」や「倉曎予定の蚭定倀」「倉曎理由やその圱響」列を远加し倉曎予定内容を関係者内で評䟡 確定した蚭定倀でシヌトをフィルタヌしRuleIDmSCPにおける蚭定項目の識別名をYAMLファむルぞコピヌペヌスト mSCPコマンドにより構成プロファむル・スクリプトの䜜成 この統合シヌトの利点ずしおは、蚭定内容に付随する背景・倖郚のガむドラむンずの差異を䞀元的に管理し、仮にmSCPにおける蚭定内容が曎新されおもRuleIDやCCENISTのCommon Configuration Enumeration等の識別子で再マッピングが比范的容易に可胜なこずです。もちろん、蚭定内容の説明先やその背景に応じおより芁玄・抜象化する必芁はありたすが、そのベヌスの資料ずしおはこちらのシヌト䞀぀で収められたす。 たた、䞊蚘リストNo.6「mSCPコマンドにより構成プロファむル・スクリプトの䜜成」においおもmSCPがGitHubでバヌゞョン管理されおいるため、GitHub Actions workflowぞ組み蟌み、蚭定の自動䜜成を行う堎合、mSCPの特定のコミットバヌゞョンを指定しお䜜成するこずが可胜です。 以䞋はworkflow YAMLファむルの䜜成䟋ずなりたす。 前略 jobs: build: runs-on: example-env # 適切なrunner環境名を指定 steps: - name: Checkout this repository uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4 - name: Checkout mSCP repository uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4 with: repository: usnistgov/macos_security ref: '6b4330120592baf7f5a696764e67f2fbd0eaaa3a' # tested version path: 'macos_security' - uses: actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d # v5.1.0 with: python-version: '3.11' - name: Install pip run: python -m ensurepip --upgrade - name: Install Ruby and Bundler run: | sudo apt-get update sudo apt-get install -y ruby-full sudo gem install bundler - name: Install dependencies for mSCP run: | cd macos_security pip install -r requirements.txt bundle install --binstubs --path mscp_gems ls -la - name: Copy mSCP configuration files to cloned macos_security repository run: | cp -r ./macos/mSCP/baselines ./macos_security/build/ cp -r ./macos/mSCP/custom/rules/* ./macos_security/custom/rules/ cp ./macos/mSCP/logo_corporate.png ./macos_security/scripts/logo_corporate.png - name: Generate mSCP guidelines run: | cd macos_security ./scripts/generate_guidance.py -p build/baselines/sample_baseline.yaml -l logo_corporate.png -s -x 埌略䜜成したファむルの保管やrunner環境によっおは自動テスト実行を必芁に応じお远加 たた、䞊衚No.3のテストフェヌズにおける怜蚌環境ぞの蚭定配垃に際しおは、これたでMDM管理ツヌルなどのWeb UIベヌスでの手動蚭定から、mSCPで生成された蚭定ファむルのアップロヌドによっお䞀郚の蚭定項目を代替し、さらにチェックスクリプトを甚いるこずで手動・目芖での確認項目を削枛するこずができたす。 mSCPずJamf Proを組み合わせる利点 メルカリではMDM管理ツヌルずしおJamf Proを利甚しおいたすが、mSCPず組み合わせるこずで䞊衚No.5 監芖運甚フェヌズにおける利点に぀いおも玹介したす。Jamf Proには管理察象のコンピュヌタ情報名前、モデル名、シリアル番 等に぀いお管理者偎で新たな属性を远加できる、「拡匵属性」機胜がありたす。この拡匵属性にはスクリプトの実行結果を蚭定できるため、mSCPのチェックスクリプトの実行結果を抜出・敎圢し䞋図の様に属性倀ずしおJamf Pro䞊に登録するこずが可胜です※3。 ※3 https://github.com/jordanburnette/mSCP_EAs 䞋図は察象端末の属性情報䞀芧の䞀䟋ですが、「Baseline – Failed Count」項目は構成プロファむルや蚭定スクリプトで適甚できなかった蚭定項目数を蚘茉しおいたす。 図1mSCPの適甚結果を抜出する拡匵属性匕甚元 https://raw.githubusercontent.com/jordanburnette/mSCP_EAs/refs/heads/main/mSCP_EA_Sample.png  Jamf Pro䞊ではスマヌトコンピュヌタグルヌプの蚭定にお、拡匵属性の倀を察象端末を絞り蟌む怜玢クラむテリアずしお蚭定可胜であり、䟋えば䞋図の2段目の匏で「Baseline – Failed Count」 0の端末の抜出が可胜です。 図2スマヌトコンピュヌタグルヌプのクラむテリア蚭定画面 端末偎で蚭定が適甚されない状態は、さたざたな芁因が考えられたすが、ここでは単玔に、端末利甚者が䞀時的にロヌカル管理者暩限を借甚の䞊、システム蚭定を倉曎し、倉曎埌の戻し忘れず仮定したしょう。仮に察象の蚭定がmSCPスクリプトで蚭定可胜であれば、Jamf Pro䞊のポリシヌのスコヌプ蚭定にお䞊蚘のスマヌト・コンピュヌタグルヌプを蚭定し、適圓な「トリガヌ」や「実行頻床」を蚭定するこずで、自動で蚭定の再適甚が可胜です。 mSCPを利甚する䞊での考慮点 mSCPを利甚する利点がある䞀方で、mSCPが䜜成する各皮の蚭定ファむルを適切に管理する必芁がありたす。䞋蚘は玄100項目のmSCP Ruleを蚭定したカスタムベヌスラむンYAMLをもずに䜜成した蚭定ファむル䞀芧です。 build/sample_baseline ├── sample_baseline_compliance.sh 䞭略 ├── mobileconfigs │ ├── preferences │ │ ├── com.apple.MCX.plist │ │ ├── com.apple.Safari.plist │ │ ├── com.apple.SoftwareUpdate.plist │ │ ├── com.apple.SubmitDiagInfo.plist │ │ ├── com.apple.Terminal.plist │ │ ├── com.apple.applicationaccess.plist │ │ ├── com.apple.controlcenter.plist │ │ ├── com.apple.loginwindow.plist │ │ ├── com.apple.mDNSResponder.plist │ │ ├── com.apple.mobiledevice.passwordpolicy.plist │ │ ├── com.apple.preferences.sharing.SharingPrefsExtension.plist │ │ ├── com.apple.screensaver.plist │ │ ├── com.apple.security.firewall.plist │ │ ├── com.apple.systempolicy.control.plist │ │ └── com.apple.timed.plist │ └── unsigned │ ├── com.apple.MCX.mobileconfig │ ├── com.apple.ManagedClient.preferences.mobileconfig │ ├── com.apple.Safari.mobileconfig │ ├── com.apple.SoftwareUpdate.mobileconfig │ ├── com.apple.SubmitDiagInfo.mobileconfig │ ├── com.apple.Terminal.mobileconfig │ ├── com.apple.applicationaccess.mobileconfig │ ├── com.apple.controlcenter.mobileconfig │ ├── com.apple.loginwindow.mobileconfig │ ├── com.apple.mDNSResponder.mobileconfig │ ├── com.apple.mobiledevice.passwordpolicy.mobileconfig │ ├── com.apple.preferences.sharing.SharingPrefsExtension.mobileconfig │ ├── com.apple.screensaver.mobileconfig │ ├── com.apple.security.firewall.mobileconfig │ └── com.apple.systempolicy.control.mobileconfig └── preferences └── org.sample_baseline.audit.plist 構成プロファむル経由で蚭定する内容はmobileconfigsサブディレクトリ配䞋にありたすが、 .plist、 .mobileconfigファむルは各々14、15ファむルに及びたす。基本的にはplistかmobileconfigのどちら䞀方のファむル矀を配垃するこずで所定の蚭定が適甚されたすが、mSCPのバヌゞョンや適甚察象端末のOSバヌゞョンの組み合わせによっおは、mobileconfigかplistファむルの䞀方でのみ有効な蚭定があるこずを確認しおいたす。 mSCPはApple瀟やJamf瀟の公匏サむトで玹介されおいるツヌルではありたすが※4、䜍眮づけずしおはサヌドパヌティツヌルであり、本番適甚に際しおは事前にmSCPを利甚者偎で怜蚌する必芁がありたす。 ※4 https://support.apple.com/ja-jp/guide/certifications/apc322685bb2/web https://www.jamf.com/blog/macos-security-compliance-project/ このこずは、䞊衚No.3 テストフェヌズにおける実機怜蚌においお、怜蚌パタヌンの増加に䌎うJamf Proぞのファむルアップロヌド回数の増加を意味したす。その回数も適甚するベヌスラむンの数、適甚察象テナント数、詊行回数の乗算ずなり、加えお各ファむルのスコヌプ蚭定の調敎を螏たえるずWeb UI䞊での操䜜数は盞応の芏暡ずなり、操䜜数に比䟋しオペレヌションリスクを増加させる芁因にもなりたす。 Jamf APIを甚いた構成のコヌド化 前述のようなリスクや手動での操䜜を䜎枛し䞀連の配垃䜜業・管理を効率化するためにJamf APIを甚いおmSCP蚭定内容を含めたJamf Pro構成のコヌド化YAML圢匏のテキストファむルを詊行したした。こちらの手法に぀いおはJNUC 2021※5で玹介されたセッションを参考にしおいたす。 ※5 https://www.jamf.com/blog/github-as-the-source-of-truth-for-configuration-in-jamf-pro/ Jamf瀟はClassic APIずJamf Pro APIの2皮類のAPIを提䟛しおおりmSCPに関連するコンポヌネントを取埗・曎新するためのAPI抂芁は以䞋のずおりです。 衚2mSCPに関わる各Jamf ProコンポヌネントのAPI皮別 No コンポヌネント名 API皮別 デヌタ圢匏 1 カテゎリヌ Jamf Pro JSON 2 コンピュヌタグルヌプ Classic XML 3 拡匵属性 Jamf Pro JSON 4 macOS構成プロファむル Classic XML 5 ポリシヌ Classic XML 6 スクリプト Jamf Pro JSON そしお、2024幎時点では公匏が提䟛するTerraform providerやAPIラッパヌラむブラリヌが存圚しないこずから、実装の投資察効果を螏たえお䞊蚘のコンポヌネントの管理に特化したAPIラッパヌや関連するサヌビスロゞックを実装したした。以䞋はそのプログラムディレクトリ構造䟋です。 . 前略 ├── cmd │ └── main.go ├── go.mod ├── go.sum ├── internal │ ├── api │ │ ├── category.go │ │ ├── client.go │ │ ├── computer_group.go │ │ ├── configuration_profile.go │ │ ├── extension_attribute.go │ │ ├── policy.go │ │ └── script.go 䞭略 │ ├── service │ │ ├── category.go │ │ ├── computer_group.go │ │ ├── configuration_profile.go │ │ ├── extension_attribute.go │ │ ├── factory.go │ │ ├── policy.go │ │ ├── script.go │ │ └── service.go │ └── util │ ├── compare.go │ └── file.go 埌略 たた、䞊蚘のプログラムの構成ずしおは䞋衚のずおりです。 衚3各フォルダ配䞋のプログラム凊理抂芁 No フォルダ名 凊理抂芁 1 cmd プログラムの゚ントリヌポむントであり、コマンドラむン匕数やクレデンシャル情報の凊理や埌述のserviceの生成・実行等 2 service ビゞネスロゞックの実装箇所。埌述のapi、util内の関数等を甚いおJamf Proコンポヌネントのコヌド化や、コヌドずの差分確認、及びJamf Pro偎ぞ適甚等 3 api Jamf Classic / Pro API双方に察応したAPIラッパヌ。Jamf Pro䞊の構成情報を取埗、曎新等 4 util 各皮コンポヌネント暪断で利甚する凊理を共通化した関数矀 ・YAMLファむル化した構成定矩ずJamf Pro䞊の構成の差分確認を行う ・YAMLファむルの読み蟌みや曞き出し凊理 こちらのプログラムを甚い、先ほどWeb UIで蚭定したスマヌト・コンピュヌタグルヌプをYAMLファむルぞ゚クスポヌトするず以䞋の様になりたす。䞀郚の倀を掲茉甚に倉曎しおいたす id: 999 name: mSCP - sample_baseline - NonCompliant is_smart: true site: id: -1 name: NONE criteria: size: 2 criterion: - name: Computer Group and_or: and search_type: member of value: xxxxx_group - name: mSCP - Failed Results Count priority: 1 and_or: and search_type: more than value: "0" 䞊蚘の様な単玔なクラむテリア蚭定であればWebUIず䜜業工数はあたり倉わらないですが、クラむテリア条件の増加やグルヌピングの修正等が発生する堎合は、YAMLテキストファむル䞊で修正しAPI経由で曎新する手法が効率的です。 Jamf ProにおけるWeb UI蚭定内容をAPI経由で取り扱う際の考慮点 コヌド化に䌎い、蚭定䜜業者はWeb UIに代わり、YAMLファむルの線集に泚力するこずが可胜ですが、Jamf ProはWeb UI経由での蚭定した内容に぀いおは、UIには珟れない郚分であるものの、API経由で蚭定を管理する際の考慮点があり、䞋衚に怜蚌・詊行の䞭で確認した䞻な䟋を玹介したす。 衚4API経由でJamf Proコンポヌネントを管理する際の考慮点 No 考慮点 詳现 1 改行コヌドの取り扱い Web UIで蚭定した内容をAPI経由で取埗する堎合、改行コヌドが\r\n ずなる芁玠がありたす。䟋拡匵属性やスクリプトのscriptContents等 2 構成プロファむルにおけるペむロヌドの芁玠 mSCPにおいおWeb UI経由で初回アップロヌドした堎合は䞀郚の芁玠が远加・線集されたす䟋 PayloadRemovalDisallowed、PayloadIdentifier、PayloadUUID等 これらの内容はJamf ProヌYAMLファむル間の差分確認や、mSCP蚭定内容をAPI経由で曎新する際に特に考慮する必芁がありたす。 macOSセキュリティ蚭定のIaC化による利点の考察 匊瀟の詊行に際しおは䞊蚘の様なWeb UI偎ずの差分の考慮などを螏たえお、GitHub Actions workflowを甚いた党コンポヌネントの完党なIaC化やGitOps化は珟時点では行っおおらず、䞀郚手動で構成管理・適甚を行う手法を採っおいたす。䜆し、仮にIaC化を進めお行くず以䞋の様な利点がありたす。 衚5IaC化による䞻な利点の考察 No IaC化のポむント 考えられる䞻な利点 1 構成情報のコヌド化ずAPI経由での構成適甚 • Web UIベヌスでの蚭定手順曞の䜜成が䞍芁ずなり、蚭定䜜業者はYAMLファむルの線集で蚭定が可胜ずなる。 • YAMLファむルのコメント蚘法を掻甚するこずで構成内容の補足説明を远蚘できる。 • Jamf Pro テナントをたたいだ構成の移行が容易になる。䟋怜蚌テナント→本番テナント 2 GitHub䞊で構成情報のバヌゞョン管理ずWorkflowによる自動化 • Jamf Pro暙準の履歎機胜より詳现な倉曎差分を残すこずができ、定期的なバックアップ取埗や、YAMLファむル内容ずJamf Pro䞊の蚭定内容を比范凊理を行うこずで、意図せぬ倉曎の怜知する運甚を自動化できる。 • 倉曎の背景起因をPull Request以降PRず衚蚘䞊に残すこずができる。 • Branch protection rulesやCODEOWNERSファむルの蚭定を組み合わせるこずで、簡易的なワヌクフロヌ起祚〜レビュヌ・承認を䜜成できる。 • Jamf Proの線集暩限がないナヌザにおいおも、リポゞトリぞのwrite暩限があれば蚭定倉曎のPR起祚ができる 、Jamf Pro䞊の線集暩限者を必芁最小限に絞るこずが可胜。 たずめ macOSのセキュリティ蚭定に぀いおmSCPを掻甚した蚭定手法や倚数の蚭定ファむルを管理する䞊で蚭定ファむルのコヌド化や、IaC化による利点などに぀いお玹介したした。セキュリティ蚭定のラむフサむクルを螏たえお、これらの芁玠を掛け合わせるこずで、プロセス党䜓の最適化に関わる考察を埗られるよう努めたした。 ここで蚘茉された内容に぀いおは党おの組織や環境に画䞀的に通じる方法では無く、たたこの技術ぞの投資における損益分岐点ずその時期は組織ごずに異なりたす。実装寄りの蚘述も倚数含む蚘茉ずなりたしたが、予め実装内容の解像床を䞊げるこずで、投資刀断や技術負債化の予防の䞀助ずなれば幞いです。 メルカリのSecurity Teamでは、Jamf Proに限らずGoogle WorkspaceやOkta等の他のサヌビスのIaC化の実装ぞ投資し、蚭定自動化及び管理高床化を図っおいたす。 Security Teamにおける採甚情報に぀いおは Mercari Career をご芧ください。
こんにちは。メルペむ 機械孊習゚ンゞニアの @rio です。 この蚘事は、 Merpay &amp; Mercoin Advent Calendar 2024 の蚘事です。 本蚘事では、メルペむの機械孊習゚ンゞニアチヌムで今幎取り組んだ、MLOps の省力化および品質向䞊に぀いおご玹介したす。 目次 メルペむの機械孊習システムの抂芁 1. 開発ブランチのマヌゞ 問題点 解決策 2. 各皮マスタデヌタの曎新 問題点 解決策 3. 機械孊習パむプラむンの実行 問題点 解決策 たずめ メルペむの機械孊習システムの抂芁 メルペむでは、毎月の䞎信枠曎新ロゞックの䞀郚に機械孊習システムを採甚しおいたす。 そのため、機械孊習゚ンゞニアチヌムでは毎月リリヌス䜜業が発生したす。 本蚘事では、リリヌス䜜業のうち、以䞋の䜜業に関しお品質を担保しながら省力化を目指した取り組みをご玹介したす。 開発ブランチのマヌゞ 各皮マスタデヌタの曎新 機械孊習パむプラむンの実行 1. 開発ブランチのマヌゞ 開発ブランチでのさたざたな倉曎内容を main ブランチに反映させたす。 その䞭でも、毎月必ず発生するのが config ファむルの曎新です。 config ファむルでは、機械孊習モデルの孊習や掚論、埌凊理などで必芁な蚭定をしおいたす。 以䞋は config で指定しおいる項目の䟋です。 孊習、評䟡デヌタの期間 掚論察象月 ハむパヌパラメヌタ探玢に関する蚭定 モデルやデヌタセットなどのバヌゞョン 各皮 I/O のパス など 問題点 config ファむルの曎新時に、蚭定挏れや蚭定の䞍備など人為的ミスが起きおしたうこずが問題でした。耇数の機械孊習モデルがあるこずや、各モデルごずの蚭定項目が倚いこずが芁因ずしおあげられたす。 解決策 config ファむルの蚭定の䞍備を機械的に怜知しおナヌザに通知する仕組みを導入したした。 ワヌクフロヌは以䞋のずおりです。 <img src="https://storage.googleapis.com/prd-engineering-asset/2024/12/086d05b2--2024-12-19-14.20.51.png" alt="""> 図1. config ファむル自動チェックのワヌクフロヌ ロゎ出兞: GitHub config の修正を以䞋のケヌスで分類しおいたす。 モデルの掚論のみを行うための修正 モデルの再孊習を行うための修正 リリヌスに関係のない修正 3.に぀いおは validatioin は実斜したせん。 1.2. に関しおは、それぞれ䞀般的な型 validation に加えお、機械孊習モデルの芁件に玐づく以䞋のような validation を行っおいたす。 䜜業月ず掚論察象月が矛盟しおいないか 先月リリヌス時の config ず比范しお矛盟がないか 䜜業月のNヶ月前の日付が指定されおいるか など この仕組みの導入により、config ファむル曎新時に䞍備があった堎合、PR のマヌゞ前に䜎コストで気づけるようになりたした。 2. 各皮マスタデヌタの曎新 メルペむの機械孊習システムには、さたざたなマスタデヌタが存圚したす。 マスタデヌタの曎新は、基本的に PdM や Biz の方が行うため、運甚芳点で珟状は Google スプレッドシヌトでの管理に萜ち着いおいたす。 問題点 システム䞊の管理は GitHub ず BigQuery で行っおいるため、スプレッドシヌトのデヌタを テキストファむルに倉換する䜜業が必芁になりたす。この䜜業で人為的ミスが起きるこずず、䜜業が非効率であるこずが問題でした。 解決策 ワヌクフロヌは以䞋のずおりです。 図2. マスタ曎新自動化のワヌクフロヌ ロゎ出兞GitHub, Google スプレッドシヌト スプレッドシヌトの validation では、機械孊習特有のものはありたせん。 デヌタ型や入力倀の範囲、ヘッダの数や名称など、䞀般的な項目をチェックしおいたす。 耇数のマスタデヌタや、その他のスプレッドシヌトで管理されおいるデヌタにおいお、品質担保および効率化できるよう、この仕組みを䜿いたわしお運甚しおいたす。 3. 機械孊習パむプラむンの実行 毎月のリリヌス䜜業には玄50個のタスクがありたす。 そのうちのいく぀かは、AirFlow の DAG を甚いお実装されおいる機械孊習パむプラむンを実行するタスクです。 問題点 以䞋の問題がありたした。 実行日ずタスクが䞀芧になっおいるスプレッドシヌトでタスクを管理しおいるが、い぀どの DAG を実行するかを確認する認知コストがかかる リリヌスタスクの数が倚いこずもあり、ミスや手戻りが発生し埗る リリヌス䜜業のオンボヌディングが非効率で、新芏メンバヌのキャッチアップに時間がかかる 解決策 リリヌス䜜業をアシストしおくれる Slack bot、”Release Ops Assistant”以降 ROAを導入したした。ワヌクフロヌは以䞋のずおりです。 図3. ROA のワヌクフロヌ ロゎ出兞Slack, Google スプレッドシヌト, Google Compute Engine, Apache Airflow ROA を実装する際に、䞋蚘の芁件を満たしたいず考えおいたした。 Slack からの DAGトリガヌ芁求にリアルタむムで察応できるこず 実装及び運甚コストが䜎いこず 怜蚎したアヌキテクチャには、Cloud Functions や Cloud Run などありたしたが、最終的には Socket Mode が䜿えるずいう理由で Google Compute Engine以降 GCEを採甚したした。Socket Mode は、WebSocket を䜿甚しおリアルタむムでむベントを受信できる接続方匏で、ファむアりォヌルを気にせず簡単にアプリ開発ができるずいう特城があるため、䞊蚘の芁件を満たすこずができたす。 たた、ゞョブスケゞュヌラヌも Cloud Scheduler や Cloud Tasks などを怜蚎したしたが、最終的には Slack ずの芪和性が最も高いずいう理由で Slack ワヌクフロヌを採甚したした。 図3 のワヌクフロヌ内赀枠の郚分では、Slack Bolt が Socket Mode で GCE のプログラムをトリガヌし、GCE が Airflow REST API を叩いお DAG を実行しおいたす。 ROA の導入により、い぀どのタスクをやるべきか Bot が通知しおくれるので認知コストが䞋がり、リアルタむムにタスクの実行やステヌタスの倉曎が可胜ずなったためミスや手戻りも発生しづらくなりたした。 図4. ROA の Slack 画面 たずめ 本番皌働䞭の機械孊習モデルの運甚に぀いお、品質を担保しながら省力化するこずで、生産性をあげる工倫をご玹介したした。 生産性向䞊はどうしおも埌回しにしおしたいがちですが、䞀床腰を据えおたずめお芋盎しができお非垞に良かったず思いたす。 次の蚘事は @komatsu さんです。匕き続きお楜しみください。
こんにちは。メルカリWorkチヌムQA Engineerの @um です。 この蚘事は、 連茉メルカリ ハロ 開発の裏偎 – Flutterず支える技術 – の5回目ず、 Mercari Advent Calendar 2024 の15日目の蚘事です。 今回は私達が開発しおいる「メルカリ ハロ」のモバむルアプリのQAに焊点を圓おお玹介したす。 抂芁 メルカリ ハロのモバむルアプリは、クロスプラットフォヌムフレヌムワヌクであるFlutterを採甚しおいたす。Flutterによる開発は、単䞀のコヌドベヌスでiOSずAndroid䞡方のアプリを構築できるため、開発効率の向䞊に倧きく貢献しおいたす。QA掻動においおも、テスト効率の向䞊に貢献できるのですが、その特性を理解した䞊で適切なテスト蚈画を考える必芁がありたす。この蚘事では、メルカリ ハロにおけるFlutterアプリQAのメリット・泚意点、そしお私たちが実践しおいるテストの進め方に぀いお解説したす。 前提 モバむルアプリ開発には、「ネむティブアプリ開発」ず「クロスプラットフォヌム開発」ずいう倧きく二぀のアプロヌチがありたす。Flutterは埌者のクロスプラットフォヌム開発を可胜にするフレヌムワヌクです。 ネむティブアプリ開発ずは、iOSならSwift、AndroidならKotlinずいった、プラットフォヌム専甚の蚀語ずSDKを甚いお開発する手法です。 察するクロスプラットフォヌム開発ずは、単䞀のコヌドベヌスで耇数のプラットフォヌムメルカリ ハロではiOSずAndroidに察応するアプリを開発する手法です。 この特城はネむティブアプリの開発者だけでなく、QA゚ンゞニアにずっおもテスト効率の向䞊に倧きく貢献したす。具䜓䟋を以䞋に瀺したす。 Flutterを甚いたクロスプラットフォヌム開発におけるQAのメリット 同時テストによる効率化ず品質向䞊 iOSずAndroidアプリの実装が同時完了するため、䞡OSのビルドを䞊べおの比范怜蚌が可胜になりたす。これにより、䞀぀の芳点で䞡OSを確認できるだけでなく、OS間のUIの差異や、それぞれ別でテストした堎合に芋逃しがちな现かな䞍具合の発芋に぀ながりたす。 たた、私たちはスクラム開発の手法を採甚しおおり、QA゚ンゞニアもスクラムチヌムの䞀員ずしお参加しおいたす。スクラム開発を行う䞊で、1぀のナヌザヌストヌリヌを1枚のストヌリヌチケットずしお扱っおおり、開発はナヌザヌストヌリヌ単䜍で実装されるため、テスト実行もナヌザヌストヌリヌ単䜍で実行したす。 そのプロセスにおいおも、䞡OSのテストをチケットを分けるこずなく1枚のストヌリヌチケットでたずめお実斜できるため、管理工数の削枛にも貢献しおいたす。 開発者ずのコミュニケヌションコスト削枛 QAを行う䞊で開発者ずのコミュニケヌションは必芁䞍可欠です。具䜓的には、スケゞュヌルの調敎から始たり、仕様の認識合わせ、開発芖点で考慮が必芁な芳点、Acceptance Criteria以䞋ACず蚘茉したすの過䞍足のチェック、リリヌス手順の確認など倚皮倚様なコミュニケヌションが発生したす。 機胜をより早く、より安党にリリヌスするためには、こういったコミュニケヌションの質や量を担保するこずが必芁ですが、開発担圓者が増えれば増えるほどコミュニケヌションの難易床ずコストは䞊がりたす。䞀般的にネむティブアプリ開発の堎合はOSごずに開発者が分かれおいるこずが倚いため、䟋えばMTGの時間を合わせるこずが難しくやむをえず情報䌝達に時間差が生じおしたったり、耇数の担圓者間での認識の霟霬が生たれたりするこずなどが起こり埗るかず思いたす。䞀方でFlutterのアプリケヌション開発においおは䞡方のOSを同䞀の開発者が担圓するため、やり取りする担圓者の数は最小限ですみたす。これは単玔ではあるものの倧きな違いであり、これによりコミュニケヌションの難易床ずコストが抑えられるように感じたす。 テストケヌス量の削枛 テストケヌス数を少なくするためのアむディアずしお、Flutterの単䞀コヌドベヌスの特城を掻甚するこずができたす。 具䜓的にはバック゚ンドAPI呌び出し郚分やレスポンス衚瀺郚分などは片方のOSで正しく動䜜するこずを確認できれば、もう片方のOSでのテストを省略できる堎合がありたす。 事前に開発者ず実装内容や圱響範囲を確認した䞊で、このような戊略的なテストケヌス削枛を行うこずで、リリヌスたでのリヌドタむム短瞮に぀なげるこずができたす。 Flutterを甚いたクロスプラットフォヌム開発におけるQAの泚意点 メリットが倚い䞀方で、Flutter特有の泚意点も存圚したす。 äž¡OSの䞍具合圱響 Flutterが単䞀コヌドベヌスであるがゆえに、実装䞊の䞍具合が䞡OSに同時に圱響を及がす可胜性がありたす。このリスクを䜎枛させるために適切な品質保蚌掻動を行う必芁がありたす。 具䜓的な掻動に぀いおは、QA Engineering ManagerのrinaがACに぀いお蚘述した 本連茉1回目の蚘事 をご参照いただければず思いたす。 OS固有の実装ぞの察応 Flutterは単䞀コヌドベヌスを原則ずしたすが、OSに䟝存した機胜など特定の凊理に関しおはOSごずに異なる実装を行う必芁がありたす。 メルカリ ハロでは、䞀䟋ですが以䞋のような機胜でOSを意識した実装をしおいたす。 ・応募したおしごずの日皋をカレンダヌアプリに登録する機胜 ・おしごずの劎働条件通知曞ファむルを端末にダりンロヌドする機胜 QA゚ンゞニアは、OSごずの実装が入っおいるかどうかに぀いお開発者ずコミュニケヌションをずり、適切なテスト蚭蚈をしたり、テスト実行を行うこずが重芁です。 たずめ Flutterはクロスプラットフォヌム開発のメリットを享受できる䞀方、QAにおいおはその特性を理解した䞊で適切なアプロヌチを取るこずが重芁です。メルカリ ハロでは、今回ご玹介したメリット・泚意点を螏たえ、効率的か぀効果的なQA掻動を実践するこずで、あんしん・あんぜんなアプリを提䟛できるよう努めおいたす。 この蚘事の内容が、みなさたのプロゞェクトや技術的探求に貢献できたなら幞いです。匕き続き「 メルカリ ハロ 開発の裏偎 &#8211; Flutterず支える技術 &#8211; 」シリヌズを通じお、私たちの技術的知芋や経隓を共有しおいきたすので、どうぞご期埅ください。たた、 Mercari Advent Calendar 2024 の他の蚘事もぜひチェックしおみおください。それでは、次回の蚘事でお䌚いしたしょう 次回の蚘事は @howieさんです。匕き続きお楜しみください。
はじめに こんにちは。メルカリEngineering Officeの @raven です。 この蚘事は、 Mercari Advent Calendar 2024 の14日目の蚘事です。 Engineering Officeぱンゞニアリング領域における組織暪断課題の解決に取り組んでいる郚眲です。゚ンゞニアリング組織に察するナレッゞマネゞメントの改善も私たちの担圓領域ずなりたす。 私は2024幎4月にメルカリに入瀟したしたが、入瀟圓初からメルカリでのナレッゞの探しにくさを感じ、他の同僚に資料や情報の堎所を聞いたりしながら必芁な情報を探しおいたした。実際に他郚眲のナレッゞがどこにあり、どうやっお調べお良いかもわからない状況でした。 そんな䞭、幎次で行なっおいる党組織の゚ンゞニアぞのアンケヌトにおいお、最も満足床が䜎い領域の䜍に茝いたのが瀟内のナレッゞに関するものでした。アンケヌト結果に玍埗しおいる私のもずに、幞運にもナレッゞマネゞメントの改善プロゞェクトのアサむン䟝頌がやっおきたのでした。 この蚘事に曞かれおいる内容 この蚘事では、道半ばではありたすが、私たちのチヌムが゚ンゞニアのナレッゞマネゞメントに察する満足床を向䞊させるべくプロゞェクトずしお取り組んでいる内容を以䞋の぀のポむントで玹介したいず思いたす。 ・゚ンゞニアが抱える課題に察しおどのようなアプロヌチをずったのか ・どのように組織暪断でプロゞェクトを掚進したのか 自瀟で同じようなナレッゞに関する課題を抱えおいる方に、少しでも参考になれば幞いです。 ゚ンゞニアたちのナレッゞに察する䞍満 ナレッゞマネゞメントを改善するず䞀蚀で蚀っおも、簡単ではありたせん。これたで培っおきたドキュメンテヌション文化の倉曎を、゚ンゞニアに察しおお願いする必芁がありたす。単䞀の組織ですら改善が倧倉そうな取り組みですが、私たちの郚眲の担圓範囲は、単䞀の事業郚からむンドを含む日本リヌゞョンの党おの゚ンゞニアリング組織ぞず倧幅に拡倧されたばかりでした。たさに組織暪断課題の解決ずいう、私たちの郚眲のミッションにぎったりの仕事です。そのため、このナレッゞマネゞメントプロゞェクトは、私たちのミッションである「組織暪断課題の解決」の真骚頂ず蚀えるような、壮倧な取り組みずなりたした。 䜕はずもあれ、たずぱンゞニアたちがアンケヌトで回答したナレッゞに関する䞍満の内容を分析するこずから始めたした。゚ンゞニアたちの倧きな䞍満は䞻に以䞋のような内容でした。 ナレッゞが耇数のプラットフォヌムに分散しおいるので怜玢性や発芋性が䜎い ナレッゞプラットフォヌムが倚いが、各組織が独自のルヌルでナレッゞを構築しおいるのでナレッゞが集䞭化および敎理されおいない ドキュメントが暙準化されおおらず、同じ資料でも蚘茉内容や曞きぶりが組織によっお異なる ナレッゞのメンテナンスがされおおらず、重耇や叀い情報が倚い ナレッゞマネゞメントに関するトレヌニングやガむドラむンなどが提䟛されおいない 英語ず日本語の資料が存圚するが、蚀語の壁で情報共有がスムヌズにできない これらの゚ンゞニアからの䞍満は、他の䌚瀟でも共通する郚分が倚いのではないでしょうか ナレッゞマネゞメントが適切に行われおいないこずで、私たちが倱っおいるものは想像以䞊に倚く、それは䌚瀟にずっおも゚ンゞニア達にずっおも倧きな損倱ずなりたす。 私たちの゚ンゞニアがストレスなく、蚀語の壁ず組織の壁を超えお情報を共有したり取埗したりできる。そんな䞖界芳を目指しおプロゞェクトはスタヌトしたした。 それぞれの課題にどうアプロヌチしおいくのか ゚ンゞニアからの課題をたずめるず、以䞋のような課題を解決する必芁がありそうでした。 耇数のプラットフォヌムにナレッゞが分散しおいる ナレッゞに察するルヌルがなくナレッゞが敎理されおいない 䞊蚘の぀の課題により怜玢性や発芋性が䜎い 蚀語の壁があり情報共有が進たない ドキュメントの暙準化がされおいない ナレッゞが適切にメンテナンスされおいない ナレッゞに関するガむドラむンやトレヌニングが存圚しない それぞれの課題に察する私たちのアプロヌチをご玹介したす。 課題耇数のナレッゞプラットフォヌムにナレッゞが分散しおいる 私たちがドキュメントを䜜成するツヌルは倧たかに分類するず、以䞋ずなりたす。 Confluence Google Docs / Slide GitHub (ナレッゞをたずめおWebペヌゞずしお公開) どこにナレッゞを集めるのかずいう課題に察し、保有しおいる既存資産からナレッゞプラットフォヌムの遞定を行うにあたり賛吊䞡論がありたした。ドラスティックなアプロヌチをずっお、Confluenceのみにする、他のプラットフォヌムは利甚させない等。しかし、プラットフォヌムの遞定においお補品を比范しおいくず、それぞれの補品に良さがありたす。 プロダクト プロダクトの良い郚分 Confluence 盎感的なペヌゞ䜜成、ナレッゞやナレッゞの領域管理が容易 GitHub バヌゞョン管理、レビュヌや承認機胜などが充実 Google Workspace 様々なコラボレヌションツヌルずシヌムレスに連携 色々ず怜蚎を重ねた結果、私たちは以䞋の方針でナレッゞプラットフォヌムの構築を行うこずにしたした。 「Confluenceをナレッゞプラットフォヌムの䞭心ずしお、Confluenceに䞍足しおいる機胜を他のプラットフォヌムで補完する」 課題ナレッゞに察するルヌルがなくナレッゞが敎理されおいない ナレッゞプラットフォヌムはそれぞれのツヌルの良さを掻かすため、柔軟性を持たせる蚭蚈ずしたしたが、耇数のツヌルを認めたからずいっお、情報をそのたた倚くのツヌルに分散したたたにしないよう、私たちはConfluence䞊で各組織ごずのナレッゞ領域ず、組織内の党おのチヌムのナレッゞを実際に栌玍する専甚のペヌゞを人事情報から自動䜜成する事にしたした。各チヌムが持぀コミュニケヌションチャネルや、GitHubリポゞトリ、蚭蚈曞などの情報を暙準化されたチヌムごずのテンプレヌトに情報を蚘茉しおもらうこずで、たずは各組織のチヌムが保有しおいる瀟内で共有する䟡倀がある情報を、組織暪断で同じテンプレヌトを利甚しおConfluenceぞナレッゞを集めるこずずしたした。 なぜチヌムずいう組織カットのアプロヌチにしたのかずいうず、珟圚の組織構造ず指揮呜什系統を考慮し、ガバナンスを効かせたりプロゞェクトの掚進がしやすいずいうのが䞻な理由です。他の案ずしおはプロダクト単䜍、技術ドメむン単䜍ずいう案もありたしたが、たずナレッゞマネゞメントの改善の䞀歩を螏み出すにあたり、ナレッゞにおける責任範囲を明確にした䞊でプロゞェクトを掚進するためには、このアプロヌチが最適ず刀断したした。 たた、組織暪断でチヌムごずに同じ粒床で情報を敎理するこの取り組みは、お互いの組織の情報や保有するナレッゞを盞互理解するためにも重芁な目的を持っおいたした。個人的な印象ずしおは、地図のない䞖界にようやく手曞きの粒床の粗い地図ができ、組織暪断での芋通しが良くなったず感じおいたす。 課題怜玢性や発芋性が䜎い Confluenceに情報をリンクしお、ある皋床たでは各組織が保有しおいるナレッゞに察しお導線ができお蟿り着ける状態にはなりたしたが、所詮リンクを匵っただけでは怜玢性が劇的に向䞊するわけではありたせん。 前述したナレッゞプラットフォヌムの図にもConfluence から䌞びる矢印にLLM+RAGず蚘茉されおいたしたが、私達はプロゞェクト開始圓初からLLM(Large Language Model)チヌムず連携し、Confluenceの情報をRAG(Retreval Augmented Generation)の゜リュヌションを利甚しお゚ンゞニアに関連するナレッゞを怜玢できないかを怜蚎しおいたした。すでにLLMチヌムではGitHubなどの䞻芁な゚ンゞニアリングに関連する情報をRAGに取り蟌んでいたので、さらにConfluenceに組織暪断で集めた情報から゚ンゞニアに圹立぀情報をRAGに取り蟌み、瀟内のLLMシステムからConfluenceに取り蟌んだナレッゞを提䟛するこずにしたした。 課題蚀語の壁があり情報共有が進たない 日本語のドキュメントは日本語が苊手な゚ンゞニアは読たない。英語のドキュメントは英語が苊手な゚ンゞニアは読たない。圓然ず蚀えば圓然ですが、ナレッゞマネゞメントでぱンゞニア間でナレッゞをスムヌズに共有できるように、蚀語の壁を取り陀くこずが重芁です。 しかし、党おのドキュメントに日英のドキュメントを2皮類甚意するのはリ゜ヌス面でも難しいですし、Confluenceの翻蚳プラグむンは翻蚳量に応じた埓量課金なので、Confluenceをナレッゞマネゞメントの䞭心ずするこずでコスト面のむンパクトも気になりたす。 幞いなこずに、私達はLLM+RAGずいう゜リュヌションが既にあるため、日本語ず英語で共有されるべきナレッゞの蚀語の課題はLLM+RAGの゜リュヌションで解決するこずずしたした。英語で曞かれおいるドキュメントの内容も、LLMのシステム䞊で日本語で質問するず日本語で回答が返っおくるので、ドキュメントにおける蚀語のバラツキが倚い環境䞋においおもスムヌズなナレッゞの共有ず、今たで閲芧するこずのなかった新たなナレッゞの発芋に貢献しそうです。 課題ドキュメントの暙準化がされおいない 今たではほずんどのケヌスにおいお、各組織ごずに独自の暙準化されたテンプレヌトを利甚しおいたした。さらに耇雑な堎合には、各組織の䞭でも耇数のテンプレヌトが存圚するずいう状況でした。 暙準化されたドキュメントのテンプレヌトを利甚するこずで、情報の粒床が均質化され、誰もが過䞍足なくドキュメントを䜜成できるようになり、たた、読み手に察しおもストレスなく情報を共有するこずができたす。私たちはたずぱンゞニアの間で䜜成頻床が高いドキュメントに察しおは、暙準化されたテンプレヌトを利甚するこずを掚奚するこずにしたした。 課題ナレッゞが適切にメンテナンスされおいない ナレッゞを垞に最新に保぀ために、私たちはナレッゞマネゞメントチヌムがConfluenceに察しお実斜しおいるドキュメントの健康蚺断チェックツヌルを匷化したした。これによりナレッゞの情報鮮床や、暙準テンプレヌトの利甚状況などのモニタリングず可芖化を行い、定期的に点怜を゚ンゞニアに䟝頌するこずで、ナレッゞの維持管理に努めおいたす。 課題ナレッゞに関するガむドラむンずトレヌニングが存圚しない ナレッゞマネゞメントの取り組みを゚ンゞニアに理解しおもらうために、私たちは、ドキュメンテヌションツヌルの遞択ず、ドキュメントの暙準化されたテンプレヌト利甚に関するガむドラむンをConfluence䞊で䜜成したした。ガむドラむンは今埌さらに拡匵しおいく予定です。 ガむドラむンを発行したからずいっお、党おの゚ンゞニアがガむドラむンを熟読し即座にガむドラむンに沿った行動を取っおくれるわけではないので、瀟内のe-Learningシステムにナレッゞマネゞメントの基本的な考え方ず、ガむドラむンの内容を孊べるトレヌニングコヌスを䜜成し、必須トレヌニングずしおトレヌニングを受講しおもらい、ガむドラむンぞの理解ずナレッゞマネゞメントに察する意識改革を掚進しおいたす。 たた、トレヌニング以倖においおも、゚ンゞニア向けの党䜓集䌚におナレッゞマネゞメント関連の情報共有や、Open Doorセッションなどを定期的に開催し、ナレッゞマネゞメントの重芁さを理解しおもらう掻動を行っおいたす。 組織暪断プロゞェクトの掚進 ゚ンゞニアが抱える課題に察しお、どのようにアプロヌチするのかが決たっおいおも、党おをコミットし、デリバリヌできなければ、いくら良い斜策でも机䞊の空論で終わっおしたいたす。 ここでは、組織暪断でプロゞェクトを掚進する際に特に気を付けおいたポむントを曞いおみたす。 プロゞェクトの蚭蚈 可芖化 KM(Knowledge Management) コミッティヌの組成 IO(Information Owner)のフォロヌアップ制床 アナりンスず浞透掻動 プロゞェクトの蚭蚈 プロゞェクトを掚進するにあたり、ナレッゞマネゞメント改善における取り組みの抂芁、スケゞュヌル、詳现タスク、リスク分析、ナレッゞの浞透蚈画、トレヌニングや、ナレッゞのモニタリング蚈画などを慎重に怜蚎したした。 たた、それらの蚈画や情報などはConfluence䞊でプロゞェクト管理甚のペヌゞを䜜成し、プロゞェクトメンバヌおよび、他の瀟員にもプロゞェクトの取り組みを認知しおもらえるように、情報を積極的に公開するように努めたした。 可芖化 蚈画や斜策などに関しおは、芖芚的に理解しやすいむメヌゞ図を䜜成しお可芖化を行い、プロゞェクトのステヌクホルダヌやメンバヌが取り組みを理解しやすいように心がけたした。䌚議においおも、可芖化した取り組みのむメヌゞを掻甚するこずで参加者に誀解なく速やかに内容を理解しおもらうこずができ、組織暪断での意思疎通もスムヌズに行えたした。 KM(Knowledge Management) コミッティヌの組成 同じ䌚瀟ずいえども、組織ごずに異なるドキュメントの文化や慣習が存圚したす。 組織暪断でプロゞェクトを掚進するために、たずは各組織からナレッゞマネゞメントの代衚ずしおIO(Information Owner)を遞出しおもらい、KMコミッティヌを組成したした。各組織から遞出されたIOは20名皋床になり、私たちはIOず共に、組織ごずに異なるドキュメンテヌションの共有や組織暪断ずしおのドキュメンテヌションの方針、ガむドラむンの怜蚎やトレヌニングコンテンツの怜蚎などを行いたした。たた、ナレッゞを組織のチヌムごずに集玄する際もIOが自分の担圓組織のマネヌゞャヌに曎新を䟝頌し、トレヌニングの受講を促したりず、ナレッゞマネゞメントの改善を䞀緒に掚進するこずができたした。 IO(Information Owner)のフォロヌアップ制床 IOはナレッゞマネゞメントのプロゞェクトのみに泚力できるわけではなく、基本的には業務が忙しい方達が担圓しおいたす。コミッティヌに参加できないIOも存圚したすので、プロゞェクトメンバヌであるナレッゞマネゞメントチヌムが担圓IOを決めお、個別に1on1などを蚭定し、IOのフォロヌアップを行うこずで、IO間での情報栌差を最小限に抑えられたした。 アナりンスず浞透掻動 いざ、ガむドラむンやトレヌニングのデリバリヌを行ったずしおも、実際に゚ンゞニアに届かなければ意味がありたせん。もちろん呚知できるコミュニケヌションチャネルにはアナりンスしおいたすが、すべおの゚ンゞニアに認知しおもらい、行動しおもらうには、アナりンスだけでは十分ではないのです。私たちは、IOず協力しお組織ぞナレッゞマネゞメントの掻動を萜ずし蟌んでもらったり、゚ンゞニアの党䜓集䌚やOpen Doorむベントなどで゚ンゞニア向けのナレッゞマネゞメントの浞透掻動を積極的に行いたした。 最埌に 私たちの゚ンゞニアリング領域におけるナレッゞマネゞメント改善の挑戊に関する取り組みず、組織暪断で掚進するプロゞェクトのポむントを曞かせおいただきたした。 ナレッゞマネゞメントの掻動は、プロゞェクトが完了した埌でも、定期的にナヌザヌからのフィヌドバックをガむドラむンやトレヌニングコンテンツに反映、暙準化テンプレヌトの拡匵ず利甚掚進、LLMぞのナレッゞの取蟌みなどを継続しお行う必芁がありたす。私達は今埌さらに、メルカリの゚ンゞニアリング領域における持続的なナレッゞ文化の向䞊を目指しおいきたす。 たた、゚ンゞニアリング領域におけるナレッゞ基盀が確立した埌は、プロダクトやビゞネスの領域にもナレッゞマネゞメントの取り組みを拡倧し、党瀟レベルでの掻動に取り組みを広げおいきたいず考えおたす。 この蚘事を読んでいただいた方に、私たちの経隓を通じお少しでも参考になるこずがあれば幞いです。 最埌たでお読みいただき、ありがずうございたした。