go11 4개의 region에 존재하는 5000개의 서버 경고 알림을 어떻게 실시간으로 수집할까? 문제 상황각 서버에서 발생하는 Alert 데이터를 수집하기 위해서는 자체적으로 Agent를 개발하는 방법과 상용 솔루션을 사용하는 방법이 존재했다. 기존 업무 환경은 약 5000개의 서버 중 80%에 해당되는 서버에 Zabbix가 설치되어 있었고 이를 바탕으로 데이터 수집을 고려했다. 데이터 수집을 위해 아래의 이미지와 접근 방법을 구상했다.각 Region 내의 개별 서버에 Zabbix를 설치하고 발생한 Alert을 하나의 Slack Workspace로 전송한다. 운영팀과 협의해 각 Region과 유의미하게 분류해야 되는 서버들은 별도의 Slack Channel로 분류해서 메시지를 관리했다.22개의 Slack Channel을 통해 각 서버에서 발생되는 Alert을 JSON 타입의 Original Mess.. 2024. 9. 17. 고루틴 Race Condition 해결 과정 장애 상황Escalation 기능의 백엔드 로직 성능을 개선하기 위해 jiraEscalation 함수와 slackEscalation 함수를 각각 비동기 방식으로 구현하려고 했다. 하지만 두 함수가 동시에 실행되어 Incident 객체에 대해 읽기 및 쓰기 작업을 수행하는 경우, 동일한 객체를 동시에 수정하려고 시도하면서 Race Condition 오류가 발생했다. 위와 같은 jiraEscalation 함수와 slackEscalation 함수를 비동기로 실행시키기 위해 최초에는 두 메서드를 고루틴으로 실행하고 고루틴 내부에서 Incident의 값을 업데이트하도록 로직을 수정했다. 그 결과, 두 개의 고루틴이 동시에 실행되면서 incident.IssueId를 수정하고 있다.jiraEscalation과 s.. 2024. 8. 13. FFmpeg 라이브러리로 구현하는 동영상 처리 모듈: 문제 해결 전략 및 분석 기능 요구 사항 정의동영상 업로드`명령` 동영상 컷 편집 (Trim)`명령` 동영상 이어 붙이기 (Concat)`명령` 작업 수행최종 동영상 다운로드동영상 및 작업 조회위와 같은 6가지의 기능 요구 사항이 주어졌다. 주목해서 살펴본 점은 `명령` 관련 요구사항이다.모든 `명령`은 즉각적으로 ffmpeg command를 실행하여 연산을 수행하지 않습니다.별도의 `명령 작업 수행`이 있어야 concat, trim 등의 연산을 수행합니다. `명령 작업 수행`은 Queue 개념과 유사하다고 판단했는데 그 근거는 다음과 같다. 여러 개의 동영상 처리 작업을 순차적 또는 동시에 실행하는 프로세스이며, 작업이 완료될 때까지 대기하거나, 작업이 실패했을 때의 상태 관리 등이 Queue 시스템과 유사하다. Queue 개.. 2024. 8. 11. Go에서는 테스트 코드를 어떻게 작성할까 테스트 기본 원칙테스트 코드를 작성할 때 고려하는 많은 원칙들이 있지만 가장 기본적인 2가지 원칙을 선택했다.Go 테스트 라이브러리 활용 방법에 대해 살펴보기 전에 테스트 작성의 기반이 되는 원칙을 먼저 살펴본 후, 테스트 라이브러리 활용 방법에 대해 코드 레벨로 알아보자. 일곱 테스팅 원칙 (Seven Testing Principles)1. 테스팅은 결함의 존재를 보여주는 것이다.테스트의 주요 목적은 제품 내의 결함을 찾아내는 것이며, 결함이 전혀 발견되지 않는다고 해서 소프트웨어에 결함이 없다고 확신할 수 없다. 2. 완벽한 테스트는 불가능하다.모든 가능성(입력과 사전 조건의 모든 조합)을 테스트하는 것은 현실적으로 불가능하다.따라서, 리스크 기반 접근을 통해 가장 중요한 부분에 테스트를 집중해야.. 2024. 8. 5. Error 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 해결 과정 개선이 필요했던 이유필터 처리된 지 3개월이 지난 경고 알림을 삭제하는 배치 작업을 수행할 때, 아래와 같은 오류가 발생했다.Error 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 약 15,000개의 데이터를 한 번에 삭제하는 로직이었고, MariaDB 파라미터인 innodb_lock_wait_timeout 값은 기본값(50초)을 사용하고 있었다. 위와 같은 오류가 발생한 원인을 분석하기 위해 아래의 쿼리를 사용하여 현재 Lock 정보, Lock 대기 정보, 트랜잭션 상태를 조회했다.# 현재 Lock 정보 조회select * from information_schema.INNODB_LOCKS;# Lock 대기 정보 조회sele.. 2024. 7. 31. Legacy Query 성능 개선 과정 Query 성능 개선이 필요했던 이유약 28,000개의 데이터 행을 처리하는 조회 기능에서 성능 저하 현상이 발생했다. 데이터가 많지 않았기 때문에 성능 저하를 예상하지 못했다. 조회 응답 시간이 5,500ms ~ 6,000ms 정도 소요되었고, 유저 입장에서는 해당 기능이 중지된다고 느껴질 정도였다. 해당 기능은 장애 발생 시 모니터링 인원의 편의성을 위해 만들어진 것으로, 평상시 자주 사용하지는 않지만, 소 잃기 전에 외양간을 고친다는 마음으로 성능 개선을 시도했다. 총 2번의 개선 시도가 있었으며, 그 내용은 다음과 같다. 1차 개선1. 서브 쿼리를 사용하던 기존 구조를 조인 구조로 리팩토링2. 총행수를 계산하기 위해 전체 쿼리를 서브 쿼리로 감싸던 방식을 명시적으로 조인된 테이블에서 직접 계산하도.. 2024. 7. 25. 이전 1 2 다음
