글로벌 애플리케이션 분산과 스테이지

쿠버네티스 모범 사례을 요약한 내용입니다.

애플리케이션의 규모를 글로벌 수준으로 늘리는 데는 여러가지 이유가 있습니다.

• 확장성
  • 애플리케이션이 성공하여 전세계의 사용자에게 배포될 때
  • 공개 클라우드 공급자의 글로벌 API 게이트웨이, 대규모 IoT, SNS 등
• 지역성
  • 대역폭이나 데이터 프라이버시의 이유로 특정 리전에 배치해야하는 경우

쿠버네티스를 사용하더라도 빛의 속도를 따라갈 수 없기 때문에 레이턴시를 최소화 하기 위해서는 애플리케이션을 전세계에 분산하여 사용자와 물리적인 거리를 좁혀야 합니다.

글로벌 리전을 관리하고 안정적으로 서비스를 롤아웃 하는 것은 대단히 어렵습니다.

7.1 이미지 분산

• 전 세계 클러스터에서 애플리케이션을 실행하기 위해서는 전 세계의 리전에서 이미지를 사용할 수 있어야 함
  • 이미지 레지스트리가 자동 리전 복제 기능을 가져야 함
  • 클라우드 공급자의 이미지 레지스트리는 이미지를 전세계에 자동으로 배포하여 해당 이미지를 풀하려는 클러스터는 가장 가까운 스토리지에서 해결 할 수 있음
  • 리전 복제를 제공하는 클라우드 레지스트리를 사용하면 이미지를 전세계에 간단하게 분산시킬 수 있음
• 클라우드 레지스트리가 없거나 공급자가 자동 리전 복제를 제공하지 않는다면 스스로 문제를 해결 해야함
  • 특정 리전의 단일 레지스트릴 사용하려면 몇가지 고려사항이 있음
    • 클러스터 구동시간에 영향을 줌
    • CI/CD 파이브라인에 영향을 줌
• 단일 레지스트리에서의 또 다른 고민은 단일 장애점
  • 해당 데이터 센터의 대규모 사고로 인해 레지스트리가 오프라인 상태로 전환될 수 있음
    • CI/CD 파이프라인은 멈춤
    • 새로운 코드 배포 할 수 없음
    • 생산성과 운영에 심각한 영향을 미치게 됨
  • 새로운 컨테이너를 구동할 때마다 상당한 대역폭을 사용함으로 레지스트리 비용도 커짐</aside>
  • <aside> ❓ 이건 단일 레지스트리를 사용할때만 인가??
• 소수의 리전에 실행할 때는 단일 레지스트리 방식이 적합한 해결책임
  • 설치도 완전한 이미지를 복제하는 것보다 간단함
• 클라우드의 리전 복제를 사용할 수 없다면 이미지를 복제하기 위한 방법을 직접 고안해야함
  • us.my-registry.io, eu.my-registery.io 등 이미지 레지스트리에 리전 이름을 사용하는 방법
    • 설정과 관리가 편한 장점이 있음
  • 레지스트리는 독립적이며 CI/CD파이프라인 마지막에 있는 모든 레지스트리에 이미지를 푸쉬할 수 있음
    • 각 클러스터가 가장 가까운 리전에서 이미지를 풀하려면 설정을 바꿔야하는 단점
    • 보통은 설정 안에 리전마다 차이가 존재할 것이므로 상대적으로 간단히 해결 가능

7.2 배포 파라미터화

• 배포할 리전에 맞춰 애플리케이션 설정이 달리질 것임
  • 리전 복제 리스트가 없다면 리전별로 이미지 이름을 바꿔야 함
  • 리전에 따라 부하가 달라질 수 있으므로 크기(레플리카 수)나 설정도 변경해야함
  • 복잡성을 편리하게 관리하는 것이 글로벌 애플리케이션의 성공의 핵심 요소
• 디스크 설정 관리 방법을 살펴 보기
  • 글로벌 리전별로 다른 디렉터리를 사용
  • 템플릿 기반 접근 방식이 좋은 아이디어
    • 공통 설정이 달라질 수 있기 때문에 템플릿 기반으로 가는 것이 좋음
  • 매개변수를 템플릿에 적용하면 지역에 특화된 설정을 생성할 수 있음

7.3 글로벌 트래픽 로드 밸런스

• 리전의 근접성을 최대한 이용해 서비스 레이턴시를 낮추려고 시도 해야함
  • 운영 중단이나 기타서비스 장애가 발생했을때 다른 리전에서 트래픽을 처리
• 다양한 리전의 디플로이먼트에 대한 트래픽 밸런스를 올바르게 설정하는 것이 시스템의 성능과 안정성을 위한 핵심
• 서비스를 위한 단일 호스트명 myapp.myco.com이 존재한다고 가져하면 먼저 결정해야할 사항은 DNS 프로토콜을 사용하여 여러 리전 엔드포인트 간의 로드 밸런싱을 할지 여부 입니다.
• DNS를 사용하면 사용자가 myapp.myco.com로 DNS 질의를 할 때 IP주소가 반환됩니다. 이 주소는 서비스에 접근하는 사용자의 위치와 현재 가용한 서비스의 위치에 따라 달라집니다.

7.4 안정적인 글로벌 롤아웃

• 글로벌 롤아웃의 일반적인 목표는 가능한 빠르게 출시하는 동시에 문제가 발생하면 신속하게 감지하는 것
• 글로벌 롤아웃 인증을 받기 전에 올바르게 동작할 거라는 신뢰를 얻을 만큼의 충분한 테스트가 필요
  • 운영에서 올바르게 동작할 것이라는 의미는 아님
  • 테스트를 통해 많은 문제를 해결할 수 있지만 운영 트레픽에 롤아웃 된 이후에 발견되기도 함
  • 테스트 데이터가 실제 데이터가 아니기 때문
    • 데이터로 인해 새로운 문제가 발생하면 테스트 데이터를 확장해야함
  • 테스트를 하더라도 롤아웃하는 도중에 많은 문제가 발견되는 것이 사실
• 리전별 롤아웃은 새로운 문제를 미리 발견할 기회임

7.4.1 사전 롤아웃 검증

• 테스트가 수행되더라도 릴리즈 파이프라인 시작하기 전에 두 종류의 테스트를 해야함
  • 완전한 통합 테스트
    • 실제 트레픽 없이 애플리케이션을 완전히 확장
    • 운영 데이터 복제본이나 동일한 크기의 모의 데이터를 실제 운영 데이터 규모로 확장
      • 이 부분이 완벽한 통합 테스트를 구성할 때 가장 어려운 부분
      • 개발 초기 단계부터 준비하여 현실적인 통합 테스트 데이터를 설정하는 것이 모범 사례
    ???

7.4.2 카나리 리전

• 정상적으로 동작하는 것으로 보인다면 첫 번째 단계는 카나리 리전이여야 함
• 카나리 리전은 릴리즈를 검증하려는 곳으로부터 현업 트래픽을 받는 디플로이먼트
  • 해당 서비스에 의존하는 내부 팀 or 서비스를 사용하는 외부 고객
• 카나리 리전의 목적은 롤아웃 장애를 일으킬 수 있다는 조기 경고를 주기 위함
• 실패 확률이 높다는 것을 이해하는 공간에서 서비스를 사용하고 배포한다면 문제를 발견하는 것이 쉬울 것 임
• 카나리는 모니터링, 확장, 특성 등에 있어 운영 리전으로 취급되어야 함
• 릴리즈를 위한 첫 번째 영역이므로 그만큼 문제 발생하기 쉬움
• 카나리의 목표는 릴리즈 초기 피드백을 받는 것임
  • 몇칠 동안 릴리즈를 카나리 리전에 유지하는 것이 좋음
  • 긴 시간이 필요한 이유는 버그가 확률적이거나 예외적인 사례에서만 발생할 수 있기 때문

7.4.3 리전 타입 식별

• 전 세계에 롤아웃할 때는 각 리전의 다양한 특성을 이해하는 것이 중요
  • 트레픽이 유달리 많은 리전
  • 접근 방법이 다른 리전
  • ex) 개발도상국의 경우 모바일 브라우저 트레픽이 높을 수 있음
  • ex) 입력 언어가 다른 리전
• 리전의 특성을 이해하고 그에 맞는 테스트를 수행해야함

7.4.4 글로벌 룰아웃 구축

• 카나리 리전이나 사용자 트래픽이 적은 리전을 시작점으로 고려하는 것이 좋음
  • 문제가 발생하더라도 영향이 적음
• 첫 운영 리전으로 롤아웃을 성공했다면 다음 리전으로 넘어가기 전까지 얼마나 오래 기다릴지 대기 시간을 정해야함
  • 대기 시간은 일반적으로 롤아웃이 완료되고 모니터링에서 문제 징후가 보일 때까지 시간
• 롤아웃에 분명한 문제가 있다면 롤아웃이 완료되자마자 인프라에 문제가 나타날 것임
  • 문제가 발생까지 시간이 필요함
  • ex) 메모리 누수 경우 인지하기까지 시간이 필요
• 애플리케이션의 이력으로부터 풍부한 통계를 도출하려면 문제가 발생할 때까지 걸리는 시간을 자세히 측정 해야함
• 트래픽이 적은 리전에서 성공적으로 롤아웃 했다면 트래픽이 많은 리전에 롤아웃 진행
  • 트래픽 유형이 다른 리전에도 동일한 패턴을 따라 롤아웃 진행
• 롤아웃 속도를 내고 싶을수 있지만 입력이나 부하에서 중요한 차이가 있는 단일 리전부터 롤아웃을 해야함
• 충분한 신뢰를 얻었다면 동시 다발적으로 릴리즈를 시작하여 속도를 높일 수 있음

7.5 문제 발생시 대처

• 문제가 발생시 압박감이 가득한 상황에서는 실수할 확률이 높아짐
  • 복구 과정에서 특정 단계를 잊어버리면 상황이 더욱 악화 될수 있음
• 차분하고 정확하게 대응하는 능력이 필요함
• 진행 순서대로 정리된 작업 체크리스트와 함께 각 작업의 예상 결과를 만들어야 함
  • 당연해 보이는 것까지 모든 단계를 작성
• 스트레스가 없는 상황에서 연습을 해야 문제 발생시 정확하게 대응이 가능
• 문제발생한 리전의 사용자 트레픽을 롤아웃하지 않은 리전으로 옮겨야 함
  • 이를 가장 먼저 연습하는 것이 좋음
  • 트래픽을 성공적으로 이동 시킬수 있는지?
  • 이동시키는데 얼만의 시간이 걸리는지?
• DNS기반의 트래픽 제한으로 하나의 리전에서 트래픽을 완전히 드레인하려면 꽤 오랜 시간이 걸리수 있음
• 데이터를 고려하여 퍼센트 단위로 트래픽 드레인 시간을 설정
  • ex) 10분내로 트래픽의 99%를 제거
• 목표를 달성할 때까지 꾸준히 연습해야 함
• 수동으로 명령어를 자르거나 붙여넣지 않도록 자동화도 추가 해야함
• 연습을 통해 사고에 대응하고 시스템 설계 개선이 필요한 곳을 확인할 수 있음
• 데이터 복구를 연습 해야함
• 시스템을 이전 버전으로 글로벌 롤백하는 방법을 연습 해야함
• 실수하는 곳을 기록하고 실수를 줄이기 위해 검증하고 자동화 해야함
• 시스템이 변경되었을 때 대응 방식을 업데이트하고 정기적인 실습을 할수 있도록 구성해야함

7.6 글로벌 롤아웃 모범 사례

• 이미지를 전세계에 분산 해야함
• 최대한 광범위한 통합 및 재현 테스트를 수행
  • 정상적인 동작할 것이라는 확고한 믿음이 있는 릴리즈만 롤아웃 해야함
• 카나리 리전에서 릴리즈를 시작
  • 대규모 고객이 직접 서비스를 사용하여 검증할 수 있는 사전 운영 환경
• 롤아웃하려는 리전의 다양한 특성을 파악
  • 각각의 차이는 전체 혹은 일부의 중단 원인이 될수 있음
  • 위험도가 낮은 리전에서부터 롤아웃을 시도해야함
• 발생할 수 있는 문제의 대응과 절차에 대해 문서화하고 연습 해야함
  • 긴급한 상황에서 무엇을 수행해야 하는지 제대로 기억해야 악화되는 것을 막을 수 있음

7.7 마치며

• 업데이트 과정에서 시스템 장애 시간을 최소화하기 위한 롤아웃 설정 방법을 살펴봤음
• 문제가 발생했을 때 대응에 필요한 과정과 절차를 구성하고 실습하는 법을 다뤄봤음