Instagram 早期技術架構

2023-11-07 12:01:04

哈嘍大家好,我是鹹魚

想必大家都聽說過 Instagram ,它是全球最受歡迎的社交媒體平臺之一,擁有數十億的活躍使用者

Instagram 誕生於 2010 年,上線一週就坐擁 10 萬註冊使用者,一年之內就擁有了 1400 萬用戶,可見擴張趨勢突飛猛進。

Instagram 誕生的時候只有 3 個工程師,想必大家對【他們怎麼設計後端架構,使用了什麼技術來支援這麼多使用者】很感興趣吧,那麼今天我們就來了解一下 Instagram 是如何在只有 3 名工程師的情況下擴充套件到 1400 萬用戶

原文:https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million

從 2010 年 10 月到 2011 年 12 月,Instagram 的使用者在一年多的時間裡從 0 增加到1400萬,關鍵是他們只有 3 個工程師

這聽起來是不是很不可思議。據 Instagram 工程師透露,他們通過遵循下面 3 個關鍵原則並擁有可靠的技術棧來做到這一點:

  • 讓事情變得非常簡單
  • 不要重複造輪子
  • 儘可能使用經過驗證的可靠技術

技術棧

Instagram 早期的基礎設施執行在 AWS 上,使用 EC2 和 Ubuntu Linux

EC2 是 Amazon 的雲服務,它允許開發人員租用虛擬機器器

  • 前端 APP

Instagram 最初在 2010 年作為 iOS 應用程式推出。由於 Swift 在 2014 年才釋出,那 Instagram 應該是使用 Objective-C 和 UIKit 等其他語言的組合來編寫的

  • 負載均衡

Instagram 使用了 Amazon 的 Elastic 負載均衡器(Load Balancer)。他們有 3 個 Nginx 範例,Nginx 之間會進行健康檢查以此保證服務高可用

當用戶請求到來時,每個請求會先經過負載均衡器,然後才被轉發到後端實際伺服器

  • 後端服務

Instagram 的應用程式伺服器使用了 Django 框架,它是由 Python 編寫的,而 Gunicorn 是它們的 WSGI 伺服器

WSGI (Web Server Gateway Interface)全稱 web 伺服器閘道器介面,它會將請求從 web 伺服器轉發到 web 應用程式

在批次管理和自動運維方面,Instagram 通過 Fabric 同時在多個範例上面並行執行命令,做到幾秒鐘內部署程式碼

Fabric 是 Python 的一個模組,基於 SSH 提供了豐富的互動介面,可以用來在本地或遠端機器上自動化的執行 Shel l命令,非常適合用來做應用的遠端部署及系統維護

這些範例在超過25臺 Amazon High-CPU Extra-Large 機器上執行。由於伺服器本身是無狀態的,如果需要處理更多請求時,便可以新增更多的機器

  • 一般資料儲存

Instagram 使用了 PostgreSQL 來儲存資料,應用程式伺服器將從 PostgreSQL 中提取資料,PostgreSQL 儲存了 Instagram 的大部分資料,例如使用者和照片後設資料

PostgreSQL 和 Django 之間的連線通過 pgbouncer

pgbouncer 是一個 PostgreSQL 連線池

任何目標應用程式都可以像連線 PostgreSQL 伺服器一樣連線到 pgbouncer,並且 pgbouncer 將建立到實際伺服器的連線,或者重用其現有的連線

Instagram 對使用者的資料進行了分片,即使用程式碼將幾千個「邏輯」碎片對映到幾個物理碎片,因為收到的資料量很大(每秒超過 25 張照片和 90 個贊)

但是在將資料寫入這組伺服器之前,Instagram 必須解決如何為資料庫中的每條資料分配ID(唯一識別符號)的問題

下面則是 Instagram 中每條資料 ID 包含的內容:

  • 41 位表示時間(以毫秒為單位)
  • 13 位表示邏輯分片 ID
  • 10 位表示自動遞增序列,模數 1024。這意味著我們可以在每毫秒內為每個分片生成 1024 個id

Instagram 的資料分片和 ID 具體是怎麼解決的小夥伴們可以看這篇文章:

https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

  • 照片資料儲存

對於使用者的照片,Instagram 使用 Amazon S3 來儲存,並且使用 Amazon CloudFront 把照片快速提供給使用者

  • 快取

Instagram 使用 Redis 將大約 3 億張照片對映到建立它們的使用者 ID 進行儲存,所有 Redis 都儲存在記憶體中以減少延遲,並在多臺機器上進行分片。

通過一些巧妙的雜湊,Instagram 能夠在不到 5 GB 的記憶體中儲存 3 億個鍵對映

對於常規快取,Instagram 使用了 Memcached。他們當時有 6 個 Memcached 範例。Memcached 相對容易疊加在 Django 上


PostgreSQL 和 Redis 都使用了主從架構,並使用 Amazon EBS(彈性塊儲存)快照對系統進行頻繁備份

  • 推播通知和非同步任務

Instagram 使用 pyapns 來實現,Pyapns 是一個開源的、通用的蘋果推播通知服務(APNS)提供商

在後端,任務被推播到 Gearman,這是一個任務佇列,將工作分配給更適合的機器。Instagram 有 大約 200 名 Python 工作者使用 Gearman 任務佇列

Gearman 常用於多個非同步任務,例如向用戶的所有關注者推播活動(釋出的新照片)

  • 監控

Instagram 使用開源 Django 應用程式 Sentry 來實時監控 Python 錯誤

Munin 用於繪製系統範圍的指標並行出異常警報。Instagram 有一堆自定義的 Munin 外掛來跟蹤應用程式級別的指標,例如每秒釋出的照片

Pingdom 用於外部服務監控,PagerDuty 用於處理事件和通知