devops7 [Backend & DevOps] Node.js LTS 유지 전략과 필요성 — 왜, 그리고 어떻게 안 귀찮게 [Backend & DevOps] Node.js LTS 유지 전략과 필요성 — 왜, 그리고 어떻게 안 귀찮게어느 날 서비스의 Dockerfile을 열어보니 node:20-alpine으로 돌고 있었다. 그런데 Node 20은 이미 EOL(지원 종료). 즉 보안 패치도 안 나오는 버전 위에서 프로덕션이 돌고 있던 것이다. 이런 일은 생각보다 흔하다. 처음 세팅한 버전 그대로 몇 년을 가다가, 어느새 지원 종료 버전에 올라타 있게 된다. 이 글은 Node를 왜 LTS로 유지해야 하는지, 그리고 그걸 어떻게 안 귀찮게 할지를 정리한다.1. 먼저 — LTS 생명주기Node의 메이저 버전은 정해진 생명주기를 따른다.Current — 갓 나온 버전. 최신 기능이 들어오지만 아직 실험적. 프로덕션 권장 아님.Activ.. 2026. 8. 19. [DevOps & Infra] 구조화 로깅과 관찰 가능성 [DevOps & Infra] 구조화 로깅과 관찰 가능성: 흩어진 로그를 추적 가능하게장애가 났다. 로그를 뒤진다. 그런데 console.log("에러 발생"), console.log(user), console.log("여기까지 옴") 같은 파편들이 수만 줄 흩어져 있어, 정작 "그 요청이 어디서 왜 실패했는지" 를 재구성할 수가 없다. 로그는 많은데 쓸모가 없다. 이 글에서는 로그를 "검색·분석·추적 가능한" 자산으로 만드는 구조화 로깅(structured logging) 을 정리한다.1. 텍스트 로그의 한계console.log로 남기는 평범한 텍스트 로그는 사람이 눈으로 읽기엔 괜찮지만, 기계가 다루기엔 최악이다.User 1234 failed to place order because stock is .. 2026. 8. 15. [DevOps & Infra] Airflow로 데이터 파이프라인 만들기: 병렬 수집 → 원자적 승격 → 리포트 [DevOps & Infra] Airflow로 데이터 파이프라인 만들기: 병렬 수집 → 원자적 승격 → 리포트여러 외부 소스에서 매일 데이터를 긁어와 서비스 DB에 반영하는 배치를 운영한다고 하자. 예전에는 서버에 cron을 걸어 스크립트를 돌렸다. 그런데 요즘처럼 애플리케이션을 여러 Pod(레플리카)로 띄우는 환경에서는 이 방식이 곧바로 문제를 일으킨다. 이 글에서는 왜 cron으로는 부족한지, 그리고 Airflow로 "병렬 수집 → 원자적 승격 → 리포트" 파이프라인을 어떻게 설계하는지 정리한다.1. cron의 한계: 여러 Pod에서 배치가 중복 실행된다가장 먼저 부딪히는 문제. cron을 각 Pod에 넣어두면, Pod가 3개면 새벽 배치가 3번 돈다. cron은 "그 컨테이너 안"만 알 뿐, 옆의 .. 2026. 8. 10. [DevOps & Infra] 헬스체크 & 무중단 배포 [DevOps & Infra] 헬스체크와 무중단 배포: 죽지 않고, 끊기지 않게배포할 때마다 잠깐씩 502가 뜨거나, 요청을 처리하던 도중에 컨테이너가 꺼져 응답이 날아간 경험. "배포 = 잠깐의 장애"가 당연한 게 아니다. 헬스체크와 그레이스풀 셧다운만 제대로 갖추면 사용자가 눈치채지 못하는 무중단 배포가 된다. 이 글에서 그 두 축을 정리한다.1. 헬스체크: liveness vs readiness오케스트레이터(쿠버네티스 등)나 로드밸런서가 "이 컨테이너가 지금 괜찮은지" 판단하려면 물어볼 창구가 필요하다. 그런데 "괜찮다"에는 두 가지 다른 질문이 있고, 이걸 구분하는 게 핵심이다.① Liveness(살아있는가?) — "이 프로세스가 죽었나, 살았나?"데드락이나 무한 루프에 빠져 응답 불능이 되면, .. 2026. 8. 10. [DevOps & Infra] GitHub Actions Docker CI/CD [DevOps & Infra] GitHub Actions로 Docker 이미지 빌드·배포 CI/CD 파이프라인코드를 main에 머지할 때마다 누군가 수동으로 테스트 돌리고, 이미지 빌드하고, 서버에 올리는 작업을 반복하고 있다면 그 과정을 통째로 자동화할 때가 됐다. 이 글에서는 GitHub Actions로 테스트 → Docker 이미지 빌드 → 레지스트리 푸시 → 배포까지 이어지는 CI/CD 파이프라인을 단계별로 구성한다. 앞서 다룬 '멀티 스테이지 Docker 빌드' 글의 자연스러운 다음 단계다.1. 전체 그림파이프라인은 하나의 워크플로 파일(.github/workflows/deploy.yml)에 정의한다. 흐름은 이렇다.main 브랜치 push └─ test 잡: 의존성 설치 → 린트 → 테스트.. 2026. 8. 8. [DevOps] Node.js 멀티 스테이지 Docker 빌드로 이미지 용량과 빌드 시간 줄이기 [DevOps] Node.js 멀티 스테이지 Docker 빌드로 이미지 용량과 빌드 시간 줄이기docker build 한 번에 이미지가 1.2GB씩 나오고, 코드 한 줄 고칠 때마다 npm install이 처음부터 다시 도는 경험. Node.js를 컨테이너로 배포해본 사람이라면 익숙할 것이다. 원인은 대부분 하나의 스테이지에서 빌드 도구와 런타임을 뒤섞어 넣는 Dockerfile에 있다. 이 글에서는 멀티 스테이지 빌드와 레이어 캐시를 이용해 이미지 용량과 빌드 시간을 함께 줄이는 방법을 정리한다.1. 문제가 되는 단일 스테이지 Dockerfile흔히 처음 작성하는 형태는 이렇다.FROM node:20WORKDIR /appCOPY . .RUN npm installRUN npm run buildCMD [".. 2026. 8. 4. 이전 1 2 다음
