グーグルのクラウドを支えるテクノロジー > 第89回 Googleのアプリケーション環境を支えるシャーディングシステム「Slicer」(パート2)

※この記事は読者によって投稿されたユーザー投稿です:
  • 編集部の見解や意向と異なる内容の場合があります
  • 編集部は内容について正確性を保証できません
  • 画像が表示されない場合、編集部では対応できません
  • 内容の追加・修正も編集部では対応できません

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は、この点を示したより詳細なアーキテクチャーになります。

この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai289.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

UX
ユーザーの体験や経験を表す言葉。ある製品サービスを利用する前の期待値、実際に利用 ...→用語集へ

連載/特集コーナーから探す

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]