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 中の人からインフラ系のお話が聞けるみたいです。どうしよう。

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM
続きを読む

財務諸表 (Financial Statements)

※ 業務 & 英語の勉強 財務諸表 (Financial Statements) の種類 諸表名 英語表記 概要 損益計算書 Profit and Loss Statement [P/L] ※ Income Statement など様々 収益と費用の状態を表す 貸借対照表 Balance sheet [B/S] 資産、負債、純資産を表す キャッシュ・フロー計算書 Cash flow Statement [C/S] 資金の増減を表す 株主資本等変動計算書 Statements of Shareholders' Equity [S/S] 純資産の変動状況を表す 損益計算書 損益計算書とは 収益から費用を差し引いた利益を計算するためのもの 利益 (profit) = 収益 (revenue) - 費用 (expense) 損益計算書の構成 記載内容 英語表記 概要 売上高 Sales 販売した財やサービスの金額 売上原価 Cost of Sales 財やサービスを生み出すための経費 期首繰越高＋当期仕入高－期末棚卸高 - 売上総利益 Gross Profit = 売上高 - 売上原価 ※ 売上高総利益率 [ 粗利益率] (Shareholder Equity Ratio) = 売上総利益 / 売上高 販売費及び一般管理費 Selling and General Administrative expenses [SGA] 売上原価以外の企業を運営するための経費 販売費: 販売手数料、広告宣伝費など 一般管理費: 人件費、福利厚生費、交際費、賃借料、減価償却費、雑費など - 営業利益 Operating Profit = 売上総利益 - 販売費及び一般管理費 営業外収益 Non-operating income 本業以外で経常的に発生する収益 受取利息、有価証券売却益、配当金、不動産賃貸収入など 営業外費用 Non-operating expense 本業以外で経常的に発生する経費 支払利息、有価証券売却損など - 経常利益 Ordinary Profit = 営業利益 + 営業外収益
続きを読む

Django と Python 3 - #python_adv

Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログ にも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.utils 配下が軽くなっていくんでしょうかね (現在は 3 サポートのためにさらに増えてる)。 バージョン 下位互換 Python サポート 2.5 2.6 2.7 3.2 3.3 Django 1.4 > 1.2 ○ ○ ○ - - Django 1.5 > 1.3 - >= 2.6.5 ○ >= 2.7.3 △ 実験的 △ 実験的 Django 1.6 > 1.4 - >= 2.6.5 ○ >= 2.7.3 ○ ○ Python 2.5 系を利用している場合は、1.6 のリリースまで (2013 後半ぐらい?) に Python 2.6.5 以上 (2.7.3 以上を強く推奨) への移行が必要です。1.5 は今月 (2012/12) 中にリリース予定とのことなので、今のうちに Python 3 へ移行方法を抑えときたいなと。以下 Django ドキュメントの翻訳作業がてら " Porting to Python 3 " を元にご紹介。さすが
続きを読む