English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

ゲスト
1 / ?

ノード、エッジ、方向

リクエストはグラフのウォーク

リクエストが触れる各コンポーネントは ノード です: クライアント、DNSリゾバー、CDNエッジ、リバースプロキシー、バックエンドレプリカ、データベース、キャッシュ。

ノードの間の接続は 有向エッジ です: リクエストは前方へ、レスポンスは後方へ流れます。前方のエッジはオープンTCP接続および上に構築されたプロトコルを表します。

リクエストはこのグラフを通して パス です。このグラフを通してのリクエストの総労働量は、各ノードでの労働量の合計および各エッジのレイテンシ(遅延)を加えます。

なぜ気にするか? グラフを描くたびに、コードでは見えないプロパティが浮かび上がります。

- ホップカウント: パスのエッジの数。各ホップはレイテンシ(ネットワークの往復 + ノードの処理)を追加します。ホップが少ないほどレイテンシの底が低くなります。

- インデgree: ノードにポインティングするエッジの数。高インデgreeはノードがスケーリングまたは自己防衛をしなければならないことを意味します。

- アウトdegree: ノードからポインティングするエッジの数。高アウトdegreeはノードが多くのダウンストリームに依存し、多くの方法で失敗することを意味します。

- カットバーテックス: グラフの切断をもたらすノード。カットバーテックスはリバースプロキシーで、どのノードが孤立するかを示します。

リクエストを通じての有向グラフ: クライアント、プロキシ、バックエンド、データベース

次のリクエストグラフを描いてください: クライアントブラウザ -> CDNエッジ -> リバースプロキシー -> バックエンドレプリカ -> データベース。ホップの数をカウントしてください。カットバーテックスを特定し、リボンが連続するためにはどのような運用上の影響があるかを予測してください。

交通が集中する場所

ファンイン = 集中

インデグリ ノード = ポイントするエッジの数。リクエストグラフでは、インデグリ = アクティブなリクエストの全体のリクエストから送信されるアップストリームソースの数。

ファンインパターン: 多くのクライアント -> 一つのCDN; 多くのCDNエッジ -> 数のオリジンプロキシ; 多くのプロキシ -> より少ないバックエンドリプリカ; 多くのバックエンド -> 単一のデータベース。

集中が重要なのは、最高のインデグリノードが最もアグリゲートされた負荷を見るからです。 最終的には、システム全体のどの部分も生成していないが、データベースがすべてのアクティブなリクエストのシステムの各リクエストからクエリを視る可能性があります。

ファンアウト = 依存

アウトデグリ ノード = ポイントするエッジの数。高アウトデグリは、多くのダウンストリーム依存性があります。

バックエンドがデータベース、2つのキャッシュ、3つの外部API、およびキューにアクセスする場合、アウトデグリは7です。成功した応答が必要な場合、各ダウンストリームの成功確率の乗算がその成功確率になります。

0.999 ^ 7 ≈ 0.993: 7つのダウンストリームそれぞれ99.9%の信頼性を持つバックエンドは、独自のバグもなく、99.3%の信頼性しか達成できません。

アウトデグリを減らす方法: ダウンストリームの結果をキャッシュする、非批判的なダウンストリームをオプショナルにし(緩和的な劣化)、並列化可能なものを並列に。

アセンimetり

ファンインは負荷を集中させる。ファンアウトはリスクを乗数します。最も影響のあるノードでグラフを最適化することで、両方を最小限に抑えます。

データベース(最高のファンイン): アグリリティにダウンストリーム結果をキャッシュする。読み取りリプリカを、複数のノードにファンインを分散させるために使用します。

オーケストレーター サービス(最高のファンアウト): 回路ブレーカーを依存関係ごとに設定、緩和的な劣化、バルクヘッドを使用します。

バックエンドのリプリカが、各々が99.95%の独立性で4つのダウンストリームサービスを呼び出します。(1) 成功した応答が必要な場合、バックエンドの可用性の上限はどれくらいになりますか? (2) 2つがオプショナルに変更され、緩和的な劣化(利用できない場合にキャッシュフォールバックを置き換えます)となりますとすると、上限はどれくらいになりますか?

挿入されたノードは柔軟性をもたらします

インダイレクション = 中間ノードの追加

プロキシがない場合のグラフは:client -> backendです。クライアントはバックエンドのアドレスについて知っています。バックエンドが移動するには、クライアント(DNSまたは構成)を通じて更新が必要です。これは、緊密な結合です。

プロキシがある場合のグラフは:client -> proxy -> backendになります。クライアントはプロキシだけを知っています。バックエンドが移動するには、プロキシのアップストリーム構成を更新する必要があります、クライアントは更新されません。

グラフの操作: 既存のエッジにノードを挿入します。新しいエッジ client -> proxy は安定しています。新しいエッジ proxy -> backend は今チームが管理するものになります。

幾何学的読み取り: インダイレクションは、上流の変更と下流の変更が分離するレイヤーを追加します。各レイヤーのエッジは独立して再構成できます。

インダイレクションのコスト

各レイヤーは:

- 1つのレイテンシー (クライアントからプロキシへのエッジ)

- 1つのカット・バーティックス (プロキシ自体)

- 1つの誤構成の可能性が増える

利点(再構成、スケーラビリティ、保護、TLSの終端、負荷分散)は、通常、どの非平凡なシステムでも、コストを上回ります。しかし、限界があります:インダイレクションのレイヤーごとに1つのホップと1つのSPOF候補が追加されます。

民間のルール: 問題は、インダイレクションのレイヤの追加で解決できます(インダイレクションのレイヤが多すぎる問題を除く)。

A team adds a CDN in front of an existing reverse proxy. The path goes from `client -> proxy -> backend` (2 hops) to `client -> CDN -> proxy -> backend` (3 hops). Name two benefits of the indirection (graph-theoretic terms welcome) & two costs.

アーキテクチャをグラフとして読み取る

合成

システムのアーキテクチャをグラフとして読むことができます:ホップをカウントし、カット・バーティックスを特定し、ファンインの集中度を測定し、可用性の屋根を計算することができます。

すべての四つのことを適用してください。

新しいサービスは、このアーキテクチャを持っています:クライアント -> CDN -> リバースプロキシ(2つのレプリカ) -> バックエンド階層(8つのレプリカ) -> {プライマリDB、キャッシュクラスタ(3ノード)、外部API}

分析:(1) 単一のリクエストパス上の最大ホップカウントは何ですか?(2) どの階層が最高のファンインを持っており、それはスケーリングにどのような意味を持つか?(3) DBが99.95%、キャッシュが99.95%、外部APIが99.9%であり、すべて必要の場合、バックエンドのアビリティーシーリーフはどれですか?(4) 最も多くのユーザーを切断する単一のノードはどれですか?

伴侶ノート

伴侶ノート

この幾何学のレッスンは、プロキシ&オリジンのメインレッスンを有向グラフ解析として再構成します。

次の伴侶レッスンは、geometry_of_stateless_horizontal_scalingで、メインのスケーリングレッスンからリプリカ数学を導き、キューイング曲線、Little's Law、および80%利用率の屈曲を幾何学的に導出します。

おおやまでした。