AWS運用設計 パッチ運用を考える
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。
オンプレミスで稼働しているシステムを AWS へ移行する or すでに移行した会社は多いと思います。 移行にあたり運用設計を見直すことになりますが、AWS 特有の考え方や AWS サービスを活用するための運用はどのようにシステムに取り込んでいけば良いでしょうか。
今回は、主にエンプラ系システムの運用設計 パッチ運用について考えてみます。
パッチ適用の目的
前提としてパッチを適用する目的は以下です。
- セキュリティホールを塞ぐ
- ソフトウェアのバグを修正する
- ソフトウェアの機能追加をパッチという形式で提供されることもある
パッチ分類
パッチと一言に言っても様々なパッチがあります。 パッチ運用では適用対象ごとに分類していきます。
| 分類 | 説明 |
|---|---|
| ハードウェア | サーバー、スイッチ、ルーターなど機器。分類上はハイパーバイザーも含める。 |
| OS | Windows、Linux など |
| ミドルウェア | RDBMS、アプリケーションサーバー、ジョブ管理、統合監視など |
| アプリケーション | ミドルウェア上で動作するアプリケーション、パッケージソフトウェアなど |
AWS 責任共有モデル
オンプレミスからシステムを移行してくる際に留意しておかなければならないのが AWS の責任共有モデルです。 AWS が運用、管理、および制御する範囲と、システム担当者が行う範囲を理解したうえで 運用設計を行う必要があります。
AWS セキュリティのベストプラクティス を参考にしてご自身が担当する範囲を決めていきます。
インフラストラクチャサービス
このカテゴリには EC2 などのコンピュータサービスと EBS、VPC などの関連サービスが含まれます。
EC2 の場合、パッチ分類の OS、ミドルウェア、アプリケーションは システム担当者がパッチ運用をします。
ハードウェアに分類されるところは AWS の範囲になります。 マネジメントコンソールや API などでメンテナンス情報を定期的に取得しておきます。
再起動が必要なメンテナンスが行われる場合、 メンテナンス予定日までにシステム担当者側で再起動を行うか AWS による自動再起動を待つことになります。
コンテナサービス
このカテゴリはシステム担当者が OS やミドルウェアを管理しないサービスが含まれます。
RDS の場合、パッチ分類のアプリケーション(DB にアクセスするアプリケーション)は システム担当者がパッチ運用をします。
ハードウェア、OS、ミドルウェア(RDMBS)に分類されるところは AWS の範囲になります。 マネジメントコンソールや API などでメンテナンス情報を定期的に取得しておきます。
メンテナンスにはインスタンス停止が発生する場合があります。 この影響を最小に留めるには、RDS をマルチ AZ で構成しておきます。
抽象化サービス
このカテゴリには高レベルのストレージ、データベース、メッセージングサービスが含まれます。 S3、DynamoDB、SQS、SES などです。
このカテゴリのサービスの場合、パッチ分類のアプリケーション(サービスにアクセスするアプリケーション)は システム担当者がパッチ運用をします。
ハードウェア、OS、ミドルウェア(RDMBS)に分類されるところは AWS の範囲になります。 パッチによるサービス停止は意識する必要はありません。
パッチ適用ポリシー
適用ポリシーを決めます。 正解はありません。ご自身が管理しているシステムの特性に合わせてポリシーを決定します。 システム全体のポリシーとせずに、サブシステム単位・サーバー単位でのポリシー決めをお勧めします。
| ポリシー例 | 説明 | パッチ対象 |
|---|---|---|
| 定期実行 | 月にメンテナンス時間帯を定めて最新パッチを適用 | OS、ミドルウェア |
| 臨時実行 | 影響の大きいパッチ、直ちにシステム停止を引き起こすような事象を解決するパッチはメンテナンス日を待たずに適用 | OS、ミドルウェア、アプリケーション |
| 非定期実行 | ワークアラウンドがあるバグ、機能追加型パッチなど影響が小さいパッチはメンテナンス時間帯に適用。当月にパッチがリリースされていなければスキップ。 | ミドルウェア、アプリケーション |
| 塩漬け運用 | 本番運用開始後はパッチ適用をしない。セキュリティは他の手段で担保。 | OS、ミドルウェア、アプリケーション |
パッチ適用フロー
パッチ適用フローは以下です。
- 適用するパッチと適用対象、手順の確認
- 検証環境でのパッチ適用と動作確認
- 本番環境へのパッチ適用を計画 (1. をさらに精緻化)
- 本番環境へのパッチ適用
このフローを実行するためのドキュメントを用意しておきます。
- パッチ概要説明書
- パッチ適用手順
- 適用後正常性確認手順
- ロールバック手順
AWS サービスを利用した効率化
AWS 上でシステムを稼働するのであれば AWS サービスを使って一連の作業を効率化します。
スナップショット
パッチ適用が失敗した際のロールバックに備えて 作業前にスナップショットを取得します。 スナップショット取得にかかる時間は、システム停止起動時間を除けばほとんどの場合数秒です。
Systems Manager
Systems Manager をフル活用して EC2 インスタンスへのパッチ適用を自動化します。 以下の機能は活用して自動化を実現します。
- パッチグループによる適用対象のグループ化 (Patch Manager)
- 承認されたパッチと拒否されたパッチをリストし適用対象をコントロール (Patch Manager)
- パッチ適用、インストール (Patch Manager)
- パッチ適用のスケジュール (Maintenance Windows)
- パッチコンプライアンス状態の表示 (Patch Manager)
- スナップショット取得～パッチ適用～適用後の状態レポート の一連タスクを自動化 (Automation)
まとめ
エンプラ系システムのパッチ運用について考える機会がありましたので記事にしました。 最新パッチを常に適用しておきたいけれども、パッチ運用に関連する手間/工数は少なくありません。 マイクロサービス化し自社の範囲 (責任共有モデルでいうところ) を限定すれば パッチ運用は回しやすくなると思います。
ただ、パッケージソフトウェアを採用しているエンプラ系システムでは やはり EC2 が基本になると思います。 AWS サービスを活用して「パッチを当てやすいシステム」を考えていかなければなりません。
参考
AWS セキュリティのベストプラクティス Amazon EC2 のメンテナンスのヘルプページ DB インスタンスのメンテナンス AWS Systems Manager Patch Manager
以上、吉井 亮 がお届けしました。
