SoundCloud のアーキテクチャの進化: パート 1

ここで疑問が生じます。現在のアーキテクチャではどのようにしてリクエストを同時に処理できるのでしょうか?

SoundCloud のアーキテクチャが最初に開発されたとき (2008 年)、Rails での同時リクエスト処理はまだ未熟であると考えられていました。

エンジニアリング チームは、依存関係の監査にさらに時間を費やす代わりに、既存のモデルを維持することにしました。

1. アプリケーション サーバー プロセスごとに単一の同時実行性。

2. ホストごとに複数のプロセス。

ホストごとに複数のプロセスがあるにもかかわらず、SoundCloud ではすでにトラフィックが急増していました。長時間実行されるリクエストが複数あると、HoL ブロッキングの問題が簡単に再現される可能性があります。

たとえば、プロセスが 1 つではなく 5 つある場合、システムは理論上、平均 5 倍の遅いリクエストを処理できるようになります。

もう一度、郵便局にいる自分を想像してください。荷物の配達を手伝ってくれる職員を列に並んで待っています。人が多いほど、遅延の可能性が高くなります (複数の荷物を持っている人など)。

この HoL 問題はどのように解決できるでしょうか?

エンジニアリング チームは、あることに気づきました。彼らが求めていたのは、待ち行列がまったく発生しないシステム、または少なくとも待ち時間が最小限の待ち行列でした。

これを実現するには、各 Rails アプリケーション サーバーが一度に複数のリクエストを受信しないようにする必要がありました。

以下の変更が行われました。

1. サーバーがステートレスであることを確認しました。

2. 追加した HAプロキシ インフラストラクチャに。

3. 最大接続数を 1 にしてバックエンドを構成しました。

繰り返しますが、デザインの選択はシンプルです。

これらの新しい変更により、HoL の問題は解決されたかもしれませんが、長時間実行されるリクエスト自体は依然として問題です。

一例として、ユーザー通知が挙げられます。

ユーザーが新しいトラックを SoundCloud にアップロードすると、そのユーザーのフォロワーに通知が届きます。フォロワーが少ないユーザーにとっては問題ないかもしれませんが、人気の高いユーザーの場合は大きな遅延が発生していました。

実際、 扇形に広がります 通知の所要時間は数十秒を超えることが頻繁にありました。これらの長時間実行されるリクエストは、代わりにジョブ (キュー) にする必要がありました。

このアーキテクチャではすべてがまだ同期されていたことを覚えていますか?

サウンドと画像用のストレージも急速に増加していたため、チームはAmazon S3に資産をオフロードすることにしました。ストレージは順調に拡張され、 トランスコーディング コンピューティングは Amazon EC2 に残りました。

「1 人のブローカーがすべてをキューに入れます。」

仕事は労働時間に基づいて主に 2 つのカテゴリに分類されます。

1. インタラクティブ – 作業時間は 250 ミリ秒未満

2. バッチ – その他すべて

この時点で、SoundCloud のユーザー数は数十万人に達していました。

アーキテクチャを継続的に進化させるためには、読み取りパスと書き込みパスを分離する必要があることをエンジニアリング チームは認識していました。

読み取りパスと書き込みパスを個別に最適化できます。

焦点を当てた領域の 1 つはウィジェットでした。

結局のところ、SoundCloud の最も大量のリクエストは、ウィジェットのデータを配信する単一のエンドポイントでした。

1. 全ページ

2. DOMフラグメント

3. 部分的にレンダリングされたテンプレート

4. 読み取り専用APIレスポンス

これらのパフォーマンスの向上により、アプリケーション層の CPU の問題 (レンダリング エンジンとランタイム) が解決されました。

もう一つの重点領域は、ユーザーのアクティビティをパーソナライズして表示するダッシュボードでした。

ダッシュボードが更新を受け取ると、すべてのデバイスとサードパーティ アプリケーションを通じて適切なユーザーに通知されます。

読み取りパスは、時間範囲にわたってユーザーごとに順次アクセスできるように最適化する必要がありました。

1 つのイベントが数百万のユーザーのインデックス作成に影響を与える可能性があるランダム アクセスに対して、書き込みパスを最適化する必要がありました。

これらの最適化を考慮すると、 カサンドラ ストレージシステムとして選択され、 エラスティックサーチ 検索を強化するために選択されました。これらのソリューションは永続性と拡張性を提供しました。

最終的なモノリシック アーキテクチャは次のようになります。