시냅스

이 글에서는 EC2 스토리지를 증설 시에도 적용이 되지 않는 문제를 살펴봅니다. Linux File System 의 간략한 설명을 함께 합니다. Amazon EBS 볼륨 - Amazon Elastic Compute Cloud 이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오. docs.aws.amazon.com Amazon EBS 는 유연한 볼륨의 변경을 가능하게 합니다. 필요에 의해 스토리지 용량을 증가시킬 때에도 간편하게 사용할 수 있습니다. EC2 에서는 EBS를 기본 Secondary Storage 로 채택하고 있습니다. 이런 변경에 있어 EC2 인스턴스의 EBS 볼륨 크기를 증가시켰음에..

이 글에서는 Full-Text Index + Search 에 대한 설명과 프로젝트에서 사용하게된 이유, Full-Text Search 를 JPA 에서 사용하는 방법을 설명합니다. 현재 진행하고 있는 프로젝트는 공연에 대한 예매시스템을 구축하고 있습니다. 사용자들은 공연에 대한 정보를 확인하거나 예매할 때 검색을 사용하기에 기능을 구현할 필요가 있었습니다. 여기에 고민한 것은 Elasticsearch 와 MySQL 의 Full-Text Search 였습니다. Elasticsearch 는 검색에 대한 분명한 장점이 있습니다. 자체적으로 분산 아키텍처를 구축하고 데이터를 샤딩하여 저장하고 역 인덱스를 통한 빠른 데이터 참조를 가능하게 합니다. 다만 구축하려는 검색기능은 높은 가용성이나 정확성을 요구하지 않고 ..

동시성 문제 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..