SAP-C02-107 · セクション 12 / タスク 3.1

Configuration Managementを自動化する

AWS Systems Manager / State Manager / Automation / 構成ドリフト / 望ましい状態 / 構成管理

既存環境では、構成管理の仕組みが存在していても、担当者がサーバーへログインして手順書を見ながら設定変更し、一部で実行漏れが起き、時間とともに設定差が拡大することがあります。

改善で目指すのは、単にスクリプトを増やすことではありません。

正しい状態を定義
↓
承認された定義から変更
↓
自動適用
↓
結果を確認
↓
ずれがあれば再び正しい状態へ近づける

という構成管理の運用サイクルへ変えることです。

ゴール

既存環境について、現在の設定変更方法、望ましい状態、意図した差分、意図しない構成ドリフト、自動適用、結果確認を整理し、AWS Systems Managerを利用して手作業中心の構成管理を改善できる状態を目指します。

1. まず「現在どの設定が正しいのか」を明確にする

自動化の前に最も重要なのは、何を自動実行するかではなく、何が正しい状態かを決めることです。

サーバーA
log_level = INFO

サーバーB
log_level = DEBUG

サーバーC
log_level = INFO

となっていても、単純に多数派のINFOを正しい状態と決めることはできません。

DEBUGが一時的な障害調査、環境固有要件、変更漏れ、過去設定の残存のどれなのかを確認します。

現在状態
↓
意図した差
↓
意図しない差
↓
維持すべき望ましい状態

2. 稼働中のサーバーを「正本」にしない

既存環境では、正しい設定のサーバーを探して設定ファイルをコピーし、別サーバーへ反映する運用が残っていることがあります。

この方式では、そのサーバー自体が本当に正しいか、誰がいつ変更したか、前の設定へ戻せるかが不明確になります。

承認済みの設定定義
= 正本

稼働サーバー
= その定義を適用する対象

設定定義自体を変更管理とバージョン管理の対象にすれば、変更前、変更内容、レビュー、承認、適用という流れを作れます。

3. 望ましい状態は「全サーバーを同じ値にする」ことではない

望ましい状態は、全対象が完全に同じ設定という意味ではありません。

項目	開発	本番
log_level	DEBUG	INFO
worker_count	2	12
monitoring	有効	有効

環境ごとの違い自体が意図された状態の場合があります。重要なのは、共通部分と明示された環境差として管理することです。

意図した差
≠
構成ドリフト

4. 構成ドリフトは「期待していない差」

既存環境で問題になるのは、望ましい状態から手動変更などによって実際の状態が意図せずずれていくことです。

望ましい状態
監視エージェント = 導入済み / 稼働中

実際
サーバーA = 稼働中
サーバーB = 停止
サーバーC = パッケージ未導入

同じ役割のフリートで期待した状態を維持できていません。構成ドリフトへの対応では、差を発見するだけではなく、望ましい状態へ戻せる仕組みを検討します。

5. State Managerは「望ましい状態を維持する手段」として使う

State Managerの関連付け・対象指定・率制御などの基本は既習です。

ここでは、手作業で同じ設定を繰り返し修正している運用から、維持すべき望ましい状態を定義し、State Managerから継続的に適用する運用へ改善するために利用します。

重要なのはState Managerの機能そのものではなく、「担当者が毎回直す」状態から「管理された定義を基準に状態を維持する」運用へ変えることです。

6. 状態維持と手順実行を分ける

State ManagerとAutomationの基本的な役割は既習です。

繰り返し維持する状態
→ State Manager

移行・例外対応などの複数ステップ処理
→ Automation

例えば、一度限りのエージェント移行にはAutomationを利用できます。移行後は「正しいエージェントと設定が維持されていること」を望ましい状態として管理します。

手順を繰り返し実行することと、結果として必要な状態を維持することを混同しません。

7. 自動化する前に現在の差分を整理する

構成差が多い環境で、いきなり自動適用すると危険です。

500台
↓
現在設定が3種類
↓
理由不明
↓
一番多い設定を500台へ強制

としてしまうと、必要な環境差まで消す可能性があります。

1. 現在状態を収集
2. 意図した差を分類
3. 正しい基準を確定
4. 小さな対象で適用
5. 結果確認
6. 対象を拡大

既習の対象指定や率制御は、この段階的な移行で利用できます。

8. 構成変更も変更管理へ載せる

自動化後でも、担当者が本番へSSHして直接設定ファイルを変更することを通常経路として残すと、再び構成差が発生します。

設定変更要求
↓
設定定義を変更
↓
レビュー / 承認
↓
State Manager等から適用
↓
結果確認

構成管理を自動化することは、手作業を高速化することではなく、承認された変更経路を再現可能にすることです。

9. State Managerの「スケジュール」だけを見ない

State Manager関連付けを毎週日曜日に設定していても、日曜日にしか絶対に実行されないとは限りません。

現在のState Managerでは、既定では関連付けを更新した場合にも実行されます。

水曜日
関連付けを変更
↓
即時実行

変更を必ず次の日曜日だけに適用したい場合は、ApplyOnlyAtCronIntervalを利用して次のcron実行まで待たせることを検討します。

ApplyOnlyAtCronIntervalはrate式には使用できない点にも注意します。

構成管理を自動化すると、設定定義の変更が本番への変更へ直結しやすくなるため、実行タイミング自体も変更管理の一部になります。

10. 静的設定と動的設定を分ける

静的な設定

監視エージェントを導入する、特定サービスを有効化する、共通セキュリティ設定を維持するといった、長期間同じ状態を維持する設定です。

動的な設定

ログ詳細レベル、機能フラグ、運用時に変更するアプリケーション設定など、稼働中に変化することを前提とする設定です。

AWS Well-Architectedでは、動的なアプリケーション設定をアプリケーションコードやインフラストラクチャコードから独立して管理する考え方を推奨しています。

アプリケーション更新
≠
設定変更

インフラ更新
≠
設定変更

設定だけを変更するためにアプリケーション全体を再構築する必要を減らせます。

11. CloudFormationのドリフトとノード構成のずれを混同しない

既習のCloudFormationでは、テンプレートからAWSリソースの期待状態を定義し、実リソースとの差を扱います。

一方、Amazon EC2上の設定ファイル、サービス状態、インストール済みソフトウェアは別の管理層です。

セキュリティグループのCloudFormation管理プロパティと、EC2内部の監視エージェント設定を同じドリフト管理方式で扱うとは限りません。

インフラストラクチャ定義
↓
IaCの管理層

ノード構成
↓
構成管理の管理層

12. 一時的な変更と正式変更を分ける

障害対応では、ログレベルを一時的にDEBUGへ変更するような例外操作が必要になる場合があります。

障害対応
↓
一時変更
↓
調査完了
↓
通常の望ましい状態へ戻す

正式な変更として採用する場合は、設定定義側を更新し、承認を経て、管理された経路から適用します。

実際のサーバー設定をそのまま正本に昇格させません。

13. 適用結果を改善サイクルへ戻す

構成管理を自動化した後は、対象へ期待どおり適用できたか、失敗している対象がないか、意図しない設定差が減ったか、手作業や適用漏れが減ったかを確認します。

重要なのは、自動化処理が実行されたことを構成管理の改善完了と考えないことです。

実際の運用結果を確認し、望ましい状態の定義、適用方法、対象範囲、例外として扱う設定を必要に応じて見直します。

14. 代表的なアンチパターン

アンチパターン	問題
稼働中の1台を正本にする	その設定自体が正しい保証がない
理由不明の差分をすべてドリフト扱い	必要な環境差まで消す
定常状態を毎回Automationで作り直す	手順実行と状態維持を混同する
State Managerを設定全体のリアルタイム監視と考える	関連付けの責任を過大評価する
設定定義を変更管理しない	自動化によって誤設定も高速に展開される
全本番へ最初から適用する	誤った望ましい状態の影響が一気に広がる
本番だけ直接修正する経路を通常運用に残す	再び構成差が発生する
設定変更のため毎回アプリケーションを再構築する	設定とアプリケーションのライフサイクルが過度に結合する

15. SAP-C02判断フロー

既存環境で設定変更が手作業、同一役割なのに設定差、実行漏れ、同じ設定不良の再発、新規ノードへの設定漏れが見えたら、次の順番で考えます。

現在の正しい状態は明確？
↓
NO
→ 意図した差 / 意図しない差を整理

YES
↓
望ましい状態を定義
↓
設定定義は変更管理されている？

NO
→ バージョン管理・承認経路を作る

YES
↓
繰り返し維持する状態？

YES
→ State Managerを中心に検討

複数手順の移行・例外処理？

YES
→ Automationを利用
↓
小さな範囲で適用
↓
結果確認
↓
対象を拡大
↓
構成ドリフトと手作業を継続的に削減

判断の目安

担当者が毎回同じ設定変更
→ 望ましい状態として自動管理

環境ごとに必要な設定差
→ 差分を明示して維持

理由不明の設定差
→ 自動適用前に分類

複数ステップの移行
→ Automation

移行後の定常状態
→ State Manager

関連付け変更を
次のcronまで実行したくない
→ ApplyOnlyAtCronIntervalを検討

AWSリソース定義の差
→ IaC側の管理

OS / アプリケーション設定の差
→ 構成管理側の管理

まとめ

構成管理の自動化では、手作業をスクリプト化することだけを目標にしません。

望ましい状態を明確化
↓
設定定義を管理
↓
意図した差分を明示
↓
自動適用
↓
適用結果を確認
↓
構成ドリフトを減らす

AWS Systems Manager State Managerは、望ましい状態を維持する中心的な候補です。Automationは、移行や例外対応などの複数ステップ処理へ利用できます。

状態を維持する処理と手順を実行する処理を分け、既存環境の手作業と設定差を減らします。