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

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

＃＃＃

はじめに
　前回に続いて、2016年に公開された論文「Slicer: Auto-Sharding for Datacenter Applications」を元にして、Googleが提供するアプリケーションのバックエンドで利用されている「シャーディングシステム」について解説します。今回は、タスクの割り当てを自動調整するシャーディングのアルゴリズムを説明します。

シャーディングのアルゴリズム
　前々回の記事では、シャーディングシステムは、ロードバランサーの機能拡張にあたるものだと説明しました。新しいサービスをSlicerに登録すると、まずはじめは、キーのハッシュ値全体を同じ幅のレンジに等分割して、それぞれを同数のタスクに割り当てます。たとえば、ハッシュ値が「a以上b未満」のレンジはタスク1〜3、「b以上c未満」のレンジはタスク4〜6と言った具合で、それぞれのレンジの幅は同一になります。仮に、それぞれのキーに対するリクエスト数が同じであれば、それぞれのタスクは同数のリクエストを受け取ることになります。
　もちろん、現実にはそのようなことはありません。それぞれのキーに対するリクエスト数に偏りがあるため、一部のタスクが多量のリクエストを受け取る、あるいは、CPUやメモリーなどのリソースの使用量が極端に増加するといったことが起こります。このような際に、タスクごとのリクエスト数、あるいは、リソースの使用量をなるべく均等に近づけることがSlicerの役割になります。たとえば、リクエストが多いレンジをさらに細かく分割して、別々のタスクに割り当て直すという方法が考えられます。あるいは、逆に、リクエストが少ない隣接する2つのレンジを結合して、1つのレンジにするという方法もあります。Slicerは、これら2つの方法を用いて、ハッシュ値の分割方法を調整することで、タスクごとの負荷のばらつきを抑えます。

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