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

私が編集支援している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