Instagram のスケール正攻法

Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。

Instagram の哲学は

  1. シンプルであること
  2. オペレーション負荷を最小化すること
  3. すべて装備

とのこと。

Instagram は以下の OSS, サービスで構築されているようです。

>>> OS / ホスティング

Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だから" だそうです。

ハードウェアの選定、導入、セットアップの手間も省けますし、パッケージ管理等の運用も軽そうですね。

>>> ロードバランサ

Amazon ELB を利用。もともとは DNS ラウンドロビン + nginx のロードバランサでバランシングしてたらしいですが、DNS の更新が遅いので止めたとのこと。nginx の負荷を軽減するために SSL も ELB までで、あとは HTTP。ELB はほんと素敵なサービスだと思います。DNS も Amazon Route 53 を利用。GUI での管理が素敵とのことです。

>>> アプリケーションサーバ

Django アプリケーションを EC2 の High-CPU Extra-Large インスタンスで実行。2012 年開始ぐらいでは約 25 インスタンスと書かれています。Android アプリを公開して 10 日で 1000 万ユーザ (20 時間で 100 万ユーザ) を獲得したようなので、今はもっと多いでしょうね。こういうサービスの拡大に柔軟に対応できるのも EC2 を含むクラウドの魅力だと思います。High-CPU にしている理由はおそらく PIL を多用するからでしょうか。WSGI サーバは gunicorn ですよね。理由は Apache と mod_wsgi より CPU 負荷が軽かったからとのこと。デプロイは Fabric でやっているそうです。Fabric の使い方は Ian 先生のブログが参考になります。

あと、ボトルネックになってるプロセスを監視するために dogslow という bitbucket 製の Django ミドルウェアを利用しているそうです。そういえば bitbucket も Django を使うメガサービスですね。

参考: High-CPU Extra-Large インスタンス

  • 7 GB メモリ
  • 20 ECU（2.5 ECU × 8仮想コア）
  • 1690 GB インスタンスストレージ
  • 64ビット プラットフォーム
  • I/O 性能: 高速

>>> データストア

ほとんどのデータ (ユーザ、写真のメタデータ、タグ等) を PostgreSQL に保存。Django ドキュメントに "PostgreSQL is recommended, because we're PostgreSQL fans" って書いてあるのを思い出しました。PostgreSQL は Cluster Compute Quadruple Extra Large インスタンスで実行。10 ギガですよ！同じく 2012 年開始ぐらいでは約 12 インスタンスと書かれています。またバックアップ用として異なるゾーンに 12 個のレプリカを置いているようです。EBS のディスクシークが遅いので、すべてのワーキングセットをメモリに保存しているそうですPostgreSQL のレプリカはストリーミングレプリケーションを利用。レプリケーションの管理は repmgr を利用。バックアップは EBS のスナップショット機能を利用。コネクションプールに PgBouncer を利用 (これがパフォーマンス向上にかなり効いたらしい)。

最初は Django のルータ機能で垂直分割 (ハードウェア負荷の分散)。次に 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 ギガビットイーサネット）

次にメインフィード、アクティビティーフィード、セッションデータ (django.contrib.sessions.backends) は redis に保存。redis は High-Memory Quadruple Extra Large インスタンスを数台。これもバックアップは EBS のスナップショット。redis のレプリカにより、簡単にオンラインフェールオーバする。redis を選択した理由は、"インサートが高速、サブセットの作成が高速" だったからとのこと。

参考: High-Memory Quadruple Extra Large インスタンス

  • 68.4 GB メモリ
  • 20 ECU（2.5 ECU × 8仮想コア）
  • 1690 GB インスタンスストレージ
  • 64ビット プラットフォーム
  • I/O 性能: 高速

ファイルシステムは XFS。

ファイルキャッシュを管理するために vmtouch を利用。vmtouch でメモリにロードする。

私は KVS の選定の際、ここを参考にしています。

>>> タスクキューと PUSH 通知

写真を facebook や twitter 等への連携、新規写真や新規ユーザの通知等のタスクは gearman で処理。worker 数は 200 程度。

PUSH 通知は pyapns (twisted powered) でやっている。

全体として、運用の手間を軽くし、フットワーク軽くサービスを提供できるように工夫されていますね。監視は munin を利用しているようです。プラグインを python-munin で作成しているようです。監視まで pythonic ですね。python-munin には Instagram さんが利用しているインフラのための素敵なプラグインが多く用意されています。もう 1 つ memcached も利用している技術の 1 つとして記載されていましたが、これについては残念ながら詳しくは書いてありませんでした。Amazon ElastiCache ですかね w

また、スライドには面白い tips も紹介されていました。

  • favicon.ico は必ず作ること: 404 error を防ぐ。最初のスケールはこれ。
  • 他のサイトで以下に favicon を軽くするかも熱く解説していました
  • サービスもインフラもスピードも計量に
  • 開発スタイル
    1. 大規模なユニットテストと機能テスト
    2. DRY
    3. シグナルによる祖結合
    4. 大部分を Python で完結し、必要に応じ C を利用
    5. 知識を共有するための頻繁なコードレビューとプルリクエスト
    6. 大規模な監視

参考:

コメント

コメントを投稿

このブログの人気の投稿

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...
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

#PySpa アドベント (23 日目)

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。
続きを読む