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

aws-summit-tokyo-2017-longlogo

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

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

セッション概要

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

スピーカー: 長野 雅広 株式会社メルカリ Principal Engineer / SRE

メルカリは今年イギリスに進出させて頂きました。現在、日本、アメリカと合わせ 3 つのリージョンにてサービスを展開しています。日本、アメリカ、イギリスはそれぞれに合わせた異なるプラットホーム上でサービスを運用していますが、それから共通して使われるマイクロサービスや 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 さんの発表でした。