SEC11-BP06 ソフトウェアをプログラムでデプロイする - AWS Well-Architected フレームワーク
実装のガイダンスリソース

SEC11-BP06 ソフトウェアをプログラムでデプロイする

可能な場合は、ソフトウェアのデプロイをプログラムで行います。この手法により、デプロイに失敗したり、人為的エラーにより予期しない問題が発生したりする可能性を低減できます。

期待される成果: テストするワークロードのバージョンはデプロイするバージョンであり、デプロイは毎回一貫して実行されます。ワークロードの設定を外部化して、変更なしでさまざまな環境にデプロイできるようになります。環境間に何も変更がないことを確認するために、ソフトウェアパッケージの暗号化署名を使用します。

一般的なアンチパターン:

  • 本番環境にソフトウェアを手動でデプロイする。

  • 環境に合わせて手動でソフトウェアに変更を加える。

このベストプラクティスを活用するメリット:

  • ソフトウェアリリースプロセスの信頼性が向上します。

  • 変更に失敗してビジネスの機能性に影響を与えるリスクが低減されます。

  • 変更リスクの低減により、リリース頻度が向上します。

  • デプロイ中に予期しないイベントが発生した場合に自動ロールバックが機能します。

  • テスト済みのソフトウェアとデプロイされたソフトウェアが同じであることを、暗号化によって証明できます。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

堅牢で信頼性の高いアプリケーションインフラストラクチャを維持するには、安全で自動化されたデプロイプラクティスを実装します。このプラクティスでは、本番環境から永続的な人間のアクセスを削除し、デプロイに CI/CD ツールを使用し、環境固有の設定データを外部化します。このアプローチに従うことによって、セキュリティを強化し、ヒューマンエラーのリスクを減らし、デプロイプロセスを合理化できます。

AWS アカウント 構造を構築し、本番環境から永続的な人的アクセスを削除できます。このプラクティスは、不正な変更や偶発的な変更のリスクを最小限に抑え、本番稼働システムの整合性を向上させます。直接ヒューマンアクセスの代わりに、AWS CodeBuild や AWS CodePipeline などの CI/CD ツールを使用してデプロイを実行できます。これらのサービスを使用して、構築、テスト、デプロイのプロセスを自動化できるため、手動の介入が減り、一貫性が向上します。

セキュリティとトレーサビリティをさらに強化するために、アプリケーションパッケージがテストされ、デプロイ中にこれらの署名を検証した後に、アプリケーションパッケージに署名できます。それには、AWS Signer や AWS Key Management Service (AWS KMS) などの暗号化ツールを使用します。パッケージに署名して検証することによって、認可および検証されたコードのみを環境にデプロイできます。

さらに、チームはワークロードを設計して、AWSSystems Manager Parameter Store などの外部ソースから環境固有の設定データを取得できます。この方法により、アプリケーションコードが構成データから分離されるため、アプリケーションコード自体を変更することなく、構成を個別に管理および更新できるようになります。

インフラストラクチャのプロビジョニングと管理を合理化するには、AWS CloudFormation や AWS CDK などの Infrastructure as Code (IaC) ツールを使用することを検討してください。これらのツールを使用して Infrastructure as Code (IaC) を定義できるため、さまざまな環境にわたるデプロイの一貫性と再現性が向上します。

ソフトウェアのデプロイが成功したことを検証するには、カナリアデプロイを検討します。カナリアデプロイでは、本番環境全体にデプロイする前に、インスタンスまたはユーザーのサブセットに変更をロールアウトします。その後、変更の影響をモニタリングし、必要に応じてロールバックできるため、広範な問題のリスクを最小限に抑えることができます。

「Organizing Your AWS Environment Using Multiple Accounts」ホワイトペーパーで概説されている推奨事項に従ってください。このホワイトペーパーでは、セキュリティと分離をさらに強化するため、環境 (開発、ステージング、本番など) を個別の AWS アカウント に分離する方法について説明します。

実装手順

  1. AWS アカウント 構造のセットアップ:

    • 「Organizing Your AWS Environment Using Multiple Accounts」ホワイトペーパーのガイダンスに従って、異なる環境 (試験、開発、ステージング、本番稼働) 用に個別の AWS アカウント を作成します。

    • 各アカウントの適切なアクセスコントロールとアクセス許可を設定して、本番環境への直接アクセスを制限します。

  2. CI/CD パイプラインの実装:

    • AWS CodeBuild や AWS CodePipeline などのサービスを使用して CI/CD パイプラインを設定します。

    • アプリケーションコードを自動的に構築、テスト、各環境にデプロイするようにパイプラインを設定します。

    • コードリポジトリを CI/CD パイプラインと統合して、バージョン管理とコード管理を行います。

  3. アプリケーションパッケージに署名して検証します。

    • AWS Signer または AWS Key Management Service (AWS KMS) を使用して、テストと検証後にアプリケーションパッケージに署名します。

    • ターゲット環境にデプロイする前に、アプリケーションパッケージの署名を検証するようにデプロイプロセスを設定します。

  4. 設定データの外部化:

  5. Infrastructure as Code (IaC) の実装:

    • AWS CloudFormation または AWS CDK などの IaC ツールを使用して、Infrastructure as Code (IaC) を定義および管理します。

    • CloudFormation テンプレートまたは CDK スクリプトを作成して、アプリケーションに必要な AWS リソースをプロビジョニングおよび設定します。

    • IaC を CI/CD パイプラインと統合して、アプリケーションコードの変更と共にインフラストラクチャの変更を自動的にデプロイします。

  6. カナリアデプロイの実装:

    • カナリアデプロイをサポートするようにデプロイメントプロセスを構成します。カナリアデプロイでは、変更がインスタンスまたはユーザーのサブセットにロールアウトされてから、運用環境全体にデプロイされます。

    • AWS CodeDeploy や AWS ECS などのサービスを使用してカナリアデプロイを管理し、変更の影響を監視します。

    • カナリアデプロイ中に問題が検出された場合は、ロールバックメカニズムを実装して以前の安定バージョンに戻します。

  7. モニタリングと監査:

    • デプロイ、アプリケーションのパフォーマンス、インフラストラクチャの変更を追跡するための監視およびログ記録メカニズムを設定します。

    • Amazon CloudWatch や AWS CloudTrail などのサービスを使用して、ログやメトリクスを収集および分析します。

    • 監査とコンプライアンスチェックを実装して、セキュリティのベストプラクティスと規制要件の遵守を検証します。

  8. 継続的な改善:

    • 定期的にデプロイのプラクティスを確認して更新し、以前のデプロイから得たフィードバックと教訓を取り入れます。

    • デプロイプロセスのできるだけ多くを自動化して、手動介入や潜在的なヒューマンエラーを減らします。

    • クロスファンクショナルチーム (オペレーションやセキュリティなど) と協力して、デプロイプラクティスを調整し、継続的に改善します。

これらのステップに従うことによって、安全で自動化されたデプロイプラクティスを AWS 環境に実装できます。これにより、セキュリティが向上し、ヒューマンエラーのリスクが軽減され、デプロイプロセスが合理化されます。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: