Pinterest のスケール
V 先生から教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います。
本題に入る前に、Python には The Zen of Python (日本語) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。"Simple is better than complex" です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。
Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android アプリ公開等のサービス拡大時にも少ないエンジニアリングで柔軟に対応できたのかと。これはあくまでもイメージでしかありませんが、AWS 上でスケールアップできるところまでスケールアップし、限界が見えたところでスケールアウトで最小限のエンジニアリングコストをかける。インフラで解決できるところはインフラで解決しているというイメージです。Pinterest のスライドでは、インフラをシンプルに更改した過程が紹介されています。
>>> インフラの遷移
- 2010/05: 創設
-
- RackSpace
- 小規模な Web Engine × 1
- 小規模な MySQL DB × 1
- 2011/01: AWS へ
フロントに nginx を立て垂直分割、MySQL をマスタースレーブ構成に垂直分割、ヘビーな処理をタスクキューに分割、MongoDB を導入。 -
- Amazon EC2 + S3 + CloudFront
- nginx × 1
- Web Engine × 4
- MySQL: Master × 1 / Slave × 1
- Task Queue × 1 / Task Processors × 2
- MongoDB × 1
- 2011 年後半: ターニングポイント
LB, Web サーバを増加、MySQL をシャーディングにより水平分割、Cassandra, Membase, Redis 等の分散型KVS を導入、MongoDB をクラスタ化。 -
- Amazon EC2 + S3 + CloudFront
- nginx × 2
- Web Engine × 16 / API Engine × 2
- MySQL: シャーディングした Master × 5 / Slave × 9
- Cassandra × 4
- Membase × 15
- Memcache × 8
- Redis × 10
- Task Router × 3 / Task Processors × 4
- Elastic Search Nodes
- Mongo クラスタ
NoSQL 大好きですね。スライドには " It will fail. Keep it simple. " という教訓が書かれています。今後このまま利用するテクノロジーを増やしていくと、運用や変更コストがすごいことになります。2012/01 に以下のようなシンプルな構成に変更したそうです。
- Amazon EC2 + S3 + ELB, Akamai
- Web Engines × 90 / API Engines × 50
- MySQL: 66 (各 1 台のスレーブ)
- Redis × 59
- Memcache × 51
- Redis Task Manager (pyres) × 1 / Task Processors ×25
- Sharded Solr
Instagram 同様 nginx から ELB に変更、CDN を利用、Web サーバの更なる増加、MySQL のレプリケーション方法を変更、KVS を Redis に統一、タスク管理も Redis へ、memcache の増加、Elastic Search から Solr へ変更。だいぶシンプルになってます。ELB は大人気ですね。また、Pinterest も Instagram 同様 KVS は redis に統一しています。シンプルです。
Pinterest がどのインスタンスを使っているかについては MySQL しか書いてありませんでした。Instagram は超ハイエンドモデル 12 インスタンスで運用しているのに対し、Pinterest はハイエンドモデル 132 台です。双方のデータ量も QPS も分かりませんが、Pinterest が超ハイエンドモデルに切り替えた場合の、運用コスト (メンテナンスコストを含む) を比較したら面白そうです。
参考: Extra Large インスタンス
- 15 GB メモリ
- 8 ECU（2 ECU × 4仮想コア）
- 1,690 GB インスタンスストレージ
- 64ビット プラットフォーム
- I/O 性能: 高速15 GB memory
Instagram が PostgreSQL で利用している Cluster Compute Quadruple Extra Large インスタンス
- 23 GB メモリ
- 33.5 EC2 Compute Unit（2 x Intel Xeon X5570、quad-core「Nehalem」アーキテクチャ）
- 1690 GB インスタンスストレージ
- 64ビット プラットフォーム
- I/O 性能: 超高速（10 ギガビットイーサネット）
>>> インフラの選択
スライドには各インフラを選択した理由が書かれています。Pinterest が技術を選択した理由に "Well known and well liked" があげられています。この選択方法は私も大好きです。以下抜粋
- AWS
-
- 信頼性が高く、報告やサポートが素敵
- 必要なものがそろってる
- 新しいインスタンスが数秒で起動する
- 選択肢が限られている w
- MySQL
-
- Well known and well liked
- データの損失が皆無
- XtraBackup (ノンブロックバックアップ), innotop (MySQL 用 top コマンド), Maatkit (管理用便利コマンド類) 等の素敵なソフトがある
- コミュニティが活発
- Percona のサポートが素敵
- memcache
-
- Well known and well liked
- 成熟している
- めったに落ちない
- redis
-
- Well known and well liked
- 使いやすいデータ構造
- 永続化とレプリカができる
- 一貫してパフォーマンスが高い
>>> MySQL のスケール
特に MySQL は重点的に解説しています。MySQL クラスタとシャーディングを比較し、シャーディングを選んでいます。クラスタを選択しなかった理由は、
- まだ出来たばかりの技術
- コミュニティによるサポートが少ない
- 運用レベルのエンジニアが少ない
- アップグレードが難しいし怖い
- 単一障害点になりえる (ここもうちょっと詳しく聞きたい)
とのことです。
またシャーディングの選定理由は、
- データベースを分割し、より多くのキャパを追加できる
- 高可用性
- ロードバランシング
- データ配置のアルゴリズムがシンプル
- ID 生成がシンプル
Pinterest では 512 個の DB を 8 台の物理サーバでシャーディングし、各ノードを Multi-Master レプリケーションで HA 構成にしているそうです。スライドには "Clustering is scary." という教訓で締められています。
うーむ。。。フェイルオーバ等 Multi-Master の制御をどうしているのか気になります。mmm? 私は Multi-Master を止めてクラスタを検討中なので、この辺りは再度勉強します。
追記:
- @methane 先生より ELB が素敵な理由: "@voluntas nginx使うと、バック側のWebサーバー一覧をnginxに教えないといけないんだけど、ELBを使うと負荷に応じてAWSが勝手にWebサーバー立ち上げてELBの分散対象に追加したり、逆に減らしたりしてくれるんです。"
参考:
--
ところで、AWS に興味がある方向けに "エンジニアオープンハウスイベント" ってのがあるみたいです。2012年4月21日 （土）10:00〜12:30 に "運用・施設＆機械・インフラネットワーク系技術対象" ってのがあって、色々と AWS 中の人からインフラ系のお話が聞けるみたいです。どうしよう。
コメント
コメントを投稿