本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日　CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない

インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。 SREとGoogleのSRE Site Reliability Engineerは日本語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日本ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。中でもSREのパイオニアとしてGoogleのSREチームが有名です。 GoogleのSREチームはGoogleの検索、広告、Gmail、YouTube、App Engin

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

こんにちわ、@t32kです。先日、3/18に大阪で開催されたFRONTEND CONFERENCE 2017に登壇してきました。また弊社メルカリは懇親会スポンサーでした。今回は『スタンドアロンAMPのススメ』というタイトルで講演した内容をシェアしたい思います。 私が所属しているソウゾウ社ではメルカリアッテというクラシファイドサービスを作っています。メルカリは配送システムを介して売買しますが、こちらは直接会って手渡しでモノの売り買いができます。もちろん、手数料や配送料はかかりませんので、よろしかったら使ってみてください。私はそこのWeb担当で、本サイトのAMP実装について話します。 今日のアジェンダです。 AMPのメリット 表現力について テンプレート分散について 構造化データについて まとめ といった内容でやっていきたいと思います。 AMPとは？ まずはAMPとは何か説明します。AMPとは

OpenRestyはnginxのほかにngx_luaをはじめとするCで書かれた各種サードパーティモジュールとngx_luaのAPIを利用したrestyモジュール、そしてLua/LuaJITで構成されています。 OpenRestyに含まれているnginx自体は本家のnginxと基本同じなので、別にOpenRestyを利用しなくても自分でngx_luaを組み込んだり、サーバ上にrestyモジュールを配布することで似たような環境を構築することは可能ですが、OpenRestyであれば主要なモジュールやライブラリが./configure、make、make installの一連の流れですべてゴソッとインストールされますし、OpenRestyのconfigureスクリプトはnginxのconfigureスクリプトを継承したものなのでnginxのconfigureオプションをほぼそのまま利用することもで

SREチームのcubicdaiyaです。 今回は本ブログでも何度か紹介しているGaurunを利用したメルカリのプッシュ配信基盤とGaurunのパフォーマンスを最大化する方法について紹介します。 github.com 改めて紹介するとGaurunはスマホアプリ向けのプッシュ通知サーバです。APNsやGCMへのプッシュ通知処理をHTTP + JSONベースのAPIでラップして大量のプッシュ通知を素早く送信することができるのが特徴です。 メルカリのプッシュ配信基盤 メルカリのプッシュ配信基盤はnginxによるL7ロードバランサーとGaurunで構成されています。 APIサーバ（e.g. 商品の購入や発送等のイベント通知）やジョブワーカ、バッチ（e.g. キャンペーン等による一斉配信）からはGaurunが提供するHTTP + JSONベースのAPIを利用してiOSやAndroidの端末へのプッシュ

SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with

SREチームの@siroken3です。以前ご案内したWEB+DB PRESSの連載第2回が2016年6月24日(金) 発売のVol.93 に掲載されます。 gihyo.jp 第2回目は @siroken3 が書かせていただきました。 今回の記事はデータベースのスケーリングと題して、Webサービスの拡大に伴ってデータが増え続ける中でも高いパフォーマンスを保ったまま安定して運用し、サービスの機能を改善し続けるための一般的な話題とメルカリでの具体例を解説することを念頭において執筆しました。 なぜスケーリングが必要なのか、その考え方についての解説から始まり、スケールアップとスケールアウトについてそれぞれメルカリでの具体的な事例を交えて留意点、スケーリングの判断材料となるモニタリングについて解説しています。少し毛色が変わったところとしてAmazon RDSをやめた時の具体的な手法についても書かせてい

みなさんはプログラマーの三大美徳ってご存知ですか? プログラミング言語Perlの作者である Larry Wall が↓で述べたのが最初とされています。 http://www.perl.com/pub/1998/08/show/onion.html 三大美徳として 怠惰(laziness) 短気(impatience) 傲慢(hubris) があげられています。 今回はそのうち怠惰(laziness)についてお話します。 怠惰(laziness) 怠惰といえば怠け者。怠け者といえば怠け者メガネ。怠け者メガネを使えば誰でも簡単に美徳を手にいれることができます。 この怠け者メガネを使うと視線は前方に向けたまま下方を見ることができます。 本来は寝転がってテレビを見るために開発されたようです。 この怠け者メガネを使ったプログラム開発について説明します。 レベル0 怠け者メガネを装着せずに作業します。

SRE(Site Reliability Engineering)チームの@cubicdaiyaです。今年のはじめから開発しているWidebulletというシンプルなAPI Gatewayを紹介します。 WidebulletはJSON-RPCをベースにしたシンプルなAPI Gatewayです。Goで書かれています。 github.com JSON-RPCはJSONによるRPC(Remote Procedure Call)プロトコルで、リクエストやレスポンスのボディに含まれるJSONを利用してクライアント/サーバ間の通信を行います。 # リクエストボディ { "jsonrpc": "2.0", "method": "echo", "params": {"msg": "ok"}, "id": "1"} # レスポンスボディ {"jsonrpc": "2.0", "result": "ok",

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により構築されています。クライアントとの通信に

原稿の執筆が一段落して心に余裕が出てきた@cubicdaiyaです。 今回はサーバを運用しているとありがちなページキャッシュに関する問題とメルカリのアプローチについて解説します。 Fluentdによるログ転送 話は変わりますが、メルカリの各サーバ上ではプログラムが吐いたログデータをKibanaやNorikraといった各種コンポーネントに転送するためにFluentdが稼働しています。各ログデータは原則単一のファイルに追記されてFluentdのtailプラグインによって各所に転送されていきます。 ログデータのサイズはまちまちで、1日で数GB程度のログデータもあれば数十GB以上のログデータもあります。 ページキャッシュと巨大なログファイル 各サーバに吐かれるログデータのサイズはサーバに搭載されているメモリのサイズと比べると1日分だけでもかなりの量になります。そして、このように絶えず書き込まれる巨