1. 로드밸런서와 API 게이트웨이

API 게이트웨이와 로드 밸런서는 언뜻 보기에는 비슷한 기능을 수행하는 것처럼 보일 수 있다.
(둘 다 네트워크 트래픽을 관리하고 요청이 효율적으로 처리되도록 하는 데 관여하기 때문)

그러나 이들은 매우 다른 용도로 사용되며 네트워크 아키텍처의 서로 다른 계층에서 작동한다.

2. 로드밸런서란?

Load Balancing

: 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 자원들에게 작업, 즉 부하(Load)를 나누는 것을 의미한다.
이로써 가용성 및 응답시간을 최적화 시킬 수 있다.

로드밸런서는 Client의 요청 및 네트워크의 트래픽이 집중되는 서버들 사이의 위치한다.

2.1 로드 밸런싱의 기본 기능

2.1.1 Health Check

• 서버들에 대해 주기적으로 Health Check를 진행하여 장애 여부를 판단하고, 정상 동작 중인 서버로만 트래픽을 보낸다.
• 계층 별 헬스 체크
  • L3 : ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인한다.
  • L4 : TCP의 3 Way-Handshakin을 기반으로 통신하는 특성을 바탕으로 각 포트 상태를 확인한다.
  • L7 : 어플리케이션 계층에서 실제 웹 페이지에 통신을 시도하여 장애 여부를 판단한다.

2.1.2 Tunneling (터널링)

• 터널링 : 데이터 스트림을 인터넷 상에서 가상의 파이프를 통해 전달시키는 기술
• 상호 연결된 곳끼리만 캡슐화된 패킷을 구별해 캡슐화를 해제하게 한다.

2.1.3 NAT(Network Address Translation)

• 내부 네트워크에서 사용하는 사설 IP 주소와 로드밸런서 외부의 공인 IP 주소 간의 변환 역할
• 로드 밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소를 통해 접속하는 것이 주 목적.
• SNAT(Source Network Address Translartion) : 내부에서 외부로 트래픽이 나가는 경우
• DNAT(Destination Network Address Translation) : 외부에서 내부로 트래픽이 들어오는 경우

2.2 로드밸런싱 알고리즘

2.2.1 라운드 로빈(RR)

• 서버로 들어온 요청을 순서대로 돌아가며 배정하는 방식.
• 클라이언트의 요청을 순서대로 배합 → 서버들이 동일한 스펙이며, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합하다.

2.2.2 가중 라운드로빈(Weighted RR)

• 각각의 서버마다 가중치를 매기고, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분하는 방식.
• 주로 서버의 트래픽 처리 능력이 상이한 경우 사용된다.

2.2.3 해시(IP Hash)

• 사용자의 IP를 해싱하여 부하를 분산 → 사용자가 항상 동일한 서버로 연결되는 것을 보장
• 접속자 수가 많을수록 분산 및 효율이 뛰어남.

2.2.4 최소 연결 방식(Least Connection)

• 요청이 들어온 시점에 가장 적은 연결(세션) 상태를 보이는 서버에 우선적으로 트래픽을 할당
• 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합

2.2.5 최소 응답시간 방식(Least Response Time)

• 서버의 현재 연결 상태와 응답 시간을 모두 고려하여, 가장 짧은 응답 시간을 보내는 서버로 트래픽을 할당
• 각 서버들의 가용한 리소스와 성능, 처리중인 데이터 양 등이 상이할 경우 적합.

💡 로드 밸런싱에는 L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 활용된다.

• L7 로드 밸런서 : 네트워크 상에서 각각의 서버에서 프로그램을 실행시킬 경우
• L4 로드 밸런서 : 한 대의 서버에 다수의 프로그램을 운영하여 포트를 다르게 실행시킬 경우

2.3 L4 로드 밸런서

: 네트워크 계층(IP, IPX)이나 전송 계층(TCP, UDP)의 정보를 바탕으로 로드를 분산

2.3.1 장점

• 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르고 효율이 높음.
• 데이터의 내용을 복호화할 필요가 없기에 안전.
• L7 로드밸런서보다 가격이 저렴.

2.3.2 단점

• 패킷의 내용을 살펴볼 수 없으므로, 섬세한 라우팅 불가.

2.4 L7 로드 밸런서

: 어플리케이션 계층(HTTP, FTP, SMTP 등)에서 로드를 분산하기 때문에, HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능 (콘텐츠 기반 스위칭)

: Dos/DDos 와 같은 비정상적인 트래픽 필터링 가능.

2.4.1 장점

• 상위 계층에서 로드를 분산하기 때문에 훨씬 더 섬세한 라우팅 가능.
• 캐싱(Cashing) 기능을 제공
• 비정상적인 트래픽을 사전에 필터링할 수 있어 서비스 안정성 높음.

2.4.2 단점

• L4 로드밸런서에 비해 비쌈.
• 패킷의 내용을 복호화하여야 하므로 더 높은 비용을 지불해야 함.
• 클라이언트가 로드밸런서와 인증서를 공유해야 하기 때문에, 공격자가 로드밸런서를 통해 클라이언트의 데이터에 접근할 수 있는 보안상의 위험성 존재.

3. API 게이트웨이란?

: API 게이트웨이는 클라이언트와 API 또는 마이크로서비스 사이의 중개자 역할을 하는 서버이다.

: API 호출을 수신하여 처리한 후 적절한 마이크로서비스로 라우팅하는데, 마치 혼잡한 교차로에서 교통 관제사가 자동차(요청)를 올바른 목적지(마이크로서비스)로 안내하는 것과 같다.

3.1 API Gateway vs Load Balancer

3.1.1 요청 및 네트워크 트래픽 관리에 대한 접근 방식

API Gateway

• 요청 자체에 관심을 갖는다.
  • 요청의 형식이 올바르고, 올바른 마이크로서비스로 라우팅되며, 리소스 가용성에 따라 우선순위를 지정
• 또한 인증, 규정 준수 및 기타 확인 프로세스와 같은 작업을 처리하여 요청이 최상의 상태로 제공되도록 한다.

Load Balancer

• 네트워크 트래픽에 더 많은 관심을 갖는다.
  • 요청이 제대로 형성되었는지, 어느 MS로 전송되는지가 아닌
    요청을 처리할 수 있는 서버가 여유는 있는지 , 네트워크 수요로 인해 과부하가 걸리지는 않는지를 본다.

3.2 자주 묻는 질문

3.2.1 API Gateway와 로드 밸런서를 함께 사용할 수 있을까?

• 함께 사용할 수 있다.
  • API Gateway는 요청을 관리하고 적절한 마이크로서비스로 라우팅할 수 있으며,
  • Load Balancer는 네트워크 트래픽을 여러 서버에 분산하도록 한다.
  • 이 조합은 효율적인 요청 처리와 부하 분산을 보장 → 보다 강력하고 확장 가능한 시스템을 구축

3.2.2 API Gateway와 로드 밸런서를 위한 특정 도구나 서비스 예시

• API 게이트웨이
  • Amazon API Gateway, Kong, Apigee, Zuul
• 로드밸런서
  • AWS Elastic Load Balancing, Google Cloud Load Balancing
  • HAProxy, Nginx

3.2.3 보안에서의 API 게이트웨이의 역할

• 인증 및 권한 부여와 같은 기능을 제공하여 유효하고 승인된 요청만 마이크로서비스로 라우팅되도록 한다.
• 또한 요청 속도를 제한할 수 있다. → DDoS 공격과 같은 위협으로부터 보호
• 또한 데이터를 암호화하고 API 키를 관리하여 시스템의 보안을 더욱 강화할 수 있다.

4. 참고 자료

• https://dodghek.tistory.com/33
• https://www.cloudv.kr/etc/lb.html
• https://co-no.tistory.com/22
• https://42jerrykim.github.io/api-gateway-vs-load-balancer/