2. 서버 아키텍쳐
2.1 서비스 요구사항
무엇을 지원해야 하는가?
-
HTTP 요청 처리
- 사용자는 출발지와 목적지를 입력하여 HTTP 요청을 보낼 것입니다. 이 요청을 서버가 받아들이고 파싱하여 이해해야 합니다.
- 요청에 따라 적절한 알고리즘 서버로 경로 계산 요청을 보내야 합니다.
-
경로 계산 서비스
- 알고리즘 서버는 받은 출발지와 목적지 정보를 기반으로 최적의 도보 경로를 계산해야 합니다.
- 보조 기구를 사용하는 사용자의 특별한 요구사항을 고려하여 장애물을 피하고 편의시설을 고려한 경로를 생성해야 합니다.
-
경로 안내 서비스
- 계산된 경로를 클라이언트에게 응답으로 전달해야 합니다. 이 응답에는 경로 정보와 안내에 필요한 세부 정보가 포함될 것입니다.
- 안내에는 출발점에서 도착점까지의 이동 방향, 거리, 시간, 주변 편의시설 등을 포함해야 합니다.
-
안내 서비스
- 사용자에게 도보로 이동하는 동안에도 지속적으로 경로 안내를 제공해야 합니다. 이는 턴 바이 턴 방향 안내, 주요 지점 표시, 장애물 알림 등을 포함할 수 있습니다.
-
오류 처리 및 예외 상황 관리
- 사용자가 잘못된 요청을 보내거나 서버가 처리하지 못하는 상황에 대비하여 오류를 적절히 처리하고 사용자에게 알려줘야 합니다.
2.2 아키텍처 구성 - 서버
기존에는 HTTP 통신을 하는 스프링 기반 API 서버만이 존재했다면, 이제 API 서버와 Engine을 분리해서 서비스 아키텍처를 구성하려고 합니다.
만약 API 서버만 사용한다면?
-
단일 지점 장애(Single Point of Failure):
- API 서버가 모든 요청을 처리하다 보니, 이 서버에 문제가 발생하면 전체 서비스에 영향을 미칠 수 있습니다.
-
확장성 제한:
- 증가하는 트래픽에 대응하기 위해 API 서버를 확장하려면 서버 자체를 더 추가해야 합니다. 이는 비용과 관리적인 어려움을 야기할 수 있습니다.
-
서비스 분리 및 역할 분담 어려움:
- 서비스를 여러 기능으로 분리하거나, 각 기능을 다른 기술 스택으로 구현하기 어려울 수 있습니다. 이는 유연성과 유지보수성을 저해할 수 있습니다.
-
일부 기능에 대한 부하:
- 모든 기능을 하나의 서버에서 처리하기 때문에, 특정 기능이나 작업에 따라 부하가 집중될 수 있습니다. 이는 전체 서비스의 성능에 영향을 줄 수 있습니다.
-
서비스 확장 및 개선의 어려움:
- 기능을 추가하거나 변경하기 위해서는 전체 서버를 업데이트해야 할 수 있습니다. 이는 유연성과 빠른 개발을 어렵게 만들 수 있습니다.
이러한 문제점들을 gRPC를 사용하여 엔진과 API 서버를 분리함으로써 부분적으로 극복할 수 있습니다. 엔진과 API 서버의 분리는 서비스의 성능, 확장성, 유지보수성을 향상시킬 수 있습니다.
저는 이러한 아키텍처와 엔진을 처음 도전해보는 터라, 많은 공부를 할 각오가 되었습니다.
2.3 소프트웨어 디자인 원칙
단일 책임 원칙 (Single Responsibility Principle - SRP)
각 클래스나 모듈은 한 가지 기능만을 가지고 있어야 합니다. 예를 들어, API 서버는 사용자 요청을 받고 처리하는 역할만을 하며, 엔진은 경로 계산 및 안내 생성에 집중해야 합니다. 이는 유지보수 및 확장에 도움이 됩니다.
분리된 인터페이스 (Separation of Concerns)
관심사의 분리를 통해 각 부분이 독립적으로 변경될 수 있도록 합니다. API 서버와 엔진은 서로 독립된 서비스로 분리되어야 하며, 인터페이스를 통해 통신합니다. 이는 유연성을 높이고 시스템을 보다 모듈화할 수 있게 해줍니다.
의존성 역전 원칙 (Dependency Inversion Principle - DIP)
고수준 모듈은 저수준 모듈에 의존하면 안 되며, 모두 추상화된 것에 의존해야 합니다. 예를 들어, API 서버가 엔진에 직접 의존하지 않고, 추상화된 인터페이스를 통해 의존해야 합니다.
확장 가능한 아키텍처 설계 (Scalable Architecture Design)
서비스를 설계할 때, 증가하는 트래픽이나 기능 추가에 대응할 수 있는 확장 가능한 아키텍처를 고려해야 합니다. 엔진과 API 서버의 분리는 서비스의 확장성을 향상시키는 중요한 요소가 될 수 있습니다.
2.3 서버 아키텍처
API 서버와 엔진을 분리하고 gRPC를 사용하여 통신하는 것은 서로 다른 기술 스택을 사용하더라도 각각의 장점을 최대한 활용할 수 있는 좋은 방법입니다.
제가 사용하려는 백엔드와 알고리즘 서버는 다른 기술 스택을 사용하기 때문에 다음과 같은 서버 아키텍처를 구상했습니다.
백엔드 API 서버는 JAVA 스프링부트, 경로 엔진은 C++ 기반입니다.
-
API 서버(Spring 기반)
- 사용자와의 상호작용 및 외부 HTTP 요청을 처리합니다.
- 사용자의 출발지와 목적지를 받아 gRPC를 통해 엔진에게 전달하고, 엔진에서 계산된 경로를 받아와 사용자에게 반환합니다.
-
엔진 (경로 탐색 및 안내 생성)
- gRPC를 통해 API 서버로부터 요청을 받아 출발지와 목적지를 받아옵니다.
- 최적의 도보 경로를 계산하고, 보조 기구를 고려하여 안전한 경로를 생성합니다.
- API 서버로 계산된 경로 및 안내 정보를 반환합니다.
이 구조를 사용하면 서로 다른 역할을 하는 두 서버 간에 명확한 역할 분담이 가능하고, 각 서버는 필요한 기술 스택을 자유롭게 선택하여 사용할 수 있습니다. Spring 기반의 API 서버는 사용자와의 상호작용을 처리하고, gRPC 기반의 엔진은 경로 계산 및 안내 생성 등의 핵심적인 작업을 수행하는 것이죠.
그러나 gRPC를 사용할 때는 프로토콜 버퍼(Protocol Buffers)를 사용하여 데이터의 직렬화와 효율적인 통신을 고려해야 합니다. 또한, 네트워크 통신에 대한 안정성과 보안을 고려하여 적절한 방식으로 구성하는 것이 중요합니다.
