Instagram はわずか 3 人のエンジニアでいかにして 1,400 万ユーザーまで拡大したか

Instagramのスケール元 1 年余りでユーザー数が 0 ～ 1,400 万人に、2010 年 10 月から 2011 年 12 月まで。 エンジニアは3人。

彼らは 3 つの重要な原則に従い、信頼できる技術スタックを保有することでこれを実現しました。

• 物事を非常にシンプルにしてください。

• 車輪の再発明はしないでください。

• 可能であれば、実績のある確かなテクノロジーを使用してください。

続きを読む前に…ご紹介したいのは SWEクイズ。

これは、データベース、キャッシュ、ネットワーキングなどのソフトウェア分野の知識のギャップを明らかにするための 450 以上の質問からなるリソースです。 仕事で自信を持ったり、面接前に知識を磨いたりするのに最適です。

一生に一度の購入で、生涯アップデートが含まれます。

SWE クイズをチェックしてください

初期の Instagram のインフラストラクチャは、Ubuntu Linux と EC2 を使用して AWS 上で実行されました。 参考までに、EC2 は開発者が仮想コンピューターをレンタルできる Amazon のサービスです。

わかりやすく言うと、私はエンジニアの視点でユーザーのことを考えるのが好きなので、 ユーザーセッションの存続期間を見てみましょう。 (マーク付き Session:)

Session: A user opens the Instagram app.

Instagram は、2010 年に iOS アプリとして最初にリリースされました。Swift は 2014 年にリリースされたため、Instagram は次の方法で作成されたと推測できます。 Objective-C と UIKit などの他のものの組み合わせ。

Session: After opening the app, a request to grab the main feed photos is sent to the backend, where it hits Instagram’s load balancer.

インスタグラム使用中 Amazon の Elastic Load Balancer。 彼らには 3 つの NGINX インスタンスがあり、それらが正常かどうかに応じて交換されていました。

各リクエストは、実際のアプリケーション サーバーにルーティングされる前に、まずロード バランサーに到達します。

Session: The load balancer sends the request to the application server, which holds the logic to process the request correctly.

Instagramのアプリケーションサーバーを使用 ジャンゴ それは Python で書かれており、 ガニコーン WSGIサーバーとして。

復習として、WSGI (Web サーバー ゲートウェイ インターフェイス) は Web サーバーから Web アプリケーションにリクエストを転送します。

インスタグラム利用 ファブリック 一度に多くのインスタンスでコマンドを並行して実行します。 これにより、わずか数秒でコードをデプロイできます。

これらは 25 台以上の Amazon High-CPU Extra-Large マシン上に存在していました。 サーバー自体はステートレスであるため、より多くのリクエストを処理する必要がある場合は、さらにマシンを追加できます。

Session: The application server sees that the request needs data for the main feed. For this, let’s say it needs:

1. latest relevant photo IDs

2. the actual photos that match those photo IDs

3. user data for those photos.

Session: The application server grabs the latest relevant photo IDs from Postgres.

アプリケーションサーバーはからデータをプルします PostgreSQL、ユーザーや写真のメタデータなど、Instagram のデータのほとんどが保存されていました。

Postgres と Django の間の接続は、次を使用してプールされました。 Pgbouncer。

Instagramがデータを共有した 彼らが受け取った量のせいで（25 枚以上の写真と 1 秒あたり 90 件の「いいね！」）。 彼らはコードを使用して、数千の「論理」シャードをいくつかの物理シャードにマッピングしました。

Instagram が直面し、解決した興味深い課題は、時間によってソートできる ID を生成することです。 結果として得られる時間順に並べ替え可能な ID は次のようになります。

• ミリ秒単位の時間の 41 ビット (カスタム エポックで 41 年間の ID が得られます)

• 論理シャード ID を表す 13 ビット

• 自動インクリメント シーケンス、モジュラス 1024 を表す 10 ビット。これは、シャードごと、ミリ秒ごとに 1024 個の ID を生成できることを意味します。

(もっと読むことができます ここ。）

Thanks to the sortable-by-time IDs in Postgres, the application server has successfully received the latest relevant photo IDs.

Session: The application server then gets the actual photos that match those photo IDs with fast CDN links so that they load fast for the user.

数テラバイトの写真がAmazonに保存されていた S3。 これらの写真は、Amazon を使用してユーザーにすぐに提供されました クラウドフロント。

Session: To get the user data from Postgres, the application server (Django) matches photo IDs to user IDs using Redis.

インスタグラム使用中 レディス メイン フィードやアクティビティ フィードなどの写真を取得するときにどのシャードをクエリするかを知るために、約 3 億枚の写真とその写真を作成したユーザー ID のマッピングを保存します。レイテンシを短縮するために、Redis はすべてメモリ内に保存され、複数のマシンにまたがってシャーディングされました。

いくつかの賢いハッシュ化により、Instagram は 5 GB 未満に 3 億のキー マッピングを保存することができました。

この写真 ID とユーザー ID のキーと値のマッピングは、どの Postgres シャードをクエリするかを知るために必要でした。

Session: Thanks to efficient caching using Memcached, getting user data from Postgres was fast since the response was recently cached.

一般的なキャッシュには Instagram を使用 Memcached。 当時、彼らには 6 つの Memcached インスタンスがありました。 Memcached は、Django の上に重ねるのが比較的簡単です。

興味深い事実: 2 年後の 2013 年に、Facebook は Memcached をどのようにスケーリングして処理を支援したかに関する画期的な論文を発表しました。 何十億もの 1 秒あたりのリクエスト数。

Session: The user now sees the home feed, populated with the latest pictures from people he is following.

Postgres と Redis はどちらも マスターレプリカのセットアップ また、Amazon EBS (Elastic Block Store) スナップショットを使用して、システムのバックアップを頻繁に作成しました。

Session: Now, let’s say the user closes the app, but then gets a push notification that a friend posted a photo.

このプッシュ通知は次を使用して送信されました ピャプンス、Instagramがすでに送信していた他の10億以上のプッシュ通知とともに。 Pyapns は、オープンソースのユニバーサル Apple プッシュ通知サービス (APNS) プロバイダーです。

Session: The user really liked this photo! So he decided to share it on Twitter.

バックエンドでは、タスクがプッシュされます。 ドイツ、タスクキュー これにより、より適切なマシンに作業が割り当てられました。 Instagram では、最大 200 人の Python ワーカーが Gearman タスク キューを消費していました。

Gearman は、ユーザーのフォロワー全員にアクティビティ (新しい写真の投稿など) をプッシュする (これはファンアウトと呼ばれます) など、複数の非同期タスクに使用されていました。

Session: Uh oh! The Instagram app crashed because something erred on the server and sent an erroneous response. The three Instagram engineers get alerted instantly.

インスタグラム使用中 衛兵、オープンソースの Django アプリで、Python エラーをリアルタイムで監視します。

悪い システム全体のメトリクスをグラフ化し、異常を警告するために使用されました。 Instagram には、1 秒あたりに投稿される写真など、アプリケーション レベルの指標を追跡するためのカスタム Munin プラグインが多数ありました。

ピンダム 外部サービスの監視に使用され、 ポケベルデューティ インシデントや通知の処理に使用されました。

出典: