안녕하세요,
교보DTS 클라우드사업팀 DevOps파트 김재욱입니다.
2023년 9월, 자사 클라우드 빌링시스템인 ‘OCKI’ 개발을 완료하였습니다. OCKI 개발 팀에서는 설계 단계부터 MSA를 지향하며 아키텍처를 설계하였고, 현재는 크게 3개의 서비스 단위로 나누어 구축된 OCKI 시스템을 운영 중에 있습니다.
아마존, 넷플릭스와 같은 빅테크 기업들의 성공적인 MSA 도입 사례 이후, 많은 국내외 많은 기업들이 MSA 구조를 택하고 있습니다. 본 문서에서는 MSA와 관련된 REST API 및 API Gateway 기술에 대해 소개하고, 이들이 어떻게 현대적인 소프트웨어 개발을 지원하는지 살펴보겠습니다.
MSA란?
MSA에 대한 명확한 사전적 정의는 아직 존재하지 않습니다. 하지만 요즘의 많은 자료와 개발 기법에서 사용되는 것처럼, MSA란 작고 독립적으로 배포 가능한 각각의 기능을 하는 서비스들로 구성된 아키텍처라고 말할 수 있을 것 같습니다. 흔히 통용되는 MSA의 특징은 다음과 같습니다.
1. 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)의 일종입니다.
2. 서비스는 기능 별로 분류됩니다.
3. 서비스의 교체가 쉽습니다.
4. 각 서비스의 최적인 개발 언어, DB, HW, 소프트웨어 환경을 사용하여 구현할 수 있습니다.
5. 각 서비스는 독립적인 배포가 가능합니다.
이미지 좌측의 모놀리식(Monolithic) 구조에서는 단순히 다른 함수를 호출하는 식으로 프로세스 간의 통신이 이루어집니다. 하지만, 이미지 우측의 마이크로서비스(Microservice)에서는 그렇지 않습니다. MSA 구조는 서비스 단위로 나누어져있는 분산 시스템(Distributed System)이기 때문에, 서비스 간의 통신을 구현해야 할 필요가 있습니다. 이러한 통신을 IPC(Inter-Process Communication), 프로세스 간 통신이라고 합니다.
| 일대일(One-to-One) | 일대다(One-to-Many) | |
|---|---|---|
| 동기(Synchronous) | 1) 요청/응답 | |
| 비동기(Asynchronous) | 2) 알림 3) 요청/비동기 응답 | 4) 발행/구독 5) 발행/비동기 구독 |
통신 방식을 나누는 방식은 하나의 요청이 서비스를 실행하는 개수로 나누어 볼 수 있습니다. 하나의 요청이 하나의 서비스를 실행하면 일대일(One-to-One), 하나의 요청이 여러 개의 서비스를 실행하면 일대다(One-to-Many)로 구분합니다.
다음으로, 동기 여부에 따라 나누어볼 수도 있습니다. 동기(Synchronous) 방식은 요청을 보낸 후 응답이 올 때까지 기다리는 방식, 비동기(Asynchronous) 방식은 요청을 보낸 후 응답을 기다리지 않고 다음 요청을 실행하는 방식입니다.
일대일(One-to-One)
1. 요청/응답 : 클라이언트가 요청 (1개 서비스) – 요청에 대한 응답을 받는 형태 (동기 방식)
2. 알림 : 클라이언트가 요청 (1개 서비스) – 요청에 대한 응답은 받지 않는 형태 (비동기 방식)
3. 요청/비동기 응답 : 클라이언트가 요청 (1개 서비스) – 비동기로 응답
일대다(One-to-Many)
4. 발행/구독 : 클라이언트가 메시지 발행 (N개 서비스) – 해당 메시지에 관심 있는 서비스만 메시지 소비
5. 발행/비동기 구독 : 클라이언트가 메시지 발행 (N개 서비스) – 일정 시간 동안 서비스 응답을 기다림
대표적인 IPC 기술로는 동기 요청/응답 기반의 REST, Apache Thrift, gRPC 그리고 비동기 메시지 기반의 AMQP, STOMP 등이 있습니다.
그 중에서도 가장 범용적이고 많이 사용되는 REST API에 대해 더 자세히 알아보도록 하겠습니다.
MSA와 REST API
REST API란?
REST(Representational State Transfer)란 어떤 자원에 대하여 HTTP URL 및 HTTP Method(GET, POST …)를 통해 CRUD(Create, Read, Update, Delete) 연산을 수행하는 것을 의미합니다.
REST의 구성 요소
1. 자원 (Resource) : HTTP URI
각 자원의 고유한 식별자인 URI(Uniform Resource Identifier)를 통해, 리소스 식별 및 위치 지정에 사용합니다
2. 행위 (Verbs) : HTTP Method
REST는 HTTP 메소드를 이용하여 자원에 대한 특정 작업을 수행합니다. GET(자원 검색), POST(자원 생성), PUT(자원 업데이트), DELETE(자원 삭제) 등의 메소드가 대표적이고, 이 외에도 PATCH(자원 부분 업데이트), HEAD(GET 응답의 헤더 부분만 요청), OPTIONS(허용된 통신 요청) 등이 있습니다.
3. 표현 (Representations) : HTTP Message Payload
자원을 전송하는 형태를 의미합니다. 주로 JSON, XML, HTML 등의 형식으로 이루어집니다.
API(Application Programming Interface)는 애플리케이션, 디바이스처럼 소프트웨어간의 통신을 정의한 것입니다. 정의 내용은 요청, 응답, 데이터 통신을 위한 방법과 규칙을 포함합니다.
정리하자면, REST API란 REST 아키텍처 스타일의 디자인 원칙을 준수하며 구현된 서비스 API를 의미합니다.
REST API의 주요 특징
1. Uniform Interface (인터페이스 일관성)
모든 것을 자원으로 표현하고, 각 자원은 고유한 URI로 식별됩니다.
2. Self-descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 쉽게 이해 가능한 구조로 되어있습니다.
3. 무상태성 (Statelessness)
각 요청 간에 작업을 위한 상태 정보가 유지되지 않습니다.
4. 캐시 가능 (Cacheable)
HTTP 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 인프라를 사용 가능하고 그 중에서도 HTTP가 가진 캐싱 기능 적용이 가능합니다.
5. Server-Client (서버-클라이언트 구조)
서버는 API를 제공하고 클라이언트는 인증, 인가 등을 직접 관리하는 구조로 서버-클라이언트의 역할이 명확하게 구분되어, 서로 간의 의존성이 줄어듭니다.
6. Layered System (계층화)
서버는 다중 계층으로 구성될 수 있어 보안, 암호화, Load Balancing 계층을 추가할 수 있으며, Proxy나 뒤에 나올 API Gateway 같은 중간 매체 이용이 가능해집니다.
REST API는 MSA에서 각 서비스 간의 통신에 주로 사용되며, 느슨한 결합과 유연한 통신을 가능하게 합니다.
위 그림에서 확인할 수 있듯이, MSA 구조에서는 많은 양의 API 통신을 수행하기 때문에 통신에 대한 복잡도가 증가한다면 MSA 구조의 장점을 극대화 하기 어려울 것입니다.
REST API를 방식을 사용하면, 다음과 같이 API 통신에서의 큰 이점들이 존재합니다.
REST API 방식의 이점
- 서비스 간 독립성 확보
MSA의 핵심 가치 중 하나는 각각의 서비스가 독립적으로 개발, 배포, 확장 가능하다는 것입니다. REST API는 서비스 간 통신을 표준화하고, 각 서비스가 서로의 내부 구현에 독립적으로 접근할 수 있게 합니다. 이는 서비스 간의 결합도를 낮추고, 개별적인 업데이트와 확장이 용이하게 합니다.
- 유연하고 확장 가능한 통신 방식
REST API는 HTTP 프로토콜을 기반으로 하며, 이는 거의 모든 플랫폼과 언어에서 지원됩니다. 이는 서로 다른 기술 스택을 사용하는 서비스 간의 통신을 가능케 하며, 플랫폼 독립적인 커뮤니케이션을 제공합니다. 또한, REST의 특성 중 하나인 Stateless한 특성은 확장성과 부하 분산에 매우 유리합니다.
- 자원 표현 및 통일된 인터페이스
REST API는 자원을 표현하고 URI를 통해 접근하는 방식으로 일관성 있는 인터페이스를 제공합니다. 이는 클라이언트와 서버 간의 상호 작용을 효과적으로 만들어냅니다. 또한, REST의 원칙을 따르는 서비스는 자원을 표현하기 위한 표준화된 방식을 채택하므로, 개발자 간의 협업을 용이하게 합니다.
- 보안 강화
REST API는 HTTPS와 같은 보안 프로토콜을 통해 통신하므로 데이터의 안전성을 확보할 수 있습니다. 또한, OAuth와 같은 표준을 통해 인증 및 권한 부여를 효과적으로 처리할 수 있습니다. 이는 서비스 간의 안전한 통신을 가능케 하며, 전체적인 시스템 보안을 강화합니다.
[Hands-On] OAuth2.0/OIDC 표준 프로토콜을 이용한 인증 체계 구축 ( Cognito IDP + Spring Security 연동 및 SSO 로그인)
실제 사례로 자사 ‘OCKI’ 시스템에서도 이러한 특징을 이용하여 인증 체계를 구축한 바 있습니다. 구축 사례에 대해 더 궁금하신 분들을 위 글을 참고하시면 될 것 같습니다.
API Gateway란?
API Gateway란 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또다른 서버입니다. 이 서버는 클라이언트의 요청에 대해 어플리케이션 내부의 마이크로서비스로 라우팅하는 역할을 수행합니다.
다시 말해, API Gateway는 클라이언트-마이크로서비스 간의 중개자로서 주요 역할을 수행하게 됩니다.
API Gateway의 주요 기능
1. 인증 및 인가: 클라이언트의 요청을 검증하고 인증 및 권한 부여를 수행합니다.
2. 로깅 및 모니터링: API 호출 및 서비스 성능을 모니터링하며 로그를 기록합니다.
3. 부하 분산: 여러 마이크로서비스로 요청을 전달하고 결과를 집계하여 클라이언트에게 반환합니다.
API Gateway는 MSA에서, 복잡한 마이크로서비스 아키텍처를 효과적으로 관리하고 확장 가능한 서비스를 제공하는 역할을 합니다. 이를 통해 개발자들은 각 마이크로서비스의 핵심 비즈니스 로직에 집중할 수 있게 되며, 전체 시스템의 유지보수 및 확장이 용이해집니다.
API Gateway의 장점
- 단일 진입점(Single Entry Point):
API Gateway는 클라이언트와 여러 마이크로서비스 간의 중개자로서 단일 진입점 역할을 수행합니다. 이로써 클라이언트는 단일 엔드포인트를 통해 서비스에 접근할 수 있어 편의성이 증가하고, 시스템 구조가 단순화됩니다.
- 프로토콜 및 데이터 변환:
다양한 마이크로서비스가 서로 다른 프로토콜이나 데이터 형식을 사용하는 경우, API Gateway는 이를 효과적으로 변환하여 서로 통신할 수 있도록 합니다.
- 보안 및 권한 관리:
API Gateway는 보안을 강화하고 인증, 권한 부여, 암호화 등을 통해 클라이언트와 서버 간의 통신을 안전하게 관리합니다.
- 로깅과 모니터링:
API Gateway는 클라이언트 및 서버에서 발생하는 로그를 수집하고 모니터링할 수 있어 시스템의 동작 상태를 추적하고 문제를 신속하게 해결할 수 있습니다.
- 부하 분산과 캐싱:
API Gateway는 트래픽을 효과적으로 분산하고 캐싱을 통해 응답 시간을 최적화할 수 있습니다.
- 이중화 및 회복성:
서비스의 이중화 및 회복성을 관리하여 시스템의 안정성을 향상시킵니다.
- 버전 관리:
API Gateway는 서비스의 버전 관리를 지원하여 새로운 기능의 배포나 업데이트가 클라이언트에게 영향을 미치지 않도록 합니다.
API Gateway의 단점
- 단일 장애 지점: API Gateway가 다운되면 전체 시스템에 영향을 미칠 수 있습니다. 따라서 이를 위한 적절한 고가용성 및 이중화 전략이 필요합니다.
- 성능 오버헤드: API Gateway는 추가적인 네트워크 통신 및 데이터 변환을 수행하므로 성능에 영향을 줄 수 있습니다. 최적화된 구현과 적절한 하드웨어 리소스가 필요합니다.
- 복잡성: API Gateway는 많은 기능을 수행하므로 구성 및 관리가 복잡해질 수 있습니다. 적절한 관리 도구 및 자동화가 필요합니다.
- 초기 설정 및 배포 복잡성: 초기에 API Gateway를 설정하고 배포하는 과정이 복잡할 수 있습니다. 특히, 마이크로서비스 수가 증가하면 그에 따라 설정도 복잡해집니다.
- 개발자 의존성: API Gateway에 대한 변경이나 업데이트는 전체 시스템에 영향을 미칠 수 있으므로 개발자 간의 협력과 조정이 필요합니다.
- 커스터마이징 어려움: 일부 상황에서 API Gateway의 기본 동작을 수정하거나 커스터마이징하는 것이 어려울 수 있습니다. 특별한 요구사항이 있는 경우 주의가 필요합니다.
API Gateway의 장점은 분명하지만 위 장단점에서 확인할 수 있듯이 단점도 분명하게 존재합니다. MSA 아키텍처에서 API Gateway 도입을 고려하고 있다면, 시스템에 적절한지 충분히 파악하여 도입할 필요성이 있습니다.
마무리하며..
요즈음 IT 시장에서 오히려 Monolithic 구조보다는 MSA 구조를 흔히 만나볼 수 있게 되었습니다. 단순히 MSA라서 좋은 것이 아니라, 관련 기술을 잘 이해하고 Trade-off를 판단하여 적절하게 구성한다면, 훨씬 더 매력적인 아키텍처를 구축할 수 있을 것이라고 생각합니다.
본 글에서는 두 가지 기술에 초점을 맞추어 작성하였지만, MSA를 지원하는 기술은 더 많이 존재하며, 앞으로도 더 많이 생겨날 것이라고 생각합니다.
이상으로 MSA 아키텍처를 지원하는 REST API와 API Gateway에 관한 포스팅을 마치도록 하겠습니다. 감사합니다.
이미지 출처
- https://www.nginx.com/blog/building-microservices-inter-process-communication/
- Microservices Architecture Components @2018 Gartner, Inc.
- https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html