CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー ＞ 第89回 Googleのアプリケーション環境を支えるシャーディングシステム「Slicer」（パート2）」を公開しました。
＃＃＃
はじめに
前回に続いて、2016年に公開された論文「Slicer: Auto-Sharding for Datacenter Applications」を元にして、Googleが提供するアプリケーションのバックエンドで利用されている「シャーディングシステム」について解説します。今回は、もう一歩踏み込んだ、より詳細なアーキテクチャーを紹介します。
Slicerのアーキテクチャー
前回の記事では、Slicerのアーキテクチャーの概要を（前回の記事にある）図2のように示しました。ただし、実際の環境では、クライアント（Clerk、Slicelet）がSlicer Serviceと直接に通信するわけではありません。前回の図1に示したように、秒間200万〜700万リクエストを処理する大規模なシステムですので、クライアントの数は膨大になります。クライアントとSlicer Serviceの通信がボトルネックにならないように、処理を分散化する必要があります。図1は、この点を示したより詳細なアーキテクチャーになります。
この続きは以下をご覧ください
(リンク »)
はじめに
前回に続いて、2016年に公開された論文「Slicer: Auto-Sharding for Datacenter Applications」を元にして、Googleが提供するアプリケーションのバックエンドで利用されている「シャーディングシステム」について解説します。今回は、もう一歩踏み込んだ、より詳細なアーキテクチャーを紹介します。
Slicerのアーキテクチャー
前回の記事では、Slicerのアーキテクチャーの概要を（前回の記事にある）図2のように示しました。ただし、実際の環境では、クライアント（Clerk、Slicelet）がSlicer Serviceと直接に通信するわけではありません。前回の図1に示したように、秒間200万〜700万リクエストを処理する大規模なシステムですので、クライアントの数は膨大になります。クライアントとSlicer Serviceの通信がボトルネックにならないように、処理を分散化する必要があります。図1は、この点を示したより詳細なアーキテクチャーになります。
この続きは以下をご覧ください
(リンク »)
本プレスリリースは発表元企業よりご投稿いただいた情報を掲載しております。
お問い合わせにつきましては発表元企業までお願いいたします。
お問い合わせにつきましては発表元企業までお願いいたします。
