CS

개요네트워크 시스템에서 처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치이다. 예를 들어 HTTP 통신을 수행하는 클라이언트와 서버가 존재한다고 가정해보자. 서버는 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한하고 싶을 수 있을 것이다. API 요청 횟수가 제한 장치에 선언된 임계치를 넘어서면 해당 클라이언트의 다음 요청은 block 되며 버려지거나, 추후 처리를 위해 큐에 보관된다. 요청이 block된 경우 HTTP status code 429 - Too many requests 를 응답한다. 또한 아래의 HTTP 헤더 값을 사용하여 클라이언트에게 적절한 정보를 응답할 수 있다.X-Ratelimit-Remaining: 윈도 내 남..

단일 모델의 단점 주문 내역 조회 기능을 구현한다고 가정한다. 주문 내역은 여러 애그리거트의 정보를 가져와야 한다. Order에서 주문 정보, Product에서 상품 정보, Member에서 회원 정보, Payment에서 결제 정보 등 여러 애그리거트의 정보를 한 데 모아 응답해줘야 한다. 이렇게 조회를 위해 여러 애그리거트의 데이터가 필요한 경우 구현 방법을 고려해봐야 한다. 애그리거트를 사용하는 경우 각 애그리거트는 애그리거트ID 라는 식별자를 통해 참조하기에 Eager Loading 전략을 사용할 수 없다. 이는 한번의 SELECT를 통해 조회에 필요한 모든 데이터를 불러올 수 없다는 의미이므로, 무의미한 I/O를 발생시켜 성능 오버헤드가 발생할 수 있다. 그렇다고 애그리거트간 참조를 객체 레퍼런스를..

이벤트 이벤트는 여러 애그리거트에 걸처 처리해야하는 작업이 하나의 트랜잭션으로 묶일 필요가 없는 경우 사용하기 좋은 데이터 처리 방법이다. 예를 들어 주문 취소 및 환불 프로세스는 순차적으로 실행되어야 하지만 실제로 트랜잭션으로 묶여 처리될 필요는 없다. 주문 취소는 주문 도메인의 영역이고, 환불은 결제 도메인의 영역으로 분리되어 있다고 가정한다. 시스템 간 강결합 문제 만약 주문 취소와 환불이 하나의 트랜잭션으로 묶이는 경우를 생각해보자. 사용자로부터 주문 취소 요청이 들어왔을 때, 표현 계층은 주문 애그리거트의 상태를 주문 취소로 변경하고, 해당 주문의 결제 정보를 찾아 환불 프로세스를 진행한다. 포인트제도 처럼 결제가 완벽하게 애플리케이션의 내부에서 진행된다면 문제가 없을 것이다. 하지만 보통 결제..

애그리거트의 동시성 문제와 트랜잭션 관리 주문 애그리거트의 루트 엔티티인 Order 클래스가 존재한다고 가정한다. 또, 주문 애그리거트는 주문 상태가 배송 상태가 아닌 경우에만 배송지를 변경할 수 있다는 정책이 존재한다. 만약 하나의 주문 애그리거트에 대해 관리자 스레드가 주문 상태를 배송으로 변경함과 동시에 고객 스레드가 배송지를 변경한다면 문제가 발생할 것이다. 예를 들면 위와 같이, 관리자가 주문 레코드를 읽고(1), 그 다음 고객이 주문 레코드를 읽는다(2). 해당 상태에서는관리자와 고객 모두 본인이 원하는 변경(주문승인 → 배송중, 경기도 → 강원도)이 가능한 상태이다. 여기서 관리자가 먼저 배송승인 상태를 배송중 상태로 변경(3)하고 커밋했다면? 해당 애플리케이션의 주문 정책에 따르면 고객은 ..

도메인? 도메인은 어떤 문제를 소프트웨어로 해결하고자 하는 영역이다. 온라인 서점을 예로 들 수 있다. 하나의 도메인은 하위 도메인으로 나눌 수 있다. 온라인 서점은 회원, 주문, 배송, 결제 등의 도메인으로 나누어진다. 각 도메인의 하위 도메인의 이름이 같다고 해서 같은 도메인이라고 착각하면 안된다. 서로 다른 하위 도메인은 같은 용어를 사용할 뿐, 전혀 다른 의미와 데이터 정보를 가지고 있을 수 있다. 요구사항을 올바르게 이해하고 도메인을 잘 설정하려면 개발자와 전문가가 함께 이야기 해야 한다. 개발자도 도메인 지식을 갖추고 있어야 도메인 전문가가 요구한 것에 가까운 제품을 만들 수 있다. 처음 도메인 모델을 구성할 때 빠지기 쉬운 함정은 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것..

Blocking I/O vs Non-Blocking I/O blocking I/O 와 non-blocking I/O의 차이는 특정 시스템(OS, 웹 서비스, DB 인스턴스 등)에 요청 후 응답을 기다리는 시점에 스레드가 block되어 응답을 받을 때까지 기다리냐(Syncronous), block되지 않고 다른 일을 처리하냐(Asyncronous)의 차이이다. 즉, Blocking I/O는 입출력 작업을 동기적으로 처리하는 것, Non-Blocking I/O는 입출력 작업을 비동기적으로 처리하는 것이다. Non-Blocking I/O 에서 응답을 확인하는 방법 여기서 의문이 생길 것이다. Blocking I/O는 요청 및 응답을 동기로 처리하기에 스레드는 요청한 뒤 응답을 기다리다가 받아서 나머지 작업을 ..

이번 포스팅은 IPC중 HTTP 기반의 동기 통신중 대표적인 REST와 gRPC의 차이를 메시지 포맷과 애플리케이션 설계 순서에 따라 정리해보려 한다. 정의와 장단점, 유의할 점 등을 간단하게만 알아본다. 기술에 대한 깊은 학습은 추후 기술을 사용할 기회가 주어진다면 진행하려 한다. 프로세스간 통신에는 여러 선택지가 있다. 동기적인 요청/응답 통신을 하는 HTTP기반의 REST, gRPC(HTTP 2.0)와 AMQP, STOMP등 비동기 메시지 기반의 통신 메커니즘도 존재한다. 메시지 포맷도 JSON, XML과 같이 인간이 읽을 수 있는 텍스트 포맷부터 avro, Protocol buffer처럼 효율이 우수한 이진 포맷까지 다양하다. HTTP 기반 동기 요청/응답 통신 동기 요청/응답(request/re..

여러 서비스에서의 Message기반 비동기 호출 아키텍처를 구성할 때, Message Driven Architecture, Event Driven Architecture의 선택지가 존재한다. 여기서 Message와 Event의 차이를 정리해보려 한다. 메시징 메시징은 서비스가 메시지를 서로 비동기적(메시지 브로커를 사용하는 경우와 통상적인 경우)으로 주고받는 통신 방식이다. 보통 메시징 기반 애플리케이션은 서비스 사이에 Message Brocker(대표적으로 Kafka, RebbitMQ)를 두어 비동기 통신을 구현하지만, 서비스가 직접 서로 통신하는 BrockerLess 아키텍처도 존재한다. BrockerLess 아키텍처는 통신할 애플리케이션이 가용중이 아니라면 내부적으로 큐를 두는 방식 등을 통해 메시..

체이닝 방식을 이용한 해시 충돌 처리를 구현해보자! 체이닝 방식은 해시 테이블에서 충돌이 발생할 경우 충돌된 키를 연결 리스트 형태로 처리하는 방법이다. 충돌이 발생하면 동일한 해시 버킷에 속한 항목들을 연결 리스트로 연결하여 저장한다. 해시를 저장할 버킷을 링크드 리스트로 선언한다. 링크드 리스트에 키값 멤버를 가진 노드를 저장할 것이다. private static final int DEFAULT_BUCKET_SIZE = 1024; private List[] buckets; private int size; private int bucketSize; public MyLinkedHashTable() { this.buckets = new List[DEFAULT_BUCKET_SIZE]; this.bucketS..