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 経由で印刷する

財務諸表 (Financial Statements)

Netflix のスケール - オートメーション編