API Gateway 최근 많은 기업들이 독립적인 기능을 수행하는 Mircro Service가 여러개로 구성된 MSA가 많이 사용되고 있습니다. 하지만 여기서 MIcro Service가 50, 100 그 이상이 된다면 어떨것 같나요? 이 많은 서비스의 엔드포인트를 관리하기 힘들것이고 서비스마다 인증과 인가 과정이 있다면, 이것또한 중복이 된다는 문제점이 있습니다. 이러한 문제점을 해결하기 위해 API Gateway가 등장하게 되었습니다. API Gateway 는 클라이언트와 서비스 사이에서 클라이언트의 요청을 받고 설정에 따라 각 엔드포인트로 대신 요청을 보냅니다. 응답을 받으면 다시 클라이언트에게 응답을 보내는 프록시 역할을 합니다. API Gateway 는 클라이언트의 요청을 라우팅해주는것 뿐만 아니..

헥사고날 아키텍처를 확장성이 좋고 결합도가 낮아 MSA 아키텍처를 구성하는데 있어서 적합한 아키텍처라고 할 수 있습니다! 헥사고날 아키텍처는 Ports and Adapter 패턴이라고도 하며 Layered Architecture의 문제를 보완하기 위해 생겨난 아키텍처 입니다. Layered Architecture의 문제 경직성 계층형 아키텍처는 코드 변경이 일어났을때 다른 계층으로 쉽게 전파될 수 있습니다. 예를 들어 데이터베이스 스키마가 바뀌었을때 비즈니스 로직, 데이터 엑세스 계층 등 다른 계층까지 전파될 수 있어 유지보수를 어렵게 만듭니다. 높은 결합도 계층형 아키텍처에서는 상위 계층이 하위 계층에 강하게 의존하게 됩니다. 이로 인해 변경이 어려워지고, 테스트를 어렵게 합니다. Presentatio..

데이터 쿼리 패턴 MSA 소프트웨어 아키텍처를 설계하면서 생긴 "데이터 쿼리"의 어려움을 해결하기 위한 패턴 API Aggregation 패턴 필요한 데이터를 얻어오기 위해서, 분리된 서비스들 각각에 각 도메인에 대한 데이터를 요청 후 필요에 맞게 Aggregation(조합) 한다. CQRS 패턴 Command(Write, Update, Delete) 작업과, Query(Read) 작업의 Endpoint를 분리하고 Command 에서 발생된 데이터의 변경을 이벤트 발행을 통해 원하는 포맷대로 Query를 위한 전용 데이터 구조를 만들어 이곳에서 복잡한 Query를 담당합니다. 가시성 (Visibility, Observability) MSA 소프트웨어 아키텍처를 설계하면서 생긴 로깅, 모니터링의 어려움(..

모놀리식 아키텍처와 SOA( Service Oriented Architecture ) - 처음 소프트웨어 아키텍처의 시작은 모놀리식 이다. - 그리고 여기서 오는 고통들과 제한적인 환경에서나마 해결하고자 했던 노력에서 나온 아키텍처가 SOA이다. MSA가 나오기 전의 아키텍처.. 모놀리식 - 하나의 어플리케이션이 하나의 서버에 배포 - 단일 코드베이스 - 싱글/멀티 모듈 방식으로 개발은 가능하지만, 근본적으로 하나의 프로세스 SOA - "서비스" 단위로 개발하고, 서비스 간 규격화된 프로토콜(인터페이스)를 사용하여 통신 - 대개 동일한 기술 스택들을 가지고 서비스들을 개발하며, 각 서비스들간이 재사용이 목적 - ESB(Enterprise Service Bus) 라는 개념을 통해, 요청에 대해 어떤 서비스..

모놀리스 아키텍처 ( Monolithic Architecture ) - 모든 종류의 서비스가 하나의 어플리케이션으로 구성되어 있는 아키텍처를 의미한다. 특징 - 하나의 주요 프로세스로 구성 - 모든 서비스가 하나의 DB endpoint를 사용 - 단 한줄만 코드 수정이 되더라도, 모든 어플리케이션의 재배포가 필요 - 싱글 혹은 멀티 모듈로 구성할 수 는 있지만 CI의 단위가 달라질 뿐, CD(배포) 의 범위는 여전히 전체이다. 모놀리스 아키텍처가 일반적이었던 이유 Easy 개발하고 빌드하고 나온 결과를 서버에서 실행시키기만 하면 됐기에 쉽다! No time, No Human Resource 고려할것이 그리 많지 않고 서버 리소스의 효율적인 활용이 가능하다 IDC, Server/DB is very Expe..