「バックエンドの経験はなかった」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

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

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

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

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

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

Scaling Instagram

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

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

立ち上げ時、2人

fig

バックエンドの経験なし

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

MacBook Proより非力

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

すべてが炎上した

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

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

favicon重要

Amazon EC2へ移行

fig

スケーリングとは、時速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

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

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

シンプルさが重要

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

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

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Amazon , クラウド , システム構築 , システム運用



≫次の記事
EMCがフラッシュストレージへの全面的な取り組みを宣言、EMC World 2012
≪前の記事
バッファローがデータセンター向けストレージに参入。Amazon S3へのバックアップに対応したラックマウント型NAS/iSCSIストレージ「TeraStation 7000」

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus