데이터베이스 성능에는 테이블, 쿼리, 설정 등 다양한 수준의 요소들이 영향을 미친다. 최적화를 위해 소프트웨어, 하드웨어 수준에서 조절할 수 있지만 이 글에서는 하드웨어 최적화는 다루지 않을 것이다. 데이터베이스 최적화최적화 방법을 살펴보기 전에 아래 질문으로 어떤 점을 고려해야 하는지 간단히 알아보자.테이블은 올바른 데이터 유형의 열을 가지고 있고 적절한 수의 열을 갖추고 있는가인덱스가 적절히 구성되어 있는가각 테이블에 적합한 스토리지 엔진을 사용하고 해당 엔진의 강점과 기능을 활용하고 있는가디스크 낭비를 줄이고 I/O 시간을 단축하기 위해 압축된 테이블을 사용하고 있는가동시성을 위해 적절한 락 전략을 사용하고 있는가메모리 캐싱 영역을 올바른 크기로 설정했는가 SQL문 최적화sql문은 데이터베이스를 조..

체인지 버퍼 체인지 버퍼는 버퍼 풀에 존재하지 않는, 보조 인덱스 페이지*의 변경 내용을 캐시하는 데이터 구조다. DML 작업으로 인한 변경사항을 일시적으로 저장하고, 이후 다른 읽기 작업으로 인해 해당 페이지를 버퍼 풀에 가져올 때 변경 내용을 병합한다. *보조 인덱스 페이지 : 인덱스 순서와 레코드의 순서가 일치하지 않으므로 레코드의 위치를 나타내는 포인터를 저장한다. 데이터가 변경되면 정렬된 상태를 유지하기 위해 인덱스 페이지가 수정된다. 변경사항을 데이터베이스에 반영하면 보조 인덱스가 수정된다. 하지만 인덱스들은 디스크에 위치하므로 레코드가 변경될 때마다 보조 인덱스를 수정하는 I/O 작업이 발생한다. 이를 방지하기 위해 체인지 버퍼에 보조 인덱스 페이지의 변경 내용을 캐싱하여 불필요한 I/O 작..

프로젝트 진행 중에 DB 과부하를 완화하기 위해 자주 액세스되는 데이터를 Redis에 캐싱한 적이 있다. 하지만 `htop`* 명령을 사용하여 DB가 설치된 서버를 모니터링한 결과, 캐싱을 적용하기 전과 후의 CPU 사용량 차이가 거의 나타나지 않았다. 어째서 아무런 효과가 없었던 걸까?*htop : 리눅스 환경에서 사용되는 프로세스 모니터링 도구 버퍼 풀버퍼 풀은 InnoDB에서 사용되는 캐싱 영역으로, 자주 사용되는 데이터를 메모리에 캐시하여 처리 속도를 향상시킨다. 이는 페이지로 나누어져 다수의 레코드를 저장할 수 있으며 연결 리스트 형태의 페이지들로 구현되어 있다. 버퍼 풀은 LRU 알고리즘을 사용하여 드물게 사용되는 데이터를 캐시에서 제거한다. 자주 사용되는 데이터를 메모리에 유지하여 mysql..

InnoDB란? InnoDB는 mysql에서 사용되는 기본 스토리지 엔진으로, 데이터베이스 테이블을 관리하는 데 사용된다. InnoDB의 장점 어떤 장점이 있길래 InnoDB를 스토리지 엔진으로 사용하는 걸까? InnoDB Recovery - 하드웨어나 소프트웨어 이슈로 서버가 예기치 못하게 종료되어도 InnoDB의 crash recovery가 자동으로 수정을 마무리한다. Buffer Pool - 버퍼 풀*에 테이블과 인덱스를 캐시하여 자주 사용하는 데이터는 메모리에서 처리한다. Index - 레코드에 키를 설정하면 해당 컬럼을 활용한 연산들을 자동으로 최적화한다. Change Buffer - 체인지 버퍼*를 이용하여 삽입, 수정, 삭제 작업을 최적화한다. 위의 장점 외에도 정말 많은 장점들이 있다. 자..

jest 란? jest는 단순함에 초점을 둔 자바스크립트 테스트 프레임워크다. 따라서 대부분의 자바스크립트 프로젝트에서 별도의 설정없이 동작할 수 있도록 설계되었다. jest는 병렬 실행 기능을 제공하는데, 이를 통해 여러 테스트 파일을 동시에 실행하여 테스트 수행 속도를 향상시킨다. 뿐만 아니라 이전에 실패한 테스트를 먼저 실행하여 개발자가 변경된 부분에 대한 결과를 빠르게 감지하고 수정할 수 있도록 돕는다. jest의 특징 별도의 설정없이 동작하도록 설계되었다. 여러 테스트 파일을 동시에 실행하여 성능을 향상시킨다. 이전에 실패한 테스트를 먼저 실행하여 빠른 피드백을 제공한다. 테스트 파일의 소요시간에 따라 실행 순서를 재조정한다. matcher matcher는 결과값을 예상된 결과와 비교하는 데 사..

한 줄만 고쳤는데요 😥개발에 제대로(?) 입문한지 얼마 되지 않았지만 테스트가 중요하다는 말을 정말 많이 들었다. 새로운 기능을 개발하느라 항상 테스트를 미루기 바빴는데 이번 포스팅에서 테스트를 진행해야 하는 이유와 테스트를 작성하는 방법을 알아볼 것이다.테스트를 작성해야 하는 이유버그 픽스, 리팩토링 등 좋은 의도에서 코드를 수정했을지 몰라도 개발자의 실수로 잘 돌아가던 코드가 에러를 발생시킬 가능성이 항상 도사리고 있다. 그렇다면 코드가 변경되었을 때 의도한 대로 동작하는지 확인할 수 있는 방법은 없을까?테스트를 이용하면 코드의 신뢰성을 확인할 수 있다. 코드를 수정한 후 기존에 작성해놓았던 테스트 코드가 실패한다면 이는 코드가 제대로 동작하지 않는다는 걸 의미한다. 즉, 테스트는 새로운 기능을 추..

수정할 게 끝이 없네!! 🤪지난 포스팅에서 블루/그린 무중단 배포를 다뤘다. 하지만 무중단 배포임에도 불구하고 신규 어플리케이션에서 에러가 발생하면 중단된다!! (얼레벌레 무중단 배포,,)이번 포스팅에서는 죽은 어플리케이션으로 트래픽을 전환하지 않도록, 어플리케이션의 상태를 확인하는 과정을 넣어줄 것이다. health check🔗 지난 포스팅- [CD] 블루/그린 무중단 배포 구현하기 1편- [CD] 블루/그린 무중단 배포 구현하기 2편health check는 서비스가 올바르게 작동하는지 확인하는 프로세스다. 장애나 문제를 미리 감지하고 예방할 수 있어 안정성을 향상시킨다.health check의 이점조기 감지 및 대응 : API의 이상을 조기에 감지할 수 있어, 잠재적인 문제를 신속하게 대응할 수 ..

CORS 에러에 부딪히면 항상 origin에다 * 넣어서 해결했는데 드디어 CORS에 대해 공부해보기로 결심했다. CORSCORS란?CORS는 Cross-Origin* Resource Sharing의 약자다. Resource Sharing이 자원 공유인 건 알겠는데 Cross Origin은 뭘까? 크로스 오리진은 서로 다른 출처를 의미한다. 즉, CORS는 서로 다른 출처 간 자원 공유다.*origin : 자원에 접근하는 출처 (프로토콜 + 호스트 + 포트)SOP: Same-Origin Policy😈 origin에다 *를 넣으면 안되는 이유CORS 요청은 보안상의 이유로 Same-Origin Policy에 의해 제한된다. Same-Origin Policy는 다른 출처에서의 접근을 막아 자원을 보호한다. ..