3. CodePipeline

1. Overview

 

개요 및 배경

• AWS 환경에서 전체 CI/CD 파이프라인을 시각적으로 구성하고 오케스트레이션(Orchestration)하는 워크플로우 도구임
• 소스, 빌드, 테스트, 배포 등 다양한 단계를 순차적(Sequential) 또는 병렬(Parallel) 작업으로 유연하게 구성 가능
• 운영(Prod)과 같은 중요 환경 배포 전, 관리자의 검토를 요구하는 수동 승인(Manual Approval) 단계를 삽입하여 안전성을 높일 수 있음

주요 리소스 및 기능

1. 파이프라인 스테이지 연동 (Stage Integrations)
   • 소스(Source): AWS CodeCommit, Amazon S3, Amazon ECR(Docker 이미지) 및 GitHub, Bitbucket 등 서드파티 도구
   • 빌드 및 테스트(Build & Test): AWS CodeBuild, AWS Device Farm(iOS/Android 앱 테스트), Jenkins 등
   • 배포(Deploy): AWS CodeDeploy, Elastic Beanstalk, CloudFormation, ECS, S3 등
   • 호출(Invoke): AWS Lambda, Step Functions를 호출하여 사용자 지정 자동화 로직 실행 가능
2. 아티팩트(Artifacts) 매커니즘
   • 각 파이프라인 스테이지에서 생성된 출력물(코드, 빌드 결과물 등)을 아티팩트(Artifact)라고 부름
   • 생성된 아티팩트는 중앙 Amazon S3 버킷에 저장되어 다음 스테이지로 전달됨
   • 즉, CodeBuild나 CodeDeploy는 서로 직접 통신하는 것이 아니라 CodePipeline이 S3를 매개로 전달해 준 아티팩트를 입력값으로 받아 동작함

헷갈리는 포인트 (Tips)

• 파이프라인 실행 실패나 스테이지 취소 등의 상태 변경을 감지하고 알림(예: 이메일 전송)을 구성하려면 Amazon EventBridge (CloudWatch Events)를 활용해야 함
• 파이프라인이 특정 단계에서 코드를 가져오거나 빌드를 실행하지 못한다면, 해당 작업을 수행하기 위한 IAM 서비스 역할(Service Role) 권한이 CodePipeline에 올바르게 부여되었는지 확인해야 함
• 인프라 내에서 거부된 API 호출(Denied API calls) 내역을 감사(Audit)하고 트러블슈팅할 때는 AWS CloudTrail을 사용함

 

---

2. Extras

 

개요 및 배경

• CodePipeline을 시작(Trigger)하는 세 가지 주요 방식(Event, Webhook, Polling)의 차이점 및 최적의 사용 사례 이해 필요
• 파이프라인을 구성하는 각 액션의 소유자(Owner)와 작업 유형(Action Type) 구조화
• 운영 배포 전 안전장치 역할을 하는 수동 승인(Manual Approval) 단계의 정확한 메커니즘과 필수 IAM 권한 구성 이해

주요 리소스 및 기능

1. 파이프라인 트리거 방식 (Pipeline Triggers)
   • 이벤트(Events): AWS에서 가장 권장하는 기본 방식임. 변경 사항 발생 시 Amazon EventBridge 규칙을 통해 파이프라인을 즉각적으로 실행함 (GitHub 연동 시 CodeStar Source Connection을 활용하여 이벤트 기반 트리거 구성)
   • 웹훅(Webhooks): CodePipeline이 노출하는 HTTP 엔드포인트로 페이로드를 전송하여 외부 스크립트 등에서 파이프라인을 시작함
   • 폴링(Polling): 주기적으로 소스 저장소의 변경 여부를 확인하는 방식으로, 이벤트 방식보다 비효율적이므로 권장하지 않음
2. 액션 소유자 및 유형 (Owner & Action Type)
   • Owner: AWS (네이티브 서비스), Third Party (GitHub, Alexa 등), Custom (Jenkins 등)
   • Action Type: Source(S3, CodeCommit 등), Build(CodeBuild), Test(Device Farm 등), Approval(수동 승인), Invoke(Lambda), Deploy(CodeDeploy 등)
3. 수동 승인 (Manual Approval) 상세 메커니즘
   • 액션 구성 시 Owner는 AWS, Action Type은 Manual로 설정됨
   • 단계 도달 시 SNS 주제(Topic)를 트리거하여 지정된 사용자에게 이메일 알림 전송 가능
   • 승인 작업을 수행하는 IAM 사용자에게 반드시 다음 두 가지 권한이 부여되어야 함:
     • codepipeline:GetPipeline*: 파이프라인에 접근하여 수동 승인 단계를 조회하기 위한 권한
     • codepipeline:PutApprovalResult: 승인(Approve) 또는 거부(Reject) 결과를 제출하기 위한 권한

헷갈리는 포인트 (Tips)

• 외부 리포지토리(GitHub)를 소스로 사용할 때, 과거 방식인 폴링이나 일반 웹훅 대신 CodeStar Source Connection을 통한 이벤트 기반 트리거를 구성하는 것이 성능 및 아키텍처 관점에서 모범 사례임
• 수동 승인 알림을 받은 관리자가 승인을 처리하려 할 때 에러가 발생한다면, PutApprovalResult 권한뿐만 아니라 해당 파이프라인 자체를 읽을 수 있는 GetPipeline 권한이 누락되지 않았는지 확인해야 함

---

3. CloudFormation Integration

 

개요 및 배경

• AWS CloudFormation을 CodePipeline의 배포(Deploy) 단계 타겟으로 사용하여, 순수 템플릿뿐만 아니라 AWS SAM, AWS CDK 기반의 인프라 및 리소스 배포 자동화 가능
• 코드 기반의 인프라 변경 사항을 실제 환경에 바로 적용하기 전, 변경 세트(Change Sets)를 검토하여 예상치 못한 리소스 삭제나 변경을 방지함

주요 리소스 및 기능

1. 작업 모드 (Action Modes)
   • 변경 세트 제어 (Change Sets): Create or replace a change set 생성 후 Execute a change set로 실행 (주로 두 단계 사이에 수동 승인을 배치하여 검증함)
   • 스택 직접 제어 (Stacks): Create or update a stack, Delete a stack, Replace a failed stack (수동 승인 없이 즉각적인 스택 생성 및 파기가 필요할 때 사용함)
2. 템플릿 파라미터 재정의 (Parameter Overrides)
   • 파이프라인 런타임 단계에서 템플릿의 파라미터 값을 JSON 객체로 덮어쓰기(Override) 가능함
   • 템플릿 구성 파일을 통한 정적(Static) 재정의와, 파이프라인 입력 아티팩트를 통한 동적(Dynamic) 파라미터 전달을 모두 지원함
3. 다중 환경 배포 확장
   • 단일 리전 배포 외에도, CloudFormation StackSets를 연동하여 여러 AWS 계정 및 다중 리전에 인프라를 동시 배포함

헷갈리는 포인트 (Tips)

• 일회성 테스트 인프라 패턴: 파이프라인 내에서 CREATE_UPDATE 액션으로 임시 테스트 환경(예: ALB, ASG 등)을 생성하고, CodeBuild를 통해 기능/부하 테스트를 완료한 직후 DELETE_ONLY 액션으로 해당 스택을 즉시 파기하는 아키텍처 패턴이 CI/CD 모범 사례로 자주 활용됨
• 중요 운영(Prod) 환경 배포 시 스택을 직접 업데이트(Create or update a stack)하는 것은 위험성이 높음. 반드시 변경 세트 생성 -> 수동 승인(Manual Approval) -> 변경 세트 실행 순서의 파이프라인 구조를 설계해야 함

---

4. Advanced

 

개요 및 배경

• 다중 환경 배포, 병렬 처리, 사용자 지정 로직 통합 및 다중 리전 배포 등 CodePipeline의 고급 구성 및 성능 최적화 기법을 다룸
• 외부 API 호출이나 복잡한 워크플로우 로직을 파이프라인 내에 매끄럽게 연동하여 자동화 수준을 극대화함

주요 리소스 및 기능

1. 병렬 작업 (Parallel Actions) 및 이벤트 제어
   • 파이프라인 스테이지 내에서 동일한 RunOrder 값을 지정하여 여러 작업(빌드, 테스트, 다중 그룹 배포 등)을 동시에 병렬로 실행하여 전체 속도를 단축함
   • 파이프라인 상태 변경 및 작업 실패는 Amazon EventBridge를 통해 감지되며, 이를 통해 Lambda 또는 SNS 알림을 자동 트리거함
2. 호출(Invoke) 액션을 통한 기능 확장
   • CodePipeline 자체에는 외부 REST API를 직접 호출하는 기능이 없으므로, AWS Lambda 함수를 Invoke 액션으로 연결하여 사용자 지정 스크립트를 실행함
   • AWS Step Functions(상태 머신)를 호출하여 DynamoDB 데이터 제어, ECS 태스크 실행 등 복잡하고 다단계인 워크플로우를 CI/CD 파이프라인에 통합함
3. 다중 리전 배포 (Cross-Region Deployments)
   • 단일 파이프라인에서 CloudFormation 등을 활용해 여러 AWS 리전에 리소스(예: Lambda 함수)를 동시 배포함
   • 파이프라인이 내부적으로 원본 리전의 입력 아티팩트를 대상 리전으로 자동 복사(Copy)하여 배포를 수행함

헷갈리는 포인트 (Tips)

• 다중 리전 배포를 구성할 때, 액션이 존재하는 모든 대상 리전마다 개별적인 S3 Artifact Store(아티팩트 버킷)를 반드시 정의해야 함
• CodePipeline의 IAM 서비스 역할(Service Role)은 연동된 모든 리전의 S3 아티팩트 버킷에 대해 읽기 및 쓰기 권한을 온전히 가지고 있어야만 교차 리전 복사가 정상 동작함
• AWS Management Console을 사용할 때는 대상 리전의 아티팩트 버킷이 자동 생성되지만, CLI 또는 SDK로 파이프라인을 프로비저닝할 경우에는 사전에 다중 리전용 S3 버킷을 수동으로 미리 생성하고 권한을 설정해야 함