왜 공부했는가
: 넷챌린지 경진대회 중 개발한 서버는 FaceID서버, Socket서버(메인 프로세스, webRTC), 모니터링 서버 이렇게 총 세 가지. 그런데 문득 마이크로서비스 아키텍쳐(MSA)라는 키워드가 떠올랐고, 이걸 공부를 해서 내가 개발한 서버를 좀 정리된 형태로 만들 수 있지 않을까 했음.
Microservice Architecture (MSA)
가장 작은 단위의 프로세스들이 서로 통신하며 하나의 큰 시스템 혹은 서비스를 만들어내는 서버 구조.
<그림0. MSA 다이어그램>
MSA는 SOA(Service-oriented Architecture)의 사상을 상속받은 서버 구조의 하나 이므로, MSA를 좀 더 잘 이해하려면 먼저 SOA에 대해 알아야 한다.
Service-oriented Architecture (SOA)
기존의 모놀리틱 서버 애플리케이션의 기능을 비지니스적 의미를 가진 기능단위로 묶어, API를 통해 서비스 라는 단위로 재 조립하여 애플리케이션을 구성하는 구조.
비지니스의 빠른 변화를 수용하기위한 민첩성을 충족하는 아키텍쳐이다.
모놀리틱 구조(Monolithic Architecture)
: 하나의 애플리케이션 내에 모오오든 로직들이 모두 들어가 있는 서버 구조
SOA등장 이전에는 대부분의 서버는 한 애플리케이션에서 모든 기능이 구현되었고, 이는 서버 의존성 관리와 배포 측면에서 거대해진 서비스를 다루는데 큰 단점을 보였다.
나날이 커져만 가는 서비스의 유지/보수를 위해서 각 기능을 분리하여 서버를 구현하게 되었고, 이를 잘 정리한 방법을 이르는 말이 바로 SOA이다.
그러나 사실상 SOA는 실패한 구조가 되었고, 현재 이를 일부 계승하여 단점을 덜고자 만들어낸 서버 구조가 바로 MSA이다.
MSA와 SOA의 차이는 이 블로그의 포스팅에서 잘 정리되어 있다. 아래 그림도 해당 블로그에 포함되어 있으나, 내가 알아보기 쉽게 조금 가공해서 붙여놨다.
<그림1. MSA로 구현된 병원 시스템.>
<그림2. SOA로 구현된 병원 시스템>
API Gateway란?
: MSA를 구현하기 위해 분리된 프로세스들은 클라이언트의 요청에 따라 유기적으로 통신하며 서버 기능을 수행해야 한다. 이를 위해 각 마이크로서비스에선 다른 마이크로서비스에게 자신이 할 수 있는 기능을 노출시키는 수단이 필요하다. 이 때 사용하는것이 바로 API이다.
API란?
프로세스간 틍신할 수 있도록 만들어놓은 규약 (혹은 명세)
간단히 말해서, 프로세스가 다른 프로세스에게 제공하는 UI라고 생각하면 된다.
웹 개발 관점에서 생각하면, 클라이언트가 서버에 요청하는 http프로토콜의 집합이라고 볼 수도 있음.
(원래는 운영체제에서 쓰이는 용어. 사용자가 응용프로그램을 통해 운영체제의 기능을 제어할 수 있게 만든 인터페이스)
API Gateway
: MSA는 말 그대로 많은 수의 마이크로서비스들로 이루어져 있는 구조이다. 그런데, 이 많은 수의 마이크로서비스가 각자의 API를 가지고 있다면...? 요청을 주고 받아야 할 API endpoint가 수십개라면 관리하는 입장에서는 짜증나기 그지없을 것이다.
이런 수요에 맞춰 탄생한 MSA의 컴포넌트 중 하나가 바로 API Gateway. 클라이언트와 마이크로서비스 간의 통신, 서버간의 API통신을 정리하는 서비스 버스 역할을 채널이 바로 API Gateway이다.
<그림3. API Gateway 개요>
++ api서버/ api클라이언트 : api를 제공하는놈/ 사용하는놈 ( 이거 나만 몰랐나? )
앞으로 공부 방향
지금까지 내가 이해한건 위의 내용이 다다. 아직 실제 적용을 위해선 어떤 과정을 지나야하는지 모르기때문에, MSA 구현 프레임웤등을 찾아 공부해 볼 생각이다.
++ 강의를 하나 찾았다. 이거 일단 들어보고, 배운 내용을 하나씩 정리하겠다
레퍼런스...
감사합니다
MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 #1
대용량 웹서비스를 위한 마이크로 서비스 아키텍쳐의 이해
MSA Vs.SOA
Microservice Architecture Tutorial
