みなさん、こんにちは。サイバーエージェントでサーバーを担当しているエンジニアの河野(@tomox)です。

オルタナティブガールズ(以下オルガル)ではパブリッククラウドのGoogle Cloud Platform(以下GCP)を利用しています。本記事では、オルガルでのGCPの活用事例、特にAutoscalerにフォーカスした内容をお届けします。

GCP Autoscaler

オルガルのAPIサーバーは、GCEのAutoscalerを利用し、負荷状況に応じて最適なインスタンス数のみで稼働ができるようにしています。Autoscalerを利用することで無駄なインスタンスが稼働することがなくなるため、お財布に優しい運用を行うことができます。

GCPでAutoscalerを利用するにあたり、いくつかこだわったポイントがあります。

General GroupとAutoscaler Group
Graceful Shutdown

上記の2つの内容について、詳しく説明していきます。

General GroupとAutoscaler Group

オルガルでは、GCEインスタンスをGeneral GroupとAutoscaler Groupの2種類に分けて運用しています。

General Group: 負荷に関わらず、稼働インスタンス数が増減しないグループ。
Autoscaler Group: 負荷に応じて(LB利用率)、稼働インスタンス数が増減するグループ。

Autoscaler Groupに所属しているインスタンスはいつ破棄されてもよい状態にしなくてはなりません。稼働台数が変動し、インスタンスが破棄されることを前提にした場合、色々と不都合が起きることが予想されたため、破棄される心配のないGeneral Groupを用意することにしました。

General Groupは例えば、

new relicなど、agentを常駐させてパフォーマンス計測を行うようなサービスを利用したい場合
パフォーマンスに影響があり、かつサービス全体で行うまでもないような本番調査用処理(プロファイリング、ログレベルの変更など）を行いたい場合
middlewareによるmemory leakなど、長期的なモニタリングが必要な場合

などのシーンでの活用を想定しています。

Graceful Shutdown

Autoscaler Groupに所属しているインスタンスは負荷状況に応じて破棄される話をしましたが、オルガルではユーザー影響なく破棄(shutdown)するGraceful Shutdownの仕組みを導入しています。具体的には、GCPのHTTPS load balancerからの切り離しを行い、ユーザーからのアクセスがない状態でshutdownが行われるようにしています。

GCPのLBは、定義したhealth checkの内容を元に、インスタンスへの疎通が異常しきい値を超えると切り離される仕組みになっています。これに対し、googleはドキュメントでshutdown時に実行されるshutdown scriptで以下のスクリプトを実行し、LBから切り離されるまで待つことを推奨しています。

※ 2016/11現在

このコマンドを実行した場合、LBから指定したポートへのアクセスをブロックすることになるため、health check 以外にuser requestもブロックしてしまうことになります。 ※health checkとuser requestのポートが異なる場合はこの限りではありません。

↓↓↓コマンド実行後↓↓↓

health check / user requestともにブロックされる

Graceful Shutdownを行うには、health checkはブロックするが、user requestは受け付ける状態を作る必要があります。

理想の状態

これを実現するために、アプリ側でhealth_blockフラグを用意しました。このフラグがONになると、実際の状態に関わらず、health checkへのアクセスをエラーとして返すようになります。 health_blockフラグをONにするAPIを用意し、shutdown scriptにて以下のようなコマンドを実行することで、Graceful Shutdownを実現しました。

# blocking health check connections for http(s) load balancing
curl -x post http://localhost/health_block_on
sleep 15

# web stop
/usr/local/web/bin/webd stop

※実際の処理とは異なります。あくまでイメージです。