[SQL/캡스톤디자인] 데이터베이스 과제 4주차
데이터베이스4주차
이번주차에선 데이터 불일치 및 동기화 문제를 다룰 예정이다. 용자가 회원가입을 시도할 때 MySQL에 사용자 정보가 저장되지만, 동시에 MongoDB에 활동 로그 삽입이 실패할 경우 시스템의 신뢰성과 일관성이 깨질 수 있다. 이는 관계형 DB와 비관계형 DB를 혼합 운용할 때 흔히 발생할 수 있는 문제다.
연구 목표는 데이터 불일치 상황을 최소화 시키기 위해 메인DB 명확히 수립, 핵심 기능과 부가기능의 loose Coupling구조 구현 비동기 처리를 위한 이벤트 메시징 큐 기반 처리 전략 탐색이 있었다.느슨한 결합이란 시스템 구성요소들이 최대한 독립적으로 동작하여, 한 부분의 변경이나 장애가 다른 부분에 최소한의 영향을 주도록 설계하는 것을 의미한다.이러한 유연한 구조를 통해 시스템은 변화에 대한 적응력과 재사용성을 높일 수 있다.본 아키텍처에서 느슨한 결합을 구현하는 방법은 메인 트랜재션처리와 로그 저장사이에 직접적인 종속성을 없애는 것을 의미한다. MySQL에 데이터가 커밋될 때 MongoDB에 즉각 동기적으로 쓰지 않고, 메시지 큐를 통해 이벤트로 전달함으로써 두 데이터의 경로를 분리한다. 이러한 설계 덕에, MySQL과 MongoDB는 서로 독립적으로 가용성을 유지할 수 있다.Loose Coupling을 강화하기 위한 추가적인 아이디어로는, 로컬 파일 백업등의 다중 싱크도 고려할수 있다. app노드에서 로그를 큐로 보내는 동시에, 로컬 파일이나 별도 저장소에 복사본을 남겨두면, 시스템 장애시에도 핵심 로그를 보존해, 사후 백업이 가능하다는 결론이 내려졌다.
이벤트 기반 비동기 로그 처리 구조
MySQL-MongoDB 이중 DB 아키텍처 application이 Mysql에 핵심 트랙잭션을 커밋한 후 메시지 큐를 통해 로그 이벤트를 발행하는 방법이다. 별도의 백그라운드 워커가 큐로부터 메시지를 수신, MongoDB에 로그 문서로 남기는 방법이다. 정기적인 체크를 통해 데이터의 적합성 을 보완한다.옆의 그림처럼 이벤트 드리븐 아키텍처를 도입하여 로그 기록을 비동기식으로 처리할 수 이다. 구체적인 동작은 아래와 같다.
1.트랜젝션 발생 2.이벤트 발행 3.로그 소비 4.확인 및 Ack
- 트랜잭션 발생 > 앱에서 사용자의 어ᄄᅠᆫ 활동으로 MySQL에 데이터 변경이 일어난다.
- 이벤트 발행 > 해당 트랜잭션이 완료된 후, 앱은 로그 정보를 이벤트 메시지로 구성한다. 이 메시지에는 앱 유형 관련 식별자 타임스탬프 기타 메타에이터가 포함이된다. 메시지 큐로 비동기식으로 전송한다.
- 로그소비 > 별도로 실행되는 로그 컨슈머가 메시지 큐를 확인한다. 컨슈머는 큐에 쌓진 로그 이벤트를 순차적으로 읽어들이며, 각 이벤트를 처리하여 Mongodb에 로그문서로 저장한다. 확인해보니 Python의 스크립트가 RM으로부터 메시지를 수신하면 json파싱 후 log_doc를 호출하는 방식으로 간다. 앱과 독립적으로 동작하므로, 로그 저갲를 최적화 시킬 수 있다.
- 확인 및 ACK: 컨슈머가 로그를 MongoDB에 성공적으로 쓰게되면, 메시지 큐에 신호를 보낸다. 이렇게된다면, 메시지는 큐에서 제거되며 처리가 완료된다. 만약 컨슈머 처리 중 오류가 발생하면 ACK를 보내지 않거나 메시지를 다시 큐에 올려 재시도를 유도할 수 있다. Kafka의 경우도 마찬가지로 진행한다.
이러한 구조는 여러 가지 이점을 가지고 있다. 우선,과다 트래픽의 대응이 용이하다. 로그 발생량이 급증하더라도, 시스템은 큐만 들이밀어 놓은 후 나가므로, 큐가 버퍼역할을 대용으로 한다. 중앙 집중화 된 로그 처리가 가능하다. 모든 로그는 write로직이 소비측에 모여있어, 서비스마다 중복코드없이 한곳에서 관리할수 있다. 이는 로그 포맷을 바꾸거나 저장방식을 변경할 때 하나만 수정하면 되니, 유지보수성이 매우 높아진다. 동일 큐에 로그만 보낸다면, 통합 로그 시스템을 구축을 할 수 있어, 로그의 일관성과 분석이 수월해지는 장점이 생긴다.
이벤트 기반 비동기 로그 처리 아키텍처는 성능, 확장성, 신뢰성을 모두 높여준다. 시스템 구성요소 간 결합도를 낮추어 한쪽의 지연이나 장애가 전체에 파급되지 않으며, 로그 처리량이 커져도 큐와 소비자 풀을 확장하여 유연하게 대응할 수 있다.
차주엔 RQ와 kafka의 비교가 필요해보인다. 두 개는 유사하나 서로의 특성이 다르다는 것으로 확인이 된다. 아직 백앤드와 프론트앤드가 완성되지 않아, 실제로 적용해보고 차이점을 보고서로 제출하긴 어렵지만, 개인적인 이론 연구를 통하여, 보고서로 작성해볼 수 있도록 하려고 한다.