전체 글72 『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. 『Go』 Go 코딩 컨벤션 프로젝트를 진행할 때 아래와 같은 코딩 컨벤션을 지키려 합니다. 원본 출처 : 뱅크샐러드 Go 코딩 컨벤션 | 뱅크샐러드 (banksalad.com)# 1, Don't Panic프로덕션 환경에서 서버가 올바르게 시작되고 요청을 처리할 수 있는 상태에선 절대 panic을 사용하지 않는다. 또한 프로세스를 종료시키는 fatal도 마찬가지로 사용하지 않는다. panic은 다른 언어의 try-catch 문법처럼 예외처리를 위한 것이 아니며, 서버 애플리케이션 초기화 시점에만 빠른 실패를 위해 사용한다. 의도치 않은 panic에 대비해 서버 인터셉터 혹은 미들웨어로 recovery 체인을 추가하는 것을 권장한다. (e.g. echo의 미들웨어, grpc 인터셉터) # 2, Panic을 낼 수 있는 함수는 m.. 2024. 7. 11. 『Go』 Go와 객체지향 프로그래밍 객체지향에 준하는 프로그래밍 언어의 조건객체지향에 준하는 프로그래밍 언어의 조건이란 무엇을 의미할까? 다양한 주장이 있지만 " Go 언어로 배우는 웹 애플리케이션 개발 "에서는 다음 3대 요소를 만족하는 것이 "객체지향에 준하는 프로그래밍 언어"라고 정의한다.캡슐화(encapsulation)다형성(polymorphism)상속(inheritance)먼저 Go 언어는 객체지향 언어일까? Go 공식 사이트에서는 'Yes'면서 'No'이기도 하다는 애매한 답변을 하는데, 이는 Go가 객체지향의 3대 요소를 일부만 도입하고 있기 때문이다. Go에서는 서브클래스화 사용 불가많은 사람들이 객체지향 언어에 기대하는 것 중 하나가 서브클래스(subclassing) 일 것이다. 좀 더 쉬운 말로 바꾸자면 클래스(단일)의.. 2024. 7. 10. 『Go』 미들웨어 패턴 여러 엔드포인트를 작성하다 보면 동일한 처리를 반복적으로 사용하는 경우가 있다. 또한, 모니터링 도구나 접근 로그 출력 등 투과적으로 접근해야 하는 처리도 있다. 이런 공통 처리를 작성하는 패턴으로 미들웨어 패턴이 있다. Go의 HTTP 서버에서도 미들웨어 패턴이 폭넓게 사용된다. 미들웨어를 만드는 법Go로 애플리케이션이나 라이브러리를 설계하고 구현할 때는 표준 패키지의 시그니처나 인터페이스에 맞추어 구현할 때가 많다. 미들웨어 패턴을 구현할 때도 마찬가지다. Go의 미들웨어 패턴에서는 시그니처를 충족하도록 구현하는 것이 일반적이다. 이런 시그니처는 다음과 같은 이유로 재사용하기 좋다.http.Handler 인터페이스를 충족하는 HTTP 핸들러 구현에 적용할 수 있다.같은 패턴의 미들웨어 구현을 통해.. 2024. 7. 6. 『Go』 Go와 의존성 주입 의존관계 역전 원칙 (Dependency Inversion Principle, DIP)문제를 작은 단위로 분할해서 해결책을 찾아내는 것은 소프트웨어 엔지니어링의 기본적인 접근법 중 하나다. 여기서 중요한 것은 분할한 문제들 간에 연결 고리를 약하게 하는 것이다. 각 문제의 의존 관계를 제거하고 분할된 작은 문제들을 분담해서 병렬로 문제를 해결할 수 있다. 상위 개념의 문제를 하위 개념의 문제와 독립해서 해결하기 위한 방법으로, SOLID 원칙 중 하나인 의존관계 역전 원칙(Dependency Inversion Principle, DIP)이 있다. 클린 소프트웨어에서는 다음과 같이 정의한다.상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다. 추상화는 상세 구현에 .. 2024. 7. 5. 『Network』 WebSocket, HTTP WebSocketWebSocket 프로토콜은 클라이언트와 서버가 전이중 채널에서 통신하는 방법을 설명한다. 즉, 클라이언트와 서버 모두 오랫동안 지속되는 연결을 통해 동시에 데이터를 보내고 받을 수 있다. 이러한 유형의 통신은 HTTP 폴링보다 오버헤드가 적기 때문에 애플리케이션에 실시간 기능에 대한 여러 이점을 제공한다. 전이중 채널은 양방향 통신이 동시에 가능한 통신 방식으로, 송신과 수신을 동시에 할 수 있는 채널을 의미한다. WebSocket 장점양방향 통신 연결된 양쪽에서 언제든지 메시지를 보낼 수 있다.WebSocket 서버가 대화를 조정하는 경우, 클라이언트는 서버에 메시지를 보낸 다음 연결된 다른 모든 클라이언트에 즉시 이를 전달한다. 사용자는 실시간으로 서로에게 메시지를 보낼 수 있다... 2024. 6. 25. 이전 1 ··· 5 6 7 8 다음
