이슈 해결과정 기록 3

하루 n억 건 모니터링 데이터를 적재하는 Telemetry 서비스 만들기

문제 인식 회사에서 운영하고 있는 Telemetry 서비스는 1분 마다 각 장비의 모니터링 메시지를 받아서 파싱 및 저장하는 역할을 수행하고 있습니다. 해당 서비스는 원래 각 메시지를 개별적으로 처리하고, 이를 데이터베이스에 건별로 삽입하는 방식을 사용했습니다. 이 접근법은 단순하고 직관적이지만, 데이터 양이 급격하게 증가하면서 서비스 구조 변경이 필요했습니다. 그래서 대용량 데이터를 처리하기 위해 다음과 같이 3가지 개선 전략을 적용했습니다. 개선 전략 1: Kafka Batch Listener 도입 처리 효율성을 높이기 위해 Kafka Batch Listener를 도입했습니다. 전통적인 Kafka Listener가 메시지를 개별적으로 처리하는 것과 달리, Batch Listener는 여러 메시지를 한..

글로벌 서비스 운영을 위한 API 설계 방법 (feat. Timezone)

글로벌 서비스를 운영하려면 Timezone과 Offset에 대한 개념에 대해 이해가 필요하다. Timezone 타임존은 동일한 로컬 시간을 따르는 지역을 의미하며, 주로 해당 국가에 의해 법적으로 지정된다. 보통 국가별로 각자의 고유한 타임존을 사용하고 있으며, 호주나 미국처럼 면적이 넓은 나라인 경우 지역별로 각기 다른 타임존을 사용하기도 한다. Offset 그리고 경도별로 조정된 시간의 차이를 Offset이라고하는데, 경도에 따라 국가 및 지역을 구분해서 대략적인 Offset으로 통일하고 있다. 서울의 경우 Offset값이 +09:00인데, 즉 UTC +00:00인 영국의 런던시간이 0시일 때에 한국은 9시간이 빠른 오전 9시를 뜻한다. 참고 UTC는 그리니치 평균시(GMT)로 불리기도 하는데, UT..

DST에 대해 알아보자

글로벌 서비스를 운영하면서 DST 관련 이슈가 발생했다. 모니터링 그래프에서 데이터가 밀려나오는 이슈였다. 처음에는 월별 그래프로 보면서 데이터를 비교해보았었는데 정말 엉뚱한 데이터 값이 나오고 있었다. 그래서 일별 그래프를 보게되었고 데이터가 하루 씩 밀려나오는 것을 확인할 수 있었다. 이슈의 원인은 바로 DST 였다. DST(Daylight saving time)는 일광 절약 시간제를 의미하고 시계(표준시)를 한 시간 당겨 생활한다. 예를 들면 8시를 9시로 바꾸고, 2시를 3시로 바꾸는 것이다. 예를 들어 평소에 8시에 출근하던 것을 1시간 늘리니까 늘린 후 8시에 출근하면은 원래 시각으로는 7시에 출근한것으로 결론적으론 1시간 일찍 하루를 시작한 효과가 된다. 이렇게 보면 이해하기 편하다. 일반 ..