オルタナティブ・ブログ > 吉政忠志のベンチャービジネス千里眼 >

IT業界でベンチャービジネスの支援をしている執筆者が日々の活動ログと感じたことを、徒然なるままに書き綴っていきます。

グーグルのクラウドを支えるテクノロジー > 第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

Comment(0)