API Gateway 서비스 API Gateway란 규모에 상관없이 API 생성, 유지 관리, 모니터링과 보호를 할 수 있게 해주는 서비스이다. 말 그대로 Client에서 server로 통신할 때 사용하는 많은 api들의 대문(게이트웨이)과 같은 역할을 한다고 보면 된다. 즉, API가 지나가는 통로인 셈이다. API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리할 수 있다. API 게이트웨이를 등록해주면, 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달하여 관리가 용이해 진다. 사용자가 설정한 라우팅 설정에 따라 각 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할을 하기 때문이다. ..

AWS Lambda Lambda는 AWS가 제공하는 서버리스 컴퓨팅 FaaS 솔루션으로, 함수의 인스턴스를 실행하여 이벤트를 처리한다. 서버리스 ServerLess 서버리스 서버리스 아키텍처 서버리스는 "서버가 없다"라는 뜻인데, 서비스를 하는데 있어 어찌되었든 저장소는 필요하고 서버는 필요하기 때문에 정말로 서버가 없다는 것은 아니다. 따라서 nninzoo.tistory.com 특징으로는 서버를 프로비저닝하거나 관리할 필요 없이 작성한 코드를 실행하게 해주는 서버리스 컴퓨팅 서비스로서 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 별도의 관리 없이 서비스 할 수 있다. 또한 다른 AWS 서비스들과 연동이 용이하고 높은 가용성을 제공한다. 장점 1. 비용절감 람다는 사용자가 필요할 때만 함수를..

CQRS CQRS는 Command Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자로 이름처럼 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다. CQRS는 초기 CQS에서 시작되어 확장되었습니다. CQS는 Command Query Separation의 약자로 시스템에서 처리되는 명령과 조회, 이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리시키는 디자인 패턴입니다. 그렇다면 명령과 조회에 대해서 정의를 내릴 필요가 있습니다. CQRS에서 명령은 상태를 변경하는 작업을 의미하며 조회는 상태를 반환하는 작업을 의미합니다. CQRS 패턴을 마이크로서비스에 적용하여 살펴보겠습니다. 마이크로서비스의 핵심은 서비스별 데이터 저장소를 각..

프로세스 간 통신 요청을 보내는 즉시 수신자로부터 응답이 오길 기대하는 "동기적 방법" 클라이언트-서버 아키텍처의 REST(HTTP)가 대표적 요청을 일단 보내놓고 수신자가 받을 때까지 보관했다가 처리하는 "비동기적 방법" 수신자가 받기 전에 누군가는 메시지를 보관해놓아야 한다 → 메시지 브로커 (메시지 큐) 메시지 브로커가 필요한 이유 분산 애플리케이션에서 프로세스 간의 느슨한 결합(loosely coupled)을 제공하는 것이 가장 큰 장점입니다. 그렇다면 강하게 결합된 시스템에서의 단점은 무엇일까요? 서로 연결되어 있는 시스템 중 한 곳에서 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향이 갑니다. 예를 들어 다음과 같은 상황에서, Server 2에 장애 상황이 발생하면, Server 1..

프로세스 간의 통신 서비스와 서비스가 서로 통신하기 위해서는 인터페이스가 존재해야 하고, 인터페이스가 요구하는 방식대로 커뮤니케이션해야한다. 동기/비동기 HTTP 프로토콜은 기본적으로 TCP(또는 UDP) 연결을 만들고, 이 위에서 요청에 따라 즉시 응답이 오는 형태로 구현이 되어 있습니다. 즉 동기적인 응답을 제공한다. 하지만 세상에는 요청에 따른 응답이 즉시 도착하는 커뮤니케이션만 있지는 않다. 예를 들어, 문자 메시지를 생각해보면 발신자는 수신자가 즉시 메시지를 보고 답장하리라고 기대하지 않는다. 또, 뉴스레터와 같은 구독 서비스를 생각해보아도, 사용자가 구독을 해놓으면 콘텐츠 생산자가 메시지를 정해진 때에 보내주고 사용자는 푸시 알림 등으로 인지하고 소비할 수 있다. 이러한 패턴은 비동기적인 커뮤..

Domain 사전적의미로 '영역', '집합' DDD에서 말하는 Domain은 비즈니스 Domain입니다. 비즈니스 Domain은 유사한 업무의 집합(MPRS-마케팅,구매,연구,영업)입니다. 애플리케이션은 비즈니스 Domain별로 나누어 설계 및 개발 될 수 있습니다. DDD(Domain Driven Design) 비즈니스 Domain별로 나누어 설계하는 방식 기존의 어플리케이션 설계가 비즈니스 Domain에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발하였습니다. DDD에서는 기존의 현업에서 IT로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니케이션을 매우 중요하게 생각합니다. DDD의 핵심 목표는 "Loosly coupling", "High cohesion"입니다. (어플리..

서버리스 서버리스 아키텍처 서버리스는 "서버가 없다"라는 뜻인데, 서비스를 하는데 있어 어찌되었든 저장소는 필요하고 서버는 필요하기 때문에 정말로 서버가 없다는 것은 아니다. 따라서 서버리스는 서버가 없는 백엔드 라는 뜻이 아닌 우리가 직접 서버를 관리하지 않아 신경 쓸 필요없는 경우를 뜻한다. 서버리스 아키텍처는 서버를 직접 관리할 필요가 없는 아키텍처를 칭하고, 서버리스는 사이드 프로젝트나 빠르게 프로토타입을 출시할 때 빠르고 쉽게 제품을 출시할 수 있고, 돈도 매우 절약할 수 있다. 서버리스 탄생 배경 온프로미스 환경과 클라우드 환경 모두 서버의 소프트웨어적인 부분은 사용자가 직접 관리를 해야 한다. 즉, 하드웨어적인 부분만 빌리고 서버 자체는 텅 비어있기 때문에 서버를 돌릴려면 이것저것 소프트웨어..

Microservices Architecture Components MicroService Architecture는 Inner Architecture와 Outer Architecture로 구분할 수 있다. Inner Architecture Inner Architecture는 내부 서비스와 관련된 아키텍처이다. Inner Architecture에서 고려해야 할 부분 서비스를 어떻게 정의할 것인가? 쇼핑몰에서 주문하기 부분과, 카트에 넣기 기능을 같은 서비스로 넣을 것인지, 다른 서비스로 분리할 것인지는 그 비즈니스나 시스템의 특성에 따라 정의되어야 한다. 서비스를 정의하기 위해 고려해야 할 사항은 비즈니스 뿐만 아니라, 서비스 간의 종속성, 배포 용이성, 장애 대응, 운영 효율성 등 굉장히 많다. DB A..