시냅스

동시성 문제 https://liltdevs.tistory.com/83 프로세스 동기화 Process Synchronization 프로세스 동기화 Process Synchronization Cooperation process 서로 영향을 주는 process thread를 공유하거나, shared memory massage passing 위의 경우 데이터 일관성에 유의해야 한다 => 실행 순서를 보장해야 한다. (I liltdevs.tistory.com 애플리케이션에서 동시성 문제는 빈번히 발생할 수 있습니다. Spring에서 각 Request 는 스레드를 사용하므로 공유자원에 대한 접근이 가능하기 때문입니다. while(i == BUFFER_SIZE) { count++; } while(i == BUFFER..

Session vs JWT 현재 프로젝트에서는 Redis Session Clustering 을 사용하고 있습니다. 사용자 정보에 대해 JWT 대신 Session 을 사용하기로 하였고 이유는 다음과 같습니다. JWT 를 사용하려는 이유는 세션에서 감당하는 부하를 줄이기 위함이다. (혹은 Stateless 하게 유지하기 위해) 다만, JWT 는 header, payload, signature 로 이루어진 구조로 모든 정보들을 노출시키고 있다. (HTTPS 를 사용한다고 하더라도...) 또한 대칭키를 알고 있고 토큰이 탈취당한 상황이라면 너무나도 쉽게 보안에 취약해진다. 이러한 문제를 최소화시키기 위해 Refresh Token 을 사용한다. Access Token, Refresh Token 쌍으로 Access..

이 글에서는 No Offset 방식이 왜 빠른지 이해하기 위한 개념과 예시를 상술합니다. LIMIT MySQL 에서 LIMIT 은 범위를 제한할 때 사용합니다. 쿼리 결과에서 지정된 순서에 위치한 레코드만 가져오고 싶을 때에 유용하게 사용됩니다. SELECT * FROM test_tb LIMIT 0, 10; 위와 같은 쿼리에서 만약 LIMIT 이 없었다면 테이블 풀 스캔을 실행하여 결과값을 반환했을 것입니다. 하지만 이 때 LIMIT 을 사용하면서 MySQL 엔진은 레코드를 10건만 읽은 직후 반환하게 됩니다. 따라서 모든 레코드를 읽어야하는 것 보다 훨씬 부하가 줄게 됩니다. -- 1 SELECT * FROM test_tb GROUP BY first_name LIMIT 0, 10; -- 2 SELECT..

Jenkins 새로운 프로젝트를 진행하며 CI/CD 의 구성을 꽤 우선순위로 잡았다. 워커 인스턴스에서는 Docker로 감싼 NGINX + WAS 여러대를 생각하고 있어 프로젝트 규모가 크지 않지만 여러가지 확장성과 가시성을 고려할 때 Jenkins 를 고려하였다. 배포 시간이 긴 것은 크게 문제가 되지 않을 것 같아, 젠킨스를 프리티어 인스턴스에서 전담하게 하였다. 그리고 무수한 page fault 의 악수 요청이 들어왔다... 1.4 초 라고 써있었지만, 1.4초 뒤에 인스턴스가 먹통이 돼서 움직이지 않았다… (약 1시간 이상 기다렸다…) CPU Usage 가 100% 로 치솟고 메모리가 80% 이상이 되는 기현상을 발견했다. demand paging을 위한 메모리 과할당 상황이 발생한 것으로 판단했..

이 글에서는 커버링 인덱스와 pk 를 활용한 복합 인덱스에 대해 간단한 예시를 통해 설명합니다. 커버링 인덱스 Covering Index는 특정 쿼리의 모든 필요한 데이터를 인덱스에서 직접 얻을 수 있게 하는 인덱스입니다. 이는 테이블 자체에 접근할 필요 없이 인덱스에서 쿼리의 모든 필요한 데이터를 찾을 수 있게 합니다. 커버링 인덱스는 인덱스에서 충족하는 데이터를 갖고 있어 디스크 I/O 를 줄이고, 테이블 락을 줄임으로써 데이터베이스의 전반적인 부하를 감소시켜 성능을 향상시킵니다. 예제1 - 단순 select 테이블은 위와 같은 모습으로 준비했습니다. id 는 pk, auto increment 로 하나씩 올라갑니다. 또한 테이블에는 미리 1,000 만 개의 데이터를 넣어 두었습니다. 커버링 인덱스는 ..

단편화, Fragmentation 단편화, fragmentation 는 기억 장치의 빈 공간 또는 자료가 여러 개의 조각으로 나뉘는 현상을 말한다. 이 현상은 기억장치의 사용 가능한 공간을 줄이거나, 읽기와 쓰기의 수행속도를 늦추는 문제점을 야기한다. https://ko.wikipedia.org/wiki/%EB%8B%A8%ED%8E%B8%ED%99%94 MySQL InnoDB 에서는 PK 혹은 Clustering Index 를 통해 각 레코드를 관리하고 있습니다. Secondary Index와 Clustering Index 는 B+Tree 의 구조를 가지며, Clustering Index는 리프노드에 직접 레코드를 가지고 있고 Secondary Index 는 Clustering Index 의 주소를 갖고..

이 글에서는 MySQL의 Repeatable Read 격리 수준에서 트랜잭션 동작 방식과 트랜잭션 락킹에 대해 설명합니다. 이해를 돕기 위해 간단한 예시를 사용하며 설명합니다. Repeatable Read Repeatable Read 는 InnoDB 기본 격리 수준입니다. 트랜잭션 내에 읽기에 대한 일관성을 스냅샷을 기준으로 보장하며 InnoDB 에서는 Next Key Lock 을 사용하며 Phantom Read 까지 예방합니다. 스냅샷을 기준으로 일관성을 보장한다는 것은, 현재 실행하고 있는 트랜잭션 id 보다 전의 id 를 갖는 언두 로그를 참조한다는 뜻입니다.. 따라서 SELECT 시에 다른 트랜잭션에서 업데이트하며 해당 데이터가 바뀌더라도 현재의 트랜잭션에서는 일관성을 유지합니다. 위와 같은 상황..

HikariCP 설정과 유의사항 maxLifetime 커넥션을 최대 얼마동안 연결 유지 할지에 대한 설정 maxLifetime 에 도달한 커넥션이 사용 중(in-use)이지 않고, 풀에 반납된 상태에서 제거된다. 만약 커넥션이 제거되어 부족한 경우 부족한 커넥션 만큼 새로 생성한다. 이러한 방식은 wait_timeout 에 의해 커넥션이 끊어졌을 경우를 대비한다. 즉 wait_timeout 으로 커넥션이 끊기기를 대비하여 커넥션을 새로 맺는 것 HikariCp 는 네트워크 지연을 고려하여 maxLifetime 을 db의 wait_timeout 설정보다 2 ~ 3초 정도 짧게 줄 것을 권고한다. wait_timeout 이 60초라면 maxLifetime 은 58초가 된다. 만약 maxLifetime 이 w..

InnoDB Locking MySQL 의 InnoDB 에서 사용하는 Locking 기법 Shared Lock, S-Lock 특정 레코드를 읽을 때 사용되는 Lock Shared Lock 끼리는 동시 접근이 가능하다. 하나의 레코드를 여러 트랜잭션이 동시에 읽을 수 있다. 어떤 자원에 Shared Lock 이 하나라도 걸려있으면 Exclusive Lock을 걸 수 없다. 동시에 읽기는 가능하지만, 변경은 불가능하게 한다. e.g. SELECT ... FOR SHARE Exclusive Lock, X-Lock 변경(write) 작업을 할 때 사용되는 lock 이다. Exclusive Lock 이 걸린 레코드에는 다른 트랜잭션에서 변경이나 삭제가 불가능하다. 특정 레코드에 Exclusive Lock 이 걸려있..

Spring MVC Spring MVC 는 웹 애플리케이션 개발을 쉽게하기 위해 지원하는 모듈입니다. Model-View-Controller 패턴을 기반으로 FrontController 패턴을 구현한 DispatcherServlet 을 활용하며 매번 Servlet 을 생성하거나 소멸시켜도 되지 않게 합니다. 흔히 Spring 이라고 하면, Spring MVC 를 떠올리게 되는 경우가 많습니다. Spring 은 전체적인 프레임워크 자체를 말하고, Spring MVC 는 웹 애플리케이션을 위한 모듈이라고 지칭하는 것이 옳은 표현일 것입니다. 그렇다면 Spring MVC 의 정체성을 결정하는 것에는 무엇이 있을까요? 구성요소 DispatcherServlet 모든 클라이언트의 요청을 받아 적절한 컨트롤러로 분배..