こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
第47回目では『Kubernetesマイクロサービス開発の実践』を取り上げます。
コンテナ、Kubernetesおよびそれに関連する技術を活用して、アプリケーションの開発と運用を行う方法について解説している本書をテーマに、Kubernetesおよびクラウドネイティブ技術を効果的に活用して実装、運用する方法を学んでいきましょう。
今回は著者の早川 博 氏、監修の北山 晋吾 氏のお二人をお招きし、Kubernetes上で動作するアプリケーションに対して、頻繁な更新とサービスの安定性を同時に実現するための様々なプラクティスをお話しいただきます。 また、モデレータに株式会社サイバーエージェントの青山 真也 氏をお迎えし、さらにDeepなところまで深掘りしていただきます。
会の様子
基調講演1〜マイクロサービスは本当に必要だったのか？〜
K8sの成熟度
2018年にK8s完全ガイドが出たことに加え、SRE/Platform Engineeringをはじめとした運用の役割定義分割が発生していることから、K8sはキャズムに入ってきたのではないかな？という感覚で北山さんはいるということでした。
アプリモダナイズへの投資状況
現在は既存アプリケーションをどのようにコンテナ化するのか？という部分に関心が移りつつある*1ということでした。細分化すると、
- Repurchase(完全に置き換えしたい場合に取る方法)
- Refactor(アプリケーションを分割してまでビジネスが伸びる見込みがある場合に取る方法)
- Replatform(移行費用や工数を抑えながら保守性のあるシステムを作るが、システムが古いと改善箇所が増えてしまう方法)
- Rehost(移行費用や工数はかかるが保守性を最適化したサービスができる)
に分かれるそうです。
移行影響としては、Rehost、Replatform、Refactorの順に高く、コストを抑えながら保守性を高められるReplatformがトレンドの一つになっているということでした。(=マイクロサービスへのリファクタリングというのは実はほとんど行われていない)
基調講演2〜Kubernetesで、アプリの安定稼働と高頻度のアップデートを両立するためのプラクティス〜
近年のアプリケーションに求められるもの
アプリケーションは頻繁なアップデートを理由に様々な理由で再起動されるため、頻繁に再起動があっても安定して稼働し続けることが求められているという話がイントロダクションとしてありました。
具体的には、
- 十分な準備
- 意図しないクラッシュの予防
- GracefulなPodの終了
という3観点に分かれるということでした。
十分な準備
Pod内のコンテナはReadyになるまでにリクエストを受け付けるための準備が必要であるため、アプリケーションごとに対応の必要があるということでした。(DBとのコネクション確立、初期ヒープメモリの確保、キャッシュを読み込む、暖機運転を利用したコンパイラ最適化...)
具体的なプラクティスとしては、initCotainersやPodStart lifecycle hookなどが利用できるということです。
意図しないクラッシュの予防
コンテナの停止をはじめクラッシュの原因も様々ありますが、
といった内容が必要だということでした。
GracefulなPodの終了
Podが終了する際は、コンテナの終了&トラフィックの停止が起こる上に動作には決まった順序がないため、preStop lifecycle hookによる待機を活用したり、Gracefulシャットダウンの無効化を設定しておくことなどが重要だという話がありました。
Q&A
基調講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
Rehostを選択して運用が大変になった事例はあるか？
大体大変になる印象はある。IPアドレス周りやログ、セッションレプリケーションなどのトラブルが多い印象はある。
マイクロサービス化はどこまで必要か？
- アプリケーションの更新頻度を基準に考えると思う
- 保守性を基準に考える。なお、保守性はチームの技術力にも依存するので、もしK8sを触ったことがないチームなら大きいままでも放っておいた方がいいかもしれない
トラフィックの停止を待つのにsleepコマンドで待っていたが、ネットワークなどを監視してトラフィックがなくなったことを認識してから終了することはできるのか？
アプリケーションのメトリクスをPrometheusのエクスポート的な形で出しておいて、SIGTERMが来たら処理待ちするみたいな連動の仕方になると思われる。ただし、sleepで我慢するほうが結果的に楽になる気がする。
ヘルスチェックを導入している時、DBとの接続チェックは行うべきか？通常通り動作するロジックは提供し続けることはできるのか？
しない方がいいと思っている。アプリケーションが停止したからといってDBが復旧するかはわからないのであまり意味がない気はしている。そのため、DBの状態とアプリケーションの状態は連動しないほうがいいと思う。後半部分はサーキットブレイカーが近いのではないかと思っている。
暖機運転は本当にいるのか？
商用環境でK8sはどのくらいの頻度でupdateするのか？アップデート対応を効率的にやる方法はあるか？
- アプリケーション側のE2Eテストを作って段階的なバージョンアップをしていくと早くupdateできるようになるはず
- 基本は3ヶ月に1回
会全体を通した感想
業界のトレンド的な話や一般的な話を北山さんがしてくれて、実際の業務で使えるプラクティスの話を早川さんがしてくれたので、流れが見事にできていて良いイベントでした。
RefactorよりRehostというトレンドは体感と一致していましたが、正式なリサーチ結果として出ているのは知らなかったので、レポートを読んでみようと思いました。
*1:Research conducted by lliminas参照
