こんにちは。メルカリのBackendエンジニアの@osari.kです。 この記事は、Mercari Advent Calendar 2023 の9日目の記事です。 一般に大きなプルリクエストはレビューが大変で、マージまでに時間がかかります。一方で複数の小さいプルリクエストに分割するとコードレビュー待ちの間、関連する開発がブロックされることがあります。今回は機能の開発時間を短くするために、チームで試したGitのブランチ戦略の1つであるStacking手法をケーススタディを交えて紹介します。 大きなプルリクエストがもたらす問題点 大きなプルリクエストがもたらす問題とは何でしょうか？ コードレビューで読むサイズが増える コードレビュー中の修正回数が増える（可能性が増える） コードレビューで必要な知識の範囲が広がる（可能性が増える） 変更箇所が多いのでリリースのリスクが増加する プルリクエストが大

Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ

こんにちは。search infraチームのmrkm4ntrです。 我々のチームでは検索基盤としてElasticsearchクラスタをKubernetes上で多数運用しています。これらのElasticsearchクラスタを管理しているnamespaceはマルチテナントな我々のKubernetesクラスタの中で最大のリソースを要求しているnamespaceです。 一方でクラスタのサイズをピークタイムに合わせて固定していたため、そのリソース利用率は非常に低いという問題がありました。Elasticsearch EnterpriseやElastic Cloudにはオートスケーリング機能が存在するのですが、これはスケールイン/アウトのためのものではなく、ディスクサイズに関するスケールアップ/ダウンを提供するもので我々の要求を満たすものではありませんでした。 そこで今回は、HPAを用いたスケールイン/

こんにちは、メルカリのレコメンドチームで ML Engineer をしている ML_Bear です。 以前の記事 [1] では、item2vecと商品メタデータを用いた、メルカリのホーム画面のレコメンド改善のお話をさせていただきました。今回は商品詳細画面でレコメンド改善を行ったお話をさせていただきます。商品詳細画面の例は図1の通りです。ユーザーはアイテムの詳細な説明を見たいときにこの画面に来訪するため、同様の商品を推薦する自然な接点として非常に重要です。 まず、私たちが商品詳細画面で行った改善の概要を示します。各部の詳細については次節以降で詳しく触れます。 日本有数の大規模ECサービスにおいてベクトル検索ベースの商品推薦アルゴリズムを実装し、推薦精度の大幅な改善を実現しました。 協調フィルタリングとニューラルネットワーク (以下、NN) を利用した商品推薦アルゴリズムを構築し、コールドスタ

こんにちは！メルカリ Engineering Office チームの@aisakaです。 メルカリのエンジニア組織は、メンバーが相互に学び合い、メンバー自身が自走し、成長できる組織を目指し、「互いに学び合い、成長し合う文化」の醸成を行っています。 こうしたメルカリの「互いに学び合い、成長し合う文化」を体現する仕組みの一つが、社内技術研修「DevDojo」シリーズです。 昨年から、一部のDevDojoシリーズを外部公開(参考)していますが、今回さらに新しいコンテンツを公開することになりました！ 今日のブログでは公開するセッションとその内容をご紹介します！ Learning materials Website 技術研修DevDojoとは DevDojoは、技術開発を学ぶ場として「Development」と「Dojo(道場)」をかけ合わせて名付けられた完全In-houseの社内研修シリーズです。

この記事はMercari Advent Calendar 2022の21日目の記事です。 こんにちは。メルカリのPlatform Infraチームで働いている @sanposhiho といいます。 個人的にKubernetesやその周辺のOSSにコントリビュートをしていて、特にKubernetesのコントロールプレーンのコンポーネントのうちの一つであるスケジューラー周りを触ってることが多いです。 この記事では、現状のスケジューラーにおける拡張性の課題と、スケジューラーに現代の汎用バイナリとも言えるWasm（WebAssembly）ランタイムを通した拡張性を持たせることができるのかどうかを検証してみます。 Kubernetes Scheduler とは スケジューラーはPodをどのNodeで実行するかを決定しているコンポーネントです。 その時の様々なリソースの状況を見たり、ユーザーが指定した

この記事は、Merpay Advent Calendar 2022 の15日目の記事です。 こんにちは。メルペイのvvakameです。 最近、社内向けにGraphQL Client Architecture Recommendationというドキュメントを書きました。社内のiOS/Android、そしてバックエンドのエンジニア向けにGraphQLをやるならこの辺りの条件を満たしておかないと恩恵を感じられなくなっちゃうかもよ、と伝えるためのものです。嬉しいことに、今までに100名弱の人たちがこのドキュメントを閲覧してくれたようです。 これをAdvent Calendarで公開するために、ちょっと調整したものがこの社外版です。 すでにGraphQLをやっているけどあまり便利じゃないな…なんでだろ？とか、これから導入したいんだけど何を気をつけるべきかな…と考える時の材料にしてください。 併せて、

こんにちは、メルカリのレコメンデーションチームで Software Engineer をしている @yaginuuun です。主に推薦を通じたホーム画面における体験改善に取り組んでいます。 元々はデータアナリストとしてデータ分析関連の業務を担う傍らA/Bテストのワークフロー改善にも取り組んできました。 Mercari Advent Calendar 2022 の12日目では、去年から今年にかけて取り組んできたA/Bテスト分析の自動化について、課題感や実際の実装などについて触れていきます。 背景 A/Bテストは世界中の企業で導入されている効果検証のゴールドスタンダードとも呼べる手法であり、メルカリでも毎日のようにA/Bテストを用いた改善活動が行われています。 A/Bテストは一見とてもシンプルな効果検証手法ですが、それを適切に使用するためにはさまざまな統計的事項やアンチパターンを考慮する必要が

はじめに こんにちは！ソウゾウのSoftware Enginner（Machine Learning）の@nkato_です。「メルカリShops [フライング] アドベントカレンダー2022」の4日目を担当します。 この記事では、ソウゾウの機械学習チームで取り組んだこととして、施策の評価にベイジアンA/Bテストという手法を取り入れた話をします。 ベイジアンA/Bテストを用いるとテスト結果が解釈しやすく、そのため最終的な意思決定に繋げやすいというメリットがあります。A/Bテストに取り組む中で「有意差がなかったから既存ロジックを採用してしまう」「信頼区間の解釈に迷う」といった経験がある方にはぜひお読みいただきたい内容です。 また、この記事は統計学に関する用語を含んでいるため、統計学についての基本的な知識を有する方を対象としています。 A/Bテストとは A/Bテストとは、ユーザーをランダムに2つ

こんにちは、メルカリMicroservices SREチームの mtokioka です。Embedded SREとしてマイクロサービスのチームに参加し、サービスの信頼性向上や自動化などの業務に従事しています。 メルカリでは Kubernetes Horizontal Pod Autoscaler（以下、HPA）を用いて pod のオートスケールを実現しています。しかし、標準でサポートされる CPU 使用率を用いたオートスケールでは不十分なケースがあり、そのような場合に External Metrics として Datadog のメトリクスを用いることでより柔軟なオートスケールを実現することができます。 これまでいくつかの External Metrics を実際に HPA で利用してきたので、導入事例を実際に適用した順番に紹介したいと思います。 事例 1：Container 別の CPU

こんにちは、メルカリMicroservices SREチームの藤本(@jimo1001)です。 私は現在、Embedded SRE として サーチインフラチームに入り活動しています。このサーチインフラチームは、Elasticsearchを使用した検索基盤を管理し、様々なマイクロサービスに検索機能を提供するチームです。この検索基盤は非常に巨大なプラットフォームで、メルカリ全体のマシンリソースの高い割合を占めており、メルカリの検索を支える非常に重要なものです。私の Embedded SRE としてのミッションは検索基盤の信頼性の向上と自動化を推進することです。 今回は、メルカリの検索基盤で利用している Elasticsearch における運用のノウハウを紹介したいと思います。 Elasticsearch とは Elasticsearch は、Elastic社が開発する Apache Lucen

※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercariの一環で書かれています。 はじめに こんにちは、メルカリ、サーチインフラチームのshinpeiです。今回はメルカリの検索基盤の裏側について、そのアーキテクチャ変遷について書こうと思います。2018~2021年の4年間で、大きく3回、変化をしました。設計の段階では希望と期待にあふれているアーキテクチャでも、問題は後からやってきます。設計には良し悪しがあり、変化することで知見を得ながら、改善を続けています。え、これだと危ないのでは？、、あぁ、やはりそうなるのね。などと、ご笑覧いただければ幸いです。 前回までのお話 メルカリの検索は、創業時から、Solrをベースにしたシステムで組まれてました。その変遷はこちらのスライドにまとめてあ

Mercari advent calender の21日目を担当します@sanposhihoです。現在大学の学部4回生で、メルカリでは内定者インターンとして、メルカリのホーム画面などのバックエンドを担当するチームに所属しています。 また、最近は個人的にKubernetesやその周辺のOSSにコントリビュートをしていて、特にKubernetesのコントロールプレーンのコンポーネントのうちの一つであるkube-scheduler周りを触ってることが多いです。 後で詳しく説明しますが、kube-schedulerはPodをどのNodeで実行するかを決定しているコンポーネントです。NodeAffinityや比較的新しいものだとPod Topology Spread Constraintsなど、Podのスケジュールの制約を指定できる機能も基本的にこのkube-schedulerに実装されています。

はじめに こんにちは、メルカリJP の Search Backend チームの otter です。 今回は、BFF的役割を担っている Search API のインターフェースを version 2 として刷新したときの課題や改善した点について紹介したいと思います。 API が持っていた課題 ご存知の方も多いと思いますが、メルカリではサービス全体としてマイクロサービスアーキテクチャによる開発を採用しています。 Search API もモノリシックな API からマイクロサービスとして切り出されたもので、iOS やAndroid などのクライアントとの後方互換性を担保するため、API のインターフェースや仕様はそのまま移行されました。 そのため、サービス面では柔軟に新たな施策に対応するのが難しかったり、システム面では各マイクロサービスで共通化されるべき、エラーハンドリングやページネーションがメ

こんにちは。ソウゾウの Software Engineer の @wakanapo です。連載：「メルカリShops」プレオープンまでの開発の裏側の 11日目を担当します。 メルカリShops唯一の ML (Machine Learning) 担当メンバーとして、メルカリShopsへのML導入を推進しています。まだ、絶賛立ち上げ中ではありますが、これまでの歩みについてお話します。 序章 私は、2019年4月に新卒入社以降メルカリJPの写真検索機能を中心に担当していました。当時写真検索はリリースされたばかりの機能だったので、バグの修正やシステムの改善を担当していました。その中で次のような課題を感じるようになりました。 写真検索のシステムは、継続的に出品された画像を検索に加える必要があるという特性から非常に複雑なものでした。またその indexing から serving までの Pipeli

こんにちは、AIチーム所属の@shidoです。CRE (Customer Reliability Engineering) 領域でMLを扱っています。 みなさんはPythonで本番コードを書くことについてどうお考えでしょうか。「研究/分析以外には使いたくない」「遅い」「動的型付け言語を本番用に使いたくない」といった声が聞こえてきそうです。 しかしながら機械学習サービス(または機械学習サービスのためのサービスなど)を作りたい場合、「学習に利用したPython用のライブラリを使用したい」「Pythonでやっていた分析と同じことを本番環境内でもやりたい」など、Pythonでバックエンドを実装したくなることがあると思います。 この記事ではtype hintsを付けながらPythonを書くことで、GoやJavaのようなサーバーサイドでよく使われる言語と可読性や保守性、場合によっては型安全性も同じレベ

TL;DR こんにちは、メルカリでCRE (Customer Reliability Engineering) に所属している @umechan です。 今回は、チームメンバーの@shidoと一緒に、以下のような試みを行ったのでその結果を共有します。 お問合せだけでは把握できない悪い体験の継続率を可視化したところ、Goodmanの法則[1]と同様に、不満を持ちながら苦情を申し立てないお客さまの継続率が悪いことが分かった 可視化した継続率をもとに、対策の優先度づけする方法を提案した 背景 ご存知のように、メルカリは個人が簡単にモノの売り買いを楽しめるフリマアプリで、買い手はもちろん売り手も個人となるC2Cサービスになります。おかげで、誰もが簡単にモノの売り買いを楽しむことができ、個人のエンパワーメントを実現する一端を手助けをできていると考えています。 しかし、売り手も個人であることで、一般的

この記事は、Merpay Tech Openness Month 2020 の17日目の記事です。こんにちは。メルペイのMachine Learningチームのhmjです。 検知精度とオペレーション負荷のトレードオフ解消 取引の連続性に着目した検知 と不正決済の検知への機械学習の適用の内容にて投稿してきました．今回は「集団的な不正の検知」がテーマとなります． 昨今，Web不正検知やセキュリティに関わるでもECサイトでの集団による不正の手口は多様化や複雑化してきていることが報告されています[1]． メルペイでも，今後起こり得る集団的な不正決済への対策を講じる必要があると考えています． 集団的な不正は検知できたとしてもその全体像がみえにくいこともあり，ソリューションとしては「検知できること」と「すばやく全体像を把握できる」を満たすものが求められています． 両者を満たす解決方法として，グラフ理論

この記事は、Merpay Tech Openness Month 2020 の 8 日目の記事です。 こんにちは。メルペイのコード決済チームでバックエンドエンジニアをしている @ktr です。 メルペイではマイクロサービスアーキテクチャを採用しており、それぞれのマイクロサービス間の通信プロトコルとして gRPC を、リクエスト・レスポンスのシリアライズフォーマットとして Protocol Buffers を採用しています。gRPC + Protocol Buffers を採用することにより、API のクライアントとサーバのインターフェース部分のコードを自動生成でき、リクエスト・レスポンスのエンコード、通信処理といった gRPC 特有の処理をほとんど意識せずに利用できます。 しかし、その一方で Protocol Buffers はバイナリベースのシリアライザであるため、例えば一般的な HTT

メルカリで写真検索とEdge AIチームに所属している澁井（しぶい）です。機械学習のモデルを本番サービスに組み込むための設計やワークフローをパターンにして公開しました。 GithubでOSSとして公開しているので、興味ある方はぜひご笑覧ください！ PRやIssueも受け付けています。私の作ったパターン以外にも、有用なパターンやアンチパターンがあれば共有してみてください！ GitHub：https://github.com/mercari/ml-system-design-pattern GitHub Pages：https://mercari.github.io/ml-system-design-pattern/README_ja.html なぜ機械学習システムのデザインパターンが必要なのか 機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのた