SOA-C03 09/16 — 배포·공유·프로비저닝 문제 해결
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 배포의 변경 단위와 중단 경계를 정한다
08에서 무엇을 배포하는지 식별했다. 이제 실제 배포가 어느 자원을 언제 바꾸고, 실패하면 어떤 상태를 남기는지 본다.
| 전략 | 진행 방식 | 운영 판단 |
|---|---|---|
| All-at-once | 대상 전체를 한 번에 변경 | 빠른 변경과 큰 영향 범위 |
| Rolling | 묶음별 순차 교체 | 배포 중 잔여 capacity·버전 공존 |
| Blue/green | 새 환경을 준비한 뒤 전환 | 추가 capacity·데이터 호환성·전환 복구 |
| Canary | 일부 요청에 새 버전 노출 후 확대 | 작은 표본에서의 지표·관찰 시간 |
| Linear | 일정 비율씩 트래픽 이동 | 단계별 실패 감지와 중단 조건 |
서비스별 지원 전략과 hook·rollback 방식은 다르다. CodeDeploy의 EC2/on-premises, Lambda, ECS 배포를 같은 기능 집합으로 가정하지 않는다. Deployment strategies, CodeDeploy configurations
트래픽을 되돌릴 수 있어도 DB schema·데이터 변경이 이전 버전과 호환되지 않으면 rollback이 완성되지 않는다. 변경 전에 읽기·쓰기 호환성을 포함한 완료 조건을 둔다.
2. Subnet은 정상 운영보다 배포 순간에 더 많은 주소가 필요할 수 있다
일반적인 AWS 제공 IPv4 subnet에서는 첫 네 주소와 마지막 주소가 예약된다. /24는 256개 주소 중 251개를 할당할 수 있다. BYOIP 등 별도 조건은 구분한다. Subnet CIDR
필요 주소는 EC2 수만 세면 부족하다. ENI를 사용하는 task·endpoint·load balancer와 교체 중 구·신 자원의 공존도 고려한다.
예를 들어 /27 subnet의 일반 할당 가능 주소는 27개다. 현재 20개를 사용하고 배포가 기존 자원을 유지한 채 10개를 더 요구하면 여유 7개로는 부족하다. 이는 주소 계산 예시이며 특정 서비스의 최소 subnet 요구를 대신하지 않는다.
배포 시 IP 부족이면 available IP와 실제 ENI 소유자를 조사한다. 기존 subnet CIDR을 제자리에서 늘리는 것으로 해결한다고 가정하지 말고, 추가 subnet·주소 계획·배치 변경을 검토한다.
3. CloudFormation은 실패한 resource event부터 읽는다
상위 stack의 실패 문구만 보면 원인을 놓치기 쉽다. Operation과 시각을 맞춰 실제 실패 resource의 StatusReason을 읽고, 그 뒤의 취소·rollback 사건과 구분한다.
| 오류 범주 | 대조할 대상 |
|---|---|
| 잘못된 parameter·속성 | 현재 account·Region의 실제 ID와 resource schema |
| Dependency | 참조·명시적 순서·외부 선행 자원 |
| 권한 실패 | 실제 실행 역할·API·resource·condition |
| Quota·capacity | 한도와 교체 중 동시 자원 수 |
| 안정화·signal timeout | resource health·초기화 log·network·signal |
| 외부 자동 조치 충돌 | Config·SSM 등이 배포 중 같은 속성을 바꾸는지 |
Stack event의 오류를 해당 서비스 로그에 연결한다. EC2 bootstrap은 cloud-init·cfn 로그를 보고, 성공 신호가 없으면 신호 자체를 강제로 성공시키기보다 설치·연결·기동이 실제로 성공했는지 확인한다. CloudFormation troubleshooting
4. 배포 호출자와 CloudFormation 실행 역할
사용자에게 CloudFormation 시작 권한이 있어도 실제 resource를 만들 권한이 충족되지 않을 수 있다. Service role을 사용하는 stack은 그 역할로 resource 작업을 수행한다. Role을 전달하는 호출자의 PassRole, 역할 trust, 역할의 서비스 API 권한을 구분한다.
한 stack에 service role을 연결하면 이후 stack 작업에서도 그 역할을 사용한다. 따라서 stack 조작 권한 자체가 그 역할을 통한 변경 능력과 연결될 수 있으므로 역할과 stack 접근 범위를 함께 설계한다. CloudFormation service role
KMS-encrypted AMI·snapshot이나 다른 account resource를 사용할 때는 resource policy·key policy·공유 설정까지 확인한다. 정책 구조 전체는 11에서 다시 연결한다.
5. Rollback도 실행이며 실패할 수 있다
UPDATE_ROLLBACK_FAILED는 원래 상태로 돌아가는 과정이 끝나지 않은 상태다. 이전 resource가 외부에서 삭제됐거나 필요한 권한·capacity가 부족하면 rollback 자체도 실패한다.
원인을 바로잡고 continue rollback을 실행한다. ResourcesToSkip으로 일부를 건너뛰면 stack template과 실제 resource가 불일치할 수 있으므로 다음 update 전에 정합성을 복원해야 한다. Rollback 재개
실패를 없애기 위해 stack을 통째로 삭제하는 것이 기본 복구 절차는 아니다. 보존해야 할 데이터·남은 자원·실제 변경 상태를 확인하고 대응한다. 완료된 stack 상태도 애플리케이션 health와 데이터 기능 검증을 대신하지 않는다.
6. RAM 공유와 StackSets 배포는 다른 목적이다
| 수단 | 하는 일 | 별도 확인 |
|---|---|---|
| AWS RAM | 지원 resource를 다른 principal과 공유 | 공유 범위·permission·서비스별 사용 조건 |
| StackSets | 같은 template 기반 stack들을 account·Region에 배포 | 대상별 실행·parameter·권한·실패 |
| AMI copy/share | 실행 이미지의 이용·복사 범위 구성 | Region ID·snapshot·KMS·launch 허용 |
RAM은 지원되는 resource를 공유하는 도구다. Shared subnet처럼 동일 자원을 사용하는 관계이지 resource를 대상 account마다 복제하는 방식이 아니다. 공유받았다는 사실만으로 모든 관리 작업 권한을 얻지는 않는다. AWS RAM
StackSets는 여러 account·Region에 개별 stack을 만든다. Self-managed는 필요한 역할·trust를 직접 구성하고, service-managed는 Organizations 연계를 사용한다. Region 순서·동시성·실패 허용도를 정하고 대상별 stack instance 결과를 본다. StackSet 정의 생성과 전체 배포 성공을 구분한다. StackSets
7. 완성된 운영 적용 — 다른 account의 새 환경 배포 실패
- 요청한 account·Region과 실제 실행 identity를 확인한다.
- StackSet의 해당 target 결과와 stack resource event를 연다.
- AMI ID·subnet·security group이 그 환경에 존재하는지 대조한다.
- Shared resource면 RAM·resource policy·KMS 접근을 확인한다.
- 주소 부족이면 배포 중 동시에 존재할 ENI 수를 계산한다.
- 권한·주소·parameter 중 확인된 원인을 수정해 실패 대상을 재시도한다.
- 모든 target의 결과와 실제 endpoint health를 각각 확인한다.
한 account 성공은 다른 account의 quota·SCP·network까지 검증하지 않는다. 같은 template도 환경별 입력과 정책에 따라 실패할 수 있다.
8. 연결 요약
배포 문제는 산출물 → 입력·주소 → 호출·실행 권한 → dependency → 실행 event → 서비스 검증 순서로 좁힌다. 시험에서는 배포 전략과 오류에 맞는 복구 수단을 선택하고, 실제 운영에서는 데이터 보존·버전 공존·부분 성공을 함께 다룬다. 범위: Domain 3 Skills 3.1.3~3.1.5.
계획과 연결
-
ID:
09-deployment-sharing-and-troubleshooting -
의존:
08-images-and-infrastructure-as-code -
결정 축: 배포 전략과 계정·리전 범위를 정한 뒤 의존성, 주소 공간, 권한, stack 이벤트에서 실패 지점을 찾는다.
-
범위: deployment strategies and services, subnet sizing, CloudFormation errors, permission failures, AWS RAM, CloudFormation StackSets, cross-account·cross-Region provisioning.
-
시험 매핑: Domain 3, Skills 3.1.3–3.1.5.