Event-Driven Architecture Patternloose coupling, 확장성에 필요event sourcesignal, method call, state change, time passingevent는 정보 제공 목적event 처리 여부를 확실히 하려면 event broker 필요lambda 등으로 처리 로직 구현 가능연속적 event가 stream eventEvent-driven architecture최대 한 번 전달retry 없음최소 한 번 전달무응 시 retryExactly once processing중복 요청에 대해서도 한 번만 처리되어야 함을 보장message broker typesstandard(store-based)event를 data store에 저장 후 처리소비 시 삭제e..

Overviewcommunication patterns동기RPC비동기Message QueuePub-Sub요청-응답 패턴blocking call즉각 데이터를 요청하고 받아야 하는 경우 사용초창기에 많이 사용의존성이 발생하므로 좋지 않음RPC서비스의 기능을 함수로 제공보통 IDL 사용해서 proxy 생성하여 사용client와 server에 모두 stub이 있고 stub은 RPC runtime으로 통신RESTful이 곽강받으면서 RPC는 도태gRPC 같이 CNA에 적합한 것을 사용HTTP2 통신 사용 - 기존의 부하기 그대로 사용 가능 및 프로토콜 버퍼를 통해 효율적 직렬화내부 서비스 간 통신에 적합비동기 메시징 패턴single receiverP2P 비동기 메시징procuder가 message broker에 ..

1. CQRS와 RDBMS 샤딩은 목적과 사용 방식이 다름CQRS(명령-쿼리 책임 분리, Command Query Responsibility Segregation)데이터의 쓰기(명령, Command)와 읽기(조회, Query)를 논리적으로 분리하는 아키텍처 패턴입니다.목적:복잡한 도메인에서 읽기와 쓰기 모델을 독립적으로 최적화읽기 부하가 큰 경우 별도의 읽기 DB, 캐시, 비관계형 구조 등을 도입하기 쉬움읽기 모델과 쓰기 모델이 반드시 "DB 구조적으로 분리"되어야 한다는 법은 없습니다.보통 읽기 DB(조회 전용 레플리카, NoSQL, Memory DB) 도입과 함께 쓰는 경우 많음RDBMS 샤딩DB 자체를 여러 샤드(서버)로 물리적 분할해서 scale-out을 꾀하는 방법위에서 논의했듯 운영 난이도/데..

1. MongoDB 샤딩의 기본 원리샤드 키(Shard Key)를 기준으로 데이터를 분할합니다.Hashed Sharding: 해시 함수를 통해 값을 균등하게 분산Ranged Sharding: 값의 범위로 분산이때, 전체 데이터를 작은 조각인 청크(Chunk)로 나누고,각 청크는 샤드 키의 "값 범위(혹은 해시 범위)"를 갖습니다.2. Balancer의 역할각 샤드에 청크 수를 될 수 있으면 evenly(고르게) 분배하는 것이 목적입니다.만약 샤드1에만 청크가 몰렸다면 Balancer가 일부 청크를 샤드2로 “이동”시킵니다.이 때 이동하는 것은 “청크 단위”이지, 샤드 키로 나뉜 각 값의 "범위"나 "해시 정책"은 그대로 존중됩니다.3. "해시 정책 위반"이 발생하는가?해시 정책은 “어떤 값이 어떤 청크에..

Cross-Origin-Resource-SharingCORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 구현된 보안 기능으로, 한 도메인(출처)에서 로드된 웹 페이지가 다른 도메인(출처)의 리소스(예: API, 이미지, 스크립트 등)를 요청할 수 있도록 허용하는 메커니즘입니다.왜 필요한가?웹 브라우저는 기본적으로 Same-Origin Policy(SOP)라는 규칙을 따르는데, 이는 동일한 출처(프로토콜, 호스트, 포트가 모두 같은 경우)에서만 리소스를 공유할 수 있도록 제한합니다. 이는 크로스-사이트 스크립팅(XSS) 같은 보안 공격을 방지하기 위함입니다.하지만 현대 웹 애플리케이션에서는 API 호출이나 외부 리소스 사용이 빈번하므로, CORS를 통해 서버가 특정 출처의 요..

왜 RESTful하지 않은가? (REST의 핵심 원칙 위배)REST(REpresentational State Transfer)는 단순히 "API를 만드는 기술"이 아니라, "웹의 장점을 최대한 활용하여 네트워크 애플리케이션을 만들기 위한 아키텍처 원칙(가이드라인)"입니다. 위 방식은 REST가 정의한 핵심 원칙들을 위배하기 때문에 RESTful하지 않습니다.1. 자원 식별(Resource Identification) 원칙 위배REST의 원칙: 모든 것은 **자원(Resource)**이며, 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별되어야 한다.GET /users/123: "123번 ID를 가진 사용자는 하나의 자원이다."GET /users/123/orders: "1..