メルカリのマイクロサービス/Kubernetes運用事例はバイブルだ - orangeitems’s diary
多くの人に見てほしいスライド メルカリのマイクロサービス/Kubernetes運用事例を拝見しました。 speakerdeck.com こちら、中身はメルカリにおけるマイクロサービス・Kubernetesの実際の運用状況をまとめた内容になっています。 この内容が欲しかった。 この世の中で、会社のITサービス基盤をKubernetesにてマイクロサービス化できている企業はほとんどいません。言い切ります。まだ仮想マシンのWEB+AP+DBの3層構成のままです。もしくは、AWS Lambraなどサーバレスでマイクロサービス化した事例は多数出てきていますがこれは基盤にKubernetesが使われている可能性はあるにしろ、ユーザーは意識していません。 Kubernetesをエンタープライズに適用する。このケースではGCEですが企業としてどのようなオペレーションになるのか、どういう思考錯誤があるのかが
Microservices と会計システム | メルカリエンジニアリング
この記事は、 Mercari Bold Challenge Month の18日目の記事です。 こんにちは。メルカリで Product Manager として働いている津田と申します。私は社内で「会計システム」と呼ばれる、会社が運営するサービスに付随して発生した債権債務の増減を記録・集計するシステムを開発するチームで働いています。 はじめに メルカリでは、お客さまの行動に応じて日々さまざまなお金の流れが発生しています。たとえばメルカリで商品が出品され購入された（取引が行われた）場合を考えてみます。 この取引は、会社から見るとそれぞれの相手先に対する債権債務関係の変化と捉えることができます。メルカリにとっては、購入したお客さまに対する債権（= 商品代金）と出品したお客さまに対する債務（= 売上金）が発生します。このとき、商品代金の一定割合（通常は 10%）が販売手数料としてメルカリの売上とな
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
お急ぎ振込の締め処理バッチの事例で見ていく バッチ処理の設計結果 | メルカリエンジニアリング
こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 今回は、前回の記事でお話したことを踏まえ、私が開発を担当して実際に動いているバッチプログラム「お急ぎ振込 締め処理バッチ(以下、締め処理バッチ)」について、述べていきます。 本記事では、「締め処理バッチについて」と「前回の記事に照らし合わせてどう設計されているか」の2点に分けて説明します。内容は、特に記載のない限り、本記事執筆時点のものとなります。 締め処理バッチについて 事例の話に移る前に、これから説明する締め処理バッチの処理がどのようなサービスを提供するのか、ご案内します。 お急ぎ振込とは お急ぎ振込とは、メルカリの中で売り上げたお金を皆様の銀行口座に出金できる機能の1つです。当初から存在している振込申請機能より早く送金することができ、最短1営業日で出金することが可能です。2017年の夏の終わ
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
Hello new logo | メルカリデザイン
みなさまにご利用いただいて、メルカリは6年目を迎えました。 創業以来、世界的なマーケットプレイスの実現を掲げ、フリマアプリ「メルカリ」の地道なアップデートを続けています。 もっとシームレスに、便利に、快適に。今までよりもなめらかな生活の後押しをするプラットフォームを目指し、メルカリは、これまでのメルカリを超え続けていきます。 そんな未来への強い意志を込めて、ロゴの変更を行いました。よりシンプルで、フレンドリーな新しいロゴでお目にかかれることを楽しみにしています。新しいメルカリは、あなたの生活とともに。 これまでの、「箱から飛び出すワクワク」というアイデンティティを残しながら、要素を少なくしていくことで、より洗練されたロゴマークに仕上げ、メルカリの目指すオープンでフェアなマーケットを表現しています。実際に作ったプロトタイプは数百種類。試行錯誤を重ねて新しいロゴマークを決定しました。
メルカリが「マイクロサービス」に本気で取り組む理由
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
メルカリiOSのUIテスト自動化をまるっとご紹介します！ | メルカリエンジニアリング
こんにちは、メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の 根本 征 です。 私は普段、テスト自動化・CI / CD改善・その他社内の生産性を上げるための自動化を行っています。 今回はiOSのUIテスト自動化について、最近の改善をまとめてご紹介したいと思います。 ざっくり言うと HTMLレポートに出力し、失敗原因を見やすくするようにしました リトライ実行するためのfastlaneプラグインを作りました テスト実行環境をJenkinsからCircleCIに移行しました Slack Commandを使って、簡単に実行できるようにしました これまでのiOSのUIテスト自動化 AQA(旧QA-SET)では去年から、JP版アプリ(iOS / Android)のUIテスト自動化に取り組んでいます。 去年のMercari Tech Conf 2017では、
Microservice で実現するメルカリオファー機能 | メルカリエンジニアリング
こんにちは、 Backend Engineer の @vkgtaro です。 メルカリでは今まで PHP で開発されたモノリシックな API に対して機能を追加してきたのですが、今後メルカリのシステムを Microservices 化していくその先駆けとして、Offer という新機能を Microservices Platform 上で開発・リリースしました。Offer は今までコメント欄でなされていた値下げ要求を機能としてできるようにしたもので、出品者から承諾が得られれば Offer した金額で購入できるというものです。受け取った人はもちろん断ることもできます。 2018/07/10 現在、「インテリア・住まい・小物」カテゴリーにて使用可能になっています。 今回はこの機能を実装するにあたってやったことをいろいろ振り返ってみようと思います。 ざっくり全体像はこんな感じになってます。 端末と
こんなに恵まれているのに何もしないのか―メルカリCEOの原体験 - Yahoo!ニュース
フリマアプリ大手のメルカリが6月19日、東証マザーズに上場した。2013年7月のサービス開始からわずか5年。時価総額でマザーズ首位に躍り出たベンチャーは、調達資金をテコに急ピッチでグローバル化を進める。けん引する山田進太郎代表取締役会長兼CEOとはどんな人物なのか。なぜ世界を目指そうとするのか。その実像に迫る。（井上理／Yahoo!ニュース 特集編集部） 「ここまで必死にやってきたので、自分でも整理できていないことが多いのかもしれません。いい機会なので、何でも聞いてください」――。今年4月、東京・六本木ヒルズのメルカリ本社を訪れると、創業者で代表取締役会長兼CEOの山田進太郎はそう言って出迎えた。メルカリが6月に東証マザーズに上場することは正式発表前だったが、既にこのとき多くのメディアがそう報じていた。もちろん、山田は上場について具体的なコメントをすることはなかったが、この後に予定された大
トップメッセージ
メルカリ10周年、創業者山田進太郎から皆さまへ メルカリを創業する前に世界一周をしていた時、地球資源が限られているなかで新興国の全員が先進国と同じように豊かに暮らすことは難しいことだと感じました。ただ、帰国後にスマートフォンの急激な普及をみて、テクノロジーの力で限りある地球資源をなめらかに循環させることができるのではと考えました。そうすることで世界中で豊かな社会を実現し、一人ひとりが持つ可能性はもっと広がるのではないか。そんな想いから小さな雑居ビルの一室で、仲間たちと立ち上げたのがメルカリです。 あれから月日が経ち、メルカリは創業10年を迎えることができました。リリース初日に数百のダウンロードだったフリマアプリ「メルカリ」は、今では日米で毎月2,500万人以上のお客さまにご利用いただき、自分にとって価値が無くなってしまったものが他の誰かの役に立つ、「モノ」の循環が生まれています。 日米フリ
ImageFluxを利用した画像配信の最適化〜動的リサイズとWebP変換〜 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はメルカリにおける画像配信とImageFluxを利用した画像の動的なリサイズとWebP変換の導入によってアプリのデータ通信量を大幅に削減した事例について紹介します。 ImageFluxはクラウド画像変換サービスです。URLに画像変換用のパラメータを組み込むことで画像データの拡大・縮小やオーバレイ、フォーマット変換等が実現できます。 メルカリにおける画像データ メルカリのアプリ上で発生するデータ通信の大部分はタイムラインや検索結果に表示される画像データが占めています。種類はいろいろありますが例えば、 商品画像 プロフィール画像 バナー画像 といったものが挙げられます。特に商品画像はデータ量がとにかく多く、毎日百万個単位で増加するほか、タイムラインや検索結果をはじめ、多くの機能で活用されています。 ImageFluxを利用した画像変換でデータの通信
メルカリチャンネルにおけるFirebaseの利用例 | メルカリエンジニアリング
Mercari Advent Calendar 2017 の16日目は@sota1235がお届けします。 この記事では私のチームが開発しているメルカリチャンネルでFirebase Realtime Databaseを使うにあたり行っている工夫をご紹介します。 同じ文脈の話を今年のPHPカンファレンスでも発表したのですが、この記事ではその時お話できなかったもう少し細かい工夫を4つ紹介したいと思います。 Realtime Databaseへのリクエストを間引く Realtime Databaseは非常に高トラフィックな通信を捌くことができます。 とはいっても無尽蔵にデータ更新処理をしたり読取処理をできるわけでは当然ありません。 メルカリチャンネルでは以下のように多くの用途にRealtime Databaseを利用しています これらを全て素直にRealtime Databaseに書き込むとすぐに
US版Mercariのリニューアルと今後 (サーバサイド)
この記事はMercari Advent Calendar10日目の記事です。昨日は@syu_creamのメルカリのデータ分析基盤の紹介〜BigQuery周辺の話〜でした。 本日はUSサンフランシスコのサーバサイドエンジニア@deme0607が、今年2017年にリニューアルしたUS版Mercariのサーバサイドについてご紹介します。 現在のアーキテクチャ Brand new US Mercari (Android 編)でもご紹介したように、US版Mercariは今年、より一層USマーケットにフィットしたアプリを提供しUSでの成長を加速すべく、大きなリニューアルが実施されました。前述の記事はAndroidアプリのリニューアルに関するものですが、iOSアプリやAPIサーバも同様にリニューアルしています。 以下の図は、リニューアル後のUS版Mercariのサーバサイドアーキテクチャです。 ここでは
メルカリのCRMツールをKaizenした話 | メルカリエンジニアリング
こんにちは、こんばんは。 サーバーサイドエンジニア（社内ではAPIエンジニアとも呼称します）の@bravewoodと申します。一部の人からはウッディと呼ばれていて気に入っております。 キャリア初期にウノウラボに大変な憧れを抱いていた身としては、ウノウの流れをくむメルカリでこうしてBlogを書くことができ感動しきりです。 さて、本日はCRMツールについてお話しします。技術的な話は少なめで、CRM周りの開発やPlanningについてざっくりとお話しします。 APIエンジニアとは まず、メルカリ社内においてAPIエンジニアとは、商品や取引などの各種データや機能を各クライアントから呼び出すための「API」を開発することを主としたエンジニアを指します。 クライアントにはiOSやAndroidのアプリとWeb、その他複数のサブシステムがあり、各担当のエンジニアと密に連携を取り、高速かつ安定したAPIを
AMP Conf 2017へ行ってきました #AMPConf | メルカリエンジニアリング
こんにちは、Software Engineerの @yui_tang です。 3月7-8日にニューヨークにて開催されたAMP Conf 2017に参加してきましたので、そのレポートを書きたいと思います。 メルカリでのAMPの取り組み まずは、現在までのメルカリにおけるAMP(Accelerated Mobile Pages)の取り組みについて簡単にお話します。 2016年7月にメルカリのWebサイトの一部に導入を開始し、現在AMPページには数万PV/日のアクセスがあります。 メルカリ内の商品毎のページが全てAMP対応しているため、そのページ数は相当数に上ります。 流入経路ですが、現在元ページにlink rel="amphtml"を設定しているのみで、メルカリのサービス内にAMPページへのリンクは露出していません。 よって全てが検索流入となっており、事実上ランディング用のページとして機能して
メルカリの世界展開を支える開発チームの今とこれから｜CTO 柄沢聡太郎 #mercariday | mercan (メルカン)
メルカリの中で働くメンバーが、日々どのようなことを考え、どのようにチャレンジしているのかを紹介する場として初めて開催した『Mercari Day 2017』。 本稿では、CTOの柄沢聡太郎が登壇したセッション「Mercari – Moving Beyond Borders」の模様をお届けします。 メルカリでは、日本、US、UKと文字通り「国境＝Borders」を越えたプロダクト開発を行っています。その中心を担うエンジニアリングチームがどのように作られているのかをご紹介しましょう。 speakerdeck.com 体制について～US、UKと拠点が広がっても「開発の中心は日本」 柄沢が最初に話したのは、3拠点におけるエンジニアリングチームの人数や役割について。拠点数が増えた今、これまでと何が変わり、何が変わっていないのかを説明しました。 僕がメルカリにジョインしたのは2年前の5月。もうすぐ2年
Gaurun Powered by HTTP/2 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。つい先日メルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバであるGaurunがGCM、APNsともにHTTP/2を利用したプッシュ通知に対応したので紹介します。 github.com ちなみにロゴも出来ました。 Gaurun〜A general push notification server in Go〜 繰り返しになりますが、GaurunはメルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバです。GCMやAPNsへのプッシュ通知処理をHTTP + JSONベースの非同期処理APIでラップして大量のプッシュ通知を素早く送信することができるのが特徴です。 github.com メルカリのプッシュ通知のシステムもこのGaurunにより構築されています。クライアントとの通信に
#attefes Mercariのatte FeS【Go・Swift開発編】行ってたけど最高 - timakin.log
どうもtimakinです。先日株式会社メルカリ様のグループ企業である、 ソウゾウ様の、「メルカリ アッテ」リリース記念のMeetupに行ってきました。 控えめにいうと最高で、技術勉強会という面から見ても非常に記憶に残る会でした。 何が最高だったか ・Go,GAE,RxSwiftという、本番導入の際に目新しさがありつつも、それをどう導入検討したか、実際書くときにどんな機能でそれが必要かが詳細に語られていて、実際に自分たちも使える可能性があるな、と強く意識できた点。 ・技術要件だけでなく、ビジネス要件、組織として最適な形であるためにどんな技術を選択するべきか考慮された話だった点。 ・技術面のトークに終始しており、参加者側として集中が途切れなかったところ。（むしろアッテ自体の紹介やリクルーティングの時間がほぼなかったのですが、逆に技術的なアピールポイントがあれば人は自然と寄ってくるという余裕があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フリマアプリ「メルカリ」の急成長を支えるエンジニアリング
