AWS上のシステム設計

第19章. チャットアプリケーションを設計する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第6章では、 、ほぼリアルタイムのメッセージングプラットフォームを構築するための、複数のネットワークプロトコルや通信メカニズムについて検討した。メッセージング・アプリケーションは世界中で広く使われている。アプリケーションはWhatsAppやTelegramのようなスタンドアローンの場合もあれば、LinkedInやInstagramのようなソーシャルネットワーキングアプリ内の機能として統合される場合もある。この章では、大規模なメッセージング・アプリケーションを設計し、ほぼリアルタイムで高速なコミュニケーションを提供する方法を学ぶ。また、WhatsAppメッセンジャーのアーキテクチャについても説明する。チャットアプリケーションのシステム要件から始めよう。

システム要件

メッセージング・アプリケーションは、様々な機能をサポートすることができるが、シンプルにするために、限られた機能のセットを構築し、音声やビデオ呼び出しのような機能を省くことにする。これらの質問に答えるために、要件を確定しよう：

アプリケーションはどのようなコミュニケーションをサポートしているか？

このアプリケーションは、1対1のメッセージング、グループ・メッセージング、ブロードキャスト・メッセージングを提供する。ブロードキャストはグループ・メッセージングとは異なり、ブロードキャスト・チャンネルでは一部のユーザのみがメッセージを送信できる。

アプリケーションはどのようなコンテンツをサポートするのか？

このアプリケーションでは、ユーザはテキストメッセージ、画像、ビデオ、ドキュメントを共有することができる。次に生じる疑問は、動画ファイルのサイズに制限があるかどうかだ。大きなメディアのアップロードを避けるため、システムはファイルサイズを100MBに制限している。

アプリケーション側ですべてのメッセージを保存するのか、それともユーザへ配信されたメッセージは削除されるのか？

WhatsAppのように、ユーザにメッセージが届いた時点でサーバからメッセージを削除できるシステムを構築する。

システムは読み取りレシートを含むのか？

ユーザが最後に見たメッセージと、送信されたメッセージの読み取りレシートを反映させることは、良い機能である。読み取りレシートには、アプリケーション・サーバに送信されたメッセージ、ユーザに配信されたメッセージ、ユーザが読み取ったメッセージを含めることができる。

システムはメッセージのエンド・ツー・エンド暗号化をサポートしているか？

暗号化によって、メッセージは送信者と受信者のみが読み取り可能となり、セキュリティが保たれる。暗号化サポートの実装の詳細については省略するが、システムが将来このサポートを提供することになんら制限を受けることはない。

グループやメッセージ・ブロードキャストのメンバー数に制限はあるか？

グループとブロードキャスト・メッセージのメンバーを1,024人に制限する。ブロードキャストチャンネルでは、管理者権限を持つ人だけがメッセージを送ることができ、それ以外の人はメッセージを見ることしかできない。管理者になれる人数に制限は設けない。全員が管理者であれば、ブロードキャストチャンネルは実質的にグループとして動作することに注意。

アプリケーションは、音声通話、ビデオ呼び出し、ユーザとのステータス更新の共有（Instagramのストーリーのような）など、メッセージング以外の機能をサポートしているか？ ...