선택과 집중

서론이전 포스팅에서 언급한대로, 회사에서 Azure 기반의 MariaDB에서 MySQL로 migration 하는 작업을 했다.이유는 9월 19일부로 MariaDB에 대한 지원을 Azure에서 종료하기 때문이다.본 포스팅에선 그 방법에 대해 작성하고자 한다. 사실 그렇게 어렵진 않은데, VM 서버의 ubuntu 버전이 호환이 안되서 삽질을 좀 많이했다.결론부터 말하자면, ubuntu 18.04 버전에선 불가능하다. 그리고 GTID 기반 replication도 불가능하다.바이너리 로그 기반 replication이 필요하다.  본인의 작업환경 버전을 꼭 체크하도록 하자.정확히는 온프레미스 환경이라면 어찌저찌 온몸비틀기로 되겠지만, 적어도 Azure 기반에선 불가능하다. 이유는 후술하겠다. 서비스 안정성을 위해..

서론회사에서 대규모 업데이트를 진행함에 따라, 기존 MariaDB 10.2에서 MySQL 8.0으로 migration하는 작업을 진행했다.이 과정에서 필연적으로 replication 작업도 진행했는데, 하는 방법도 중요하지만 원리에 대해 조금 더 알아보고자 한다.본론Replication?Replication(복제)은 write 연산과 read 연산을 분산시켜 DB의 부하를 낮추고, 시스템 장애 발생 시 slave를 master DB로 승격시켜 빠른 장애 대응이 가능한 기법을 의미한다.정의 같은 것은 너무 기본적인 내용이고 더 자세하게 소개한 레퍼런스가 많으니 패스하고, 간단하게 도식화한 그림으로 이해해보자.어떤 원리로 작동하는가?크게 동기식, 비동기식, 반동기식(semi-sync)가 존재한다.반동기식은 ..

서론회사에서 이벤트 브로커를 만들 수 있는 좋은 기회가 생겼다.기존에 우리 회사는 IoT 기기로부터 전달된 이벤트를 받아서 쓰기 때문에, 이를 저장하거나, 갈무리해 관리할 수 있는 구조가 아니었다. 이번에 새로운 3rd-party 플랫폼을 추가하게 되어서, 해당 작업을 맡게 되었다.전반적인 아키텍처는 구도가 잡혔는데, 파티션 수, 토픽의 개수, 순서 보장 방법, 클러스터 내 브로커 개수 등의 세부적인 설계가 필요한 상황이 되었다.카프카의 스펙을 어떻게 설정하는지, 기초부터 차근차근 따져가면서 생각해보기로 하자.설계가 필요한 다른 사람들에게 도움이 되길 바란다.본론배경먼저 현 상황에 대해 간단히 기술해보자면 TPS 기준으로, 평상시 700~800, 특정 타임 1500~2500, 스파이크 시 3500 이상의..