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

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

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー > 第88回 Googleのアプリケーション環境を支えるシャーディングシステム「Slicer」(パート1)」を公開しました。

###

はじめに
 今回からは、2016年に公開された論文「Slicer: Auto-Sharding for Datacenter Applications」を元にして、Googleが提供するアプリケーションのバックエンドで利用されている「シャーディングシステム」について解説します。以前はアプリケーションごとに個別の仕組みを作り込んでいましたが、効率のよいシャーディングシステムを開発するのはそれほど簡単ではありません。そこで、複数のアプリケーションから利用できる共有型のシャーディングシステムとして、「Slicer」が開発されました。現在では、Speech Recognition(音声認識)やCloud DNSなど、さまざまなサービスのバックエンドとして、1秒あたり200万〜700万リクエストを処理するシステムになっているそうです。

シャーディングシステムのユースケース
 ここで説明するシャーディングシステムは、クライアントからのアクセスを複数のアプリケーションサーバーに分配するロードバランサーの機能拡張にあたります。なお、Googleの環境では、アプリケーションサーバーの機能は、コンテナ管理システムであるBorgの「タスク」として稼働します。これ以降は、アプリケーションサーバーの代わりに「タスク」という用語を使用します。
 たとえば、先ほど挙げた音声認識サービスの場合は、さまざまな言語に対応する必要があり、各タスクは、言語ごとに専用のモジュールをメモリにロードします。ただし、メモリの使用量を最適化するために、すべてのモジュールを同時にロードするのではなく、タスクごとに異なるモジュールをロードしておき、英語のリクエストは、英語のモジュールをロードしたタスクにルーティングするといった処理を行います。仮に、英語のモジュールをロードしていないタスクに英語のリクエストが来た場合、リクエストを処理する前に(既存のモジュールを破棄して)英語のモジュールをロードしなおす処理が必要になり、リクエストに対する応答時間が長くなります。

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

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

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

今日の用語

アドネットワーク
サイトやSNS、アプリ、ブログなど、広告が掲載可能なWeb媒体を集約し、まとめて ...→用語集へ

インフォメーション

RSSフィード


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