多くのスタートアップ企業がこのような状況を経験しています。毎日大勢の新規ユーザーが登録し、開発チームはサービスを運営し続けるのに苦労しています。

これは良い問題ですが、Web アプリケーションをゼロから数十万のユーザーまで慎重に拡張する方法について、Web 上には明確な情報がほとんどありません。 通常、火災解決策またはボトルネック解決策のいずれか (多くの場合、両方) が存在します。 したがって、人々はアマチュアのプロジェクトを本当に本格的なものにスケールアップするために、かなりありきたりなテクニックを使用します。

情報をフィルタリングして、基本的な式を書き留めてみましょう。 新しい写真共有サイト Graminsta のユーザー数を 1 人から 100 人まで段階的に拡大していく予定です。

視聴者が10人、100人、1000人、10万人、000万人と増えたときに、具体的にどのような行動が必要なのかを書き出してみましょう。

1ユーザー：1マシン

Web サイトであれモバイル アプリケーションであれ、ほぼすべてのアプリケーションには XNUMX つの主要なコンポーネントがあります。

• API
• データベース
• クライアント (モバイル アプリケーション自体または Web サイト)

データベースには永続的なデータが保存されます。 API は、このデータに対するリクエストとそのデータに関するリクエストを処理します。 クライアントはユーザーにデータを送信します。

私は、アーキテクチャの観点から、クライアントと API エンティティが完全に分離されていれば、アプリケーションのスケーリングについて話すのがはるかに簡単であるという結論に達しました。

最初にアプリケーションの構築を開始するときは、XNUMX つのコンポーネントすべてを同じサーバー上で実行できます。 ある意味、これは私たちの開発環境に似ています。XNUMX 人のエンジニアがデータベース、API、クライアントを同じマシン上で実行します。

理論的には、以下に示すように、単一の DigitalOcean Droplet または AWS EC2 インスタンス上のクラウドにデプロイできます。

そうは言っても、サイトに複数のユーザーがいる場合は、ほとんどの場合、データベース層を専用にすることが合理的です。

10 ユーザー: データベースを別のレベルに移動する

データベースを Amazon RDS や Digital Ocean マネージド データベースなどのマネージド サービスに分割することは、長期的には役に立ちます。 単一マシンまたは EC2 インスタンスでのセルフホスティングよりも少し高価ですが、これらのサービスを使用すると、マルチリージョン バックアップ、リードレプリカ、自動など、将来役立つ多くの便利な拡張機能をすぐに利用できます。バックアップなど。

現在のシステムは次のようになります。

100 ユーザー: クライアントを別のレベルに移動する

幸いなことに、最初のユーザーは私たちのアプリケーションをとても気に入ってくれました。 トラフィックはより安定してきているため、クライアントを別のレベルに移動する時期が来ました。 注意すべきこと 分離 エンティティは、スケーラブルなアプリケーションを構築する上で重要な要素です。 システムの一部がより多くのトラフィックを受信すると、それを分割して、特定のトラフィック パターンに基づいてサービスがどのように拡張されるかを制御できます。

これが、私がクライアントを API から切り離して考えることを好む理由です。 これにより、Web、モバイル Web、iOS、Android、デスクトップ アプリケーション、サードパーティ サービスなどの複数のプラットフォーム向けの開発を考えることが非常に簡単になります。これらはすべて、同じ API を使用する単なるクライアントです。

たとえば、現在、ユーザーからモバイル アプリケーションのリリースを求めることが最も多くなっています。 クライアントと API エンティティを分離すると、これが簡単になります。

このようなシステムは次のようになります。

1000 ユーザー: ロード バランサーを追加

状況は上向いています。 Graminsta ユーザーはますます多くの写真をアップロードしています。 登録数も伸びています。 私たちの唯一の API サーバーは、すべてのトラフィックに対応するのに苦労しています。 もっと鉄分が必要です！

ロード バランサーは非常に強力な概念です。 重要なアイデアは、API の前にロード バランサーを配置し、トラフィックを個々のサービス インスタンスに分散するということです。 これは、水平方向にスケールする方法です。つまり、同じコードを持つサーバーを追加して、処理できるリクエストの数を増やします。

Web クライアントの前と API の前に別々のロード バランサーを配置します。 これは、API コードと Web クライアント コードを実行する複数のインスタンスを実行できることを意味します。 ロード バランサーは、負荷の低いサーバーにリクエストを送信します。

ここで、もう XNUMX つの重要な利点、つまり冗長性が得られます。 XNUMX つのインスタンスに障害が発生した場合 (おそらく過負荷またはクラッシュ)、受信リクエストに応答し続ける他のインスタンスが残されます。 動作しているインスタンスが XNUMX つだけの場合、障害が発生するとシステム全体がクラッシュします。

ロード バランサーは自動スケーリングも提供します。 負荷がピークになる前にインスタンスの数を増やし、すべてのユーザーがスリープしているときにインスタンスの数を減らすように構成できます。

ロード バランサーを使用すると、リクエストの数が増加したときに新しいインスタンスを追加するだけで、API レベルをほぼ無制限に拡張できます。

注記。 現時点で、私たちのシステムは、AWS の Heroku や Elastic Beanstalk などの PaaS 企業がそのまま提供しているものと非常によく似ています (これが、非常に人気がある理由です)。 Heroku はデータベースを別のホストに配置し、自動スケーリング ロード バランサーを管理して、Web クライアントを API とは別にホストできるようにします。 これは、初期段階のプロジェクトやスタートアップに Heroku を使用する大きな理由です。基本的なサービスがすべてすぐに利用できるためです。

10 ユーザー: CDN

おそらく最初からこれを行うべきだったでしょう。 リクエストの処理と新しい写真の受け入れにより、サーバーに過度の負担がかかり始めています。

この段階では、画像、ビデオなどの静的コンテンツを保存するためにクラウド サービス (AWS S3 または Digital Ocean Spaces) を使用する必要があります。 一般に、API は画像の提供やサーバーへの画像のアップロードなどの処理を避ける必要があります。

クラウド ホスティングのもう XNUMX つの利点は CDN (AWS ではこのアドオンを Cloudfront と呼んでいますが、多くのクラウド ストレージ プロバイダーがそのまま提供しています) です。 CDN は、世界中のさまざまなデータ センターに画像を自動的にキャッシュします。

当社のメイン データ センターはオハイオ州にありますが、誰かが日本からイメージを要求した場合、クラウド プロバイダーはコピーを作成して日本のデータ センターに保存します。 次に日本でこの画像をリクエストした人は、より早く画像を受け取ることができます。 これは、写真やビデオなど、ダウンロードして世界中に送信するのに時間がかかる大きなファイルを扱う場合に重要です。

100 ユーザー: データ層の拡張

CDN は大いに役立ち、トラフィックはフルスピードで増加しています。 有名なビデオブロガーの Mavid Mobrick がちょうど私たちに登録し、よく言われるように彼の「ストーリー」を投稿しました。 ロード バランサーのおかげで、API サーバーの CPU とメモリの使用量は低く抑えられています (XNUMX 個の API インスタンスが実行されている) が、リクエストで多くのタイムアウトが発生し始めています... この遅延はどこから来ているのでしょうか?

メトリクスを少し詳しく調べてみると、データベース サーバーの CPU の負荷が 80 ～ 90% であることがわかります。 もう限界です。

データ層のスケーリングは、おそらく方程式の中で最も難しい部分です。 API サーバーはステートレスなリクエストを処理するため、API インスタンスを追加するだけです。 鼻 過半数で データベースではこれができません。 一般的なリレーショナル データベース管理システム (PostgreSQL、MySQL など) について説明します。

キャッシング

データベースのパフォーマンスを向上させる最も簡単な方法の XNUMX つは、新しいコンポーネントであるキャッシュ レイヤーを導入することです。 最も一般的なキャッシュ方法は、Redis や Memcached などのメモリ内のキーと値のレコード ストアです。 ほとんどのクラウドには、AWS 上の Elasticache と Google Cloud 上の Memorystore というサービスのマネージド バージョンがあります。

キャッシュは、サービスが同じ情報を取得するためにデータベースに対して何度も繰り返し呼び出しを行う場合に役立ちます。 基本的に、データベースにアクセスするのは XNUMX 回だけで、情報はキャッシュに保存され、再度触れることはありません。

たとえば、Graminsta サービスでは、誰かがスター Mobrik のプロフィール ページにアクセスするたびに、API サーバーがそのプロフィールの情報をデータベースに照会します。 このようなことが何度も起こります。 Mobrik のプロファイル情報はリクエストごとに変更されないため、キャッシュに優れています。

データベースからの結果をキーごとに Redis にキャッシュします user:id 有効期間は 30 秒です。 現在、誰かが Mobrik のプロフィールにアクセスすると、まず Redis をチェックし、データが存在する場合は Redis から直接転送します。 現在、サイト上で最も人気のあるプロファイルへのリクエストは、実際にはデータベースをロードしません。

ほとんどのキャッシュ サービスのもう XNUMX つの利点は、データベース サーバーよりも拡張が容易であることです。 Redis には、Redis クラスター モードが組み込まれています。 ロードバランサーに似たもの1を使用すると、Redis キャッシュを複数のマシン (必要に応じて数千台のサーバー) に分散できます。

ほとんどすべての大規模アプリケーションはキャッシュを使用しており、高速 API には絶対に不可欠な部分です。 クエリ処理の高速化とコードの生産性の向上はすべて重要ですが、キャッシュなしではサービスを数百万のユーザーに拡張することはほぼ不可能です。

リードレプリカ

データベースへのクエリの数が大幅に増加した場合、もう XNUMX つできることは、データベース管理システムにリードレプリカを追加することです。 上で説明した管理サービスを使用すると、これをワンクリックで実行できます。 リードレプリカはメインデータベースに最新のまま残り、SELECT ステートメントで使用できます。

現在のシステムは次のとおりです。

次のステップ

アプリケーションが拡張し続けるにつれて、サービスを分離して個別に拡張していきます。 たとえば、Websocket を使い始める場合は、Websocket の処理コードを別のサービスに取り込むのが合理的です。 これを独自のロード バランサーの背後にある新しいインスタンスに配置することができ、オープンな Websocket 接続に基づいて、HTTP リクエストの数に関係なくスケールアップおよびスケールダウンできます。

私たちはデータベースレベルでの制限とも闘い続けます。 この段階で、データベースのパーティショニングとシャーディングについて検討します。 どちらのアプローチでも追加のオーバーヘッドが必要ですが、データベースをほぼ無制限に拡張できます。

また、New Relic や Datadog などの監視および分析サービスもインストールしたいと考えています。 これは、遅いクエリを特定し、どこを改善する必要があるかを理解するのに役立ちます。 規模を拡大する際には、前のセクションのアイデアの一部を使用して、ボトルネックを見つけて排除することに重点を置きたいと考えています。

ソース

この投稿は、次のいずれかにインスピレーションを得たものです 高いスケーラビリティに関するお気に入りの投稿。 プロジェクトの初期段階に向けて記事をもう少し具体的にし、XNUMX つのベンダーから切り離したいと思いました。 このトピックに興味がある場合は、必ずお読みください。

脚注

1. 複数のインスタンスにわたる負荷分散という点では似ていますが、Redis クラスターの基礎となる実装はロード バランサーとは大きく異なります。 [戻る]

出所： habr.com