본 내용은 인프런 프리온보딩 과정을 회고하는 목적으로 작성되었습니다.
이번 게시물은 아키텍처를 통한 성능 개선에 관련한 내용입니다.
위는 두 개 이상의 데이터센터를 활용하는 아키텍처 입니다.
장애가 없는 상황에서 클라이언트는 지리적으로 가장 가까운 데이터 센터로 라우팅되며 이를 지리적 라우팅(geoDNS-routing 또는 get-routing)이라고 합니다. 지리적 라우팅에서 DNS는 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정합니다.
이러한 다중 데이터 센터 아키텍처를 설계하려면 데이터 동기화(Sychronization)이 중요합니다. 데이터 센터마다 별도의 데이터베이스를 사용한다면, 장애가 자동 복구되어 트래픽이 다른 데이터베이스로 우회된다고 해도 해당 데이터센터에는 찾는 데이터가 없을 수 있습니다.
따라서 다른 데이터 센터에도 동일한 데이터 복사본을 다중화함으로써 서비스의 중단 없이 계속하여 데이터 센터에 접근할 수 있도록 해야합니다.
서비스의 규모가 커지기 시작하면, 하나의 단일 API 시스템(Monolithic) 은 장점보다 단점이 커지게 됩니다.
단일 시스템은 한 부분의 오류가 전체 시스템에 영향을 끼칠 수 있습니다. 특정 부분의 오류로 network connection 들이 timeout이 나는 오류가 발생한다면 전체 서버의 퍼포먼스가 영향을 받을 수 있기때문입니다.
단일 시스템에서는 전부 하나의 시스템에 묶여 있기 때문에, 동일한 리소스가 부여됩니다. 결제기능 보다 비디오 스트리밍 기능이 사용 빈도수가 훨씬 높더라도 하나의 시스템에 묶여있기 때문에 두 기능 모두 동일한 사양과 개수의 서버가 할당이 되며 일괄적으로 시스템을 확장해야하는 비효율이 발생합니다.
단일 시스템에서는 시스템 중 한 부분만 업데이트가 되어도 전체 시스템이 모두 새로 배포가 되어야 합니다. 따라서 불필요하게 배포의 빈도수가 증하며, 잦은 배포로 인한 결함이나 오류의 리스크가 높아집니다.
하나의 코드 베이스에 모든 기능이 존제하다면 느슨한 결합을 유지하기 위한 코드 구현 난이도가 상승하게 됩니다. 동일한 코드 베이스에 작업을 하다보니, 각 기능별에 맞는 다양한 언어나 기술을 적용하기 어렵고 일괄적인 언어, 기술이 적용되게 됩니다.
동일한 코드 베이스에 많은 수의 개발자들이 작업을 하게 된다면 소유권(ownership)을 효과적으로 관리하기 어렵고 코드 베이스가 방대하지며 결합도가 높아집니다. 이는 협업을 비효율적이며 높은 난이도로 만들게 됩니다.
위는 시스템의 전체적인 구조를 서비스별로 독립적으로 나누어 구성한 아키텍처 방식입니다. 예를들어 유저에 관련된 기능은 UserService 서버에서 독립적으로 담당합니다.
이렇게 Micro하게 나누어진 서비스들이 모여 하나의 서비스가 완성되며 단일 시스템(Monolithic System)의 단점들(오류 관리, 확장성, 배포 효율성, 개발 효율성)을 보완할 수 있습니다.
MSA 에서는 각 기능이 서비스 별로 나뉘어 독립적인 시스템으로 운영되다 보니, 각 서비스가 물리적으로도 나누어집니다. 이는 각 서비스의 엔드포인트 호출 하기 위해서 접속해야 하는 주소도 다르게 됩니다.
User Service -> user.api.com
Payment Service -> payment.api.com
Streaming Service -> video.api.com
이러한 경우 프론트엔드에서 각 서비스별로 기억, 관리하는 주소가 증가하게 되고 효율적인 API 사용이 어렵게 됩니다. 그 외에도 서비스 간의 통신 증가(네트워크 오버헤드)와, 디버깅 및 추적의 어려움(모니터링), 배포의 복잡성 등의 단점이 있습니다. 이런 단점중 엔드포인트의 증가 문제 해결하기 위해 API Gateway를 사용하게 됩니다.
API Gateway는 이름 그대로 API의 입구 역활을 하며 단일화된 주소를 통해 MSA 구조의 시스템을 사용 가능하게 합니다. 모든 트래픽은 먼저 API Gateway를 통해 이동하며, API Gateway는 받은 트래픽을 적절한 서비스로 분산 및 전달합니다.
참고문헌
원티드 교육자료