MSA(Micro Service Architecture) & API Gateway
마이크로서비스 아키텍처를 이해하기 위해서는 마이크로서비스 아키텍처가 아닌 모놀리식(Monolithic) 아키텍처에 대한 이해가 필요하다.
모놀리식의 뜻은 "하나로 된" 이다. 서비스 혹은 어플리케이션이 하나의 거대한 아키텍처로 구성되어 있을 때, 이를 모놀리식 아키텍쳐라고 한다. 이러한 아키텍처는 초기 개발에 용이하고 테스트 수행하기 편하다는 장점이 있다.
하지만 규모가 커지면서 한계를 부딪히게 된다. 일부분의 코드 수정이라도 전체를 다시 빌드하여 테스트하고 배포해야 한다. (서비스가 이미 배포된 상태라면, 업데이트하는 동안 전체 서비스가 중단된다.) 이 과정에서 예상치 못한 곳에서 에러가 발생하거나 그럴 수 있고, 개발자가 여러 명일 경우 모든 코드를 이해할 수 없으므로, 중복적인 코드가 있을 수 있고, 유지보수에 어려움이 따른다. 또한 부분적인 서비스 파트의 스케일 아웃이 불가능하여 자원을 효율적으로 사용하기가 힘들다.
또한 위 그림처럼 서비스 규모가 커지고 개발 팀이 많아진다면 기존 모놀리식으로 개발하기란 쉽진 않다. 위처럼 팀을 분리하고 서비스를 나눠 각자 개발하는 것이 많은 장점이 있다. 일단 개념부터 보면.
마이크로서비스 아키텍처는 이러한 모놀리식 아키텍처와 다르게 서비스를 하나의 아키텍처로 구성하는 것이 아니라, 하나의 서비스를 여러개의 작은 서비스, 즉 여러 개의 마이크로서비스로 구성하는 아키텍처를 의미한다.
마이크로 서비스 아키첵처는 서비스 규모가 커지고 복잡해 질 수록 장점을 가지게 되는데, 효율적인 자원사용이 가능하고 특정 서비스의 코드를 업그레이드 했을 때, 이 특정 서비스의 코드가가 전체 서비스 코드에 영향을 주지 않아 보다 높은 안정성을 확보할 수 있다.
그리고 개발자가 모든 코드를 알 필요가 없기 때문에 부담이 적으며, 여러 서비스에서 필요한 코드 같은 경우 각 팀들이 참조해서 사용할 수 있도록 하여 코드 사용 효율성도 높일 수 있으며, 유지보수가 용이하다.
그리고 각 서비스마다 개발의 자유도가 높다. 모놀리식의 경우, 서비스의 DB를 SQL DB를 쓴다하면 SQL DB 밖에 사용할 수 없다. 하지만, 마이크로서비스로 가게 되면, 위 그림처럼 각 팀마다 필요에 따라 다른 DB를 사용할 수 있다.(이는 단점이 될 수 도 있지만, 여튼) 이처럼 DB 뿐 아니라, 각 서비스를 개발하는 데 있어 필요한 부분들을 조금 자유롭게 개발이 가능하다.(상식선에서 자유로움까지! 가령.. 언어를 다르게 쓴다던가. 그런것 말고)
하지만 단점 또한 생기게 되는데, 마이크로 서비스 간의 통신을 위한 코드가 추가적으로 필요하게 된다. 이는 프로그램의 복잡도를 높이기도 하지만, 서비스의 성능에 영향을 줄 수도 있다.(응답 시간 증가로 인한)
또한 각각의 마이크로서비스로 배포하고 관리가 가능하다는 것은 여러 언급한 여러 장점을 가진 동시에 관리포인트가 증가한다는 것을 의미하며, 테스팅이 복잡해질 수 있다.(간단히 말해, 그거 우리 일 아닌데요 하는 팀이 생긴다는 것이다. 모놀리식이면 전부 내 일, 마이크로서비스면 여기까지 내일, 저기부턴 우리 일 아님 하는 수가 생김)
마지막으로, 각 마이크로서서비스가 각각의 DB로 각자 돌아가기 때문에, 하나의 큰 서비스(여러 마이크로서비스들)를 하나의 트랜잭션으로 묶는 것이 힘들다. 하나의 트랜잭션으로 묶을 필요가 있을 경우 이를 위한 추가 작업이 MSA에서는 필요하게 된다.
마이크로서비스 아키텍처를 위해서는 PaaS나 도커, 쿠버네틱스 같은 컨테이너 기술을 이용하여 구성할 수 있다.
특정 서비스만 변경을 해야될 때, 모놀리식으로 구성하게되면, 전체 코드를 손 봐야할 수 있지만,(한 덩어리로 되어 있어 한 서비스의 변경이 다른 서비스 코드에 영향을 줄 수 있기 때문에)
마이크로서비스 아키텍쳐에서는 특정 서비스 코드만 수정을 하면 된다.(각 서비스가 개별의 서비스로 구분되어 있기 때문에)
이게 장점이 될 수 있지만, 단점으로 서비스간 통신을 위한 추가적인 코드가 필요하다고 했었는데, 이는 클라이언트, 웹 UI나 앱 등은 모든 마이크로서비스로 부터 요청을 보내고 받아야된다는 것이다. 그대로 구현하게 되면 요청과 응답이 몰려 지연 시간이 발생할 수 있다.
이를 해결하기 위해 API Gateway를 클라이언트와 마이크로서비스 사이에 위치시킬 수 있다. 클라이언트는 API Gateway만 연결하고, API Gateway는 마이크로서비스들과 연결을 한다.
이때 API Gateway는 로드 밸런서 역활을 해줄수 있고, 캐싱을 하여 동일한 요청에 대한 반복작업을 줄 일 수 있으며, 모니터링 역활을 같이 해줄 수 있다. 인증이 필요한 경우, api 키 혹은 api 토큰을 검사하여 유효한 요청에게만 api 응답을 주는 등의 인증 기능도 할 수 있다. 더불어 사용빈도를 제한을 하여 불필요한 트래픽 낭비 방지 혹은 DDoS 공격 방어등의 역할을 할 수 있다.
하지만 API Gateway도 병목 현상이 발생할 수 있으므로, 확장을 고려한 설계를 해야한다. 그리고 서비스간 통신은 Rest API 혹은 GraphQL(좀 더 최신) 한다.
그리고 MSA의 Data Format은 HTML, XML, JASON 등이 있다.