グーグルのクラウドを支えるテクノロジー > 第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
ソーシャルもやってます!