- 2010/10から2011/11までの約1年間で、0人から1,400万人のユーザーに到達。エンジニアはわずか3人
- 3つの原則に従っていた
- シンプルに保つこと (Keep things very simple.)
- 車輪の再発明をしないこと (Don’t re-invent the wheel.)
- 可能であれば、実証済みで堅牢な技術を使うこと (Use proven, solid technologies when possible.)
ユーザー視点でシンプルにスタックを見てみる
- 初期インフラはAWS EC2上のUbuntu Linux
- InstagramアプリはまずiOS版のみが公開され、Swift発表前だったため、Objective-C + UIKitだった可能性が高い
- ロードバランシングのためにAmazonのElastic Load Balancerと3つのNGINXインスタンスを使用
- バックエンド
- アプリケーションサーバーはPythonで開発され、DjangoとWSGIサーバーとしてGunicornを使用
- Fabricを使って複数インスタンスで同じコマンドを同時実行。これによりコードを数秒でデプロイ
- 高性能CPUのExtra-Largeマシン25台を稼働。すべてStatelessなので必要に応じて容易に追加可能
- 一般データストア
- 関連するフォトID、そのIDの実際の写真、写真に関するユーザーデータ
- アプリケーションサーバーがPostgreSQLからデータを取得
- DjangoとPostgreSQLの間でpgbouncerによるプーリング
- Instagramは時間順にソート可能なIDを使用: 41ビットのミリ秒 + 13ビットのシャードID + 10ビットの自動増分シーケンス
- 写真ストレージ: S3とCloudfront
- キャッシュ: RedisとMemcached
- スマートなハッシュによって、3億個のキーマッピングを5GB未満の容量に保存
- そして2年後、FacebookはMemcachedをスケールして毎秒数十億件のリクエストへ拡張した方法に関する論文を発表
- PostgresとRedisはいずれもMaster-Replicaモードで動作。Amazon EBSスナップショットで継続的にバックアップ
- Push NotificationとAsync Task: 通知はpyapns。Gearmanタスクキュー
- エラーをリアルタイムで監視するためにオープンソースのDjangoアプリであるSentryを使用し、システム全体のメトリクスにはMuninを、外部サービスの監視にはPingdomとPagerDutyを使用
3件のコメント
Instagramは初期のころ（頑なにiPhoneしかサポートしていなかった時代）は、せいぜいおしゃれな画像フィルターアプリくらいの印象だったんですよね。ここまで大ヒットするとは想像もできませんでした。（私の想像力がその程度だったということです;;;）
Exitまで経験したプロダクトを比較する中で、Instagramは1人あたりのイグジット額がかなり高かったのを見た記憶があります。学ぶ点が多いと思います。
Hacker Newsの意見