지금까지 이 시리즈에서 속성 이름을 꽤 여러 개 지었습니다. order.id, db.system, http.request.method 같은 것들이요. 별생각 없이 지은 이름도 있고 어디서 본 듯한 이름도 있었죠. 그런데 이름은 정말 아무래도 괜찮을까요? 🤔 스팬 하나만 놓고 보면 그렇습니다. http.method라고 적든 request_method라고 적든 내가 읽으면 되니까요. 문제는 그 스팬이 나 혼자 만든 게 아닐 때 시작됩니다. 이름이 갈리면 잃는 것 상황을 그려 보겠습니다. 주문 서비스는 직접 계측해서 http.metho
남은 신호는 로그 하나입니다. 그런데 지표 정리까지 왔다면 좀 이상하게 느껴질 거예요. 로그는 이미 다들 쓰고 있잖아요. 😅 파이썬이면 logging, Node라면 Pino나 Winston을 붙여 두고 잘 돌아가는데 여기에 또 새로운 걸 얹어야 하나 싶죠. OpenTelemetry도 같은 생각을 했습니다. 그래서 로그만 다른 길을 갔어요. 이 글에서는 그 선택이 무엇이었는지, 그리고 기존 로그를 추적과 이어 붙이는 방법을 다루겠습니다. 로그만 접근이 달랐던 이유 추적과 지표는 OpenTelemetry가 새로 표준을 만들었습니다.
Bun이 Node.js를 잇는 차세대 자바스크립트 런타임으로 급 부상하면서, Bun을 위해서 탄생한 웹 프레임워크인 Elysia도 큰 관심을 받고 있습니다. 이번 포스팅에서는 Elysia의 주요 특징과 사용법, 그리고 Elysia가 다른 웹 프레임워크와 어떻게 차별화되는지에 대해서 살펴보겠습니다. Elysia란? Express 프레임워크가 Node.js 생태계에서 대표 웹 프레임워크를 담당하고 있다면 Elysia는 Bun 생태계에서 비슷한 역할과 인지도를 갖고 있는 하고 있는 웹 프레임워크입니다. 물론 간단한 웹 서버를 개발할 때는
수집기 정리까지 오면서 흘려보낸 건 추적뿐이었습니다. 추적은 요청 하나를 아주 자세히 보여 주지만 "지난 한 시간 동안 오류율이 몇 퍼센트였나"에는 답하지 못해요. 요청 하나하나를 다 뒤져 세야 하니까요. 지표, 로그, 추적 정리에서 정리했듯 그건 지표(metric)의 몫입니다. 이 글에서는 지표를 만드는 계측기(instrument) 종류를 고르는 법, 속성을 붙일 때 조심할 것, 그리고 Prometheus까지 연결하는 과정을 다루겠습니다. 계측기는 네 가지 지표를 만들려면 먼저 미터(meter)를 얻고 거기서 계측기를 만듭니다.
지금까지 만든 구조에는 선이 하나뿐이었습니다. 애플리케이션이 백엔드로 직접 보내는 선이요. 서비스가 둘일 때는 아무 문제가 없죠. 그런데 스무 개가 되면 어떨까요? 백엔드 주소를 바꾸려면 스무 곳을 고쳐 배포해야 합니다. 어떤 속성을 모든 서비스에 붙이기로 했다면 역시 스무 곳이고요. 백엔드가 잠깐 죽으면 스무 개의 애플리케이션이 각자 재시도하다 메모리에 데이터를 쌓습니다. 😰 관측을 위해 넣은 코드가 서비스를 위협하는 셈이죠. 이 글에서는 그 사이에 두는 수집기(Collector)를 다루겠습니다. 파이프라인 세 조각 수집기는 텔
Node.js로 웹 서버를 만들 때 오랫동안 Express가 사실상 표준이었는데요. 그런데 최근 몇 년 사이에 Cloudflare Workers, Deno, Bun 같은 새로운 런타임들이 등장하면서 상황이 달라지고 있습니다. Express는 Node.js에 특화되어 있어서 다른 런타임에서 그대로 쓸 수 없거든요. 이런 흐름 속에서 Hono가 주목받고 있습니다. Hono는 웹 표준(Web Standards) API 위에 만들어진 경량 웹 프레임워크로, 같은 코드가 Bun이든 Deno든 Cloudflare Workers든 어디서나 돌아
OpenTelemetry 추적 정리에서 만든 트리는 깔끔했지만 한계가 있었습니다. 프로세스 하나 안에서만 이어진다는 것이요. 주문 서비스가 결제 서비스를 HTTP로 부르면 어떻게 될까요? 결제 서비스 입장에서는 그냥 요청 하나가 들어온 겁니다. 자기가 누구의 자식인지 알 도리가 없으니 새 추적을 시작하죠. 결과적으로 사용자 눈에는 한 번의 주문인데 추적은 두 개로 쪼개집니다. 😅 서비스가 늘어날수록 이 조각은 많아지고, 정작 알고 싶은 "이 주문 요청이 어디서 시간을 썼나"는 답할 수 없게 돼요. 이 글에서는 경계를 넘어 추적을
OpenTelemetry 정리에서 계측 코드가 API에만 의존하면 백엔드를 갈아 끼울 수 있다는 이야기를 했는데요. 그때 만든 스팬은 greet 하나뿐이었습니다. 이름을 붙이고 끝낸 게 전부였죠. 실제로는 여기서부터가 어렵습니다. 요청 하나를 처리하는 동안 스팬을 하나만 만들면 "이 요청이 200밀리초 걸렸다"까지만 알 수 있고, 반대로 함수마다 만들면 화면이 스팬으로 뒤덮여 오히려 안 보이거든요. 😅 이 글에서는 스팬에 무엇을 담는지, 어느 단위로 나누는 게 쓸모 있는지, 그리고 만든 추적을 Jaeger에서 어떻게 확인하는지를
추적(trace)을 처음 붙일 때 Jaeger를 골랐다고 해 볼게요. Jaeger가 주는 라이브러리를 받아 서비스 곳곳에 스팬을 만드는 코드를 심었고, 잘 돌아갑니다. 그런데 반년 뒤 팀이 다른 백엔드로 옮기기로 합니다. 무엇을 다시 해야 할까요? 심어 둔 계측 코드 전부입니다. 😅 몇 년 전까지는 이게 기본값이었습니다. 관측 도구를 고르는 일이 곧 그 도구를 코드에 새겨 넣는 일이었고, 한번 새기면 되돌리기 어려웠죠. 지금은 다릅니다. 계측 코드는 그대로 두고 환경 변수 하나만 바꾸면 텔레메트리(telemetry)가 다른 곳으로
이번 글에서는 NestJS에서 API의 버전을 체계적으로 관리하는 방법에 대해서 배워보도록 하겠습니다. API Versioning이란? REST API와 같은 서버 애플리케이션을 운영하다 보면, 부득이하게 클라이언트에 큰 영향을 줄 수 있는 위험한 변경을 해야 할 때가 있는데요. API Versioning, 즉 버전 관리를 통해서, 우리는 서버 측 API 변경에 따른 클라이언트의 영향을 최소화하고, API의 호환성과 안정성을 높일 수 있습니다. 버전 관리가 이루어지는 API는 보통 클라이언트에게 v1, v2, v3... 이런 식으로
이번 글에서는 가드(Guard)를 활용하여 NestJS 앱을 위험한 요청으로 부터 효과적으로 보호하는 방법에 대해서 배워보도록 하겠습니다. 가드(Guard)란? NestJS에서 가드(guard)란 애플리케이션의 최전선에서 말그대로 애플리케이션을 보호하는 역할을 담당하는데요. NestJS로 들어오는 요청은 컨트롤러(controller) 단에 도달하기 전에 반드시 가드를 거쳐가도록 되어 있습니다. 가드를 이용하면 컨트롤러가 요청을 처리하기 전에 안전하지 않은 요청을 효과적으로 차단할 수 있습니다. 따라서 애플리케이션 보안을 위해서 필수
유지보수가 용이하고 안정적으로 동작하는 NestJS API를 개발하려면 각각의 엔드포인트가 잘 작동하는지 확인하는 것이 필수적입니다. 이번 글에서는 Jest와 Supertest를 활용하여 효과적으로 NestJS 앱을 테스트하는 방법에 대해서 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로젝트를 구성하는 기본적인
NestJS 앱을 개발,테스트, 운영 등 다양한 환경에 배포하려면 어느 환경에 배포하느냐에 따라서 다르게 설정되야하는 값들이 생기기 마련이죠? 이번 포스팅에서는 NestJS 앱에서 이렇게 환경 별로 달라지는 설정 값들을 어떻게 효과적으로 관리할 수 있는지 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로젝트를 구
마이크로서비스(microservices) 아키텍처나 분산 시스템 환경에서는 모든 서비스가 정상적으로 살아서 동작하는지를 검사하는 것이 매우 중요합니다. 이를 위해서 각 서비스에 생존 여부(liveness)와 가용 여부(readiness)를 응답해주는 HTTP 엔드포인트(endpoint)가 필요하기 마련인데요. 이번 포스팅에서는 NestJS 앱에서 이러한 엔드포인트(endpoint)를 어떻게 구현할 수 있는지에 대해서 알아보도록 하겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요
로깅(logging)은 애플리케이션에서 발생하는 각종 이벤트에 대한 기록을 남기고 문제 발생 시 원인을 파악하는데 핵심적인 역할을 하는데요. 이번 포스팅에서는 NestJS 앱에서 어떻게 로거(logger)를 사용하고 커스터마이징(customizing)할 수 있는지 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로
분산 시스템 환경에서 가장 흔하게 접할 수 있는 백엔드(backend) 애플리케이션은 아마도 특정한 도메인의 데이터를 관리해주는 REST API일 텐데요. 이번 포스팅에서는 NestJS를 이용하면 얼마나 효과적으로 이러한 전형적인 REST API를 개발할 수 있는지 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프
최근에 NestJS로 시작하는 백엔드(backend) 프로젝트가 부쩍 많아진 느낌입니다. 이번 포스팅에서는 차세대 웹 프레임워크로 각광받고 있는 NestJS에 대해서 함께 알아보려고 합니다. NestJS란? NestJS는 자바스크립트나 타입스크립트로 서버 애플리케이션을 개발할 수 있는 백엔드 웹 프레임워크(Web framework)입니다. 다른 프로그래밍 언어에서 넘어오신 분이라면 자바의 스프링(Spring)이나 파이썬의 장고(Django)를 생각하시면 이해가 쉬우실 것 같네요. 자바스크립트 쪽에서는 상당히 오랫동안 Express라
관측성 정리에서 미리 정하지 않은 질문에 답하려면 원시 이벤트를 남겨야 한다고 했는데요. 그러면 다음 질문이 따라옵니다. 어떤 형태로 남길까? 앞 글에서 던진 자가 진단 세 질문을 다시 꺼내 보면 답이 셋으로 갈립니다. "지금 오류율이 얼마인가"는 숫자 하나로 답하고, "그 사용자의 요청에 무슨 일이 있었나"는 사건 기록으로 답하고, "요청이 어느 서비스에서 시간을 썼나"는 요청의 여정으로 답해야 하거든요. 이 세 형태가 지표(metric), 로그(log), 추적(trace)입니다. 2017년쯤부터 "관측성의 세 기둥"이라는 말로
Node.js로 웹 서버를 만들어야 한다면 가장 먼저 떠오르는 이름이 바로 Express일 겁니다. 2010년에 처음 등장한 이후로 지금까지 Node.js 생태계에서 압도적인 점유율을 자랑하고 있는 웹 프레임워크인데요. Express는 "최소한의 기능만 제공하되, 필요한 것은 직접 골라 쓰자"라는 철학을 바탕으로 설계되어서, 가벼우면서도 유연한 서버를 구축할 수 있습니다. 이번 포스팅에서는 Express를 처음 접하는 분들을 위해 프로젝트 셋업부터 라우팅, 미들웨어, 요청/응답 처리까지 핵심적인 사용법을 차근차근 알아보겠습니다. E
에러 예산 정리까지 네 편에서 다룬 도구는 전부 잘 작동합니다. 알림이 울리면 온콜이 확인하고 대시보드를 열죠. 그런데 대시보드를 열어 놓고 막히는 순간이 있습니다. "왜 특정 지역 사용자만 느리지?"라는 질문에 답할 그래프가 없는 거예요. 지역별 응답 시간 그래프를 미리 만들어 둔 적이 없으니까요. 🤔 미리 만든 그래프는 미리 정한 질문에만 답합니다. 장애 중에 나오는 질문은 대개 미리 정하지 않은 질문이고요. 이 간극에 이름을 붙인 게 관측성(observability)입니다. 이 글에서는 모니터링과 관측성이 어떻게 다른지, 왜