-
인프라 및 배포 자동화
- 휴먼 에러를 줄이기 위해!
자동화 해야하는 이유!
- 대규모 컴퓨팅 환경을 구축하려면 상당한 시간과 에너지가 필요!
- 롤백 롤아웃 관리를 위해
- 배포 관리
자동화가 없는 경우
- 클릭으로 할시 완전이 같은 환경이라는 것을 보장 못함
- 확장불가, 버전제어 없음, 감사내역부족, 일관성 없는 데이터 관리
인프라 자동화 (IaC)
- AWS CloudFormation (or 테라폼도 사용 가능)
- AWS 인프라를 설명하는 공통 언어 제공
- 설명된 리소스를 자동화된 방식으로 생성, 구축
- 하나의 템플릿으로 dev , prod 모두 deploy가능
Cloud Formation
code로 취급 -> vcs(git)
Yaml/Json 사용 -> CF -> stack -> Resource
템플릿은 조건부 출력을 생성할 수 있다.
1) Drift
v1 -> Resource
사용자가 Resource를 직접 변경(Direct Change)하면 Drift set으로 확인후 변경할지 말지 확인 가능
2) Change Set
version이 변경된 경우 기존과 바뀐 부분 확인 가능
스택 업데이트
기존 스택 -> 변경 세트 생성-> 변경 세트 -> 변경 세트 보기->변경 검사 -> 변경 세트 실행 -> CloudFormation
계층을 나눠서 구축
AWS Quick Start(https://aws.amazon.com/ko/quickstart/)
표준화된 템플릿
배포 자동화
OpsWors Stacks 사용하여 애플리케이션 계층을 배포
먼저 VPC , IAM은 Cloud Formation으로 만들어야한다.
수동 작업 줄이기
Elastic Beanstalk 환경
- 개발자 입장에서 인프라 관리를 최대한으로 줄인다.
배포전략
블루-그린
- 기존 앱과 신규앱을 같이 유지하면서 트래픽을 점점 옮긴다
블루-그린 챌린지
- 기존 DNS가 캐싱되어 업데이트 전 DNS로 트래픽이 들어올 수 있다.
-해결책
1. LB와 Auto Scaling 그룹을 사용하여 DNS우회
- 단점 : 인프라 변경 테스트에 블루-그린 사용을 허용하지 않음
2. Global Accelerator를 사용하여 DNS 캐싱 직접 처리
- 단점 : 사용 사례에 따라 비용이 많이 추가될 수 있다.
Canary
- 일부만 배포해보고 문제가 없어 보이면 전체 배포
- 점진적인 배포
블루-그린 Canary
배포간 트래픽 라우팅 (Route 53)
ASW Systems Manager
- 실행 명령
- 패치 관리
- 유지 관리 기간
- 상태 관리자
지속적 통합 및 지속적 배포(CI/CD)
릴리스 프로세스: 주요단계
소스 -> 빌드 -> 테스트 -> 배포 -> 모니터링
CI/CD
지속적 통합 : 빨리 합쳐서 조기에 문제 해결 ( git -> jenkins )
지속적 전달 : 코드 push 후 배포 및 테스트 문제 없으면 바로 배포한다.
AWS Code Service
- CodeStar로 총괄 관리