Merge pull request #539 from Meet-Coder-Study/byungwoo

[#528] 무중단 배포전략의 종류
Meet-Coder-Study · Feb 24, 2021 · 4dd02a8 · 4dd02a8
2 parents 267f0a5 + 8aa113d
commit 4dd02a8
Show file tree

Hide file tree

Showing 2 changed files with 93 additions and 0 deletions.
diff --git a/byungwoo/2021-02-18-deployment-strategy.md b/byungwoo/2021-02-18-deployment-strategy.md
@@ -0,0 +1,93 @@
+# 무중단 배포전략의 종류
+
+## 무중단 배포
+
+배포란 "빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일"이다.
+
+MSA(Microservices Architecture)가 늘어나면서 다양한 배포전략이 생겨나고 있고 심지어 무중단 배포가 현재는 거의 표준으로 자리잡고 있다.
+
+무중단 배포란 서버를 실제로 서비스할 때 서비스적 장애와 배포에 있어서 부담감을 최소화할 수 있게끔 서비스가 중단되지 않고도 코드를 배포할 수 있는 기술이다.
+
+무중단 배포의 반대는 중단 배포이다. 가끔 어떤 웹사이트에 접속하면 "작업중이니 사이트 이용이 불가하다"는 안내창을 본 적이 있을 것이다. 장애상황일 수도 있겠지만 배포의 관점에서 보면 해당 웹사이트에는 중단 배포가 일어난다고 볼 수 있다.
+
+과거에는 배포를 하기 위해서 담당자들이 서비스 유입이 적은 야간이나 새벽 시간 대에 작업을 하였지만 현재에는 일반적인 업무시간 내에 배포와 함께 필요시 롤백을 하는 방식으로 변하고 있다.
+
+소프트웨어 분야를 제외하더라도 무중단 배포는 우리의 일상생활에 깊숙히 스며들어 있다.
+
+![road-construction.jpg](images/road-construction.jpg)
+
+위의 사진은 도로공사 현장이다. 도로공사 현장에서 일부 차선만을 개방하거나 우회로를 안내하는 방식은 무중단 배포를 하는 것과 유사하다고 볼 수 있다. 
+
+다시 말해서 원활한 교통흐름을 위해서는 도로에는 항상 일정한 통행이 보장되어야 하기 때문에 불가피한 경우가 아니라면 교통흐름을 방해하지 않고 이렇게 일부 차선을 개방하거나 우회로를 안내하는 "무중단" 방식의 작업이 필요하다. 더불어 주간에 작업할 경우 작업자들이 보다 "안전한" 환경에서 예상치 못한 상황에 대응할 수 있다.
+
+## 서버 이중화
+
+무중단 배포는 반드시 "서버 이중화" 상태에서 수행할 수 있다.
+
+서버 이중화란 다음과 같이 로드밸런서를 앞에 두고 한 대 이상의 동일한 서버가 트래픽을 분산하는 것을 말한다.
+![server-duplicate.png](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Ft1.daumcdn.net%2Fcfile%2Ftistory%2F2332684E583157AD06)
+
+서버 이중화는 다음의 두 가지 큰 목적을 가지고 있다.
+
+첫 번째는 Failover(시스템 대체 작동)이며 두 번째는 Load Balance(부하균등)이다.
+
+Failover란 평소 사용하는 서버와 동일한 서버를 구축하여 하나의 서버가 장애로 사용이 어렵게 될 경우 대체 서버를 활용하여 중단없이 서비스를 제공 할 수 있게 하는 것이다.
+
+LoadBalance란 로드밸런서를 통해서 하나에 서버에 가해지는 부하를 분산시켜서 한 서버에 너무 많은 부하가 걸리거나 병목이 걸리지 않도록 하는 것이다.
+
+## 무중단 배포전략의 종류
+### 롤링 업데이트(Rolling Update)
+![rolling-updates.png](https://t1.daumcdn.net/cfile/tistory/99143F435C87397A09)
+
+롤링 업데이트란 구 버전에서 신 버전으로 하나씩 업데이트 방식을 말한다. 서버 전체의 개수를 N이라고 할 때 구 버전과 신 버전의 비율은 N-K:K이며 N:0에서 시작하여 0:N 비율로 가는 것을 목표로 한다. 배포를 위한 인프라 리소스 확보가 어려울 경우 사용하기에 적합하다.
+
+- 장점
+  - 배포를 위한 추가적인 인프라 리소스를 요구하지 않는다.
+- 단점
+  - 배포 중에는 인스턴스 수가 감소되므로 서버 처리 용량을 고려해야 한다. 
+  - 구 버전과 신 버전이 공존하는 시기가 있으므로 구 버전을 모두 고려하여 개발해야 한다. 예를 들어 데이터베이스 스키마에 큰 변화를 주기 어렵다.
+  - 세션을 사용할 경우 기존 서버에 접속하고 있는 사용자의 세션에 대한 고려가 필요하다.
+
+
+### 블루/그린(Blue/Green) 
+![blue-green.png](https://t1.daumcdn.net/cfile/tistory/99A68F4E5C8739470D)
+
+구 버전과 신 버전을 동시에 배포한 상태에서 로드밸런서에서 트래픽을 "일제히" 신 버전을 바라보게 하는 방식이다.
+롤백이 빠르지만 시스템 자원이 최소 두배 이상 필요하다.
+
+- 장점
+  - 신규 버전에 문제 발생시 빠른 롤백이 가능하다.
+- 단점
+  - 인프라 리소스가 2배로 들어간다.
+  - 기존 운영되고 있는 서버에서 Long-term 트랜잭션이 수행중이었다면 전환시 어떤 방식으로 처리할 지 충분한 고려가 필요하다.
+
+[레드/블랙(Red/Black) 배포라고 표현하기도 한다.](https://octopus.com/blog/blue-green-red-black)
+
+### 카나리(Canary)
+![canary.png](https://t1.daumcdn.net/cfile/tistory/9946A3495B0DDDB12E)
+
+카나리아라는 새에서 유래한 배포방식이다. 옛날이 광부들이 광산에서 유독가스가 나오는 것을 알아내기 위해 가스에 민감한 카나리아를 광산에서 키웠다고 한다. 카나리아가 죽으면 유독가스가 나오는 것으로 판단하고 조치를 취했다고 하는데, 이 개념을 배포전략에 차용한 것이 카나리 배포이다.
+
+![canary-deployment.png](https://t1.daumcdn.net/cfile/tistory/99E6E74C5C8737EC0E)
+
+새로운 버전이 운영환경에 적합한지 시험하는 배포 전략이다. 카나리 버전에 일부의 트래픽을 주어서 검증 후에 트래픽을 늘려가면서 신규 버전을 늘려나간다. 카나리 버전으로 가는 트래픽은 단순히 비율뿐만 아니라 랜덤 혹은 사용자의 특정 프로필을 기반으로 라우팅할 수 있다.
+
+- 장점
+    - 배포한 카나리 버전으로 용량/부하산정 테스트(Load/Capacity Testing)과 A/B 테스트를 진행할 수도 있다.
+    - 카나리 버전을 테스트하는 초기 단계에서는 롤백이 용이하다.
+- 단점
+    - 모니터링하는 시간이 중간에 포함되기 때문에 배포가 진행되는 작업시간이 길어진다.
+
+
+### [참고] A/B 테스트 
+![ab-testing.png](https://t1.daumcdn.net/cfile/tistory/993F14395A92BE330A) 
+
+A/B 테스트란 서로 다른 두 가지 버전의 유용성, 인기도, 안정성 등을 테스트하는 방법론이다. 카나리 배포와 유사하나 목적이 사용자 테스트에 있기 때문에 배포전략이라기 보다는 테스팅 방법론이라고 보아야 한다.
+
+## 참고
+- https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/
+- https://thefif19wlsvy.tistory.com/22
+- https://reference-m1.tistory.com/211
+- https://jason-lim.tistory.com/3
+- https://itwiki.kr/w/%EC%B9%B4%EB%82%98%EB%A6%AC_%EB%B0%B0%ED%8F%AC
+
diff --git a/byungwoo/images/road-construction.jpg b/byungwoo/images/road-construction.jpg