[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 새로운 코드 배포의 위험 줄이기

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

---

 🚀코드 배포 위험 줄이기:
Blue/Green Deployment로 안전하게

클라우드 플랫폼으로 전환하면서 코드 배포의 위험을 줄이는 방법을 고민합니다. 그중 하나가 바로 Blue/Green Deployment입니다. 이 글에서는 Blue/Green Deployment가 무엇인지, 어떻게 배포 위험을 줄이는지 쉽게 이해할 수 있도록 설명하겠습니다.

---

🔧 Blue/Green Deployment란 무엇일까?

• 새로운 코드 버전을 배포할 때 기존 버전과 새 버전을 함께 운영하는 Blue/Green Deployment 방식을 도입합니다.
  이 방식은 마치 무대 위에서 두 배우가 준비된 것과 비슷합니다. 한 명(Blue, 기존 버전)은 현재 공연 중이고, 다른 한 명(Green, 새 버전)은 옆에서 대기 중입니다.
• v1(Blue)이 현재 서비스를 제공하고 있을 때, v2(Green)를 프로덕션 환경에 함께 배포합니다.
  이렇게 하면 새 버전을 실제 환경에서 테스트할 수 있으면서도 기존 버전은 안정적으로 동작합니다.

Blue/Green Deployment는 기존 버전(Blue)과 새 버전(Green)을
동시에 운영해 배포 위험을 줄이는 전략입니다.

---

🔄 트래픽 전환으로 안전한 배포

• 새로운 버전이 준비되면 트래픽을 v1(Blue) 에서 v2(Green) 으로 전환합니다.
  만약 v2에 문제가 생기면? => 다시 v1으로 트래픽을 돌리면 됩니다. 이렇게 하면 서비스 중단 없이 빠르게 문제를 해결할 수 있습니다.
• 예를 들어, 새로운 기능을 추가한 v2가 제대로 작동하지 않는다면, 즉시 v1으로 롤백해 안정적인 서비스를 유지합니다. 이 방식은 배포 중 발생할 수 있는 장애를 최소화하는 강력한 방법입니다.

트래픽을 Green으로 전환하고,
문제가 생기면 Blue로 롤백해 서비스 안정성을 유지합니다.

---

⚠️ Blue/Green Deployment의 한계: Big Bang Release

• Blue/Green Deployment는 한 가지 아쉬운 점이 있습니다.
  트래픽을 v1에서 v2로 전환하는 순간, 모든 코드 변경 사항이 한꺼번에 적용됩니다. 이를 Big Bang Release라고 부르는데, 이 과정에서 예상치 못한 문제가 발생할 가능성이 여전히 존재합니다.
• 이 문제를 해결하려면 배포와 릴리스의 개념을 명확히 이해해야 합니다.
  배포(Deployment)는 새로운 코드를 프로덕션 환경에 올리는 과정이고,
  릴리스(Release) 는 그 코드를 실제 고객에게 제공하는 과정입니다.
  Blue/Green Deployment는 배포를 안전하게 하지만, 릴리스 과정에서 여전히 위험이 있을 수 있습니다.

Blue/Green Deployment는 배포를 안전하게 하지만,
Big Bang Release로 인해 릴리스 시 위험이 남아 있습니다.

---

📊 Blue/Green Deployment의 장점과 한계 요약

• Blue/Green Deployment는 코드 배포의 위험을 줄이는 강력한 도구입니다. 하지만 모든 변경 사항을 한 번에 릴리스하는 방식은 여전히 위험을 내포하고 있습니다.
  이를 보완하려면 Canary Release나 Feature Toggles 같은 추가 전략을 고려할 수 있습니다. 이런 방법들은 변경 사항을 점진적으로 적용해 위험을 더욱 줄입니다.

Blue/Green Deployment는 배포 위험을 줄이지만,
점진적 릴리스 전략과 함께 사용하면 더 안전합니다.

---

🎯핵심 요약

• Blue/Green Deployment를 통해 코드 배포의 위험을 줄였습니다.
• 기존 버전(Blue)과 새 버전(Green)을 동시에 운영하며, 트래픽 전환으로 안전하게 새 버전을 릴리스합니다.
• 문제가 생기면 즉시 롤백해 서비스 안정성을 유지합니다. 하지만 Big Bang Release로 인해 릴리스 시 위험이 남아 있으므로, 점진적 릴리스 전략을 추가로 고려해야 합니다. 이를 통해 배포와 릴리스 과정을 더욱 안전하고 효율적으로 만들 수 있습니다.

---

🚀배포와 릴리스:
코드 배포 위험을 줄이는 전략 

---

🛠️ Deployment: 프로덕션에 코드 설치하기

• 현재 Catalog Service v1이 프로덕션에서 잘 운영되고 있습니다. 새로운 기능을 추가한 v1.1을 배포하려면, 먼저 Continuous Integration 시스템으로 코드를 빌드하고, Pre-production 환경에서 테스트합니다. 모든 검증과 승인이 완료되면, 드디어 v1.1을 프로덕션에 배포합니다.
• 하지만 프로덕션에 배포한다고 해서 바로 사용자 트래픽을 받는 건 아닙니다.
  Deployment는 새로운 코드를 서버나 컨테이너 같은 프로덕션 자원에 설치하는 과정일 뿐, 아직 사용자 요청은 받지 않습니다. 이 상태에서 Smoke Test를 진행하거나 Metrics와 Logging을 통해 새 버전이 제대로 작동하는지 확인합니다.

Deployment는 새 코드를 프로덕션에 설치하지만,
사용자 트래픽은 받지 않아 서비스에 영향을 주지 않습니다.

---

🚦 Release: 사용자에게 새 코드 노출하기

• 코드가 프로덕션에 배포된 후, 이제 Release를 결정할 차례입니다. Release는 새로운 코드에 사용자 트래픽을 보내는 과정입니다. 하지만 모든 사용자에게 한 번에 코드를 공개하는 대신, 점진적으로 진행하면 위험이 줄어듭니다.
• 먼저 내부 직원들에게만 v1.1을 노출합니다. 직원들은 새 버전을 사용하면서 Logging과 Metrics를 통해 코드의 동작을 관찰합니다. 문제가 없으면 점차 더 많은 사용자에게 공개합니다. 이 과정은 마치 광산에서 카나리아를 보내 위험을 확인하는 것과 비슷해 Canary Release라고 불립니다.

Release는 새 코드에 사용자 트래픽을 점진적으로 보내는 과정으로,
Canary Release를 통해 위험을 줄입니다.

---

🐤 Canary Release: 소규모로 안전하게 테스트

• Canary Release는 소수의 사용자에게 새 버전을 먼저 공개하는 전략입니다.
  예를 들어, v1이 여전히 대부분의 트래픽을 처리하는 동안, v1.1은 소량의 트래픽만 받습니다. 이 과정에서 문제가 발견되면 즉시 트래픽을 v1으로 돌려 롤백할 수 있습니다.
• 만약 v1.1의 성능과 기능이 만족스럽다면,  점차 더 많은 사용자에게 새 버전을 공개합니다. 

Canary Release는 소규모 사용자에게 새 버전을 테스트해
문제를 조기에 발견하고 롤백할 수 있게 합니다.

---

📈 점진적 릴리스와 롤백: 위험 최소화

• 릴리스는 점진적으로 진행됩니다. 사용자 그룹을 확대하면서 새 코드의 동작을 계속 관찰합니다.
  모든 고객이 v1.1을 사용하게 될 때까지 이 과정을 반복합니다. 하지만 언제든 예상치 못한 문제가 생기면, 트래픽을 v1으로 돌려 롤백할 수 있습니다.
• 과거 Rolling Upgrade 방식을 사용했는데, 새 버전이 배포되자마자 바로 트래픽을 받았습니다. 이 방식은 버그나 문제를 사용자에게 바로 노출시켜 위험했습니다.
  Deployment와 Release를 분리함으로써 사용자에게 새 코드를 더 안전하게 제공할 수 있게 되었습니다.

점진적 릴리스와 롤백은 새 코드의 문제를 최소화하며,
Deployment와 Release 분리는 위험을 줄입니다.

---

🎯핵심 요약

• Deployment와 Release를 분리해 코드 배포의 위험을 줄였습니다.
• Deployment는 새 코드를 프로덕션에 설치하지만 트래픽은 받지 않고, Release는 점진적으로 사용자에게 트래픽을 보내는 과정입니다.
• Canary Release를 통해 소규모 사용자에게 먼저 테스트하고, 문제가 생기면 롤백해 안정성을 유지합니다. 이 방식은 과거의 Rolling Upgrade보다 훨씬 안전하며, Metrics와 Logging으로 코드 동작을 관찰해 신뢰도를 높입니다. Istio 같은 도구를 사용하면 트래픽 제어를 통해 릴리스 위험을 더욱 줄일 수 있습니다.

---