#msa
노트 15개
Backend › Architecture
대규모 서비스 기술 스택 해부Netflix·Uber·Reddit·Twitter 같은 대규모 서비스의 기술 스택을 계층별로 겹쳐 보고 반복되는 설계 선택을 정리했다. 데이터 성격별로 DB를 고르는 폴리글랏 저장, 캐시를 조회 가속 이상으로 쓰는 네 가지 방식, 비싼 작업을 큐로 미루고 CDC로 캐시를 맞추는 패턴, 표준화된 이벤트 플랫폼, 카나리 배포 중심의 CI/CD, 자동 버그 수정과 전용 하드웨어까지 다룬다.
Backend › Architecture
대규모 트래픽에서 서비스를 지키는 설계읽기 위주 서비스가 평소의 몇 배로 치솟는 트래픽을 버티는 방법. CDN과 웹 서버로 WAS 앞단에서 부하를 덜고, 미리 만들어 둔 정적 응답으로 빈 화면을 막고, 서킷 브레이커·서비스 디스커버리로 장애 전파를 끊고, 한계치 모니터링과 자동 방어 모드로 사람 없이도 대응하는 구조를 정리했다.
Backend › Architecture
데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성데이터가 여러 서비스·저장소에 흩어질 때 쓰는 패턴을 모았다. DB 변경을 로그에서 읽어 퍼뜨리는 CDC, 상태 대신 이벤트를 저장하는 이벤트 소싱, 읽기·쓰기 모델을 나누는 CQRS, 인덱스 테이블, 최종 일관성을 만드는 네 가지 방법(이벤트·백그라운드 동기화·사가·CQRS), 이벤트와 스키마의 호환성 규칙(Avro, 스키마 레지스트리)까지 다룬다.
Backend › Architecture
마이크로서비스 아키텍처큰 시스템을 비즈니스 기능 단위의 작은 서비스로 나누고, 서비스마다 데이터와 배포를 따로 갖게 하는 구조다. 운영에는 API 게이트웨이, 서비스 레지스트리, 인증 서버, 비동기 메시징, 메트릭·로그 수집이 따라붙는다. 서비스 협업은 오케스트레이션과 코레오그래피 두 방식이 있고, 지연에 민감하거나 상태를 메모리에 둬야 하는 시스템에는 모놀리스가 낫다.
Backend › Architecture
메시지 큐와 Kafka메시지 큐를 고르는 기준과 IBM MQ → RabbitMQ → Kafka → Pulsar로 이어진 구조 변화, Kafka의 토픽·파티션·컨슈머 그룹 구조와 빠른 이유(순차 I/O, 제로 카피), 전달 보장 수준(at-most/at-least/exactly once)과 메시지가 유실되는 지점별 대책, Kafka와 RabbitMQ의 차이, 처리 실패와 DLQ, Kafka Connect·Streams·스키마 레지스트리 생태계를 정리했다.
Backend › Architecture
분산 시스템의 통신·데이터 흐름 패턴서비스끼리 주고받는 방식(요청-응답, 비동기 요청-응답, 발행-구독, 경쟁 소비자, 우선순위 큐, 클레임 체크), 데이터가 흐르는 방식(ETL, 배치, 스트림 처리, 이벤트 소싱, CQRS), 여러 서비스를 조율하는 방식(오케스트레이션, 사가, 리더 선출, 분산 락, 앰배서더)을 한 지도로 묶고 각 패턴이 푸는 문제와 대가를 정리했다.
Backend › Architecture
분산 트랜잭션: 2PC와 사가여러 DB·서비스에 걸친 작업을 하나처럼 끝내는 방법을 정리했다. 2단계 커밋(2PC)의 동작과 블로킹·코디네이터 장애 문제, 그 대안인 사가 패턴의 보상 트랜잭션 설계, 보상이 실패할 때의 처리, 격리가 없어 생기는 중간 상태와 대응책(시맨틱 락 등), 코레오그래피·오케스트레이션 구현 비교를 다룬다.
Backend › Architecture
소프트웨어 아키텍처 패턴계층형, 클라이언트-서버, 이벤트 기반, 마이크로서비스, 플러그인(마이크로커널), 헥사고날(포트와 어댑터) 아키텍처를 구조·장점·약점으로 비교하고, 구성 요소·커넥터와 제어·데이터 흐름으로 스타일을 가르는 다섯 계열(데이터 흐름, 호출-반환, 독립 구성 요소, 데이터 중심, 가상 머신)과 문제 모양별 선택 경험칙을 정리한다. 패턴마다 얻는 것과 치르는 것이 다르므로 시스템의 변경 방향과 팀 규모를 보고 고른다.
Backend › Architecture
아키텍처와 API 계층의 진화: 모놀리스에서 페더레이션까지대규모 서비스가 모놀리스 → 서비스 분리(SOA·마이크로서비스) → 매크로서비스로 옮겨 가는 이유와, 그에 맞춰 API 계층이 직접 호출 → 게이트웨이 집계 → BFF → GraphQL 페더레이션으로 바뀌는 흐름을 정리했다. 반대로 모놀리스와 단순한 백엔드로 큰 트래픽을 감당하는 사례와 여러 SaaS API를 묶는 통합 플랫폼도 다룬다.
Backend › Architecture
웹 확장성의 구성 요소: 한 장으로 보는 웹 아키텍처확장 가능한 웹 애플리케이션을 이루는 구성 요소(DNS, 로드 밸런서, CDN, 프론트 웹 서버, 웹 서비스, 캐시, 메시지 큐와 워커, 데이터 저장소, 검색엔진)를 한 장의 지도로 정리했다. 3-Tier와 MSA의 데이터 흐름, 확장의 세 축(복제, 기능 분할, 데이터 분할), HTTP 캐시와 객체 캐시, 비동기 처리와 이벤트 기반 구조, 구간별 보안, 그리고 사람과 팀을 확장하는 법까지 다룬다.
Backend › Architecture
이벤트 기반 아키텍처 설계이벤트 기반 아키텍처는 「무슨 일이 일어났다」는 사실을 발행하고, 관심 있는 쪽이 구독해 반응하게 해서 시스템 사이의 논리적 의존을 끊는다. 이벤트와 커맨드의 구분, 이벤트 계층(앱·내부·외부), 페이로드 설계, 발행 시점의 정합성, 큐와 토픽, 멱등 소비, 순서와 재처리, 조회 모델 분리까지 설계할 때 정해야 할 것을 정리했다.
Backend › Architecture
인증·인가 로직은 어디에 두나: 필터, 인터셉터, API 게이트웨이인증·인가를 컨트롤러마다 넣으면 중복과 누락이 생긴다. 단일 서버에서는 필터·인터셉터·메서드 보안으로, MSA에서는 API 게이트웨이에서 토큰을 검증하고 각 서비스가 자기 리소스의 인가를 맡는 식으로 층을 나눈다. 게이트웨이 우회 차단과 신원 전달 방식이 핵심 주의점이다.
DevOps
쿠버네티스 네트워킹: 서비스, DNS, Ingress, NetworkPolicy파드마다 IP를 주는 네트워크 모델과 CNI, 서비스의 가상 IP가 kube-proxy(iptables·nftables·IPVS) 규칙으로 파드에 닿는 원리, 서비스 유형별 세부 동작, CoreDNS와 이름 해석, 외부로 나가는 트래픽, Ingress·Gateway API, NetworkPolicy, 서비스 메시(Istio·Linkerd), 연결·DNS 문제 진단을 정리한다.
DevOps
쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소브라우저 요청이 로드 밸런서, 게이트웨이, 서비스 메시를 거쳐 파드의 컨테이너에 닿고, 그 트래픽이 Prometheus·Grafana로 관측되기까지의 경로와 각 구성 요소(Terraform, Kubernetes, Helm, Istio, API 게이트웨이)의 역할을 프론트엔드 개발자 관점에서 정리했다.
DevOps
VM과 컨테이너OS 전체를 가상화하는 VM과 애플리케이션 단위로 격리하는 Docker 컨테이너의 차이, Docker의 핵심 개념과 클라이언트·데몬·레지스트리 구조, dockerd·containerd·runc 런타임 계층과 OCI 표준, Docker와 쿠버네티스의 관계, 컨테이너가 많아질 때 필요한 오케스트레이션·오토 스케일링(Swarm·Kubernetes·ECS), MSA에서의 장단점을 다룬다.