모범 사례: 앱과 쿡북의 관리 및 배포 - AWS OpsWorks
일관성 유지온라인 인스턴스에 코드 배포

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

모범 사례: 앱과 쿡북의 관리 및 배포

중요

이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두 사용할 수 없습니다. 고객은 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션할 것을 강력히 권장합니다. 마이그레이션에 대해 궁금한 점이 있으면 AWS re:Post 또는 Premium AWS Support를 통해 AWS Support 팀에 문의하세요.

AWS OpsWorks Stacks는 원격 리포지토리에서 각각의 새 인스턴스에 앱과 쿡북을 배포합니다. 인스턴스의 수명 주기 동안 종종 스택의 온라인 인스턴스에서 앱 또는 쿡북을 업데이트하여 기능을 추가하고, 버그를 수정하는 등의 작업을 수행해야 합니다. 다양한 방법으로 스택의 앱과 쿡북을 관리할 수 있지만, 다음의 일반 요구 사항을 충족하는 접근 방식을 사용해야 합니다.

  • A/B 테스트와 같은 일부 목적을 제외하고 모든 프로덕션 스택 인스턴스는 동일한 애플리케이션 및 사용자 지정 쿡북 코드를 실행해야 합니다.

  • 업데이트 배포 시 뭔가가 잘못되더라도 사이트의 운영이 중단되지 않아야 합니다.

이 섹션에서는 앱과 사용자 지정 쿡북을 관리 및 배포하기 위해 권장되는 방법을 설명합니다.

일관성 유지

일반적으로 프로덕션 스택에서 실행되는 앱 또는 쿡북 코드는 엄밀히 통제해야 합니다. 대개 모든 인스턴스가 현재 승인된 버전의 코드를 실행해야 합니다. 나중에 설명하는 것처럼 앱 또는 쿡북을 업데이트할 때 그리고 A/B 테스트와 같은 특별한 경우는 예외입니다.

앱 및 쿡북 코드는 다음 두 가지 방식으로 지정된 소스 리포지토리에서 스택의 인스턴스에 배포됩니다.

  • 인스턴스를 시작하면 AWS OpsWorks Stacks는 현재 앱과 쿡북 코드를 인스턴스에 자동으로 배포합니다.

  • 온라인 인스턴스에 대해서는 배포 명령(앱의 경우) 또는 사용자 지정 쿡북 업데이트 명령(쿡북의 경우)을 실행하여 현재 앱 또는 쿡북 코드를 수동으로 배포해야 합니다.

배포 메커니즘이 두 가지이므로 의도치 않게 인스턴스마다 다른 코드를 실행하지 않도록 주의하여 소스 코드를 관리하는 것이 매우 중요합니다. 예를 들어 Git 마스터 브랜치에서 앱이나 쿡북을 배포하는 경우 Stacks는 당시 해당 브랜치에 AWS OpsWorks 있던 것을 배포합니다. 사용자가 마스터 브랜치에서 코드를 업데이트한 후 새 인스턴스를 시작한다면 이 인스턴스에서는 이전 인스턴스보다 최신 버전의 코드가 실행됩니다. 더 최신 버전이 프로덕션용으로 승인되지 않았을 수도 있습니다.

권장 사항: Amazon S3 아카이브

모든 인스턴스에서 승인된 코드 버전이 실행되도록 하려면 Amazon Simple Storage Service(S3) 아카이브에서 앱 및 쿡북을 배포하는 것이 좋습니다. 이렇게 하면 코드가 명시적으로 업데이트되어야 하는 정적 아티팩트(.zip 또는 기타 아카이브 파일)임을 확인할 수 있습니다. 또한 Amazon S3는 안정성이 뛰어나므로 아카이브에 액세스하지 못하는 경우는 거의 없습니다. 추가적으로 일관성을 보장하려면, 명명 규칙을 사용하거나 감사 트레일과 간편하게 이전 버전 복구를 제공하는 Amazon S3 버전 관리를 사용하여 각 아카이브 파일을 명시적으로 버전 관리합니다.

예를 들어 Jenkins 같은 도구를 사용하여 배포 파이프라인을 생성할 수 있습니다. 배포하려는 코드를 커밋하고 테스트한 후 아카이브 파일을 생성하여 Amazon S3로 업로드합니다. 모든 앱 배포 또는 쿡북 업데이트가 이 아카이브 파일의 코드를 설치하고 모든 인스턴스가 동일한 코드를 실행합니다.

권장 사항: Git 또는 하위 버전 리포지토리

Git 또는 하위 버전 리포지토리 사용을 선호하는 경우 마스터 브랜치에서 배포하지 마십시오. 대신, 승인된 버전을 태그 지정하고 해당 버전을 앱 또는 쿡북 소스로 지정합니다.

온라인 인스턴스에 코드 배포

AWS OpsWorks Stacks는 업데이트된 코드를 온라인 인스턴스에 자동으로 배포하지 않습니다. 사용자가 수동으로 이 작업을 수행해야 하는데, 이때 다음과 같은 도전 과제를 해결해야 합니다.

  • 배포 프로세스 도중 사이트가 고객 요청을 처리하는 능력에 악영향을 주지 않고 효율적으로 업데이트를 배포

  • 배포된 앱 또는 쿡북의 문제 또는 배포 프로세스 자체의 문제로 인해 실패한 배포를 처리

가장 간단한 접근 방식은 모든 인스턴스에 동시에 업데이트를 배포하는 기본 배포 명령(앱의 경우) 또는 사용자 지정 쿡북 업데이트 명령(쿡북의 경우)을 실행하는 것입니다. 이 접근 방식은 간단하고 빠르지만 오류의 여지가 없습니다. 배포가 실패하거나 업데이트된 코드에 문제가 있을 경우 프로덕션 스택의 모든 인스턴스가 영향을 받을 수 있으므로 문제를 해결하거나 이전 버전으로 롤백할 때까지는 사이트가 중단 또는 비활성화될 수 있습니다.

권장 사항: 사용자가 배포 성공을 확인하여 확신을 가지고 모든 수신 트래픽을 새 버전으로 이전할 수 있을 때까지는 이전 버전의 코드를 실행하여 요청을 계속 처리하도록 인스턴스를 허용하는 강력한 배포 전략을 사용합니다.

다음 섹션에서는 강력한 배포 전략의 두 가지 예를 제시하고 배포 시 백엔드 데이터베이스를 관리하는 방법을 설명합니다. 간결한 설명을 위해 앱 업데이트에 대한 설명만 나와 있지만 쿡북에도 유사하게 적용할 수 있습니다.

롤링 배포 사용

롤링 배포는 스택의 온라인 애플리케이션 서버 인스턴스에서 애플리케이션을 여러 단계에 걸쳐 업데이트합니다. 각 단계마다 온라인 인스턴스의 하위 집합을 업데이트하고 업데이트가 성공했는지 확인한 후 다음 단계를 시작합니다. 문제가 발생할 경우 이전 앱 버전을 실행 중인 인스턴스가 문제 해결 시까지 계속 수신 트래픽을 처리할 수 있습니다.

다음 예제는 사용자가 권장 방법을 사용하여 여러 가용 영역에 걸쳐 스택의 애플리케이션 서버 인스턴스를 배포하는 것으로 가정합니다.

롤링 배포를 수행하려면

  1. 앱 배포 페이지에서 [고급]을 선택하고 단일 애플리케이션 서버 인스턴스를 선택한 다음 앱을 해당 인스턴스에 배포합니다.

    좀 더 주의를 기울이고 싶다면 앱을 배포하기 전에 로드 밸런서에서 인스턴스를 제거할 수 있습니다. 그러면 사용자가 애플리케이션이 제대로 작동하는지 확인할 때까지 애플리케이션이 업데이트되지 않습니다. Elastic Load Balancing을 사용하는 경우 Elastic Load Balancing 콘솔, CLI 또는 SDK를 사용하여 로드 밸런서에서 인스턴스를 제거하세요.

  2. 업데이트된 앱이 제대로 작동하고 인스턴스의 성능 지표가 허용 가능한지 확인합니다.

    Elastic Load Balancing 로드 밸런서에서 인스턴스를 제거한 경우 Elastic Load Balancing 콘솔, CLI 또는 SDK를 사용하여 복원합니다. 이제는 업데이트된 앱 버전이 사용자 요청을 처리합니다.

  3. 가용 영역에서 인스턴스의 나머지 부분에 대해 업데이트를 배포하고 인스턴스가 올바르게 작동하고 지표가 허용 가능한지 확인합니다.

  4. 스택의 다른 가용 영역에 대해 3단계를 반복하되, 한 번에 한 영역씩 처리합니다. 특히 주의를 기울이려는 경우 1 - 3단계를 반복합니다.

참고

Elastic Load Balancing 로드 밸런서를 사용하는 경우 상태 확인을 사용하여 배포 성공 여부를 확인할 수 있습니다. 단, ping 경로를 단지 애플리케이션 서버가 실행 중인지 확인하는 정적 파일이 아니라 종속성을 검사하고 모든 것이 올바로 작동하는지 확인하는 애플리케이션으로 설정해야 합니다.

별도 스택 사용

애플리케이션을 관리하기 위한 또 하나의 접근 방식은 애플리케이션 수명 주기의 각 단계마다 별도의 스택을 사용하는 것입니다. 때로는 이러한 스택을 환경이라고 부르기도 합니다. 이 배열은 공개적으로 액세스할 수 없는 스택에서 개발 및 테스트를 수행할 수 있게 해줍니다. 업데이트를 배포할 준비가 완료되면 사용자 트래픽을 현재 애플리케이션 버전을 호스트하는 스택에서 업데이트된 버전을 호스트하는 스택으로 전환합니다.

개발, 스테이징 및 프로덕션 스택 사용

가장 일반적인 접근 방식에서는 다음과 같은 스택을 사용합니다.

개발 스택

새로운 기능 구현 또는 버그 수정과 같은 작업에 개발 스택을 사용합니다. 개발 스택은 기본적으로 프로덕션 스택과 동일한 계층, 앱, 리소스 등을 포함하는 프로토타입 프로덕션 스택입니다. 대개의 경우 개발 스택이 프로덕션 스택과 동일한 로드를 처리할 필요는 없으므로 더 적은 수의 인스턴스를 사용하는 것이 일반적입니다.

개발 스택은 퍼블릭 스택이 아니며, 다음과 같이 액세스를 제어합니다.

  • 애플리케이션 서버 또는 로드 밸런서의 보안 그룹 인바운드 규칙을 지정된 IP 주소 또는 주소 범위로부터 수신된 요청만 허용하도록 구성하여 네트워크 액세스를 제한합니다.

    예를 들어 HTTP, HTTPS 및 SSH 액세스를 회사 주소 범위 내 주소로 제한합니다.

  • AWS OpsWorks 스택의 권한 페이지를 사용하여 스택 스택 관리 기능에 대한 액세스를 제어할 수 있습니다.

    예를 들어 개발 팀에 관리 권한 수준을, 다른 모든 직원에게는 표시 권한을 부여합니다.

스테이징 스택

스테이징 스택을 사용하여 업데이트된 프로덕션 스택의 후보를 테스트하고 완료합니다. 개발을 완료했으면 개발 스택을 복제하여 스테이징 스택을 생성합니다. 그런 다음 스테이징 스택에서 테스트 도구 모음을 실행하고 업데이트를 이 스택에 배포하여 발생하는 문제를 해결합니다.

스테이징 스택도 퍼블릭 스택이 아닙니다. 개발 스택에서와 마찬가지 방식으로 스택 및 네트워크 액세스를 제어합니다. 참고로 개발 스택을 복제하여 스테이징 스택을 생성할 때는 스택 권한 관리에서 부여한 AWS OpsWorks 권한을 복제할 수 있습니다. 하지만 복제가 사용자의 IAM 정책에 의해 부여되는 권한에는 영향을 미치지 않습니다. 이러한 권한을 수정하려면 IAM 콘솔, CLI 또는 SDK를 사용해야 합니다. 자세한 정보는 사용자 권한 관리을 참조하세요.

프로덕션 스택

프로덕션 스택은 현재 애플리케이션을 지원하는 퍼블릭 스택입니다. 스테이징 스택이 테스트를 통과하면 이 스택을 프로덕션으로 승격하고 이전 프로덕션 스택은 사용 중지합니다. 이렇게 하는 방법의 예는 블루-그린 배포 전략 사용 섹션을 참조하세요.

참고

AWS OpsWorks 스택 콘솔을 사용하여 스택을 수동으로 생성하는 대신 각 스택에 대한 AWS CloudFormation 템플릿을 생성하십시오. 이 접근 방식에는 다음과 같은 장점이 있습니다.

  • 속도 및 편의성 - 템플릿을 시작하면, AWS CloudFormation 이(가) 모든 필요한 인스턴스를 포함하여 스택을 자동으로 생성합니다.

  • 일관성 - 소스 리포지토리에 각 스택의 템플릿 저장하여 개발자들이 동일한 목적에 동일한 스택을 사용하게 합니다.

블루-그린 배포 전략 사용

블루-그린 배포 전략은 별도의 스택을 효율적으로 사용하여 애플리케이션 업데이트를 프로덕션에 배포하는 일반적인 전략입니다.

  • 블루 환경은 현재 애플리케이션을 호스트하는 프로덕션 스택입니다.

  • 그린 환경은 업데이트된 애플리케이션을 호스트하는 스테이징 스택입니다.

업데이트된 앱을 프로덕션에 배포할 준비가 완료되면 사용자 트래픽을 블루 스택에서 그린 스택으로 전환합니다. 그러면 그린 스택이 새 프로덕션 스택이 됩니다. 그런 다음 기존의 블루 스택을 사용 중지합니다.

다음 예제에서는 AWS OpsWorks Stacks 스택을 Route 53 및 Elastic Load Balancing 로드 밸런서 풀과 함께 사용하여 블루-그린 배포를 수행하는 방법을 설명합니다. 스택을 전환하기 전에 다음 사항을 확인해야 합니다.

  • 그린 스택의 애플리케이션 업데이트가 테스트를 통과하고 프로덕션 준비가 완료되어야 합니다.

  • 그린 스택이 업데이트된 앱을 포함하는 점 이외에 블루 스택과 동일하고 퍼블릭 스택이 아니어야 합니다.

    두 스택 모두 권한이 동일하고, 각 계층 내 인스턴스 수 및 유형이 동일하고, 시간 기반 및 로드 기반 구성이 동일해야 합니다.

  • 모든 그린 스택의 24/7 인스턴스 및 예약된 시간 기반 인스턴스가 온라인 상태여야 합니다.

  • Elastic Load Balancing 로드 밸런서 풀은 어느 스택의 계층에 동적으로 연결될 수 있고 예상 트래픽 볼륨을 처리하도록 미리 워밍할 수 있습니다.

  • Route 53 가중치 기반 라우팅 기능을 사용하여 로드 밸런서 풀을 포함하는 호스팅 영역에서 레코드 세트를 생성해야 합니다.

  • 블루 스택의 애플리케이션 서버 계층에 연결된 로드 밸런서에 0이 아닌 가중치를 할당하고 사용되지 않는 로드 밸런서에는 0의 가중치를 할당했어야 합니다. 이는 블루 스택의 로드 밸런서가 모든 수신 트래픽을 처리하도록 보장합니다.

사용자를 그린 스택으로 전환하려면

  1. 그린 스택의 애플리케이션 서버 계층에 풀의 사용되지 않는 로드 밸런서 중 하나를 연결합니다. 플래시 트래픽이 예상되거나 트래픽을 점차적으로 증가시키도록 부하 테스트를 구성할 수 없는 경우와 같은 일부 시나리오에서는 로드 밸런서를 사전 워밍하여 예상 트래픽을 처리합니다.

  2. 그린 스택의 모든 인스턴스가 Elastic Load Balancing 상태 확인을 통과하면 Route 53 레코드 세트에서 가중치를 변경합니다. 그러면 그린 스택의 로드 밸런서 가중치가 0이 아닌 상태가 되고 블루 스택의 로드 밸런서가 이에 따라 가중치를 줄입니다. 그린 스택에서 요청의 극히 일부, 대략 5% 정도를 처리하도록 하고 나머지는 블루 스택에서 처리하도록 하는 것으로 시작하면 좋습니다. 이제, 수신되는 요청의 일부를 처리하는 그린 스택과 나머지 요청을 처리하는 블루 스택, 이렇게 두 가지 프로덕션 스택이 있습니다.

  3. 그린 스택의 성능 지표를 모니터링합니다. 이러한 성능 지표가 허용 가능한 경우 수신 트래픽의 10%를 처리하도록 그린 스택의 가중치를 늘립니다.

  4. 그린 스택이 수신 트래픽의 약 절반을 처리할 때까지 3단계를 반복합니다. 이 시점까지 모든 문제가 표면화되어야 합니다. 따라서 그린 스택이 허용 가능한 상태로 수행 중인 경우 블루 스택의 가중치를 0으로 줄여 프로세스를 완료할 수 있습니다. 이제 그린 스택이 새로운 블루 스택이 되어 수신 트래픽을 모두 처리 중입니다.

  5. 이전 블루 스택의 애플리케이션 서버 계층에서 로드 밸런서를 분리하고 풀로 반환합니다.

  6. 이전 블루 스택이 사용자 요청을 더 이상 처리하지 않더라도 새 블루 스택에 문제가 발생하는 경우를 대비해 얼마 동안은 이전 블루 스택을 유지하는 것이 좋습니다. 문제가 발생하면 위의 절차를 반대로 수행해 수신 트래픽을 다시 이전 블루 스택으로 연결하여 업데이트를 롤백할 수 있습니다. 새 블루 스택이 허용 가능한 상태로 작동한다는 확신이 들면 이전 블루 스택을 종료하세요.

백엔드 데이터베이스 관리

애플리케이션이 백엔드 데이터베이스를 사용하는 경우 이전 애플리케이션에서 새 애플리케이션으로 전환해야 합니다. AWS OpsWorks Stacks는 다음 데이터베이스 옵션을 지원합니다.

Amazon RDS 계층

Amazon Relational Database Service(RDS) 계층에서는 RDS DB 인스턴스를 별도로 생성한 후 스택에 등록합니다. RDS DB 인스턴스는 한 번에 한 스택에만 등록할 수 있지만 RDS DB 인스턴스를 한 스택에서 다른 스택으로 전환할 수 있습니다.

AWS OpsWorks Stacks는 연결 데이터가 포함된 파일을 애플리케이션에서 쉽게 사용할 수 있는 형식으로 애플리케이션 서버에 설치합니다. AWS OpsWorks 또한 스택은 레시피로 액세스할 수 있는 스택 구성 및 배포 속성에 데이터베이스 연결 정보를 추가합니다. JSON을 사용하여 애플리케이션에 연결 데이터를 제공할 수도 있습니다. 자세한 정보는 데이터베이스에 연결을 참조하세요.

데이터베이스에 의존하는 애플리케이션을 업데이트할 때 다음 두 가지의 기본적인 도전 과제를 해결해야 합니다.

  • 전환 시 모든 트랜잭션을 적절히 기록하면서도 새 애플리케이션 버전과 기존 버전 간 경합 조건을 방지

  • 사이트의 성능에 대한 영향을 제한하고 가동 중지를 최소화 내지는 배제하는 방식으로 전환을 수행

이 항목에서 설명하는 배포 전략을 사용하는 경우 단지 데이터베이스를 기존 애플리케이션에서 분리하고 새 애플리케이션에 다시 연결할 수는 없습니다. 전환 시 애플리케이션의 두 버전이 동시에 실행되며 동일한 데이터에 액세스할 수 있어야 합니다. 다음은 전환을 관리하는 두 가지 접근 방식에 대한 설명입니다. 각 접근 방식 모두 장점과 도전 과제가 있습니다.

접근 방식 1: 두 애플리케이션 모두 동일한 데이터베이스에 연결
장점

  • 전환 시 가동 중지가 없습니다.

    한 애플리케이션이 점진적으로 데이터베이스 액세스를 중지하고 다른 애플리케이션이 점진적으로 대신합니다.

  • 두 데이터베이스 간에 데이터를 동기화할 필요가 없습니다.

도전 과제

  • 두 애플리케이션 모두 동일한 데이터베이스에 액세스하므로 데이터 손실 또는 손상이 방지되도록 액세스를 관리해야 합니다.

  • 새 데이터베이스 스키마를 마이그레이션해야 할 경우 기존 애플리케이션 버전이 새 스키마를 사용할 수 있어야 합니다.

별도의 스택을 사용할 경우 아마도 이 접근 방식이 Amazon RDS에 가장 적합할 것입니다. 인스턴스가 특정 스택에 고정적으로 결합되지 않고 다른 스택에서 실행되는 애플리케이션에 의해 액세스될 수 있기 때문입니다. 하지만 RDS DB 인스턴스를 여러 스택에 동시에 등록할 수는 없습니다. 그러므로 예를 들어 JSON을 사용하여 두 애플리케이션에 모두 연결 데이터를 제공해야 합니다. 자세한 정보는 사용자 지정 레시피 사용을 참조하세요.

롤링 업그레이드를 사용하는 경우 기존 및 새 애플리케이션 버전이 동일한 스택에서 호스트됩니다. 따라서 Amazon RDS 또는 MySQL 계층을 사용할 수 있습니다.

접근 방식 2: 각 애플리케이션 버전에 자체 데이터베이스를 제공
장점

  • 각 버전마다 자체 데이터베이스가 있으므로 스키마 호환성이 필요하지 않습니다.

도전 과제

  • 전환 시 데이터 손실 또는 손상 없이 두 데이터베이스 간에 데이터를 동기화해야 합니다.

  • 동기화 절차로 인해 상당한 가동 중지가 발생하거나 사이트의 성능을 현저히 저하되지 않아야 합니다.

별도의 스택을 사용하는 경우 각 스택에 자체 데이터베이스가 있습니다. 롤링 배포를 사용하는 경우 각 애플리케이션마다 하나씩 두 데이터베이스를 스택에 연결할 수 있습니다. 기존 애플리케이션과 업데이트된 애플리케이션에 호환되는 데이터베이스 스키마가 없을 경우 이 접근 방식이 더 유용합니다.

권장 사항: 일반적으로 Amazon RDS 계층을 애플리케이션의 백엔드 데이터베이스로 사용하는 것이 좋습니다. 이 접근 방식이 더 유연하며 어떤 전환 시나리오에도 사용 가능하기 때문입니다. 전환을 처리하는 방법에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.