Tag Archives: Amazon API Gateway

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

마이크로 서비스 아키텍쳐(Micro Service Architecture)는 줄여서 MSA라고 부르며 서비스를 기능별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴으로, 기본 컨셉은 하나의 서비스는 한가지 일에 초점을 맞춘다는 것입니다. 또 다른 서비스와의 연계는 API로 구현합니다.

마이크로 서비스 아키텍쳐 구현 프로세스는 크게 4단계로 나눌 수 있는데, 구체적인 처리 절차는 다음과 같습니다.

STEP 1. 기능별로 서비스 어플리케이션 구분

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 2. 서비스 이미지 개발

– 이때 각각의 서비스 어플리케이션은 수샙, 수백여개의 서비스들로 구성되며, 각 서비스는 적절한 CPI, Memory, I/O리소스를 제공받아야 하고, 배포는 빠르고 효율적이어야 함. 참고로 배포 방법은 서버마다 전체 서비스를 적용하는 방법, 서비스를 VM위에 적용하는 방법, 서비스를 도커 콘테이너 위에 적용하는 방법 등이 있습니다.

– 서버별로 서비스를 적용하면 배포 및 서비스의 시작속도가 빠르다는 장점이 있습니다. 그러나 한 서비스 인스턴스가 CPU와 메모리를 모두 사용하는 문제점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 서비스를 VM에 적용하면 서비스별로 고정된 자원을 사용할 수 있고 클라우드 인프라 기능을 활용할 수 있다는 장점이 있습니다. 반면에 의도 해던 기능 외의 다른 VM의 기능은 낭비된다는 단점이 있고, 또 VM 자체를 관리해주어야 하는 오버해드를 가지고 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 마지막으로 서비스를 도커 콘테이너에 적용하는 방법이 있는데, 이는 VM의 장점을 거의 포함하면서 VM 보다는 가볍다는 잇점이 있습니다. 반면에 VM보다는 다소 기능이 떨어 질 수 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 3. 클라이언트에서 필요한 서비스 선택

– 실제 서비스 설계시 클라이언트에서 어떤 기능을 필요로 하는지 모델링을 할텐데, 이때 기능에 중복성을 없애면서 통신을 최소 하는 방향으로의 설계가 바람직합니다.

– 최적화 된 클라이언트의 구현 방법으로 API Gateway와 IPC(Inter-process Communiation)의 두가지 방법이 있습니다.

– API Gateway는 내부 시스템 아키텍쳐를 캡슐화 해서 클라이언트에 적합한 API를 제공하는 방식인데, 이는 주로 Netty, Vert.x, Node.js, Nginx와 같은 비동기, 논블로킹 I/O를 지원하는 플랫폼으로 개발됩니다. 또 통신 규격의 다양화로 이중 가장 효율적인 것을 선택할 수 있다는 장점이 있으며, Auto Scaling 및 IP 주소 변경에 유연하게 대응할 수 있다는 장점이 있습니다. 마지막으로 서비스 오류 핸들링을 용이하게 할 수 있다는 장점이 있는데, 넷플릭스의 Hystrix가 바로 그 예입니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– IPC(Inter-process Communication)은 서비스-클라이언트, 서비스-서비스간 통신 구현 방식인데, 구현 방법에 따라 동기적(request)/비동기적(message-based) 방식으로 나뉩니다. 주로 HTTP Rest나 Thrift 프로토콜을 많이 사용하며, 서비스 오류 핸들링이 용이하다는 장점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 4. 인스턴스 선택/관리

– 서비스가 가상화되먄 여러 인스턴스로 실행 시킬 수 있습니다. 이때 Auto Scaling 혹은 장애 등으로 IP 주소가 변화될 수 있습는데, 장애를 막기 위해 서비스 레지스트리에 자신의 상태를 전달합니다. 이때 상태 전달을 hearbeat이라고 호칭합니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

 

마이크로 서비스 아키텍쳐의 장점을 요약하면 다음과 같습니다.

  • 빠른 복구
  • Scaling
  • 서비스 확장 용이
  • 대규모 장애 확률 감소
  • 협업 용이

 

반면에 마이크로 서비스 아키텍쳐의 단점은 다음과 같습니다.

  • 복잡함
  • 트렌잭션 관리 어려움
  • 다중 테스트
  • 소규모 장애 확률 증가

 

 

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

인터넷 기반으로 서비스를 하는데 서버 없는 아키텍쳐가 있다고 하여 이를 올려 봅니다.

제목에 서버가 없다고 했지만, 서버가 아예 없는건 아닙니다. 정확한 표현은 최소화했다고 보는 것이 맞을 것 같습니다.

 

아래의 사례는 Amazon S3를 기반으로 하는 서비스 아키텍쳐 입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

Amazon CloudFront를 통해 콘텐츠르 배포하고, Amazon API Gateway를 이용하여 필요한 기능은 AWS Lamda를 이용한 사례입니다. AWS Lamda는 하나의 함수를 코드조각으로 구성하여 실행하는 실시간 대응형 서비스입니다.

 

아래의 사례는 모바일 앱의 사례인데, 기능이 좀더 복잡하여 Amazon API Gateway로 분기하여 AWS Lamda를 호출 한 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

아래의 사례는 최소한의 기능만 가지고 서비스를 하는 마이크로 서비스의 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

뭐, 서버가 없다고 했지만, 이 모든것을 Lamda로 대체 가능하다고 주장하고 있습니다. 이를 위해서는 소프트웨어 구현 방법이 기존과는 달라져야 합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

글로벌 비디오 서비스 강자인 넷플릭스는 아마존 AWS를 운영환경으로 사용합니다.

그들이 온라인 비디오 시장에서 티격태격하면서 경쟁하고 있지만, 아이러니하게도 넷플릭스는 아마존과 끈끈한 관계를 유지하고 있습니다. 아마도 아마존은 넷플릭스덕분에 그들의 아마존 프라임 비디오 서비스를 위한 환경 구축을 북미 전역에 쉽게 얻었을 것이라는 생각을 하게 만듭니다. 

서비스 트래픽에 따라 서버 인스턴스를 늘렸다 줄였다 하는 오토스케일링(AWS Auto Scaling)을 기본으로 쓰고 있는데, 이는 다른 서비스 아키텍쳐와 다를 바가 없습니다.

다만, 트래픽이 증가한다고 무작정 오토스케일링을 하지 않고, 그들의 정책에 따라 EC2나 DynamoDB등의 키 컴포넌트를 스케일인, 스케일아웃을 한다는 것이 특징이라고 할 수 있습니다. 아래 그림에서는 Titus Control Plane이라 불리우는 넷플릭스 자체 시스템이 그러한 정책을 관리합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

또 하나 눈여겨 볼 것은 모바일/텔레비젼과의  통신은 Open API를 통해서 하지만, 자체구축하지 않고 Amazon API Gateway를 사용했습니다. 그럼으로 인해서 비용절감 및 보안(Security)을 해결하는 일타이피( ? ) 전략을 구사하고 있습니다.

참고로 위의 스핀네이커(Spinnaker)는 node.js 기반으로 동작하는 넷플릭스의 CDS(Continuous Delivery System)입니다.