ShopifyのAndy Kwiatkowski氏がベルリンのVelocityカンファレンスで講演して、ShopifyがKubernetesのカスタムオートスケーラ(autoscaler)を開発した理由について説明した。既存の自動スケールソリューションがShopifyのニーズを満足しなかった大きな理由は、同社に流入する巨大かつ急激なトラフィック要求にある。さらに同社は、スケールダウン時や複雑なスケール条件におけるコスト効率の高いソリューションも必要としていた。
Kwiatkowski氏によれば、ShopifyのWebサイトでは、特にセールスキャンペーンや"フラッシュセール"時に大規模かつ急激なリクエストが発生する。フラッシュセールとは、通常は15分から20分といった短時間に行われるセールである。従って、高速なスケールアップが必要になる。新たなノードのスピンアップやDockerイメージのダウンロード、デーモンセットなどのアプリケーションの起動といったアクティビティを持つリアクティブなスケーリングは、同社では役に立たない。スケールアップに平均20～25分も要するようでは、自動スケールアップが完了してキャパシティが増大した頃には、フラッシュセールは終わっているかも知れないのだ。
突然のスパイク的なトラフィックに対応するため、Shopifyでは、Goを使ったカスタムオートスケーラを開発した。現時点ではオープンソース公開はされていない。合わせて同社には、安全なデプロイメントを行うためのコントロールや、過去データを使用するような複雑なスケール条件の設定を行う必要もあった。同社のオートスケーラは30秒毎に起動し、次のフラッシュセールに必要なレプリカを追加する。
スケールアップとスケールダウンは月毎のクラウド費用にも影響するため、オートスケーラはそのために有用な判断を行う必要がある。そこで、クラスタに必要なレプリカ数を決定するためにShopifyは、KubernetesのHPAから流用したリスク対コスト分析の公式を使用している。まず、サーバをどの程度ビジーにしたいかを定義する。その上で、サーバのビジー状態と存在するレプリカ数に基づいて、クラスタの所持すべきレプリカ数を公式から導き出すのだ。設定したクラスタの利用度を常に維持することが、この方法の目標である。
クラスタのスケールダウンには時間を要するため、コスト増加の原因となる。従って、コスト効率のよいスケールソリューションを実現するには、過去のトラフィックデータの分析によるオートスケーラの改善が必要だ。何回かの経験を通じて、Spotifyでは、一般的なソリューションが行っているような平均CPU使用率を使用したスケーリングルールの設定では、スパイクを正確に予想できないことに気付いた。CPU使用率の中心値(median)を使用した方が、一時的な容量増に対して良い結果が得られたのだ。ただし、もっと長時間(30分間)のスパイクに対しては、レプリカが追加されないという問題がある。これを解決するために、CPU使用率として指数加重平均(EWA)を使用して、古い値よりも新しい値をより重要視することで、より多くのレプリカが短時間に追加されるようにした。
Shopifyのオートスケーラでは、CPU使用率の中央値とEWAの両方を計算して、大きな差異がなければ中央値を使用し、そうでなければEWAを使用するようになっている。この方法で、必要な時に、必要なだけのレプリカを追加するようになる。
最後にKwiatkowski氏は、収集データにヌル値やゼロ値、旧値や欠測といったエラーが発生した場合について話した。スケールアップおよびダウン時の問題を回避するため、このようなデータエラーが発生した場合、同社では、安全を考えて常に最大容量にスケールするようにしている。同時に、スケールダウン時の問題を回避するため、最小にレプリカ値の設定も行っている。