皆さん、パッチ適用していますか？
本番環境リソースへのパッチ適用では、サービスへの影響が出ないように、細心の注意が必要とされます。
冗長化されたアーキテクチャであれば、一時的にシステムを片系に切り替え、縮退しつつもサービスは継続し提供しながら、パッチ適用を実行するといった方法も取れ、広く採用されてきた方法の一つではないかと思います。
だいぶ要点のみにフォーカスしていますが、下図のような AWS でよく取られる ELB 配下に EC2 を複数台配置することで冗長化されたアーキテクチャにおいても ELB より EC2 を切り離した上で、パッチ適用を実施し、完了後に再度 ELB へ登録するといった方法を取ることで、冒頭に記載した方法と同様のパッチ適用が実現出来ます。
今まで確立された方法を採用し続けることも悪くはないのですが、クラウドの特性（今回ではプログラマブルにリソースを管理出来るため、より広範囲に運用作用が自動化出来る）をより活用して、最適化されたクラウド運用へシフトすることで、よりクラウドを利用しているメリットを得ることが出来ます。
このベストプラクティスを活用するメリット:
パッチ適用の基準や環境全体への配布方法など、パッチ管理プロセスを確立することで、それらの利点を実現し、影響を制御することができます。これにより、必要な機能と能力の導入、問題の除去、ガバナンスの継続的な遵守が可能になります。パッチ管理システムと自動化を実装して、パッチをデプロイする労力を軽減し、手動プロセスに起因するエラーの発生を抑制します。
引用元： 運用上の優秀性の柱 AWS Well-Architected Framework - OPS05-BP05 パッチ管理を実行する
いつもながら、前置きが長くなってしまいましたが、今回はパッチ適用を実施する際に、「ELB から切り離す」, 「 EC2 へパッチ適用する」, 「ELB へ再登録する」 の３つを自動実行する SSM Patch Manager 向けドキュメントをご紹介します。
このドキュメントではターゲットとなる EC2 が登録された ELB を検索し、登録解除（切り離し）を実行した上でパッチ適用を行い、再度 ELB への登録を実行します。素晴らしいことに draining の時間まで指定出来ます。
The automation workflow is as follows:
1. The load balancer or target group to which the instance is attached is determined, and the instance is verified as healthy.
2. The instance is removed from the load balancer or target group.
3. The automation waits for the period of time specified for the connection draining time.
4. The AWS-RunPatchBaseline automation is called to patch the instance.
5. The instance is reattached to the load balancer or target group.↓↓↓ 機械翻訳 ↓↓↓
1. インスタンスがアタッチされているロードバランサーまたはターゲットグループが決定され、インスタンスが健全であることが検証されます。
2. インスタンスはロードバランサまたはターゲットグループから削除されます。
3. オートメーションはコネクションの消耗時間に指定された期間待機します。
4. AWS-RunPatchBaseline オートメーションがインスタンスにパッチを適用するために呼び出される。
5. インスタンスがロードバランサーまたはターゲットグループに再接続される。引用元: AWS Systems Manager Automation runbook reference User Guide - AWSEC2-PatchLoadBalancerInstance
シナリオ
- ALB 配下に Web サービスがインストールされた EC2 を複数台配置し、冗長化してサービスを提供
- 一つの EC2 がパッチ適用の対象
- ALB から対象 EC2 を切り離し、SSM Patch Manager からパッチ適用を実施
- 簡易的なサービス影響確認のために CloudWatch Synthetics から1分単位でモニタリング
番外編
今回のアーキテクチャに対して SSM Patch Manager のベーシックなドキュメント AWS-RunPatchBaseline を気ままに実行してみます。
対象インスタンスへパッチ適用を実行されました（10:52 - 10:55）
パッチ適用中に再起動が実行されています（02:02 時点で７分間起動している。つまり7分前に起動している。日本時間に変換すると 10:55 頃）
[root@ip-10-0-4-113 ~]# date
Tue Jun 27 02:02:32 UTC 2023
[root@ip-10-0-4-113 ~]# uptime
02:02:35 up 7 min, 0 users, load average: 0.00, 0.03, 0.01
[root@ip-10-0-4-113 ~]#CloudWatch Synthetics でも、当該時間帯に 失敗 が記録されています。
必ずしもこのケースになるとは限りませんが適切な前処理を実施せずにパッチ適用を実行すると OS 再起動が実行されるケースなどにおいては、サービスへの影響が発生するリスクが内在します。
パッチ適用
では、同じ要領で AWSEC2-PatchLoadBalancerInstance を実行してみます。
AWS Systems Manager ＞＞＞ ドキュメント ＞＞＞ AWSEC2-PatchLoadBalancerInstance ＞＞＞ オートメーションを実行する
今回、片側のみパッチ適用を実行したいので、専用タグを付与して対象を指定します。また draining を考慮して実行前に待機する時間を指定します。
あとは実行します。
はじめに、今回のドキュメントの肝となるこちらの前処理を実行していきます。
- The load balancer or target group to which the instance is attached is determined, and the instance is verified as healthy.
- The instance is removed from the load balancer or target group.
- The automation waits for the period of time specified for the connection draining time.
CloudFormation を利用して Lambda が作成されています。
作成された Lambda により前処理（EC2 から ELB 情報を取得）が実行されます。
ELB から EC2 の登録解除を実行されていますね。
パッチ適用が実行されています。（ 00:17 台は最初の環境構築時にインストールした Web サービスの履歴）
[root@ip-10-0-0-125 ~]# cat /var/log/yum.log
Jun 27 00:17:20 Installed: apr-1.7.2-1.amzn2.x86_64
Jun 27 00:17:21 Installed: apr-util-1.6.3-1.amzn2.0.1.x86_64
Jun 27 00:17:21 Installed: apr-util-bdb-1.6.3-1.amzn2.0.1.x86_64
Jun 27 00:17:21 Installed: httpd-tools-2.4.57-1.amzn2.x86_64
Jun 27 00:17:21 Installed: httpd-filesystem-2.4.57-1.amzn2.noarch
Jun 27 00:17:21 Installed: generic-logos-httpd-18.0.0-4.amzn2.noarch
Jun 27 00:17:21 Installed: mailcap-2.1.41-2.amzn2.noarch
Jun 27 00:17:21 Installed: mod_http2-1.15.19-1.amzn2.0.1.x86_64
Jun 27 00:17:21 Installed: httpd-2.4.57-1.amzn2.x86_64
Jun 27 02:29:25 Updated: nspr-4.34.0-3.1.amzn2.x86_64
Jun 27 02:29:25 Updated: nss-util-3.79.0-1.amzn2.x86_64
Jun 27 02:29:25 Updated: expat-2.1.0-15.amzn2.0.2.x86_64
Jun 27 02:29:25 Updated: systemd-libs-219-78.amzn2.0.22.x86_64
Jun 27 02:29:25 Updated: sqlite-3.7.17-8.amzn2.1.2.x86_64ELB へ EC2 が再登録されました。
ターゲットグループのメトリクスからも数が遷移しているのが確認できます。
一連のパッチ適用が無事に終了しました。
CloudWatch Synthetics を確認すると、番外編のように実行時間帯（11:20-11:35）に 失敗 の記録はありません。
ELB 配下にある EC2 に対して、サービスへ影響を出さないために、ELB から切り離しからパッチ適用までを自動実行することが出来ました！（便利..
さいごに
良さそうだけど、今回のドキュメント内で実行されているパッチ適用部分について、他のパッチ適用ドキュメントや設定したいパラメーターがあるというケースでは、ドキュメントをクローンしてカスタマイズするか、ドキュメント内容を参考に既存ドキュメントを更新する等で、自社システムに適した内容に変更することも可能ではないかと思います。
4
