この記事は Gunosy Advent Calendar 2020 の 20日目の記事です。
広告技術部のUT @mocyuto です。
今回は既存システムをインスタンス（Opsworks）管理していた広告配信サーバをkubernetesに移行した話です。
Gunosyでは広告配信サーバがいくつかありますが、今回移行したものがOpsworksで管理していた最後の配信サーバとなっていたため、 今回の移行で全ての広告配信サーバがkubernetes上に乗りました。
チームの話
突然チームの話が出てきましたが、イメージが付きやすいかと思い、どういうメンバーで移行を実施したかを紹介しておきます。
移行を実施したメンバーは以前紹介したkubernetesで広告システムを作ったメンバーと同じです。
広告チームには特に専任でインフラを見るという人はおらず、全員がフロントからインフラまでを見ています。 なのでチーム全体で移行の作業を実施していました。 もちろん開発案件は他にもあるので、同時並行で開発は進めていました。
新規で作ったときはまだチームもEKSの知識がほぼゼロのところからスタートしたのですが、 今回はスタートから知識がある状態ですすめることが出来たので心強かったです。
移行への決断
既存システムから移行した理由としては、コストカットが多くを占めます。 Opsworksで運用していた際は、オートスケールなどは実施しておらずピーク帯に合わせた台数でインスタンスを運用していました。 正確にはピーク帯にはtimebaseで台数を増やすなどはしていましたが、基本的にはオートスケールしていませんでした。
そんな折にインスタンスのコストを比較していると、以前kubernetesで構築した配信システムとこのシステムのコストが2倍近く違うことわかり、 更にリクエスト量はほぼ同じ、むしろ移行対象のシステムのほうが全体としては若干少ない状況でした。
システムが同じではないのでサーバの負荷なども違い一概にコストが半分になるとは思っていませんでしたが、 少なくとも3分の2までは減りそうだなという見立てから移行をすることに決まりました。
また広告の配信サーバの運用がkubernetesで統一されるというのも一つのメリットでありました。
実際の移行
移行方法としては単純で以下の方法で実行しました。
- kubernetes上で移行するシステムを構築する
- ステージング環境でテスト
- Route53のWeighted routingでトラフィックを順次移行
移行先のアーキテクチャ
アーキテクチャに関しては以前紹介したものと大枠は変わっていません。 データストアがこちらのシステムのほうが多いのでそこは変わってきますが、 spotメインで組むAPIのdeploymentとオンデマンドインスタンスで組むfluent aggregatorのstatefulsetという構成は同じです。
移行の際ハマったところ
システム構築に関しては、以前作ったシステムと構成としても似ていたのでほぼ考慮することがありませんでした。 また、同一クラスタに別ASGとして組んだので、クラスタのセットアップなどもなくスムーズに構築が完了しました。
しかし最後までスムーズにはいきませんでした。 Route53でトラフィック制御をしていたのですが、10%トラフィックをkubernetes側に流しているはずなのに集計すると5%くらいしか流れていませんでした。 原因としては、接続先クライアントでDNSのルート情報をキャッシュしていたからだったのですが、 ここまでの問題の切り分けにすごく時間がかかりました。
以下がトラフィック問題を解決するまでの時系列となります。
- トラフィックの設定が10%のはずなのに5%しか流れていない
- 欠損の可能性を検討
- ALB Ingress？
- envoyプロキシ？
- fluent？
- 合計値としては欠損してなさそう
- k8sへのトラフィックを100%に
- 旧環境へトラフィックが流れている
- DNSがおかしい？
- Route53では100%にALBで新旧のトラフィックルーティングをする
- 各メディアごとに集計を実施
- 明らかにあるメディアだけ集計値が少ない
- 該当の接続先にDNSキャッシュを消してもらう
- 期待しているトラフィック流量に
移行の際、kubernetes側のトラフィックかOpsworks側のトラフィックかをわかるフラグをログに含めることで、 ルーティングの割合と実際の流れた割合を比較することができました。
DNSはttlだけではなくクライアントのキャッシュなども影響があるので、 なるべくDNSでのルーティングは早めに終わらせ、ALBのWeighted Routingで検証することをオススメします。
各種新規機能投入
こちらは移行に際して実施したものですが、せっかく移行するのでついでに運用などもカイゼンしていくためいくつか新しい機能も投入しました。 もちろん本番で稼働しています。 これらに関しては、以前のAdvent Calendarに他のメンバーが書いてくれています。
チームでそれぞれ新機能の追加などを実施してくれているので大変心強いです。 現在も引き続き運用しやすいようにチームでシステムのカイゼンを行っています。
移行後のコスト推移
単純比較はできないですが、インスタンスのコストは図のように変化しました。 以下図はコストエクスプローラで出したインスタンスの償却コストです。 緑がOpsworksで運用していたインスタンスのコストで青が新しく構築したkubernetesでのインスタンスとなっています。 当時の見立てよりも大幅に大きいおよそ2/3のコスト削減に成功しました。
まとめ
移行という作業は既存のシステムを把握しそれを新しい環境に移すため、障害や事故などが発生しやすいですが、 それを補うほどのメリットが往々にしてあるので、恐れずチャレンジすることが大事かなと思います。
明日はitayaさんの「Fitbitのカスタムレポートを作成してLINEに通知する」です！
