OPS05-BP03 構成管理システムを使用する
設定を変更し、変更を追跡記録するには、構成管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
静的な構成管理では、ライフタイムを通じて一貫性を維持することが期待されるリソースの初期化時に値を設定します。このケースの例として、インスタンス上のアプリケーションサーバーまたはウェブサーバー用を設定する場合や、
AWS マネジメントコンソール 内または
AWS CLI
動的な構成管理では、ライフタイムを通じて変化する、または変化することが予測されるリソースの初期化時に値を設定します。例えば、構成変更を介してコードの機能を有効にするように機能トグルを設定したり、インシデント発生時にログの詳細レベルを変更してより多くのデータを取得し、インシデント終了時に詳細レベルを元に戻して不要なログや負荷を減らしたりすることができます。
AWS では、 AWS Config を使用して アカウント間とリージョン全体にわたる AWS リソースの設定を 継続的にモニタリングできます。これは、設定履歴を追跡し、設定変更がほかのリソースに与える影響を理解して、 AWS Config ルール と AWS Config コンフォーマンスパックを使用した期待される、または望まれる設定との比較監査を行えます。
Amazon EC2 インスタンス、AWS Lambda、コンテナ、モバイルアプリケーション、または IoT デバイスで実行されているアプリケーションで動的設定が使用されている場合、 AWS AppConfig を使用して環境全体にわたり、設定、検証、デプロイ、モニタリングできます。
AWS では、
AWS デベロッパーツールなどのサービスを使用して、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを構築できます
期待される成果: 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの一部として設定、検証、デプロイを行います。モニタリングして、設定が正しいことを確認します。これにより、エンドユーザーや顧客への影響を最小限に抑えることができます。
一般的なアンチパターン:
-
あなたがフリート全体でウェブサーバー設定を手動で更新したところ、更新エラーのために多数のサーバーが応答しなくなりました。
-
あなたは、何時間もかけて、アプリケーションサーバーフリートを手動で更新します。変更中の設定の不整合が、予期しない動作を引き起こします。
-
誰かがセキュリティグループを更新したため、ウェブサーバーにアクセスできなくなりました。変更内容を把握しなければ、問題の調査にかなりの時間を費やすことになり、復旧までより長くの時間を要することになります。
-
検証をせずに CI/CD を使用して本番稼働前の設定を本番環境にプッシュします。ユーザーと顧客に正確でないデータやサービスを提供してしまいます。
このベストプラクティスを活用するメリット: 構成管理システムを採用することで、変更やその追跡の労力のレベルと、手動の手順に起因するエラーの頻度を軽減できます。構成管理システムを使用すると、ガバナンス、コンプライアンス、規制要件に関して保証が得られます。
このベストプラクティスを活用しない場合のリスクレベル: 中程度
実装のガイダンス
構成管理システムは、アプリケーションと環境の設定変更を追跡して実装するために使用されます。構成管理システムは、手動プロセスを原因として発生するエラーを低減し、設定の変更を繰り返し可能かつ監査可能にして、労力を軽減するためにも使用されます。
実装手順
-
設定担当者を特定します。
-
コンプライアンス、ガバナンス、または規制上のニーズを設定担当者に伝えます。
-
-
設定項目と成果物を特定します。
-
設定項目とは、CI/CD パイプライン内のデプロイにより影響を受けるすべてのアプリケーション設定と環境設定です。
-
成果物には、達成基準、検証、モニタリング対象などがあります。
-
-
ビジネス要件とデリバリーパイプラインに基づいて、構成管理ツールを選択します。
-
誤った構成による影響を最小限に抑えるために、構成を大幅に変更する場合は、canary デプロイなどの加重デプロイを検討します。
-
構成管理を CI/CD パイプラインに統合します。
-
プッシュされたすべての変更を検証します。
リソース
関連するベストプラクティス:
関連するドキュメント:
関連動画:
