IaC・開発運用ツールのシナリオ判断

検証環境を再現する、資源を更新する、リリースを自動化する、遅い要求を調べるという場面で、使う情報とサービスを選びます。テンプレートや変更セットの成功をデータの復旧や業務の成功と取り違えない練習です。

この単元で学ぶこと

IaCの再利用と環境差の確認を具体例へ適用する
変更・ドリフト・データ保護の境界を判断する
ビルド・リリース・要求追跡を使い分ける

本文解説

1. 同じ構成をもう一つ作る開発チームが検証環境を追加する場合、CloudFormationのテンプレートを再利用し、スタックを別に作る方法を考えます。環境名や容量等をパラメーターにすると差を明示できます。既存の名前をそのまま複製できるとは限らず、サービスの対応、クォータ、権限を確認します。コピーしたファイル数ではなく、必要な構成を再現できるかを評価します。

2. 変更前に影響を読む本番DBの属性変更が置換を伴う案なら、変更セットで対象を把握します。置換を示す行を見て、データを移す方法、停止の許容、復旧点を確認します。変更セットの作成は実行の前の確認です。事前検証を通っていても、実行時のサービス状態や独自処理による失敗の可能性は残ります。

3. 手動変更への対応障害対応で管理者が資源設定を手動変更した後、テンプレートと実設定がずれる場合があります。ドリフト検出で対応する範囲を調べ、変更が必要だったのかを確認します。原因を調べず期待値へ戻すと障害を再発させる場合もあるため、定義を直すか実設定を直すかを判断します。検出成功を修正完了という意味にはしません。

4. 定義の履歴とデータの履歴 Gitに保存したテンプレートから昨日の構成を確認できても、昨日の注文データまでは含まれません。定義の履歴はレビューと再現に使い、業務データの履歴はバックアップ等で保護します。例えば空のDBとWebサーバーが再作成できた段階と、必要な注文を読み出せて業務を再開できる段階は別です。

5. ビルドの実行を読むソース変更後にコンパイルしてテストを実行する作業はCodeBuildで扱えます。成功ログがある場合も、何のテストをどの条件で実行したかを確認します。テスト未定義、対象の漏れ、接続先の間違いがあれば、緑の結果だけで本番の業務動作を保証できません。成果物が意図した版かも確認します。

6. 段階を順につなぐ CodePipelineはソース取得、ビルド、テスト、配備等を段階としてつなぎます。CodeBuildやCloudFormation等を使うアクションを組み合わせ、必要なら承認を挟みます。ビルドが成功しても、後段の配備が失敗したらリリース全体は完了していません。どの版がどの環境へ進んだか、停止時に何を戻すかを確認します。

7. 利用中の遅延を追う公開後にAPI応答が遅いと分かったとき、X-Rayのトレースでサービス間の処理と遅延を調べます。リリースの実行履歴だけでは、どの下流呼出しが遅かったかを直接説明できません。計測されていない経路や収集条件にも注意します。遅延箇所の発見とコードや容量の修正は、別の作業として進めます。

8. 自動化の境界を確認する IaCは構成作成、ビルドは成果物作成、パイプラインはリリースの手順、トレースは実行の観測という境界があります。自動化しても、不適切な権限や消えるデータ、未定義の業務テストを自動で正しく推測するわけではありません。必要な設定と確認を具体化することで、反復作業の負担を減らしながら変更を管理できます。

図解

成功を段階ごとに確認する — 前の段階の成功だけで、後の段階の完了を判断しません。

重要ポイント

変更案の確認と適用の完了を区別する。
テンプレート履歴は注文データの履歴ではない。
ビルド成功、配備成功、実行中の正常性は別に確認する。

間違えやすい点

ドリフトを見つけたら原因に関係なく即座に戻す。
トレースがない経路は利用されていないと断定する。

用語解説

成果物: ビルド等で作り、配備に使うプログラムやパッケージ等。
変更セット: スタックへ提案した変更の影響を実行前に確認するもの。
リリース手順: ソースの取得からテスト・配備等を通じて変更を利用環境へ届ける流れ。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。