배포란?
개발자가 작성한 코드를 빌드하고 빌드된 파일을 사용자가 접근할 수 있는 환경에 배치하는 것입니다.
(빌드를 하고 생성된 .jar or .war 파일을 WAS에 배치)
배포의 목적
당연히 사용자가 애플리케이션에 접근해 사용할 수 있게 하기 위해 아니야? 라고 생각하실 텐데요
추가로 다른 목적들도 알아보도록 하겠습니다.
- 새로운 기능이나 업데이트를 위한 배포
- 버그 수정 및 안정성 향상을 위한 배포
- 사용자의 요구사항 반영을 위한 배포
- 성능 및 보안 강화를 위한 배포
배포 과정
배포 계획
애플리케이션이 배포될 대상의 환경을 확인합니다.
- 개발환경 및 운영환경인지?
- 필요한 종속성 및 라이브러리가 설치되어 있는지?
- 배포될 대상이 맞는지?
빌드
개발자가 작성한 소스코드를 배포 가능한 단위로 패키징합니다.
테스트
위 빌드 단계중에 자동화된 테스트가 실행되어 코드가 의도한 대로 작동하고 지정된 요구 사항을 충족하는지 확인합니다.
배포
애플리케이션의 요구 사항과 조직의 요구 사항에 따라 블루-그린 배포, 카나리아 배포 또는 롤링 배포와 같은 배포 전략을 선택합니다.
자동화된 배포 도구 또는 스크립트를 사용하여 대상 환경에 애플리케이션을 배포합니다.
모니터링
모니터링 도구와 대시보드를 사용하여 애플리케이션의 상태와 성능을 모니터링합니다.
배포의 종류 및 전략(무중단 배포)
Rolling Deployment(롤링)
사용중인 인스턴스 내에서 새 버전을 점직적으로 교체하는 것으로 무중단 배포의 가장 기본적인 방식입니다.
서비스 중인 인스턴스 하나를 로드밸런서에서 라우팅하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅하도록 합니다.
이를 반복해 모든 인스턴스에 새 버전의 애플리케이션을 배포합니다.
Blue/Green 배포 방식은 인프라 리소스가 2배로 필요한데 비해, 롤링 업데이트 배포는 서버 자원이 한정적인 경우 유리합니다.
목표 : 중단 시간과 위험을 최소화 하면서 원활한 전환을 보장하는 것 입니다.
장점
인스턴스마다 차례로 배포를 진행하기에 상황에 따라 손쉽게 롤백이 가능합니다.
추가적으로 인스턴스를 늘리지 않아도 됩니다.
관리가 간편합니다.
버전의 업데이트와 테스트를 동시에 수행 할 수 있습니다.|구/신 버전이 공존하므로, 두 버전 모두 고려해 개발해야합니다.
단점
새 버전을 배포할때 인스턴스 수가 감소하기 때문에 사용중인 인스턴스에 트래픽이 몰릴 수 있습니다.
구/신 버전 사이 호환성 문제가 발생할 수 있습니다. (사용자가 균일한 서비스를 받지 못함)
세션 영속성에 대한 고려사항
(서버가 롤링 업데이트 상태로 넘어갈 때, 기존 서버에 접속하고 있던 사용자의 session을 신규 서버로 이전해야 한다. 업데이트가 종료된 서버나 업데이트 되지 않은 서버 모두에서 서비스를 이어갈 수 있도록 구성해야 합니다.)
Blue/Green Deployment(블루그린)
블루는 구 버전, 그린은 신 버전을 의미합니다.
운영중인 구 버전과 동일하게 신 버전의 인스턴스를 구성한 후 로드밸런서를 통해 모든 트래픽을 한번에 신 버전 쪽으로 전환하는 방식입니다.
목표 : 무중단 배포를 보장하고 빠른 롤백을 가능하게 하며 버전 간 명확한 구분을 제공합니다.
장점
구 버전의 인스턴스가 남아있어 손쉬운 롤백이 가능합니다.
구 버전의 환경을 다음 배포에 재사용할 수 있습니다.
운영환경에 영향을 주지 않고 신 버전 테스트가 가능합니다.(신 버전을 위한 인스턴스를 생성해 놓았으니...)
단점
구/신 버전을 위한 인스턴스를 각각 생성해 놓아야 하므로 시스템 자원이 두배로 필요합니다.
새로운 환경에 대한 테스트가 전제되어야합니다.
Canary Deployment(카나리)
옛 광부들이 가스에 민감한 카나리아 새를 이용해 가스 누출 위험을 감지했던 것에서 유래한 것으로 잠재적 문제 상황을 미리 발견하기 위한 방식입니다.
신 버전을 소수의 유저들 및 서버의 작은 하위 집합에게만 배포를 해보고 문제가 없는 것을 확인해가며 점차 많은 유저들에게 배포하는 방식입니다.
블루/그린 배포와 유사하지만 블루/그린 처럼 트래픽을 한번에 바꾸는 것이 아니라 단계적으로 전환하기에 부정적 영향을 최소화 하고 트래픽 양을 조절하며 롤백할 수 있습니다.
목표 : 더 많은 유저에게 영향을 미치기 전에 통제된 환경에서 문제나 이상을 식별하는 것입니다.
장점
전체 인프라에 영향을 미치기전에 문제를 식별할 수 있습니다.
잠재적인 문제에 노출되는 사용자 또는 요청의 수를 제한합니다.
A/B테스트1로 활용이 가능합니다.
1 : 대조군과 실험군으로 나누어 특정한 UI나 알고리즘의 효과를 비교하는 방법론
단점
잠재적인 문제를 식별하기 위해 메트릭을 면밀히 모니터링하고 분석해야 합니다.
소규모 그룹만 처음에 변경사항을 적용하므로, 모든 시나리오에는 적합하지않습니다.
배포 도구
자동화된 빌드 및 배포 프로세스를 사용하지 않는 경우(수동)
소규모 프로젝트나 애플리케이션에 대한 엄격한 규제 및 요구 사항이 있을 경우 사용하는 작업입니다.
-
CASE 1.
빌드 도구 및 IDE의 기능을 이용해 빌드를 한 후 생성된 jar, war 파일을 FileZilla를 이용해 해당 서버에 옮겨준 후 -> FTP, SFTP
PuTTY를 이용해 해당 서버에 옮겨진 새로운 jar, war 파일을 실행 시켜줍니다. -> SSH -
CASE 2.
필자가 사용하는 방법으로 IntelliJ Ultimate Edition의 내장된 '원격 호스트'기능을 이용하는 방법
자동화된 빌드 및 배포 프로세스를 사용하는 경우(자동)
도구와 스크립트를 활용하여 소프트웨어 업데이트의 배포 및 설치를 간소화하는 작업입니다.
-
CI/CD(지속적 통합/지속적 배포)
Jenkins, Travis CI, CircleCI 및 GitLab CI/CD와 같은 도구는 코드 빌드에서 배포까지 종단 간 자동화를 제공합니다.
이를 통해 파이프라인을 정의하고, 코드 변경 시 빌드를 트리거하고, 테스트를 실행하고, 다양한 환경에 배포할 수 있습니다. -
컨테이너 화
Docker 및 Kubernetes는 컨테이너화 및 오케스트레이션에 널리 사용되는 도구입니다.
컨테이너는 종속성과 함께 애플리케이션을 캡슐화하여 다양한 환경에서 일관성을 제공합니다.
Reference
https://jocoma.tistory.com/entry/IT-%EC%9A%A9%EC%96%B47-%EB%B0%B0%ED%8F%AC-%EB%B0%A9%EC%8B%9D-%EC%A2%85%EB%A5%98
https://llshl.tistory.com/47
https://bkjeon1614.tistory.com/707
https://velog.io/@jingrow/%EB%B8%94%EB%A3%A8%EA%B7%B8%EB%A6%B0-%EB%A1%A4%EB%A7%81-%EC%B9%B4%EB%82%98%EB%A6%AC-%EB%B0%B0%ED%8F%AC%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90%EA%B3%BC-%EC%96%B4%EB%96%A4-%EA%B2%BD%EC%9A%B0%EC%97%90-%EA%B0%81%EA%B0%81%EC%9D%98-%EB%B0%B0%ED%8F%AC%EB%B0%A9%EC%8B%9D%EC%9D%84-%EC%8B%9C%EB%8F%84%ED%95%98%EB%8A%94%EC%A7%80-%EC%A1%B0%EC%82%AC%ED%95%B4%EB%B3%B4%EC%84%B8%EC%9A%94
https://onlywis.tistory.com/10
Note
너무 깊게 들어가면 너무 방대해질까봐 조금은 라이트하게 기술하였습니다.
해당 포스트에 나온 기술들은 추후 자세히 포스팅 하도록 하겠습니다.
