WhatsApp システム設計: 高レベルと低レベルのアーキテクチャを巡るユーモラスな旅-＆＃＆チュートリアル-php.cn

WhatsApp System Design: A Humorous Journey Through High-Level and Low-Level Architecture

旅仲間の皆さん、WhatsApp システムデザインの素晴らしく混沌とした世界へようこそ!この記事では、WhatsApp の高レベル (HLD) アーキテクチャと低レベル (LLD) アーキテクチャをわかりやすく説明するだけでなく、ユーモアも交えて (システム設計が退屈である必要はないからです!)、いくつかの図を描きます (なぜなら、みんなフローチャートが大好きです)。

それでは、シートベルトを締めて、コーヒーを一杯飲み、サーバー、データベース、メッセージングプロトコルが連携して何十億ものメッセージを携帯電話に届ける旅に乗り出しましょう。

1. ハイレベルアーキテクチャ (HLD): 全体像

WhatsApp をよく整理された交響曲として想像してください。ただし、ヴァイオリンの代わりにサーバーがあり、チェロの代わりにデータベースがあります。大まかに言うと、私たちは以下をサポートするシステムを設計しています:

数十億人のユーザー
リアルタイムメッセージング
マルチメディア共有
エンドツーエンド暗号化
高可用性と低遅延 (「入力中...」を待つのが好きな人はいません)

HLD の概要:

HLD では、建築家のように考えます。まだ各窓の形については気にしていません。家が倒壊しないようにしたいだけです。

高度 30,000 フィートの眺めでは、WhatsApp のアーキテクチャは次のとおりです。

クライアントアプリケーション (iOS、Android、Web)
API ゲートウェイ
ロードバランサー (数百万のメッセージの混乱のバランスをとる)
アプリケーションサーバー (魔法が起こる場所)
データベース層 (データはどこかに存在する必要があるため)
ファイルストレージ (猫のGIF用)
メッセージキュー (リアルタイムメッセージング用の Kafka のようなシステム)
通知サーバー (好きな人が返信したら知らせる必要があります)

HLD の中核要素:

クライアントアプリケーション: WhatsApp は、同じバックエンドサーバーに接続するモバイル (iOS/Android)、Web、デスクトップアプリで動作します。クライアントは、UI/UX、メッセージの送受信、暗号化/復号化 (これについては後ほど説明します)、および Wi-Fi がコーヒーブレイクを取ることを決定したときの再接続を担当します。
API ゲートウェイ: これは、クライアントからのリクエストを処理し、それらを適切なバックエンドサービスに転送する仲介者です。 API ゲートウェイは、ユーザーが適切に認証されているかどうかを確認し、メッセージリクエストを記録し、適切なサーバーに送信します。
ロードバランサー: 何百万ものユーザーがオンラインにいるため、どのサーバーも混雑しないようにするには、オーケストラの指揮者 (または 2 人) が必要です。ロードバランサーはリクエストを多くのアプリケーションサーバーに分散するため、過負荷が防止され、処理が超高速になります。
アプリケーションサーバー: これらの悪者たちは WhatsApp の頭脳です。これらはメッセージを処理し、ユーザーセッションを管理し、暗号化を実行します。ここで重要なのはスケーラビリティです。さらに多くのユーザーが参加すると、サーバーも追加されます。
データベース層: あなたのメッセージやメディアはどこに行くのでしょうか?ここでデータベースが登場します。
- NoSQL データベース (Cassandra): ユーザープロファイル、メッセージ履歴などの大規模なデータの保存用
- SQL データベース: まれに、リレーショナルデータが必要な場合 (財務記録など)。
ファイルストレージ: すべての写真、ビデオ、音声メモは、スケーラブルな分散ファイルストレージシステムに保存されます。 S3 を考えてみましょう (ただし、WhatsApp はおそらくカスタマイズされたものを構築したでしょう。なぜなら、それはとてもクールだからです)。
メッセージキュー (Kafka/Redis): リアルタイムメッセージングの場合、WhatsApp はメッセージキューを使用して、さまざまなサーバー間でのメッセージ配信を処理します。ユーザーがオフラインの場合、メッセージはユーザーが戻るまでキューに保存されます。
通知サーバー: 携帯電話の画面がオフの場合、WhatsApp は APN (Apple Push Notification Service) や Android 用 Firebase Cloud Messaging などのサービスを通じて通知を送信します。

HLD フローチャート:

これは、WhatsApp でのクライアント、バックエンドサービス、データベース間の対話を視覚化するための基本的なフローチャートです。

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

ログイン後にコピー

2. 低レベルアーキテクチャ (LLD): 要点の詳細

LLD では、個々のコンポーネントの実装と技術的な詳細に焦点を当てます。ここでは、アルゴリズム、データベースシャーディング、暗号化方法、ネットワークプロトコルについて詳しく説明します。

LLD の主要な概念:

メッセージ配信システム:
- WhatsApp は、リアルタイムのメッセージ配信に XMPP プロトコルを使用します。これは、1 対 1 とグループメッセージングの両方を処理する軽量で効率的なプロトコルです。
- 受信者がオフラインの場合、メッセージは一時的に保存され、オンラインになると配信されます。
エンドツーエンド暗号化:
WhatsApp のエンドツーエンド暗号化は、シグナルプロトコル に基づいています。このアイデアはシンプルですが天才的です:
- すべてのメッセージには独自の一意の暗号化キーがあります。
- 送信者と受信者だけが必要なキーを保持しているため、WhatsApp も第三者もあなたのメッセージを読むことはできません。
もし WhatsApp がスパイ小説だったら、間違った人がそれを読もうとすると、メッセージは自動的に破壊されてしまいます!
データストレージとレプリケーション:
- Cassandra (NoSQL データベース) は、チャットメッセージの保存に使用されます。なぜ？分散型で可用性が高く、複数のデータセンターにわたるレプリケーションを処理できます。 Cassandra は、サーバーがクラッシュしても (サーバーが仮眠が必要だと判断したときに発生します)、データが失われないようにします。
- メディアファイル (写真やビデオなど) はテキストメッセージとは別に、多くの場合クラウドベースのファイルストレージシステムに保存されます。
オフラインユーザーの処理:
- メッセージを送信し、受信者がオフラインの場合、メッセージは Kafka/Redis などのシステムを使用してキューに入れられます。これは、誰かが家にいないときに家のドアにメモを残すようなものですが、そのメモは列の中に安全に保管されます。
データベースシャーディング:
- WhatsApp には何百万ものユーザーがおり、全員のデータを 1 つの巨大なデータベースに保存することはできません。それは、世界中の人々を 1 台のエレベーターに乗せようとするようなものです。
- 代わりに、WhatsApp はデータベースをシャーディングします。シャーディングは、エレベーターを 100 の小さなエレベーターに分割し、それぞれが独自のユーザーグループを担当するようなものです。

LLD フローチャート:

これは、リアルタイムメッセージングとメッセージキューに焦点を当てた簡略化された LLD フローチャートです。

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

ログイン後にコピー

3. フローチャート: 私たちのデザインヒーロー

物事を非常に明確にするために、いくつかの図を追加しましょう。フローチャートを建築家の設計図として想像してください。これらはシステムを視覚的に理解するのに役立ちます。

メッセージ送信フロー:

      +------------------+   Send Message   +-------------------+
      | Client App        |---------------->| API Gateway        |
      +------------------+                  +-------------------+
                  |                                  |
                  |         Authenticate User        |
                  V                                  V
          +----------------+                 +------------------+
          | Message Queue   |  <--Store Msg---| Application      |
          | (Kafka/Redis)   |                 | Servers (XMPP)   |
          +----------------+                 +------------------+
                       |                               |
                       |   Offline/Store Msg            |
                       |------------------------------->
                       V
                +-------------+
                |   Database   | (Sharded Cassandra, File Storage)
                +-------------+

ログイン後にコピー

メッセージ取得フロー:

Client (Mobile App)
     |
     V
API Gateway  --->  Authenticate ---> Forward to Application Server
     |
     V
Load Balancer ---> Routes to Least Busy Server
     |
     V
Message Queue ---> Holds the message if the user is offline
     |
     V
Database ---> Saves the message for future retrieval

ログイン後にコピー

4. コアコンポーネントの内訳

重要なコンポーネントのいくつかをさらに詳しく見てみましょう:

XMPP: リアルタイムメッセージの送受信に使用されるメッセージングプロトコル。
Kafka/Redis: 受信者がオフラインのときにメッセージをキューに入れる責任を負います。
Cassandra: メッセージ、ユーザーデータ、チャット履歴を保存する NoSQL データベース。
シグナルプロトコル: メッセージのプライバシーのためのエンドツーエンドの暗号化を強化します。
シャーディング: 何百万ものユーザーを処理できるように、データベースをより小さく管理しやすい部分に分割します。

5. これらのコンポーネントを使用する理由

なぜカサンドラなのか？

WhatsApp には高可用性、低遅延、および複数の場所に分散されたデータベースを処理する機能が必要なため、Cassandra が最適です。さらに、決してダウンしないように設計されており、WhatsApp はその信頼性を気に入っています。

XMPP を選ぶ理由

XMPP は軽量で効率的で、リアルタイムメッセージング用に設計されています。 5 分後に始まる映画について友達に教えるなど、遅刻するわけにはいかないシステムに最適です。

なぜ Kafka/Redis なのか?

メッセージキューにより、受信者が休暇中で Wi-Fi のないゾーンにいる場合でも、メッセージが失われないことが保証されます。 Kafka と Redis は信頼性が高く、高速で、スケーラブルです。

暗号化に Signal プロトコルを使用する理由

WhatsApp はあなたのメッセージを読みたくありません (約束します)。エンドツーエンド暗号化では、あなたと受信者だけがキーを持っているため、物理的に暗号化を読み取ることができません。

6. 豆知識と WhatsApp 固有の最適化

マルチデバイスのサポート: WhatsApp では、ユーザーが複数のデバイスで同じアカウントを使用できます。これには、慎重なセッション管理とメッセージ同期が必要です。
効率的なメディアストレージ: WhatsApp は、異なるチャット間で共有される同一のメディアファイルの重複を排除することでメディアストレージを最適化します (なぜなら、私たち全員に同じミームをすべてのグループに送信する 1 人の友人がいるからです)。

結論: すべてをまとめる

これで、WhatsApp のシステム設計のツアーは終わりました。私たちは、ハイレベルアーキテクチャ (HLD) を探求し、ローレベルデザイン (LLD) を掘り下げ、さらには旅を楽しくするためにユーモアを加えてきました。 XMPP プロトコルから Kafka キュー、Cassandra データベース、Signal 暗号化に至るまで、WhatsApp はグループチャットを活気づけ続けるスケーラブルなリアルタイムメッセージングの傑作です!

以上がWhatsApp システム設計: 高レベルと低レベルのアーキテクチャを巡るユーモラスな旅の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。