전체 글

기본적으로 검색 쿼리를 작성할 때, 기본적을 와일드카드를 사용하여 LIKE 검색을 이용하는 것을 떠올릴 것이다. 이 방법은 가장 기본적이며 사용하기 쉬워 어렵지 않게 적용을 할 수 있으나, 데이터가 많아지면 무조건 성능 이슈를 맞이하게 된다. LIKE를 사용할 때 크게 고려해야 할 부분은 Index 설정에 대한 고려와 와일드카드의 쓰임 그리고 풀스켄에 대한 고려 등이 있을 것 같다. 이에 대한 대안이 될 수 있는 기능으로 MySQL의 Full-Text Search 기능이 있으며, 이 기능에 대한 간단한 배경, 검색 메커니즘, 활용법 등에 대한 내용을 다루려고 한다.# Full-Text Search란?Full-Text Search는 데이터베이스에서 텍스트 데이터를 검색하기 위한 기술로, 특정 키워드나 문장..

이전 글 [Node.js] Node.js의 가비지 컬렉션 (Garbage Collection, GC) 1 _ V8 엔진의 메모리 구조 (Stack과 Heep)사내 서비스 개선 보고서 중 Node.js 기반으로 구동하고 있는 애플리케이션의 안정화에 대한 내용을 보게 되었다. 해당 서비스는 끊김 현상이 지속적으로 있었고 이는 곧 연결 재시도 폭주로 인jangbageum.tistory.com  이전 글에서는 V8 엔진과 V8 엔진의 메모리 구조에 대해 간단하게 알아보았다.이러한 메모리 구조에서 동적인 데이터를 어떻게 관리하는지 가비지 컬렉션을 통해 알아보려고 한다. # 가지비 컬렉션이란가비지 컬렉션 (Garbage Collection, GC)은 자동 메모리 관리의 한 형태이다. 이는 Heap 영역에서 동적으로..

사내 서비스 개선 보고서 중 Node.js 기반으로 구동하고 있는 애플리케이션의 안정화에 대한 내용을 보게 되었다. 해당 서비스는 끊김 현상이 지속적으로 있었고 이는 곧 연결 재시도 폭주로 인해 장애 전파, 트래픽 유실 등의 문제를 야기하였다. 이 방법을  해결하기 위해서 스케일업, 스케일아웃을 진행하였으나 고질적인 프로세스 중단 문제는 해결되지 않았고 민감도를 낮추지 못했다.이 보고서에서는 Node.js 런타임 상의 메모리 사용에 대한 내용을 다루어 해결하려는 시도가 있었으며 이 과정에서 "--max-old-space-size 옵션"에 대한 내용이 등장한다. 단순히 "old space가 뭘까? 그럼 new space도 있나? 껄껄 (진짜 있었다.)" 하는 궁금증과 Node.js를 주로 다루고 있는 나로..

얼마 전에 관리하는 애플리케이션에서 RabbitMQ와 Connection을 유지하고 관리하는 로직이 잘못되어 MQ의 Connection Port를 과도하게 점유하는 이슈와 부딪히게 되었다. 이러한 현상은 의도한 것이 아니었고 Connection 관리는 RabbitMQ 동작 흐름과는 큰 관계가 있는 것은 아니었지만 기본적인 해상도를 높이기 위해 복습 차원에서 RabbitMQ에 대한 기본 지식을 정리하려고 한다.  오늘의 주제는 RabbitMQ에서 메시지를 라우팅 하기 위한 논리적인 개념인 Exchange이다. 이전에 RabbitMQ에 대한 소개를 간단하게 짚고 가려고 한다.  RabbitMQ란? RabbitMQ는 메시지 브로커으로, 애플리케이션 간에 비동기 메시지를 전달해 주는 역할을 한다. 오픈 소스이며..

commit 메시지를 잘못 입력했거나, 혹은 디버깅용 코드를 포함하거나 간단한 실수를 코드에 포함하여 commit 하였을 때, 어떻게 대처를 해야 될까? git reset -soft를 통해 commit을 삭제 후 다시 commit을 하는 방법도 있지만 더 예측 가능하면서 안전하게 직전 commit을 수정하는 방법이 있다.바로 git commit의 옵션 중 --amend 옵션이다. commit 메시지 수정하기직전 commit의 메시지를 수정하려면 아래와 같이 git commit에 --amend 옵션을 사용하면 된다.$ git commit --amend 만약 아래와 같이 마지막 commit 메시지를 "4th commit"으로 작성하려고 했는데, 실수로 "5th commit"으로 작성했다고 가정해 보자.git..

개발을 하다 보면 외부 API를 수없이 사용하게 되고 고려하지 않으면 요청한 API 서버로부터 `429 Too Many Request`라는 곤란한 응답을 받게 된다. Rate Limting은 API Client만 고민하는 것이 아닌 요청을 받고 응답을 내려주는 API Server로부터 고려된 것이고 API Server는 DoS 공격과 같은 공격에 대해 대비하고 서버의 응답 처리량을 관리하기 위해서는 Rate Limiting은 필수로 고려되어야 하는 부분이다. 나는 얼마 전에 429 응답을 마주하게 되었고 요청을 받는 입장이 아닌 요청을 하는 입장에서 어떻게 요청량을 관리해야 될지에 대한 방법론을 몇 가지 알아보려고 한다. (Server와 Client의 방법론은 크게 다를 것 없다.) 429 Too Man..