조그만 사람의 개발 주머니

신뢰성 엔지니어링 그리고 DBA 지난 수년간, 데이터베이스 성능 모니터링은 단일 서버 성능에 대한 심층 분석에 의존했다. 이는, 사후 대응적인 측정에 더 중점을 경향으로 DBA가 게이트키핑으로서 역할할 때의 표준 운영 절차였다. 하지만, 현대의 DBA는 다르다. 구글은 신뢰성 엔지니어링에 대해 다음과 같이 이야기 한다. DBA의 역할은 더욱 복잡해지고 SRE(사이트 신뢰성 엔지니어) 또는 DBRE(데이터베이스 신뢰성 엔지니어)로 바뀌었으며, 팀은 시간을 최적해야합니다. 서비스 수준은 고객이 언제 불만을 느끼는지 정의하는 데에 도움이 되며, 성능 문제와 내부적으로 처리하는 작업 문제를 조율하여 시간을 보다 효율적으로 안배할 수 있습니다. 즉, 성공적인 고객 경험을 보장하기 위해 MySQL을 모니터링하는 것..

MySQL의 논리적 아키텍처 MySQL의 논리적인 뷰는 아래와 같은 그림과 같이 크게 세 개의 계층으로 나타낼 수 있다. 최상위 계층인 클라이언트부터 최하위 계층인 스토리지 엔진까지는 다음과 같이 역할이 분담되어 있다. - 첫 번째 계층 ( 클라이언트 ): 네트워크 기반 클라이언트 / 서버 도구 또는 서버에 필요한 연결 처리, 인증, 보안. - 두 번째 계층 ( 파서, 옵티마이저 등 ): 쿼리 파싱, 분석, 최적화 및 모든 기본 제공 함수 등 MySQL의 대부분의 지능적인 부분. - 세 번째 계층 ( 스토리지 엔진 ): MySQL에 데이터를 저장하고 검색하는 역할. 서버는 스토리지 엔진 API를 통해 통신하고, 이 API는 스토리지 엔진 간의 차이를 숨겨서 쿼리 계층에서는 그 차이를 느끼지 못함. "트랜..

2년간 회사를 다니면서, MySQL 데이터베이스와 관련한 다양한 이슈는 항상 내 곁을 따라왔다. 대게 이슈는 다음과 같은 형태를 가진다. 1. 슬로우 쿼리 최적화 이슈 2. 트랜잭션과 그 격리 레벨에 따른 동시성 이슈 3. 데이터 베이스이 리소스 관리 이슈 - 커넥션, CPU, 메모리 중 하나가 부족하여, 라이브 서비스에 발생한 장애가 그 예다. 위와 같은 이슈를 겪으면서 내가 가졌던 생각을 나열하면, 다음과 같다. 1. 데이터 베이스는 서버가 갖는 불가피한 외부 의존성이기에, 데이터 베이스의 장애는 서비스에 치명적일 수 밖에 없다. 2. 그렇기에, HA와 같이 장애가 발생했을 때의 방어 조치들도 중요하지만, 장애를 피할 수 있다면 최대한 피하는 것이 필요하다. 정리하면, 데이터 베이스의 선제/후속 조치..