MSA (MicroServiceArchitecture)/MSA 개요 및 설계 관련 (9) 썸네일형 리스트형 느슨한 결합과 강한 결합 그림으로 느슨한 결합과 강한 결합을 설명하기 위해, 두 가지 다이어그램을 그릴 수 있다.느슨한 결합 (Loose Coupling)다이어그램: 인터페이스를 통해 구현체를 분리하여 의존성을 줄이는 구조+----------------+ +----------------+| ShoppingCart | | PaymentProcessor|| |강한 결합 (Tight Coupling)다이어그램: 클래스가 다른 클래스의 구체적인 구현에 직접 의존하는 구조+----------------+ +----------------+| ShoppingCart |------>| PayPalProcessor|| | | .. MSA에서 비동기 통신을 해야 하는 이유? 질문. 왜 비동기 통신을 통해서 의존성을 줄여야 하는가? 동기 통신 으로으로는 의존성을 줄일수 없나?비동기 통신을 통해 의존성을 줄이는 이유는 다음과 같다.성능 향상: 비동기 통신은 서비스가 응답을 기다리지 않고 다른 작업을 계속 수행할 수 있게 한다.이는 시스템의 전체 처리량을 증가시킨다.확장성: 비동기 통신은 서비스 간의 결합도를 낮추어 각 서비스가 독립적으로 확장될 수 있게 한다.내결함성: 비동기 메시징 시스템을 사용하면 한 서비스가 다운되더라도 메시지가 큐에 남아 있어 나중에 처리될 수 있다.유연성: 비동기 통신은 서비스 간의 직접적인 호출을 줄여, 서비스의 변경이 다른 서비스에 미치는 영향을 최소화 한다.동기 통신은 서비스 간의 강한 결합을 초래할 수 있으며, 한 서비스의 지연이 다른 서비스의 .. MSA에서 서비스 간 통신 오버헤드를 해결하기 위한 방법 서비스 간 통신 오버헤드를 해결하기 위한 방법은 다음과 같다:동기 통신 최소화:REST API 대신 비동기 메시징 시스템 (예: RabbitMQ, Kafka) 사용.비동기 통신을 통해 서비스 간의 의존성을 줄이고 성능을 향상.데이터 직렬화 최적화:JSON 대신 Protobuf, Avro와 같은 더 효율적인 직렬화 포맷 사용.직렬화/역직렬화 과정에서의 오버헤드 감소.네트워크 지연 최소화:서비스 간의 물리적 거리를 최소화.네트워크 인프라 최적화 및 고성능 네트워크 장비 사용.캐싱:자주 사용되는 데이터를 캐싱하여 통신 횟수 감소.Redis와 같은 인메모리 데이터 저장소 사용.API 게이트웨이 최적화:API 게이트웨이를 통해 공통 기능 처리 및 통신 최적화.로드 밸런싱, 라우팅 최적화.서비스 병합:너무 세분화된.. 3-Tier Architecture를 Micro Service Architecture로 전환할 때 서비스 분할 전략 3-Tier Architecture를 Microservice Architecture로 전환할 때 서비스 분할 전략은 다음과 같다:도메인 주도 설계 (DDD) 적용:도메인 모델을 기반으로 서비스 경계를 정의한다.Bounded Context를 식별하여 각 컨텍스트를 독립적인 마이크로서비스로 분리한다.기능별 분할:각 기능을 독립적인 서비스로 분리한다.예를 들어, 사용자 관리, 주문 처리, 결제 등을 각각의 마이크로서비스로 분리한다.데이터 분할:각 마이크로서비스가 자체 데이터베이스를 가지도록 한다.데이터베이스를 공유하지 않도록 하여 서비스 간 결합도를 낮춘다.API 게이트웨이 도입:클라이언트 요청을 각 마이크로서비스로 라우팅하는 API 게이트웨이를 도입한다.인증, 로깅, 모니터링 등의 공통 기능을 API 게이트.. MSA 아키텍처... # 다시 MSA 아키텍처에 대해서 고민을 해봐야겠다. CQRS 패턴이나 SAGA 패턴 EDA 패턴 등 이너 아키텍처 패턴에 대한 고민이 필요하고 해당 패턴을 가지고 Kubernetes에 어떤 식으로 적용할지에 대한 고민이 필요하고 스프링 클라우드 넷플릭스 유레카를 기반으로 했던 기존의 프로젝트를 어떤식으로 커스텀하여 뺄껀 빼고 남긴건 남겨서 적용할지 등 다시한번 하나하나 테스트 하면서 적용을 해봐야 할거 같다. 단기간이아닌 약간 장기간? 짬짬이 시간날때마다 테스트를 진행 해봐야 겠다. AWS 환경은 비용이 발생하니 로컬 Minikube를 최대한 활용하여, 테스트를 진행한다. Outer Architecture와 Inner Architecture의 이해 Inner Architecture vs Outer Architecture Outer Architecture : MSA가 운영되는 환경을 정의, 예시는 아래와 같다. 우리가 생각하는 일반적인 인프라 아키텍처 구조라고 할 수 있다. Inner Architecture : 실제 비즈니스가 실행되는 각 MSA내 구조를 정의한 아키텍처이다. Inner Architecture는 위에서 설명한 Outer Architecture와는 다른 차이점이 있는데 차이점으로는 위에서 설명한 Outer Architecture는 인프라 기반의 아키텍처를 설명한 반면 Inner Architecture는 실제 비지니스가 실행되는 구조를 정의한 것이다. 내부 서비스와 관련된 architecture. 쉽게 말해 내부 서비스를 어떻게 잘 쪼개.. 쿠버네티스를 활용한 MSA 아키텍처 구성 # MSA... MSA... MSA... 여기저기서 MSA에 혈안이 되어 있다. Micro Service Architecture 즉 MSA는 아래의 그림으로 설명이 가능하다. 구글링을 통해 그나마 잘 설명된 그림을 골라서 가져왔다. MSA를 구현하는데 있어서 쿠버네티스는 필수는 아니다. 하지만 쿠버네티스와 도커 환경없이 MSA를 구현하기 힘들기 때문에 MSA를 말하면 기본적으로 쿠버네티스와 도커 그리고 API Gateway를 통한 서비스 분기 정도 떠올리수 있을거 같다. 자, 그렇다면 나는 AWS를 사용하고 있으므로 AWS에서 제공하는 쿠버네티스 환경인 EKS를 기반으로 MSA를 구현하는 방법에 대해서 말해보자. 기본적인 아키텍처는 아래와 같다. (지극히 개인적인 구조이고, 추상화도 개인적으로 되어 있으.. MSA 아키텍처 설계 시 문제점 및 해결방안 문제점 1. 성능 2. 장애 격리 3. 데이터 동기화 # 성능 - 대용량 트래픽 대응 - 초당 15,000 회의 호출 발생 - 모든 시스템이 대용량 트래픽을 감당하기에는 어려움 # 장애 격리 - 내부 서비스나 DB 장애가 발생해도 서비스는 이상이 없어야 한다. # 데이터 동기화 - 데이터가 분산 되어 있음 해결방안 CQRS 아키텍처 : 명령과 조회를 철저히 분리 C : Command (명령) Q : Query (조회) R : Resposibility S : Segregation 폴리그랏 아키텍처 적용 AWS SNS, SQS 를 사용하요 데이터 동기화 진행 정리 MSA를 꼭 해야되나? 규모의 경제가 바탕이 되어야 한다. 트래픽, 시스템, 인력 이전 1 2 다음
