분류 전체보기

들어가며실시간 서비스에서 Polling, Long Polling, SSE 3가지 방식을 이용해 HTTP 통신을 할 수 있다.그러나 해당 방식들에는 큰 단점이 하나 존재하는데 먼저 3가지 방식에 대해 알아본 뒤 얘기하도록 하겠다. Polling원하는 응답이 올 때까지 서버로 지속적인 요청을 보내는 방식이다. 단점1. 트래픽 낭비원하는 응답이 올 때까지 지속적인 요청이 필요하므로 트래픽이 낭비된다. 2. 요청 주기로 인해 실시간성 확보 불가능요청-응답 구조를 통해서 통신하는 과정에서 응답 이후 다음 요청이 오기 전까지 약간의 시간 간격이 발생하는데 이때 이벤트가 발생한다면(여기서는 메일이 도착하는 경우) 실제 시간과는 오차가 발생하게 된다. 3. HTTP 오버헤드HTTP 통신에서는 요청에 헤더가 함께 전송되..

들어가며최근 아쉽게도 더 이상 진행하지 못하고 종료하게 되었던 프로젝트 코드를 살펴보다가, 문득 @ResponseeBody와 ResponseEntity 둘 중 어떤 것을 사용할지에 대한 의문이 들었다. 차이점개념의 차이ResponseEntity is like @ResponseBody but with status and headers.스프링 공식 문서에서는 ResponseEntity를 @ResponseBody와 대체로 비슷하지만 header나 status를 묶어서 설정할 수 있도록 했다고 설명하고 있다. @GetMapping("/api/category")public ResponseEntity> getCategory() { return ResponseEntity.ok() .body(new ..

들어가며이번에는 대부분의 상용 RDBMS에서 단순히 Lock으로만 동시성 제어를 할 때보다 처리량을 끌어올리기 위해 사용하는  MVCC에 대해 알아보도록 하겠다. 물론 각 RDBMS마다 동작 방식은 다를 수 있으며, 여기서는 MySQL을 기준으로 설명한다. MVCC(Multiversion Concurrency Control)제어 기법에 따른 두 Lock 간 호환성Lock Read LockWrite LockRead LockOXWrite LockXXMVCC Read LockWrite LockRead LockOOWrite LockOXLock으로만 동시성 제어를 했을 때와 비교해 보면 표만 봐도 트랜잭션 처리량이 더 많으리라는 것을 직감할 수 있다. MVCC 이해를 위한 예제예제를 보기 전에 먼저 알아둬야 할 ..

들어가며이번엔 Lock을 활용해 Concurrency Control을 하는 방법에 대해 설명하고자 한다.3편에 앞서 먼저 1편과 2편을 읽어보는 것을 권한다. Lock을 사용하는 이유write 연산과 read 연산을 할 때 여러 트랜잭션이 같은 데이터에 접근하다 보면 이로 인해 예상치 못한 이상현상이 나타날 수 있다. 그래서 lock을 통해 사용하는 데이터를 잠가두는 방식을 활용하는 것이다.다음은 간단한 예시이다.tx1에서 x에 대한 write lock을 획득하고, tx2에서 lock 획득을 시도하지만 이미 tx1에서 lock을 가지고 있기 때문에 lock을 얻기 위해 대기하게 된다. 그러고 나서 tx1이 x를 20으로 바꾼 뒤 lock을 반환한다. 그러면 드디어 tx2에서 write lock을 얻은 뒤..

들어가며이번엔 트랜잭션의 Isolation Level에 대해 정리할 것이다.Isolation Level에 앞서 Isolation이 보장되지 않았을 때 나타날 수 있는 여러 이상현상(Anomaly)들을 먼저 설명한다. AnomalyDirty Read(1)commit되지 않은 데이터를 읽을 때 발생할 수 있는 현상을 의미한다.첫 번째 예시다. tx2에서 y를 70으로 변경했지만 해당 트랜잭션을 commit하지 않고 rollback함으로써 tx1의 결과에도 영향을 미치는 모습이다. Dirty Read(2)이번엔 변화를 발생시킨 트랜잭션이 rollback되지 않았음에도 Dirty Read가 발생하는 예시다. tx1에서 x를 10으로 변경했고 commit되지 않은 상태에서 tx2를 수행했더니 tx2에서의 x + ..

들어가며DB 동시성 제어는 분량이 꽤 많을 것 같아 4편으로 나누어 작성하려고 한다.이번엔 DB 동시성 제어 이해에 필요한 Schedule에 대해 정리할 것이다. ScheduleSchedule이란 여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operation의 실행 순서를 의미한다. Lost Update다음처럼 H와 K의 계좌 잔액을 조회하거나 변경하는 등의 작업을 수행하는 2개의 트랜잭션이 존재한다고 생각해 보자.해당 케이스에서 Tx2가 실행되고 나서 Tx1은 이 사실을 알지 못한 채 H의 계좌 잔액을 220만 원으로 변경한다. 이때 Tx2의 변경사항은 유실되어 버리는데 이를 Lost Update라고 한다. Serial Schedule, Non-Serial Schedule먼저 봤던 케이스를 ..

들어가며https://eelseungmin.tistory.com/28 Block I/O vs Non-Block I/OBlock I/OI/O 작업을 요청한 프로세스나 스레드가 요청이 완료될 때까지 block 되는 것(요청을 제외한 추가적인 작업이 불가능)을 의미한다. Non-Block I/OI/O 작업을 요청한 프로세스나 스레드를 block하eelseungmin.tistory.com저번주에 Block, Non-Block I/O에 대해 글을 작성했었는데 이번엔 해당 개념들과 연관이 깊은 동기, 비동기에 대해 정리해 보았다.Synchronous와 Asynchronous는 각각 동기와 비동기로 번역되며, 작업 완료 순서의 보장 여부에 따라 두 방식을 구분하게 된다. 동기와 비동기프로그래밍 관점다음 그림을 살펴보..

Block I/OI/O 작업을 요청한 프로세스나 스레드가 요청이 완료될 때까지 block 되는 것(요청을 제외한 추가적인 작업이 불가능)을 의미한다. Non-Block I/OI/O 작업을 요청한 프로세스나 스레드를 block하지 않고 요청에 대한 현재 상태를 즉시 반환하는 것을 의미한다. I/O 결과 처리 방식1. 완료됐는지 계속해서 확인Non-Block I/O 예시를 다시 한 번 살펴보자. 아래 그림에서 파란색으로 표시한 일련의 작업을 완료될 때까지 확인한다고 보면 된다.1번 방식의 단점데이터가 준비되었을 때 바로 작업 완료 여부를 확인하고 응답을 받아오면 좋겠지만, 아래 그림처럼 다시 작업 완료를 확인하기까지 약간의 시간 차가 발생할 수도 있다.또한 반복적으로 작업 완료 여부를 확인하면서 CPU 낭비..

들어가며모두의 회식 백엔드에는 운영을 대비해서 무중단 배포를 적용했었다. 즉, 새로운 버전의 코드가 배포되더라도 사용자 입장에서는 마치 끊김 없이 서비스가 지속되는 것처럼 보이기 위한 것이다.여러 전략 중 Blue/Green 배포 전략을 선택했는데, 백엔드에선 하나의 인스턴스를 사용하고 있으며 인스턴스를 추가하지 않고도 Nginx가 가리키는 컨테이너만 변경하는 간단한 방식이 적합하다고 생각했기 때문이다. 무중단 배포에 대한 조사를 하면서 고민이 필요한 부분이 있었는데 아래에서 이어가도록 하겠다. Graceful Shutdown배포가 이루어질 때 구버전의 서버에서 요청을 처리하다가 응답이 완료되지 않은 시점에 구버전으로 향하는 포트가 끊기고 신버전의 서버가 실행된다고 가정하자.이때 처리가 끝나지 않은 요청..

사용법예시는 MySQL 기준이다. 두 정수의 곱셈 결과를 나타내는 프로시저mysql> DELIMITER $$ -- 기존에 쿼리에서 사용하던 ';' 기호 대신 "$$"가 쿼리의 끝을 나타내도록 변경mysql> CREATE PROCEDURE product(IN a int, IN b int, OUT result int) -- a, b는 input이고 result라는 변수를 output으로 사용함. 아무것도 적지 않을 경우 default로서 IN이 적용됨.BEGIN SET result = a * b;END$$mysql> DELIMITER ; -- 다시 ';'가 쿼리의 끝을 나타내도록 변경mysql> call product(5, 7, @result);mysql> select @result;결과로는 35가 테이블에..

들어가며현재 프로젝트에는 음식점 데이터가 존재하고 이를 각각 제공하는 메뉴에 따라 특정 카테고리로 분류하는 작업이 필요하다. 예를 들면 다음과 같은 방식이다.각 카테고리가 계층적인 구조를 가질 필요가 있다. 고민한 방법들1. 테이블 구조 변경처음으로 고려한 방법이다.Enum은 건드리지 않으면서 음식점 카테고리 엔티티에 부모 엔티티를 나타내는 하나의 외래키 필드만 추가하면 되었기 때문에 해당 방법을 사용했었다.위와 같이 빨간색으로 표시된 하나의 필드만 추가하면 되었기 때문에 변경할 부분이 많지 않았고, 아직 운영 DB에 보존해야 할 데이터가 없기 때문에 구조를 바꾸는 것 또한 간단했다. 사실 이 방법을 사용했을 때의 문제는 카테고리의 depth가 깊어질수록 쿼리가 계속해서 추가적으로 실행되어야 한다는 점이..

배경Java 8에서 등장한 Stream을 사용하면서 다음과 같은 장점들을 체감하게 되었다. 1. 불변성, 즉 스트림을 통해 연산하는 동안 참조하는 변수의 값을 변경하지 않는다.2. 메서드 체이닝을 이용해 연산을 편리하게 조합할 수 있다.3. 익숙해지면 스트림을 사용하지 않을 때보다 가독성이 향상된다. DB에서 조회한 결과 리스트들의 중복을 스트림을 이용해 제거하는 중 겪은 문제 상황을 정리해 보았다. 문제 발생distinct()만 사용한 경우// 중복 제거 후 검색 정책에 따라 정렬List sortedPlaces = Stream.concat( firstPlaces.stream(), secondPlaces.stream()) .distinct() .(중략) .toList();단순히 이 코드만 작성했..