기존 서비스는 Windows 서버에서 JAR 파일을 직접 실행하는 방식으로 운영되고 있었다. 서버가 자주 불안정했고, Windows 환경 특성상 운영 자체가 불편한 점이 많았다. 결국 리뉴얼을 결정하면서 Linux + Docker 환경으로 전환하기로 했다.

전환을 준비하던 중 감사 일정이 잡혔다. 감사에서 가장 중요한 요구사항은 개인정보가 저장된 DB에 대한 접근 제한이었다.

요구사항을 정리하면:

• DB는 외부에서 직접 접속 불가
• API 서버만 외부에 노출
• 나머지 서비스와 DB는 내부에서만 접근 가능
• DB 접근은 반드시 서버 SSH 접속 후 컨테이너를 통해서만 가능

서브넷(Subnet)이란?

서브넷은 하나의 네트워크를 더 작은 단위로 나눈 것이다. 쉽게 말하면 같은 건물 안에서도 층별로 독립된 내선 전화망을 구성하는 것과 비슷하다. 같은 층(서브넷) 안에서는 자유롭게 통신할 수 있지만, 다른 층(서브넷)과는 별도의 경로를 통해야 한다.

예를 들어 172.10.0.0/24 라는 서브넷은:

• 172.10.0.0 — 네트워크 주소
• /24 — 앞 24비트가 네트워크 대역, 나머지 8비트가 호스트 대역
• 즉 172.10.0.1 ~ 172.10.0.254 범위의 IP를 사용할 수 있음

Docker 네트워크란?

Docker는 컨테이너 간 통신을 위한 가상 네트워크를 직접 구성할 수 있다. 기본적으로 컨테이너를 실행하면 bridge 라는 기본 네트워크에 연결되는데, 이 경우 모든 컨테이너가 같은 네트워크에 있어 서로 통신이 가능하다.

커스텀 네트워크를 만들면:

• 같은 네트워크 안의 컨테이너끼리만 통신 가능
• 컨테이너에 고정 IP 부여 가능
• 네트워크 단위로 격리 가능

서브넷을 Docker에 적용할 수 있는 이유

전통적인 서버 환경에서 서브넷은 물리적인 네트워크 장비로 구성한다. 하지만 Docker는 소프트웨어적으로 가상 네트워크를 만들 수 있어서, 서브넷 개념을 컨테이너 레벨에서 그대로 구현할 수 있다.

즉 Docker 네트워크에 서브넷을 지정하면:

• 같은 서브넷 안의 컨테이너끼리만 통신 가능
• 다른 서브넷의 컨테이너는 접근 불가
• 물리적인 네트워크 장비 없이 소프트웨어로 격리 가능

이 특성을 활용해서 외부에 노출할 서비스(API) 와 내부에서만 동작할 서비스(Batch, DB 등) 를 분리했다.

적용

네트워크 생성

docker network create \
  --driver bridge \
  --subnet 172.10.0.0/24 \
  --gateway 172.10.0.1 \
  app-network

• --driver bridge — 단일 호스트 내 컨테이너 간 통신
• --subnet — 네트워크 대역 지정
• --gateway — 게이트웨이 IP 지정

컨테이너 IP 고정

각 컨테이너에 고정 IP를 부여했다. IP가 고정되어 있으면 컨테이너가 재시작되어도 IP가 유지되기 때문에 서비스 간 통신 설정이 흔들리지 않는다.

docker run \
  --name app-api \
  --network app-network \
  --ip 172.10.0.11 \
  ...

nginx를 통한 외부 노출

기존 nginx 컨테이너가 있다면 app-network에 추가로 연결할 수 있다. nginx는 여러 네트워크에 동시에 연결될 수 있기 때문에 외부 네트워크와 app-network 사이의 리버스 프록시 역할을 할 수 있다.

docker network connect app-network nginx

외부 요청 흐름
외부 → nginx → app-api (172.10.0.11)

내부에서만 접근 가능
app-a     (172.10.0.12)
app-b     (172.10.0.13)
app-mysql (172.10.0.10)

DB 접근 제한

DB는 app-network 내부에서만 접근 가능하기 때문에 외부에서 직접 접속할 수 없다. 반드시 서버에 SSH로 접속한 후 컨테이너를 통해 접근해야 한다.

# 서버 SSH 접속
ssh user@server-ip

# 컨테이너 진입 후 DB 접속
docker exec -it app-mysql bash
mysql -u root -p

마무리

처음에는 네트워크를 별도로 구성해야 한다는 게 번거롭게 느껴졌다. 그냥 포트를 열고 닫는 것만으로도 충분하지 않을까 싶었는데, 직접 구성해보니 생각보다 훨씬 명확하게 서비스를 격리할 수 있었다.

서브넷이라는 개념이 물리적인 네트워크 장비에서만 가능한 줄 알았는데, Docker에서 소프트웨어적으로 동일하게 구현할 수 있다는 게 인상적이었다.

다만 이 방식은 단일 호스트에서의 격리에 한정된다는 점을 염두에 두어야 한다. 서비스가 커지거나 멀티 호스트 환경이 필요해진다면 Docker 네트워크만으로는 한계가 있다. Kubernetes는 이런 네트워크 격리와 서비스 디스커버리를 훨씬 정교하게 다룰 수 있고, 실제로 이 부분이 Docker와 Kubernetes의 가장 큰 차이 중 하나라고 생각한다.

Docker 네트워크를 직접 구성해보면서 네트워크 격리의 개념을 이해할 수 있었고, 이게 Kubernetes에서는 어떻게 추상화되어 동작하는지 더 공부해보고 싶어졌다.

각 도구의 역할을 간단히 정리하면:

이 4개가 함께 동작하면 장애 발생 시 언제, 어디서, 왜 를 빠르게 파악할 수 있다.

왜 ELK가 아닌가?

로그 수집 하면 보통 ELK (Elasticsearch + Logstash + Kibana) 스택을 먼저 떠올린다. 실제로 많은 회사에서 사용하는 검증된 스택이기도 하다.

하지만 우리 인프라는 Traditional 3-Tier Architecture (Web - WAS - DB) 였다. Kubernetes 환경이 아니다 보니 ELK가 제공하는 강점들이 크게 필요하지 않았다.

Grafana와 자연스럽게 연동되는 Loki, 메트릭 수집의 Prometheus, 트레이스의 Tempo까지 하나의 Grafana 대시보드에서 모두 확인할 수 있다는 점이 매력적이었다. ELK는 강력하지만 Traditional 3-Tier 소규모 서비스에서 Elasticsearch의 리소스 부담은 오버스펙에 가까웠다.

테스트 서버 구축

먼저 테스트 서버에 4개 스택을 전부 올려봤다. docker-compose로 구성했고, Spring Boot 애플리케이션에 actuator와 OpenTelemetry agent를 붙여서 메트릭, 로그, 트레이스를 각각 수집했다.

services:
  prometheus:
    image: prom/prometheus:v3.5.1
    ports:
      - 9090:9090
  grafana:
    image: grafana/grafana:12.4.2
    ports:
      - 3000:3000
  loki:
    image: grafana/loki:3.4.2
    ports:
      - 3100:3100
  tempo:
    image: grafana/tempo:2.7.2
    ports:
      - 3200:3200
      - 4317:4317

Grafana 대시보드에서 메트릭을 보고, 이상한 구간을 발견하면 Loki로 로그를 확인하고, Tempo로 트레이스를 추적하는 흐름이 생각보다 훨씬 강력했다. 테스트 서버에서는 모두 정상 동작했다.

Spring Boot 연동

모니터링 스택을 구성했다고 끝이 아니다. 애플리케이션에서 메트릭을 노출해야 Prometheus가 수집할 수 있다.

의존성 추가

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'io.micrometer:micrometer-registry-prometheus'

pom.xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

application.yml 설정

management:
  endpoints:
    web:
      exposure:
        include: prometheus, health, info
  endpoint:
    prometheus:
      enabled: true
  metrics:
    tags:
      application: ${spring.application.name}

prometheus.yml scrape 설정

Prometheus가 어떤 엔드포인트에서 메트릭을 가져올지 설정한다.

scrape_configs:
  - job_name: my-app
    metrics_path: /actuator/prometheus
    static_configs:
      - targets:
        - 192.168.0.1:8080
        labels:
          application: my-app

Production 서버 적용 — 내부망이라는 벽

문제는 Production 서버였다. Production 서버는 내부망 환경이었고, 외부와의 통신이 제한되어 있었다. VPN으로 접속하는 방식이었는데, Windows 서버 VPN 특성상 접속할 때마다 IP가 달라지는 문제가 있었다.

여기서 Prometheus와 Loki/Tempo의 근본적인 차이가 드러났다.

Pull vs Push

Prometheus는 Pull 방식이라 모니터링 서버에서 애플리케이션 엔드포인트로 주기적으로 요청을 보내서 메트릭을 가져온다. 즉 모니터링 서버가 애플리케이션 서버에 접근할 수 있으면 되기 때문에 내부망에서도 문제없이 동작했다.

반면 Loki와 Tempo는 Push 방식이라 애플리케이션이 직접 Loki/Tempo 서버로 데이터를 전송해야 한다. 내부망에서는 애플리케이션이 외부로 나갈 수가 없었고, 거기다 VPN IP가 매번 바뀌니 고정 엔드포인트 설정 자체가 불가능했다.

결국 Production 서버에는 Prometheus + Grafana + AlertManager 만 적용하기로 결정했다.

Production 서버 구성 — Prometheus + Grafana + AlertManager

docker-compose 구성

services:
  prometheus:
    image: prom/prometheus:v3.5.1
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --web.enable-lifecycle
      - --storage.tsdb.retention.time=30d
      - --storage.tsdb.retention.size=10GB
      - --web.enable-remote-write-receiver
    restart: unless-stopped

  alertmanager:
    image: prom/alertmanager:v0.31.1
    command:
      - --config.file=/etc/alertmanager/alertmanager.yml
    restart: unless-stopped
    depends_on:
      - prometheus-msteams

  grafana:
    image: grafana/grafana:12.4.2
    restart: unless-stopped
    depends_on:
      - prometheus

  prometheus-msteams:
    image: quay.io/prometheusmsteams/prometheus-msteams:latest
    environment:
      - TEAMS_INCOMING_WEBHOOK_URL=https://your-teams-webhook-url
      - TEAMS_REQUEST_URI=alertmanager
    command:
      - -workflow-webhook
    restart: unless-stopped

AlertManager Teams 연동

Teams webhook을 직접 AlertManager에 붙이는 건 지원이 안 돼서 prometheus-msteams 라는 중간 브릿지를 사용했다.

흐름

Prometheus → AlertManager → prometheus-msteams → Teams

처음에는 기존 Incoming Webhook 방식으로 연동하려 했는데, 2025년 이후 Teams Incoming Webhook 지원이 종료되면서 Power Automate Workflow Webhook 방식으로 변경해야 했다. Webhook URL을 Power Automate에서 생성하고 환경변수로 주입하면 된다.

alertmanager.yml

global:
  resolve_timeout: 5m
route:
  receiver: 'teams-notification'
  group_by: ['alertname', 'application']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
receivers:
- name: 'teams-notification'
  webhook_configs:
  - url: 'http://prometheus-msteams:2000/alertmanager'
    send_resolved: true

알림 규칙 설정

서비스 다운, CPU 과부하, JVM Heap 과부하 3가지 알림을 설정했다.

alert_rules.yml

groups:
  - name: 기본알람
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          description: "[{{ $labels.application }}] 서비스 다운"

      - alert: HighCpuUsage
        expr: process_cpu_usage * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          description: "[{{ $labels.application }}] CPU {{ $value | printf \"%.1f\" }}% 초과"

      - alert: HighHeapUsage
        expr: |
          (
            sum by(instance, application) (jvm_memory_used_bytes{area="heap"})
            /
            sum by(instance, application) (jvm_memory_max_bytes{area="heap"})
          ) * 100 > 85
        for: 5m
        labels:
          severity: critical
        annotations:
          description: "[{{ $labels.application }}] Heap {{ $value | printf \"%.1f\" }}% 초과"

Test vs Production 비교

로그와 트레이스를 포기한 건 아쉬웠지만, Prometheus만으로도 CPU, 메모리, JVM Heap, 응답시간, 서비스 상태 등 핵심 메트릭은 충분히 수집할 수 있었다.

마무리

모니터링을 붙이고 나서 가장 크게 달라진 건 장애 대응 속도였다. 이전에는 VOC가 들어온 후에야 인지했다면, 이제는 알림으로 먼저 인지하고 Grafana 대시보드에서 어느 시점에 무슨 일이 있었는지 바로 확인할 수 있게 됐다.

완벽한 구성은 아니었지만, 제약된 환경에서도 할 수 있는 최선을 찾아서 적용한 경험이 됐다. 나중에 내부망 환경에서 Loki를 붙일 수 있는 방법을 더 찾아볼 생각이다.

tail -f /logs/tomcat/catalina.out

그러다 Logback 설정을 열어봤는데 파일이 여러 개였다.

app.log
error.log
business.log

"어? 그럼 catalina.out이랑 app.log가 같은 내용 아니야?"

이 의문에서 시작했다.

Tomcat 로그 종류부터 정리해야 한다

로그 파일이 여러 개 생기는데, 각자 역할이 다르다.

AccessLogValve는 HTTP 요청 기록이다.

server.xml에서 설정한다.

찍히는 로그는 이렇다.

192.168.1.10 - - [15/Jan/2024:10:23:45 +0900] "GET /api/orders HTTP/1.1" 200 1234

누가 뭘 요청했고 응답코드가 뭔지만 찍힌다. 앱 내부에서 뭔 일이 있었는지는 모른다.

catalina.out은 Tomcat 표준출력이다.

setenv.sh에서 경로를 지정한다.

CATALINA_OUT="/data/tomcat/logs/catalina.out"

JVM이 콘솔에 찍는 것들이 전부 여기 쌓인다.

Logback은 앱 내부 로직 기록이다.

개발자가 log.info(), log.error()로 직접 찍은 것들이다.

그래서 두 군데 찍히는 게 맞나

맞다.

원인은 ConsoleAppender 때문이다.

    /data/tomcat/logs/app.log

흐름이 이렇다.

log.info("주문 생성: orderId=1234")
         │
         ├──► STDOUT(ConsoleAppender) → catalina.out  ← 여기도 찍힘
         ├──► DEFAULT(FileAppender)  → app.log        ← 여기도 찍힘
         └──► ERROR(LevelFilter)     → error.log      ← ERROR만

ConsoleAppender가 콘솔로 출력하면 Tomcat이 그걸 catalina.out으로 받아버린다.

catalina.out이랑 app.log는 같은 내용이 중복으로 쌓이고 있는 거다.

그럼 왜 굳이 파일을 따로 빼나

catalina.out은 Tomcat이 관리하는 파일이라 Logback이 직접 rotate를 못 한다.

DEFAULT appender로 따로 빼면 Logback이 직접 관리할 수 있다.

    /data/tomcat/logs/backup/app.%d{yyyy-MM-dd}.%i.gz
    100MB
    90
    2GB

100MB 넘으면 자동으로 압축해서 backup 폴더로 보내고, 90일치 보관하고, 전체 2GB 넘으면 오래된 것부터 지운다.

catalina.out은 이런 관리가 안 된다. 그래서 별도로 logrotate를 써야 한다.

catalina.out은 logrotate로 관리한다

Ubuntu 기준으로 logrotate는 cron이 아니라 systemd timer로 돌아간다.

# /lib/systemd/system/logrotate.timer
OnCalendar=daily

흐름은 이렇다.

systemd timer (매일)
    │
    └──► /etc/logrotate.conf
              │
              └──► include /etc/logrotate.d/
                        │
                        └──► tomcat
                                  │
                                  └──► catalina.out rotate 실행

/etc/logrotate.d/ 폴더에 파일만 넣으면 자동으로 포함된다.

설정은 이렇다.

/data/tomcat/logs/catalina.out {
    copytruncate   # Tomcat 재시작 없이 rotate
    daily          # 매일
    rotate 60      # 60일치 보관
    compress       # gzip 압축
    delaycompress  # 가장 최근 파일은 압축 안함
    missingok      # 파일 없어도 에러 안남
    dateext        # 파일명에 날짜 붙임
}

여기서 핵심은 copytruncate다.

일반 rotate는 파일을 옮기고 새 파일을 만드는데, Tomcat은 파일 경로를 고정으로 잡고 있어서 파일이 바뀌면 못 찾는다.

copytruncate는 파일을 복사한 다음 원본을 비워버리는 방식이라 Tomcat 재시작 없이 rotate가 가능하다.

마무리

로그 구조를 정리하면 이렇다.

HTTP 요청
    │
    ├──► AccessLogValve → localhost_access_log.txt
    │
    └──► Spring App
              │
              ├──► ConsoleAppender → catalina.out  (logrotate)
              ├──► DEFAULT         → app.log       (Logback 관리)
              └──► ERROR           → error.log     (ERROR만)

결국 catalina.out이랑 app.log는 중복이 맞다.

근데 각자 관리 주체가 다르다.

catalina.out은 Tomcat이 들고 있어서 logrotate로 밖에 못 건드리고, app.log는 Logback이 직접 들고 있어서 세밀하게 관리할 수 있다.

같은 내용이 두 군데 찍히는 게 버그가 아니라 관리 주체가 다른 두 채널이 동시에 받고 있는 구조였던 거다.

“DB도 정상이고 CPU도 널널한데, 왜 API만 느리지?”

이럴 때 의외로 많이 걸리는 게 커넥션 풀이다. 나도 처음엔 maxPoolSize만 늘리면 해결되는 줄 알았는데, 구조를 이해하고 나니까 문제 보는 시선이 완전히 달라졌다.

이 글은 설정값 얘기 말고, HikariCP가 실제로 어떻게 동작하는지를 흐름 기준으로 정리한다.

커넥션 풀은 단순 재사용이 아니다

커넥션 풀을 흔히 “미리 만들어두고 재사용”이라고 생각하기 쉬운데, 실제 역할은 그보다 더 중요하다.

커넥션 풀은 결국 동시에 DB에 붙을 수 있는 수를 제한하는 장치다.

요청이 100개 들어와도 커넥션이 10개면, 동시에 처리 가능한 건 10개뿐이다. 나머지는 무조건 기다린다.

그래서 커넥션 풀은 성능을 올리는 도구라기보다 시스템이 감당 가능한 처리량을 강제로 맞추는 장치에 가깝다.

HikariCP 구조를 보면 왜 빠른지 이해된다

HikariCP 내부 구조는 단순한 큐 기반이 아니다.

Application Thread
    ↓
HikariPool
    ↓
ConcurrentBag
    ↓
Connection

여기서 핵심은 ConcurrentBag이다.

일반적인 풀처럼 큐에 넣고 빼는 방식이 아니라, 각 커넥션이 상태를 가지고 있고 스레드가 그 상태를 바꾸면서 가져가는 구조다.

이 방식의 목적은 하나다.

락을 최대한 피하고, 동시에 여러 스레드가 접근해도 병목이 생기지 않게 만드는 것.

왜 굳이 이런 구조를 썼을까

일반적으로는 BlockingQueue를 써서 풀을 만든다. 구현도 쉽고 직관적이다.

근데 트래픽이 늘어나면 문제가 생긴다.

스레드가 많아질수록 lock 경쟁이 심해지고, 대기와 컨텍스트 스위칭이 늘어나면서 전체 성능이 떨어진다.

HikariCP는 이 문제를 피하려고 아래 3가지를 중심으로 설계했다.

• 가능한 한 lock을 쓰지 않는다
• 상태 변경은 CAS 방식으로 처리한다
• 같은 스레드는 같은 커넥션을 다시 쓰도록 유도한다

이 세 가지가 합쳐지면서, 요청이 많아져도 성능이 크게 떨어지지 않는다.

커넥션을 가져오는 실제 흐름

HikariCP에서 커넥션을 얻는 과정은 생각보다 단순하다.

1. ThreadLocal에서 먼저 확인
2. 있으면 그대로 사용
3. 없으면 ConcurrentBag에서 탐색
4. 사용 가능한 커넥션이 있으면 가져옴
5. 없으면 새로 생성 (가능한 경우)
6. 최대치면 대기

여기서 중요한 포인트는 ThreadLocal이다.

같은 스레드는 이전에 사용했던 커넥션을 우선적으로 다시 사용하려고 한다. 이 경우 풀 전체를 탐색하지 않기 때문에 거의 비용이 발생하지 않는다.

결과적으로 반복 요청이 많은 환경에서는 커넥션을 가져오는 비용 자체가 거의 사라진다.

성능을 결정하는 건 커넥션 수가 아니다

많이 하는 실수가 하나 있다.

“느리니까 maxPoolSize를 늘리자”

근데 대부분 이걸로 해결 안 된다.

진짜 중요한 건 커넥션 개수가 아니라 커넥션을 얼마나 오래 잡고 있느냐다.

예를 들어 커넥션이 10개 있고, 각 요청이 1초씩 잡고 있으면 초당 최대 10개밖에 처리 못 한다.

여기서 트랜잭션 안에 외부 API 호출이 들어가면 상황이 더 나빠진다.

DB 작업이 끝났는데도 커넥션을 계속 잡고 있기 때문이다.

이러면 풀을 아무리 늘려도 계속 밀린다.

커넥션 풀이 터지는 순간

모든 커넥션이 사용 중이면 이후 요청은 전부 대기한다.

모든 커넥션 사용 중
→ 요청 대기
→ 응답 지연
→ timeout

이 상태가 되면 특징이 있다.

CPU는 정상이고, DB도 정상인데 API만 느리다.

이럴 때 커넥션 풀을 의심해야 한다.

maxPoolSize는 많다고 좋은 게 아니다

maxPoolSize를 늘리면 무조건 좋아질 것 같지만, 실제로는 그렇지 않다.

DB도 동시에 처리할 수 있는 한계가 있고, 커넥션이 많아질수록 스레드 간 경쟁과 컨텍스트 스위칭이 늘어난다.

결국 일정 수준을 넘으면 오히려 성능이 떨어진다.

중요한 건 단순히 늘리는 게 아니라 DB가 감당 가능한 수준에 맞추는 것이다.

마무리

처음에는 커넥션 풀을 그냥 설정값으로만 봤는데, 구조를 이해하고 나니까 문제를 보는 기준이 완전히 달라졌다.

이제는 API가 느려지면 먼저 본다.

“지금 커넥션을 누가 오래 잡고 있지?”

이 질문이 나오기 시작하면, 단순 튜닝이 아니라 구조를 이해한 상태다.

하지만 실제로 세션이 어떻게 동작하는지,
특히 멀티 WAS 환경에서 어떤 문제가 발생하는지 이해하고 있는 경우는 많지 않다.

이 글에서는 JSESSIONID를 중심으로
세션의 내부 동작과 구조를 조금 더 깊게 정리한다.

세션의 본질

세션은 단순히 말하면 다음과 같다.

• 서버에 저장된 사용자 상태
• 요청 간 상태를 유지하기 위한 장치

HTTP는 stateless(무상태)이기 때문에
요청마다 사용자를 식별할 방법이 필요하다.

이때 사용하는 것이 세션이다.

JSESSIONID의 역할

세션은 서버에 저장되지만,
클라이언트는 자신의 세션을 어떻게 식별할까?

그 역할을 하는 것이 JSESSIONID다.

전체 흐름

1. 클라이언트 최초 요청
2. 서버에서 세션 생성
3. 세션 ID 생성 (예: ABC123)
4. 응답에 쿠키로 전달

Set-Cookie: JSESSIONID=ABC123

5. 이후 요청마다 자동 포함

Cookie: JSESSIONID=ABC123

6. 서버는 해당 ID로 세션 조회

세션 저장 위치

세션은 일반적으로 다음 위치에 저장된다.

1. WAS 메모리 (기본)

• Tomcat, Tomee 등
• 가장 빠름
• 서버마다 따로 존재

2. 외부 저장소

• Redis
• DB

멀티 서버 환경에서 사용

중요한 오해

많이 하는 착각이 있다.

JSESSIONID에 사용자 정보가 들어있다?

아니다.

• JSESSIONID = 단순한 키
• 실제 데이터 = 서버 내부

즉, 클라이언트는 아무 정보도 가지고 있지 않다.

단일 WAS 환경

[Client] → [WAS1]

• 세션 생성
• JSESSIONID로 계속 접근

문제 없음

멀티 WAS 환경 문제

[Client] → [LB] → [WAS1 / WAS2]

시나리오

1. 로그인 → WAS1 → 세션 생성
2. 다음 요청 → WAS2

결과:

• 세션 없음
• 로그인 풀림

해결 방법

1. Sticky Session

• LB가 특정 WAS로 고정

장점:

• 간단

단점:

• 확장성 낮음
• 장애 시 문제

2. Session Replication

• WAS끼리 세션 공유

단점:

• 네트워크 비용 큼
• 성능 저하

3. Redis 기반 세션

• 외부 저장소 사용

구조:

Client → LB → WAS → Redis

장점:

• 확장성 좋음
• 안정적

JSESSIONID + JVM Route

클러스터 환경에서는 이런 형태도 사용한다.

JSESSIONID=ABC123.node1

여기서

• ABC123 → 세션 ID
• node1 → 서버 식별자

LB가 이 값을 보고 특정 서버로 라우팅

실무에서 자주 터지는 문제

1. 로그인 유지 안됨

• 멀티 WAS
• 세션 공유 없음

2. 특정 API에서만 세션 유실

• 다른 서버로 라우팅됨

3. 외부 콜백 이후 세션 사라짐

• 도메인 변경
• 쿠키 미전달

쿠키와 보안

JSESSIONID는 쿠키이기 때문에
보안 설정이 중요하다.

• HttpOnly
• Secure
• SameSite

설정에 따라

• XSS 방지
• CSRF 대응

가능

왜 이런 구조일까?

HTTP는 stateless이기 때문에

• 서버가 상태를 기억하려면
• 클라이언트가 식별자를 보내야 한다

그래서

• 서버 → 세션 저장
• 클라이언트 → ID만 보관

이 구조가 만들어졌다.

한 단계 더

세션 방식 외에도 다른 방식이 있다.

• JWT (Stateless)
• Token 기반 인증

세션은 상태 기반(stateful),
JWT는 무상태(stateless) 방식이다.

정리

• 세션은 서버에 저장된다
• JSESSIONID는 그 세션을 찾는 키다
• 단일 서버에서는 단순하다
• 멀티 서버에서는 전략이 필요하다

한줄 요약

세션은 서버에 있고,
JSESSIONID는 그 세션을 찾기 위한 식별자다.

ERROR: duplicate key value violates unique constraint
Key (id)=(4) already exists

auto increment인데 왜 중복이 발생할까?

처음에는 DB가 자동으로 값을 잘 관리해줄 거라고 생각하기 쉽다.
하지만 실제로는 그렇지 않다.

결론부터 말하면
시퀀스는 테이블 상태를 전혀 모른다.

auto increment의 정체

PostgreSQL에서 auto increment는 내부적으로 다음과 같이 동작한다.

nextval('sequence_name')

이 함수는 단순히 숫자를 하나씩 증가시키며 반환한다.

중요한 점은 다음이다.

• 테이블을 조회하지 않는다
• 현재 PK 상태를 확인하지 않는다
• 단순히 숫자만 증가시킨다

즉, auto increment는 “똑똑한 증가 기능”이 아니라
독립적인 숫자 생성기에 가깝다.

duplicate key가 발생하는 구조

다음과 같은 상황을 가정해보자.

현재 상태

테이블 데이터: id = 1, 2, 3, 4, 5

시퀀스 상태: nextval = 4

이 상태에서 insert를 수행하면

INSERT INTO table (...) VALUES (...);

실제로는 내부적으로 다음과 같이 처리된다.

id = nextval(...)
→ 4

이미 테이블에 존재하는 값이기 때문에
duplicate key 에러가 발생한다.

시퀀스가 꼬이는 이유

이런 상황은 의외로 자주 발생한다.

1. 수동으로 PK를 넣은 경우

INSERT INTO table(id, ...) VALUES (100, ...);

테이블에는 100이 들어가지만
시퀀스는 이 사실을 모른다.

이후 시퀀스는 기존 값 기준으로 계속 증가하게 되고
결국 충돌이 발생한다.

2. dump / restore

데이터를 백업했다가 복구할 때

• 데이터는 정상적으로 들어오지만
• 시퀀스 값은 초기 상태로 남아있는 경우가 많다

실무에서 가장 흔한 원인이다.

3. 서버 간 데이터 이관

운영 환경의 데이터를 개발 환경으로 복사할 때

• 테이블 데이터만 복사
• 시퀀스 값은 그대로

이 경우에도 쉽게 문제가 발생한다.

4. truncate에 대한 오해

TRUNCATE TABLE table;

이 명령은 데이터를 삭제할 뿐
시퀀스 값은 초기화하지 않는다.

그래서 이후 insert 시 예상과 다른 값이 들어갈 수 있다.

5. 트랜잭션 롤백

SELECT nextval('seq'); -- 10
ROLLBACK;

이 경우 많은 사람들이
값이 롤백될 것이라고 생각한다.

하지만 시퀀스는 트랜잭션과 무관하다.

• 10은 이미 사용된 값
• 다시 되돌아가지 않는다

그래서 중간 숫자가 비는 것은 정상적인 동작이다.

왜 이렇게 설계되어 있을까

시퀀스가 테이블과 독립적으로 동작하는 이유는 성능 때문이다.

만약 시퀀스가 테이블 상태를 매번 확인한다면

• 락이 발생하고
• 동시성이 크게 떨어진다

그래서 DB는 단순한 구조를 선택했다.

• 숫자를 빠르게 발급
• 충돌 여부는 제약조건으로 처리

해결 방법

문제가 발생했다면 시퀀스를 테이블에 맞춰주면 된다.

SELECT setval(
  'sequence_name',
  (SELECT MAX(id) FROM table)
);

이렇게 하면 시퀀스가 현재 데이터 기준으로 재정렬된다.

실무에서의 대응 방법

1. 데이터 이관 후 시퀀스 정렬

데이터를 복사하거나 복구했다면
반드시 시퀀스를 맞춰야 한다.

2. PK 수동 입력 지양

특별한 이유가 없다면
auto increment에 맡기는 것이 안전하다.

3. duplicate key 발생 시 우선 확인

코드 문제로 보기 전에
시퀀스 상태를 먼저 확인하는 것이 빠르다.

정리

auto increment는 테이블을 기준으로 동작하는 기능이 아니다.

• 테이블 상태를 모른다
• 트랜잭션과 무관하다
• 단순히 숫자만 증가시킨다

이 구조를 이해하지 못하면
예상하지 못한 duplicate key 문제를 만나게 된다.

처음에는 MyBatis 문제인가 싶었고, DB 설정 문제인가 싶었고, 격하게 삽질을 했다.

결론은 단순했다.

트랜잭션이 안 먹은 게 아니라, 프록시를 타지 않았다.

문제 상황

다음과 같은 코드였다. (예시 코드)

@Component
@RequiredArgsConstructor
public class OrderApplication {

    private final OrderService orderService;
    private final OrderResultPublisher publisher;

    public void orderGenerateWithPublish(OrderVo orderVo) {
        OrderMessage message = generateOrder(orderVo);
        publisher.send(message);
    }

    @Transactional
    public OrderMessage generateOrder(OrderVo orderVo) {

        if (orderService.existsByOrderNumber(orderVo.getOrderNumber())) {
            orderService.deleteByOrderNumber(orderVo.getOrderNumber());
        }

        Order order = orderService.save(orderVo.toEntity());

        // 강제 예외
        if (true) {
            throw new RuntimeException("예외 발생");
        }

        return OrderMessage.from(order);
    }
}

의도는 단순했다.

• 주문 저장
• 예외 발생 시 롤백
• 트랜잭션 보장

하지만 실제로는 삭제도 되고 insert도 되고 예외도 터지는데 롤백이 되지 않았다.

원인

문제는 이 한 줄이었다.

OrderMessage message = generateOrder(orderVo);

같은 클래스 내부에서 this 로 메서드를 호출했다. 이게 왜 문제일까?

Spring 트랜잭션은 프록시 기반이다.

Spring의 @Transactional은 AOP 기반으로 동작한다.

우리가 주입받는 Bean은 실제 객체가 아니라 트랜잭션 처리를 감싸고 있는 프록시 객체다.

구조를 단순화하면 다음과 같다.

[Proxy 객체] → [실제 Bean]

메서드를 호출하면 프록시가 먼저 실행되고 여기서 트랜잭션을 시작한다.

하지만 같은 클래스 내부에서 다른 메서드를 호출하면,

generateOrder();

• 프록시를 거치지 않는다
• 그냥 자기 자신 메서드를 호출한다
• 트랜잭션 AOP가 실행되지 않는다

즉, 트랜잭션이 안 먹은 게 아니라, 애초에 트랜잭션 로직이 실행되지 않은 것이다.

트랜잭션이 동작하지 않는 구조

public void outer() {
    this.inner(); // 프록시 안 거침
}

@Transactional
public void inner() {
}

이 구조에서는 @Transactional이 적용되지 않는다.

정상 동작 구조

다른 Bean을 통해 호출해야 한다.

@Service
public class OrderTxService {

    @Transactional
    public void generate() {
        // 트랜잭션 보장
    }
}

@Component
@RequiredArgsConstructor
public class OrderApplication {

    private final OrderTxService orderTxService;

    public void outer() {
        orderTxService.generate(); // 프록시 경유
    }
}

이렇게 하면 프록시를 거치기 때문에 트랜잭션이 정상 동작한다.

추가로 많이 헷갈리는 포인트

1. private과 @Transactional

@Transactional
private void save() {}

동작하지 않는다. 프록시가 가로챌 수 없기 때문이다.

2. 예외를 try-catch로 삼켜버린 경우

@Transactional
public void save() {
    try {
        throw new RuntimeException();
    } catch (Exception e) {
        // 아무것도 안 함
    }
}

예외가 밖으로 던져지지 않으면 롤백되지 않는다.

3. Checked Exception

@Transactional(rollbackFor = Exception.class)

Checked Exception은 기본적으로 롤백되지 않는다. 명시적으로 설정해야 한다.

정리 및 마무리

Spring에서 @Transactional이 안 먹는 대표적인 이유는 다음과 같다.

1. 같은 클래스 내부 호출 (Self Invocation)
2. private 메서드
3. 예외를 삼켜버림
4. Checked Exception

그중 가장 많이 터지는 원인은 Self Invocation이다.

@Transactional이 안 먹는 게 아니라 프록시를 타지 못하고 있었던 것이다. 트랜잭션 문제는 코드 한 줄의 문제가 아니라 호출 구조의 문제인 경우가 많다. 실무에서 한 번쯤은 반드시 겪게 되는 이슈다.

같은 삽질을 반복하지 않기를.

대규모 리뉴얼 프로젝트를 겪으면서 DTO 설계 기준을 다시 세우게 된 이유를 정리한 기록이다.

1. resultMap 중심 설계의 한계

기존 구조에서는 resultMap이 거의 모든 걸 책임지고 있었다. (진짜 보기 힘든 개쓰레기 코드들의 향연...)

문제1. 컬럼명 ↔ 필드명 매핑이 각기 다름 문제2. 타입이 뭔지 알아 볼 수가 없음 문제3. 중첩 객체 구성 (맵안에서 맵을 쓰는 기괴한...)

처음엔 유연해 보였지만, 시간이 지나면서 문제가 드러났다. 특히 아래 3가지 문제가 심각했다.

심각한 문제1. resultMap 하나 수정하면 여러 쿼리에 영향 심각한 문제2. DTO 구조를 한눈에 파악하기 어려움 심각한 문제3. 실제로 어떤 데이터가 내려오는지 추적이 힘듦

특히 3번 때문에 봤던 코드를 몇번이나 다시 봤는지 모른다. 이렇게 지독한 코드 다시보기를 체험하니 마음이 단호해졌다.

매핑 로직이 많아질수록 DTO는 ‘보이지 않는 객체’가 된다. 그래서 resultMap 의존도를 줄이고, DTO를 중심으로 쿼리와 매핑을 맞추는 방향으로 기준을 바꾸기로 다짐했다. (제발)

2. DTO는 “조회용”과 “행위용”을 섞으면 안 된다.

리뉴얼 초기에 가장 많이 봤던 패턴이 이거였다.

조회 결과를 담는 DTO 저장/수정 요청을 받는 DTO 계산 결과까지 담기 시작한 DTO

이게 한 클래스에 섞이기 시작하면 DTO는 금방 비대해진다. 왜냐하면 a테이블, b테이블에거 갖고온 모든 데이터들이 짬뽕처럼 섞인 김치짬뽕우웩탕이 탄생되기 때문...

사실 제일 큰 문제는 크기보다 역할이 모호해진다는 점이었다. 그래서 기준을 단순하게 잡았다.

조회 DTO: 화면이나 API에 내려줄 데이터만 요청 DTO: 입력값 검증 중심 내부 계산용 데이터는 별도 객체로 분리

DTO는 상태를 담는 객체이지, 비즈니스 판단을 하는 객체가 아니니까! 절대로 db를 그대로 때려박지 않으려고 노력했다.

3. 날짜와 금액 타입은 타협하지 않기로 했다.

레거시에서는 이런 타입들이 섞여 있었다.

날짜: String, Date, Timestamp 혼용 금액: int, long, double 혼재

리뉴얼 과정에서 이걸 그대로 가져가면, 나중에 버그가 나는 지점을 예측하기가 어려웠다. 특히 가격 계산이 중요한 프로젝트인데 숫자들이 아주 지멋대로라 굉장히 곤란...

그래서 DTO 기준을 아예 고정했다.

날짜/시간: LocalDateTime 금액/비율(정수, 소수): Integer, BigDecimal

변환 시간이 조금 들더라도 의미가 명확한 타입을 쓰는 게 유지보수에서는 훨씬 싸다는 결론이었다. 그게 조금 더 확실한 계산이 가능하니까!

5. DTO가 바뀌면 로직도 같이 흔들린다.

리뉴얼을 하면서 가장 크게 느끼고 걱정했던 점이 이거였다.

DTO는 단순하지만 서비스 구조를 나타내는 설계의 일부분이다. DTO 필드가 하나 추가될 때마다 로직이 늘어나고 검증이 생기고 테스트를 해야한다.

그래서 DTO를 추가할 때마다 이 필드가 정말 있어야 하는지 고민을 많이많이많이 했다. 내 선택에 후회가 없기를. (물론 이렇게 하고 다음날에 후회해서 몇백줄 바꾸고 했음;)

마무리

리뉴얼 프로젝트를 하면서 깨달은 건 하나다.

DTO는 빨리 만들수록 좋지만, 아무 기준 없이 만들면 가장 오래 발목을 잡는다.

이후로는 DTO를 만들 때 항상 이 질문을 먼저 던진다.

이 DTO의 역할은 무엇인가 이 데이터는 언제까지 유효한가 서비스 로직과 얼마나 강하게 결합되는가

DTO 설계 기준을 정리한 것만으로도 리뉴얼 이후 코드의 흔들림은 확실히 줄어들었다. 특히 도메인을 바꾼다던가 이상한 짓은 절대 하지 않기로 다짐했다.

이상... 프로젝트 8개를 한번에 리뉴얼한 개발자의 일기... 끝. (문제는 아직도 테스트 중이다.)

“어차피 값 몇 개만 바꿔서 한 번 더 insert 하는 건데
객체를 새로 만들지 않고 재사용해도 되지 않을까?”

결론부터 말하면 insert에서 객체 재사용은 피하는 게 맞다. 특히 이력성·동의성 데이터라면 더더욱 그렇다.

문제 상황

아래는 하나의 요청에서 두 종류의 동의 데이터를 저장하는 상황을 단순화한 예시다. 먼저 기본 동의를 저장하고, 조건에 따라 추가 동의를 한 번 더 저장한다.

Agreement agre = new Agreement();

// 공통 값 세팅
agre.setOrderId(orderId);
agre.setUserType("MAIN");
agre.setCreatedAt(now);
// 기본 동의
agre.setAgreeItems(baseAgreeList);
baseAgre.setExtraYn("N");
mapper.insert(agre);

// 추가 동의
if (!extraAgreeList.isEmpty()) {
    agre.setAgreeItems(extraAgreeList);
    baseAgre.setExtraYn("Y");
    mapper.insert(agre);
}

겉보기에는 문제가 없어 보이고, 실제로도 정상적으로 insert는 수행된다. 하지만 이 구조에는 몇 가지 근본적인 문제가 있다.

문제점

1. insert인데 update처럼 보인다

같은 객체를 수정해서 다시 insert 하면 코드를 읽는 입장에서는 자연스럽게 이런 의문이 든다.

이 객체는 이미 DB에 들어간 상태 아닌가? PK나 식별 값은 어디서 관리되는가? update와 무엇이 다른가?

의도가 코드에 드러나지 않아 이해 비용이 커진다.

2. 값 오염 가능성

현재는 필드가 단순해서 괜찮아 보일 수 있다. 하지만 시간이 지나면서 다음과 같은 변화가 생긴다.

컬럼 추가 insert 조건 분기 증가 기본값 세팅 로직 변경

이 순간부터 이전 insert의 값이 다음 insert에 섞여 들어갈 위험이 생긴다.

3. 이력성 데이터에겐 최악

동의, 로그, 이력 테이블은 “언제, 무엇이, 왜 저장됐는지”가 중요하다. 객체 하나를 계속 수정해서 여러 row를 만드는 구조는 장애 분석과 디버깅 시 추적 난이도를 크게 높인다.

권장 방식

원칙은 단순하다.

insert = 객체 1개 = row 1개

공통 세팅은 메서드로 분리하고, 각 insert마다 새 객체를 생성한다.

private Agreement baseAgreement(String orderId, LocalDateTime now) {
    Agreement agre = new Agreement();
    agre.setOrderId(orderId);
    agre.setUserType("MAIN");
    agre.setCreatedAt(now);
    return agre;
}

// 기본 동의
Agreement baseAgre = baseAgreement(orderId, now);
baseAgre.setAgreeItems(baseAgreeList);
baseAgre.setExtraYn("N");
mapper.insert(baseAgre);

// 추가 동의
if (!extraAgreeList.isEmpty()) {
    Agreement extraAgre = baseAgreement(orderId, now);
    extraAgre.setAgreeItems(extraAgreeList);
    extraAgre.setExtraYn("Y");
    mapper.insert(extraAgre);
}

정리

insert 로직에서 객체 재사용은 당장은 코드가 짧아 보일 수 있지만, 시간이 지날수록 유지보수 비용이 커진다. 특히 동의·로그·이력 데이터라면 객체를 아끼기보다 명확한 구조를 선택하는 게 맞다.

insert는 항상 “이 객체는 하나의 row만 책임진다” 라는 원칙을 지키는 것이 가장 안전하다.

로컬에선 문제 없던 스케줄러가 톰캣에 올리면 중복 실행되는 문제 발생했다. 아래는 기존 server.xml 설정이다.

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">  
<Context docBase="test" path="/" reloadable="true" />

원인

/webapps/
├── test.war
├── test/          ← test.war가 자동으로 풀리면서 생성됨
├── ROOT/          ← 기본 context

톰캣이 실행되면 webapps안에 test 폴더와 ROOT 폴더가 생기는데, 결과적으로 동일 WAR의 인스턴스가 중복 실행되어 @Scheduled 사용시 2번 실행된다.

해결 방법

1. autoDeploy, deployOnStartup비활성화

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false" deployOnStartup="false">  
<Context docBase="test" path="/" reloadable="true" />

autoDeploy="false" → WAR 파일이 있어도 자동 배포 안 함

deployOnStartup="false" → 톰캣 기동 시 WAR 자동 전개 안 함

<Context>에 명시된 docBase="test"만 명확하게 실행되며 test.war가 자동으로 풀려서 test/ 폴더 생기는 것도 방지된다.

2. appBase 자체를 별도로 설정

<Host name="localhost" appBase="webapps/test" unpackWARs="true" autoDeploy="true">  
<Context docBase="test" path="/" reloadable="true" />

webapps/test라는 별도의 디렉토리를 톰캣 배포 루트(appBase)로 지정하여 해당 경로에 test.war만 존재하도록 관리한다.

📌 구성 요소

🔁 가동 순서

1. Elasticsearch
2. Kibana
3. Logstash
4. Filebeat

⛔ 종료 시에는 반대 순서로: Filebeat → Logstash → Kibana → Elasticsearch

Elasticsearch

1. 설치

# Elasticsearch 컨테이너 실행
docker run -d \
  --name elasticsearch \
  -p 9200:9200 \
  -e discovery.type=single-node \
  -e ELASTIC_PASSWORD=**** \
  -e xpack.security.enabled=true \
  -e xpack.security.authc.api_key.enabled=true \
  -e ES_JAVA_OPTS="-Xms512m -Xmx512m" \
  -v esdata:/usr/share/elasticsearch/data \
  docker.elastic.co/elasticsearch/elasticsearch:9.0.3

# 접속 주소: http://localhost:9200
# 기본 관리자 계정: elastic
# 비밀번호: ELASTIC_PASSWORD 설정
# 실행 모드: 단일 노드 (discovery.type=single-node)
# Kibana, Logstash, Filebeat 모두 이 주소로 연결됨

Kibana

1. 설치

docker run -d \
  --name kibana \
  -p 5601:5601 \
  -e ELASTICSEARCH_HOSTS=http://elasticsearch:9200 \
  -e ELASTICSEARCH_USERNAME=kibana_system \
  -e ELASTICSEARCH_PASSWORD=***** \
  -e xpack.security.encryptionKey=**** \
  -e xpack.encryptedSavedObjects.encryptionKey=**** \
  -e xpack.reporting.encryptionKey=**** \
  docker.elastic.co/kibana/kibana:9.0.3

Logstash

1. 설치

docker run -d \
  --name logstash \
  -p 5044:5044 \
  -e xpack.monitoring.elasticsearch.username=elastic \
  -e xpack.monitoring.elasticsearch.password=**** \
  -e xpack.monitoring.elasticsearch.hosts=http://elasticsearch:9200 \
  docker.elastic.co/logstash/logstash:9.0.3

2. 설정

docker exec -it logstash /bin/bash
cd /usr/share/logstash/pipeline
vi logstash.conf

input {
  beats {
    port => 5044
  }
}

filter {
  json {
    source => "message"
    remove_field => ["message"]
    tag_on_failure => ["_jsonparsefailure"]
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    user => "elastic"
    password => "****"
    index => "log-%{project}-%{+YYYY.MM.dd}"
  }

  stdout {
    codec => rubydebug
  }
}

Filebeat

1. 설치

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.18.3-amd64.deb
sudo dpkg -i filebeat-8.18.3-amd64.deb
cd /etc/filebeat
vi filebeat.yml

2. 설정

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /path/to/your/logs/app.log
    fields:
      project: your-project-name
    fields_under_root: true

output.logstash:
  hosts: ["your-logstash-host:5044"]

sudo chown root:root filebeat.yml
sudo chmod 644 filebeat.yml

3. 실행

# 서비스 등록
sudo systemctl enable filebeat
# 시작
sudo systemctl start filebeat
# 시작
sudo systemctl stop filebeat
# 재시작 
sudo systemctl restart filebeat
# 로깅
sudo journalctl -u filebeat -f

• Nginx 올리기 docker run --name nginx -d -p 80:80 -p 443:443 nginx

• 접속 docker exec -it nginx /bin/bash

• conf 설정 (include 설정 추가) vi /etc/nginx/nginx.conf

2. Docker에 tomcat, java 이미지 설치

• 원하는 설정에 맞춰서 톰캣과 자바를 설치 docker pull tomcat:10.1.30-jdk17-temurin-noble

3. Docker에 tomcat 컨테이너 올리기

• 호스트 포트 및 컨테이너 포트 설정 후 올리기 docker run -d -p 8080:8080 --name tomcat-container tomcat:10.1.30-jdk17-temurin-noble

4. Nginx conf 설정

• includ에 설정한 위치에 설정 conf 생성
• 포워딩 주소 및 도메인 설정

proxy_set_header X-Real-IP $remote_addr; 클라이언트의 실제 IP 주소를 백엔드 서버로 전달 이 설정을 생략하면 백엔드 서버에서 클라이언트의 실제 IP를 알 수 없고, 대신 프록시 서버의 IP 주소만 보이게 되어, 원본 클라이언트의 IP를 추적할 수 없음.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for 클라이언트의 IP 주소를 X-Forwarded-For 헤더에 추가 이 헤더를 설정하지 않으면, 백엔드 서버가 요청의 출처 IP를 알 수 없게 되어, 클라이언트의 실제 IP를 파악할 수 없음

proxy_set_header X-Forwarded-Port $server_port; 요청을 받은 서버의 포트 번호를 X-Forwarded-Port 헤더로 전달 이 설정을 하지 않으면, 백엔드 서버에서 요청이 들어온 포트를 알 수 없어서, 요청이 어떤 포트로 들어왔는지 확인할 수 없음.

proxy_set_header X-Forwarded-Proto $scheme; 요청이 HTTPS인지 HTTP인지 구분할 수 있도록 X-Forwarded-Proto 헤더를 전달 이 헤더가 없으면 백엔드 서버는 요청이 HTTP로 전달되었는지 HTTPS로 전달되었는지 알 수 없어서 보안이나 리디렉션 관련 로직에서 문제가 발생할 수 있음

proxy_set_header X-Forwarded-Host $Host; 클라이언트가 요청한 원래의 호스트 이름을 X-Forwarded-Host 헤더로 전달 이 헤더가 없으면, 백엔드 서버가 원래 요청된 호스트 이름을 알 수 없어, 동적 도메인 기반 로직이 제대로 작동하지 않을 수 있음

proxy_set_header Host $http_host; 클라이언트가 요청한 호스트를 Host 헤더로 전달하고 $http_host는 클라이언트의 요청에 포함된 호스트 정보를 나타냄 이 설정을 하지 않으면, 백엔드 서버가 요청에 대한 정확한 호스트를 알 수 없고, 이는 다중 도메인을 사용하는 시스템에서 중요한 정보를 잃게 될 수 있음

여러 개의 독립적인 컴퓨터나 서버가 네트워크를 통해 연결되어 하나의 시스템처럼 작동하도록 구성된 시스템. 클러스터의 주요 목적은 성능 향상, 신뢰성 증대, 또는 두 가지 모두를 달성하는 것. 클러스터는 여러 형태가 있으며, 각 형태는 특정 용도와 요구 사항에 맞게 설계된다.

📌 클러스터(Cluster) 종류

프로세스 간의 통신 방법 중 하나로 프로세스에 특정 이벤트가 발생했음을 알리기 위해 사용된다. 예를 들어, 시그널을 사용하여 프로세스에 종료, 중지, 일시 정지와 같은 다양한 명령을 전달할 수 있다.

📌 주요 시그널과 명령어

인터넷을 통해 원격 저장소(리포지토리)에서 패키지를 다운로드하고 설치하는 방법

• 원격 저장소 사용: 패키지 관리 도구가 인터넷에 연결된 저장소에서 최신 패키지 정보를 가져와 패키지를 설치, 업데이트, 제거한다.
• 의존성 해결: 패키지를 설치할 때 필요한 다른 패키지(의존성)를 자동으로 찾아서 함께 설치한다.

명령어 예시 레드햇 계열: yum install <패키지>, dnf install <패키지> 데비안 계열: apt-get install <패키지>, apt install <패키지> SUSE 계열: zypper install <패키지> Arch Linux: pacman -S <패키지>

💻 오프라인 패키지 관리 기법

인터넷 연결 없이 로컬에 저장된 패키지 파일을 직접 설치, 제거, 관리하는 방법

• 로컬 패키지 사용: 이미 다운로드된 패키지 파일을 로컬에서 직접 설치하거나 관리한다.
• 의존성 해결 필요: 오프라인으로 패키지를 설치할 때는 의존성을 수동으로 해결할 수도 있음

명령어 예시 레드햇 계열 및 SUSE: rpm -ivh <패키지.rpm> 데비안 계열: dpkg -i <패키지.deb> Arch Linux: pacman -U <패키지.tar.xz>

📌 온라인/오프라인 패키지 관리기법 구분표

리눅스에서 디스크 관리의 유연성을 제공하는 시스템으로 물리적 디스크(Physical Volume, PV)를 그룹으로 묶어 하나의 논리적 볼륨(Logical Volume, LV)을 만들 수 있게 한다. 이 논리적 볼륨은 파일 시스템이 사용하는 공간으로, 물리적인 디스크의 제약에서 벗어나 크기를 동적으로 조절하거나, 디스크를 추가할 수 있는 장점이 있다.

❗️ LVM 주요 구성 요소

Physical Volume (PV) 실제 물리적인 디스크 또는 디스크 파티션을 의미하며 LVM의 가장 기본 단위다.

Volume Group (VG) 여러 개의 Physical Volume(PV)을 묶어 하나의 Volume Group(VG)을 만들고, 논리적 볼륨을 생성할 수 있는 공간을 제공한다.

Logical Volume (LV) Volume Group(VG)에서 생성된 논리적인 파티션으로 실제 파일 시스템을 생성하고 데이터를 저장할 수 있는 공간으로 사용된다.

⚙️ LVM 사용 순서

• PV > VG > LV

여러 개의 하드디스크를 결합하여 하나의 논리적인 디스크처럼 동작하게 하는 기술로 데이터의 성능, 안정성, 용량을 개선하기 위해 사용된다. RAID는 여러 수준(Level)으로 나뉘며, 각 수준마다 특성과 목적이 다르다.

📌 RAID 레벨별 계산 공식

1. RAID 0

   • 가용 용량 = N × S
   • 손실 용량 = 0
   • 성능과 용량 극대화가 목적, 가용 용량은 모든 디스크의 용량 합과 동일

2. RAID 1

   • 가용 용량 = S
   • 손실 용량 = (N - 1) × S
   • 데이터 보호를 위해 모든 디스크에 동일한 데이터를 저장, 가용 용량은 단일 디스크의 용량과 동일

3. RAID 5

   • 가용 용량 = (N - 1) × S
   • 손실 용량 = S
   • 패리티 정보가 각 디스크에 분산 저장, 전체 디스크 수에서 하나를 제외한 나머지 디스크의 용량 합이 가용 용량.

4. RAID 6

   • 가용 용량 = (N - 2) × S
   • 손실 용량 = 2 × S
   • 두 개의 패리티 정보가 각 디스크에 분산 저장, 전체 디스크 수에서 두 개를 제외한 나머지 디스크의 용량 합이 가용 용량.

💻 예시 문제 및 풀이

예시 1: RAID 0

• 문제: 4개의 디스크가 있으며, 각 디스크의 용량이 1TB인 경우, RAID 0의 가용 용량은?
• 풀이:
  • N = 4, S = 1TB
  • 가용 용량 = N × S = 4 × 1TB = 4TB

예시 2: RAID 1

• 문제: 4개의 디스크가 있으며, 각 디스크의 용량이 2TB인 경우, RAID 1의 가용 용량은?
• 풀이:
  • N = 4, S = 2TB
  • 가용 용량 = S = 2TB

예시 3: RAID 5

• 문제: 5개의 디스크가 있으며, 각 디스크의 용량이 1TB인 경우, RAID 5의 가용 용량은?
• 풀이:
  • N = 5, S = 1TB
  • 가용 용량 = (N - 1) × S = (5 - 1) × 1TB = 4TB

예시 4: RAID 6

• 문제: 6개의 디스크가 있으며, 각 디스크의 용량이 1TB인 경우, RAID 6의 가용 용량은?
• 풀이:
  • N = 6, S = 1TB
  • 가용 용량 = (N - 2) × S = (6 - 2) × 1TB = 4TB

You are given an array prices where prices[i] is the price of a given stock on the ith day.

You want to maximize your profit by choosing a single day to buy one stock and choosing a different day in the future to sell that stock.

Return the maximum profit you can achieve from this transaction. If you cannot achieve any profit, return 0.

Example 1: Input: prices = [7,1,5,3,6,4] Output: 5 Explanation: Buy on day 2 (price = 1) and sell on day 5 (price = 6), profit = 6-1 = 5. Note that buying on day 2 and selling on day 1 is not allowed because you must buy before you sell.

Example 2: Input: prices = [7,6,4,3,1] Output: 0 Explanation: In this case, no transactions are done and the max profit = 0.

📝 풀이

class Solution {
    public int maxProfit(int[] prices) {
        int buy = prices[0];
        int profit = 0;
        for (int i = 1; i < prices.length; i++) {
            buy = Math.min(buy, prices[i]);
            profit = Math.max(profit, prices[i] - buy);
        }
        return profit;
    }
}

문제는 주식을 한 번 사고, 나중에 팔아서 벌 수 있는 최대의 이익을 찾는 것이다.

먼저 buy를 첫 번째 날의 주식 가격인 prices[0]으로 초기화하고, 현재까지 주식을 살 수 있는 가장 저렴한 가격을 담는다. 그리고 profit를 0으로 초기화하여, 현재까지 계산된 최대 이익을 저장한다.

다음, 두 번째 날부터 시작하여 (i = 1) 마지막 날까지 반복문을 돌린다. 이후 buy를 업데이트하면서 현재의 buy 값과 i번째 날의 가격을 비교하고 더 작은 값을 선택한다. 또한 Math.max로 현재까지의 최대 이익과 i번째 날의 가격에서 현재 최저 구매 가격을 뺀 값(prices[i] - buy) 중 더 큰 값을 선택한다.

이렇게 반복문을 수행하면 매일 주식을 팔았을 때의 최대 이익을 쉽게 계산할 수 있다.

📝 풀이

class Solution {
    public int tribonacci(int n) {
         if (n == 0) {
            return 0;
        }

        if (n == 1 || n == 2) {
            return 1;
        }

        int t0 = 0, t1 = 1, t2 = 1;
        int tn = 0;

        for (int i = 3; i <= n; i++) {
            tn = t0 + t1 + t2;
            t0 = t1;
            t1 = t2;
            t2 = tn;
        }

        return tn;
    }
}

문제를 해결하기 위해, 동적 계획법(Dynamic Programming)을 사용해 이전 결과를 활용하여 다음 값을 계산하는 반복문 방법을 선택했다.

Tribonacci 수열의 시작점인 T0, T1, T2 값이 이미 정의되어 있으므로, 이들에 대한 기본 조건을 설정한다. 이후 기본 값을 제외한 나머지 Tribonacci 값은 이전 세 항의 합으로 이루어지므로, 반복문을 통해 이를 계산한다.