タグ

ブックマーク / engineering.mercari.com (6)

  • メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング

    こんにちは!ソウゾウの Software Engineer の @dragon3 です。 連載:「メルカリShops」プレオープンまでの開発の裏側の8日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD (テスト・ビルド・デプロイ)やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は

    メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
    itchyny
    itchyny 2021/08/19
  • Goで高速JSONライブラリを作るためにしたこと | メルカリエンジニアリング

    他にもまだまだあると思いますが、自分が見たことがあるのは上記になります。 それぞれ見比べてみると、やはりエンコード・デコード両方に対応しているライブラリが人気があるようです。 この中で特に人気のある easyjson , gojay , json-iterator/go でベンチマークをとってみた結果、パフォーマンスの良い順に並べると次のようになりました。 gojay > json-iterator/go > easyjson > encoding/json 設計方針の違いがそのまま速度に現れているようにも見えますが、理論上最速にできるはずの easyjson が遅かったりと実装の良し悪しも影響しているようです。 一番遅いのは encoding/json です。そもそも encoding/json が遅いから新しい JSONライブラリを作ろうとしているはずなので、一番遅いのは仕方ないのです

    Goで高速JSONライブラリを作るためにしたこと | メルカリエンジニアリング
  • マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング

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

    マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
  • Go Fridayこぼれ話:非公開(unexported)な機能を使ったテスト #golang | メルカリエンジニアリング

    はじめに メルペイ エキスパートチームのtenntennです。 メルカリグループでは、毎週金曜日にGo Fridayという社内勉強会を開催しています。 毎週やっているとそれなりに知見が溜まってくるので、定期的に”こぼれ話”としてブログを書こうという話になりました。 今回の記事では、先日のGo Fridayで話題にあがった非公開な機能を使ったテストについて扱いたいと思います。 なお、Goにおけるテストの手法やテストしやすいコードの書き方については、GopherCon 2017でも発表があったmitchellhさんの”Advanced Testing with Go”(スライド/動画)が参考になります。テーブル駆動テストやテストヘルパーなど非常に勉強になるので、まだ見たことのない方はぜひスライドや動画をご覧ください。 TL;DR Goのテストではテスト対象とテストコードを別パッケージにできる

    Go Fridayこぼれ話:非公開(unexported)な機能を使ったテスト #golang | メルカリエンジニアリング
  • 「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング

    はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 番環境の住所情報テーブルをdropするまでの作業 今回、番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC

    「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
  • Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング

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

    Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング
    itchyny
    itchyny 2016/02/10
  • 1