CNDT 2022 登壇資料.pdf

GKE の Spot VM / Preemptible VM 利用者を救う！
インフラコストを削減しながら可用性を維持できるソフトウェア『
Panope』
From 7knot.Co
1

2
自己紹介
・名前: 山本浩平
・twitter: @yamagai_0919
・所属: 株式会社7knot 代表
某ソシャゲのサーバーチーム (2022年入社)
・一言: 97年生まれです
おうち Kubernetes 楽しいです

このセッションで話すこと
1. GCP の Preemptible VM / Spot VM とは
2. Preemptible VM / Spot VM のメリットとデメリット
3. Panope とは
4. Panope の仕組み・機能
5. その他 Preempt への対処法
6. ...etc
3

Preemptible VM / Spot VM とは
4

5
Preemptible VM とは
(出典: https://cloud.google.com/compute/docs/instances/preemptible)

6
・GCP において、標準 VM よりもはるかに低価格で利用できる VM →
60%〜91%割引！

7
・24時間に一度、強制的にインスタンスが停止 (Preepmt)される
60%〜91%割引！

8
Spot VM とは
(出典: https://cloud.google.com/compute/docs/instances/spot)

9
Spot VM とは
60%〜91%割引！料金体系は Preemptible VM と同じ

10
・24時間に一度、強制的にインスタンスが停止 (Preepmt)される制限は無い
ただし、予期せぬタイミングで Preempt される
Spot VM とは
60%〜91%割引！料金体系は Preemptible VM と同じ

11
・24時間に一度、強制的にインスタンスが停止 (Preepmt)される制限は無い
ただし、予期せぬタイミングで Preempt される
Spot VM とは
・GCP において、標準 VM よりもはるかに低価格で利用できる VM
→ 60%〜91%割引！料金体系は Preemptible VM と同じ
・Preemptible VM に取って代わる存在 (GKE クラスタ作成時には Spot VM しか使えない)

Preemptible VM / Spot VM の
メリット・デメリット
12

13
Preemptible VM / Spot VM のメリット・デメリット
Preemptible VM Spot VM
メリット
デメリット

14
メリット・金銭的コストがかなり低い・金銭的コストがかなり低い
デメリット

15
デメリット・24時間に一度 Preempt される・予期せぬタイミングで Preempt
される

16
デメリット・24時間に一度 Preempt される
→ 1. 可用性の低下
・予期せぬタイミングで Preempt
される

17
デメリット・24時間に一度 Preempt される
→ 2. 運用コストの増加
・予期せぬタイミングで Preempt
される
→ 2. 運用コストの増加

18
デメリット①(可用性の低下)
可用性低下の原因 1
Preempt 時に突如いっぺんに Pod が終了されてしまう
→ PodDisruptionBudget が効かないため、動いて欲しい replica 数が保証できない(一定のレプ
リカ数を最低でも必要とするようなアプリケーションだと特に影響が大きい
→ Kubernetes v1.20 以降で有効化された kubelet graceful node shutdown により、Node, Pod
の終了は graceful に行われる
→ ちなみに Kubernetes v1.20 よりも前のバージョンだと、kubernetes からは Node, Pod が突
如使用不能になったように見え、 graceful shutdown することもない

19
terminationGracePeriodSeconds が最大でも 25 秒になってしまう
→ Preempt により Node が強制的にシャットダウンされるため、Pod の終了処理開始からコンテ
ナの強制終了までの時間が最大でも(約) 25 秒になってしまう
→ リクエストが集中した場合や、処理に時間がかかった場合などに、graceful shutdown が完了
する前にコンテナが強制終了され、処理が中断されることがある

20
Node が複数同時に再起動された場合
→ いっぺんに Pod がスケジュールし直され起動しようとすると、Node のリソースを奪い合ってし
まい、起動までに時間がかかることがある
→ Liveness Probe の設定によっては、無限に再起動されるようになってしまう場合もありうる
→ その間、Pod は処理を行うことができないため可用性低下に繋がる

21
デメリット②(運用コストの増加)
運用コストが増えてしまうケース

22
1. リソースを節約している場合
→ Node 数と replica 数、resource request の設定によっては、Pending な Pod が残り続けてし
まいマニフェストに設定した replica 数よりも少ない Pod しか動かないことがある
→ Cluster Autoscaler などを利用していない場合、Node Pool のサイズを上げて Pod をスケ
ジュールさせてから drain して.... など手作業が必要となりうる

23
1. リソースを節約している場合
→ Node 数と replica 数、resource request の設定によっては、Pending な Pod が残り続けてし
まいマニフェストに設定した replica 数よりも少ない Pod しか動かないことがある
→ Cluster Autoscaler などを利用していない場合、Node Pool のサイズを上げて Pod をスケ
ジュールさせてから drain して.... など手作業が必要となりうる
2. Node が複数同時に再起動された場合
→ いっぺんに Pod がスケジュールし直され起動しようとすると、Node のリソースを奪い合ってし
まい、起動までに時間がかかることがある
→ この場合、Pod を手作業で削除して別 Node にスケジュールされるようにするなどの手作業
が必要となりうる

24
デメリットまとめ
要するに....

25
要するに....
・こういう用途なら使えるかな？と思っても意外と用途が限定される

26
要するに....
・こういう用途なら使えるかな？と思っても意外と用途が限定される
・条件を気にしてお守りをしないといけないので、インフラ実費は節約できても
結局人的コストが高く付いてしまう
😕😕

Preemptible VM / Spot VM で金銭的コストを抑えつつ、
これらのデメリットを無くせないか...？
27

Preemptible VM / Spot VM で金銭的コストを抑えつつ、
これらのデメリットを無くせないか...？
28
作っちゃおう！

30
Panope とは
『インフラコストを削減しながら可用性を維持できるソフトウェア』
もう少し詳しく言うと...

『インフラコストを削減しながら可用性を維持できるソフトウェア』
もう少し詳しく言うと...
『GKE において Node のシャットダウンのタイミングを制御し、
Preemptible VM / Spot VM でも可用性を保って運用できるよう処理するこ
とで全自動でコストを抑えてくれるソフトウェア』
31
Panope とは

Panope を使ってみた結果
32

33
本番環境に導入してみた
・株式会社 WESEEK の GROWI.cloud というサービスに本番導入
・GROWI.cloud は Markdown Wiki サービスを提供する SaaS
・GROWI.cloud の個人向けプランでは、サービスを安価に提供する代わりに法人
向けプランと比較してSLOをやや妥協しつつもPreemptible VM での運用をしてい
た

34
GROWI.cloud に導入してみた結果...(6/10 に導入開始)
冗長化していないPod (シングルレプリカ)の可用性の1日間平均
99.52%

35
GROWI.cloud に導入してみた結果...(6/10 に導入開始)
99.97%
99.52%
99.5%台だった可用性
が 99.9%後半に UP！

36
99.59%

37
99.97%
99.59%
99.5%台だった可用性
が 99.9%後半に UP！

38
冗長化しているPod (複数レプリカ)の可用性の7日間平均
99.95%

39
冗長化しているPod (複数レプリカ)の可用性の7日間平均
99.98%
99.95%
99.95% だった可用性
が 99.98% に UP！

40
Panope をおすすめしたい対象
Panope は特に以下のような考えを持つ組織におすすめです
・すでに Preemptible VM, Spot VM を使って GKE を運用しているが、可用性の維持や運
用コストに悩んでいる
・本番環境や開発環境用の GKE を安く使いたいけど、それによって人的コストが増えるの
は嫌
・フロントとサーバーなどチームが完全に分離しており、開発環境が止まると影響範囲が
大きく、開発環境の可用性もある程度担保したいものの、金銭的コストも抑えたい

Panope の基本機能とアーキテクチャ
41

1. Preemptible VM / Spot VM を Preempt される前に graceful shutdown
→ GCE により Preempt される前に Panope のタイミングでシャットダウンすることで、必要数の Pod を
残しながら安全に Node を入れ替える
2. シャットダウンする Node の代わりとなる Node を事前にプロビジョニングし、Pod を退避さ
せる
→ スペック不足でスケジュールされない Pod をケア
3. 事前に Node を cordon してから 1replica の Deployment のみ Rollout
→ 1replica かつ strategy: RollingUpdate な Deployment についてもダウンタイムが発生しないように
42
Panope の基本機能

せる
43

せる
44

せる
3. 事前に Node を cordon してから 1replica の Deployment のみ rollout
45

controller… agent へ GKE クラスタ内の Spot /
Preemptible VM に対する操作内容を命令するコンポーネン
ト。7knot 側のクラスタで管理している。
agent… controller からの命令を実行するコンポーネン
ト。サービス利用者側の GKE クラスタにインストールする。
インストールには helm chart を用いる。
observer... Panope が処理を開始するために必要な
annotation の操作など、Spot / Preemptible VMごとに必要
な処理を行うコンポーネント。agent と同様に、サービス利用
者側の GKE クラスタにインストールする。agent と同じ
helm chart でインストールされる。
46
Panope のアーキテクチャ
Panope helm chart:
https://github.com/7knot/helm-charts

annotation の操作など、Spot / Preemptible VM ごとに必要
47
Panope helm chart:

controller… agent へ GKE クラスタ内の Spot/
48
Panope helm chart:

49
Panope helm chart:

agent
controller
51
Panope の仕組み

agent
controller
1. クラスタ内の全 Spot / Preemptible VM の情
報を送ってくるように命令
52
Panope の仕組み

agent
controller
2. 全 Spot /
Preemptible VM の情
報取得
53
Panope の仕組み

agent
controller
2. 全 Spot /
報取得
3. クラスタ内の全 Spot / Preemptible
VM の情報を返す
54
Panope の仕組み

agent
controller
2. 全 Spot /
報取得
4. 全 Spot / Preemptible
VM の情報を元に各 Spot /
Preemptible VM に必要な
処理を思考
55
Panope の仕組み

agent
controller
2. 全 Spot /
報取得
4. 全 Spot / Preemptible
VM の情報を元に各 Spot /
Preemptible VM に必要な
処理を思考
5. 必要な処理を Spot / Preemptible VM ごとに送信
56
Panope の仕組み

1. UpdateAnnotations
2. CordonNode
3. CreateNode
4. RollingUpdateSingleReplicaDeployment
5. DrainNode
6. DeleteNode
57
処理の流れ

1. UpdateAnnotations
2. CordonNode
3. CreateNode
5. DrainNode
6. DeleteNode
58
処理の流れ

1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与
2. CordonNode
3. CreateNode
5. DrainNode
6. DeleteNode
59
処理の流れ

2. CordonNode
3. CreateNode
5. DrainNode
6. DeleteNode
60
処理の流れ

2. CordonNode : annotation を元に対象の Node を cordon
3. CreateNode
5. DrainNode
6. DeleteNode
61
処理の流れ

3. CreateNode
5. DrainNode
6. DeleteNode
62
処理の流れ

3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング
5. DrainNode
6. DeleteNode
63
処理の流れ

5. DrainNode
6. DeleteNode
64
処理の流れ

4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア
5. DrainNode
6. DeleteNode
65
処理の流れ

5. DrainNode
6. DeleteNode
66
処理の流れ

5. DrainNode : Node から Pod を退避させる
6. DeleteNode
67
処理の流れ

6. DeleteNode
68
処理の流れ

6. DeleteNode : 空っぽになった Node を削除
69
処理の流れ

70
処理の流れ

71
処理の流れ
この一連の動作を Panope draining と呼んでいます

annotations:
panope.net/boot-time: "2022-02-08T19:49:09Z"
panope.net/time-to-kill-node: "2022-02-09T07:08:09Z"
annotations:
boot-time に一定の時間を加算した時刻を time-to-kill-node として annotation に付与
(処理のタイミングが被らないように 3分以上の間隔を開けるようにしている )
Observer Observer
Node1 Node2
72
処理の流れ①(UpdateAnnotations)

Spec:
Unschedulable: true
2022-02-09T05:12:59Z(Annotation の時刻+1h)
Node1 Node2
73
Observer Observer
処理する際の時刻が time-to-kill-node の時刻を過ぎていた場合、 Node を cordon し Pod
がスケジュールできないようにする
処理の流れ②(CordonNode)
annotations:
annotations:

annotations:
panope.net/need-to-create-node: "true”
agent が Google Cloud API を使って
Node をプロビジョニング
need-to-create-node の annotation があった場合、新 Node をプロビジョニング
Node2 Node3
Node1
74
Observer Observer Observer
処理の流れ③(CreateNode)

cordon した Node 上に 1Pod の Deployment がいた場合、rollout する
Node2 Node3
Node1
75
SingleReplica
Deployment
1Pod で strategy: RollingUpdate
な Deployment を rollout
rollout した Deployment の新 Replicaset の
Pod が作成される
処理の流れ④(RollingUpdateSingleReplicaDeployment)

『Daemonset に属する Pod』と『kube-system namespace の kube-dns 以外の Pod
を除く Pod 』を全て drain の対象として、対象の Node に載るそれらの Pod を drain
する
Node2 Node3
Node1
76
evict すべき Pod が存在したらそれらを evict Pod が evict されてくる
処理の流れ⑤(DrainNode)

drain が完了したら cordon されていた Node を削除
Node2 Node3
Node1
77
agent が Google Cloud API を使って
Node をシャットダウン
処理の流れ⑤(DeleteNode)

Observer Observer
Node2 Node3
78
古い Preemptible VM / Spot VM (Node1) が 24h 立つ前に削除され、
新たな Preemptible VM / Spot VM (Node3) で Pod が動く
1周が終わると...

その他 Preempt への対処法
79

80
その他 Preempt への対処法①
→ Pod の終了開始時点で存在するコネクションをいきなり中断させることのないよ
う、処理し終わるまで終了を待つような実装を行うことで、処理が中断されてしまうリ
クエストを減らす
Graceful shutdown の導入

81
その他 Preempt への対処法②
spec:
containers:
- name: web
image: nginx:latest
ports:
- containerPort: 80
name: web
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 5"]
preStop の設定
・コンテナが終了する直前に呼び出されるフックのこと
→ SIGTERM は preStop 終了後に送られる
・exec / httpGet / tcpSocket の 3 種類から選択できる
・このフックが失敗した場合、コンテナは強制終了する
preStop とは？

82
その他 Preempt への対処法②
→ Pod の終了時には、非同期でコンテナのシャットダウン・endpoint からの除外・Owner
からの解放が行われる
→ その際、endpoint からの除外よりも先にコンテナのシャットダウンが行われてしまう
と、リクエストを処理できない Pod にリクエストが転送されてしまう
→ これを防ぐために、preStop で一定の時間 sleep させるなどして kubelet からの
SIGTERM を遅らせることで、先に endpoint からの除外を完了させる
→ また、preStop でアプリに通知して Readiness Probe を失敗させることで SIGTERM が
送られる前に endpoint から除外させることも可能
preStop の設定

84
その他の悩み
Kubernetes 運用する中で手間がかかる作業って...？

85
その他の悩み
Kubernetes クラスタのバージョンアップ！！！

86
その他の悩み
・ダウンタイムを作りたくない (複数クラスタあればなぁ ...
・全体のリソースを減らしたくない (スケジュールされない Pod が出るかも...
・時間をかけたくない (作業時間取られるし自動化できたらなぁ ...

87
その他の悩み
・ダウンタイムを作りたくない (複数クラスタあればなぁ ...
・全体のリソースを減らしたくない (スケジュールされない Pod が出るかも...
・時間をかけたくない (作業時間取られるし自動化できたらなぁ ...
気にしないといけないことが多い！！！

Panope のその他の機能
88

89
Panope のその他の機能①
Kubernetes バージョンオートアップグレード機能

90
→ Node Pool に panope.net/auto-upgrade-kubernetes-enabled のラベルを付与すること
で有効化できる
→ メンテナンスウィンドウの設定や、アップデートするバージョンの幅 (パッチ・マイナー
など) も設定できる
→ アップデート時には、 Panope が以下の処理を順に行う
1. Node Pool を新設する
2. 旧 Node Pool の Panope draining を行う
3. 旧 Node Pool を削除する

91
→ Node Pool に panope.net/auto-upgrade-kubernetes-enabled のラベルを付与すること
で有効化できる
→ メンテナンスウィンドウの設定や、アップデートするバージョンの幅 (パッチ・マイナー
など) も設定できる
→ アップデート時には、 Panope が以下の処理を順に行う
1. Node Pool を新設する
2. 旧 Node Pool の Panope draining を行う
3. 旧 Node Pool を削除する
ダウンタイム無し・リソースの減少無し・全自動！！

92
Panope のその他の機能②
在庫枯渇時の failover

93
→ Preemptible VM / Spot VM には GCE 側の在庫枯渇により、新規に Preemptible
VM / Spot VM をプロビジョニングできないことが起こりうる

94
→ この在庫枯渇は、時間の経過に伴って GCE 側のリソースに空きが出ると解消され
る

95
る
→ 在庫枯渇が起きた場合、 Panope draining のうち、CreateNode が正常に完了しな
い

96
る
→ 在庫枯渇が起きた場合、 Panope draining のうち、CreateNode が正常に完了しな
い
→ 『在庫枯渇が発生した際には標準 VM の Node Pool を一時的に作成し、在庫枯渇
が終了してから Preemptible VM / Spot VM をプロビジョニングする』という機能により
在庫枯渇の影響を回避する

98
ここまでのまとめ
1. Preemptible VM / Spot VM にはいくつかデメリットがある
→ 可用性の低下、運用コストの増加
2. 上記のデメリットへの対策として Panope を作成
→ Panope は、Panope draining という一連の処理によって可用性を維持しつつ Preemptible VM /
Spot VM での運用を可能にする
3. Panope に加えて可用性を低下させない方法もある
→ preStop の設定、graceful shutdown の実装などで可用性の低下防止が見込める
4. Panope には付随機能もある
→ Kubernetes バージョンオートアップグレード機能や在庫枯渇時の failover 機能などがある

100
Panope のこれから
1. GKE 以外のパブリッククラウドへの対応
→ EKS, AKS などにも対応することで利便性を上げる
2. Spot VM に対しても Preempt のタイミングを予測
→ Spot VM に対して、Panope による Node の処理開始をもっとストリクトにやることでさらなる
節約を狙うことができる
3. Kubernetes や GKE の新機能に追従していく
→ Kubernetes 本体や GKE から新機能が出ることで、さらに可用性を高める工夫の幅が広がる
ので随時 Panope のアップデートを行っていく

annotations:
Observer
Node1
102
・現状、Preemptible VM に最適化しているため
Spot VM への最適化はこれからの課題
・ただし、基本的には Preemptible VM よりも Spot
VM の生存期間の方が長いため、 Spot VM でも有
用性はある
time-to-kill-node の時刻について
・boot-time に一定の時間を加算した時刻を
time-to-kill-node として annotation に付与

103
・Drain が完了しプロビジョニングされた Node が利用されるタイミングでその
annotation を外すことで、Cluster Autoscaler からの保護が必要な場合以外は
Node が Cluster Autoscaler による管理対象となるような仕組み
・Panope が特定の Node の cordon / drain を行う際に、事前にプロビジョニン
グしたばかりの Node には専用のannotation
(cluster-autoscaler.kubernetes.io/scale-down-disabled)を付与することで
Cluster Autoscaler による削除を防ぐ
Cluster Autoscaler との共存について
・Panope は Cluster Autoscaler との共存が可能

104
最後に
コロナウイルスの影響もありオフラインイベントでの登壇が初めてなので、
こういった機会をご用意していただきとても嬉しいです 👏👏
今日は弊社の CTO (@mugiokax) やメンバーもみんな来ているので、みなさま是非是
非この後でもいつでもお話ししましょう！
「こういうケースでも Panope 採用できそう？」などといった相談にも乗れますし、
技術の話や、おうち Kubernetes の話もぜひぜひ🙈

CNDT 2022 登壇資料.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a CNDT 2022 登壇資料.pdf

Similar a CNDT 2022 登壇資料.pdf (20)

Último

Último (8)

CNDT 2022 登壇資料.pdf