본문 바로가기
개인 공부 일지/아키텍처

소프트웨어 아키텍처 및 시스템 설계 - (3) 빌딩 블록(DNS, 로드밸런스, 메시지 브로커)

by 대체로 무해함 2025. 9. 14.

해당 시리즈는 【한글자막】 소프트웨어 아키텍처 및 대규모 시스템 설계 강의를 보고 정리한 내용입니다.

빌딩 블록 - DNS, 로드밸런싱, GSLB

로드 밸런싱

  • 시스템의 여러 서버에 트래픽 부하를 나누는 것
  • 기본적으로 클라이언트는 여러 서버에 부하를 분산하기 위해서 각 서버의 주소를 알고 있어야 함
    • 각 요청은 이 서버의 주소와 강하게 결합됨
    • 이는 클라이언트 서비스 구현 내부적으로 강한 결합이 발생하고, 이를 수정하는 건 어려운 일이 됨
  • 로드 밸런서는 여러 서버에 부하를 나누어 단일 서버에 과부하를 피하게 함
    • 대개 추가적으로 서버에 대한 추상화 기능을 제공함
    • 이는 하나의 큰 서버를 이용하는 것과 같이 보임

로드 밸런스로 얻을 수 있는 품질 속성

  • 확장성
    • 부하가 증가함에 따라 인스턴스를 수평적으로 확장 가능(Scale Out)
    • 부하가 감소하면 불필요한 인스턴스를 줄일 수 있음
    • 부하의 기준으로 초당 응답 요청 수나 네트워크 대역폭 등이 있음
  • 고가용성
    • 로드 밸런서의 모니터링 기능을 사용하면 문제가 있는 서버에 부하를 멈출 수 있음
  • 기능(Performance), 처리량(Throughput)
    • 로드 밸런서 자체는 추가 지연 시간과 응답 소요 시간을 늘림
    • 하지만 처리량에 있어서 유의미한 성과를 가지기 때문에 사용함
  • 유지보수성
    • 서버를 번갈아 가며 구동하기 때문에 특정 서버에 대해 가동을 멈추고 유지보수가 가능
      • 서비스 중단 없이 어플리케이션 버전을 조정할 수 있음

로드 밸런스의 종류

  • DNS 로드 밸런싱
    • 사용자가 DNS 서버로 쿼리를 보낼 때,단일 DNS 레코드와 단일 IP 주소를 매핑하지 않고 주소의 목록을 반환함
    • 사용자는 주로 목록의 첫 번째 서버에 요청하는데, DNS에서 이 순서를 라운드 로빈으로 조정해서 보냄
    • 장점
      • 싸다 (도메인 주소 하나만 있으면 됨)
      • 간단하다
    • 단점
      • 서버의 헬스 체크가 되지 않음
        • TTL이 긴 상태에서 사용자 컴퓨터에 캐싱되면 더 오랜 시간 요청이 보내지지 않을 수 있음
      • 전략이 단순한 라운드 로빈 방식임
        • 더 리소스가 많은 인스턴스를 파악할 수 없고, 부하가 발생한 서버를 발견할 수 없음
      • 클라이언트 어플리케이션에게 서버 주소 목록이 전달됨
        • 시스템 구현의 세부사항이 전달됨
        • 주소가 악의적으로 활용될 수 있음(특정 서버 공격)
  • 하드웨어 로드 밸런싱 & 소프트웨어 로드 밸런싱
    • 전용 장치에서 로드 밸런싱 실행 / 로드 밸런싱 기능을 하는 프로그램에 의한 로드 밸런싱
    • 하드웨어 타입, 각 서버의 부하량, 활성화된 연결 수 등을 고려할 수 있음
    • 기기 간의 추상화에도 활용 가능
    • 보안, 복구, 모니터링, 로드 밸런싱 측면에서 DNS에 비해 뛰어남
    • 지형적 위치가 다른 여러 개의 데이터 센터의 경우 무조건 로드 밸런서를 거치면서 한쪽의 성능을 포기해야 함
  • GSLB (글로벌 서버 로드 밸런서)
    • DNS 방식과 하드웨어 / 소프트웨어 방식이 결합된 방식
    • 요청의 원본 IP로 사용자의 위치를 파악하고, 한편으로 각 인스턴스들을 모니터링함
      • 각기 다른 데이터 센터에 로드 밸런스를 두고 요청에 따라 가장 가까운 로드 밸런스 위치를 반환함
    • 재해 복구 상황에 강점을 보임
      • 한쪽 데이터 센터/로드 밸런서가 다운된 경우 다른 데이터 센터의 로드 밸런서 주소를 반환함

빌딩 블록 - 메시지 브로커

  • 앞서 설명됐던 모든 어플리케이션 간의 통신은 양측 어플리케이션이 모두 정상이고 동시에 실행중이라는 전제가 필요했음
    • 이런 형태를 동기 의사소통이라고 함
  • 문제점 ⇒ 해결하기 위해 메시지 브로커 사용
    • 동기 의사소통은 양측이 정상인 채로 트랜잭션의 완료까지 연결을 유지해야 함
      • 만약 메시지가 커지면 시간이 오래 걸리므로 해당 조건을 만족하기 힘듦
    • 급증한 트래픽 또는 부하를 해결할 시스템 패딩이 없음
      • 동시에 많은 요청이 왔을 때, 인스턴스를 늘려도 이미 도착한 많은 요청을 처리하기 위해 오랜 시간이 걸려 이를 해결할 수 없음

메시지 브로커

  • 대기열 구조를 통해 발신자와 수신자 사이의 메시지를 저장함
  • 외부 트래픽 감당을 위한 로드 밸런서와 달리 시스템 내부에 사용되어 밖에 노출되지 않음
  • 기본적인 메시지 버퍼링 외에도 다음의 기능을 제공함
    • 메시지 라우팅
    • 유효성 검사
    • 로드 밸런싱
  • 자체 의사소통 API를 통해 수신자와 발신자를 분리함
  • 아키텍처 빌딩 블록으로 모든 비동기 소프트웨어 아키텍처에 사용됨
  • 이점
    • 메시지 버퍼링을 통해 하나의 서비스를 단계별 서비스로 나눌 수 있음
    • 급등하는 트래픽에 대해 방어가 가능함
      • 프론트 엔드에서 요청된 트래픽을 임시로 저장하면서 카운팅하여 재고를 처리하고, 이를 차후에 버퍼링된 메시지를 처리하여 서비스를 제공함
    • 대개 publish/subscribe 패턴을 제공
      • 시스템을 변형하지 않고 추가적으로 서비스를 만들 수 있음

품질 속성

  • 시스템 간의 의사소통을 가능케 하여 시스템에 많은 내결함성을 제공함
  • 내결함성을 바탕으로 고가용성 제공 가능
  • 메시지 버퍼링을 통해 고가용성/확장성 제공 가능

빌딩 블록 - API 게이트웨이

  • 문제점
    • 단일 서비스를 여러 서비스로 확장할 경우 최초로 구성한 API에 대해 프론트 엔드는 코드를 수정하여 각각의 서비스에 대해 따로 호출해야 함
    • 각 서비스에 대해 보안성, 인증, 권한 부여를 다시 구현해서 사용해야 함
    • 결과적으로 중복된 과정과 오버헤드가 발생함

API 게이트웨이?

  • 외부 API를 단순화하고 서비스 형태를 추상화함
  • 프론트엔드와 백엔드 컬렉션 사이에 놓인 API 관리 서비스
  • API composition이라는 아키텍처 패턴을 따름
  • 이점
    • 시스템에 적용되는 내부 변화를 완벽하고 투명하게 이용자에게 제공
    • 모든 보안성, 인증 권한 부여를 단일 공간에 통합할 수 있음
      • 권한과 역할에 따라 사용자가 다른 작업을 진행할 수 있게 함
      • DoS 공격 방지를 위해 속도 제한일 실행할 수 있음
    • 시스템 성능 개선
      • 사용자가 여러 서비스에 다중 요청을 보내는 것을 방지할 수 있음 ⇒ 요청 라우팅
    • 특정 요청에 대한 응답에 대해 캐싱할 수 있음
    • 각 서비스에 대해 모니터링과 경고가 가능함
    • 단일 공간에서 프로토콜 변환을 진행할 수 있음

품질 속성 / 고려사항

  • 보안성, 성능, 모니터링을 통한 높은 가용성 제공
  • 고려사항
    1. API Gateway에는 어떠한 비즈니스 로직도 없어야 한다
      • API Gateway에 기능이 많아지면 초기에 단일 서비스를 분리하려 했던 문제로 회귀하게 됨
    2. API Gateway는 Single Point of Failure이 될 수 있다
      • API 다중 게이트웨이를 배포하고 로드 밸런스 뒤에 배치함으로써 성능 측면의 문제는 쉽게 해결할 수 있음
    3. 외부에서 API Gateway를 우회하는 것을 피해라
      • 우회하는 코드가 많아질수록 관리해야 하는 구간이 늘어나 초기 문제로 회귀함

CDN

  • 문제점
    • 최종 사용자와 호스팅 서버의 물리적 거리 차이로 인해 심각한 지연이 발생함
    • 오가는 모든 요청이 서로 다른 네트워크 라우터의 여러 홉을 지나야 함
    • 서비스를 복사해 여러 데이터 센터에 복사하면 비즈니스 로직의 속도를 개선할 수 있으나 사용자에게 더 빠른 로딩을 제공하기 위해서는 정적 콘텐츠의 개선이 필요함

CDN?

  • 최종 사용자에게 컨텐츠 전송 속도 상승을 목적으로 전략적인 장소에 위치 시킨 세계적으로 분산된 서버 네트워크
  • 종종 엣지 서버로 언급되는 다른 상호 접속 위치에 자리한 서버에 웹 사이트 컨텐츠를 캐싱하는 방식
  • 이미지, 텍스트, CSS, JS 파일, 비디오 스트림과 같은 정보를 전송하는데 사용함
  • 이점
    • 빠른 페이지 로딩으로 성능 개선
    • CDN의 분산적 성격으로 고가용성 제공
    • 시스템 보안성을 개선하고 DoS 공격 방어를 도움

컨텐츠 캐싱 관련 전략

  • Pull 전략
    • 캐싱하려는 웹사이트와 캐시를 무효화 하는 횟수를 전달하는 방법
    • 만료된 에셋에 대한 요청의 경우 서버에게 버전을 확인하고 버전이 바뀌지 않았다면 만료 기간만 다시 설정하여 사용자에게 제공함
    • 유지 관련을 많이 설정하지 않아도 됨
    • 에셋의 최초 사용자는 지연이 길다는 단점이 있음
  • Push 전략
    • 서버에서 컨텐츠를 CDN으로 전달하고, 업데이트가 발생할 경우 수동으로 서버에 해당 버전을 전달하는 방법
    • 콘텐츠가 자주 변경되지 않는 경우 한 번의 전송으로 고가용성을 유지할 수 있음
    • CDN에서 지속적으로 캐싱되어 있기 때문에 고가용성에 좋음
    • 사용자가 예전 버전에 고착화된다는 단점이 있음