[36일차] 환경변수 설정 및 배포 전략
클라이언트 환경 변수
생성한 빌드 프로젝트 클릭 후 편집 환경 선택한다. 추가 구성에서 환경 변수 값을 입력하고 환경 업데이트한다.
서버 환경 변수 설정
AWS Parameter Store 서비스를 이용하 EC2 instance에 환경 변수를 전달한다.
파라미터 생성 - 현재 리포지토리에서 총 4개(DATABASE_HOST, DATABASE_USER, DATABASE_PASSWORD, DATABASE_PORT)의 환경 변수를 이용해 DB와의 연결을 세팅해두었다. 해당 과정을 반복해 4개의 파라미터를 모두 생성한다.
다음으로 로컬 환경에서 소스 코드의 start.sh 파일을 수정한다.
#!/bin/bash
cd /home/ubuntu/im-sprint-practice-deploy/server
수정된 scripts/start.sh
export DATABASE_USER=$(aws ssm get-parameters --region ap-northeast-2 --names DATABASE_USER --query Parameters[0].Value | sed 's/"//g')
export DATABASE_PASSWORD=$(aws ssm get-parameters --region ap-northeast-2 --names DATABASE_PASSWORD --query Parameters[0].Value | sed 's/"//g')
export DATABASE_PORT=$(aws ssm get-parameters --region ap-northeast-2 --names DATABASE_PORT --query Parameters[0].Value | sed 's/"//g')
export DATABASE_HOST=$(aws ssm get-parameters --region ap-northeast-2 --names DATABASE_HOST --query Parameters[0].Value | sed 's/"//g')
authbind --deep pm2 start app.js변경 사항을 저장하고 commit한 뒤, master로 push하여 파이프라인을 통해 변경 사항을 전달한다.
AWS CLI (Command Line)
AWS Command Line Interface는 쉘 커맨드를 사용하여 AWS 서비스와 상호 작용할 수 있는 도구이다.
우리가 브라우저로 아마존 웹 서비스 홈페이지(콘솔 홈)에 가서 서비스를 이용한 것 처럼, 터미널에서 명령줄로 aws 서비스를 이용하는 것이라고 보면 된다.
최소한의 구성으로 AWS CLI를 사용하면 브라우저 기반 AWS Management Console에서 제공하는 것과 동일한 기능을 구현하는 명령을 실행할 수 있다.
따로 CLI 기반의 커맨드를 지원하는 이유는, AWS CLI를 사용하여 서비스의 기능을 살펴보고 리소스를 관리할 쉘 스크립트를 개발할 수 있기 때문이다. 예를들어 VPC 인프라를 구축한다고 하면 웹 콘솔 브라우저에서는 마우스로 이리저리 클릭하며 생성해야 되지만, 쉘 스크립트로 템플릿을 짜서 실행만 하면 뚝딱 만들 수 있다.
- 리눅스 aws cli 설치
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version
aws-cli/2.7.9 Python/3.9.11 Linux/5.13.0-51-generic exe/x86_64.ubuntu.20 prompt/off
rm -f awscliv2.zip 설치 되었으면 용량 보면서 zip은 지워주자. 용량이 여유롭지 못하다.
- CLI 인증 설정
AWS Cli를 사용하기 위해서는 AWS 계정에서 발급한 IAM 사용자의 AWS Access Key ID와 AWS Secret Access Key가 필요하다.
AWS 홈페이지에서 계정을 로그인 한 것과 같이, CLI에서도 내 서비스를 이용하기 위해선 IAM에서 등록한 사용자 계정의 아이디와 비밀번호가 필요하다.
그 아이디와 비밀번호가 Access Key ID와 Secret Access Key 라고 보면 된다.
유저 엑세스 키를 알아낸 후 aws configure를 입력하여 이용하고자 하는 User의 Access, Secret Access Key를 입력
배포 전략
- 블루/그린 배포
Blue-Green 배포는 애플리케이션 또는 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델이다.
배포를 자동화할 때 겪는 어려움 중 하나는 소프트웨어를 최종 테스트 단계에서 실제 프로덕션 단계로 전환하는 컷오버 자체이다. 일반적으로 다운 타임을 최소화하려면 이 작업을 신속하게 수행해야 한다.
블루 / 그린 배포는 가능한 동일한 두 가지 프로덕션 환경을 확보함으로써 이를 실현시킬 수 있다.
컷오버(cutover) : 기존에 운영 되던 환경을 중단시키고, 새로 구축된 환경으로 오픈하는 것
다운타임(Downtime) : 시스템을 이용할 수 없는 시간
blue를 실제 운영중인 환경으로 가정하겠다.
새로운 버전을 릴리즈 하고 싶은 경우 green 환경에서 테스트를 진행한다.
테스트가 정상 완료 된다면 blue 환경에서 들어가던 모든 요청을 green 환경으로 변경한다.
blue는 이전 green 환경의 역할을 가져감과 동시에 green이 잘 동작하지 않을때 사용할 수 있는 백업 서버로의 역할도 수행이 가능하게 된다.
- 블루 / 그린 배포의 원칙
두 환경은 다르지만, 최대한 동일해야 한다.
경우에 따라 하드웨어의 다른 부분일 수도 있고 동일한(또는 다른) 하드웨어에서 실행되는 다른 가상 머신일 수도 있다. 또한 두 슬라이스에 대해 별도의 IP 주소를 사용하여 별도의 영역으로 분할된 단일 운영 환경이 될 수도 있다.
무중단 배포여야 합니다.
한 시점에 하나의 버전만 액티브 상태여야 하며, 롤백이 쉬워야 한다.
- 블루 / 그린 배포의 장점
동일하게 구성된 환경을 하나 더 추가함으로써 서비스의 가동 중단 시기를 최소화 시킬 수 있다.
서비스 되고 있는 환경(블루 혹은 그린)에 문제가 발생한 경우 백업 서버로 사용 할 수 있다.
다음 배포를 위한 최종 테스트 단계의 스테이징 환경으로 사용 할 수 있다.
- 롤링 배포
롤링 배포는 애플리케이션이 실행 중인 인프라를 완전히 교체하여 이전 버전의 애플리케이션을 새로운 버전의 애플리케이션으로 서서히 교체하는 배포 전략이다.
롤링 배포는 가용 자원이 제한적일 경우에 사용된다.
사용 중인 인스턴스(v1) 내에서 새 버전(v2)을 점진적으로 교체하게 된다.
- 롤링 배포의 장점
업그레이드 과정에서 문제가 발견되면 일반적으로 롤링 배포를 "reverse"로 이동하여 새 버전의 앱을 제거하고 이전 버전을 다시 시작할 수 있다.
Downtime이 없다.
- 롤링 배포의 단점
배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있다.
배포중인 서버는 서비스가 중단된 상태이기 때문에 서버 부하량을 체크하며 배포를 진행해야 한다.
- 카나리 배포
카나리 배포는 전체 인프라에 새로운 소프트웨어 버전을 릴리즈하여 모든 사용자가 사용할 수 있도록 하기 전에 변경 사항을 천천히 릴리즈함으로써 프로덕션 환경에 새로운 소프트웨어 버전을 도입하는 위험을 줄이는 전략이다.
블루 / 그린 배포와 유사하게 사용자가 라우팅되지 않는 인프라의 하위 집합에 새 버전의 소프트웨어를 배포하는 것으로 시작한다.
Canary Release는 잠재적 문제를 초기에 발견하여 전체 운영환경이나 사용자에게 영향을 미치는 것을 방지한다.
카나리 배포 방식
특정 서버에만 배포를 진행하여 오류 여부를 확인하고 문제가 없다면 모든 서버에 새로운 버전을 단계적으로 배포하는 방식이다.
- 카나리 배포 장점
문제 발생 시 먼저 배포가 진행되었던 서버만 롤백 하면 됨으로 비교적 롤백이 간편하다.
운영 환경에서 신규버전을 테스트 할 수 있다.
부하를 서서히 증가시키며 신규 버전이 운영 환경에서 어떠한 반응을 보이는지 모니터링 하고 수치를 측정할 수 있다.
특정 서버로 먼저 배포를 진행하기 때문에 문제 발생시 리스크가 비교적 적다.
====================================
참고 자료