Difference Between API Gateway and Load Balancer

System Design Interview Basics: Difference Between API Gateway and Load Balancer

종종 우리는 시스템 디자인의 부분을 이루는 소프트웨어 아키텍처 구성요소를 접하게 되고, 우리는 그때마다 접하는 것들에 대해 잘 알지 못하는 것 같다는, 애매한 느낌을 받는다. API 게이트웨이와 로드 밸런서도 그러한 예시 중 하나이다. 

 

대부분의 사람들은 로드 밸런서와 API 게이트웨이를 이용하여 작업해본 경험을 갖지 못한다. 때문에 이러한 이유에서 우리는 그것들에 이야기할 때 불편함을 느낀다. 특히 시스템 디자인 인터뷰에서. 

 

이번 포스트에서는 두 구성요소(=API 게이트웨이와 로드밸런서)에 대한 기본적인 지식, 그리고 두 구성요소가 어떻게 쓰이는지에 대해 설명한다. 

마이크로서비스란? 

마이크로서비스(Microservice architecture를 의미하는 듯)란 소프트웨어 아키텍처 디자인 패턴으로, 어플리케이션이나 서비스가 다른 모듈식(조립가능한?) 구성요소나 서비스로 구성되어 있는 것을 말한다. 각 마이크로서비스는 작고, 독립적인 기능적인 단위로 나뉘어져 있으며, 각 마이크로서비스는 다른 마이크로서비스와 잘 정의된 인터페이스 또는 API를 통해(일반적으로는 네트워크를 통해) 통신한다. 예를 들어 인스타그램 같은 서비스를 만들 때, 사진을 저장하거나, 뉴스 피드를 생성하거나, 사용자에게 알림을 보내는 기능을 별도의(각각의?) 마이크로서비스를 이용하여 구축할 수 있다. 

API 게이트웨이란?

API 게이트웨이란 여러 마이크로서비스에 대해서 단일 출입구 역할(중개인? 창구? 비슷한 느낌)을 하는 서버이다. API 게이트웨이는 사용자의 요청을 받아서, 적절한 마이크로서비스로 전달한다. 그리고 서버의 응답을 다시 사용자에게 전달한다. 

로드 밸런서란?

로드 밸런서란 네트워크 트래픽을 여러 대의 백엔드 서버나 서비스로 분산시켜, 시스템의 성능이나 가용성을 향상시키는 장치이다. 보통 로드밸런서는 서버와 사용자 사이에서 다양한 알고리즘을 사용해 들어오는 요청을 사용가능한 서버들에게 분산시킨다. 보통 성능을 극대화하거나, 하나의 서버에 과부하가 가해지는 일이 없게 하는 방식으로 작동한다. 이는 시스템 전반의 안정성이나 응답성을 높이기 떄문에 시스템이 더 많은 양의 요청도 받아들일 수 있게 한다.

API 게이트웨이와 로드 밸런서 간 차이점은?

API 게이트웨이는 요청이 적절한 마이크로서비스까지 최적의 경로로 갈 수 있게끔 라우팅하는 것에 집중하는 반면에 로드 밸런서는 백엔드 서버 그룹에 요청을 균등하게 분산하는 것에 집중한다. 

 

API 게이트웨이와 로드 밸런서는 둘 다 컴퓨터 네트워크에서 들어오는 요청을 관리하고, 시스템의 성능을 증가시키는 데 사용되는 인프라장치????이다. 

 API 게이트웨이 : API 게이트웨이는 사용자와 마이크로서비스 집합 사이에 있는 미들웨어 유형이다. API 게이트웨이의 주목적은 사용자의 요청이 적절한 마이크로서비스에 도착하게끔 라우팅하고, 마이크로서비스의 응답이 사용자에게 잘 돌아가게끔 하는 것이다. 또한 API 게이트웨이는 authorization이나 rate limiting, 그리고 cashing 같은 다른 기능도 수행한다.

 

로드 밸런서 : 반면에 로드 밸런서는 들어오는 요청을 백엔드 서버 그룹에 균등하게 분산하여 시스템의 성능이나 가용성을 높이는 것을 목적으로 한다. 로드 밸런서는 보통 잘 알려진 단일 IP 주소에서 전송된 요청을 다루며, 그리고 시스템의 성능이나 가용성에 기반해서 그러한 요청들이 이용 가능한 많은 백엔드 서버 중 하나에 라우팅되게끔 한다.

 

다른 차이점은 요청이 일반적으로 관리되는 방식에 있다. API 게이트웨이는 보통 어플리케이션이 인터넷을 통해 서로 통신할 수 있도록 하는 웹 기반 인터페이스인 API에 대한 요청을 다룬다. 이러한 요청들은 주로 사용자가 접근하려고 하는 API를 식별할 수 있게끔 특정 URL을 가지고 있으며, API 게이트웨이는 URL을 이용해서 요청이 적절한 마이크로서비스에 라우팅한다(적절한 도착지에 도착하도록 하는 것이 목적). 반면에, 로드 밸런서는 보통 잘 알려진 단일 IP 주소에서 전송된 요청들을 다루며, 시스템의 성능이나 가용성에 기반해서 그러한 요청들이 이용 가능한 많은 백엔드 서버 중 하나에 라우팅되게끔 한다(요청들이 잘 분산되도록 하는 것이 목적).

API 게이트웨이의 용도

API 게이트웨이는 마이크로서비스 아키텍처에서 아래와 같은 다양한 목적을 위해 사용된다.

1. 라우팅 : API 게이트웨이는 사용자로부터 요청을 받고, 요청이 적절한 마이크로서비스에 라우팅되게끔 한다. 이는 사용자가 단일 진입점(API 게이트웨이를 뜻하는 듯)를 통해 다양한 마이크로서비스에 접근할 수 있게끔 함으로써 전반적인 시스템 디자인을 간단하게 한다. 
2. 속도 제한 : 사용자가 API 게이트웨이에 접근하려고 할 때 속도를 제한할 수 있다. 이는 서비스 거부 공격(DoS attack)이나 기타 악의적인 동작을 방지하는 데 도움이 된다. 
3. 캐싱 : API 게이트웨이는 마이크로서비스의 응답을 캐시하여, 마이크로 서비스로 전달해야 하는 요청 수를 줄이고, 시스템의 전반적인 성능을 높일 수 있다.
4. 인증 및 권한부여 : API 게이트웨이는 마이크로서비스에 대해 사용자를 인증하고 접근 통제 정책을 보강하는 데 사용할 수 있다. 이는 권한을 부여받은 사용자만이 마이크로 서비스에 접근하도록 하고, 승인되지 않은 접근을 막는 데 도움이 된다. 
5. 로드 밸런싱 : API 게이트웨이는 들어오는 요청을 다양한 마이크로서비스에 분산할 수 있다. 이는 시스템이 더 많은 수의 요청을 다룰 수 있게 하고, 시스템의 전반적인 성능이나 규모를 키울 수 있게 한다. 
6. 모니터링 : API 게이트웨이는 요청과 응답에 관한 여러 데이터를 수집할 수 있다. 이는 진단되는 문제를 식별하고, 시스템의 전반적인 안정성이나 복구능력을 높이는 데 도움을 준다. 
7. Transformation : API 게이트웨이는 마이크로서비스에게 받은 데이터를 사용자가 사용하기 편리한 형태로 변환하는 데 사용할 수 있다. 이는 XML과 JSON 같이 다른 데이터 포맷 사이의 변환이나 여러 마이크로서비스에게 받은 데이터를 하나의 응답에 모으는 행위도 포함한다. 
8. 요청과 응답의 타당성 검사 : API 게이트웨이는 마이크로서비스로부터의 요청과 응답에 대한 타당성을 검사하여 예상되는 포맷과 구조를 준수하는지 확인할 수 있다. 이는 에러를 막고, 마이크로 서비스가 적절한 기능을 하도록 보장하는 데 도움을 준다. 
9. 회로 차단기 : API 게이트웨이는 단일 마이크로서비스의 실패가 전체 시스템을 중단하지 않도록 도움을 주는 회로 차단기 패턴을 구현하는 데 사용할 수 있다. 회로 차단기는 마이크로서비스의 상태를 모니터링하고, 필요하다면 자동적으로 백업서비스로 failover 할 수 있다. 
10. 서비스 발견 : API 게이트웨이는 사용가능한 마이크로 서비스와 그들의 경로를 알아내고, 사용자가 특정 주소(마이크로 서비스에 대한 주소)를 알지 못하고도 접근하는 것을 가능하게 한다. 이는 사용자에게 영향을 미치지 않고도 새로운 마이크로 서비스를 추가하고, 기존 마이크로서비스를 변경하는 것을 쉽게 한다.

API 게이트웨이 사용의 이점

1. 성능 향상
2. 시스템 디자인 간소화
3. 안전 강화
4. 규모 성장
5. 더 나아진 모니터링과 가시성

API 게이트웨이 사용의 단점

1. 복잡성 증가
2. 성능 오버헤드 : 요청-응답 경로 사이에 사용자가 거쳐야하는 추가 계층이 생겨나면서 약간의 성능 오버헤드가 발생할 수 있음 
3. 단일 실패 지점?? : API 게이트웨이가 제대로 설계되거나 구현되지 않으면 대부분의 요청 응답이 API 게이트웨이를 거치기 때문에 대부분의 요청 응답이 실패할 수 있음. 이는 시스템의 전반적인 안정성, 가용성에 영향을 준다.

결론

API 게이트웨이는 사용자와 마이크로서비스 사이의 인터페이스 역할을 주로 하는 반면, 로드 밸런서는 요청을 여러 서버 또는 서비스에 분산시켜 성능과 가용성을 높이는 것을 목적으로 함. 비슷한 용도를 가지고 있지만 엄연히 다른 목적을 가지고 있으며, 때문에 각각이 같이 사용되는 경우가 많다. 결론적으로는 둘 다 마이크로서비스가 개별 작업에 집중하도록 하여 시스템이 전반적으로 성능과 확장성 및 안정성을 개선할 수 있도록 한다.