해당 시리즈는 【한글자막】 소프트웨어 아키텍처 및 대규모 시스템 설계 강의를 보고 정리한 내용입니다.
빌딩 블록 - 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 공격 방지를 위해 속도 제한일 실행할 수 있음
- 시스템 성능 개선
- 사용자가 여러 서비스에 다중 요청을 보내는 것을 방지할 수 있음 ⇒ 요청 라우팅
- 특정 요청에 대한 응답에 대해 캐싱할 수 있음
- 각 서비스에 대해 모니터링과 경고가 가능함
- 단일 공간에서 프로토콜 변환을 진행할 수 있음
품질 속성 / 고려사항
- 보안성, 성능, 모니터링을 통한 높은 가용성 제공
- 고려사항
- API Gateway에는 어떠한 비즈니스 로직도 없어야 한다
- API Gateway에 기능이 많아지면 초기에 단일 서비스를 분리하려 했던 문제로 회귀하게 됨
- API Gateway는 Single Point of Failure이 될 수 있다
- API 다중 게이트웨이를 배포하고 로드 밸런스 뒤에 배치함으로써 성능 측면의 문제는 쉽게 해결할 수 있음
- 외부에서 API Gateway를 우회하는 것을 피해라
- 우회하는 코드가 많아질수록 관리해야 하는 구간이 늘어나 초기 문제로 회귀함
- API Gateway에는 어떠한 비즈니스 로직도 없어야 한다
CDN
- 문제점
- 최종 사용자와 호스팅 서버의 물리적 거리 차이로 인해 심각한 지연이 발생함
- 오가는 모든 요청이 서로 다른 네트워크 라우터의 여러 홉을 지나야 함
- 서비스를 복사해 여러 데이터 센터에 복사하면 비즈니스 로직의 속도를 개선할 수 있으나 사용자에게 더 빠른 로딩을 제공하기 위해서는 정적 콘텐츠의 개선이 필요함
CDN?
- 최종 사용자에게 컨텐츠 전송 속도 상승을 목적으로 전략적인 장소에 위치 시킨 세계적으로 분산된 서버 네트워크
- 종종 엣지 서버로 언급되는 다른 상호 접속 위치에 자리한 서버에 웹 사이트 컨텐츠를 캐싱하는 방식
- 이미지, 텍스트, CSS, JS 파일, 비디오 스트림과 같은 정보를 전송하는데 사용함
- 이점
- 빠른 페이지 로딩으로 성능 개선
- CDN의 분산적 성격으로 고가용성 제공
- 시스템 보안성을 개선하고 DoS 공격 방어를 도움
컨텐츠 캐싱 관련 전략
- Pull 전략
- 캐싱하려는 웹사이트와 캐시를 무효화 하는 횟수를 전달하는 방법
- 만료된 에셋에 대한 요청의 경우 서버에게 버전을 확인하고 버전이 바뀌지 않았다면 만료 기간만 다시 설정하여 사용자에게 제공함
- 유지 관련을 많이 설정하지 않아도 됨
- 에셋의 최초 사용자는 지연이 길다는 단점이 있음
- Push 전략
- 서버에서 컨텐츠를 CDN으로 전달하고, 업데이트가 발생할 경우 수동으로 서버에 해당 버전을 전달하는 방법
- 콘텐츠가 자주 변경되지 않는 경우 한 번의 전송으로 고가용성을 유지할 수 있음
- CDN에서 지속적으로 캐싱되어 있기 때문에 고가용성에 좋음
- 사용자가 예전 버전에 고착화된다는 단점이 있음
'개인 공부 일지 > 아키텍처' 카테고리의 다른 글
| 소프트웨어 아키텍처 및 시스템 설계 - (6) 빅데이터 아키텍처 (0) | 2025.09.14 |
|---|---|
| 소프트웨어 아키텍처 및 시스템 설계 - (5) 소프트웨어 아키텍처 패턴 (0) | 2025.09.14 |
| 소프트웨어 아키텍처 및 시스템 설계 - (4) 데이터 스토리지 (0) | 2025.09.14 |
| 소프트웨어 아키텍처 및 시스템 설계 - (2) 인터페이스 (0) | 2025.09.14 |
| 소프트웨어 아키텍처 및 시스템 설계 - (1) 시스템 설계 (0) | 2025.09.14 |