MSA (마이크로서비스 아키텍처)

마이크로서비스를 클라우드 네이티브 앱이라고도 부른다.
클라우드 앱 : 우리가 어디에 위치해잇든 알바 ㄴㄴ 사용자처리를 csp에서함
클라우드 네이티브 어플리케이션 : 클라우드에 최적화된 어플리케이션

특징

	msa	모노리스
장애	따로 따로 장애가 생김	장애가 점진적으로 전파가됨
크기	적음	코드량이 방대함
의존성 (커플링)	적음	큼
기술스택	각각모듈별로 다달라도됨	제한됨
연동	빡셈	쉬움
확장	용이	어려움
배포	각모듈별로배포	하나의 변경이 나머지의 모든 재배포를 유발함

• 무정지배포
• msa <-> 모노리스 : 대척점임
  • 모노리스 무적건나쁜건아님
    • 은행처럼 잘안바뀌고,무결성정합성이중요한서비스는 대부분 모노리스임
• cicd
  • 워크로드 많아질시 자동으로 조절(클라우드 특징인듯)
    • 근데보통 클라우드 형식으로구현하니깐..
• 6각형으로 각 모듈을표시
  • 자연계에 존재하는 가장 완벽하고 스테이블한 구조물
• 각각의 모듈에 의존성이 없다보니 따로따로 다른언어프레임워크를써도된다
  • 당연 네트워크로 통신할꺼임
    • http - 동기방식
    • 메세징 큐 방식 - 비동기 방식 느슨한결합
• 독립성과 자치성을 코드의 재사용성 보다 높게 본다
  • 코드와 데이터를 공유하지 않음

제프베조스의 의무사항

어떠한 직접적 서비스간의 연동은 허용 ㄴㄴ
오직 네트워크를 통한 호출 만 허용

• 저장소(db)까지 쪼개야 한다!(물리적으로 따로)
• 연동 허용 ㄴㄴ하는 예
  • 직접 링크 연결
  • 다른 팀의 데이터 저장소를 직접 조회
  • 공유 메모리 사용
  • 백도어 등 모든 비공식 접근

동기식 비동기식에 따른 차이

구분	동기식 구조	비동기식 구조
통신 방식	요청-응답(응답 대기)	요청 후 즉시 반환, 응답은 나중에 콜백/이벤트로 전달
결합도	높음(서비스 간 직접 의존)	낮음(메시지/이벤트 기반, 약결합)
확장성	상대적으로 낮음	높음
장애 전파	한 서비스 장애 시 전체 영향	장애 격리 용이
예시	HTTP, REST	Kafka, RabbitMQ, 이벤트 기반 메시징
처리 흐름	직선적, 순차적 처리	병렬적, 분산 처리 가능
트랜잭션	강한 정합성(2PC 등)	SAGA, 보상 트랜잭션 등 약한 정합성

장애전파

• 동기식: 장애가 상위 호출자에 바로 전파됨(블로킹).
• 비동기식: 장애가 즉시 전파되지 않고, 메시지 큐를 통해 격리됨. 장애가 발생한 서비스(B)가 복구되면 큐에 쌓인 메시지를 다시 처리할 수 있습니다

동기식

• 동기식에서는 A가 B에 요청을 보내고, B의 응답을 받을 때까지 기다립니다.
• 만약 B에서 장애가 발생하면, A의 요청이 블로킹되어 A도 정상적으로 동작하지 못하게 되고, 이 영향이 연쇄적으로 C, D 등 상위 호출 서비스까지 확산됩니다
• 즉, 서비스 간에 "응답을 기다리는" 강한 의존성 때문에 장애가 빠르게 전파됩니다.

비동기식

• 비동기식에서는 A가 B로 메시지를 보내고, 응답을 기다리지 않고 자신의 작업을 계속합니다.
• B가 장애가 나더라도, A는 메시지 큐(브로커)에 메시지를 넣고 바로 반환받기 때문에 A의 처리가 중단되지 않습니다
• 만약 C가 B의 메시지를 받아야만 동작한다면, B가 장애일 때 C는 새로운 메시지를 받지 못할 수 있지만, A와 C는 직접적으로 묶여 있지 않으므로 A의 장애가 C에 직접적으로 전파되지는 않습니다.
• 메시지 큐가 중간에서 완충 역할을 하여, 한 서비스의 장애가 전체 시스템에 즉각적으로 영향을 주지 않도록 격리해줍니다

단일실패지점

하나가 고장나거나 장애가 발생시 전체시스템에 문제가 생기는 지점

이벤트스토밍

crud 중 cud만이벤트임
디비가 바뀌는거시이벤트임용
비동기식 msa에서 사용하는기법

발행구독(pubsub) 알고리즘
kafka가 멀까

이벤트 기반 아키텍처(EDA)
정합성을 어케유지하지?

분해

비지니스관점에서의 분해

ddd+조직

- aggregate(집계): 테이블단위로 쪼개는것을 의미함 - core/supporting - sub domain - core : 말그대로 코어, 핵심경쟁력에 중요하고 버릴 수 없음 - supportive : 외부 서비스 사용고려 가능한정도 - generic : 일반적인 제품으로 다른 제품을이용하거나 사는게 더저렴하거나 기업의 경쟁력과 무관

DDD(도메인 주도 설계)

• 소프트웨어 복잡성을 관리하는 전략적 도구
• Bounded Context(경계가 명확한 영역)로 나누어 설계한는 방법론
• 기술적인 설명엄슴
• 위의 비지니스관점에서는 거의 도메인주도설계가 드감
  • 비지니스가 곧도메인 느낌아닌가?흠...+조직?
• Aggregate 로 일관성과 규칙 유지

생명주기별 DDD

1. 도메인 탐색
   • 탐색적 DDD
2. 소프트웨어 아키텍처
   • 전략적 DDD
3. 소프트웨어 설계
   • 전술적 DDD

바운디드 컨텍스트 매핑(Bounded Context Mapping)

• 공유 커널(shared kernel)
• 소비자 공급자(customer/supplier)
• 준수자(conformist)
• 충돌방지 계층(Anti-Corruption Layer)
• 공개 호스트서비스(Open Host Service)

애자일과의 관계

MSA는 시스템을 작은 단위로 쪼개 독립적으로 배포·수정할 수 있게 하여 빠른 변화 대응을 가능하게 하는 아키텍처임
따라서 같이사용하는 경우가 꽤됨

항목	MSA(마이크로서비스 아키텍처)	애자일 방법론
목적	시스템을 작은 서비스로 분할해 독립적 개발·배포	빠른 피드백과 변화 대응, 고객 중심 개발
구조	각 서비스가 독립적으로 동작, API로 통신	팀이 짧은 주기로 반복 개발(스프린트)
팀 구성	서비스별 소규모 팀, 자율적 운영	크로스펑셔널(다기능) 팀, 자율적 운영
변화 대응	서비스 단위로 빠른 변경·배포 가능	요구사항 변경에 유연하게 대응
데이터 관리	서비스별로 데이터 분리·관리	데이터 구조보다 프로세스와 협업 중시
적용 예시	대규모 웹서비스, 클라우드 기반 시스템	스타트업, 신제품 개발, 변화가 잦은 프로젝트