「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか

2012年5月25日

昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。

InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。

Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。

Instagramのシステム構成

約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers Instagram: Hundreds of Instances, Dozens of Technologies」では、同社のシステムがどのような技術で構築されたのかが紹介されています。

Instagram Engineering • What Powers Instagram: Hundreds of Instances, Dozens of Technologies

ポイントを以下にまとめました。

Ubuntu Linux 11.04 on Amazon EC2
3台のNginxをAmazon Elastic Load Balancerでロードバランス
PythonのDjangoをAmazon High-CPU Extra-Largeインスタンスで稼働、25台以上
WSGI（Web Server Gateway Interface）サーバとしてGunicornを利用
データのほとんどはPostgreSQL
12台のQuadruple Extra-Large memoryインスタンスでクラスタを構成
別のアベイラビリティゾーンでレプリケーション
メインフィードにはRedis。 Quadruple Extra-Large Memoryインスタンスで稼働
100台以上のインスタンスの監視にMunin
サービスのモニタリングにPingdom
インシデントと通知にPagerDuty

バックエンドの経験がないまま試行錯誤

Scribdには、Instagramの共同創業者であるMike Krieger氏による「Scaling Instagram」という資料が公開されています。

この資料によると、Krieger氏はInstagramを立ち上げる前はMeeboでフロントエンドエンジニアをしており、もう一人の創業者Kevin Systrom氏ともども、本格的なバックエンドの経験はなかったそうです。

そんな状態のままスタートしたInstagramがどうやってシステムをスケールしてきたのか、いわゆる「高橋メソッド」状態で延々と紹介されているスライドを、ざっくりと以下にまとめてみました。

Scaling Instagram

2年もたたずに3000万以上のユーザーを獲得

我々はこれまでどうやってスケールしてきたか

立ち上げ時、2人

バックエンドの経験なし

ロサンゼルス某所でホストされたサーバが1台

MacBook Proより非力

初日に2万5000ユーザーが登録

すべてが炎上した

人生で最高で最悪の一日だ

favicon.icoを忘れ、Djangoに死ぬほど404エラーが発生

favicon重要

Amazon EC2へ移行

スケーリングとは、時速100マイルで走りつつ
自動車のすべての部品を交換するようなものだ

Nginx＆Redis＆Postgres＆Django

Nginx＆HAProxy＆Redis＆Memcached＆Postgres＆
Gearman＆Django

24時間運用し続け

我々の理念

1.simplicity シンプルに

2.optimize for minimal operational burden 運用の手間を最小に

3.instrument everything すべてを機械化すべし

DBのスケーリング

写真はどんどん増えていった

Amazon EC2の最大メモリは68GB

どうする？

まず垂直分散

キーと写真データを分散

数カ月後にはもうメモリに収まらなくなった

今度は水平分散、つまりSharding

Shardingの何が大変か？

1.データの取得

多くの場合、ユーザーIDで分散させる

2.特定のShardが大きくなりすぎたらどうする？

我々は多数の小さな論理Shardを作って、
それをいくつかの物理Shardにまとめた

3.どのツールをどこで使う？

We love Redis

Redisは、比較的限定された構造化データを扱うのが得意

（インメモリDBが解決策だということにとらわれすぎない方がいい）

フォローグラフ

最初のバージョンではRedis上に構築

一貫性に問題発生

追加ロジックがどんどん増えた

Twitterの本を見てデザインし直し

素早く対応するのが吉

2010年：エンジニア2人

2011年：エンジニア3人

2012年：エンジニア5人

足りないことがフォーカスを生む

1 extensive unit-tests and functional tests

2 keep it DRY

3 loos coupling using notifications / signals

4 do most of our work in Python, drop to C when necessary

5 frequent code reviews pull requests to keep things in the 'shared brain'

6 extensive monitoring

システムはいま大丈夫か？過去の履歴と比べてどうか？

素早く対応すること＝何が重要かをつねに意識すること

シンプルさが重要

可能な限り稼働部品を少なく、クリアなソリューションにする

予想より物事は早く起きる。まわりに良きアドバイザーがいるはず