3 tier arch와 함께 살펴보는 LB와 API gateway
API Gateway(GW)가 단순히 엔드 포인트를 일원적으로 관리해주는 역할 뿐만 아니라, 유저 검증이나 로드 밸런서의 역할을 하면서 LB와 GW의 차이가 무엇인지를 묻는 일이 많아졌다. GW가 LB의 역할을 할 수도 있다고 단순하게 정리해도 되지만, 각 요소가 왜 필요한지 짚어보면서 이해해보기로 하자.
3 tier 아키텍쳐와 LB의 필요성 대두 : 확장성(scalability!)
www.jinfonet.com/resources/bi-defined/3-tier-architecture-complete-overview/
thenewstack.io/database-load-balancing-and-the-delusion-of-3-tiered-architecture/
우선, LB가 왜 필요했고, 등장했는지를 알아보자.
우선 3-tier 아키텍쳐는 아래와 같은 세 레이어로 구성된다.
소위 말하는 '프론트', '백엔드'의 명확한 구분이 가능한 것도 이러한 레이어 구분이 있기 때문이다.
각각이 분리되어 ('모듈화 되어 있어') 개발팀이 특정 부분을 업데이트하는데 좀 더 유연하게 대처할 수 있는 편이다.
조금 더 실제 프로덕트에 가까운 3-tier 아키텍쳐는 아래와 같다.
3-tier 아키텍쳐의 또 다른 장점으로는 '확장성'이 있습니다. scalability라고 하죠.
레이어는 분리되어 있으므로 각 레이어는 필요에 따라 확장할 수 있다.. 예를 들어서 웹 서버을 많이 받고 있는데 WAS에서는 별 영향이 없는 경우 웹 서버만 늘릴 수 있습니다. 반대로 웹 서버보다 WAS에 많은 요청이 가는 경우 WAS를 늘릴 수 있다.
여기서 포인트는 특정 레이어를 늘릴 경우 유저에게 적절히 특정 서버로 분배하는 역할이 필요하다는 겁니다.
이게 LB가 할 일입니다.
그렇다면 작은 규모의 서비스이고, 각 서버가 한대만 있는 모놀리식한 구조라면 굳이 LB를 추가할 필요가 없다는 말이다.
별 세팅 생각 없이 하나의 EC2에 올리기도 한다. (제발 EC2 직접 쓰지 말라니깐요?)
LB의 역할은 여기까지 입니다.
그러면 GW는 언제 쓰는가 : 중앙화된 api 엔드포인트 관리 및 중앙적 미들웨어
기본적으론 각 마이크로 서비스의 엔드 포인트를 별도로 관리하지 않게 한 곳에 몰아서 관리해주는 역할을한다.
유식한 말로 API 서버들의 엔드 포인트를 단일화해주는 또 다른 서버다. 클라우드 서비스를 제공해주는 GW 외에 직접 GW를 만들 수도 있다. 따라서, GW는 특정 서비스의 이름이라기보다는 일반 명사에 가깝고, 지원하는 내용도 플랫폼마다 다른지라 완전 요약하긴 어렵다.
그림을 보면 직관적으로 이해할 수 있다.
어느 규모 이상의 마이크로 서비스 기반 어플리케이션에서 사용하게 되지,
일반 모놀리식 어플리케이션에서는 딱히 이용할 이유가 없다. (사용 하지 말라는 건 아니다.)
다만 클라우드 서비스 내의 serverless를 쓴다면 자연스레 GW를 쓰게 된다. 어쨌거나 접근 주소가 필요하니까...
( * 아래 예시에서 왜 LB가 붙냐면, 각 비즈니스 로직을 처리하는 부분의 서버가 여러대일 수 있기 때문이다.)
( * 당연한 소리지만, 로깅에 mongoDB를 쓰고, 일반적인 부분은 MariaDB를 쓰는 등 특정 로직을 처리하기 위해 적합한 DB를 사용하는 등의 변칙적인 구성을 줄 수 있다. 큰 기업들은 다 이렇게 하더라)
각 플랫폼에 따라 다르긴 하지만 인증이나 보안, 트래픽 컨트롤(REST API에서 많이 쓰는 버저닝 /v1 /v2 등…) 등 중앙화된 미들웨어로서의 역할도 한다.
여기서 GW가 LB로서의 역할을 할 수 있는 이유가,
API 호출을 라우팅 하는 기능이다. 같은 API라도 사용하는 서비스나 클라이언트에 따라서 다른 엔드포인트를 이용해서 서비스를 제공하거나, 데이타 센터가 여러개일때, 데이타 센터간의 라우팅등을 지원하는 기능이다.
출처: https://bcho.tistory.com/1005 [조대협의 블로그]
그런데 왜 이렇게 각 서비스 별 api 엔드 포인트를 GW를 통해 관리해야 할 정도로 많아지게 된 것일까?
서비스 규모가 커지면서 MSA가 유행을 타면서 그런 점도 있지만 근본적인 원인으로는 스마트폰의 등장이 원인으로 지목된다.
교양) 왜 이렇게 API가 자주 사용되게 되었나?
여러 원인이 있지만 대체론 아이폰 때문이라는 의견.
과거 스마트폰이 등장하기 전에는 (Web-내부망연결-WAS) 구조로 사실 긴밀하게 연결되있었다.
그러나 아이폰이 출시하되면서 서버 내부의 리소스를 인터넷을 통해서 스마트폰이 접근해야 하게 되었고 외부에서 접근하도록 API를 만들게 되었다. 물론 아무나 엔드 포인트를 안다고 해서 접근 권한을 그냥 줄 수는 없으니 인증이 필요해서 OAuth 같은 기술이 도입되는 등 API와 관련된 기술이 등장했다.
reference)
aws 오카방 설명도 참고했습니다 ㅋㅋ