MSA (Microservices Architecture)

1) 왜 나왔나 (문제 인식)

• 거대한 모놀리식(monolith) 앱은 배포가 한 덩어리라서 작은 수정도 전체 재배포가 필요함.

• 팀 규모가 커지면 코드 충돌, 빌드 시간 증가, 릴리스 조율 지옥.

• 도메인별 성격이 다른데도 한 가지 기술 스택/DB로 묶여 병목 발생.

• 장애 시 전체가 영향 받는 취약한 복원력.

2) 핵심 아이디어

• 도메인 단위의 작은 서비스로 쪼개고, 각 서비스는 독립 배포/확장 가능.

• 서비스별 데이터 독립(“DB-per-service”), 느슨한 결합, 명시적 통신(API/이벤트).

• 팀도 서비스 단위로 완전 소유(you build it, you run it).

3) 장단점

장점

• 팀/기능 단위 독립 개발·배포, 장애 격리, 필요 서비스만 수평 확장.

• 기술 이기종 허용(Java 옆에 Python 등), 각자의 최적 도구 사용.

• 도메인 주도 설계(DDD)의 Bounded Context와 찰떡궁합.

  

단점

• 분산 시스템 복잡도(네트워크, 데이터 일관성, 디버깅).

• 오버헤드: API 호출 비용, 운영/모니터링 인프라가 필수.

• 잘못 쪼개면 Distributed Monolith(분산돼 있는데 서로 강결합) 

5) 적용 시점 가이드

• 팀/도메인이 명확히 분리되고 릴리스 빈도가 높을 때.

• 기능별 트래픽 편차가 커서 부분 확장이 필요할 때.

• 반대로 초기 소규모 MVP라면 모놀리식 + 모듈화가 더 빠르고 안전.

6) 실무 체크리스트(요약)

• 경계 설정: Bounded Context 먼저, 그다음 서비스 쪼개기.

  예:

  • “주문(Order)”이 쇼핑몰 컨텍스트에서는 “고객이 장바구니를 결제한 기록”을 뜻하지만,

  • 배송 컨텍스트에서는 “배송해야 할 물품 목록”이라는 다른 의미로 쓰일 수 있음.

  • 따라서 주문(Order)이라는 같은 단어도 Bounded Context가 다르면 다른 모델이 될 수 있음.

• 통신: 동기 최소화, 가능하면 이벤트 중심.

  
  

• 데이터: 공유 스키마 금지

  • 의미: 서로 다른 서비스들이 하나의 공용 DB 테이블이나 스키마를 직접 공유하지 않는다는 원칙.

  • 왜냐면?

    • 서비스 간 결합도가 높아짐 → 하나가 바뀌면 다른 서비스도 깨짐.

    • 독립 배포, 독립 확장이 불가능해짐.

  • 대안: 서비스마다 자기 DB를 소유하고, 자기 데이터는 자기만 책임짐.

  • 비유: 자취방 살면서 냉장고를 따로 쓰는 것. 공용 냉장고 쓰면 누가 바꿔놨는지 모르고 맨날 싸움남

• 신뢰성: Idempotency 키, 재시도 규칙, 서킷 브레이커.

  Idempotency 키 (멱등성 키) - 같은 요청을 여러 번 처리해도 결과가 한 번 처리한 것과 동일하게 보장되는 성질.

  재시도 규칙 -  실패한 요청을 일정 규칙에 따라 다시 시도하는 방식.마이크로서비스 환경에서는 네트워크 일시 장애가 흔함. → 한 번 더 시도하면 성공할 확률이 높음

  서킷 브레이커 - 마치 전기 차단기처럼, 특정 서비스가 계속 실패하면 연결을 끊고 잠시 대기하는 패턴, 장애난 서비스를 계속 두드리면 자기 리소스까지 고갈됨

• 관측성: 분산 트레이싱(OpenTelemetry), 표준 로깅/메트릭.

  분산 트레이싱(OpenTelemetry) - 마이크로서비스는 요청 하나가 여러 서비스를 거쳐 처리됨, 주문 -> 결제->출고->배송, 이 중 어디서 지연이 생겼는지 찾기 어려움.

                                                           분산 트레이싱은 요청이 흘러가는 경로를 따라 Trace ID를 붙이고, 각 서비스가 이 Trace ID로 자기 작업을 기록.

  표준 로깅/메트릭 -  서비스마다 로그 형식 제각각이면, 장애 분석할 때 로그를 합쳐 볼 수 없음.Timestamp, Trace ID/Span ID, Log Level(INFO/ERROR), 등

  메트릭 - 서비스와 비즈니스 상태를 수치로 모니터링, 시스템 메트릭: CPU, 메모리, 네트워크 I/O, 애플리케이션 메트릭: 요청 수, 평균 응답 시간, 에러율

• 보안: 제로 트러스트, mTLS, JWT, RBAC.

  제로 트러스트 - “내부 네트워크는 안전하다”는 가정을 버리고, 모든 요청은 항상 검증해야 한다는 원칙. 

                            회사 건물 안에 들어왔어도, 사무실·서버실·창고마다 출입카드 따로 찍어야 들어갈 수 있는 느낌.

  mTLS (mutual Transport Layer Security) - TLS(HTTPS)처럼 서버만 인증하는 게 아니라, 클라이언트와 서버가 서로 인증하는 방식. 통신 경로 암호화 + 서비스 간 신뢰성 확보.

  JWT (JSON Web Token) - 사용자 인증·인가 정보를 담은 서명된 토큰.클라이언트가 로그인 → 서버가 JWT 발급 → 클라이언트가 이후 요청마다 JWT 헤더에 포함.서버는 DB를 다시 조회할 필요 없이 토큰만 검증해도 사용자 권한 확인 가능.놀이공원 입장할 때 손목밴드 차고 다니는 거. 일일이 신분증 확인할 필요 없음.

  RBAC (Role-Based Access Control) -  사용자의 권한을 개인 단위가 아니라 역할(Role) 단위로 관리하는 방식.Admin → 모든 서비스 접근 가능, Manager → 주문/배송만 접근 가능, User → 자기 계정 관련 데이터만 접근 가능

• 테스트: 소비자 주도 계약 테스트(Contract Test) 필수.

  소비자 주도 (Cunsumer-Driven) - 서비스를 사용하는 쪽(Consumer)이 "내가 이 API에서 필요한 건 이 필드와 응답이다”를 계약으로 정의.Provider(제공자)는 이 계약을 반드시 충족시켜야 함. 즉, 계약의 기준은 Provider가 아니라 Consumer. Provider는 자기 입장에서 불필요하다고 생각하는 필드를 없앨 수 있지만, Consumer 입장에서는 그게 핵심일 수 있음.

  계약 테스트(Contract Test) - 서비스 간의 약속(계약, Contract: 요청/응답 형식, 필드 등)이 제대로 지켜지는지 검증하는 테스트.POST /payment → { "amount": number, "currency": string } → 응답 { "status": "OK" }

• 배포: Canary/Blue-Green, 파이프라인 자동화

  수동 배포 (Manual Deployment) -  개발자가 직접 빌드 결과물(.jar, .war, 바이너리 등)을 추출 →scp, ftp 같은 걸로 서버에 업로드 → SSH 들어가서 java -jar ... 같은 명령으로 실행

  카나리아 배포 (Canary Deployment) - 새로운 버전을 전체에 배포하지 않고, 일부 사용자/트래픽에만 먼저 배포해서 안정성 확인 후 점진적으로 확장하는 방식.문제가 있으면 빠르게 롤백 가능, 영향 최소화.

  블루그린 배포(Blue-Green) - 두 개의 환경(Blue=현재 버전, Green=새 버전)을 준비해 두고, 배포 시 트래픽 스위치만 바꿔서 새로운 버전으로 전환하는 방식.문제 생기면 다시 Blue로 트래픽 전환 → 즉시 롤백.

  파이프라인 자동화(CI/CD Pipeline) - 코드 → 빌드 → 테스트 → 배포 과정을 자동화.코드가 푸시되면 자동으로 테스트 & 배포 준비.

  
  

MVC (Model–View–Controller)

1) 왜 나왔나 (문제 인식)

• 화면/입력/도메인 규칙/데이터 접근이 뒤엉키면 유지보수 불가.

• 변경 이유가 달라도 파일이 함께 변해 응집도 낮고 결합도 높음.

2) 핵심 아이디어

• View: 화면 표현(HTML/JSON), 비즈니스 규칙 없음.

• Controller: 요청을 어댑트하고 흐름 제어(검증, 바인딩, 서비스 호출).

• Model: 도메인 상태와 규칙(엔티티·밸류·도메인 서비스).
  (현대 웹에선 Model의 순수성을 지키기 위해 Service/Repository를 추가한 3-계층+MVC 혼합이 일반적)

3) 웹 요청 흐름(스프링 예)

Request → Controller → Service(트랜잭션·규칙) → Repository(JPA/SQL) → Domain Model → Service → Controller → View(JSON/템플릿)

• Controller: REST 엔드포인트, DTO 입출력, 인증 체크.

• Service: 도메인 규칙/트랜잭션 경계, 외부 시스템 협력.

• Repository: 영속화(조회/저장).

• View: Thymeleaf 등 템플릿, 혹은 API JSON.

 “Controller–Service–Repository”는 MVC의 C(Controller) 를 웹 어댑터로 좁히고, M(Model) 의 영속 책임을 Repository로, 규칙을 Service로 깨끗하게 분리한 현대적 변형

4) 장단점/안티패턴

장점

• 관심사 분리, 테스트 용이, 역할이 명확.

• UI 바뀌어도 도메인 규칙 재사용.

안티패턴

• Fat Controller: 검증/규칙/쿼리를 C에 다 넣음 → 서비스로 이동.

• Anemic Domain Model: 규칙이 전부 Service에만 있고 엔티티는 DTO처럼 비어있음 → 핵심 규칙은 도메인으로.

• Active Record 남용: 영속/비즈니스 뒤섞임 → Repository로 분리.

• 양파형 의존 역전 무시: View/Infra가 도메인을 참조해야지, 반대는 금물.

5) 실무 체크리스트

• 입력 DTO ↔ 도메인 모델 분리, 검증은 1) 단순 형식(Controller), 2) 비즈니스 규칙(Service/Domain) 이원화.

• Repository는 질의명세 중심(Specification/Query Object), 비즈니스 규칙 없음.

• 예외는 의미 있는 도메인 예외로 승격, 컨트롤러 어드바이스로 매핑.

  
  

• 

  

  
  

주의: 응답자가 여러 CSP에 체크할 수 있는 복수응답 방식이라 총합이 100%를 초과함.

클라우드 기본 개념

1) 클라우드가 해결한 것

• 물리 서버 구매/설치/확장에 수주~수개월 ⟶ 분/초 단위로 프로비저닝.

• 탄력 확장/축소, 사용한 만큼만 비용 지불(Pay-as-you-go).

• 네트워크/스토리지/보안/모니터링을 API로 관리(IaC).

2) 서비스 모델 한눈에

IaaS → Infrastructure as a Service (서비스형 인프라)
PaaS → Platform as a Service (서비스형 플랫폼)
SaaS → Software as a Service (서비스형 소프트웨어)
FaaS → Function as a Service (서비스형 함수/기능, 서버리스 컴퓨팅 모델)

3) 인프라 기초 용어

• EC2 → Elastic Compute Cloud : 가상 서버(인스턴스)를 제공하는 핵심 컴퓨팅 서비스.

• S3 → Simple Storage Service : 객체 스토리지 서비스, 파일·이미지·백업 저장에 많이 씀.

• RDS → Relational Database Service : 관리형 관계형 DB 서비스 (MySQL, PostgreSQL, Aurora 등 지원).

  
  

  4) 클라우드 설계 6원칙(요약)

1. 운영 우수성: 자동화/관찰/런북.

2. 보안: 암호화·IAM·감사.

3. 신뢰성: 멀티-AZ·오토리커버리·백오프 재시도.

4. 성능 효율: 적합한 컴퓨트/스토리지 선택.

5. 비용 최적화: 서버리스·스팟/RI·오토스케일.

6. 지속가능성: 리소스 효율/탄소 발자국 감소.

   
   

6) 실무 체크리스트

• Stateless 앱으로 설계

  사용자 세션 정보, 진행 중인 작업, 임시 데이터<-서버 자체는 이런 상태를 가지고 있지 않는다. 특정 서버가 죽어도 문제 없음. 다른 서버가 똑같이 처리 가능.배포 시에도 서버 간 상태 싱크 고민 불필요.

• 멀티-AZ 기본,크리티컬은 멀티-리전 복제 검토.

  AZ(Availability Zone) = AWS 같은 클라우드에서 한 리전(Region) 안에 있는 서로 분리된 데이터센터 단위.애플리케이션이나 DB를 최소 2개 이상의 AZ에 동시에 배치.

  크리티컬은 멀티-리전 복제 검토 - Multi-AZ만으로는 “리전 전체 장애”는 막을 수 없음. (예: AWS 서울 리전 전체에 장애 발생).여러 리전에 동시에 데이터 복제 & 서비스 배포.

  
  

•