SEC11-BP06 프로그래밍 방식으로 소프트웨어 배포 - AWS Well-Architected 프레임워크
구현 지침리소스

SEC11-BP06 프로그래밍 방식으로 소프트웨어 배포

가능한 한 프로그래밍 방식으로 소프트웨어를 배포하세요. 이 접근 방식을 통해 인적 오류로 배포 실패나 예기치 않은 문제가 발생할 가능성을 줄일 수 있습니다.

원하는 성과: 테스트하는 워크로드의 버전은 배포하는 버전이며 배포는 매번 일관되게 수행됩니다. 워크로드 구성을 외부화하여 변경 없이 다양한 환경에 배포할 수 있습니다. 암호화된 서명 소프트웨어 패키지를 사용하여 환경 간에 변경된 내용이 없음을 확인합니다.

일반적인 안티 패턴:

  • 프로덕션에 소프트웨어를 수동으로 배포합니다.

  • 다양한 환경에 맞게 소프트웨어를 수동으로 변경합니다.

이 모범 사례 확립의 이점:

  • 소프트웨어 릴리스 프로세스에 대한 신뢰도가 높아집니다.

  • 비즈니스 기능에 영향을 미치는 변경 실패 위험을 줄여줍니다.

  • 변경 위험 감소로 인해 릴리스 주기가 길어집니다.

  • 배포 중 예기치 않은 이벤트에 대한 자동 롤백 기능이 지원됩니다.

  • 테스트된 소프트웨어가 배포된 소프트웨어임을 암호화하여 증명하는 기능이 제공됩니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 높음

구현 가이드

강력하고 신뢰할 수 있는 애플리케이션 인프라를 유지하기 위해 안전하고 자동화된 배포 방식을 구현합니다. 이 방식에는 프로덕션 환경에서 지속적인 인적 액세스 제거, 배포를 위해 CI/CD 도구 사용, 환경별 구성 데이터 외부화가 포함됩니다. 이 접근 방식을 따르면 보안을 강화하고 인적 오류의 위험을 줄이며 배포 프로세스를 간소화할 수 있습니다.

AWS 계정 구조를 구축하여 프로덕션 환경에서 지속적인 인적 액세스를 제거할 수 있습니다. 이 방식은 무단 변경 또는 우발적 수정의 위험을 최소화하여 프로덕션 시스템의 무결성을 개선합니다. 사람의 직접적인 액세스 대신 AWS CodeBuild 및 AWS CodePipeline과 같은 CI/CD 도구를 사용하여 배포를 수행할 수 있습니다. 이러한 서비스를 사용하여 구축, 테스트 및 배포 프로세스를 자동화하여 수동 개입을 줄이고 일관성을 높일 수 있습니다.

보안 및 추적성을 더욱 강화하기 위해 애플리케이션 패키지를 테스트한 후 애플리케이션 패키지에 서명하고 배포 중에 이러한 서명을 검증할 수 있습니다. 이렇게 하려면 AWS Signer 또는 AWS Key Management Service(AWS KMS)와 같은 암호화 도구를 사용합니다. 패키지에 서명하고 확인하면 인증되고 검증된 코드만 환경에 배포할 수 있습니다.

또한 팀은 워크로드를 아키텍팅하여 AWS Systems Manager Parameter Store와 같은 외부 소스에서 환경별 구성 데이터를 얻을 수 있습니다. 이 방식은 애플리케이션 코드를 구성 데이터와 분리하므로 애플리케이션 코드 자체를 수정하지 않고도 독립적으로 구성을 관리하고 업데이트할 수 있습니다.

인프라 프로비저닝 및 관리를 간소화하려면 AWS CloudFormation 또는 AWS CDK와 같은 코드형 인프라(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. 구성 데이터 외부화:

    • 환경별 구성 데이터를 AWS Systems Manager Parameter Store에 저장합니다.

    • 배포 또는 런타임 중에 Parameter Store에서 구성 데이터를 검색하도록 애플리케이션 코드를 수정합니다.

  5. 코드형 인프라(IaC) 구현:

    • AWS CloudFormation 또는 AWS CDK와 같은 IaC 도구를 사용하여 인프라를 코드로 정의하고 관리합니다.

    • CloudFormation 템플릿 또는 CDK 스크립트를 생성하여 애플리케이션에 필요한 AWS 리소스를 프로비저닝하고 구성합니다.

    • IaC를 CI/CD 파이프라인과 통합하여 애플리케이션 코드 변경과 함께 인프라 변경 사항을 자동으로 배포합니다.

  6. 카나리 배포 구현:

    • 전체 프로덕션 환경에 배포하기 전에 인스턴스 또는 사용자 하위 집합에 변경 사항이 롤아웃되는 카나리 배포를 지원하도록 배포 프로세스를 구성합니다.

    • AWS CodeDeploy 또는 AWS ECS와 같은 서비스를 사용하여 카나리 배포를 관리하고 변경의 영향을 모니터링합니다.

    • 카나리 배포 중에 문제가 감지되면 롤백 메커니즘을 구현하여 이전의 안정적인 버전으로 되돌립니다.

  7. 모니터링 및 감사:

    • 모니터링 및 로깅 메커니즘을 설정하여 배포, 애플리케이션 성능 및 인프라 변경을 추적합니다.

    • Amazon CloudWatch 및 AWS CloudTrail과 같은 서비스를 사용하여 로그 및 지표를 수집하고 분석합니다.

    • 감사 및 규정 준수 검사를 구현하여 보안 모범 사례 및 규제 요구 사항 준수 여부를 확인합니다.

  8. 지속적 개선:

    • 배포 방식을 정기적으로 검토 및 업데이트하고 이전 배포에서 얻은 피드백과 배운 내용을 반영합니다.

    • 배포 프로세스를 최대한 자동화하여 수동 개입과 잠재적인 인적 오류를 줄입니다.

    • 여러 분야의 팀원으로 구성된 팀(예: 운영 또는 보안)과 협력하여 배포 방식을 조정하고 지속적으로 개선합니다.

이러한 단계를 따르면 AWS 환경에서 안전하고 자동화된 배포 방식을 구현하여 보안을 강화하고 인적 오류의 위험을 줄이며 배포 프로세스를 간소화할 수 있습니다.

리소스

관련 모범 사례:

관련 문서:

관련 비디오:

관련 예제: