처음 백엔드 코드를 AWS 클러스터에 배포하고 S3에 배포한 프론트랑 연결하다가 마주친 CSP 에러! 반갑당

프론트 이미지 빌드할때 API_BASE_URL을 같이 빌드하니 BE로 요청은 가는데 CSP 에러 때문에 에러 발생.

S3 배포 환경에서 백엔드 API 호출 실패

요약

1. 문제 정의

1.1 증상

• 로컬 환경: 백엔드 API 호출 정상 작동 (npm run dev)
• S3 배포 환경: 브라우저 Network 탭에 API 요청 자체가 나타나지 않음
• 증상 특징: CORS 에러도 표시되지 않고, 요청이 아예 발생하지 않음

1.2 재현 조건

1. 프론트엔드를 S3에 배포
2. 브라우저에서 S3 URL로 접속
3. 백엔드 API를 호출하는 기능 실행
4. Network 탭 확인 → 요청 없음

1.3 환경 차이

1.4 영향 범위

• 영향받는 기능: 백엔드 API를 사용하는 모든 기능
• 사용자 영향: S3 배포 환경에서 서비스 완전 불가
• 데이터 영향: 없음 (요청이 발생하지 않음)

2. 타임라인

3. 근본 원인 분석

3.1 5 Whys 분석

🎯 근본 원인: index.html의 Content Security Policy에서 connect-src 지시어가 'self' https://*.paddle.com만 허용하도록 설정되어 있었고, 백엔드 API 도메인(https://*.AAA)이 포함되지 않아 브라우저가 요청을 원천 차단했음.

3.2 기술적 세부 사항

CSP (Content Security Policy) 동작 원리

<meta http-equiv="Content-Security-Policy"
  content="connect-src 'self' https://*.paddle.com;" />

• connect-src: XMLHttpRequest, Fetch API, WebSocket 등 네트워크 요청을 제어
• 'self': 현재 origin(S3 도메인)만 허용
• https://*.paddle.com: Paddle 결제 도메인만 허용
• 문제: api-dev.skuberplus.com은 허용되지 않음

로컬 환경이 정상 작동한 이유

// vite.config.ts
server: {
  proxy: {
    '/api': {
      target: 'https://api-AAA',
      changeOrigin: true,
    },
  },
}

• 로컬에서는 Vite 프록시가 /api 요청을 백엔드로 전달
• 브라우저 입장에서는 같은 origin(localhost:4180)으로 요청
• CSP의 'self'에 해당하여 허용됨

S3 배포 환경의 차이

// src/api/client.ts
const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;
// → "https://api-dev.AAA"

export const apiClient = axios.create({
  baseURL: API_BASE_URL, // 직접 호출
});

• S3에는 프록시 서버가 없음
• 브라우저가 직접 `api-dev.AAA으로 요청
• CSP에 해당 도메인이 없어 차단됨

1. Docker Desktop 실행

Docker 컨테이너를 실행하기 위해서는 먼저 Docker daemon이 실행 중이어야 한다.

open -a Docker

Docker Desktop이 완전히 시작될 때까지 기다렸다가 실행.

2. Nginx 컨테이너 실행

Docker daemon이 실행되면 nginx 컨테이너를 시작한다.

docker run -d -p 8080:80 --name webview-test nginx

명령어 설명:

• -d: 백그라운드에서 실행 (detached mode)
• -p 8080:80: 로컬 8080 포트를 컨테이너의 80 포트로 매핑
• --name webview-test: 컨테이너에 이름 지정

처음 실행 시 출력:

 Unable to find image 'nginx:latest'
  locally
  latest: Pulling from library/nginx
  88770be1d442: Download complete
  40b6fc5618c6: Download complete
  bb8ecb62799c: Download complete
  b89cf3ec7a3e: Download complete
  2254fb813b11: Download complete
  cc57e8335c98: Download complete
  cf9a807fe41d: Download complete
  Digest: sha256:553f64aecdc31b5bf944521731
  cd70e35da4faed96b2b7548a3d8e2598c52a42
  Status: Downloaded newer image for
  nginx:latest
  b7557f3935858c0c6ca277230b43eb636b26e4025
  e5432697efff0dbb51c44bd

Docker Desktop 앱에서 실행 중인 nginx 컨테이너를 확인할 수 있다.

3. 실행 확인

실행 중인 컨테이너 확인

docker ps

curl로 테스트

curl http://localhost:8080

접근 가능한 주소

다음 주소들로 nginx에 접근할 수 있다.

• http://localhost:8080
• http://127.0.0.1:8080

5. 클라이언트 코드에서 사용

WebView를 임베딩할 macOS 앱의 코드에서 다음과 같이 사용할 수 있다.

const nginxUrl = 'http://localhost:8080';

컨테이너 관리

컨테이너 중지

docker stop webview-test

컨테이너 재시작

docker start webview-test

컨테이너 삭제

docker rm webview-test

Prometheus란?

Prometheus는 SoundCloud에서 만든 시스템 및 서비스의 상태를 모니터링하는 오픈소스 모니터링 시스템이다. 현재는 Kubernetes 다음으로 인기있는 CNCF 프로젝트라고 볼 수 있다.

Prometheus는 특히 메트릭 수집과 알람에 특화되어있다.

Prometheus 메트릭 수집 방법

메트릭 수집의 경우 HTTP 엔드 포인트를 통한 pull 방식으로 이루어지고 있다.

Pull 방식

• 주기적으로 타겟 서버를 찾아가서 메트릭을 긁어옴 (scraping)
  • ex) 매 15초마다 /metrics 엔드포인트 호출

Push 방식

• 각 서버/애플리케이션이 직접 모니터링 시스템으로 메트릭 전송
• 애플리케이션이 주기적으로 메트릭을 모니터링 시스템의 api로 전송

Pull vs Push 방식 비교

Prometheus 핵심 개념

이렇게 수집한 데이터는 시계열 데이터로 저장한다.

시계열 데이터란 모든 데이터를 시간과 함께 저장하는 것이다.  
시간별로 데이터가 어떻게 변했는지 기록하는 것처럼 시간별로 데이터가 저장된다.
"시간" + "벨류"
대신 과거 데이터를 수정하지 않고 계속 쌓기만 한다. 따라서 시간 기반 계산에 최적화되어있다.

예시

웹브라우저로 http://.../metrics 접속하면 보이는 내용

  http_requests_total{method="GET", endpoint="/login"} 1234
  http_requests_total{method="POST", endpoint="/signup"} 567
  memory_usage_bytes 1073741824
  cpu_usage_percent 45.2

• 메트릭이름{라벨="값"} 현재값
• 타임스탬프는 보이지 않음 (Prometheus가 수집 시점에 자동 기록)
• 브라우저로 /metrics 접속하면 현재 시점의 값만 보임
• Prometheus가 주기적으로 이 엔드포인트르 스크레핑해서 타임스탬프랑 같이 저장

Prometheus 메트릭 타입

• Counter
  • 누적값, 증가만 가능
  • 예: http_requests_total, error_count_total
• Gauge
  • 증가 / 감소 가능한 값
  • 예: cpu_usage_percent, memory_usage_bytes
• Histogram
  • 구간별 분포 측정
  • 예: http_request_duration_seconds
• Summary
  • 백분위수 계산
  • 예: response_time_percentile

Prometheus 라벨

라벨을 통해서 더 세밀하게 구분할 수 있다. key-value로 이루어져 있으며, 영문자로 시작해야한다. 여기서 __로 시작하는 이름은 prometheus에서 내부적으로 사용하는 예약어라 사용하면 안된다.

라벨 활용 예시

좋은 라벨 설계

  http_requests_total{
    method="POST",          # 값이 제한적 (GET, POST, PUT, DELETE)
    endpoint="/api/users",  # 엔드포인트 수는 한정적
    status="200",          # HTTP 상태 코드 (200, 404, 500 등)
    env="production"       # 환경 (dev, staging, production)
  }

나쁜 라벨 설계

  http_requests_total{
    user_id="user_123456",     # 수백만 개의 고유값 -> 메모리 폭발
    timestamp="2024-01-01"      # 시간은 이미 자동 저장됨
  }

주의사항: 라벨이 변경되면 변경된 라벨에 맞춰 새로운 시계열이 생성된다. 라벨 값이 바뀌면 다른 시계열로 취급되어 문제를 발생시킬 수 있다. 이렇게되면 시계열 데이터 수가 매우 증가할 수 있기 때문에 메모리 성능에 문제가 생길 수 있어 정말 필요한 부분에만 라벨을 처리하는게 중요하다.

저장된 데이터 찾기

Prometheus는 데이터를 저장하기 위해서 Chunk(청크)와 WAL(Write-Ahead-Log)를 사용한다.

Chunk

청크는 여러개의 샘플을 하나의 덩어리로 묶은 데이터 구조이다. 만약 1시간 동안의 CPU 사용률 데이터의 경우 아래와 같다.

  [10:00:00, 45%] [10:00:15, 47%] [10:00:30, 52%] ...

하나의 청크로 압축되어 디스크에 저장된다. 이렇게 압축된 청크 덕분에 Prometheus는 많은 데이터를 효율적으로 저장하고 빠르게 조회할 수 있다.

WAL (Write-Ahead-Log)

WAL은 데이터 안정성을 보장하는 로그 파일이다. 샘플이 수집되게되면 가장 먼저 WAL에 저장된다.

수집 → WAL에 즉시 기록 → 메모리 저장 → 청크로 압축 → 디스크 저장

WAL의 경우 만약 장애가 발생하게 되면 복구를 도와주는 중요한 역할을 하게 된다. 만약, Prometheus가 비정상적으로 종료되었을 경우에, WAL 파일을 읽어서 데이터를 복구할 수 있게 된다.

1. 메트릭 수집: Prometheus는 타겟으로부터 메트릭을 수집하고, 이를 시계열 데이터로 변환한다.
2. WAL 기록: 수집된 샘플과 해당 시계열 정보는 먼저 WAL에 기록되어 장애 발생 시 복구 가능하게 한다.
3. 메모리 저장: 수집된 메트릭은 Prometheus의 in-memory TSDB 구조에 시계열(series)과 샘플(sample) 형태로 저장된다.
4. 청크 압축: 메모리 내의 샘플들은 chunk로 압축되어 저장된다.
5. 디스크 저장: 일정 시간이 경과하거나 조건이 충족되면 디스크에 block 형태로 flush 된다. 이후 해당 시점까지의 WAL segment는 삭제된다.
6. Compaction: 디스크에 저장된 block들은 주기적으로 compaction 과정을 거치며, 이 과정에서 저장 공간을 최적화한다.

재시작시 복구 과정

만약 문제가 있어 Prometheus가 재시작이 된다면 다음과 같은 과정을 거치게 된다.

1. WAL 파일을 읽어 메모리에만 존재하던 데이터를 복구한다
2. 시계열과 샘플 정보를 다시 메모리에 로드한다
3. 데이터 연속성을 유지한다.

데이터 저장 위치와 보존 기간 설정 예시

# prometheus.yml
  storage:
    tsdb:
      path: /var/lib/prometheus  # 데이터 저장 경로
      retention.time: 15d         # 15일간 보관
      retention.size: 10GB        # 최대 10GB까지 저장

PromQL (Prometheus Query Language)

Prometheus는 자체 쿼리인 PromQL을 제공하며, 다양한 방식으로 메트릭을 집계하고 필터링한다.

PromQL 예시

  # 5분간 초당 요청 수 (QPS)
  rate(http_requests_total[5m])

  # 엔드포인트별 에러율
  sum(rate(http_requests_total{status=~"5.."}[5m])) by (endpoint)
  /
  sum(rate(http_requests_total[5m])) by (endpoint) * 100

  # 메모리 사용률 80% 넘는 서버 찾기
  (memory_usage_bytes / memory_total_bytes) > 0.8

  # 특정 팀의 프로덕션 서버만 모니터링
  cpu_usage{team="backend", env="production"}

알람 설정

Prometheus는 알람 기능도 제공하고 있기 때문에 임계값을 초과하면 알림을 발송해서 문제를 알고 대응할 수 있다.

알람 설정 예시

  groups:
    - name: example
      rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 5m
        annotations:
          summary: "{{ $labels.endpoint }} 에러율 5% 초과"
          description: "현재 에러율: {{ $value | humanizePercentage }}"

      - alert: HighMemoryUsage
        expr: memory_usage_bytes / memory_total_bytes > 0.9
        for: 10m
        annotations:
          summary: "메모리 사용률 90% 초과"

모니터링

PromQL의 쿼리 결과들은 보통 다른 모니터링 도구로 그래프와 대시보드 형태로 표현해 확인할 수 있다. 나의 경우 Grafana를 통해서 초기 대시보드 화면을 구현한적 있다. 직접 만든 화면은 회사 데이터가 있으므로 Grafana에서 가져온 것으로 대체한다.

Prometheus는 데이터 수집과 저장에 특화되어있고, 시각화는 주로 Grafana를 연동해서 사용하는 추세이다.

• 1. Prometheus가 메트릭 수집/저장
• 2. Grafana가 Prometheus를 데이터소스로 연결함
• 3. 대시보드에서 PromQL로 쿼리 작성
• 4. 실시간 그래프와 알림 설정 가능

실제 Grafana Dashboard Template이 있어서 원하는 템플릿을 직접 가져와서 사용해도 된다. 나의 경우 데이터가 보이지 않거나 다른 데이터를 보여줘야할때 Panel을 추가해서 직접 PromQL로 데이터를 보여줬다

* Grafana Dashboard Template: https://grafana.com/grafana/dashboards/

Prometheus의 한계

Prometheus의 경우 분명 메트릭을 수집하는데 특화되어있다. 그러나 실제 운영에 있어서 모니터링앱을 구성할때는 메트릭 데이터만으로는 모니터링 앱을 만드는데 한계가 있다. 로그나 트레이싱을 지원하지 않기 때문에 완벽한 모니터링 앱을 만들고자한다면, 로그나 트레이싱(예., Jaeger) 데이터를 수집하는 다른 것들이 필요하다.

MSA(Microservices Architecture) 기반 서비스가 증가하면서 서비스 간 의존성과 상호작용이 복잡해지고 있다.

예를 들어 사용자가 주문 버튼을 누르면 유저서비스 → 상품서비스 → 재고서비스 → 결제서비스 → 주문서비스 → 알림서비스...

이렇게 엮여있다보니, 주문이 안들어왔을 경우에, 어디서 막혔는지 찾는게 쉽지 않게 되어버렸다.

클라우드 환경에서도 마찬가지다. 클라우드 환경에서도 가끔 알 수 없는 문제가 발생한다. 예를 들어 트래픽이 몰려 자동 스케일링으로 인해 잠깐 서비스에 문제가 발생 한다던가, 네트워크가 갑자기 느려져 타임아웃이 발생한다던가 말이다.

예전의 모니터링 툴에서는 CPU나 메모리만 보면 정상처럼 보이기 때문에 잡아내는게 어렵다.

이로 인해 Observability (서비스 관측성)이 중요해지고 있다.

단순히 "서버가 살아있나" 를 보기보다 내 요청이 어디로 가서 얼마나 걸리고 어디서 막히는지 실시간으로 추적이 필요해졌기 때문이다.

오늘은 Observability를 위한 다양한 오픈 소스 중에 CNCF(Cloud Native Computing Foundation)의 프로젝트인 OpenTelemetry에 대해서 공부해보고자 한다.

OpenTelemetry란 무엇일까?

OpenTelemetry는 줄여서 OTel이라 표기하기때문에 지금부터 OTel로 표현하도록 하겠다.

OTel은 Trace, Metrics, Logs 이 3가지 핵심 관찰성 데이터를 생성하고 수집하고 관리하는 통합 표준이라고 볼 수 있다.

Metrics: 시간에 따른 숫자 측정값(CPU 사용률, 응답 시간, 요청 수)
Log: 이벤트 기록(에러 메세지, 디버그 정보 등). 디버깅에 사용
Traces: 분산 시스템에서 요청의 전체 경로 추적. 호출 관계와 성능 병목 파악 가능

다만, OTel 자체에서는 데이터 저장이나 쿼리 기능을 제공하지 않는다. 대신 표준화된 방식으로 Telemetry 데이터를 생성하고 수집한 뒤, 다양한 백엔드 시스템으로 전송하는 역할만 담당하고 있다.

• 상용 서비스의 경우: Dataodg, New Relic, Groundcover와 같은 SaaS 플랫폼

• 오픈소스 백엔드의 경우: Grafana, Prometheus, Jaeger등의 자체 호스팅 솔루션

  Grafana 대시보드라면 많이들 들어봤을 것이다. Grafana에서 OTel로 수집한 데이터를 활용해 실시간 모니터링 대시보드를 구축할 수 있다.

결국, OTel은 어떻게 관찰성 데이터를 만들고 보낼 것인가에 대한 표준이지 어디에 저장하고 어떻게 볼 것인가는 OTel의 역할이 아니라고 볼 수 있다.

OpenTelemetry 아키텍처 및 구성 요소

OTel은 개발 언어별로 SDK, 데이터 변환 수집, 변환 및 데이터 내보내기 등 여러 구성 요소로 구성된다.

SDK (Software Development Kit)
개발자가 애플리케이션에 관찰성 기능을 쉽게 추가할 수 있도록 제공되는 라이브러리 세트

Java, Python, Go, JavaScript, PHP 등 주요 언어를 지원한다.

https://opentelemetry.io/docs/languages/

• API :

  • 텔레메트리 데이터 생성을 위한 인터페이스
  • 언어별로 제공

• SDK :

  • 코드에서 자동으로 메트릭, 로그, 트레이스 생성
  • HTTP 요청, 데이터베이스 쿼리, 외부 API 호출 등을 자동 추적
  • 수동으로 커스텀 매트릭 가능
  • 예) Otel SDK 추가 후 설정 코드 추가 -> Otel Collector가 데이터 수집
  • Collector :
    • 텔레메트리 데이터 수신, 처리, 전송
    • 다양한 백엔드로 데이터 라우팅 가능

OpenTelemetry Collector

Otel Collector는 측정 데이터인 Metrics, Traces, Logs를 수집하고 처리해서 여러 백엔드로 동시에 전송 가능하다. 콜렉터가 없다면 각각의 백엔드 서비스마다 다른 설정을 해야하지만, Collector를 사용하면 각 백엔드 앱마다 설정을 따로 하지 않아도 된다.

  Collector 없이:
  앱1 → Prometheus
  앱2 → Jaeger
  앱3 → Datadog
  각각 다른 설정, 복잡함


  Collector 있으면:
  앱1,2,3 → OTel Collector → Prometheus
                          → Jaeger
                          → Datadog

OpenTelemetry Collector의 구성

OTel Collector의 경우 수집 (receive), 처리 (process), 전송 (export)로 구성된다.

• Receiver(수집):
  • 여러 애플리케이션에서 보내는 메트릭, 로그, 트레이스를 수신 받는다.
  • 하나 이상의 수집기를 구성할 수 있다.
• Processor(처리):
  • 수신한 데이터를 백엔드로 보내기 전에 데이터를 필터링, 변환, 샘플링한다.
  • 민감한 정보를 제거할 수 있고
  • 데이터 포맷을 변환할 수 있다.
• Exporter(전송):
  • 여러 백엔드로 동시 전송이 가능하다.

이 OTel Collector의 경우 yaml로 설정할 수 있는데 아래의 예와 같다.

 # collector-config.yaml
  receivers:
    # OTLP 프로토콜로 데이터 수신
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

    # Prometheus 메트릭 스크래핑
    prometheus:
      config:
        scrape_configs:
          - job_name: 'my-app'
            static_configs:
              - targets: ['localhost:8080']

  processors:
    # 샘플링 (10%만 저장)
    probabilistic_sampler:
      sampling_percentage: 10.0

    # 메모리 제한
    memory_limiter:
      limit_mib: 400
      spike_limit_mib: 100

    # 배치 처리
    batch:
      timeout: 1s
      send_batch_size: 1024

    # 리소스 속성 추가
    resource:
      attributes:
        - key: environment
          value: production
          action: upsert

  exporters:
    # Jaeger로 트레이스 전송
    jaeger:
      endpoint: jaeger-collector:14250
      tls:
        insecure: true

    # Prometheus로 메트릭 전송
    prometheus:
      endpoint: "0.0.0.0:8889"

    # Datadog으로 전송
    datadog:
      api:
        key: "${DD_API_KEY}"
        site: datadoghq.com

  service:
    pipelines:
      # 트레이스 파이프라인
      traces:
        receivers: [otlp]
        processors: [memory_limiter, probabilistic_sampler, batch]
        exporters: [jaeger, datadog]

      # 메트릭 파이프라인
      metrics:
        receivers: [otlp, prometheus]
        processors: [memory_limiter, resource, batch]
        exporters: [prometheus, datadog]

      # 로그 파이프라인
      logs:
        receivers: [otlp]
        processors: [memory_limiter, batch]
        exporters: [datadog]

모니터링 앱에서 OpenTelemetry를 사용하는 이유

지금까지 글을 읽어보면 단번에 대답할 수 있을 것이다.

우선 각 백엔드별로 개별 설정 파일이 필요하다. 버전 업데이트도 따로따로할테고, 문제가 생기면 어느 에이전트 때문인지 알기 어렵다. 만약 Datadog을 쓰다가 New Replic으로 바꾸게 되어도 코드를 전체 다 다시 작성해야할 것이다.

그러나 Otel을 사용하면, Collector의 설정값만 바꾸면 되기 때문에 데이터 수집은 OTel에 맡기고, 데이터 분석과 시각회에 집중할 수 있어 더 나은 모니터링 앱을 만들 수 있을 것이다.

출저: https://opentelemetry.io/docs/

프로젝트마다 다른 데이터베이스를 사용하는 이유가 궁금해졌다

현재 회사에서 3개의 프로젝트를 담당하고 있는데, 흥미롭게도 각 프로젝트가 서로 다른 데이터베이스를 사용하고 있다. 하나는 PostgreSQL(RDBMS)을, 나머지 두 개는 MongoDB(NoSQL)를 사용 중이다.

솔직히 말하면, 지금까지는 각 데이터베이스를 "왜" 선택했는지 깊이 고민해본 적이 없다.

운영 중인 첫 번째 프로젝트는 투입 당시 이미 PostgreSQL이 세팅되어 있었고, 급하게 운영에 들어가야 했기에 기술 선택의 배경을 파악할 여유가 없었다. 나머지 프로젝트들도 선임 개발자들의 결정을 따라갔을 뿐, 그 이유를 깊이 탐구하지 못했다.

그런데 최근 새로운 프로젝트를 시작하면서 또 다시 NoSQL을 사용하게 되자, 문득 의문이 들었다.

"왜 어떤 프로젝트는 RDBMS를 쓰고, 어떤 프로젝트는 NoSQL을 선택하는 걸까?"

데이터베이스를 집🏠으로 비유해보자.

PostgreSQL (RDBMS) = 아파트 🏢

아파트를 생각해보면 모든 집이 똑같은 구조로 되어있다. 101호도 방 3개에 화장실 1개, 102호도 방 3개에 화장실 1개. 규칙이 엄격해서 방을 마음대로 추가하거나 제거할 수 없다. 그리고 아파트 자체는 관리사무소가 있기 때문에 관리가 체계적이고 자유롭게 뭔가 관리할 수 없다.

NoSQL (MongoDB) = 단독 주택 🏠

한 마을에 단독 주택들을 떠올려보자. 각 주택마다 구조가 저마다 다 다르다. 어떤 집은 방이 2개고, 어떤 집은 방만 5개에다 지하실과 다락방이 존재할 수도 있다. 아파트에 비해 자유롭게 개조할 수 있고, 관리사무소가 통제하고 있지 않아서 각자 관리하고 있다.

이번에는 기술적으로 바라보자.

RDBMS (PostgreSQL) = 구조화된 세계

Schema 스키마

RDBMS의 경우 Schema (스키마)라는 미리 정해진 설계도가 존재한다. 모든 데이터가 정해진 테이블과 컬럼 형식을 따라야 한다. 따라서 RDBMS의 경우, 모든 경우를 위한 컬럼을 미리 다 만들어야한다. 그리고 여기에서는 데이터 타입, 길이, 관계가 엄격하게 정의되고 있다.

ACID 보장

• Atomicity : 거래가 전부 성공하거나 전부 실패
• Consistency : 데이터 무결성 유지
• Isolation : 동시 작업 간 충돌 방지
• Durability : 한 번 저장된 데이터는 영구 보존

따라서 RDBMS의 경우 정확한 거래 기록이 필수인 금융 시스템이나, 재고 관리 시스템과 같이 복잡한 관계를 가진 데이터를 다뤄야할때 사용하면 좋다.

NoSQL = 유연한 세계

Schema-less

NoSQL의 경우 단독주택처럼 각 문서(document)가 다른 구조일 수 있다. 따라서 필드를 자유롭게 추가/삭제할 수 있기 때문에 빠른 개발과 변경이 잦을 경우 사용하기 유리하다.

Horizontal Scaling 수평적 확장

한 마을에 집들을 더 짓는 것처럼 서버를 늘려서 성능을 향상시킬 수 있고, 대용량 데이터를 처리하거나 분산 처리하기 용이하다.

따라서 NoSQL의 경우 다양한 콘텐츠가 있는 소셜 미디어나, 센서마다 다른 데이처인 IoT 데이터를 수집할때 좋으며, 실시간 분석이 필요한 빅데이터를 다룰때 사용하면 좋다.

실제로 데이터가 어떻게 저장될까?

PostgreSQL의 경우

 학생 테이블 (무조건 이 칸을 다 채워야 함!)
  ┌─────────┬────────┬─────┬────────┬──────────┐
  │ 학생번호  │   이름  │  나이 │   반   │  전화번호  │
  ├─────────┼────────┼─────┼────────┼──────────┤
  │    1    │ 이올뱌   │  17 │  3-2  │ 010-1234  │
  │    2    │ 이슭    │  16 │  2-5  │ 010-5678  │
  │    3    │ 햅삐슭  │  17 │  3-1  │    NULL    │ <- 전화번호 없으면 NULL
  └─────────┴───────┴─────┴───────┴────────────┘


  성적 테이블 (학생 테이블과 연결됨)
  ┌─────────┬─────────┬──────┬──────┐
  │  성적번호 │  학생번호 │  과목  │ 점수  │
  ├─────────┼─────────┼──────┼──────┤
  │    1    │    1    │ 수학  │  90  │
  │    2    │    1    │ 영어  │  85  │
  │    3    │    2    │ 수학  │  95  │
  └─────────┴─────────┴──────┴──────┘

특징:

• 이올뱌의 성적을 보려면 학생번호 1을 찾아서 성적 테이블과 연결해야 한다.
• 새로운 정보(예: 혈액형)를 추가하려면 전체 테이블 구조를 바꿔야 한다. 현재 학생 테이블에는 학생 번호, 이름, 나이, 반, 전화번호만 존재하기 때문이다.
• 모든 학생이 똑같은 정보를 가져야하고 만약 정보가 없다면 NULL이 들어와야 한다.

NoSQL의 경우

[
    {
      "학생번호": 1,
      "이름": "이올뱌",
      "나이": 17,
      "반": "3-2",
      "전화번호": "010-1234",
      "성적": [  // 바로 여기에 성적 정보를 넣음!
        {"과목": "수학", "점수": 90},
        {"과목": "영어", "점수": 85}
      ],
      "특별활동": ["개발부", "과학동아리"]  // 이올뱌만 있는 정보
    },
    {
      "학생번호": 2,
      "이름": "이슭",
      "나이": 16,
      "반": "2-5",
      "전화번호": "010-5678",
      "성적": [
        {"과목": "수학", "점수": 95, "담당선생님": "김선생님"}  // 이슭의 선생님 
  // 정보 추가
      ],
      "알레르기": ["먼지"]  // 이슭만 있는 정보
    },
    {
      "학생번호": 3,
      "이름": "햅삐슭",
      "나이": 17,
      "반": "3-1"
      // 전화번호 필드 자체가 없어도 OK
    }
  ]

성능 차이에서 비교해보자

RDBMS

정확하지만 느릴 수 있다. 복잡한 관계 연산(join)때문에 느려질 수 있지만, 데이터 정확성은 더 높을 수 있다.

NoSQL

빠르지만 주의해야함. 실제로 단순한 조회는 빠르게할 수 있었지만, 연결을 해서 보거나 좀더 깊은 데이터만 뽑아 보려고할 때 연산이 어려운 것을 느꼈다.

실제 프로젝트와 비교해보자.

3개의 프로젝트는 성격이 아주 다르다.

A 프로젝트 : K8s 관리 플랫폼 MongoDB 사용

쿠버네티스를 관리하고 있기때문에 쿠버네티스 리소스(pod, service, deployment ...)가 계속해서 변화할 수 있기 때문에 동적인 데이터 구조를 가지고 있다. 시스템 이벤트들이 각각 다른 형태의 메타데이터를 보유하고 있고, 클러스터가 커질수록 대량의 로그와 매트릭 데이터를 처리해야하기 때문에 MongoDB를 사용하게 되었다.

  @Schema({ versionKey: false })
  export class Event {
    @Prop() podName: string;
    @Prop() uid: string;
    @Prop() timestamp: string;
    @Prop() type: string;
    @Prop() reason: string;
    @Prop() message: string;
  }

B 프로젝트 : 자동차 소프트웨어 관련 시스템

차량 소프트웨어 배포의 경우 실패하면 안되기 때문에 엄격한 데이터가 일관적이여야한다. 또한 사용자 - 이벤트 - 권한 등등 서로 밀접하게 연결되어있어서 테이블마다 복잡하게 엮여져있다.

  @Entity('')
  export default class TABLE {
    @PrimaryColumn() versionId: string;
    @Column({ nullable: true }) eventId: string;
    @Column({ nullable: true }) versionName: string;
    @Column({ type: 'boolean', nullable: true }) approval: boolean;
    @Column({ type: 'json', nullable: true })
    part: { ecuNm: string; scomoNodeNm: string }[];
  }

그러나 B 프로젝트의 경우, Kafka로 거의 1초마다 대량의 로그 데이터를 수신 받고 있다. 그리고 로그에는 JSON 형태로도 저장하고 있기때문에 이런 용도라면 MongoDB가 더 적합할 것이라고 생각했다.

하지만, Kafka 메세지를 수신받기 전 이미 PostgreSQL 기반으로 시스템이 구축되어 있고, 로그 데이터보다 통합 관리의 목적으로 다른 테이블에 있는 데이터들이 더욱 중요하기 때문에 PostgreSQL을 사용하고 있다. 또한 각 테이블마다 매우 밀접하게 연결되어있어서 Kafka를 제외하고서는 PostgreSQL이 운영자 입장에서 더욱 편하게 사용할 수 있었다.

Three.js 프로젝트를 통해 웹의 새로운 가능성을 탐구하고, 사용자에게 혁신적인 온라인 경험을 제공하고자 합니다.

1. 프로젝트 개요

1.1 프로젝트명

“3D 인터랙티브 웹 경험 (3D Interactive Web Experience)”

1.2 프로젝트 중간 보고

Three.js를 사용하여 개발된 인터랙티브 3D 우주 시뮬레이션입니다.

메인 프로젝트 전 three.js를 학습하고자 만든 페이지 입니다. 지구와 달, 주변의 별들로 이루어진 간단한 태양계를 시뮬레이션화 했습니다. 지옥에서 온 고양이 캐릭터와 함께 다양한 카메라 컨트롤을 통해 사용자 상호작용 요소를 포함하고 있습니다.

1.3 기술 스택

• Frontend: HTML5, CSS3, JavaScript
• 3D 렌더링: Three.js
• 배포 관리: Netlify
• 버전 관리: Git

2. 프로젝트 세부 내용

# 2.1 프로젝트 구조

현재 프로젝트 구조

project_root/
│
├── dist/
├── node_modules/
│── src/
│   ├── texture/
│   │   ├── cat_eyes.png
│   │   └── fur.jpg
│   ├── cat.js
│   ├── index.html
│   ├── main.css
│   ├── main.js
│   ├── planet.js
│   └── spaceProject.js
├── babel.config.js
├── package-lock.json
├── package.json
├── README.md
└── webpack.config.js

현재 프로젝트 구조의 문제점

[모듈화 부재]

• spaceProject.js 에 scene, camera, 객체 생성 등 너무 많은 다양한 기능들이 혼재되어 있음.
• cat, planet만 분리되어있고, 다른 주요 컴포넌트들은 개별 모듈로 분리되어있지 않다.

→ 가독성 및 유지보수성 떨어짐

#2.2 프로젝트 구조 개선 방안

컴포넌트 기반 구조화

project_root/
│
├── dist/
├── node_modules/
└── src/
    ├── components/
    │   ├── Planet.js
    │   ├── Star.js
    │   └── Cat.js
    ├── scenes/
    │   ├── MainScene.js
    ├── controllers/
    │   └── OrbitController.js
    ├── assets/
    │   ├── textures/
    │   └── models/
    ├── styles/
    │   └── main.css
    ├── index.html
    └── main.js

• components: 각 3D 객체를 개별 컴포넌트로 분리하여 재사용성과 유지보수성을 높일 수 있다.
• scenes: 여러 씬을 관리할 수 있게 되어 추후 로딩 화면, 메인 화면 등을 별도로 구현할 수 있다.
• controllers: 입력 처리와 관련된 로직을 한 곳에서 관리할 수 있다. 현재는 카메라 관련 컨트롤러만 넣어 놓은 상태다.
• assets : 모든 외부 리소스를 관리한다.
• styles: CSS 파일을 별도 폴더에서 관리한다

3. 주요 기능

Geometry & Material만 가지고 만든 
“지옥에서 온 고양이..”

1. 우주 시뮬레이션

• 지구와 달의 사실적인 3D 모델
• bump 매핑과 반사 하이라이트를 통해 텍스쳐 표면
• 지구와 달의 대기 효과
• 지구 주위를 도는 달의 rotation

2. 우주 환경 효과

• 움직이는 별
• 은하수같은 별 배경 효과

3. 조명

• 사실감을 위한 그림자 생성
• 다양한 조명 포함

2. 상호작용

• 줌인/아웃 등 카메라 효과
• scene 내에서 드래그 가능한 고양이 캐릭터
• 카메라 및 회전 등 설정을 조정할 수 있는 GUI 컨트롤
• 전체 화면 rotation

4. 기술적 시도

핵심 컴포넌트로 createPlanet 를 통해 지구 및 달을 생성한다.

[행성 표면 만들기]

const surfaceGeometry = new THREE.SphereGeometry(surface.size, 32, 32);
const surfaceMaterial = new THREE.MeshPhongMaterial({
  map: new THREE.TextureLoader().load(surface.textures.map),
  bumpMap: new THREE.TextureLoader().load(surface.textures.bumpMap),
  bumpScale: surface.material.bumpScale,
  specularMap: new THREE.TextureLoader().load(surface.textures.specularMap),
  specular: surface.material.specular,
  shininess: surface.material.shininess,
});
const planetSurface = new THREE.Mesh(surfaceGeometry, surfaceMaterial);
planetGroup.add(planetSurface);

• SphereGeometry로 구 모양을 만든 뒤 . surface.size로 크기를 정한다.
• MeshPhongMaterial로 행성 표면의 재질을 만든다.
  • map: 행성 표면의 기본 이미지
  • bumpMap: 표면에 울퉁불퉁한 느낌을 주는 이미지
  • specularMap: 빛이 반사되는 부분
• Mesh로 구 모양과 재질을 합쳐 행성 표면을 만든다
• 만든 표면을 planetGroup에 추가한다.

[행성 표면 만들기]

const surfaceGeometry = new THREE.SphereGeometry(surface.size, 32, 32);
const surfaceMaterial = new THREE.MeshPhongMaterial({
  map: new THREE.TextureLoader().load(surface.textures.map),
  bumpMap: new THREE.TextureLoader().load(surface.textures.bumpMap),
  bumpScale: surface.material.bumpScale,
  specularMap: new THREE.TextureLoader().load(surface.textures.specularMap),
  specular: surface.material.specular,
  shininess: surface.material.shininess,
});
const planetSurface = new THREE.Mesh(surfaceGeometry, surfaceMaterial);
planetGroup.add(planetSurface);

• SphereGeometry로 구 모양을 만든 뒤 . surface.size로 크기를 정한다.
• MeshPhongMaterial로 행성 표면의 재질을 만든다.
  • map: 행성 표면의 기본 이미지
  • bumpMap: 표면에 울퉁불퉁한 느낌을 주는 이미지
  • specularMap: 빛이 반사되는 부분
• Mesh로 구 모양과 재질을 합쳐 행성 표면을 만든다
• 만든 표면을 planetGroup에 추가한다.

[⭐️ 지구와 달의 대기효과 만들기]

Shader 사용

Shader를 사용하기 전에는 단순한 Mesh만을 이용한 구를 사용해 대기를 표현했다. 이 방식을 사용하니 실제 대기와 같은 자연스러운 발광 효과를 만들기 어려웠고, 그라데이션 효과를 구현하는 것도 한계가 있었다.

Shader의 경우 픽셀 단위로 색상과 투명도를 정밀하게 제어할 수 있고, 카메라 위치에 따라서 대기의 모습을 동적으로 변경할 수 있었다. 또한, 수학적인 계산을 통해 더 사실적인 발광 효과를 만들 수 있어서 Shader를 사용하게 되었다.

const atmosphereMaterial = new THREE.ShaderMaterial({
  vertexShader: `
    ...
  `,
  fragmentShader: `
    uniform vec3 glowColor;
    uniform float coefficient;
    uniform float power;
    void main() {
      float intensity = pow(coefficient - dot(vNormal, vec3(0, 0, 1.0)), power);
      gl_FragColor = vec4(glowColor, 1.0) * intensity;
    }
  `,
  uniforms: {
   ...
  },
  ...
});

[코드 설명]

GLSL과 Shader 사용

Shader은 픽셀 단위로 색상을 정의하기 때문에 GLSL를 사용했다. shader에게 명령을 전달하기 위해서는 shader 언어(GLSL, HLSL 등)으로 작성된 작성된 코드가 필요하기 때문이다.

GLSL은 Three.js의 기본 material로는 구현하기 어려운 복잡한 시각 효과를 만들 수 있고, vec3, dot() 와 같은 함수를 사용해서 그래픽에 필요한 함수를 제공하기 때문이다. 사실 GLSL은 C 기반 언어라서 C/C++를 사용할 수 있다면 쉽게 작성할 수 있겠지만, 나는 C언어에 대한 지식이 부족하여 공부 후 더 정리하도록 하겠다.

uniform vec3 glowColor;
uniform float coefficient;
uniform float power;

1. uniform vec3 glowColor;

   uniform은 셰이더 프로그램 전체에서 동일한 값을 가지는 변수를 선언할 때 사용한다. vec3는 RGB 색상을 나타낸다. glowColor는 발광 효과의 색상을 지정하는 변수로, 색상 코드를 사용해 대기에 빛나는 부분을 설정한다.

2. `uniform float coefficient; float는 소수점이 있는 숫자 타입, 그리고coefficient`으로, 위에 설정한 발광 효과의 강도를 조절하는 것이다.

3. `uniform float power; power`는 발광 효과가 얼마나 강한지 약한지를 제어해주는 값.

[계산식]

void main() {
  float intensity = pow(coefficient - dot(vNormal, vec3(0, 0, 1.0)), power);
  gl_FragColor = vec4(glowColor, 1.0) * intensity;
}

1. intensity: 각 픽셀의 발광 강도

float intensity = pow(coefficient - dot(vNormal, vec3(0, 0, 1.0)), power); - pow(… , power) - pow는 지곱 함수로, 사용자가 에서 설정한 발광 효과 강도에서 dot(..) 값을 뺀뒤, 발광 효과의 강도를 조절한다, 이를 통해 가장자리에서 중심으로 갈때 더 자연스럽게 발광 효과가 줄어들 수 있도록 설정할 수 있다. 만약, pow를 사용하지 않더라면, 직선 형태로 일정하게 연한 값으로 줄어들기 때문에 자연스럽지 못하다.

• coefficient - dot(vNormal, vec3(0, 0, 1.0))
• vNormal은 지구나 달 표면의 각 점에서의 방향을 말한다. vNormal과 카메라 방향이 일치하면 (dot = 1) ⇒ 행성 중심 ( 구 가운데 ) vNormal과 카메라 방향이 거의 수직이라면 (dot = 0) ⇒ 행성 가장자리 (구 보면 옆에 동그라미 라인)
• vec3(0, 0, 1.0)은 카메라 방향을 나타내며 정면을 가르키고 있다.
• ceofficient - dot() ceofficient를 1이라고 가정한다면, 행성의 중심: 1 - 1 = 0 (어두움) | 행성 가장자리: 1 - 0 = 1 (밝음)
• 위의 값에서 coefficient를 빼는 이유: 행성의 가장자리가 밝고, 점점 어두워지는 효과를 주기 위해서임. 그냥 값을 뒤집어서 우리가 원하는 밝다가 점점 어두워지는 효과를 만들기 위함.

Shader 사용 전 후

Shader 사용 전/후 비교를 위해 임시적으로 발광하는 부분의 크기를 변경해서 비교했다.

전)

• 그라데이션 효과가 없다.

• 부자연스럽고 지구위에 막이 덮힌 느낌이라 지구의 색이 선명하지 못함

5. 어려웠던 점

해당 시뮬레이션을 만들면서 가장 힘들었던점은 에러 로깅. 기존 React나 Next.js 의 경우 콘솔에 에러 내용이 나왔는데 three.js는 어떠한 로그도 찍혀있지 않은 경우가 꽤나 있었다.

scene에 등록을 하지 않는다던가, 컨트롤끼리 충돌이 났다던가, 혹은 뭔가 설정이 잘 못 되어있어서 그냥 흰 바탕만 나오는 경우가 있어서 뭐가 문제인지 알아내기가 조금 힘들었다.

이에 관련해서 에러 로깅이라던지 다른 방법이 있는지 알아보고난 후 적용시켜 본 프로젝트를 시작하면 좋을 것 같다.

컨트롤 파넬은 ui 수정이 가능한지 봐야겠다. 뭔가 안이쁨. 내스타일이 아님. 이쁜게조아ㅏㅏㅏㅏ~ 🧚‍♀️✨ 별도 너무 정신없이 너무 많다. 사용자가 보고있다보면 어지러울 수 있을 것 같아서 좀 더 자연스러운 별을 만들어보도록 해야겠음,.,.,

Three.js 프로젝트를 통해 웹의 새로운 가능성을 탐구하고, 사용자에게 혁신적인 온라인 경험을 제공하고자 합니다.

1. 프로젝트 개요

1.1 프로젝트명

“3D 인터랙티브 웹 경험 (3D Interactive Web Experience)”

1.2프로젝트 목적

Three.js를 활용하여 사용자에게 독특하고 몰입감 있는 3D 웹 경험을 제공하는 인터랙티브 홈페이지 목업 개발

1.3 프로젝트 기대 효과

• 기업 또는 개인의 온라인 존재감 강화
• 사용자 참여도 및 체류 시간 증가
• 기술 혁신을 통한 브랜드 이미지 제고

2. 프로젝트 세부 내용

2.1 주요 기능

1. 3D 인터랙티브 내비게이션
   • 3D 공간에서 마우스/터치로 이동 가능 메뉴 시스템
2. 동적 3D 배경
   • 사용자 상호작용에 반응하는 애니메이션 배경
3. 3D 제품/서비스 쇼케이스
   • 회전, 확대/축소가 가능한 3D 모델 전시
4. 인터랙티브 데이터 시각화
   • 3D 그래프, 차트를 통한 정보 표현
5. 가상 투어
   • 3D 공간을 탐험할 수 있는 가상 환경

2.2 기술 스택

• Frontend: HTML5, CSS3, JavaScript
• 3D 렌더링: Three.js
• 반응형 디자인: CSS Grid, Flexbox
• 버전 관리: Git

2.3 개발 단계

1. 기획 및 디자인 (2주)
   • 와이어프레임 및 3D 모델 concept 설계
2. 3D 모델링 및 텍스처 작업 (3주)
   • 필요한 3D 에셋 제작
3. Three.js 기반 개발 (4주)
   • 3D 렌더링 및 인터랙션 구현
4. UI/UX 개선 및 최적화 (2주)
   • 사용자 경험 향상 및 성능 최적화
5. 테스트 및 디버깅 (1주)
   • 크로스 브라우저 테스트 및 버그 수정

3. 리소스

문제 상황

운영 중인 서비스에서 데이터 센터로부터 CPU 사용량이 MAX를 기록했다는 알림 메일을 받았다. 처음에는 특정 시간대에만 발생하는 문제라면 크론잡(cron job) 관련 이슈일 가능성을 생각했지만, 실제로는 불특정 시간에 지속적으로 발생하는 문제였다.

문제 원인 분석

CPU 사용률이 급증하는 원인을 파악하기 위해 데이터베이스 성능부터 점검해보기로 했다. PostgreSQL에서 테이블별 스캔 통계를 확인할 수 있는 쿼리를 실행했다.

SELECT schemaname, relname, seq_scan, seq_tup_read, idx_scan
FROM pg_stat_user_tables
ORDER BY seq_tup_read DESC;

이 쿼리를 통해 각 테이블의 아래 목록을 확인할 수 있었다:

• seq_scan: Sequential Scan(전체 테이블 스캔) 횟수
• seq_tup_read: Sequential Scan으로 읽은 행의 총 개수
• idx_scan: Index Scan 횟수

문제 발견

통계 결과를 분석한 결과, 가장 많이 스캔되는 상위 4개 테이블에서 인덱스가 설정되지 않은 컬럼들이 빈번하게 조회되고 있었다. 이로 인해 매번 전체 테이블을 스캔(Full Table Scan)하면서 CPU 사용률이 급증한 것으로 판단되었다.

해결 방법

운영 중인 서비스이므로 서비스 중단 없이 인덱스를 추가해야 했다. PostgreSQL의 CONCURRENTLY 옵션을 사용하여 인덱스를 생성했다.

CREATE INDEX CONCURRENTLY index_name ON "table_name" ("column_name");

CONCURRENTLY 옵션을 사용하는 이유

✅ CONCURRENTLY 사용 시

• 인덱스 생성 중에도 테이블에 대한 읽기/쓰기 작업이 정상적으로 가능
• 서비스 중단 없이 인덱스 생성 가능
• 사용자 경험에 영향 없음

❌ CONCURRENTLY 미사용 시

• 인덱스 생성 동안 해당 테이블이 완전히 락(lock) 됨
• 모든 INSERT, UPDATE, DELETE 작업이 블록됨
• 테이블 크기에 비례하여 락 시간 증가 (수 분 ~ 수십 분)
• 서비스 장애 발생 위험

성능 개선 결과

인덱스 추가 후 쿼리 실행 시간을 테스트해보았다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT "table"."column"
FROM "table"
WHERE "table"."column" = 'test_value'
LIMIT 1;

실행 계획 분석 결과, 쿼리 실행 시간이 대폭 단축되었다.

결론

• 운영 서버의 성능 이슈 발생 시 데이터베이스 스캔 통계 확인이 효과적
• 자주 조회되는 컬럼에는 반드시 적절한 인덱스 설정 필요
• 운영 중인 서비스에서는 CONCURRENTLY 옵션으로 무중단 인덱스 생성 권장
• 성능 최적화 후 반드시 실행 계획 분석을 통한 검증 수행

간단한 인덱스 추가만으로도 시스템 성능을 크게 개선할 수 있었던 사례였다. 자세한건 운영팀의 모니터링 결과를 좀 보긴 해야한다..!

정사각형 형태의 2차원 배열(행렬)이 주어졌을 때, 왼쪽 대각선 (primary diagonal) 과 오른쪽 대각선 (secondary diagonal)의 합의 절댓값 차이를 구하시오.

입력 예시

3
11 2 4
4 5 6
10 8 -12

11 + 5 + -12 = 4 4 + 5 + 10 = 19 답 : 4 - 19 = 15

풀이 과정

처음에 어떻게 풀어야하는지 이해가 가지 않아서 차근차근 하나씩 손으로 적어가면서 이해했다. 여기서 가장 중요했던 개념은 array[i][i]

array[i][i]란?
해당 열의 인텍스를 찾는 것이다.

예를 들어 [1, 3, 5]가 있다고 하면, array[0][1]은 3이 된다. 0번째열에 1번째 인덱스의 값을 찾는 것이기 때문이다.

11 2 4
4 5 6
10 8 -12

의 경우에는 다음과 같이 손으로 먼저 적었다. 11, 5, -12를 먼저 추출해야했으니,

• arr[0][0] = 11
• arr[1][1] = 5
• arr[2][2] = -12

그 다음으로 4, 5, 10 추출

• arr[0][2] = 4
• arr[1][1] = 5
• arr[2][0] = 10

여기서 가만히보면 이런 생각이 든다. 왼쪽에서 오른쪽으로 내려가는 대각선의 경우 인덱스와 열이 같다. arr[i][i] 하지만 오른쪽에서 왼쪽으로 내려가는 대각선은 다음과 같은 느낌이다. 지금 현재 배열의 길이가 3개다. 그럼 arr[i][배열의 길이 - i -1]을 한 값과 같다고 볼 수 있다. 그래서 다음과 같이 코드를 짰다.

 right += arr[i][(len-i-1)];

여기서 절대값을 구해야하는데, 위의 값으로는 -값이 붙는다. 그래서 Math.abs()를 사용해서 절대값을 구했다.

Kubernetes 환경에서 vector는 DaemonSet으로 배포되어 모든 노드에 하나씩 상주하며, 로그 및 메트릭 수집을 수행한다. 반면, kube-state-metrics는 클러스터의 상태 정보를 제공하는 단일 Pod로 배포된다. 현재 구성에서는 각 노드의 vector 인스턴스가 동일한 kube-state-metrics 데이터를 모두 수집하고 있어, 중복된 메트릭 전송 및 저장 문제가 발생하고 있다. 이를 해결하기 위해 Node Affinity와 Pod Affinitiy가 언급되어 해당 기능에 대해 공부하고자 한다.

⚠️ 문제 사항

vector DaemonSet → 모든 노드에 존재 kube-state-metrics → 1개의 노드에만 존재

모든 vector가 동일한 kube-state-metrics 엔드포인트를 scrape → 데이터 중복 수집, 스토리지 낭비, 리소스 과소비 발생

🔍 Pod Affinity란?

Pod Affinity는 Kubernetes 스케줄링 기능 중 하나로, 특정 조건을 만족하는 다른 Pod가 존재하는 노드에만 새로운 Pod을 배포하도록 지정할 수 있다.

✳️ 주요 용도

같은 노드에 앱과 사이드카 또는 로깅 에이전트 등을 공존시키고자 할 때, 데이터 로컬리티가 중요한 경우 (예: 캐시 활용, 동일 디스크 접근)

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
          - key: app
            operator: In
            values:
              - kube-state-metrics
      topologyKey: "kubernetes.io/hostname"

→ 위 설정은 kube-state-metrics Pod이 있는 노드에만 새로운 Pod을 배치하게 함

⚙️ Node Affinity란?

Node Affinity는 노드에 정의된 label을 기준으로, 특정 Pod이 배포될 노드를 제어하는 스케줄링 기능. DaemonSet과 같이 모든 노드에 배포되는 리소스에 대해서도 적용 가능하며, 특정 노드에만 제한적으로 배포되도록 구성할 수 있다.

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
          - key: ksm-node
            operator: In
            values:
              - "true"

→ ksm-node=true label이 설정된 노드에만 해당 Pod이 배포됨

하지만 해당 기능은 부적합할 수 있다고 판단.

✅ Pod Affinity 방식의 한계

1. DaemonSet과 Pod Affinity는 근본적으로 충돌

Pod Affinity는 “다른 Pod가 있는 노드에 배치된다”

만약, kube-state-metrics가 있는 노드에만 vector를 배치하려고 할 경우:

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: kube-state-metrics
      topologyKey: "kubernetes.io/hostname"

그러나 DaemonSet은 모든 노드에 무조건 배포된다.

-> kube-state-metrics가 없는 노드에도 배포되려 하기 때문에, affinity 조건과 충돌하게 된다. 이렇게되면 나머지 노드에는 affinity 조건이 맞지 않아 배포되지 않음 → vector의 다른 기능 (예: 로그 수집)도 사라짐

🔎 즉, Pod Affinity는 Deployment에는 유용하지만, DaemonSet에는 적절하지 않다.

2. Pod Affinity는 스케줄링 시점 기준이며, 동적 환경에 취약

Pod Affinity는 "이 노드에 kube-state-metrics가 있어야만 배포됨"이라는 조건을 요구한다. 하지만 현실에서는 kube-state-metrics Pod이 재시작하거나 다른 노드로 옮겨질 수 있다. 이럴 경우 vector Pod이 사라지거나 생성되지 않을 수 있다. → 불안정한 배포

3. ⚠️ DaemonSet + Pod Affinity의 제약사항

DaemonSet의 특성:

• 모든 노드에 1개씩: DaemonSet은 기본적으로 모든 노드에 배포
• Affinity 무시: Pod Affinity는 DaemonSet에서 제한적으로 동작
• NodeSelector 우선: DaemonSet은 nodeSelector, tolerations만 주로 사용

kube-state-metrics의 특성:

• 단일 파드: 일반적으로 Deployment로 1개 파드만 실행
• 유동적 배치: Kubernetes가 적절한 노드에 스케줄링
• 재시작 시 이동: 파드 재시작/재스케줄링 시 다른 노드로 이동 가능

🤔 Pod Affinity 방식의 문제점

1. kube-state-metrics 이동 시 문제:

1. kube-state-metrics가 worker001에 있음
2. worker001의 Vector만 수집 중
3. kube-state-metrics가 worker002로 이동
4. worker001 Vector는 계속 시도하지만 실패
5. worker002 Vector는 아직 수집 안함
→ 데이터 수집 중단!

2. 동적 감지의 복잡성:

• 실시간 감지 어려움: initContainer는 파드 시작 시에만 실행
• 지속적 모니터링 필요: kube-state-metrics 이동을 실시간 감지 어려움
• 복잡한 로직: Kubernetes API 지속적 호출 필요

3. 성능 오버헤드:

• API 호출 부담: 모든 Vector가 지속적으로 kube-state-metrics 위치 확인 ⚡ 지연 시간: 동적 감지로 인한 수집 지연

Pod Affinity vs 라벨 기반 비교

meme이랑 비슷한 상황,, 클라우드에 올린 클러스터들이 많아서 비용문제로 인해 클러스터 삭제가 필요했다. 이에따라 DB 데이터를 백업해야하는 상황.

현재 MongoDB를 사용하고 있으므로, MongoDB 데이터를 안전하게 백업하는 방법에 대해서 정리하겠다.

1. 파드 상태 확인

실행 중인 MongoDB 파드를 확인해야한다.

kubectl get pods -A

2. 파드에 접속해 데이터 확인

MongoDB 파드에 접속해서 실제로 데이터가 있는지 확인한다.

# 파드 접속
kubectl exec -it [mongoDB파드 이름] -n [네임스페이스] -- bash

# MongoDB 접속 및 데이터 확인
mongo
> show dbs
> use [db이름]
> show collections
> db.resources.count()
> exit
> exit

3. mongodump로 데이터 백업

MongoDB의 mongodump 명령어를 사용해 모든 데이터를 BSON 형식으로 백업

kubectl exec -it [파드이름] -n [네임스페이스] -- mongodump --out /tmp/backup

BSON 형식으로 백업하는 이유

• 데이터 타입 무손실

  • ObjectId, Date, NumberLong, Binary, Decimal128 등 모든 MongoDB 타입 보존
  • 인덱스 정보도 함께 백업됨

• 빠른 복원 속도

  • 바이너리 형식이라 복원이 매우 빠름
  • 대용량 데이터에서 특히 효과적

JSON 형식의 한계

• ObjectId가 문자열로 변환되어 원본과 달라짐
• Date 타입이 ISO 문자열로 변환
• 복원 시 타입 변환 문제 발생 가능
• 인덱스 정보 손실

4. 백업 파일 확인

# 백업 디렉토리 확인
kubectl exec -it [파드이름] -n [네임스페이스] -- ls -la /tmp/backup/

# 백업 크기 확인
kubectl exec -it [파드이름] -n [네임스페이스] -- du -sh /tmp/backup/

5. 백업 파일 압축

네트워크 전송을 위해 백업 파일 압축 필요

# 파드 내에서 압축
kubectl exec -it [파드이름] -n [네임스페이스] -- tar -czf /tmp/mongodb-backup.tar.gz -C /tmp backup

# 압축 파일 크기 확인
kubectl exec -it [파드이름] -n [네임스페이스] -- ls -lh /tmp/mongodb-backup.tar.gz

6. 로컬로 백업 파일 복사

kubectl cp 명령어를 사용해 압축된 백업 파일을 로컬로 복사합니다.

# 로컬로 복사 (현재 디렉토리에 날짜별로 저장)
kubectl cp [네임스페이스]/[파드이름]:/tmp/mongodb-backup.tar.gz ./mongodb-backup-$(date +%Y%m%d-%H%M%S).tar.gz

7. 로컬에서 압축 해제 및 내용 확인

# 복사된 파일 확인
ls -lh mongodb-backup-*.tar.gz

# 압축 해제
tar -xzf mongodb-backup-*.tar.gz

# 백업 내용 확인
ls -la backup/

백업된 파일 구조

backup/
├── admin/
│   ├── system.version.bson
│   └── system.version.metadata.json
└── [db이름]/
    ├── accounts.bson
    ├── accounts.metadata.json
    ├── resources.bson
    ├── resources.metadata.json
    ├── events.bson
    ├── events.metadata.json
    └── ... (기타 컬렉션들)

각 MongoDB 컬렉션마다 두 개의 파일이 생성된다.

• .bson 파일: 실제 데이터 (바이너리 형식)
• .metadata.json 파일: 인덱스 및 컬렉션 설정 정보

8. 데이터 복원 방법 (참고)

나중에 새로운 MongoDB 인스턴스에서 데이터를 복원할 때를 대비해 미리 작성

# 백업 파일을 새 파드로 복사
kubectl cp ./backup [네임스페이스]/[새로운 파드 이름]:/tmp/restore-backup

# 데이터 복원
kubectl exec -it [새로운 파드 이름] -n [네임스페이스] -- mongorestore /tmp/restore-backup

정리

• mongodump: MongoDB 데이터를 BSON 형식으로 완전 백업
• 압축 전송: 네트워크 효율성을 위한 tar.gz 압축
• kubectl cp: 쿠버네티스 파드와 로컬 간 파일 전송
• 완전한 복원: BSON + metadata로 인덱스까지 완벽 복원 가능

Linux의 커널은 컴퓨터를 부팅하면 하드웨어 메모리에 올라가서 끌때까지 메모리 위에서 동작한다. 따라서 응용 프로그램을 실행하면, 커널이 메모리에 충분한 공간이 있는지 없는지 모니터링하는 역할을 하게 된다.

기존 Linux 모니터링의 한계

제한적인 관찰 능력

• 정해진 형태의 정보만 제공: 커널이 미리 준비해둔 데이터만 확인 가능
• 낮은 실시간성: 주로 1초 단위로 업데이트되는 평균값만 제공
• 표면적인 정보: 시스템 내부에서 일어나는 세부적인 동작을 파악하기 어려움

커널 확장의 위험성

만약 커널 내부에서 일어나는 일들을 사용자가 원하는 방식으로 관찰하거나, 수정하기 위해서는 커널 모듈(kernel module) 을 작성해야했는데 이 방식은 위험하고 복잡한 작업이었다. 이 작업은 마치 집 구조를 바꾸려고 할때, 벽을 허무는 것과 같은 작업이다. 만일하나 실수를 하게되면 집 전체가 무너질 수 있는 위험도가 컸다.

eBPF: 안전한 커널 확장 기술

반면 eBPF는 Linux 커널의 한계를 확장시켜 사용할 수 있다. 기존의 커널을 사용하려면, 커널 모듈(kernel module)을 작성해야했다. 하지만, eBPF는 샌드박스 환경에서 안전하게 커널 레벨 코드를 실행할 수 있게 해준다. 또한, 커널이 기본적으로 제공하는 모니터링은 제한적이었으나, eBPF로는 네트워크 패킷 하나, 시스템 콜 호출, 파일 접근 등 실시간으로 세밀하게 관찰하고 분석할 수 있다.

eBPF의 핵심 장점

1. 안전한 실행 환경

• 샌드박스 보호: 격리된 환경에서 코드 실행
• 사전 검증: 코드 로딩 전 안전성 검사
• 메모리 보호: 허용된 메모리 영역만 접근 가능
• 무한루프 방지: 실행 시간 제한으로 시스템 보호

2. 동적 기능 추가

시스템 재부팅 없이 커널에 새로운 기능을 즉시 추가할 수 있다.

예시: 웹 서버 보안

상황: 웹 서버에 특정 IP의 요청만 차단하고 싶은 경우

• 기존 방식: 커널의 동작 방식을 바꾸거나 확장이 필요하기 때문에 수정 후 재부팅이 필요했고, 재부팅을 하지 않는다면 시스템 크래시가 발생할 위험이 있었다.
• eBPF 방식: 안전하면서 즉시 적용할 수 있게 되었고, 재부팅이 불필요해서 안전하게 새로운 기능을 추가할 수 있다

이는 수천 대의 서버를 관리하는 환경에서 특히 중요하다. 서비스 중단 없이 보안 정책이나 모니터링 규칙을 실시간으로 적용할 수 있기 때문이다.

모니터링 방식의 혁신적 변화

Linux

Linux 에서는 "이미 만들어진 음식을 받아먹는 것"으로 볼 수 있었다. 1초 단위로 업데이트되는 평균값들을 커널이 미리 준비해둔 정보만 볼 수 있었고, 정해진 형식으로만 데이터를 제공받을 수 있었다.

netstat -an | grep :80
# 결과: 현재 80포트 연결 상태의 스냅샷만 제공

eBPF

eBPF에서는 "주방에 들어가 요리하는 과정을 직접 보는 것"으로 볼 수 있다. 커널 내부에서 일어나는 모든 일들을 "나노초 단위로 실시간으로 정밀하게 측정하여 관찰할 수 있다.

bpftrace -e 'kprobe:tcp_connect { 
    printf("%s PID:%d -> %s:%d (지연시간: %dus)\n", 
           comm, pid, ntop(arg1), arg2, elapsed/1000) 
}'

연결 시도 순간마다 실시간 추적이 가능하고, 어떤 프로그램이 어디에 얼마나 빨리 연결했는지 상세 정보를 확인 할 수 있다. 또한, 데이터 커스터마이징이 가능한 장점이 있다.

클라우드 환경에서 eBPF의 중요성

클라우드 네이티브 환경, 특히 Kubernetes와 같은 환경에서는 수천 개의 컨테이너가 복잡한 네트워크 환경에서 작동한다. 기존의 모니터링 도구로는 상세한 문제 추적이 어려워 eBPF 기반 도구가 점점 중요해지고 있다.

• 실시간 성능 모니터링: 컨테이너의 성능을 초정밀 실시간으로 측정 및 관리
• 네트워크 트래픽 분석: 상세한 패킷 수준의 실시간 트래픽 추적
• 보안 위협 탐지: 이상 행동과 잠재적인 보안 위협을 신속히 식별
• 서비스 메쉬 관찰성 향상: 컨테이너 간 통신 흐름과 장애를 실시간으로 명확히 추적하여 빠른 문제 해결 지원

서비스 메시와 eBPF 기반 도구들

서비스 메시(Service Mesh)

여러 서비스들이 서로 데이터를 주고 받을 때, 각 지점마다 전담 프록시를 두고, 중앙에서 모든 과정을 관리하는 시스템이라고 볼 수 있다.

왜 서비스 메시가 필요한가?

전통적인 방식 (모놀리식):

하나의 큰 애플리케이션
[사용자] → [하나의 큰 애플리케이션] → [데이터베이스]

- 쇼핑몰 전체가 하나의 프로그램
- 주문, 결제, 배송이 모두 한 덩어리 

마이크로서비스 방식

[사용자] → [API Gateway] 
                ↓
[주문서비스] ↔ [결제서비스] ↔ [재고서비스] ↔ [배송서비스]
    ↓           ↓           ↓           ↓
[주문DB]    [결제DB]    [재고DB]    [배송DB]

마이크로서비스 방식의 경우, 서비스들 간의 통신이 복잡해졌다. 어떤 서비스가 어떤 서비스와 얼마나 많이 통신하는지 파악이 어려워, 네트워크 오류, 보안, 트래픽 제어 등을 각 서비스마다 따로 관리하는 문제가 있었다.

서비스메시의 역할

서비스메시는 이런 복잡한 통신을 투명하게 관리해주는 도구다.

서비스 메시가 없었을 때는 개발자가 직접 통신해야했다.

[주문서비스] --직접통신--> [결제서비스]
(개발자가 직접 재시도, 암호화, 모니터링 코드 작성)

그러나 서비스 메시가 있을 경우, 중앙에서 모든 통신들을 관리하기

서비스 메시 있을 때:
[주문서비스] → [프록시] → [프록시] → [결제서비스]
                ↑                ↑
            자동으로 재시도,     자동으로 암호화,
            로드밸런싱,          모니터링
            트래픽 분석

메트릭(Metric)

메트릭 = 측정 가능한 숫자 데이터

서버 상태:
- CPU 사용률: 75%
- 메모리 사용량: 8GB / 16GB
- 디스크 사용률: 60%
- 네트워크 트래픽: 100Mbps

메트릭 수집이 왜 중요한가?

메트릭 없이 서버 관리한다면 다음과 같은 상황 발생

상황: 쇼핑몰 웹사이트가 갑자기 느려짐

개발자: "어? 왜 느리지?"
방법: 서버에 직접 접속해서 하나씩 확인
- htop 실행해서 CPU 확인
- free 명령어로 메모리 확인  
- df 명령어로 디스크 확인
- 로그 파일 하나씩 뒤져보기

문제: 이미 문제가 생긴 후에야 알 수 있음

메트릭을 수집하면 문제를 즉시 발견하고 원인을 파악하기 용이하다.

상황: 쇼핑몰 웹사이트가 갑자기 느려짐

모니터링 대시보드에서 즉시 확인:
- CPU: 95% (빨간불) ← 문제 발견!
- 메모리: 90% (주황불)
- 응답시간: 5초 (빨간불)
- 에러율: 10% (빨간불)

결과: 문제를 즉시 발견하고 원인도 바로 파악

eBPF로 메트릭 수집 방법

기존 방식 vs eBPF 방식

기존 방식

외부에서 관찰

모니터링 프로그램이 1초마다:
cat /proc/cpuinfo     # CPU 정보 읽기
cat /proc/meminfo     # 메모리 정보 읽기
netstat -an          # 네트워크 연결 정보 읽기

문제점:

• 1초 단위로만 확인 가능
• 평균값만 알 수 있음
• 세세한 내부 동작은 모름

eBPF 방식

내부에서 실시간으로 관찰

커널 내부에 eBPF 프로그램을 심어두고:
- 함수가 호출될 때마다 측정
- 네트워크 패킷이 올 때마다 기록
- 파일이 읽힐 때마다 시간 측정

결과:

• 나노초 단위 정밀 측정
• 실시간 데이터
• 세세한 내부 동작까지 파악

eBPF 메트릭 수집 장점

1. 정확성

기존: "평균적으로 응답시간이 2초"
eBPF: "95%는 100ms, 4%는 500ms, 1%는 10초"

→ 1%의 매우 느린 요청이 문제라는 걸 정확히 파악할 수 있다.

2. 실시간성

기존: 1분 후에 "아, 1분 전에 문제가 있었음"
eBPF: "지금 이 순간 문제 발생!!!"

3. 세밀함

기존: "네트워크가 느림"
eBPF: "TCP 연결 설정은 빠른데, 데이터 전송에서 지연이 생김. 
      특히 192.168.1.100 서버와 통신할 때만 느림"   

정리

메트릭 수집 = 컴퓨터의 상태를 숫자로 측정해서 기록하는 것 eBPF로 메트릭 수집 = 커널 내부에서 실시간으로 정확하게 측정하여 더 빠르고 정확한 문제 발견할 수 있고, 세밀한 성능 분석과 자동화된 대응을 가능하게 한다.

Cilium, Hubble, Prometheus

eBPF가 내장됨. (즉, Cilium과 Hubble을 설치하면 자동으로 eBPF가 사용됨)

직접 eBPF로 개발을 한다는 것은 '자동차 엔진을 직접 만드는 것'과 같다. C언어로 직접 eBPF 프로그램을 작성해야하고, 커널에 직접 로드해야한다. 데이터 수집 로직도 구현해야하기 때문에 매우 복잡하고 어렵다.

그러나, Cilium과 Hubble을 사용하면 이미 eBPF가 내장되어있어 '완성된 자동차'를 구매하는 것 과같다. Cilium과 Hubble은 설치만하면 바로 사용 가능하기 때문에 복잡한 개발 과정이 불필요하다.

Cilium

네트워킹 + 보안

Cilium은 eBPF기반 쿠버네티스 네트워킹 솔루션이다.

Cilium 설치 시

# Cilium 설치
helm install cilium cilium/cilium --namespace kube-system

Cilium 설치시 커널에 자동으로 로드되는 eBPF 프로그램들:

Cilium이 설치되면 자동으로 eBPF 프로그램들이 커널에 로드되고, 아래와 같은 기능들을 사용할 수 있게 된다.

• 네트워크 패킷 필터링
• TCP/UDP 연결 추적
• HTTP 요청/응답 분석
• 보안 정책 적용
• 메트릭 수집
• 로드밸런싱

# 설치만
kubectl apply -f cilium.yaml

# cilium-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
data:
  # eBPF로 네트워크 정책 적용
  enable-policy: "true"
  # eBPF로 로드밸런싱
  enable-l7-proxy: "true"
  # 실시간 모니터링 활성화
  enable-hubble: "true"

위의 Yaml을 등록하면, Cilium은 알아서 수십 개의 eBPF 프로그램을 커널에 로드하게 된다. 그렇게되면 실시간으로 네트워크 모니터링을 시작하게 되고, 메트릭 수집을 자동으로 시작한다.

Cilium이 하는 일:

• Pod 간 네트워크 통신 관리
• 보안 정책 적용 (어떤 Pod끼리 통신 가능한지)
• 로드밸런싱
• 네트워크 메트릭 수집

Hubble

관찰! 위의 Cilium을 관찰하는 도구임.

# Hubble로 실시간 네트워크 트래픽 관찰
hubble observe

# 출력 예시:
# Oct 20 12:34:56.789: frontend-pod -> backend-pod:8080 (HTTP GET /api/users)
# Oct 20 12:34:56.792: backend-pod -> db-pod:3306 (TCP)
# Oct 20 12:34:56.845: db-pod -> backend-pod:3306 (TCP)
# Oct 20 12:34:56.850: backend-pod -> frontend-pod:8080 (HTTP 200 OK)

-> 로그 보니까 Skuber에서 log에 보이는 로그들과 비슷한 것 같음. (확인 필요)

네트워크 정책 적용

# network-policy.yaml
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-to-backend"
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
  - toEndpoints:
    - matchLabels:
        app: backend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

# 적용하면 eBPF가 자동으로 패킷 필터링 시작
kubectl apply -f network-policy.yaml

Hubble이 수집하는 메트릭

# 서비스별 트래픽 통계
hubble metrics list
# - dns_queries_total
# - drop_count_total  
# - tcp_flags_total
# - http_requests_total

백그라운드에서 일어나는 일

1. kubectl apply 명령 실행
2. Cilium이 정책을 읽음
3. eBPF 프로그램을 자동으로 생성/업데이트
4. 커널에서 즉시 패킷 필터링 시작
5. 정책 위반 패킷은 자동으로 차단

Prometheus

메트릭 저장소로 메트릭을 수집하고 저장하는 데이터베이스.

# prometheus-config.yaml
global:
  scrape_interval: 15s

scrape_configs:
  # Hubble에서 메트릭 수집
  - job_name: 'hubble'
    static_configs:
      - targets: ['hubble:9090']

  # 내 Go 애플리케이션에서 메트릭 수집  
  - job_name: 'my-go-app'
    static_configs:
      - targets: ['my-app:8080']

Go 예시

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "time"

    "github.com/gorilla/mux"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

// 상품 구조체
type Product struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Price int    `json:"price"`
}

// Prometheus 메트릭 정의
var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "총 HTTP 요청 수",
        },
        []string{"method", "endpoint", "status_code"},
    )

    httpDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name: "http_duration_seconds",
            Help: "HTTP 요청 처리 시간",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "endpoint"},
    )

    databaseConnections = prometheus.NewGauge(
        prometheus.GaugeOpts{
            Name: "database_connections_active",
            Help: "활성 데이터베이스 연결 수",
        },
    )
)

수정중..,

next.js 프로젝트를 서버에 배포하고 빌드하는 과정에서 두 가지 주요 오류가 발생했다🤦‍♀️.

• 빌드 시 권한 문제
• 서버 실행 시 포트 충돌 문제

이 글에서는 위의 문제의 원인과 해결 과정을 공유하고자 한다.

오류 1: 빌드 시 권한 문제 (EACCES: permission denied)

next build 명령을 실행했을 때 다음과 같은 오류가 발생했다.

> Build error occurred
[Error: EACCES: permission denied, unlink '/.../.next/server/middleware-manifest.json'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'unlink',
  path: '/.../.next/server/middleware-manifest.json'
}

도대체 middleware-manifest가 뭔데 여기 접근을 못하는걸까?

middleware-manifest.json

middleware-manifest.json 파일은 Next.js 빌드 시 생성되는 내부 메타데이터 파일 중 하나다. Middleware, Edge Functions 및 관련 라우팅 정보를 Next.js 런타임에서 사용하기 위해 이 매니페스트 파일에 포함된다. 일반적으로 next build 시 자동으로 생성되며, .next/server/ 디렉토리 내부에 위치한다.

여기서 에러메세지를 보면 빌드 프로세스 중에 이 파일에 접근할 수 없어서 에러가 발생했다는 뜻이다.

• EACCES: permission denied - 파일 시스템 권한 거부
• syscall: 'unlink' - 파일을 삭제하려고 시도했으나 실패
• /.../.next/server/middleware-manifest.json - 문제가 발생한 파일 경로

즉, Next.js가 빌드 과정에서 middleware-manifest.json 파일을 삭제하거나 수정하려고 했지만, 해당 파일에 대한 충분한 권한이 없어서 build를 실패하는 것이다.

해결 시도

방법 1 .next 디렉토리 삭제 후 다시 빌드

가장 먼저 시도해 볼 수 있는 방법은 기존 빌드 결과물인 .next 디렉토리를 삭제하고 다시 빌드하는 것이다.

sudo rm -rf /경로/.next
npm run build

하지만, 이 방법으로 해결되지 않았고, 동일한 오류가 계속 발생했다.

방법 2. 권한 변경

오류 메세지처럼 파일/디렉토리 권한 문제일 가능성이 높으므로, .next 디렉토리에 대한 권한을 변경했다.

sudo chmod -R 777 /경로/.next
npm run build

chmod -R 777은 모든 사용자에게 모든 권한을 부여하므로 보안상 권장되지 않는다. 임시적인 해결책이나 테스트 환경에서만 사용하는 것이 좋으며, 실제 운영 환경에서는 빌드를 실행하는 사용자에게 필요한 최소한의 권한만 부여하거나 파일 소유권을 올바르게 설정하는 것이 바람직하다. (예: sudo chown -R $(whoami) /프로젝트경로/.next)

오류 2: 포트 충돌 문제 (EADDRINUSE: address already in use)

권한 문제를 해결한 후 npm run build가 성공하고 서버를 시작하려고 할 때 다음과 같은 포트 충돌 오류가 발생했다.

Browserslist: caniuse-lite is outdated. Please run:
0|ccap-admin-stg  |   npx browserslist@latest --update-db
0|ccap-admin-stg  |   Why you should do it regularly: https://github.com/browserslist/browserslist#browsers-data-updating
0|ccap-admin-stg  | Error: listen EADDRINUSE: address already in use :::8090
0|ccap-admin-stg  |     at Server.setupListenHandle [as _listen2] (node:net:1463:16)
0|ccap-admin-stg  |     at listenInCluster (node:net:1511:12)
0|ccap-admin-stg  |     at Server.listen (node:net:1599:7)
0|ccap-admin-stg  |     at /경로/server.stg.js:25:6 {
0|ccap-admin-stg  |   code: 'EADDRINUSE',
0|ccap-admin-stg  |   errno: -98,
0|ccap-admin-stg  |   syscall: 'listen',
0|ccap-admin-stg  |   address: '::',
0|ccap-admin-stg  |   port: 8090
0|ccap-admin-stg  | }
0|ccap-admin-stg  | error - uncaughtException: Error: listen EADDRINUSE: address already in use :::8090

EADDRINUSE 오류는 Error: Address Already in Use의 약자로, 애플리케이션이 사용하려고 하는 네트워크 포트(이 경우 8090)를 이미 다른 프로세스가 사용하고 있음을 의미한다.

해당 프로젝트의 경우, 8090 포트는 현재 Next.js 애플리케이션(FE)이 사용하도록 설정된 포트다. 뭔가 이전에 비정상적으로 종료되었거나 다른 방식으로 실행된 동일 애플리케이션의 인스턴스가 포트를 계속 점유하고 있을 가능성이 높다.

해결 과정

1. 이미 실행 중인 포트가 있는지 확인

먼저, 어떤 프로세스가 8090 포트를 사용하고 있는지, 그리고 PM2로 관리되는 관련 프로세스가 있는지 확인했다.

ss -tulpn | grep 8090
pm2 list

ss -tulpn | grep 8090
tcp   LISTEN 0      511                *:8090             *:*
[서버 계정]$ pm2 list
[PM2] Spawning PM2 daemon with pm2_home=/경로/.pm2
[PM2] PM2 Successfully daemonized
┌────┬───────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name      │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
└────┴───────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘

ss 명령어 결과, 8090 포트가 LISTEN 상태인 것을 확인했다. 하지만 pm2 list 결과에는 해당 포트를 사용하는 것으로 예상되는 PM2 프로세스가 없었다. 이는 이전 애플리케이션이 PM2를 통하지 않고 실행되었거나, PM2 프로세스가 비정상 종료되어 포트만 점유된 상태일 수 있다고 판단했다.

2. 포트 종료 및 재실행

sudo kill -9 $(sudo fuser -n tcp 8090 2>/dev/null)

pm2 start ecosystem.stg.config && pm2 logs 0

원인 불명의 프로세스가 8090 포트를 점유하고 있으므로, 해당 프로세스를 찾아 강제로 종료했다. fuser 명령어를 사용하면 특정 포트를 사용하는 프로세스의 PID를 찾아 종료할 수 있다.

또 만났다. NGINX Nginx는 도대체 뭐때문에 날 이렇게 괴롭히는 것인지?

문제 상황

현재 프로젝트 서버 마이그레이션중으로 to-be 서버에 Next.js 프로젝트를 배포했다. 화면은 정상적으로 나오지만, 브라우저 콘솔에는 Websocket오류가 계속 발생했다. 🤦‍♀️ 그만 좀 떠라 제발..

회사 url이 있기 때문에 사진 첨부는 어렵지만, 대략 아래와 같은 메세지가 반복해서 나왔다. 🚨 WebSocket connection to 'wss:// [domain]: 8080/_next/webpack-hmr' failed

사실 화면도 잘 뜨고 프로젝트도 잘 돌아가니까, 굳이 해야하나 싶었다. 그치만 콘솔창 들어갈때마다 보이는 에러가 보기 싫어서 결국 구글링 및 삽질해서 해결했다.

해결은 역시나 nginx.conf 😊

프로젝트 환경

우선 해당 프로젝트 스펙을 간단하게 정리해본다.

• Next.js: v12
• Nginx: 프록시 서버로 사용
• 배포 도구: PM2
• 특이사항: Websocket을 실제로 사용하지 않는 프로젝트, Load Balancer를 통한 SSL 사용

문제 해결 과정

시도 1: Next.js 설정 수정 - 해결 ❌

WebSocket을 사용하지 않는 프로젝트다. next.js v12는 서버 커넥션 유지를 위해 WebSocket을 활용하기 시작했다. 이에 따라 Next.js 버전 11에서 12로 업그레이드한 사용자 중에 해당 에러가 빈번히 발생하는 문제가 많음을 발견했다. 여기서 나는 Next.js에서 웹소켓 연결을 시도하는 것이 문제라고 판단해 next.config.js 를 수정하고자 했다. 몇몇 사용자는 v11로 내리니 에러가 사라졌다고 하나, *프로젝트는 처음부터 v12버전을 사용하고 있었기때문에 11로 버전을 내릴 생각은 없었다. *

그래서 next.js next.config.js에서 HMR(Hot Module Replacement) 관련 설정을 비활성하려고 시도했다.

실제 운영중인 프로젝트이기때문에 소스코드를 그대로 적을 수 없어 추가한 설정만 남겨놓겠다.

module.exports = withTM({
  publicRuntimeConfig,
  trailingSlash: true,
  reactStrictMode: false,
  experimental: {
    esmExternals: false,
    jsconfigPaths: true
  },
  webpack: (config) => {
    config.resolve.alias = {
      ...config.resolve.alias,
     ...
    }

    config.optimization = {
      ...config.optimization,
      runtimeChunk: false,
      splitChunks: false
    }

    return config;
  },

  webSocketTransport: false,
  async rewrites() {
    return rewrites
  }
})

결과 실패. 😢 계속 같은 에러가 발생했고, WebSocket 연결 시도가 계속되어졌다.

시도 2: Next.js 설정에 header 설정 추가 - 해결 ❌

WebSocket 연결 실패가 CORS(Cross-Origin Resource Sharing) 정책 위반일 수 있다고 판단했다. 브라우저 보안 정책으로 인한 차단일 수 있어서 CORS header 추가를 시도했다.

    async headers() {
    return [
      {
        source: '/_next/webpack-hmr',
        headers: [
          {
            key: 'Access-Control-Allow-Origin',
            value: '*'
          },
          {
            key: 'Access-Control-Allow-Methods',
            value: 'GET, POST, PUT, DELETE, OPTIONS'
          },
          {
            key: 'Access-Control-Allow-Headers',
            value: 'X-Requested-With, Content-Type, Upgrade, Connection'
          },
          {
            key: 'Connection',
            value: 'Upgrade'
          },
          {
            key: 'Upgrade',
            value: 'websocket'
          }
        ]
      }
    ]
  }

결과 역시 실패 😢😢 CORS Header를 여러개 추가하고 삭제도 해보고 해봤지만, 같은 에러가 발생했다. 이에따라 단순한 CORS 문제가 아님을 깨달았다.

시도 3: ecosystem.config파일 수정 - 해결 ❌

next.config.js 설정만으로는 해결이 안되어 프로세스 실행 환경(pm2)에서 WebSocket을 비활성하려고 시도했다. 환경변수를 통해서 Node.js레벨에서 WebSocket 연결을 막을 수 있을 것이라 예상했다.

module.exports = {
  apps: [
    {
      name: "",
        ...
      env: {
        ...,
        NEXT_HAS_CLIENT_WEBSOCKETS: "false",
        DISABLE_WEBSOCKET: "true"
      },
    }
  ]
}

결과로는 실패했다. 😢😢😢 환경변수 설정 적용이 안되었고, 여전히 같은 에러가 발생했다.

사실 이 이외에도 다양한 설정들을 주고 적용해봤지만 결과는 여전히 실패였다..

시도 4: Nginx 수정 - 해결 ✅

에러 메세지가 wss://로 시작하는 것을 보고 혹시 SSL/TLS 관련 문제이지 않을까? 라고 추측했다. 기존 프로젝트의 경우, SSL은 nginx에서 처리했다. 하지만 To-be 서버에서는 LB(Load Balancer)에서 SSL을 처리하도록 변경되었다. 이로 인해 WebSocket의 프로토콜 업그레이드가 제대로 되지 않는걸까? 라는 추측에서 시작되었다. 또한, nginx 프록시 서버로 작동하면서 WebSocket 연결 요청을 제대로 처리하지 못하는 걸수도 있다고 추측했다.

(실제로는 여러 시도가 실패하다 보니 '이쯤 되면 nginx 문제겠지...'하는 마음 99.99999% .... 👉👈)

시도 4-1 : nginx 설정 수정 - 해결 ➿

현재 프로젝트는 8081 포트로 접속한다. 그래서 당연히 nginx.conf에서8081 포트에 WebSocket 설정을 수정해줬다.

server {
    listen 8081;  
    server_name name~;

    location / {
        proxy_pass http://localhost:8090;
    }
    location /_next/webpack-hmr {
        proxy_pass http://localhost:8090;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

결과로는 실패했다. 😢😢😢😢 계속 같은 에러가 발생했다. nginx 도 문제가 아닌걸까... 하다가 다시 에러 메세지를 확인했다.

🚨 WebSocket connection to 'wss:// [domain]: 8080/_next/webpack-hmr' failed

시도 4-2 : nginx 설정 수정 - 해결 ✅

에러메세지를 자세히보니 8080 포트가 언급되어있다. 즉, 클라이언트가 8080포트로 WebSocket 연결을 시도하고 있다고 판단해서 위의 설정을 8080포트에도 설정해줬다.

server {
    listen 8080;  
        ....

    location / {
        proxy_pass http://localhost:8090;
    }

    location /_next/webpack-hmr {
        proxy_pass http://localhost:8090;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

결과 성공 🎉🎉

더 이상 해당 에러가 콘솔에서 보이지 않았다.

next.js는 서버 상태 유지를 위해 WebSocket을 사용하는데, nginx에 관련 설정이 없어서 연결이 계속 끊어지고 있었다. 또한, 클라이언트는 8080 포트로 접속을 시도하는데, 나는 8081 포트만 설정해둔 것이 문제였다.

따라서 클라이언트가 접속하는 8080 포트에 WebSocket 설정을 추가하여 해결할 수 있었다.

여기까지 느낀 결과: 에러 메세지를 잘 읽자. 😊 라고 했으나 내가 8080 포트로 들어가서 그랬던 것.... ^^

참고: https://github.com/vercel/next.js/issues/30491

배경

현재 운영 중인 프로젝트는 Kafka Consumer로 구성되어 있어, 다른 회사(Producer)로 부터 주기적으로 메세지를 전달받고 있다.

꽤나 방대한 양의 메세지를 받는 중이다🧚‍♀️✨ 현재 서버 마이그레이션 작업이 진행 중이라 모니터링하는 과정에서 서버의 메모리 이슈가 발생했다. 꽤나 중요한 문제였기때문에 그동안 삽질하면서 해결했던 과정에 대해서 정리하려고 한다.

.pm2 로그 관리를 통한 서버 메모리 이슈 해결 내용이 필요한 분들은 가장 하단으로 이동해주길 바란다.

기타 환경

node.js 애플리케이션의 상용 프로세스를 관리하는 도구로 현 프로젝트는 pm2를 사용하고 있다. pm2를 이용해서 애플리케이션이 종료되지 않도록 유지시켜주며, 다운타임 없이 재시작할 수 있게 된다.

🚨 문제 상황 1: git pull or build이슈

💡 현상

테스트 중 소스 코드 변경이 필요해서 WAS 서버에서 git pull을 시도했으나, 서버 용량 부족으로 인해 git pull이 되지 않았다.

git pull로 당겨서 업데이트 된 소스코드를 받았지만, build가 안되는 문제 또한 발생했다.

$ npm run build
npm ERR! code ENOSPC
npm ERR! syscall write
npm ERR! errno -28
npm ERR! nospc ENOSPC: no space left on device, write
npm ERR! nospc There appears to be insufficient space on your system to finish.
npm ERR! nospc Clear up some disk space and try again.

npm ERR! A complete log of this run can be found in:
npm ERR!    .../.log

🛠️ 조치

급하게 소스 코드를 업데이트해서 빌드해야했으므로 임시 방편으로 임시 파일들을 지우는 방법으로 조치하고 작업을 수행했다.

급하게 처리한 것이라 정리가 안되었다. 순서가 바뀔 수 있을텐데 그래도 필요한 분이 있다면 참고가 되었으면 하는 마음에 사용했던 방법들을 아래에 정리해놨다.

rm -rf .git/objects/pack/*.pack
rm -rf .git/objects/pack/*.idx

rm -f .git/objects/pack/._pack-*
rm -rf .git
git init
git remote add origin https://github.com/was.git
git pull
git remote show origin

git branch
git branch --set-upstream-to=origin/main master
git pull
git checkout -b main origin/main

// 문제 발생

$ git branch --set-upstream-to=origin/main master
fatal: branch 'master' does not exist

$ git pull origin main
From https://github.com/was
 * branch            main       -> FETCH_HEAD
error: Untracked working tree file '.dockerignore' would be overwritten by merge.

git clean -f .dockerignore
git pull origin main
git status
git diff origin/main
git branch -avv 
git remote -v 
git branch -m master main 
git branch --set-upstream-to=origin/main main 
git ls-remote origin
git remote show origin
git fetch origin --prune 
git reset HEAD .
git checkout .
git fetch --all
git reset --hard origin/main

이후에는 git pull과 build를 잘해서 새로운 소스코드를 서버에 잘 반영했다.

🚨 문제 상황 2: Kafka 메세지 수신 이슈

💡 현상

Kafka Broker IP를 변경 후 TO-BE Kafka 트랜잭선이 보이지 않는 문제가 발생했다. WAS log를 모니터링하면 JS stacktrace 에러가 발생한 뒤에 더 이상 Kafka 메세지를 받아오지 못했다.

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

해당 문제는 JavaScript heap out of memory로 heap 메모리가 부족해서 발생한 것이다.

🛠️ 1 차 조치 시도: Cron 작업 주기 조정

Cron을 통해서 작업해야했는데 테스트 때문에 Cron 주기를 너무 빈번하게 했다. cron 작업은 새로운 프로세스를 생성하고 메모리를 할당받기 때문에 너무 빈번한 실행은 결국 메모리 부족을 발생시킬 수 있다. 이에 따라 cron 주기를 한달에 한 번으로 늘렸다.

해결되는 듯했으나, 일시적이였고 곧 메모리 할당 문제로 동일한 현상이 재발했다.

🛠️ 2 차 조치 시도: 로그 최적화

Kafka 메세지가 들어올 때마다 로그가 너무 빈번하게 기록되는 문제를 발견했다. 로그가 과도하게 쌓일 경우, 결국 디스크 공간이 부족할 수 있기 때문에, Kafka 메세지에 대해 한 번만 로그를 기록하도록 수정했다.

물론 어느정도 해결은 되었으나, 동일한 메모리 문제가 발생했다.

🛠️ 3 차 조치 시도: 메모리 추가 할당

다시 에러를 확인했는데, Heap 메모리가 너무 부족한 것이 계속 눈에 밟혔다. 현재 전체 용량이 어느정도인지 확인했다.

$ node -e 'console.log(v8.getHeapStatistics().heap_size_limit/(1024*1024))'

// 2096

2096이니까 약 2배전도 용량을 늘려 메모리 할당을 증가시켰다.

용량을 늘리는 것은 간단하다. ecosystem.config에서 하당의 코드를 그대로 추가했다.

module.exports = {
    apps: [
        {
            name: 'nest',
            script: './dist/main.js',
            node_args:  "--max-old-space-size=4096",,
            ...
        }
    ]
}

한 동안 에러 없이 Kafka 메세지가 제대로 들어오는 것을 확인했다.

🛠️ 4 차 조치 시도: DB 쿼리 최적화

계속 되는 용량 문제때문에 분석하던 중, Kafka 메세지 수신 시 비정상적으로 많은 DB쿼리가 실행되는 것을 발견했다. 문제가 된 쿼리들은 아래와 같았다.

1. 레거시 코드에 남아있는 미사용 쿼리들
2. 불 필요한 중복 조회 쿼리들 
3. 최적화 되지 않은 쿼리문 

위의 쿼리들을 제거하자 Kafka 메세지가 정상적으로 수신되었다. 하지만, 이것 역시 임시적인 해결책에 불과했다.

🛠️ 5 차 조치 시도: 근본 원인 발견

이틀 후 또 다시 메세지가 중단되어 디스크 사용량을 확인해봤다.

$ df -h

확인 결과 .pm2 디렉토리의 로그 파일이 과도하게 누적되어 있었다.

장기간 운영하던 프로젝트이기 때문에, 급격히 늘어난 Kafka 메세지 양으로 인해 로그가 지속적으로 축척되었다.

따라서 로그 파일을 백업한 후 삭제하자, 지금까지도 Kafka 메세지가 안정적으로 수신되는 것을 확인했다.

또 문제가 발생하면 '6차 시도'에 관해 글을 업데이트하겠지만, 현재까지는 로그 파일이 위의 모든 에러들의 근본적인 원인임을 파악하고, 로그 파일을 관리하는 것을 아래에 작성할 것이다.

pm2 로그 파일

기본적으로 pm2는 로그를 /home/user/.pm2에 log 폴더가 존재한다.

// .pm2/logs

$ ls
nest-error.log  nest-out.log

특별한 설정을 해두지 않았기 때문에, nest-error.log와 nest-out.log에 로그가 쌓여있는 것을 확인할 수 있다.

이미 로그를 한 번 삭제했기 때문에, 현재 많은 데이터가 쌓여있지 않지만, 분명 며칠이 지나면 또 가득 찰 것으로 예상된다.

[user@ip logs]$ ls
nest-error.log  nest-out.log

[user@ip logs]$ ls -alh
total 5.4G
drwxr-xr-x. 2 user user 4.0K Dec 18 13:37 .
drwxr-xr-x. 5 user user 4.0K Dec 19 11:16 ..
-rw-r--r--. 1 user user 4.7G Dec 20 06:55 nest-error.log
-rw-r--r--. 1 user user 643M Dec 20 06:55 nest-out.log

PM2 logrotate 모듈

앞서 지금까지 상황을 미루어보아 위의 로그 파일들은 현 프로젝트가 계속 운영될수록 점점 더 쌓여서 또 서버 용량을 가득 차게 만들 것이다.

그럼 분명 디스크 용량이 부족하게되면서 git, build, kafka 메세지 수신등 많은 문제를 일으킬 수 있다.

이를 위해 pm2 로그 파일을 관리하는 pm2 logrotate모듈을 사용해보기로 했다.

PM2 logrotate 모듈이란?

pm2를 실행할때마다 로그 경로에 저장되는 로그들은 직접 삭제해주지 않는다면, 계속 쌓이게 된다. 이 모듈을 설치하게 되면 로그 자동 삭제, 파일 리사이즈 등등 다양한 로그 관리 기능을 이용할 수 있게 된다.

PM2 logrotate 설치 방법

pm2 logrotate 파일은 아래 명령어를 통해 설치할 수 있다.

pm2 install pm2-logrotate

PM2 logrotate 옵션

pm2 conf

pm2 conf를 통해 logrotate에 기본적으로 설정된 옵션을 확인할 수 있다.

• max_size: 각각의 로그파일의 최대 크기. 해당 용량이 넘어가면 다음 파일을 생성하게 된다.(기본값 10M)
• retain: 로그 저장 갯수 (기본값 30개)
• compress: 생성된 로그를 gzip으로 압축 유무 (기본값 false)
• dataFormat: 로그 파일 뒤에 날짜 포맷 (기본값 YYYY-MM-DD_HH-mm-ss)
• workerInterval: 로그 파일 사이즈를 확인하는 1초마다의 횟수. (기본값 초당 30회)
• rotateInterval: cronjob (기본값 0 0 * * -> 매일 정각)
• rotateModule: 새로운 로그 파일 생성 여부 (기본값 true)

기본 설정을 보면, 로그가 10MB 넘길때마다 새로운 로그 파일이 생성되며, 30개 이상 생성되지 않도록 한다. => 300MB 까지만 로그가 기록된다.

현재 꽤나 용량이 크기 때문에 설정을 아래와 같이 바꿨다.

pm2 set pm2-logrotate:rotateInterval "0 0 * * *"
pm2 set pm2-logrotate:compress true
pm2 set pm2-logrotate:retain 30
pm2 set pm2-logrotate:dateFormat YYYY-MM-DD
pm2 set pm2-logrotate:workerInterval 30
pm2 set pm2-logrotate:max_size 2000M

잘 설정되었는지 확인하려면 pm2 conf로 확인할 수 있다.

이렇게 되면 자동으로 ./pm2/logs폴더 안에 nest-out.log, nest-error.log파일들 뒤에 날짜가 붙은채로 압축된 파일이 매일 하나씩 생성될 것이다.

(현재 테스트 중)

이렇게되면 가독성이 없다고 판단해서 폴더를 따로 만들어서 거기다가 압축파일을 옮기고 싶었는데, 하루종일 삽질한 결과 pm2-logrotate에는 그런 기능은 없는듯하다..

🤯 삽질의 기록

궁금한 사람들을 위한 내 삽질 기록..

나는 댕멍청하게 config파일에 error_file과 out_file을 설정하면 될것이라고 판단했다.

module.exports = {
  apps: [
    {
      name: 'nest',
      script: './dist/main.js',
      cwd: '/home/user/was',
      watch: true,
      log_date_format: 'YYYY-MM-DD',
      error_file: '/home/user/was/.pm2/logs/logError/nest-error.log',
      out_file: '/home/user/was/.pm2/logs/logOut/nest-out.log',
      env: {
              ...

이렇게 설정해두고서 로그를 찍어봤는데, pm2 logs nest 0을 하면 실시간으로 로그를 확인할 수 있는데, .pm2/logs/폴더에서는 로그가 저장되지 않았다.

이미 .pm2/logs폴더 안에 nest-out.log와 nest-error.log가 존재하기 때문에 해당 파일을 찾지 못해서 발생하는 문제인 듯 하다.

그래서 해당 설정을 지우니까 다시 log가 잘 저장되었다.

(왜 글이 사라졌냐... 왜....)

지금 정리하면서 든 생각은 이미 있는 nest-out.log와 nest-error.log의 파일 위치를 각각 logOut과 logError 폴더로 이동시키면 되지 않을까..? 라는 생각 ?? 출근해서 테스트 해보고 다시 수정해보겠다. =>cron과 script파일로 수정할 예정.

💡cron & script 설정

테스트해본 결과 pm2-logrotate-out___2024.12.22.log.gz 이런 식으로 pm2-logrotate 로그파일이 계속 생성되었다. 이렇게 될 경우, 또 로그파일이 쌓이면서 디스크 용량이 더 커질 것으로 생각되었다. 따라서 해당 로그파일은 이틀에 한 번씩 삭제하는 걸로 수정하기로 했다. 또한, nest-error와 nest-out 파일이 압축되면서 디렉토리 구조가 너무 지저분하게 관리되는 문제가 있었다. 한 두개의 압축파일은 괜찮겠지만, 한 달동안 둬야할 경우에는 분명 파일 찾아보는 것이 힘들 것이라 판단했다. 이 경우에도 script로 관리하는 것으로 해결했다.

🛠️ script 설정 - pm2-logrotate-out___log.gz 파일 삭제

우선, script 파일들을 저장할 script폴더를 만들었다.

cd .pm2/logs
mkdir -p scripts

이후 pm2-logrotate와 관련된 로그를 지우는 스크립트를 작성했다.

error는 당분간 모니터링을 위해서 지우지 않는 것으로 했다.

vi clean_logrotate_log.sh
#!/bin/bash

LOG_PATH="/home/user/.pm2/logs"

find "$LOG_PATH" -type f -name "pm2-logrotate-out__*.log.gz" -mtime +2 -exec rm -f {} \;

esc -> :wq!로 저장.

만약 스크립트가 잘 작동되는지 확인하려면, ./clean_logrotate_log.sh를 입력해서 해당 로그파일들이 삭제되는지 확인하면 된다.

삭제가 잘 된다면, 스크립트가 실행될 수 있도록 권한을 부여한다.

chmod +x /home/user/.pm2/logs/scripts/clean_logrotate_logs.sh

🛠️ script 설정 - nest-out & nest-error 파일 이동

.pm2/logs/script폴더 안에 스크립트 파일 생성

우선, logs 폴더 안에 errorLog와 outLog 폴더를 생성한다.

mkdir -p errorLog
mkdir -p outLog

./pm2/logs/script폴더로 이동해서 move_nest_logs.sh스크립트를 생성한다.

vi move_nest_logs.sh
#!/bin/bash

SOURCE_DIR="/home/user/.pm2/logs"
ERR_DEST="$SOURCE_DIR/errorLog"
OUT_DEST="$SOURCE_DIR/outLog"

find "$SOURCE_DIR" -type f -name "nest-error__*.log.gz" -exec mv {} "$ERR_DEST" \;

find "$SOURCE_DIR" -type f -name "nest-out__*.log.gz" -exec mv {} "$OUT_DEST" \;

🛠️ cron 설정

매일 자정 위에서 만든 스크립트가 실행되도록 cron을 설정한다.

대신 로그가 찍히는 것을 막기 위해서 /dev/null 2>&1 를 설정해줬다.

crontab -e
0 0 * * * /home/user/.pm2/logs/scripts/clean_logoutrotate_logs.sh > /dev/null 2>&1 && /home/user/.pm2/logs/scripts/move_nest_logs.sh > /dev/null 2>&1

🚨 pm2 install pm2-logroate 설치 에러

npm 네트워크 문제로 설치가 안될 경우

[user@user ~]$ pm2 install pm2-logrotate
[PM2][Module] Installing NPM pm2-logrotate module
[PM2][Module] Calling [NPM] to install pm2-logrotate ...
npm ERR! code ECONNRESET
npm ERR! syscall read
npm ERR! errno ECONNRESET
npm ERR! network request to https://registry.npmjs.org/pm2-logrotate failed, reason: read ECONNRESET
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2024-12-23T07_14_47_792Z-debug-0.log
[PM2][ERROR] Installation failed via NPM, module has been restored to prev version

자꾸 pm2-logrotate를 하는 과정에서 에러가 발생했다. 그래서 직접 수동으로 pm2-logrotate소스코드를 직접 다운받기로 했다.

git clone https://github.com/pm2-hive/pm2-logrotate.git

이 경우, npm 으로 설치할때 글로벌로 설치해야한다.

# sudo로 글로벌 설치
sudo npm install -g

# 또는 현재 위치에서 pm2에 직접 설치
cd pm2-logrotate
pm2 install .

나의 경우, pm2-logrotate 폴더에서 직접 pm2에 설치했다.

설치 후 pm2 conf를 했을 경우, default로 설정되어있는 것들이 설치가 안되어있어서 다시 설치를 해줬다.

pm2 set pm2-logrotate:rotateInterval "0 0 * * *"
pm2 set pm2-logrotate:compress true
pm2 set pm2-logrotate:retain 30
pm2 set pm2-logrotate:dateFormat YYYY-MM-DD
pm2 set pm2-logrotate:workerInterval 30
pm2 set pm2-logrotate:max_size 2000M
pm2 set pm2-logrotate:rotateModule true

안됨. 망할 방화벽.., 안되어서... 쉘 스크립트 또 만들었음..

#!/bin/bash

LOG_DIR="/home/user/.pm2/logs"
RETAIN_DAYS=30
DATE_FMT=$(date '+%Y-%m-%d')


TARGET_FILES=("name-out.log" "name-error.log")

for logfile in "${TARGET_FILES[@]}"
do
  FULLPATH="$LOG_DIR/$logfile"

  if [ -f "$FULLPATH" ]; then
    base_name="${logfile%.log}"
    new_name="${base_name}__${DATE_FMT}.log"

    mv "$FULLPATH" "$LOG_DIR/$new_name"

    gzip -f "$LOG_DIR/$new_name"

  fi
done

pm2 reloadLogs

find "$LOG_DIR" -type f -name "*.gz" -mtime +$RETAIN_DAYS -exec rm -f {} \;

이렇게 만들고 이 파일도 crontab에 추가해주면 된다.

🧚‍♀️ 결론:

pm2-logrotate를 사용하니까 또 pm2.log가 쌓여가서.. 결국은 모든 서버에 scrtips, cron으로 셋팅하고 log-rotate를 제거했다 ^^..,

현회사에서 WEB서버는 nginx를 통해 ssl를 설정하고 있다. 정확하게 기억은 안나지만, 대략 6-8개월 전에 한 번 ssl을 변경시켰었던 적이 있었다. 처음이자 마지막이였는데, 또 다시 업데이트를 하게 되었다. 하지만 기억이 나지 않...🤯 분명 SSL은 업데이트를 시켰는데, 재실행하지 않아서 인증서가 만료되는 똥멍청이같은 짓을 하게 되었다.

기록해두고 담번엔 실수 안해야징 쿄쿄

Nginx SSL 변경 방법

ssl이 위치한 폴더로 이동

나의 경우 mobaxterm에서 WEB 서버를 nginx 계정으로 로그인하여 들어갔다. 나의 경우 /webserver/nginx/ssl 폴더에 ssl이 위치해있다. 여기다 업데이트할 파일을 옮겨준다.

ssl 파일명이 변경되었을 경우,

이번 경우에는 ssl 파일명이 변경되지 않아 nginx.conf 파일을 변경하지 않아도 되었지만, 만약, 파일명이 변경되었을 경우 nginx.conf파일에 들어가서 ssl 이 설정된 곳을 변경시켜줘야 한다.

나의 경우, /webserver/nginx/httpd/conf에 nginx.conf 파일이 존재한다.

vi 혹은 nano를 통해서 nginx.conf파일을 수정한다.

vi nginx.conf

...
server {
 ssl_certificate      /ssl파일이 있는 경로/certification 파일 이름;
 ssl_certificate_key  /ssl파일이 있는 경로/key 파일 이름;
}

...

:wq!

해당 ssl이 해당하는 위치를 확인하고 작성하는 것이 좋다.

⭐️ 제일 중요!! nginx 재시작!! ⭐️

내가 재시작하는 것을 잊어서... 이 사단이 났다.. 하.. 왜.. 나ㅡㄴ...

현 회사의 경우, nginx는 /sbin/nginx 에서 실행 및 정지를 하고 있다.

/sbin으로 들어가기

/webserver/nginx/httpd/sbin

nginx를 정지시키기

./nginx -s stop

nginx가 멈춘지 확인

ps aux | grep nginx

여기서

root      0000  0.0  0.0  0000   000 ?        Ss   11:11   0:00 nginx: master process ./nginx
nginx     0000  0.0  0.0  0000  0000 ?        S    11:11   0:00 nginx: worker process

이게 안보이면 멈춘것.

nginx 재시작

./nginx

nginx가 재시작한지 확인

ps aux | grep nginx

여기서

root      0000  0.0  0.0  0000   000 ?        Ss   11:11   0:00 nginx: master process ./nginx
nginx     0000  0.0  0.0  0000  0000 ?        S    11:11   0:00 nginx: worker process

이게 보이면 재시작한 것.

쿠버네티스에서 Cronjob
- 클러스터 레벨에서 동작하는 스케줄링 리소스
- 주기적으로 pod 생성해 작업 수행

또 다시 마주치고 싶지 않아 k8s...🤦‍♀️

위에서 살짝 언급했듯, 쿠버네티스에서 Cronjob은 클러스터 레벨에서 작동을 한다. 반면, Nest.js의 Cron은 애플리케이션 레벨에서 동작하며, 애플리케이션이 실행중인 동안 계속 동작하게 된다.

어쨌거나 저쨌거나 내가 이번 프로젝트에서 Cron을 사용한 이유는 여러가지가 있겠지만 크게 두 가지 기능을 위해서다.

1. 사용자 비밀번호 만료일 관리: 비밀번호 만료일(expire date)를 확인하고, 만료된 계정을 자동으로 disabled 처리하는 작업 2. 로그 데이터 정리: 2022년부터 쌓여있는 방대한 로그 기록 중 최근 1달치만 보관하고 나머지는 자동 삭제하는 작업

이렇게 반복적이고 정기적으로 실행해야하는 작업들은 Cron을 통해서 자동화할 수 있다. 특히, Nest.js에서는 애플리케이션 코드 내에서 이런 작업들을 직접 스케줄링할 수 있어서 별도의 인프라 설정 없이도 편리하게 사용할 수 있다.

백엔드를 하게된지 0.5개월된 신입 개발자의 머리에는 Cron말고 떠오르는게 없는데, 더 좋은 방법이 있다면 언제든 댓글로 알려주십쇼.. 😮‍💨

Nest.js에서 Cron 사용하기

Nest.js에서 Cron을 사용하기 위해서는 우선 관련 모듈을 설치해야 한다.

npm을 사용하는 경우:

npm install --save @nestjs/schedule
npm install --save-dev @types/cron

yarn을 사용하는 경우:

yarn add @nestjs/schedule
yarn add --dev @types/cron

현 회사에서 기존에 개발되어 운영 중인 서비스를 담당하게 되었다. 처음엔 단순 유지보수만 하면 될 줄 알았지만 시간이 지날수록 기존 코드를 수정하고 새로운 기능을 추가해야 하는 일이 잦아졌다.

이런 과정에서 가장 큰 고민은 코드 수정이나 기능 추가 후 기존 기능들이 정상 작동 하는것이냐였다. 물론 문제 없이 잘 돌아가면 좋겠지만, 현실은 그렇지 않았다. 수정 후 직접 확인했음에도 예상치 못한 곳에서 에러가 튀어나오곤 해서 결국 모든 기능을 일일이 확인해야만 했다.

시간이 충분하다면 전부 꼼꼼히 확인하는 게 최선이겠지만, 현실적으로 매번 그러기는 힘들다.

이런 고민을 하다 문득 취준생 시절 기술 면접에서 자주 들었던 질문이 떠올랐다. "테스트 코드 작성해보셨어요?" 아이러니하게도 취업 후엔 테스트 코드를 작성할 기회가 줄어들어 그 중요성을 잊고 있었다. 이번 경험을 계기로 테스트 코드의 필요성을 다시 한번 느끼고, 제대로 공부해보기로 마음먹었다.

TDD란

TDD(TEST-DRIVEN DEVELOPMENT)는 동작하는 코드를 작성하기 이전에, 테스트를 먼저 작성하고, 그 테스트를 통과하는 코드를 작성한다. 통과한다면 그 코드를 리팩토링한다.

위의 사진처럼 TDD는 3가지 단계를 한 사이클로 돈다.

1. Write a failing test : 실패하는 작은 테스트 작성. 컴파일러조차 되지 않을 수 있지만 일단 작성한다.
2. Make the test pass : 테스트를 통과하도록 최소한의 코딩을 하는 것
3. Refactor : 리팩토링. 중복된 코드를 제거하는 등 코드를 리팩토링한다.

왜 실패하는 작은 테스트를 작성해야하는 것일까?

내 생각에는 테스트 코드를 써보고 실행해서 잘못되었을 경우, 더 개발이 진행되기 전에 개발 초기 단계에서 잘못된 코드/분석 및 설계라는 것을 깨달을 수 있기 때문이라 생각한다.

테스트 코드를 작성하다보면, 코드의 구조에 대해서 깊게 고민할 수 있고, 새로운 방향을 깨달을 수 있다. 더더욱 복잡한 로직일수록 체계적으로 해결해 더 옳은 방향으로 개발 할 수 있도록 깨달을 수 있기 때문이다.

초기 프로젝트에 대해서 분석하고 설계하는 것은 생각보다 굉장히 어려운 일이라고 생각한다. 프로젝트의 미래와 방향 등은 모두 "추측"에 기반되어 시작된다.

이런 추측에 기반해 오랜 기간 설계하고 구현하다보면 해당 설계가 맞으면 좋겠지만, 선택한 설계 방향이 적절하지 않음을 깨달을 수 있다.

이미 상당 시간을 분석과 설계 그리고 어느정도의 개발 단계까지 투자했기 때문에, 다시 원점으로 되돌리게 된다면 데드라인을 맞추지 못할 가능성이 크다.

반드시 TDD를 사용해야할까?

반드시 필요하다 말하기도 어렵다. 이 글을 쓰기 전까지 나는 오히려 'TDD는 비효율적이다.' 라고 생각하는 개발자 중 한 명이었다.

예를들어, 내가 맡았던 프로젝트들의 경우 개발 기한이 생각보다 굉장히 짧을 때가 많았다. 개인적으로 나는 이해 관계자들과 함께 업무를 진행해야하는 환경 속에서 가장 중요한 것은 무엇보다도 "기한 지키기" 였다.

따라서 기능을 하나 추가할때마다, 테스트 코드를 미리 작성해야하기 때문에 오히려 개발 속도를 늦출 수 있기 때문에 단기적인 생산성을 저하시킬 수 있다고 생각한다. 따라서 대부분의 프로젝트는 "분석 -> 설계 -> 구현 -> 테스트 -> 오픈" 방향으로 개발을 했다.

어느것이 옳고 틀린지 아직은 명확하게 알 수 없으나, 개인적인 생각으론 각 프로젝트마다 환경과 요구사항이 다 다르기 때문에, 상황에 맞는 방법론을 선택하여 테스트하는 것이 좋다고 생각한다.

간단한 예제를 통해서 테스트해보자. (with React.js)

Bundling = JavaScript파일들, 이미지 css들을 하나의 모듈로 보고 배포용으로 병합하고 포장하는 작업을 함. 이 작업을 수행하는 툴들을 번들러라고 하는데, 번들러 중에 Webpack이 현재 시점에서 가장 인기가 많음.

PerspectiveCamera

사람이 보는듯한 시야각이 있는 카메라 모드.

PerspectiveCamera(fov: Number, aspect: Number, near: Number, far: Number)

• fov (시야각): 사람이 보는 시야각(field of view) 우리 눈으로 보는 것처럼, 카메라가 얼마나 넓게 볼 수 있는지를 결정한다.

• aspect (화면의 높이 및 너비): 가로 세로 화면 비율.
• near (가까운 거리 제한): 카메라가 볼 수 있는 가장 가까운 거리. 이 거리보다 더 가까이 있는 물체는 화면에 보이지 않는다.
• far (먼 거리 제한): 카메라가 볼 수 있는 가장 먼 거리. 이 거리보다 더 멀리 있는 물체는 화면에 보이지 않는다.

*여기서 물체는 near과 far 사이에 있고 fov 안에 들어와야지만 보인다. *

설정

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

scene.add(camera)

카메라 위치의 중요성

3D 공간에서 카메라는 우리의 눈 역할을 한다. 따라서 이렇게 설정한 카메라는 반드시 위치를 (position)설정해야 한다. 만약 카메라의 위치를 설정하지 않으면, 기본적으로 (0, 0, 0) 위치에 놓이게 되는데, 이 위치는 3D 공간의 중심점으로, 대부분의 물체들이 배치되는 곳이라 자칫하면 물체와 겹쳐지기 때문이다. 이렇게 되면 물체를 제대로 볼 수 없고, 화면에 아무것도 보이지 않을 수 있다. 따라서 카메라는 물체보다 조금 더 앞에 떨어진 곳에 위치해야 한다.

일반적인 카메라 위치

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

camera.position.z = 6; 혹은
camera.position.set(0, 1, 5)
scene.add(camera)

일반적으로 카메라는 물체보다 약간 뒤쪽에 위치한다. 이는 z 값을 양수로 설정하여 구현할 수 있다. 또한 조금 위쪽에서 내려다보는 각도로 설정하는 것이 일반적이다. 이는 y 값을 약간 높게 설정하여 구현할 수 있다. 예를 들어, camera.position.set(0, 1, 5)와 같이 설정하면 물체보다 약간 위, 그리고 뒤쪽에 카메라가 위치하게 되는 것이다.

OrthographicCamera

물체의 크기, 카메라의 거리와는 상관 없이 일정하게 보이는 것.

OrthographicCamera(left: Number, right: Number, top: Number, bottom: Number, near: Number, far: Number)