1. AWS CI/CD 배포의 개념
2. AWS CI/CD 배포의 실전
3. 실제 프로젝트 배포시 Github Actions 워크플로우 작성법(환경변수 관련)
4. NLB와 DNS 도메인 설정
AWS 데브옵스 실무과정을 수강하면서 노션에 기록해두었던 자료를 총 정리하고 직접 프로젝트를 무중단 배포해보면서 있었던 어려운 점들을 4편에 걸쳐 기록해 보겠습니다.
처음은 AWS CI/CD를 진행하기 위해 필요한 개념으로 구성했습니다.
CI/CD 무중단 배포에는 아래의 구성으로 진행했습니다.
ElasticBeanStalk + Github Actions(자동배포도구) + EC2 서버 2개 + RDS + ALB + NLB + IAM
AWS 프리미터(1년 무료)
사용 범위를 초과한다던지 무료가 아닌 것을 사용하면 비용이 청구됩니다.
EC2 - (한달을 켜두면 24시간 * 31일 = 744시간) x 2 = 약 1500시간 무료(t2.micro, t3.micro 사용가능)
RDS - 750시간 무료(t2.micro 버전)
로드밸런서 - 750시간 무료
AWS CI/CD 배포 과정
1. 로컬에서 Github 로 커밋을 진행하면 Github Actions(CI 서버)에서 테스트와 빌드를 진행하고 실행파일(jar)을 생성합니다.
2. AWS로 배포를 진행하면서 github Actions 워크플로우로 작성해놓은 스크립트가 실행되게 됩니다. 이때 그래서 AWS 환경과 동일한 OS의 명령어를 이용해서 스크립트를 작성해야 합니다.
3. CI 서버에서 통과가 완료되면 AWS에서 실행된다는 것을 보장해주는 것이고 CD(지속적배포)를 통해 자동 배포가 진행되게 됩니다.
정리를 하면 로컬에서 커밋을 하게되면 Github에서 변경감지가 일어나게 되고 CI서버로 CD를 하게 됩니다.
CI 서버에서는 AWS 환경과 동일한 환경에서 테스트와 빌드를 하고 실행파일을 생성한 뒤에 AWS 서버로 CD를 하게 됩니다.
이 과정을 CI/CD라고 합니다.
CI/CD의 개념
CI : 지속적 통합
CD : 지속적 배포(전달)
로컬에서 블로그 프로젝트를 2명이서 개발을 한다고 가정해보겠습니다.
각자 기능을 맡아 개발을 하고 Github에 올려서 통합을 시키면 기존 버전과 최신 버전이 생기게 됩니다.
최신 버전을 테스트 - 검증 - 빌드를 거쳐 AWS로 Jar 파일을 배포하게 되는데 이를 미리 감지하고 대신 해주는 서버가 대표적으로 2가지가 있습니다.
1. travis는 github에 10초마다 request요청을 보내서(폴링) 검증하고 Aws로 push 전달을 합니다.
2. Jenkins는 github에서 웹훅을 통해서 서버에 이벤트를 전달하고 검증후에 Aws로 push전달을 하는 프로그램입니다.
3. 지금 진행할 방식으로 GithubAction 이라는 github에서 직접제공하는 프로그램을 통해서 CI/CD를 해결하는 방법입니다.
AWS 사용자, 정책, 그룹, 역할
I AM(Identity Access Manager)
- 사용자: 직원
- 정책 : 권한의 모임
- 그룹 : 직원의 모임
- 역할: 권한의 모임(임시로 정책처럼 만들어서 서비스에 부여한다. 사용자가 아닌 서비스에 부여한다.)
로드밸런서
오토스케일링 그룹
클라이언트 입장에서는 EC2 A와 B 2개 중에 어디로 접속해야할지 모릅니다. 그래서 ALB(애플리케이션 로드밸런서)로 접근한다음
ALB가 A서버와 B서버의 트래픽을 확인하고 적은 쪽으로 접근시켜줍니다.
이때, 서버 2개가 다 바쁘다고 한다면 서버 C와 D를 자동으로 늘려줘서 접근을 시켜줍니다.(오토스케일링)
이후 트래픽이 널널해진다면 C 서버와 D 서버를 다시 자동으로 삭제합니다.(인스턴스 최소 2, 최대 4)
포트
엘라스틱 빈스톡 환경을 세팅하다 보면 리스너와 프로세스의 개념이 나오는데요.
리스너는 접근의 개념으로 80 포트를 허용해주면 80포트로 들어오는 것만 허용하겠다는 의미이고
프로세스의 포트 설정은 라우팅(리스너에서 프로세스로 전달)의 개념을 가지고 있습니다.
즉, 리스너에 8080포트를 추가하고 프로세스에는 8080 포트를 추가하지 않는다면 리스닝은 하지만 라우팅은 하지 않겠다는 의미가 됩니다.
추가적으로 포트에 대해 설명을 더 드리자면 well-known 포트라는 개념이 존재합니다.
0번 부터 1023번 까지는 이미 정해진 포트번호로 이후 번호는 내가 직접 사용할 수 있는 포트이지만 약속처럼 정해놓은 포트들을 의미합니다.
- 0번 ~ 1023번: 잘 알려진 포트 (well-known port)
- 1024번 ~ 49151번: 등록된 포트 (registered port)
- 49152번 ~ 65535번: 동적 포트 (dynamic port)
대표적으로 몇 가지 예시는 아래와 같습니다.
- 22번 포트 - 시큐어 셸 (SSH, Secure SHell) - ssh scp, sftp같은 프로토콜 및 포트 포워딩
- 80번 포트 - HTTP (HyperText Transfer Protocol) - 웹 페이지 전송
- 443번 포트 - HTTPS - 보안 소켓 레이어 (SSL, Secure Socket Layer) 위의 HTTP(암호화 전송)
롤링의 이해
무중단 배포의 필요성에 대해 설명드리겠습니다. 예를 들어 피파온라인이나 리그오브레전드와 같은 게임은 매주 목요일에 점검을 하면서 서버를 중단하고 업데이트하고 다시 재가동하게 됩니다.
하지만, 쿠팡과 같은 이커머스 기업은 서버점검을 하기 위한 시간동안 매출의 감소가 발생하기 때문에 반드시 무중단 배포로 진행하고 있습니다.
이를 위한 배포 전략은 여러가지가 있습니다. 대표적으로 몇가지를 설명드리겠습니다.
1. 한번에 모두(중단배포)
2. 추가 배치 전략
무중단 배포를 위해 서버를 몇 개씩 추가하여 새 서버에 배포를 시작합니다.
새 서버에 정상적으로 배포가 완료되면 이전의 서버들도 배포를 진행합니다.
하지만 이 방식엔 문제점이 존재하는데 새 서버엔 배포성공했지만 이전 서버에 에러가 발생하는 경우 롤백에 시간이 걸리고 효율성이 떨어지게 됩니다.
3. 블루/그린 전략
블루는 기존 서버를 의미하고 그린은 새 서버를 의미합니다.
그린 서버를 만들어서 새로 배포를 진행하고 정상적으로 배포가 완료되면 블루 서버를 삭제하는 방식입니다.
이전 방식의 문제였던 롤백에 대한 단점을 극복한 것으로서 문제가 발생했을 때 롤백이 쉽다는 장점이 있습니다만 자원이 많이 들어 비용이 가장 많이 발생합니다.
보안그룹의 이해
보안 그룹 관련해서는 2편에서 직접 배포를 진행하면서 자세히 설명드리겠습니다만 "왜"사용해야 하는지는 간단히 설명드리겠습니다.
VPC(Virtual Personal clude)는 가상 개인용 클라우드란 의미를 가지고 있습니다. 즉, 가상의 클라우드 공간을 만들고 외부 접근으로부터 안전하게 보호하기 위한 목적이 강합니다.
위의 그림은 EC2에 접근할 수 있는 포트를 설정해서 생성하고, RDS에는 EC2에서만 접근이 가능하게 함으로서 데이터베이스를 외부접근으로 부터 차단시킨 모습입니다.
이때, 차단을 어떻게 시키냐 ?
EC2의 보안그룹에서만 RDS로 접근할 수 있도록 RDS의 접근 규칙을 EC2 보안그룹으로 설정해두는 것입니다.
EC2를 직접 지목하지 않고 보안그룹으로 설정하게 되면 인스턴스가 여러개 생성되어도 추가로 접근을 허용시켜주기 위한 추가적인 작업이 필요가 없습니다.
여기까지 우선은 AWS CI/CD 배포에 대해 필요한 개념만을 정리해드렸습니다.
2편 부터는 직접 배포를 진행하면서 환경 설정에 대한 부분들을 설명드리도록 하겠습니다.
