Load Balancer와 배포방식의 기초

Load Balancer

• "대량 트래픽에 의한 서버 부담을 분산하는 방법"
• 단 한개의 웹 서버를 통해 WAS를 제공하는 경우 두가지 문제가 생김
  1. 가용성 문제: 대량의 트래픽이 한개의 웹 서버로 집중되는 경우
     • 한개의 웹 서버가 트래픽을 감당하지 못해 터져버린다
       • 수직적 확장 | 수평적 확장이 필요하다
  2. 새 버전의 웹 어플리케이션 배포 시
     • 새로운 웹 서버에 배포하는 경우 IP가 변경된다
       • IP가 바뀌면 서버를 잃어버리게 된다
     • 기존의 웹 서버에 배포하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저가 사용할 수 없음

How?

• LB를 웹 서버의 앞단에 두고, IP를 부여한 뒤 웹 Client가 해당 LB를 호출하게 한다
  • 트래픽 처리에 대한 짐을 분산 시켜줌
  • LB는 앞단의 모든 Web Client의 요청을 받아 뒷단의 모든 웹 서버에게 요청을 분산한다
    • 배포 이슈 해결: Client는 고정된 IP의 LB만 호출하기에 Web Server가 몇개든 죽든말든 상관이 없다
    • 트래픽 이슈 해결: 아무리 많은 요청이 들어와도 LB 뒷단에 서버 수만 늘리면 된다 (= 수평적 확장)
      

      

LB vs API Gateway

• API Gateway: 어떤 서버에 어떤 요청을 해야하는지 알고 있음
  • "기차가 왔을때 다른 라인으로 보내는 역할"
  • "서비스와 서비스를 연결시켜주는 역할"
• LB: Traffic이 왔을때 Service Cluster에 분산시키는 역할
  • 서비스의 단위이다
  • 서버의 상태를 검사하는 Health Checker가 있음
    • Instance가 정상인지 계속 확인함
  • 항상 고정된 IP를 가지고 있음
    • 재배포라는 개념이 없음
    • Public IP가 직접 부여가 된다
  • Re-platform할때 LB를 사용해 위험도를 나열해 가장 낮은 위험도를 가진 API부터 옮김

---

배포 방식

• LB의 등장으로 인해 수평적 확장으로 다수의 웹 서버를 한번에 운용할 수 있게 되었다
  • Web Application의 버전을 바꾸기 위해 재배포를 할때 단 하나의 웹 서버만 바꾸는 것이 아니라
  • 모든 다수의 웹 서버를 새로운 버전을 바꾸는 재배포를 해야해서 관련된 전략들이 등장하였다
• 배포의 종류
  • Rolling:
    • 점진적으로 서버를 Upgrade함
      • 구버전 하나 죽이고 -> 신버전 하나 죽이고 -> 반복...
    • 버전 간 트래픽이 섞이지 않는다
      • 서버를 죽이기 전에 트래픽을 옮긴다
      • 가지고있는 Instance에서 죽이고 띄우고 한다
        • 비용 발생이 없음
        • 가용성이 좋음
          

          

    • 단점:
      • 트래픽이 한방향이다
        • 이후에 다룰 예정
    • 배포방식이 명시되지않으면 Default Method
    • Rolling with Additional Batches
      • 가용성을 해치지 않게 하기 위한 서버를 하나 더 추가함
      • 새로운 버전이 생기면 그쪽으로 트래픽을 분산함
        

        

      1. Create new server
      2. Deploy code to new batch of instances
      3. Stop few Instances which are running older version of the code
      4. Deploy new version of the code and start
         5 and 6. Repeat step 3 and 4 with other set of instances
      5. Terminate additional batch of instances
      • 장점:
        • Good for production as Application is running at Capacity
      • When to use it?
        • Ok to have small Additional cost
        • Ok to have longer deployment times
    • Rolling with Immutable (불변성)
      • 어떤것에도 영향을 끼지지 않겠다!
      • ASG (Auto Scaling Group)을 만들어서 Rolling을 수행한다
      • 이후에 다룰 예정

• Canary:
  • 신버전 테스트 후 -> 신버전 전체 전환
    • 먼저 새로운 버전을 시도해본 후, 괜찮으면 전환한다
  • 장점:
    • 테스트에 굉장히 용이하다
  • 단점:
    • 오래걸린다
  • 특징:
    • 버전간 트래픽이 섞인다
    • 테스트에 용이하다
      • ex.) A/B Test: A안과 B안을 동시에 테스트함
        • "유저대상 사회실험"
        • 트래픽을 9대1로 나눠 1로 테스트를 진행함
          

          

• Blue-Green:
  • "미리 끼워놓고 기다린다"
    • 한번에 바로 전환시킨다
  • 그룹을 기준으로 구버전 / 신버전 구별하여, 문제 발생 시 즉시 롤백이 가능하다
  • 장점:
    • 전환이 빠르다
    • 문제 발생 시 Rollback에 용이하다
  • 단점:
    • 비용이 많이 든다
      • 같은 서버가 두개나 필요하다
        

        

        
        

        

  • 일반적으로 Canary + Blue-Green 방식을 합쳐 배포하며, Blue-Green이 Canary 개념을 내포하기도 한다
    • 두 전략의 장점만 합쳐 혼합 사용하는 경우
      • 장점: 테스트에 용이함 + 빠른 트래픽 전환