【レポート】AWS Summit Tokyo 2017: [メルカリ] Cloud connect the world as a Glue #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、Dev Day トラック 2のセッション、「 [メルカリ] Cloud connect the world as a Glue」をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

発表資料

発表者の紹介

• @kazeburo
• Mercari, Inc, Pricipal Engineer, SRE チームに所属
• BASE, Inc Technical Advisor

所属しているSRE Teamの紹介

• Site Reliability Engineeringの略
• GoogleのBen Treynorが提唱
• Googleの各種サービスを横断してSoft Engineeringの力を使ってサービスの信頼性を向上

Google 発祥の SRE

• オライリーから出版されている http://landing.google.com/sre/book.html
• ソフトウェアエンジニアと同等の技術力を持っている
• オペレーション業務は50％以下。残りはソフトウェアの信頼性向上にあてる
• エラーバジェットという考え方 − リリースにバグはつきもの
  • SLAを設定し、SLAを超過しない限りリリースしてもOK
  • 安定派と変更派の利害を一致させる

メルカリにおけるSRE

• 新規サービスの開発以外のエンジニアリングは全部やる
• 2015/11 インフラチームからSREへ名称変更。
• インフラよりもサービス指向。サービスが中心
• 現在は6人と少ない。絶賛募集中

SRE の業務範囲

• 基盤の構築
• 新しいミドルウェアの開発
• etc.

Agenda

• メルカリとは / 世界3拠点での開発運用体制について
• メルカリのアーキテクチャ / クラウドの利用
• 距離を超える、世界を繋ぐシステム

メルカリについて

• 国内最大級のフリマアプリ
• スマホで簡単に出品できる
• メルカリが仲介して安心・安全な決済を実現

Mercari KPI

• ダウンロード数:6500万DL
• 出品数:1日100万品以上
• GMV(総取引額):月間100億円以上

日本最大のフリマアプリ

• 1日に100万以上の出品
• 1分間に1,200品以上(ピーク時間帯)

出品からすぐに売れる

• 売れた商品の50％は24時間以内に取引成立

Global Service

• JP
• US
• UK : 2017/03/15サービス開始

Global Development Team

• Tokyo
  • 開発の中心
• San Francisco
  • 言語だけでなく、文化・習慣に合わせたローカライズ
• London
  • サービス立ち上げ
  • 法令に合わせたローカライズ

London

Global Developmentの難しさ

• 時差のため3拠点揃って顔を合わせることはかなり難しい
• どうやってかいはつをすすめているの?
• 東京が開発の中心
• 現地採用、出向者、長期出張

Global Developmentの進め方(1)

• クラウドを活用してコミュニケーションを図る
  • 太平洋・大西洋をまたいだ非同期な Pull Request レビュー
  • Slack
  • Video Conference
  • リモートペアプロ(画面共有しながら)iOS/Androidチーム

Global Developmentの進め方(2)

各リージョンが自立して課題解決する

• 個人がフルスタックではなく、チームとしてフルスタック(PM、クライアント、サーバーサイド)
• チームまるごと出張＆集中して開発
• iOS/Androidはリージョン毎にブランチを分けて、作業が競合しないようにする

SRE はどうやっているの?

• 東京拠点
• 6人のうち一人がUSに長期出張中
• USメンバーは US サービスのヘルプもしている
• 週1でUSとsync MTG
  • 日本の朝
  • USの前日夕方
• UKとは案件ベースでMTG
  • 日本の夕方
  • UKの同日朝

Mercari Architecture

Infrastructure

• JP/US/UK それぞれ別システム
• ハイブリッドかつマルチクラウド
  • JP:さくらインターネット石狩DC.物理サーバー
  • US:AWSオレゴンリージョン
  • UK:GCP

歴史的経緯:1

• 2013/07 JP リリース
• さくらインターネットのVPS 1台にWeb/DBすべてのせた
• インフラ専任者がいない中で身近な技術を選択
• リリース後2ヶ月でさくらクラウド専用サーバに移行

歴史的経緯:2

• 2014/09 USリリース
• 当初からAWS(Oregon)でサービス構築
• JPリリース当初に比べ、エンジニアが増え、AWS経験者が多い
• とはいってもインフラ専任は少ないため、AWSマネージド・サービスを多く利用してサービスを構築
• USの専用サーバ利用も検討したが、サービスの予想をしにくいため

歴史的経緯:3

• 2015/02 スピーカー入社
• さくら・AWSのハイブリッドインフラを進化させ、ハイブリッド構成の信頼性とスケーラビリティを向上させた
• 2017/03 UKリリース
• UKでは新しい技術チャレンジとしてGCPを採用

アーキテクチャー

• すごくシンプル
• 3層+α

3層＋αなシンプルなアーキ

• リバプロ
• アプリ
• DB
• スケールアップとスケールアプトを行う斜め(Diagonal)のスケール指向
• 物理サーバーのDBにはioMemory NVMeを採用したサーバを採用

US/UK

• JPのアーキを基本的に踏襲
• AWS EC2/GCP GCEを中心とした構成
• US独自のサービスや中・小規模DBにはAWS RDSを利用
• UKでは法令的な面からCloud Load Balancerを利用 https://cloud.google.com/load-balancing/
• ただし下回りは全部同じ

なぜこのようなアーキテクチャーになっているのか?

• 少数精鋭(6人)のSREですべてやる
• メンテナンス・スケーラビリティーを共通化
• Ansible Playbook 再利用
• 日本の実績ある構成を海外にも流用
• 実際、USでのApp Storeランキングで昨年3位になったが、問題なく運用できた
• EC2のIaaSとしてのパフォーマンス、信頼性はかなり向上している

メルカリアーキのまとめ

• 3リージョンで採用するインフラストラクチャーが異なる
  • サーバを中心としたアーキテクチャーを採用
  • クラウドらしい設計はしていない
  • 運用の共通化と省力化
• クラウドを積極的に使っていない?
  • サーバーをまとめるためのものとしてはクラウドを積極的に利用している

Mercari Global Infrastructure

• 各リージョンのインフラは独立している
• データをサービスを行う域内に留める必要性
• 幾つかのクラウドサービスを共通して利用

Global Infrastructure

共通アーキテクチャーの最上位と最下位(Route53, S3)はAWSの信頼性のあるサービスを利用

• common:DNS:route 53
• common:Akamai, CloudFront
• サーバーが中心:Sakura/AWS/GCP
• common:Analysis:Google BigQuery
• common:Storage: S3

Amazon Route53

• 高い可用性と信頼性のDNS
• Roadworker で設定管理
• Routefile変更のPR -> GitHub -> Travis-CI -> Route53 という流れ
• CI を経由して自動反映

https://github.com/codenize-tools/roadworker

Amazon Route53 + healthcheck

• DNS-Round Robin運用時の問題点
  • サーバー障害時にLBの変更のようなDNSの書き換えに時間がかかる
  • DNS書き換えのパイプラインの途中でつまることもありえる
  • マイクロサービス化にともない、様々なクライアントがサーバーと通信する
  • ブラウザのような一部クライアントはDNS-RRと相性がよいが、多くのクライアントはDNS-RR障害時に再接続しない
• Route53のHealth Check機能を使って解決するよう検証中

内部DNS

• すべてのサーバにunboundを導入
  • キャッシュと可用性の向上
• unboundがリクエストを振りわけ
  • *.localはBIND
  • *.consulはconsul

内部DNSでCNAME

• 内部DNSでエンドポイントのCNAMEを設定
• アプリケーションから接続はCNAME経由
• エンドポイントの管理はアプリケーションではなくDNSにまかせ、エンドポイントをスムーズに変更させる

Amazon S3

• これがないとあらゆるサービスが動かない
• 高い可用性と信頼性のストレージ
• IAMを利用したアクセス管理
• 疎結合

商品画像

• 数百万枚/day
• 同期処理。並行して画像加工処理をしてS3にPUT

ログ

• 1TB/day 以上
• fluentd > logサーバー > batch+aws-cli/awscli > S3

バックアップ

• 1.2TB(圧縮済み)/day 以上
• 古いデータは間引く

Amazon S3 as a Hub

• S3をハブにしてデータを中継
  • 新規システムのデータ
  • 物流・決済のようなパートナーの古いシステムはSFTP経由
  • consul の設定ファイルの配布

機械学習への取り組み

• 行動解析してユーザーが探しているものを検索結果として返す
• 出品時に参考価格を提示

距離を超えて世界を繋ぐ

距離とレイテンシ

クラウドをどう効率的に使うのか?

• 光は 50 msecに地球半周もできない。
• 日本からアメリカ東海岸まで光速で移動しても 50msec
• データセンター間、クラウド間の距離が有る場合に、レイテンシーを下げたい

国内外のレイテンシ

• 実際の数値は一部適当
• 太平洋・北米、大西洋はもとより、石狩も遠い

距離が離れているとHTTPS通信が遅い

• RTT 26 msec のときに、HTTPS通信を行うと 200 msec 以上かかる
• HTTPS通信では通常のTCPハンドシェイクに加え数回のやり取りが必要
• mercari APIのレスポンスタイムは(90 percentile)100 msec程度
• 一番アクセスの多いAPIは 50 msec 程度
• アプリからさらにHTTPSの通信時間を上乗せしたくない

遠距離接続するユースケース

• リージョンまたぎ
• アプリケーションから他のクラウドにアクセス
  • SaaS
  • マイクロサービス

どうやれば速度改善できる?

• CDNを利用
  • AWS CloudFront, Akamai, Fastly
  • コストの高い通信はクライアントの近くにあるエッジサーバーと行う
  • CDNとOrigin間はコネクション集約や専用ネットワークを利用
• MercariはCDNを利用

MercariでのCDNの利用

• URLのパスによってオリジンを切り替えている

アプリケーションからクラウドへのアクセスを改善

• KeepAliveでHTTPS通信したい
• PHPの KeepAliveは難しい
  • リクエスト処理後にメモリがクリアされ、TCP接続も切れる。使い回しが難しい
  • mod_php はマルチプロセス。KeepAliveしても、次のリクエストでKeepAliveしているプロセスにあたるヒット率が非常に低い
• 接続の Connection Poolingを目的としたProxy Server"chocon"を開発

chocon

• https://github.com/kazeburo/chocon
• Goで実装した proxyserver
• プライベートネットワークは HTTP、グローバルネットワークでは KeepAlive
• 東京-石狩間の通信が 248msec->21msecに短縮された

なぜ chocon を作ったの?

• HTTPSはクライアントとサーバー間でend to endの暗号化通信。ユースケースにぴったりなミドルウェアがない
• Go標準のHTTP/2による集約、非同期処理による高速なアクセス
• chocon 利用によりRTTに近い速度まで改善
• 遠距離通信が高速化したことにより、レイテンシーを気にせずに外部サービスを利用できるようになった

まとめ

• メルカリはJP/US/UKの3拠点でサービス展開、開発
• クラウドによらずサーバー中心とした共通アーキテクチャー
• グローバルでは route53, S3の信頼性の高いサービスを利用
• 世界を結ぶために各種クラウドサービスを利用し、足りないところは自社開発で補完
• SRE のメンバー増やしたい

感想

日本・ベルリンの2拠点でサービス開発するチームに所属する身としては、3拠点開発の話は参考になりました。 最近まで日本・バンクーバー・ベルリンの3拠点開発で、その時と会議時間帯が一緒だったのには親近感を覚えました。(所属チームではさらにバンクーバー・カナダMTGもやっていました)

S3/EC2/CloudFront/Route53というAWSのコアサービスの上にシステムを構築し、サービス要件が厳しくないものはRDSで済ませるなど、適材適所でサービスを使い分けているのも、見逃せないです。

通信のボトルネックを見つけ、ツール(chocon)開発して、解決するという、まさにSREな @kazeburo さんの発表でした。