카프카 Consumer를 사용하다 보면 offset을 reset해야하는 경우가 종종 있다. 개발 테스트를 진행하다가 필요에의해 offset을 리셋 실제 production에서 사용중에 예상치 못한 에러 등으로 데이터 누락이 발생하여 일정기간 전으로 다시 offset을 rewind해서 사용하고자 하는 경우 이런 경우에 Consumer API를 사용중이라면 직접 코드 레벨에서 programmatic하게 reset도 가능하고, 아니면 kafka에서 제공하는 reset tool을 이용해서 reset이 가능하다. 카프카 바이너리 설치 카프카 바이너리를 설치한다. Mac에서 brew가 있다면 아래 명령어로 간단히 설치 할 수 있다. (Mac을 기준으로 설명 한다.) ...
크롬 익스텐션(Chrome Extension)은 모두 자바스크립트(Javascript)로 되어있기때문에 웹개발을 해본 사람이라면 그리 큰 노력을 들이지 않고도 개발을 시작 할 수 있다. 하지만 구글에서 익스텐션을 통한 보안이슈가 생기는 것을 막기 위해 다양한 방식으로 익스텐션의 자바스크립트가 실행되는 컨텍스트(context)들을 세분화 시켜두었기 때문에, 이러한 세분화된 컨텍스트에서 각각 어떤 작업이 수행가능한지, 어떻게 분리된 스크립트 컨텍스트간에 통신을 할 수 있는지를 이해하는 것이 생각보다 어렵다. 따라서 본 글에서는 이 부분의 개념에 대해서 자세히 비교 설명하고, 각각의 스크립트들이 잘 동작하도록 미리 설정된 보일러 플레이트 프로젝트를 소개할 예정이다. 대신 크롬 익스텐션에서 사용하는 세부적인 API들이나 manifest관련 세부 설정들은 구글에서 제공하는 문서에도 잘 나와있고, 다양한 sample project에도 케이스별로 잘 나와있기 때문에 따로 정리하지는 않을 예정이다. ...
RDBMS만큼의 정합성과 영속성을 보장할 필요가 없는 데이터들을 빠르게 처리하거나 일정 기간동안만 보관하고 있기 위한 용도로 레디스(Redis), memcached 등의 in-memory 기반 저장소가 많이 사용된다. 그중에서도 Redis는 빠른 성능을 유지하면서도 일정 수준 이상의 persistence를 제공하고, 다양한 native 데이터 구조들을 제공하여 효율적이고 편리한 사용이 가능하게 해주기 때문에 다양한 use-case들이 존재한다. 이 글은 실제 명령어를 날려서 레디스를 직접 사용해보는 것을 배우기 보다는 어떤 in-memory 저장소를 선택할지 고민하는 분들을 위해서 주요 운영 방식, 레디스의 내부 동작 방식 및 특징, 주요 클라이언트들에 대한 정보를 제공하는 쪽에 초점이 맞춰져 있다. ...
MySQL의 InnoDB 엔진은 SQL 표준에 정의된 4가지 트랜잭션 격리 수준(transaction isolation level)을 모두 제공한다. InnoDB 엔진의 트랜잭션 격리 수준 기본값은 REPEATABLE READ이다. MySQL client는 SET TRANSACTION 구문을 실행해서 격리 수준을 변경할 수 있고, server 자체에 옵션을 줘서 모든 client 연결에 대해 동일한 격리 수준을 적용하는 방법도 있다. 그러면 각각의 트랜잭션 격리 수준을 제공하기위해서 MySQL의 InnoDB 엔진이 어떤 방식을 사용하고있는지 가장 많이 사용되는 격리 수준 순으로 각각 알아보도록 하자. 1. REPEATABLE READ 앞서 언급했듯이 REPEATABLE READ 레벨의 경우 InnoDB 엔진에서 사용하는 디폴트 트랜잭션 격리 수준이고 특별한 성능 이슈가 없다면 잘 변경하지 않기때문에 가장 많이 사용된다. REPEATABLE READ를 만족시키기 위해서 MySQL InnoDB 엔진은 아래 두가지 방식을 사용한다. ...
대규모의 많은 요청이 동시에 들어오는 데이터베이스(Database, DB) 어플리케이션의 경우 데이터의 정합성을 유지하면서 최대한 동시성을 높이는 것이 매우 중요한 포인트이다. MySQL InnoDB 엔진의 경우 상황에 따른 여러가지 락(Lock)을 통해서 동시성을 제어하며 이를 통해서 사용자가 설정한 대로 원하는 수준의 트랜잭션 격리 수준(Transaction Isolation level)을 유지해준다. MySQL InnoDB 엔진은 사용자가 필요에 따라 명시적으로 locking read를 할 수 있도록 두가지 쿼리를 제공한다. 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 수정하기 위해 락을 획득하려 할때 (읽어가는 것은 허용) 기다리게 만들고 싶다면 SELECT ... LOCK IN SHARE MODE 사용 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 읽거나, 수정하기 위해 락을 획득하려할 때 기다리게 만들고 싶다면 SELECT ... FOR UPDATE 사용 예) 특정 필드의 값을 읽어온 후 (SELECT), 해당 값을 1 증가시켜서 저장 (UPDATE)하고 싶을때 이 경우 SELECT .. FOR UPDATE를 사용하지 않으면, 여러 트랜잭션이 동시에 접근할 경우 정상 동작 하지 않을 수 있다. 즉, 트랜잭션 2개가 실행되었는데 값이 2만큼 증가되지 않고 1만 증가되어있을 가능성 존재. 먼저 이러한 locking 구문들이 실제 어떤 lock들을 통해서 내부적으로 구현되는지 좀더 자세히 알아보도록 하자. ...
Thread에서 공유 자원에 동시 접근을 제한하기 위해 Lock을 걸듯이 DB에서도 트랜잭션들 간에 같은 동일한 데이터에 대한 동시 접근을 제한하기 위하여 Lock을 설정할 수 있다. Lock을 건다는 것은 그만큼 동시처리량이 줄어든다는 의미이기 때문에 과도하게 사용하면 성능에 문제가 생길 수 있다. 따라서 상황별로 꼭 필요한 수준의 Lock을 걸어서 정합성을 유지하고 최대한의 성능을 내기 위해서는 동시성 이슈가 발생할 수 있는 상황들을 정확히 정의하여 구분하는 것이 매우 중요하다. 다음에 설명하고있는 트랜잭션 격리 수준(Transaction isolation level)을 통해 이 부분을 명확히 정의 할 수 있다. ...
웹사이트 상에서 미리 제작된 영상 템플릿을 제공하고 이에 맞게 사용자가 이미지나 텍스트만 바꿀 수 있도록 툴을 제공한 후 사용자가 만들어낸 데이터 모델을 기반으로 영상을 만들어내는 video generator 기능을 구현하려면 어떻게 해야할까? 일단 웹사이트 프론트엔드에서 이미지를 업로드하고, 텍스트를 입력하고 배치하는 일들은 일반적인 웹사이트 제작에 사용되는 Vue.js나 React 등을 사용해서 빠르게 만들 수 있다. 이렇게 사용자에게 영상을 구성할 수 있는 툴을 제공하고, 해당 툴을 이용해서 생성된 모델을 백엔드 서버에 저장하는 일까지는 일반적인 웹 개발 방식을 이용하면 어렵지 않게 만들어 낼 수 있다. ...
MySQL에서 벌크 인서트를 실행할때 내부 동작을 찾아보다 보니, 어찌어찌 MySQL InnoDB 스토리지 엔진 내부에서 AUTO_INCREMENT(오토인크리먼트)를 어떤식으로 핸들링하고 있는지가 더 궁금해져서 MySQL 레퍼런스 문서(MySQL 5.7 기준)를 읽으면서 아래 내용을 요약해보았다. 이제까지 AUTO_INCREMENT 컬럼에 대해서 아무 고민없이 값이 자동으로 잘 증가하겠거니 하고 사용해 왔을텐데, 내부적인 동작 방식을 정확히 이해해서 concurrency를 높여서 성능을 향상시킬 수 있는 튜닝 포인트를 확인해 보자. 인서트의 종류 구분 설명에 들어가기에 앞서 다양한 상황을 좀더 쉽게 설명하기 위해 인서트 구문의 종류를 구분해보면 다음과 같다. ...
Size Filter Off Size Filter On Size Filter Off Size Filter On (There should NOT be grayish color on the borders of the image) ...
“클라우드플레어(Cloudflare)를 적용만 하면 당신의 사이트의 속도를 빠르게 할 수 있다” 라는 클라우드플레어 광고 문구를 보고 도대체 클라우드플레어가 중간에서 어떤일을 하는지 궁금해서 조금 자세히 찾아보았다. 사이트 접속시에 어떤 일이 일어날까? 사용자가 http://example.com 주소를 입력했을때 일반적으로는 DNS에 example.com을 조회하면 그에 해당하는 서버의 IP주소를 알려주고, 해당 IP주소로 실제 HTTP요청이 일어난다. 하지만 클라우드플레어(Cloudflare)를 사용하게되면 모든 요청이 클라우드플레어 서버를 먼저 한번 거친 후, 필요한 경우에만 실제 서버의 IP주소까지 요청이 도달한다. 일반적인 접근: DNS -> Server IP 클라우드플레어 설정 후: DNS -> Cloudflare Server(CDN) -> Your IP (Origin) ...