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

Scaling Kubernetes Tenant Management with Hierarchical Namespaces Controller Author: @deeeeeeeet from Platform Developer Experience Team Three years ago, we took the decision to break our monolithic API into microservices, and move from the physical machine deployment on-premise to container deployment on GCP by using Google Kubernetes Engine (GKE). We architected our Kubernetes cluster with multi

表を見ていただくと分かるように今回の変更によって Istio 1.10 以降は Istio なしの場合と挙動も変わらないため、認知負荷も減り今までよりも Istio を採用しやくなったのではないでしょうか。 ここまで Istio 1.10 から変更になった Inbound Fowarding の内容を見てきました。 次にこの変更によって私達のサービスに起きた問題を共有していきます。 起きた問題 今回の変更によってアプリケーションが動かなくなるケースとしては、アプリケーションが lo にのみ bind している場合です。 Istio ではこれを事前にチェックするためのコマンドを用意しており istioctl experimental precheck を実行します。 該当する Pod がある場合には IST0143 という message code が出力されます。 該当する Pod があっ

こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載：「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今

Introduction The seven day’s post of Mercari Advent Calendar 2020 is brought to you by Yu from mercari data platform team. We have been building a data-driven culture at mercari. As you know, building a data-driven culture is not so easy, because we have to change our mindset and implement technical foundations. Especially, it is very difficult to achieve that without technical foundations. So, in

この問題を解決するため、もともとのコードベースであるところのモノリスもコンテナ化してKubernetesに乗せることにしました。ツールセットの統一をすることでよりシンプルな体系ができ、プラットフォームチームも一つの環境向けの改善に注力できるようになります。 プロジェクトの流れ PoC 計画についてあたため始めた際にちょうどよくUSチーム内でのハッカソンイベントがあったため、それに合わせて試しにKubernetesで動かすデモを発表しました。デモで見せる部分はごく限られたものだったため3人で3日くらい集中して開発したところ動くものができあがりました。 デモの評判は上々でEM、CTOに説明し実際にプロジェクトとしてすすめられることになりました。 現状分析 プロジェクト始動後、まず実施することは現状分析とどう移行するかの設計です。ここでのどの程度システムを把握できるかが計画の精度を決めます。しか

エンジニアの成長段階ごとに期待される行動を明文化

Merpay Advent Calendar 2020 の11日目は、メルペイ Solutions Team の apstndb がお送りします。 色々な場所で既に書かれている通り、メルペイはサービス開始当初から主要なデータベースとして Google Cloud Platform(GCP) の DBaaS である Cloud Spanner を使っています。 この記事ではメルペイにおける Cloud Spanner の実行計画の活用のために取り組んだことについて紹介します。 Cloud Spanner の特性である外部一貫性による強い一貫性保証、レプリケーションによる高い可用性、水平分散による高いスケーラビリティ、リレーショナルデータモデルによるスキーマ、フルマネージドなことによる低い運用負荷などは多くの業界にとってメリットがあるものですが、金融サービスであるメルペイも例外ではありません。

こんにちは！ Mercari Advent Calendar 2020 の6日目は、メルカリ Notification チーム/Software Engineer の tarotaro0 がお送りします。 Notification チームは、メルカリのアプリ内通知やメール、プッシュ通知などを扱うマイクロサービスの開発・運用を担当しているチームです。いわゆるバックエンドアプリケーションの開発と、そのアプリケーション・サーバー及びデータベースなど関連サービスの運用を行っています。 Notification チームでは、データベースに Google Cloud Spanner (以下 Spanner) を採用しています。メルカリにおける通知は社内でも特に大きいトラフィック・データ量を扱う領域で、秒間数千にも及ぶリクエストに対応出来るスケーラビリティや高可用性などが求められます。Spanner は

Merpay Advent Calendar 2020 の3日目です。 メルペイでバックエンドエンジニアをしている iwata です。 メルペイスマート払いの開発をしている Credit Design というチームに所属しています。 私は2019年の入社以来、「メルペイスマート払い（定額払い）」（以下、定額払い）の開発を担当しており、今年の７月にようやくリリースすることができました。 この定額払いの手数料計算のために、「1万分の1を1とする単位」であるベーシスポイントを扱うGo言語のパッケージ go.mercari.io/go-bps を作成しました。 ちょうど1年前に、 mercari.go #12 で「料率計算における小数の扱いについて」として発表しましたが、当時はオープンソースとして公開していませんでした。 今回オープンソースとして公開しましたので、改めてパッケージを紹介します。 料

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

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

メルカリで写真検索と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 なぜ機械学習システムのデザインパターンが必要なのか 機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのた

こんにちは。Product Securityチームの@gloriaです。前回、自動化テストエンジニアからセキュリティエンジニアへのキャリアチェンジについて記事を書きました。 今日は、最近OSSとして公開した社内ツールのプロジェクトについてお話をしたいと思います！ 「Testdeck」とは？ TestdeckはGolangで書いたgRPCマイクロサービスのインテグレーションテスト、エンドツーエンドテスト（E2E）とセキュリティテストの自動化ツールです。以下の機能を提供しています： gRPCとHTTPエンドポイントのインテグレーションテスト・E2Eテスト ファズテスト 悪意のあるペイロードの注入（Burp SuiteのIntruderという機能のように） gRPCとHTTPリクエストのユーティリティメソッド CharlesやBurp Suiteなどのデバッギングプロクシーに接続し、リクエストの

この記事は、Merpay Tech Openness Month 2020 の20日目の記事です。 こんにちは。メルペイのVP of Engineeringの木村（@hidek）です。 はじめに メルペイでは VP of Engineering と Engineering Manager (EM)が HR と連携をしながら、エンジニア組織のピープルマネジメントにコミットしています。ピープルマネジメントとは、 採用 → 育成 → 評価 → リテンション → 外へのアウトプット → より良い採用… というサイクルを好循環させながら、組織全体に貢献することと定義しています。 その中で、今回リテンションという観点で EM 間で議論を行い、「ローテーションプログラム」というものを作ったので、その紹介をしたいと思います。 「チャレンジ」のプロセス化 メルペイもプロダクトがリリースされて１年半以上が経ち

この記事は、Merpay Tech Openness Month 2020 の17日目の記事です。 こんにちは。メルペイのSREの駒崎（@komattaka）です。 暑かったり台風だったりと大変な日々が続いていますが、ご自愛ください。 目次 対象読者 得られるもの 説明しないこと はじめに CronJobの仕組 そもそもCronJobとは何か パラメータの解説 CronJobが作成される流れ メルペイでは何に困っていた？ suspend: trueにしていたCronJobがfalseにした後もJobを生成しない (GKE特有) NodeがCluster Autoscalerによって停止されると、そのNodeで稼働していたJob(Pod)のEvictをCronJobが正常終了したと誤解しconcurrencyPolicy: Forbid(Replace)なのに並列稼働した ユースケース別に設

メルペイ エキスパートチームの@tenntennです。本稿は Merpay Tech Openness Month の11日目の記事です。 「プログラミング言語Go完全入門」の期間限定公開のお知らせでも書いたように、メルペイでは、社外の方向けにGopher道場という体系的にGoを学べる場を無償で提供してきました。Goの普及を目的にこれまでに8回開催し100人以上の方に参加していただきました。 また、Gopher道場の動画や資料はGopher道場 自習室として誰でも利用できるようになっており、現時点で300名以上の方が利用されています。 Gopher道場の資料のベースになっている「プログラミング言語Go完全入門」は、2020年7月31日までの限定公開になっていましたが、本日より公開期限を撤廃し、完全公開することになりました。 また、本日8月31日から始まる「Online Summer Int

Microservices Platform Teamの@deeeeeeetと@dragon3です． Microservices Platform TeamではGoogle Kubernetes Engine（GKE）をメインのコンポーネントとして利用し，その上にメルカリとメルペイのMicroservicesを動かすための基盤を構築しています．メルカリのMicroservices化のプロジェクト自体は2年ほど前から始めており，GKEも当時に構築したものを今日まで運用し続けてきました． この2年間でGKEからは多くの機能がリリースされました．その中のほとんどはそのまま有効にすることができますが，中にはClusterを作り直す必要があるものもあります．例えばRoutes-based ClusterをVPC-native Clusterに，Zonal ClusterをRegional Clust

メルカリで写真検索と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 なぜ機械学習システムのデザインパターンが必要なのか 機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのた

こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか？ 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ