본문 바로가기

전체 글

 (236)
TCP/IP 네트워크 스택 이해하기 TCP/IP의 중요한 성질Connection oriented먼저 두 개의 엔드포인트(local, remote) 사이에 연결을 맺은 후 데이터를 주고받는다. 이때 TCP 연결 식별자는 형태이다. Bidirectional byte stream양방향 데이터 통신을 하고, 바이트 스트림을 사용한다. 이 바이트 스트림은 여러 패킷으로 분할되어 전송되지만, 수신측의 TCP에서 이러한 패킷을 일련의 바이트 스트림으로 재조립하여 응용 계층에서 처리할 수 있게 한다. In-order delivery송신자가 보낸 순서대로 수신자가 데이터를 받는다. 이를 위해서는 데이터 순서가 필요한데 순서를 표시하기 위해 TCP 세그먼트 필드에 32비트의 sequence number 필드가 있다. Reliability through A..
Caffeine을 통한 로컬 캐싱 스프링의 캐시 추상화스프링은 캐시 매니저를 통해 캐싱 방법을 추상화한다. 즉, 특정 캐시 기술에 종속되지 않고 AOP를 통해 적용하여 애플리케이션 코드에 캐시 기능을 추가할 수 있다.  스프링의 캐시 매니저는 다음과 같다. ConcurrentMapCacheManager: JDK의 ConcurrentHashMap을 캐시 저장소로 사용하는 캐시 매니저이다. 별도의 설정을 하지 않으면 기본으로 ConcurrentHashMap을 통해 캐싱된다. 하지만 캐시 관리에서 필요한 다양한 기능들(ex, TTL, TTI)이 부족하여, 실제 서비스에서 사용하기에 기능이 빈약하다.SimpleCacheManager: 기본적으로 제공하는 캐시가 없고 사용할 캐시를 직접 등록하여 사용하기 위한 캐시 매니저이다.EhCacheCach..
좋아요 동시성 제어 과정 문제 상황이 글은 프로젝트에서 진행했던 좋아요 동시성 제어 과정에 대한 글이다. 앞서 게시글 페이징 조회 성능 개선을 위해 좋아요 수(likeCount)를 게시글 엔티티의 필드로 추가하면서, 동시성 제어가 필요해졌다. (https://olsohee.tistory.com/169) 동시성 제어가 필요한 상황은 다음 두 경우가 있다.사용자는 같은 게시글에 좋아요를 2개 이상 누를 수 없다.여러 명의 사용자가 동시에 같은 게시글에 좋아요를 누를 경우 해당 게시글의 좋아요 수가 덮어 씌워지면 안 된다.기존 코드에서 두 경우를 테스트한 결과, 두 경우 모두 데드락이 발생했다. 데드락의 원인은 MySQL이 조회하는 레코드에 외래 키가 있을 때, 외래 키에 해당하는 테이블 레코드에 S락을 걸기 때문이다. 즉, 게시글 ..
예약 동시성 제어 과정 0. 개요이 글은 프로젝트에서 진행했던 예약 동시성 제어 과정에 대한 글이다. 문제 상황은 다음과 같다. 한 트레이너는 특정 시간에 하나의 예약만 받을 수 있다. 그러나 여러 회원이 동시에 요청을 보낼 때 2개 이상의 예약이 완료되는 문제가 발생했다. 즉, 동시성 제어가 필요한 상황이다. 예약 로직은 다음과 같다.트레이너 이메일과 예약 시간을 기준으로 예약 내역을 조회한다. (SELECT)조회된 예약이 없으면 새로운 예약을 생성하여 저장한다. (INSERT)동시성 문제 해결 과정은 다음과 같다.1. 자바의 synchronized 키워드예약 로직 메서드에 synchronized 키워드를 붙이는 방법이다.@Service@Transactional@RequiredArgsConstructorpublic class..
Backlog Queue와 Accept Queue Backlog Queue와 Accept QueueTCP 연결은 3-way handshake 과정을 통해 이뤄진다. 이 과정에서 서버 측 커널은 다음 두 가지 큐를 유지한다.Backlog Queue(SYN Queue): 클라이언트 측이 보낸 SYN 요청에 대해 half-open 요청을 해당 큐에 저장한다.Accept Queue: 3-way handshake가 완료되어 클라이언트로부터 ACK 패킷을 수신하면, 완전히 연결된 요청을 해당 큐에 저장한다.3-way handshake 과정을 통해 두 큐의 쓰임을 살펴보자.클라이언트 측은 연결을 시작하기 위해 서버 측에 SYN을 보낸다. 클라이언트 측은 SYN_SENT 상태가 된다.서버 측이 클라이언트 측으로부터 SYN을 수신하면, 서버 측은 SYN_RECV 상태가..
MySQL의 갭 락과 넥스트 키 락에 대해 프로젝트에서 MySQL을 사용하며 락과 트랜잭션 격리 수준에 대한 문제를 여러 번 마주했었다. 이번 기회에 좀 더 제대로 알고자 글을 쓴다.  InnoDB 스토리지 엔진 잠금InnoDB 스토리지 엔진은 MySQL에서 제공하는 잠금과는 별개로 스토리지 엔진 내부에서 레코드 기반의 잠금 방식을 제공한다. 따라서 MyISAM보다 훨씬 뛰어난 동시성 처리를 제공할 수 있다. 또한 레코드 락뿐 아니라 레코드와 레코드 사이의 간격을 잠그는 갭 락이라는 것도 제공한다. InnoDB 스토리지 엔진은 인덱스 레코드에 락을 건다InnoDB 스토리지 엔진은 레코드를 잠글 때, 레코드 자체가 아니라 인덱스의 레코드를 잠근다. 인덱스가 하나도 없는 테이블이더라도 내부적으로 자동 생성된 클러스터 인덱스를 이용해 잠금을 설정한다...
톰캣이 요청에 스레드를 할당하는 방법 1. 스레드 풀톰캣은 멀티 스레딩을 지원한다. 즉, 동시에 여러 HTTP 요청들을 처리해준다. 그리고 이때 스레드 풀을 사용해서 스레드를 효율적으로 관리한다. 따라서 스레드 풀에 대해 먼저 알아보자. 자바는 One-to-One Threading Model로 스레드를 생성한다. 즉, 자바에서 유저 스레드를 생성하면 해당 스레드는 운영체제 스레드와 1:1로 매핑된다. 따라서 자바에서 스레드를 생성할 때마다 OS 작업이 수행되기 때문에 스레드 생성 비용이 많이 든다. 그리고 스레드가 무한정으로 생성되면 그만큼 메모리를 차지하게 되고 컨텍스트 스위칭이 빈번히 발생한다. 따라서 스레드 풀이란 개념이 등장한다. 스레드 풀은 일정량의 스레드를 미리 만들어 두고 필요한 시점에 꺼내 사용하는 방식이다.자바의 스레드 풀자..
서비스 계층에 @Transactional 어노테이션을 붙이는 것에 대한 고찰 @Transactional 어노테이션스프링은 AOP를 통해 트랜잭션 시작과 종료를 간편하게 할 수 있도록 지원한다. 덕분에 @Transactional 어노테이션을 통해 비즈니스 로직에 트랜잭션 관련 로직이 섞이지 않을 수 있다. 트랜잭션 처리 로직은 프록시 객체가 가져가고, 서비스 계층에는 순수한 비즈니스 로직만 남길 수 있게 해준다. @Transactional을 적용했을 때 동작 과정은 다음과 같다.트랜잭션을 시작하기 위해서는 먼저 커넥션이 필요하다.커넥션을 획득했으면, 해당 커넥션을 통해 auto commit 속성을 false로 설정한다. 즉, 트랜잭션이 시작되었고, 이후 진행되는 로직들은 DB에 바로 반영되지 않고 커밋 시점에 반영된다.이후 서비스 계층 내에서 DB에 접근하는 메서드가 실행되면 해당..

티스토리툴바