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 오카방 설명도 참고했습니다 ㅋㅋ
'AWS > 🌐 AWS Network' 카테고리의 다른 글
| 클라우드 사용을 위한 인프라 기초 (0) | 2020.10.22 |
|---|
