9장에서 Travis CI를 활용해 배포 자동화 환경을 구축해 보았다.
하지만 배포하는 동안 애플리케이션이 종료된다는 문제가 남아있다.
긴 기간은 아니지만, 새로운 Jar가 실행되기 전까진 기존 Jar를 종료시켜 놓기 때문에 서비스가 중단됨.
반면 카카오톡 같은 서비스의 경우 배포하는 동안 서비스가 정지되지 않는다. 어떻게 서비스 중단 없이 배포를 걔속 할 수 있는지 이번장에서 해보자.
10.1 무중단 배포 소개
예전에는 배포라고 하면 팀의 아주 큰 이벤트이기 때문에 다 같이 코드를 합치는 날과 배포를 하는날을 정하고 진행하였다.
특히 배포일에는 사용자가 적은 새벽기간에 개발자들이 모두 남아 배포 준비를 해야만 했고 배포가 잦아질 때는 새벽마다 남아야했다.
더군다나 배포하고 나서 치명적인 문제가 발견된다면 새벽시간에 해결하다가 사용자 유입이 많아지는 아침이 되면 긴급점검을 공지하고 수정해야했다.
서비스를 정지하지 않고 배포할 수 있는 방법들을 찾기 시작했고 이를 무중단배포라고 한다.
무중단 배포 방식
- AWS에서 블루 그린(Blue-Green) 무중단 배포
- 도커를 이용한 웹서비스 무중단 배포
- L4 스위치를 이용한 무중단 배포
- L4가 워낙 고가의 장비이다 보니 대형 인터넷 기업외에는 쓸 일 없음.
- 엔진엑스(Nginx)
- 웹 서버, 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등을 위한 오픈소스 S/W
이전에 아파치가 대세였던 자리를 완전히 빼앗은 가장 유명한 웹서버이자 오픈소스이다.
엔진엑스가 가지고 있는 여러기능 중 리버스 프록시가 있다.
리버스 프록시
- 엔진엑스가 외부의 요청을 받아 백엔드 서버로 요청을 전달하는 행위
리버스 프록시 서버(엔진엑스)는 요청을 전달하고, 실제 요청에 대한 처리는 뒷단의 웹애플리케이션 서버가 처리
이것을 이용해 무중단 배포 환경을 구축해보자.
엔진엑스를 사용하는이유
- 저렵하고 쉽다.
구조
하나의 EC2 혹은 리눅스 서버에 엔진엑스 1대와 스프링 부트 Jar를 2대 사용한다.
운영 과정
1. 사용자는 서비스 주소로 접속(80혹은 443포트)
2. 엔진엑스는 사용자의 요청을 받아 현재 연결된 스프링 부트로 요청 전달(스프링 부트1 즉, 8081포트로 요청을 전달한다고 가정)
3. 스프링 부트2는 엔진 엑스와 연결된 상태가 아니니 요청받지 못한다.
1.1 버전으로 신규 배포가 필요하면, 엔진엑스와 연결되지 않은 스프링부트2(8082포트)로 배포한다.
운영과정
1. 배포하는 동안에도 서비스는 중단되지 않음.(엔진엑스는 스프링 부트1을 바라보기 때문)
2. 배포가 끝나고 정상적으로 스프링부트2가 구동하는지 확인
3. 스프링 부트2가 정상 구동중이면 nginx reload 명령어를 통해 8081대신 8082를 바라보도록 한다.
4. nginx reload 는 0.1초 이내에 완료됨.
이후 1.2 버전 배포가 필요하면 이번에는 스프링 부트1로 배포
1. 현재는 엔진엑스와 연결된 것이 스프링부트 2
2. 스프링 부트1의 배포가 끝났다면 엔진엑스가 스프링 부트 1을 바라보도록 변경하고 nginx reload 실행
3. 이후 요청부터는 엔진엑스가 스프링부트1로 요청 전달
무중단 배포 전 구조
10.2 엔진엑스 설치와 스프링부트 연동하기
책 참고
보안그룹에 80포트 추가
nginx config 재설정
각각 리다이렉션 url 에 8080포트 뺀 주소 추가
10.3 무중단 배포 스크립트 만들기
무중단 배포 스크립트 작업 전에 api를 하나 추가. 이 API 는 이후 배포시에 8081을 쓸지, 8082를 쓸지 판단하는 기준이 된다.
에러 발생
1. nginx error
step1 에가서 deploy.sh를 실행시켜줘야함
2. 테스트 에러
테스트의 application.properties에 oauth include 한 코드를 삭제시켜줘야함.
real1, real2, profile 생성
현재 EC2 환경에서 실행되는 profile은 real 밖에 없다. 해당 profile은 Travis CI 배포 자동화를 위한 profile이니 무중단 배포를 위한 profile 2개(real1, real2)를 src/main/resources 아래에 추가하자.
배포 스크립트 작성
먼저 step2와 중복되지 않기 위해 EC2에 step3 디렉토리 생성
무중단 배포는 앞으로 step3를 사용한다. appspec.yml 도 step3로 배포되게 수정
무중단 배포를 진행할 스크립트는 총 5개이다.
- stop.sh: 기존 엔진엑스에 연결되어 있진 않지만, 실행 중이던 스프링 부트 종료
- start.sh: 배포할 신규버전 스프링 부트 프로젝트를 step.sh로 종료한 'profile'로 실행
- helth.sh: 'start.sh'로 실행시킨 프로젝트가 정상적으로 실행됐는지 체크
- switch.sh: 엔진엑스가 바라보는 스프링부트를 최신버전으로 변경
- profile.sh: 앞선 4개 스크립트 파일에서 공용으로 사용할 'profile'과 포트 체크 로직
스크립트를 모두 작성하자!
10.4 무중단 배포 테스트
배포 테스트를 하기전, 한가지 추가 작업을 진행하자. 잦은 배포로 Jar 파일명이 겹칠 수 있다. 매번 버전을 올리는 것이 귀찮으므로 자동으로 버전값이 변경
이제 이 시스템은 마스터 브랜치에 푸시가 발생하면 자동으로 서버 배포가 진행되고, 서버 중단 역시 전혀없는 시스템이 되었다.
이번 장에서 배운것
- 무중단 배포 소개
- 웹 서버이자 로드 밸런서의 역할을 하는 엔진엑스에 대한 소개
- 엔진엑스를 이요한 무중단 배포 방법
- source 명령어를 이용한 쉘 스크립트 파일 import 방법
'Spring > 스프링부트와 AWS로 혼자구현하는 웹 서비스' 카테고리의 다른 글
| CI / CD 란? (0) | 2023.02.25 |
|---|---|
| 섹션9. 코드가 푸시되면 자동으로 배포해 보자 - Travis CI 배포 자동화 (0) | 2023.02.12 |
| 섹션8. EC2 서버에 프로젝트를 배포해 보자. (0) | 2023.02.06 |
| 섹션7. AWS RDS (1) | 2023.02.05 |
| 섹션 6. AWS 서버 환경을 만들어보자 - AWS EC2 (0) | 2023.01.30 |
9장에서 Travis CI를 활용해 배포 자동화 환경을 구축해 보았다.
하지만 배포하는 동안 애플리케이션이 종료된다는 문제가 남아있다.
긴 기간은 아니지만, 새로운 Jar가 실행되기 전까진 기존 Jar를 종료시켜 놓기 때문에 서비스가 중단됨.
반면 카카오톡 같은 서비스의 경우 배포하는 동안 서비스가 정지되지 않는다. 어떻게 서비스 중단 없이 배포를 걔속 할 수 있는지 이번장에서 해보자.
10.1 무중단 배포 소개
예전에는 배포라고 하면 팀의 아주 큰 이벤트이기 때문에 다 같이 코드를 합치는 날과 배포를 하는날을 정하고 진행하였다.
특히 배포일에는 사용자가 적은 새벽기간에 개발자들이 모두 남아 배포 준비를 해야만 했고 배포가 잦아질 때는 새벽마다 남아야했다.
더군다나 배포하고 나서 치명적인 문제가 발견된다면 새벽시간에 해결하다가 사용자 유입이 많아지는 아침이 되면 긴급점검을 공지하고 수정해야했다.
서비스를 정지하지 않고 배포할 수 있는 방법들을 찾기 시작했고 이를 무중단배포라고 한다.
무중단 배포 방식
- AWS에서 블루 그린(Blue-Green) 무중단 배포
- 도커를 이용한 웹서비스 무중단 배포
- L4 스위치를 이용한 무중단 배포
- L4가 워낙 고가의 장비이다 보니 대형 인터넷 기업외에는 쓸 일 없음.
- 엔진엑스(Nginx)
- 웹 서버, 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등을 위한 오픈소스 S/W
이전에 아파치가 대세였던 자리를 완전히 빼앗은 가장 유명한 웹서버이자 오픈소스이다.
엔진엑스가 가지고 있는 여러기능 중 리버스 프록시가 있다.
리버스 프록시
- 엔진엑스가 외부의 요청을 받아 백엔드 서버로 요청을 전달하는 행위
리버스 프록시 서버(엔진엑스)는 요청을 전달하고, 실제 요청에 대한 처리는 뒷단의 웹애플리케이션 서버가 처리
이것을 이용해 무중단 배포 환경을 구축해보자.
엔진엑스를 사용하는이유
- 저렵하고 쉽다.
구조
하나의 EC2 혹은 리눅스 서버에 엔진엑스 1대와 스프링 부트 Jar를 2대 사용한다.
운영 과정
1. 사용자는 서비스 주소로 접속(80혹은 443포트)
2. 엔진엑스는 사용자의 요청을 받아 현재 연결된 스프링 부트로 요청 전달(스프링 부트1 즉, 8081포트로 요청을 전달한다고 가정)
3. 스프링 부트2는 엔진 엑스와 연결된 상태가 아니니 요청받지 못한다.
1.1 버전으로 신규 배포가 필요하면, 엔진엑스와 연결되지 않은 스프링부트2(8082포트)로 배포한다.
운영과정
1. 배포하는 동안에도 서비스는 중단되지 않음.(엔진엑스는 스프링 부트1을 바라보기 때문)
2. 배포가 끝나고 정상적으로 스프링부트2가 구동하는지 확인
3. 스프링 부트2가 정상 구동중이면 nginx reload 명령어를 통해 8081대신 8082를 바라보도록 한다.
4. nginx reload 는 0.1초 이내에 완료됨.
이후 1.2 버전 배포가 필요하면 이번에는 스프링 부트1로 배포
1. 현재는 엔진엑스와 연결된 것이 스프링부트 2
2. 스프링 부트1의 배포가 끝났다면 엔진엑스가 스프링 부트 1을 바라보도록 변경하고 nginx reload 실행
3. 이후 요청부터는 엔진엑스가 스프링부트1로 요청 전달
무중단 배포 전 구조
10.2 엔진엑스 설치와 스프링부트 연동하기
책 참고
보안그룹에 80포트 추가
nginx config 재설정
각각 리다이렉션 url 에 8080포트 뺀 주소 추가
10.3 무중단 배포 스크립트 만들기
무중단 배포 스크립트 작업 전에 api를 하나 추가. 이 API 는 이후 배포시에 8081을 쓸지, 8082를 쓸지 판단하는 기준이 된다.
에러 발생
1. nginx error
step1 에가서 deploy.sh를 실행시켜줘야함
2. 테스트 에러
테스트의 application.properties에 oauth include 한 코드를 삭제시켜줘야함.
real1, real2, profile 생성
현재 EC2 환경에서 실행되는 profile은 real 밖에 없다. 해당 profile은 Travis CI 배포 자동화를 위한 profile이니 무중단 배포를 위한 profile 2개(real1, real2)를 src/main/resources 아래에 추가하자.
배포 스크립트 작성
먼저 step2와 중복되지 않기 위해 EC2에 step3 디렉토리 생성
무중단 배포는 앞으로 step3를 사용한다. appspec.yml 도 step3로 배포되게 수정
무중단 배포를 진행할 스크립트는 총 5개이다.
- stop.sh: 기존 엔진엑스에 연결되어 있진 않지만, 실행 중이던 스프링 부트 종료
- start.sh: 배포할 신규버전 스프링 부트 프로젝트를 step.sh로 종료한 'profile'로 실행
- helth.sh: 'start.sh'로 실행시킨 프로젝트가 정상적으로 실행됐는지 체크
- switch.sh: 엔진엑스가 바라보는 스프링부트를 최신버전으로 변경
- profile.sh: 앞선 4개 스크립트 파일에서 공용으로 사용할 'profile'과 포트 체크 로직
스크립트를 모두 작성하자!
10.4 무중단 배포 테스트
배포 테스트를 하기전, 한가지 추가 작업을 진행하자. 잦은 배포로 Jar 파일명이 겹칠 수 있다. 매번 버전을 올리는 것이 귀찮으므로 자동으로 버전값이 변경
이제 이 시스템은 마스터 브랜치에 푸시가 발생하면 자동으로 서버 배포가 진행되고, 서버 중단 역시 전혀없는 시스템이 되었다.
이번 장에서 배운것
- 무중단 배포 소개
- 웹 서버이자 로드 밸런서의 역할을 하는 엔진엑스에 대한 소개
- 엔진엑스를 이요한 무중단 배포 방법
- source 명령어를 이용한 쉘 스크립트 파일 import 방법
'Spring > 스프링부트와 AWS로 혼자구현하는 웹 서비스' 카테고리의 다른 글
| CI / CD 란? (0) | 2023.02.25 |
|---|---|
| 섹션9. 코드가 푸시되면 자동으로 배포해 보자 - Travis CI 배포 자동화 (0) | 2023.02.12 |
| 섹션8. EC2 서버에 프로젝트를 배포해 보자. (0) | 2023.02.06 |
| 섹션7. AWS RDS (1) | 2023.02.05 |
| 섹션 6. AWS 서버 환경을 만들어보자 - AWS EC2 (0) | 2023.01.30 |
