AWS 개발 및 운영 방안 / CI,CD / 운영

AWS 지속적 코드 배포 방법

지속적 통합 (continuous integration)

• 빌드 및 테스트가 수행된 후, 개발자가 코드 변경을 중앙 레포지토리에 정기적으로 통합하는 소프트웨어 개발방식
• 소프트웨어 릴리즈 프로세스 중 빌드 또는 통합 단계를 주로 가리키며, 자동화 구성 요소와 문화적 구성 요소를 포함
• 버그 신속 해결
• 소프트웨어 품질 개선
• 소프트웨어 업데이트 검증
• 릴리즈 시간 단축

---

지속적 전달 (Continuous delivery)

• 상용에 릴리스하기 위한 코드 변경이 자동으로 빌드, 테스트 및 준비되는 소프웨어 개발 방식이다.
• 빌드 단계 이후 모든 코드 변경을 테스트 환경 및 프로덕션 환경에 배포함으로써 지속적 통합을 확장한다.

---

지속적 배포 (Continuous deploy)

• 명시적 승인 없이 자동으로 프로덕션 환경에 배포되며 이를 통해 전체 소프트웨어 릴리즈 프로세스가 자동화

---

기본 코드 배포 파이프라인

---

효율적인 배포 정책 (Blue/Green)

• 효율적인 무중단 배포 방식

BLUE (V.1)	90%	50%	20%	0%
GREEN(V.2)	10%	50%	80%	100%

---

효율적인 배포 지원 시스템 (Spinnaker)

• Git
• Jenkins
• Blue / Green

---

AWS 운영 방안

계정 및 비용관리

• AWS를 운영하는 계정이 여러 개 일 경우 서로 간의 접근 통제, 권한 부여 및 과금 관리 등을 다양한 tool, 서비스를 통해 효율적으로 관리할 수 있도록 한다.
• 보안 격리, 서비스 구분 회계 등과 같은 여러 사유로 인해 계정을 다수개로 운영할 수 있으며 중앙 관리 부서에서 통합 빌링 (Consolidated Billing) 계정으로 과금 내역을 관리한다.
• 통합 빌링 계정은 과금만 중앙에서 관리 가능하며 리소스에 대한 연결은 링크드 계정의 권한으로 사용할 수 있다. 
• 예를 들어 개발/QA/상용처럼 환경의 목적에 맞게 계정을 분리한다거나 비즈니스 군 별로 계정을 분리하여 운영 가능하다.

---

자산 관리

• 배포된 자산에 대해 추적하거나 관리를 위해 자산 관리 정책이 필요하며 효율적으로 자산 운영할 수 있도록 AWS 제공 기능 혹은 내부의 기술들을 활용
• 리소스에 대해 다양한 메타정보를 제공하고 있으며 API, CLI를 통해 프로그래밍 가능하게 정보 수집이 가능하다. 또한 커스텀 tag 기능을 통해 요구사항을 충족시킬 수 있는 정보들을 직접 입력 및 관리 가능하다.

---

모니터링 및 사고 관리

• 애플리케이션과 시스템 모니터링은 기본적인 운영 및 장애 대응의 방법이며 비즈니스의 중요도에 준하여 알람 설정과 모니터링 정책들을 관리한다.
• CloudWatch를 통해 AWS의 리소스들의 모니터링 메트릭을 설정 가능하고 SNS, SMS를 통해 알람 기능을 연동하여 효과적인 운영을 가능하게 한다.
• 서비스 중단 혹은 약속된 성능을 제공하는데 실패한 경우 신속하게 정상 동작으로 서비스를 복구해야 하며 서비스 성능의 저해 가능성이 있는 요소들을 제거하고 방지 관리한다.
• 인시던트 관리는 사고 인식, 로깅, 우선순위화, 초기 진단, 2선 에스컬레이션 와 같은 역할을 포함한다.

---

고가용성 및 탄력성 방안

• 효율적인 HA 정책에는 Multi AZ를 활용한 인스턴스의 이중화 관리, 로드밸런싱, 오토스케일링, 모니터링과 region 내 복구를 포함하고 있다.
• 중요한 어플리케이션일수록 모든 SPOF의 사항을 확인하고, 어플리케이션의 가용 요구 사항과 위험 측면을 바탕으로 검토해야 한다.

---

고가용성 및 탄력성 방안

• EC2 인스턴스가 Multi AZ에 걸쳐 (이중화되어) 동작되고 있는가?
• Multi AZ에 걸쳐서 ELB(Elastic Load Balancing)를 활용하고 있는가?
• 자동화된 인스턴스의 확장 복구를 위해 AutoScaling을 활용하고 있는가?
• CloudWatch 매트릭을 활용해 모니터링과 알람을 연동하고 있는가?
• Elastic IP의 Static한 특성을 활용하여 인스턴스에 매핑하였는가?
• EBS (Elastic Block Store) 볼륨을 관리하기 위해 Point-in-time snapshot을 활용하고 있는가?
• 오브젝트 저장을 위해 S3 혹은 컨텐츠 분배를 위해 CloudFront를 활용하고 있는가?
• Key/Value 형태의 데이터 저장을 위해 Simple DB나 dynamoDB를 사용하고 있는가?
• 어플리케이션 버전 관리와 환경 구성을 위해 Elastic Beanstalk를 활용하고 있는가?
• 복잡성과 확장성을 가진 어플리케이션의 관리를 위해 DevOps 솔루션인 OpsWorks를 활용하고 있는가?
• 데이터베이스 미러링과 같은 동기형 데이터 복제 기술을 사용하고 있는가?
• HA 리소스 용량까지 고려하여 AWS 리소스의 Quota를 추가하였는가? 

---

DR 및 백업 관리 (disaster recovery)

• 효율적인 DR 정책은 단일 컴포넌트 복구 뿐만이 아니고 애플리케이션 단에서의 예상된 DR 시나리오 수행 등을 포함하고 있다.
• DR 정책은 지역간 이중화, 글로벌 트래픽 관리 혹은 로드밸런싱, 모니터링, 지역 대 지역 간 복구들을 포함해야 하며 아래와 같은 사항 및 기술들이 DR 정책에 고려되어야 한다.

---

DR 및 백업 관리

• 데이터 저장, AMI 혹은 타 지역(region)에 추가 인스턴스가 있는지 확인하였는가?
• Route 53을 통해 DNS에 기반한 지역간 fail-over를 사용하고 있는가?
• Glacier 를  통해 데이터 보관을 하고 있는가?
• 데이터베이스 log shipping 과 같은 비동기형의 데이터 복제 기술을 사용하고 있는가?
• EBS Snapshot 복제와 혹은 AMI 복제를 지역간 하고 있는가?
• S3의 Versioning을 활용하여 데이터 저장이나 보호를 하고 있는가?
• 데이터 손실로부터 빠른 복구를 위해 주기적인 EBS Snapshot 혹은 3rd party 툴을 활용하고 있는가?
• S3의 생명주기 정책(object lifecycle policies)를 활용하여 Glacier로의 보관을 하고 있는가?
• DR 리소스 용량까지 고려하여 DR 리즌의 리소스의 Quota를 추가하였는가?

---

AWS 운영 체크리스트

기본 체크리스트

• 상용 레벨의 애플리케이션을 런칭하기 전에 검토해야할 체크리스트 이며 잠재적인 위험요소와 통상적인 인프라 go-live에 관련한 사항이다.
• 비용 관리 및 계정 관리를 위한 관리 시스템을 개발하였는가?
• 조직 안에 다수의 계정 과금에 대한 통합 관리 방안은 결정하였는가?
• AWS에서 사용 중인 리소스들의 확인 및 변경사항 추적을 위한 정책을 가지고 있는가?
• AWS API, 콘솔, OS, 네트워크와 데이터의 보안과 접근을 위한 정책을 개발하였는가?
• AWS 리소스와 연동하여 장애 관리 방법과 적합한 모니터링 툴을 산정하였는가?

---

책임 분담 모델

Infrastructure 서비스 모델

Abstracted 서비스 모델