본문 바로가기

Dev68

『Go』 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.
『DataBase』 대용량 데이터를 마이그레이션 할 때 무엇을 고려해야 할까 1️⃣편 Multi Column Index다중 컬럼 인덱스는 데이터 조회 시 함께 사용되는 컬럼들의 조회 성능을 최적화하기 위해 사용된다.각 컬럼에 개별 인덱스를 설정하는 것과 다중 컬럼 인덱스를 사용하는 것에는 차이점이 존재하는데 아래와 같다. 개별 인덱스를 각 컬럼에 설정한 경우, 데이터베이스는 쿼리 실행 시 어느 인덱스를 우선 사용할 것인지 판단한 후, 선택된 인덱스에 따라 순차적으로 검색을 진행한다. 이 과정에서 필요한 경우 여러 인덱스를 결합하여 사용할 수 있지만 추가적인 비용이 발생할 수 있다. 반면, 다중 컬럼 인덱스는 상위 컬럼의 인덱스 값에 대해 하위 컬럼의 값을 함께 저장한다. 따라서 쿼리 실행 시 어떤 인덱스를 먼저 사용할지를 판단하는 과정이 생략되고, 상위 인덱스에 의해 이미 필터링된 결과 .. 2024. 8. 20.
『Network』 Network System Overview of Network SystemsChoosing a Network Topology네트워크상의 노드 구성은 토폴로지(Topology)라고 한다. 네트워크의 토폴로지는 두 노드 간의 단일 연결처럼 단순하거나, 또는 노드가 데이터를 교환할 수 있는 노드의 레이아웃처럼 복잡할 수 있다. 네트워크 토폴로지의 유형은 점대점 연결형, 데이터 체인형, 버스형, 링형, 스타형과 그물형의 6가지 기본 범주로 나뉜다.   가장 단순한 형태의 네트워크인 점대점(Point-to-Point) 연결은 두 노드가 하나의 연결을 공유한다. 이러한 유형의 네트워크 연결은 드물지만, 두 노드 간에 직접 통신이 필요할 때 유용하다.   일렬의 점대점 연결을 데이터 체인(Data Chain)이라고 한다. 데이터 체인에서 트래.. 2024. 8. 16.
『Go』 고루틴 Race Condition 해결 과정 장애 상황Escalation 기능의 백엔드 로직 성능을 개선하기 위해 jiraEscalation 함수와 slackEscalation 함수를 각각 비동기 방식으로 구현하려고 했다. 하지만 두 함수가 동시에 실행되어 Incident 객체에 대해 읽기 및 쓰기 작업을 수행하는 경우, 동일한 객체를 동시에 수정하려고 시도하면서 Race Condition 오류가 발생했다. 위와 같은 jiraEscalation 함수와 slackEscalation 함수를 비동기로 실행시키기 위해 최초에는 두 메서드를 고루틴으로 실행하고 고루틴 내부에서 Incident의 값을 업데이트하도록 로직을 수정했다. 그 결과, 두 개의 고루틴이 동시에 실행되면서 incident.IssueId를 수정하고 있다.jiraEscalation과 sla.. 2024. 8. 13.
『Go』 FFmpeg 라이브러리로 구현하는 동영상 처리 모듈: 문제 해결 전략 및 분석 기능 요구 사항 정의동영상 업로드`명령` 동영상 컷 편집 (Trim)`명령` 동영상 이어 붙이기 (Concat)`명령` 작업 수행최종 동영상 다운로드동영상 및 작업 조회위와 같은 6가지의 기능 요구 사항이 주어졌다. 주목해서 살펴본 점은 `명령` 관련 요구사항이다.모든 `명령`은 즉각적으로 ffmpeg command를 실행하여 연산을 수행하지 않습니다.별도의 `명령 작업 수행`이 있어야 concat, trim 등의 연산을 수행합니다. `명령 작업 수행`은 Queue 개념과 유사하다고 판단했는데 그 근거는 다음과 같다. 여러 개의 동영상 처리 작업을 순차적 또는 동시에 실행하는 프로세스이며, 작업이 완료될 때까지 대기하거나, 작업이 실패했을 때의 상태 관리 등이 Queue 시스템과 유사하다. Queue 개.. 2024. 8. 11.
『Go』 Go에서는 테스트 코드를 어떻게 작성할까 테스트 기본 원칙테스트 코드를 작성할 때 고려하는 많은 원칙들이 있지만 가장 기본적인 2가지 원칙을 선택했다.Go 테스트 라이브러리 활용 방법에 대해 살펴보기 전에 테스트 작성의 기반이 되는 원칙을 먼저 살펴본 후, 테스트 라이브러리 활용 방법에 대해 코드 레벨로 알아보자.  일곱 테스팅 원칙 (Seven Testing Principles)1. 테스팅은 결함의 존재를 보여주는 것이다.테스트의 주요 목적은 제품 내의 결함을 찾아내는 것이며, 결함이 전혀 발견되지 않는다고 해서 소프트웨어에 결함이 없다고 확신할 수 없다. 2. 완벽한 테스트는 불가능하다.모든 가능성(입력과 사전 조건의 모든 조합)을 테스트하는 것은 현실적으로 불가능하다.따라서, 리스크 기반 접근을 통해 가장 중요한 부분에 테스트를 집중해야 .. 2024. 8. 5.
『Go』 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.
『DataBase』 Legacy Query 성능 개선 과정 Query 성능 개선이 필요했던 이유약 28,000개의 데이터 행을 처리하는 조회 기능에서 성능 저하 현상이 발생했다. 데이터가 많지 않았기 때문에 성능 저하를 예상하지 못했다. 조회 응답 시간이 5,500ms ~ 6,000ms 정도 소요되었고, 유저 입장에서는 해당 기능이 중지된다고 느껴질 정도였다. 해당 기능은 장애 발생 시 모니터링 인원의 편의성을 위해 만들어진 것으로, 평상시 자주 사용하지는 않지만, 소 잃기 전에 외양간을 고친다는 마음으로 성능 개선을 시도했다. 총 2번의 개선 시도가 있었으며, 그 내용은 다음과 같다. 1차 개선1. 서브 쿼리를 사용하던 기존 구조를 조인 구조로 리팩토링2. 총행수를 계산하기 위해 전체 쿼리를 서브 쿼리로 감싸던 방식을 명시적으로 조인된 테이블에서 직접 계산하도.. 2024. 7. 25.
『Node』 서비스에 실시간 통신을 도입한 과정 실시간 통신이 필요했던 이유최근 담당하고 있는 프로젝트의 대시보드 일부 기능에 대해 실시간 통신을 적용해야 되는 상황이 발생했다. 유저에게서 다음과 같은 불편함을 문의받았다.기존 조회 방식은 HTTP 프로토콜을 사용하여 5초마다 143KB의 브라우저 캐시를 폴링(polling)하는 방식인데. 이에 따라, 모니터링 인원이 대시보드를 장시간 사용 시 브라우저 메모리가 증가하여 성능 저하가 발생하는 문제가 발생합니다. 개선해 줄 수 있나요? 위 문제를 해결하기 위해서는 Long Polling이나 Server-Sent Events (SSE) 같은 방법들도 존재했지만, 경고를 식별하고 Escalation 하는 기능에서는 적합하지 않았다. 이유는 다음과 같았다. Long Polling 방식 또한 기존 Polling.. 2024. 7. 19.

티스토리툴바