遅ればせながら１１月３日のPHP Conferenceで発表してきたことについて補足交え、ブログをかきます
発表資料は上記の画像のリンクからたどってみてください。 ちなみに動画で見たい方はコチラです
(動画がアーカイブされることを知らず、発表前、プラプラしているのを取られちゃってますが・・・)
kubernetesをつかいはじめ、もろもろつまづいたところをまとめ、今後のみなさんの導入の助けになれば、といった内容になっています。
スライドにもありますが、kubernetesの特徴として
・デプロイの自動化
・アプリケーションをスケーリング
・ハードウェアの使用を最適化
があげられます
用語が覚えるまでピンとこなかったので、用語の解説もスライドにのせています
kubernetesのPodの管理は非常に優秀で、基本的にDeploymentに状態を定義すれば、あとは気にすることはありません
Rolling Updateもすばらしい機能です
ただし、自分が携わっているゲームの運用において、Rolling Updateは運用上都合がわるいです。
ゲームでは、ユーザへ不公平感がでないようにすることが重要で、サーバの更新（プログラムの挙動の変化）がすべてのユーザ同時に起こることがのぞまれます。
たとえば、バトルに関するゲームで、スキルの発動の不具合を直すデプロイをしたとき、
ユーザが接続したサーバによって、スキルの発動結果が異なる結果になったら、公平感がなくなってしまいます。
そのため、基本的にはサーバの更新がサーバによらず、同時に反映されてほしいものです。
そこで、Rolling Updateではなく、ブルーグリーンデプロイをkubernetesで行うにはどうずればよいかを検証してみました。
発表スライドにありますが、以下、２種類の方法で検証、比較しています
(A) Ingress(LB)によるブルーグリーンの切り替え
(B)Serviceの振り分け先を変更することによるブルーグリーンの切り替え
です
発表スライドで試したときには、Node数３、Pod数３で試したのですが、今回、Node数、Pod数が多いときの挙動で、デプロイの動作に違いが出るかも同時に比較してみました。
以下、結果です(GKEで実施しています)
(1)Node数2、Pod数20の環境でIngressでBlue系をGreen系に切り替えたとき
縦軸はreq/s、横軸は、デプロイしてからの経過時間です。約80req/sのアクセスをしたときに、Blue系のレスポンスがかえってきたときは青のグラフ、Green系のレスポンスがかえってきたときは赤のグラフになっています(以下グラフの見方は同様です)
(2)Node数2、Pod数20の環境でServiceを更新してBlue系をGreen系に切り替えたとき
(1)と(2)を比べてわかることは、(2)の方が、Blue系のレスポンスが０になるまで時間がかかっているということです。
(1)は(2)にくらべ、Blue系のレスポンスが０になるまでの時間が短いです。
ただし、デプロイ後に直にGreen系のレスポンスがかえってくるわけではなく、Green系のレスポンスがかえってくるようになるまで１分くらいかかっていることがわかります。
次にNode数、Pod数を増やしてみた結果をみてみます。
(3)Node数20、Pod数200の環境でIngressでBlue系をGreen系に切り替えたとき
(4)Node数20、Pod数200の環境でServiceを更新してBlue系をGreen系に切り替えたとき
Node数、Pod数を増やしてみたところ、傾向は同じで、より顕著に違いがわかるようになりました。
LBで切り替える場合は、Node数、Pod数によらず、Green系のレスポンスが0になるまでの時間は(1)とくらべ、あまり変わりません
一方、Serviceで切り替える場合は、Node数、Pod数が増えると、Green系のレスポンスが、なかなか0にならないのがはっきりとグラフに現れています
上記検証結果をうけて、現時点（2016/11/9)のkubernetesのGKE上の動作では、ブルーグリーンデプロイを実施するのであれば、LBによる切り替えのほうが望ましい、と自分は結論づけました。
みなさんがkubernetesを使うときの参考になれば幸いです