やっていくしかないことを愚直にやってきた
齋藤光氏：やっていくしかないんですけど、やってきた内容としてはここまで紹介されたことを愚直にやってきたというのが大きいですね。1つは、真っ先に大きめのクラスタにはmax surge sizeを設定しました。Microsoftさんの推奨は33パーセントなんですけど、さすがにちょっと勇気がなくてですね（笑）。勇気がないというか、安全性とのトレードオフだとは思っていて、弊社では10パーセントで設定していて、今後、徐々に上げていけたらうれしいなと思っています。
これも先ほどお伝えしたんですけれども、そもそもパラメータを知らないとこの存在はわからない。しかもこれはポータルからは設定できないため、ドキュメントを読まないでポータルを眺めながらやっている人だと絶対に気づかないやつなので、気をつけたほうがいいと思います。弊社ではTerraformで設定しています。
あとはpdbですね。これも先ほど「邪魔をして失敗したことがある」と言っていたのは、minAvailableの設定をしていて邪魔していることが多かったからです。今、弊社ではmaxUnavailableの設定に切り替えてmax surge sizeに合わせて10パーセントに設定をしています。
あとはアップグレードだけじゃないんだろうとは思うんですけど、Gracuful Shutdown。PreStop フックの設定をしてPodが安全に停止をするところのケアをSREチームから開発チームにして、マニフェストファイルの改善をやってきました。
あとはパッチバージョンの自動アップグレード設定ですね。これも安心して自信を持ってやるためには、その設定内容にはけっこう気を配らなければいけないところです。わりと柔軟に設定できますよという話もあり、確かにある程度は柔軟に設定できたりはします。弊社では日中帯に設定をすることで対応する人が多い状態を作って、失敗・異常時の検知、リカバリー対応を早くする努力をしています。
アップグレードの罠
あとはウインドウ。メンテナンスウインドウとしては、当たり前ですが1日のピーク時間を避けて、あとは繁忙日とか。繁忙曜日というのがどの業界でもあると思うんですけれども、そこは避けて設定をしたほうがいいと思います。
先ほど「柔軟ですよ」と（吉川さんが）仰っていたんですけど、ちょっといろいろ言いたいことがあってですね（笑）。拒否設定でnotAllowedTimeというのがあるんですけど、（一つの）時間枠しか設定できなくて（笑）。自分は「あれは柔軟と言えるのか」みたいなところがちょっとあって、今後に期待をしたいなと思っています。
あとちょっと罠があるのは、最低4時間の枠を設定しなければならない。これは別にいいんですけれども。気をつけなければいけないのは、この4時間の枠にメンテナンスが終わりますよという意味じゃなくて、その枠のどこかでアップグレードが開始されますという意味になっているので、その枠の一番最後に開始されたら、そこから1時間アップグレードが始まるので、それは気をつけないといけないと思います。
あとは事前のメンテナンス通知はない。あとはベストエフォートなので、緊急でのパッチバージョンが出てきたら適用されてしまう可能性はあるというところは、実際に設定した者として注意点かなと思っています。ピーク時間帯を避けるという意味だと、小売りの業界は実店舗を伴う業界だとそうだと思うんですけど、だいたいピークは昼と夕方の5時、6時なんですよね。
だからこの最低4時間の枠もけっこう厳しいんだというところがあって、細かい設定は言えないんですけど、毎月第何曜日の午前中に設定をしています。参考までに。そんなとこをやってきていますという話でした。わりと真壁さんと吉川さんのおっしゃっていることがそこそこ実践できているのかなと自分では思っています。みなさんも褒めていただけるとうれしいなと思います。
練度を高めていくために何が必要か
そんな改善を進めていきましたよというのを通して、じゃあAKSアップグレードの練度を高めていくために何が必要なんでしょうというところです。3人目の問いかけですね。AKSのアップグレードは大変なんでしょうか？ 正直、本当に大変なのかというところです。やはりAKSというマネージドサービスがすばらしいというのもあって、オペレーション自体は別に大したことはないんだろうなと思っています。
でも失敗したりとか、なにかトラウマを抱えている人がいる。そういうトラウマを抱えるような大変な思いをしたり、リスクを恐れるのは本当にアップグレードそのものに対してなのかというのは、ちょっと問いかけたいところです。怖がらないという意味だと、まず冒頭でお伝えしたとおり、やっていくしかなくて、数をこなして徐々にこなれていくことが必要なので、JUST DO ITしかないんじゃないかなと思っています。
「口で簡単に言うけれども……」となるので、この次のスライドに続くんですけれども。じゃあ、そうやって安心して数をこなしていくためにはどうしたらいいかというと、こういう話に限らずですけど安心して失敗できる状況を作ることが大事かなと思っています。まず失敗そのものが検知できることですね。これはobservabilityやモニタリングの向上を進めていこうかなと。
失敗時にどうリカバリするんですかと。なにか壊れたら最悪は作り直すしかないので、作り直す準備をしましょう。そうなったらやはりクラスタをいつでもIaCで作り直せる、アプリケーションをCI/CDパイプラインでいつでもデプロイし直せる、observabilityツールとかAKSに載せた追加のものをCI/CDパイプラインでいつでもデプロイし直せる、大人の余裕が必要なんじゃないかなと思います。
ここで書くことは、他の話でも出てくることが多くて。結局そのAKSアップグレード自体に対してなにかをがんばるというよりは、ふだんやるべき運用の改善やブラッシュアップが実は大事なんじゃないんでしょうかというところが、今日の言いたいことでした。
失敗した場合にどうリカバリするか
おまけ的に、安心して失敗できる。もし失敗した場合にどうリカバリするんですか？ ほとんど真壁さんのスライドと同じですね（笑）。付け加えるならばですね、AKSのアップグレードのリトライ方法はやはりパッと見て出てきにくいというか、僕の目が節穴だから気づきにくいです。あとはポータルからやりたがる人は、ポータルからはリトライができないので、これに初めて遭遇すると「どうしたらいいんだ」と、普通に焦ります。
それでSRに起票するしかないというのがあるので、一応コマンドはここには載せているんですけれども、こういったコマンドでリカバリするというところですね。それを頭の隅に入れておいていただけるとうれしいです。
1回遭遇して良かったと思ったのは、もうSRに起票するしかないなとSRに起票したんですけど、SR起票の途中でこのコマンドをそのまま「これをやれば再実行ができるので、再実行をしてみませんか？」と。再実行を普通に提案されました。SR起票が1つ減りました。これは利用者としてもMicrosoftさんのテクニカルサポート担当の方にしてもお互いにwin-winだ。いい体験だったなと思ったので、付け加えさせていただきます。
最後にまとめです。言いたいことは、AKSのアップグレードは怖くないというところですね。AKSがすばらしいから怖くないんです。ただ、提供しているMicrosoftさんの推奨を参考に実践を積み重ねていきましょう。サラッといろいろ言っていますけれども、Kubernetes自体は僕も難しいと思います。CKAとか、CKADとか、CKSを持っていますけど、なにもわからないです（笑）。
ただ、そこから逃げたらもっとおかしくなっていくので、触りましょう、やりましょう。それしかないと思います。こういった運用をブラッシュアップしていくためには実はAKSそのものよりも周辺のobservabilityとか、パイプラインとか、IaCとか、SREとか、プラットフォームエンジニアリングとかの文脈で出てくることを普通にやっておけば普通にAKSアップグレードも改善されていくと思います。という言葉をもちまして、発表を終わらせていただきます。ご清聴ありがとうございました。
（一同拍手）
