🛵꾸준한 꿈틀꿈틀

MySQL MDL(metadata_locks): insert 쿼리가 병목 상태에 빠지는 이유 글에서 이어지는 내용입니다.이 글은 MySQL InnoDB 엔진 기준으로 작성됩니다.이전 글에서 MySQL MDL(metadata_locks)로 인해서 의도치 않게 insert 쿼리가 병목 상태에 빠졌었는데요 🥲이번 글에서는 재발 방지를 위해서 Observability를 추가하는 방법에 대해 기록해보려고 해요.먼저, MDL에 대해서 정확히 이해해야 적절한 metric을 뽑아서 효율적으로 Observability를 확보할 수 있을 거예요.그래서 Metadata Lock(MDL)에 대해서 좀 더 알아보려고 합니다. MySQL Metadata Lock(MDL) 이해하기MySQL은 데이터의 일관성을 유지하고 동시 접근..

최근에 DDL을 실행시키는 과정에서 모든 Insert 쿼리가 대기 상태에 빠져 밀리는 현상을 발견해서 정확한 원인 분석을 진행하고 그 내용을 기록합니다.문제가 발생했던 상황1. datagrip에서 무거운 select 쿼리 실행2. datagrip에서 새로운 세션으로 ALTER TABLE 쿼리를 online DDL로 실행3. server application에서 Insert 쿼리가 대기 상태에 빠짐일반적으로 봤을 때는 오잉 datagrip 뭐가 문제지? 라는 생각이 들 수 있는데요. 자세한 내용은 좀 더 아래에서 풀어보겠습니다.문제 원인은 다음과 같았어요MySQL에서 ALTER TABLE 쿼리는 실행을 위해서 table metadata lock(=MDL)을 획득해야 하고 이 때, Exclusive Lock..

혹시 Zero Copy에 대해서 아시나요? 저도 데이터 엔지니어링을 공부하면서 처음 알게되었고 꽤 흥미로운 메커니즘이었습니다 ㅎㅎ그리고 최근에 kotlin을 활용해서 파일 서빙을 다루는 작업을 진행했던 경험이 있는데, 당시 파일 전송 속도가 꽤 중요한 요소였고 자연스럽게 Zero Copy가 떠올랐습니다.kotlin을 사용하다보니 JVM이라는 도구에서 오는 특성 등도 고민하게 되고 꽤 의미있는 경험이었는데요.그래서 오늘은 Zero Copy에 대해서 간단하게 소개하고 kotlin S3 upload에서 Zero Copy가 가능한지? 등을 공유해보겠습니다 :)먼저, 코드레벨에서 파일 전송 등 local storage(e.g. disk)에서 파일을 읽어서 외부로 보내는 로직을 구성했다면 어떤 과정을 거치게 될까..

이 글은 최근에 있었던 서버 OOMKilled 장애 과정을 기록 및 공유하며 회고하는 글입니다.또한 이 글은 인프라 레벨(cpu, memory)에서의 장애 감지 및 대응 프로세스에 관한 내용을 기록하기 때문에 NPE(Null Point Exception) 같은 코드 레벨에서의 명확하고 단순한 문제는 크게 다루지 않습니다. 여러분들은 서버의 메모리가 부족해 OOMKilled 장애 발생 시 어떻게 대응하시나요?저는 보통 다음과 같은 프로세스로 대응합니다.1. 장애 감지2. 예상되는 원인 범위를 합리적으로 찾고 가설을 세운다. (가설 수립)3. 가설을 검증하기 위해 APM, log 등 단서들을 찾고 가설을 확인하고 원인 범위를 좁혀간다. (가설 검증 및 route finding)4. 위 과정을 반복하여 원인을..

MySQL 실행 계획 분석💡 실행 계획에서 표시되는 각 컬럼이 어떤 것을 의미하는지 알아보자메뉴얼한 작업이나 가끔 쿼리 성능을 확인하고 싶을 때 EXPLAIN 키워드를 통해 MySQL 실행 계획을 살펴보게 되는데, 각 칼럼의 의미에 대해서는 명확하게 정리하거나 알아본 경험이 없는 것 같아서 이번 기회에 이를 정리하고 상기합니다.각 칼럼의 구성은 다음과 같습니다.id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra id 칼럼💡 ID 컬럼은 단순히 SELECT 쿼리 수를 의미하고 해당 SELECT 쿼리를 식별하기 위한 용도로 사용됨.SELECT 쿼리 수를 의미하므로 같은 ID가 여러..

트랜잭션의 격리 수준(isolation level)에 대해서 정확하게 이해하는 것은 애플리케이션 로직을 정확하게 제어하는 것에 있어서 중요합니다. 하지만 격리 수준이 구체적으로 어떻게 동작하는지 정확하게 모르고 있었던 사실을 발견해서 재학습을 위해 내용을 정리합니다. 이 글은 MySQL 기준으로 작성합니다. 트랜잭션 격리 수준 격리 수준은 크게 다음과 같이 4가지로 다음과 같이 나뉘게 됩니다. READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 1번에서 4번으로 갈수록 트랜잭션 간의 데이터 격리 수준이 높아지며, 동시 처리 성능이 떨어지는 것이 일반적입니다. 그리고 보통 SERIALIZABLE 정도가 아니면 크게 성능의 개선이나 저하는 발생하지 ..

최근에 staging 환경에서 단일 인스턴스를 두면서도 무중단 배포를 하고 싶었는데, AWS Elastic Beanstalk을 활용해서 이를 손쉽게 해결할 수 있었습니다. 그래서 저와 같은 고민을 하고 계신 분들을 위해 기록차 이 글을 작성합니다. AWS Elastic Beanstalk은 vercel과 유사하게 코드만 올리면 인프라 관련 세팅을 매우 손쉽고 빠르게 배포할 수 있도록 도와주는 PaaS(Platform as a Service)입니다. Elastic Beanstalk을 사용하면 인프라 관리를 신경쓰지 않을 수 있고 비용도 Elastic Beanstalk 기능 자체는 무료이며 S3, EC2 등 웹 애플리케이션을 저장하고 실행하기 위해 생성한 리소스에 대해서만 지불하면 됩니다. 그래서 리소스를 최..

gRPC는 왜 실용적일까? 이 글은 gRPC를 접한 지 얼마 안 됐거나 새롭게 알아보고 싶은 사람을 대상으로 go, gRPC 그리고 MSA 환경에서의 실무 경험을 기반하여 작성되었습니다. 저는 gRPC는 인프라 구축에 있어 다소 러닝커브가 있는 편이지만 굉장히 실용적이라고 생각합니다. 오늘은 이에 대한 이야기를 해보려고 해요. 먼저, gRPC는 무엇일까요? gRPC는 한 문장으로 다음과 같이 정의해볼 수 있습니다. gRPC는 Protocol Buffer를 IDL(Interface Definition Language)로 사용하는 HTTP/2기반의 RPC 프레임워크입니다. 생소한 단어들이 많을 수 있을 것 같은데요! 잠깐 몇 가지 살펴볼까요? RPC(Remote Procedure Call) RPC는 말 그대..