어디부터 봐야 할까

네트워크 패킷이 서버에 도달해서 애플리케이션까지 가는 경로는 4계층입니다.

이 글에서는 가운데 두 계층을 중심으로, 안전한 값을 제시합니다.

1단계 — 현재 상태 진단

설정을 만지기 전에 무엇이 부족한지 확인합니다.

# 패킷 드롭 발생 여부
ip -s link show eth0 | grep -A1 RX
netstat -s | grep -E "drop|overflow"

# accept 큐 오버플로
ss -s
nstat -a | grep -i listen

# conntrack 사용량
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# TIME_WAIT 개수
ss -tan | awk '{print $1}' | sort | uniq -c

“ListenOverflows”나 “drops” 카운터가 증가 중이라면 그 부분의 튜닝이 필요합니다. 모든 카운터가 0이고 처리량이 부족하다면 NIC나 애플리케이션 쪽을 봐야 합니다.

2단계 — TCP 백로그 / accept 큐

somaxconn은 수락(accept) 대기 큐의 최대 크기입니다. 기본값 4096이 작아 보이지 않지만, Nginx의 listen ... backlog=도 이 값에 의해 제한되므로 실제론 자주 부족합니다.

# /etc/sysctl.d/99-network-tune.conf
# accept 대기 큐
net.core.somaxconn = 8192

# SYN 백로그
net.ipv4.tcp_max_syn_backlog = 8192

# 연결 추적 테이블
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_buckets = 262144

Nginx 측에서도 listen 80 backlog=8192; 처럼 함께 명시해야 의미가 있습니다.

3단계 — TIME_WAIT와 임시 포트

높은 동시 연결, 짧은 keep-alive 환경에서는 TIME_WAIT 상태 소켓이 빠르게 누적됩니다. 임시 포트가 고갈되면 새 연결이 안 됩니다.

# TIME_WAIT 재사용 (NAT 환경에서도 안전)
net.ipv4.tcp_tw_reuse = 1

# FIN_WAIT 짧게
net.ipv4.tcp_fin_timeout = 15

# 임시 포트 범위 확장
net.ipv4.ip_local_port_range = 10240 65535

⚠️ 사용 금지

• net.ipv4.tcp_tw_recycle — 4.12 커널에서 제거됨. NAT 환경에서 연결 실패의 원인이 됩니다.

4단계 — 송수신 버퍼

긴 RTT(예: 글로벌 사용자) 환경에서 처리량이 잘 안 나온다면 버퍼 크기가 작은 것일 수 있습니다.

# 최대 소켓 버퍼 (16MB)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# TCP 자동 튜닝 한계
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 백로그 큐 (소프트IRQ가 처리 못한 패킷)
net.core.netdev_max_backlog = 5000

대역폭 곱 RTT(BDP)가 8MB를 넘는 경우(예: 100Mbps × 100ms RTT = 1.25MB는 OK이지만 1Gbps × 100ms = 12MB)에는 위 16MB로도 부족할 수 있습니다.

5단계 — 혼잡 제어 알고리즘 (BBR)

BBR은 패킷 손실이 아니라 대역폭과 RTT 측정으로 혼잡을 판단합니다. 한국-일본처럼 짧은 RTT, 또는 글로벌 긴 경로 양쪽 모두에서 cubic 대비 좋은 결과를 보이는 경우가 많습니다.

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

활성 후 확인:

sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr

6단계 — keepalive 짧게

방화벽이나 LB가 idle 연결을 끊는 환경에서는 keepalive를 짧게 잡아 미리 dead connection을 정리합니다.

net.ipv4.tcp_keepalive_time = 600    # 10분 (기본 7200초 = 2시간)
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 3

7단계 — SYN Flood / 보안 관련

DDoS 환경에서 동작하는 서버라면 다음 값을 함께 설정합니다.

# SYN Cookie (메모리 고갈 방어)
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2

# 비정상 패킷 무시
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# IP 스푸핑 방어 (Reverse Path Filter)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# ICMP redirect 무시
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

DDoS 방어 원리에 대한 더 자세한 설명은 이 글을 참고하세요.

8단계 — 애플리케이션 한계 (nofile)

sysctl만 풀어도 애플리케이션 한계가 그대로면 의미가 없습니다.

# /etc/security/limits.conf
*    soft  nofile  1048576
*    hard  nofile  1048576
root soft  nofile  1048576
root hard  nofile  1048576

systemd 서비스 단위로도 적용:

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=1048576

sudo systemctl daemon-reload
sudo systemctl restart nginx

확인:

cat /proc/$(pidof nginx)/limits | grep "open files"

한 번에 적용하는 권장 프로필

웹/API 서버의 무난한 시작점입니다. 워크로드에 따라 추가 조정이 필요합니다.

# /etc/sysctl.d/99-server-tune.conf
# === 백로그 / 큐 ===
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 8192

# === TIME_WAIT / 포트 ===
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = 10240 65535

# === 버퍼 ===
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# === 혼잡 제어 ===
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# === keepalive ===
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 3

# === conntrack ===
net.netfilter.nf_conntrack_max = 1048576

# === 보안 ===
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0

sudo sysctl --system
sudo sysctl -p /etc/sysctl.d/99-server-tune.conf

안전한 적용 절차

운영 서버에 한 번에 적용하지 마세요. 다음 절차를 권장합니다.

1. 개발/스테이징 서버에서 먼저 동일 워크로드로 부하 테스트(wrk, k6 등)
2. 변경 전후 지표 비교 — RPS, 응답 시간, CPU, 메모리, 패킷 드롭
3. 운영 서버에 점진 적용 — 한 번에 한두 항목씩, 24시간 관찰
4. 롤백 계획 준비 — 적용한 파일을 .disabled로 바꾸면 다음 부팅 시 무효화됨

운영 중 적용은 그라데이션이 핵심입니다. 일이 잘못되면 새벽 3시에 누군가 깨어나야 하므로 느려도 안전한 방법을 택하세요.

측정 도구

튜닝 효과는 반드시 숫자로 확인해야 합니다.

전체적인 모니터링 구성은 Netdata 가이드에 정리해두었습니다.

마무리

커널 튜닝은 “블랙박스에서 손가락 굴리는” 작업이 아니라, 카운터 → 가설 → 측정 → 적용의 루프입니다. 위 권장 프로필을 그대로 가져가도 안전하지만, 패킷 드롭이나 백로그 오버플로 카운터가 증가하지 않는다면 굳이 만질 필요가 없는 경우가 많습니다.

TCP-80.NET의 전용서버는 NIC 인터럽트 분산까지 사전 설정해 출고합니다. 추가 튜닝에 대한 문의는 @tcp80net으로 부탁드립니다.

한눈에 보는 핵심 헤더

가장 먼저 추가해야 하는 것은 위 4개의 “필수” 헤더입니다.

1. HSTS (Strict-Transport-Security)

브라우저가 이 도메인은 절대 HTTP로 접근하지 말라고 기억하게 만듭니다. SSL Strip 같은 다운그레이드 공격을 무력화합니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

• max-age=31536000 — 1년간 유지
• includeSubDomains — 모든 서브도메인에 동일 적용
• preload — 브라우저 빌트인 목록(HSTS Preload)에 등재 신청용

주의: HSTS는 신중히 적용해야 합니다. 한 번 적용되면 만료 전까지 HTTP로 절대 접근할 수 없습니다. 인증서 갱신 실패나 서브도메인 중 HTTP만 쓰는 게 있다면 사이트 전체가 차단됩니다.

도입 절차:

1. max-age=600 (10분)로 시작 → 며칠 운영
2. max-age=86400 (1일) → 1주 관찰
3. max-age=31536000 (1년)으로 강화
4. (선택) hstspreload.org에 등록

2. Content-Security-Policy (CSP)

페이지에서 로드 가능한 리소스의 출처를 제한합니다. XSS 공격이 성공해도 외부로 데이터를 빼돌리거나 외부 스크립트를 실행하기 어렵게 만듭니다.

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" always;

CSP 도입 절차

기존 사이트에 갑자기 적용하면 정상 리소스까지 차단됩니다. 다음 순서로 도입하세요.

1단계 — Report-Only 모드 (차단 없이 위반 사항만 수집)

add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report" always;

서버에서 /csp-report 엔드포인트를 만들어 위반 보고서를 수집·분석합니다.

2단계 — 위반 사항을 모두 정상화한 뒤 Report-Only를 떼고 일반 CSP로 전환합니다.

3단계 — unsafe-inline, unsafe-eval을 제거할 수 있도록 인라인 스크립트를 nonce/hash 방식으로 바꿉니다.

<script nonce="random123">/* 인라인 스크립트 */</script>

add_header Content-Security-Policy "script-src 'self' 'nonce-random123'" always;

3. X-Content-Type-Options

브라우저가 응답의 Content-Type을 멋대로 추측(MIME sniffing)하지 못하게 합니다.

add_header X-Content-Type-Options "nosniff" always;

이 한 줄만 추가하면 끝입니다. 부작용 없이 무조건 추가하세요.

4. X-Frame-Options

다른 사이트가 우리 페이지를 iframe으로 감싸지 못하게 합니다(클릭재킹 방어).

add_header X-Frame-Options "SAMEORIGIN" always;

CSP frame-ancestors를 이미 설정했다면 X-Frame-Options는 옛 브라우저 호환용으로만 의미가 있습니다.

5. Referrer-Policy

다른 사이트로 이동할 때 어떤 레퍼러 정보를 노출할지 제어합니다.

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

특별한 이유가 없다면 strict-origin-when-cross-origin이 정답입니다.

6. Permissions-Policy

페이지가 카메라, 마이크, 위치, 결제 API 등을 사용할 권한을 명시합니다.

add_header Permissions-Policy "geolocation=(), microphone=(), camera=(), payment=(self)" always;

• () 빈 괄호 — 모든 출처 차단
• (self) — 같은 출처만 허용
• (self "https://trusted.com") — 특정 출처도 허용

XSS가 성공해도 카메라·마이크 자동 켜기, 결제 API 무단 호출 등을 차단할 수 있습니다.

7. 한 번에 적용하는 Nginx 설정

/etc/nginx/conf.d/security-headers.conf로 분리해 모든 사이트에 include하면 관리가 편합니다.

# /etc/nginx/conf.d/security-headers.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

# CSP는 사이트마다 다르므로 server 블록에서 개별 적용

서버 블록에서 사이트별로 CSP 추가:

server {
    listen 443 ssl http2;
    server_name example.com;

    include /etc/nginx/conf.d/security-headers.conf;

    add_header Content-Security-Policy "default-src 'self'; ..." always;
}

8. 검증

설정을 적용한 뒤 다음 도구로 확인합니다.

• https://securityheaders.com — A 등급이 목표
• https://www.ssllabs.com/ssltest/ — A+ 등급이 목표
• https://csp-evaluator.withgoogle.com — CSP 정책 약점 검증

# 명령행에서 헤더만 확인
curl -I https://example.com

흔한 실수

always를 빼먹는다

• Nginx의 add_header는 기본적으로 2xx, 3xx 응답에만 적용됩니다. 404, 500 같은 에러 페이지에도 헤더가 붙으려면 always가 필수입니다.

add_header가 server 블록과 location 블록에 섞여 있을 때

• location 블록에 add_header가 하나라도 있으면 server 블록의 add_header는 덮어쓰여 사라집니다(상속 안 됨). location에서도 모든 헤더를 다시 명시하거나, location에서는 add_header를 쓰지 않는 것이 안전합니다.

CSP의 unsafe-inline을 영원히 두는 경우

• 처음에는 어쩔 수 없지만, nonce/hash로 옮기면 XSS 방어 효과가 비교할 수 없이 커집니다. 우선순위를 두고 단계적으로 제거하세요.

HSTS를 처음부터 1년으로 적용

• 인증서 갱신 실패 시 사이트가 1년간 접근 불가가 됩니다. 짧게 시작 → 점진적으로 늘리세요.

마무리

보안 헤더는 추가 비용도, 성능 저하도 거의 없는 보안 강화 수단입니다. SSL 인증서를 발급한 다음 단계로 반드시 적용해야 합니다.

TCP-80.NET의 VPS / 전용서버에서 Nginx 보안 설정 중 막히는 부분이 있으면 @tcp80net으로 한국어 문의 가능합니다.

핵심 아이디어

배포 절차:

1. Green에 신규 버전을 배포
2. Green이 정상 동작하는지 헬스체크
3. 로드밸런서/프록시 설정만 변경 → 트래픽이 Green으로 전환
4. Blue는 즉시 폐기하지 않고, 문제 발생 시 즉시 롤백 가능한 상태로 유지

핵심은 트래픽 전환이 단일 설정 변경이라는 점입니다. 코드 푸시도, 빌드도, 재시작도 아닌 — Nginx의 upstream만 바꿉니다.

1단계 — 두 개의 애플리케이션 인스턴스

같은 서버에서 두 인스턴스를 동시에 운영합니다(다른 포트로).

# Blue (운영 중)
systemctl status myapp-blue   # 포트 8080
# Green (대기)
systemctl status myapp-green  # 포트 8081

systemd 템플릿 유닛으로 관리하면 깔끔합니다.

# /etc/systemd/system/myapp@.service
[Unit]
Description=MyApp instance %i
After=network.target

[Service]
User=deploy
WorkingDirectory=/opt/myapp/%i
ExecStart=/opt/myapp/%i/bin/start.sh
EnvironmentFile=/opt/myapp/%i/env
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl enable myapp@blue myapp@green
sudo systemctl start myapp@blue

2단계 — Nginx upstream 정의

# /etc/nginx/conf.d/myapp.conf

upstream blue {
    server 127.0.0.1:8080;
    keepalive 32;
}

upstream green {
    server 127.0.0.1:8081;
    keepalive 32;
}

# 현재 활성 upstream을 가리키는 별명
upstream active {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    location / {
        proxy_pass http://active;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

active가 가리키는 포트만 바꾸면 트래픽이 전환됩니다.

3단계 — 전환 스크립트

active의 포트만 바꿔서 nginx reload 하는 스크립트입니다.

#!/bin/bash
# /usr/local/bin/switch-deploy.sh
set -euo pipefail

TARGET="${1:-}"  # blue 또는 green
CONF="/etc/nginx/conf.d/myapp.conf"

if [[ "$TARGET" != "blue" && "$TARGET" != "green" ]]; then
  echo "Usage: $0 <blue|green>"
  exit 1
fi

PORT=8080
[[ "$TARGET" == "green" ]] && PORT=8081

# active upstream의 포트만 치환
sed -i "/upstream active/,/}/ s|server 127.0.0.1:[0-9]*;|server 127.0.0.1:${PORT};|" "$CONF"

# Nginx 설정 검증 후 reload
sudo nginx -t
sudo systemctl reload nginx

echo "Switched to $TARGET (port $PORT)"

sudo chmod +x /usr/local/bin/switch-deploy.sh

4단계 — 배포 스크립트 (Green에 배포)

#!/bin/bash
# /usr/local/bin/deploy-green.sh
set -euo pipefail

NEW_VERSION="$1"
APP_DIR="/opt/myapp/green"

echo "[1/4] Stopping green..."
sudo systemctl stop myapp@green

echo "[2/4] Deploying version $NEW_VERSION to green..."
cd "$APP_DIR"
git fetch origin
git checkout "$NEW_VERSION"
npm ci --production
# 또는 pip install / cargo build / docker pull 등

echo "[3/4] Starting green..."
sudo systemctl start myapp@green

echo "[4/4] Health check..."
for i in {1..30}; do
  if curl -fsS http://127.0.0.1:8081/healthz > /dev/null; then
    echo "Green is healthy"
    exit 0
  fi
  sleep 1
done

echo "Green failed to start" >&2
exit 1

성공하면 다음과 같이 트래픽을 전환합니다:

sudo /usr/local/bin/deploy-green.sh v1.1.0
sudo /usr/local/bin/switch-deploy.sh green

5단계 — 헬스체크 엔드포인트

/healthz는 단순 200을 반환하는 게 아니라 실제 의존성까지 체크해야 합니다.

@app.route('/healthz')
def healthz():
    try:
        db.execute("SELECT 1")          # DB 연결
        redis.ping()                     # 캐시 연결
        return {"status": "ok"}, 200
    except Exception as e:
        return {"status": "fail", "error": str(e)}, 503

DB가 죽었는데 단순 200을 반환하면, Green으로 전환하자마자 모든 요청이 500으로 떨어집니다.

6단계 — 롤백

문제가 생기면 한 줄로 되돌립니다.

sudo /usr/local/bin/switch-deploy.sh blue

이게 Blue-Green의 가장 큰 가치입니다. Blue가 살아 있는 한 언제든 단일 명령으로 즉시 복귀가 가능합니다.

주의해야 할 함정

상태가 있는 연결

• WebSocket, SSE, gRPC 스트림처럼 장기 연결을 유지하는 클라이언트는 reload 시 그대로 유지됩니다. 새 연결만 Green으로 갑니다. 점진적으로 자연스러운 전환이 됩니다.
• 다만 세션 어피니티가 필요한 경우(예: 인메모리 세션) 두 인스턴스 모두에 세션 스토어가 공유돼야 합니다. Redis 세션 스토어 등을 두는 것이 안전합니다.

DB 마이그레이션

• Blue와 Green이 동시에 같은 DB를 보고 있으므로, 이전 버전과 호환되는 마이그레이션만 적용해야 합니다. 컬럼 삭제, 타입 변경 같은 파괴적 변경은 다음 절차로 분리하세요.
  1. 새 컬럼 추가 (이번 배포)
  2. 코드를 새 컬럼 사용으로 교체 (다음 배포)
  3. 옛 컬럼 삭제 (그 다음 배포)

환경 변수 / 비밀

• Green 환경 변수가 Blue와 다르면 의도하지 않은 차이가 생깁니다. 환경 변수 파일을 같은 곳에서 읽도록 통일하세요.

연결 풀 / 캐시 워밍업

• Green이 막 떴을 때 첫 요청은 DB 연결 풀이 비어 있어 느릴 수 있습니다. 헬스체크에서 가벼운 쿼리를 한 번 보내거나, /warmup 엔드포인트를 만들어 주요 쿼리를 미리 실행해두면 좋습니다.

Canary 배포로 확장

Blue-Green을 한 단계 발전시키면 Canary 배포가 됩니다. Nginx의 가중치 기능으로 트래픽을 부분 전환할 수 있습니다.

upstream active {
    server 127.0.0.1:8080 weight=9;  # Blue 90%
    server 127.0.0.1:8081 weight=1;  # Green 10%
    keepalive 32;
}

10%로 시작 → 30% → 50% → 100% 단계로 모니터링하면서 늘리면 됩니다. 문제 발생 시 가중치만 0으로 바꿔 즉시 차단합니다.

마무리

Blue-Green은 거창한 도구가 아닙니다. 두 개의 인스턴스 + 한 줄 짜리 Nginx upstream 변경만 있으면 다운타임 0초 배포가 가능합니다. 진입 비용이 낮으면서 효과는 즉시 체감됩니다.

TCP-80.NET의 일본 VPS 4GB 플랜이면 Blue-Green 환경 두 개를 모두 띄우기에 충분합니다. systemd 템플릿이나 Nginx 설정에 막히는 부분이 있으면 @tcp80net으로 한국어 문의 가능합니다.

MinIO를 선택해야 할 때

단일 노드 MinIO는 디스크 1대를 그대로 사용하므로 디스크 장애 = 데이터 손실입니다. 중요한 데이터는 백업 또는 분산 모드(4노드+)로 운영해야 합니다.

1단계 — 디스크 준비

MinIO는 빈 디렉토리만 있으면 동작하지만, 별도 디스크/파티션을 권장합니다. 다른 서비스의 디스크 사용량과 영향을 분리하기 위함입니다.

# 새 디스크 마운트 예시 (전용서버에 추가 디스크가 있을 때)
sudo mkfs.xfs /dev/sdb1
sudo mkdir -p /mnt/minio
sudo mount /dev/sdb1 /mnt/minio

# /etc/fstab 등록
echo "/dev/sdb1  /mnt/minio  xfs  defaults,noatime  0  2" | sudo tee -a /etc/fstab

xfs가 큰 파일과 많은 파일 양쪽에서 안정적이라 MinIO 공식 문서도 권장합니다.

2단계 — MinIO 설치

# 바이너리 다운로드
wget https://dl.min.io/server/minio/release/linux-amd64/minio -O /usr/local/bin/minio
chmod +x /usr/local/bin/minio

# 클라이언트(mc)도 함께
wget https://dl.min.io/client/mc/release/linux-amd64/mc -O /usr/local/bin/mc
chmod +x /usr/local/bin/mc

전용 사용자 생성:

sudo useradd -r minio-user -s /sbin/nologin
sudo chown -R minio-user:minio-user /mnt/minio

3단계 — systemd 서비스로 등록

# /etc/systemd/system/minio.service
[Unit]
Description=MinIO
After=network-online.target
Wants=network-online.target

[Service]
User=minio-user
Group=minio-user
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES
Restart=always
LimitNOFILE=65536
TasksMax=infinity
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

# /etc/default/minio
MINIO_VOLUMES="/mnt/minio"
MINIO_OPTS="--console-address :9001 --address :9000"
MINIO_ROOT_USER="admin"
MINIO_ROOT_PASSWORD="<강력한 비밀번호 32자 이상>"

sudo systemctl daemon-reload
sudo systemctl enable --now minio
sudo systemctl status minio

4단계 — 방화벽

기본 포트는 9000(API), 9001(Console)입니다. 외부에 노출할 필요가 없다면 차단하고, Nginx 리버스 프록시 뒤에 둡니다.

# 외부 노출 차단, localhost만
sudo ufw deny 9000
sudo ufw deny 9001

5단계 — Nginx로 HTTPS 종단

s3.example.com 도메인을 MinIO 앞에 둡니다.

# /etc/nginx/sites-available/minio
server {
    listen 443 ssl http2;
    server_name s3.example.com;

    ssl_certificate     /etc/letsencrypt/live/s3.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/s3.example.com/privkey.pem;

    # 대용량 업로드 허용
    client_max_body_size 5G;
    proxy_request_buffering off;
    proxy_buffering off;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 300;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        chunked_transfer_encoding off;
    }
}

# Console (관리 UI)
server {
    listen 443 ssl http2;
    server_name console.s3.example.com;

    ssl_certificate     /etc/letsencrypt/live/console.s3.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/console.s3.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9001;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket (콘솔 실시간 갱신)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        chunked_transfer_encoding off;
    }
}

client_max_body_size는 업로드 가능한 최대 객체 크기입니다. 영상 업로드까지 받으려면 충분히 키워야 합니다.

6단계 — 버킷 생성과 사용자 권한

mc 클라이언트로 관리합니다.

# 별칭 등록
mc alias set local https://s3.example.com admin '<MINIO_ROOT_PASSWORD>'

# 버킷 생성
mc mb local/uploads
mc mb local/backups

# 버킷 목록
mc ls local

# 정책 적용 (uploads만 공개 읽기)
mc anonymous set download local/uploads

애플리케이션용 별도 사용자(IAM 키)를 만듭니다.

mc admin user add local app-user '<32자 비밀번호>'

# 정책 작성: uploads 버킷에만 접근
cat > /tmp/app-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::uploads/*"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::uploads"]
    }
  ]
}
EOF

mc admin policy create local app-policy /tmp/app-policy.json
mc admin policy attach local app-policy --user app-user

이제 app-user의 액세스 키와 시크릿 키를 애플리케이션 환경 변수로 사용하면 됩니다.

7단계 — 애플리케이션 코드 (S3 SDK 그대로)

AWS S3 SDK에 endpoint만 바꿔주면 됩니다.

import boto3

s3 = boto3.client(
    's3',
    endpoint_url='https://s3.example.com',
    aws_access_key_id='app-user',
    aws_secret_access_key='<32자 비밀번호>',
    region_name='ap-northeast-1'
)

s3.upload_file('/tmp/photo.jpg', 'uploads', 'photos/2026/04/photo.jpg')

// Node.js (AWS SDK v3)
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  endpoint: "https://s3.example.com",
  region: "ap-northeast-1",
  credentials: {
    accessKeyId: "app-user",
    secretAccessKey: process.env.S3_SECRET,
  },
  forcePathStyle: true,  // MinIO는 path-style 권장
});

8단계 — 백업

단일 노드 MinIO는 디스크 장애에 취약합니다. 다음 중 하나는 반드시 적용하세요.

옵션 A: 별도 서버로 미러링 (Site Replication)

mc admin replicate add local backup --remote-bucket=uploads

옵션 B: 정기적으로 다른 위치로 동기화

# 매일 새벽 백업 서버로 동기화
mc mirror --remove local/uploads backup-server/uploads

옵션 C: 분산 모드 (운영 환경 권장) 서버 4대 이상으로 erasure coding을 활성화. 디스크 절반이 죽어도 데이터가 보존됩니다.

운영 모니터링

MinIO는 Prometheus 메트릭을 기본 제공합니다.

GET https://s3.example.com/minio/v2/metrics/cluster

주요 지표:

• minio_node_disk_free_bytes — 디스크 여유 공간
• minio_s3_requests_total — 초당 요청 수
• minio_node_disk_latency_us — 디스크 지연

Netdata, Grafana 대시보드와 연결하면 실시간 모니터링이 됩니다.

마무리

MinIO는 “S3 호환 + 자체 운영 + 일본 IDC 위치”라는 세 조건을 한 번에 만족시킵니다. 데이터 주권 요구가 있는 한국·일본 기업에 특히 잘 맞습니다.

영상·이미지 같은 대용량 워크로드는 전용서버의 디스크 옵션이 더 적합하며, 디스크 추가 옵션 문의는 @tcp80net으로 부탁드립니다.

세 가지의 역할

SPF만 있으면 본문 변조를 못 잡고, DKIM만 있으면 발송지 IP를 속일 수 있습니다. 세 가지가 함께 동작해야 안전합니다.

사전 조건

• 일본 서버에 PTR(역방향 DNS)이 설정되어 있어야 합니다. TCP-80.NET은 PTR 등록을 @tcp80net 요청으로 처리합니다.
• 도메인의 DNS를 직접 편집할 수 있어야 합니다(Cloudflare, 가비아, AWS Route 53 등).
• 메일 서버(Postfix 등)가 이미 동작 중이어야 합니다.

1단계 — SPF 설정

SPF는 도메인의 TXT 레코드에 한 줄을 추가하는 것으로 끝납니다.

타입: TXT
이름: @
값: v=spf1 ip4:203.0.113.10 -all

여러 발송 경로가 있을 때:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com -all

처음에는 ~all로 시작하고, 안정되면 -all로 강화하는 것이 안전합니다.

검증:

dig +short TXT example.com

2단계 — DKIM 설정 (Postfix + OpenDKIM)

DKIM은 메일 본문에 서명을 추가하고, 공개키를 DNS에 게시해 수신 서버가 검증할 수 있게 합니다.

OpenDKIM 설치

sudo apt install opendkim opendkim-tools
sudo mkdir -p /etc/opendkim/keys/example.com
sudo chown -R opendkim:opendkim /etc/opendkim

키 생성

cd /etc/opendkim/keys/example.com
sudo opendkim-genkey -s default -d example.com
sudo chown opendkim:opendkim default.private

생성된 default.txt에 DNS 등록용 공개키가 들어 있습니다.

default._domainkey  IN  TXT  ( "v=DKIM1; h=sha256; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

이 내용을 도메인 DNS에 TXT 레코드로 추가합니다(이름: default._domainkey).

OpenDKIM 설정

# /etc/opendkim.conf
Syslog                  yes
UMask                   002
Domain                  example.com
KeyFile                 /etc/opendkim/keys/example.com/default.private
Selector                default
Socket                  inet:8891@localhost
Mode                    sv
SubDomains              no
AutoRestart             yes
SignatureAlgorithm      rsa-sha256

Postfix 연동

# /etc/postfix/main.cf 끝에 추가
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

sudo systemctl enable --now opendkim
sudo systemctl restart postfix

테스트 메일을 보내고 Gmail 헤더에서 dkim=pass가 보이면 성공입니다.

3단계 — DMARC 설정

DMARC는 SPF/DKIM 실패 시 동작과 보고서 수신 주소를 정의합니다.

타입: TXT
이름: _dmarc
값: v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100

정책 단계

DMARC는 단계적으로 강화해야 합니다. 처음부터 reject로 두면 정상 메일까지 차단되는 사고가 일어납니다.

rua=로 지정한 주소로 매일 인증 결과 보고서가 옵니다. 대규모 발송 환경이면 https://dmarcian.com 같은 분석 SaaS를 쓰는 게 편합니다.

4단계 — BIMI (선택)

BIMI는 인증된 도메인의 메일에 브랜드 로고를 표시해주는 표준입니다. DMARC p=quarantine 이상이 전제 조건입니다.

타입: TXT
이름: default._bimi
값: v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem

BIMI 자체는 인증이 아니지만, 사용자에게 메일이 정품임을 시각적으로 보여줘 클릭률을 높이는 효과가 있습니다.

5단계 — 검증 도구

설정이 다 끝나면 다음 도구로 확인합니다.

# 한 번에 보기
dig +short TXT example.com           # SPF
dig +short TXT default._domainkey.example.com  # DKIM
dig +short TXT _dmarc.example.com    # DMARC

웹 도구:

• https://mxtoolbox.com/SuperTool.aspx — SPF/DKIM/DMARC 한 번에 확인
• check-auth@verifier.port25.com 으로 메일을 보내면 자동 응답으로 결과 분석

자주 빠지는 함정

SPF에 include: 너무 많이 추가

• SPF는 DNS 조회 횟수가 10회를 초과하면 실패 처리됩니다. SendGrid, Mailgun, Google 등을 모두 추가하면 한도를 넘기 쉬우니, 사용하지 않는 서비스는 제거하세요.

DKIM 키 길이 1024 → 2048 변경 시

• 일부 DNS 제공자는 TXT 레코드 한 줄 길이 제한이 있습니다. 따옴표로 분할해 넣어야 하는 경우가 있으니 등록 후 dig로 반드시 검증하세요.

DMARC reject 직행

• 외부 SaaS(설문, 청구서, CRM 등)도 같은 도메인으로 발송 중이라면, 정책을 강화하면 그쪽 메일이 모두 차단됩니다. 보고서로 발송 출처를 모두 파악한 뒤 단계적으로 강화하세요.

메일 발송 IP의 PTR 누락

• IPv6로 메일을 보낼 때 PTR이 없으면 Gmail은 거의 무조건 거부합니다. 호스팅사에 PTR 등록을 요청하세요.

마무리

SPF·DKIM·DMARC는 한 번 잘 설정해두면 도메인 평판이 안정적으로 누적됩니다. 설정 후에는 DMARC 보고서를 1주일 정도 모니터링한 뒤 정책을 점진 강화하세요.

TCP-80.NET의 일본 서버는 PTR 등록을 무료로 지원하며, 메일 서버 운영 중 막히는 부분이 있으면 @tcp80net으로 한국어 안내가 가능합니다.

게임 서버에서 중요한 지표

웹은 1초가 빠르고 늦고에 민감하지만, 게임은 5ms와 10ms의 차이가 곧 승패에 영향을 줍니다.

1단계 — 데이터센터 위치 선택

같은 일본이라도 도쿄/오사카/후쿠오카에 따라 한국 사용자와의 RTT가 다릅니다.

다만 후쿠오카는 IDC 선택지가 좁아 가용성이 떨어질 수 있습니다. 글로벌 사용자도 함께 받는다면 도쿄가 균형이 좋습니다.

2단계 — NIC 큐와 IRQ 분산

게임 서버처럼 패킷이 많은 워크로드는 단일 CPU에 인터럽트가 몰리면 그 코어만 100%가 되고 다른 코어는 놀게 됩니다. RSS(Receive Side Scaling)로 큐를 늘리고 IRQ를 분산해야 합니다.

# NIC가 지원하는 큐 개수 확인
ethtool -l eth0

# 큐 개수를 코어 수 만큼 설정
sudo ethtool -L eth0 combined 8

# IRQ를 각 코어에 분산
sudo systemctl enable --now irqbalance

수동으로 IRQ를 고정하고 싶다면 set_irq_affinity.sh 스크립트를 사용하거나 /proc/irq/<번호>/smp_affinity를 직접 편집합니다.

3단계 — TCP/UDP 버퍼 튜닝

게임이 UDP를 쓰더라도 백엔드 통신(DB, 인증)은 대부분 TCP입니다. 양쪽 모두 튜닝합니다.

# /etc/sysctl.d/99-game.conf
# 수신/송신 버퍼 (최소 / 기본 / 최대)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# UDP 수신 버퍼 (대형 게임 패킷에 중요)
net.core.netdev_max_backlog = 5000

# TIME_WAIT 빠르게 재사용
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 동시 연결 백로그
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

# 임시 포트 범위 확장 (클라이언트 연결이 많을 때)
net.ipv4.ip_local_port_range = 10240 65535

sudo sysctl --system

주의: tcp_tw_recycle은 더 이상 권장되지 않으며 NAT 환경에서 문제를 일으킵니다. tcp_tw_reuse만 사용하세요.

4단계 — 혼잡 제어 알고리즘

기본 알고리즘은 cubic이지만, 한국-일본처럼 RTT가 짧은 회선에서는 BBR이 더 좋은 결과를 내는 경우가 많습니다.

# 현재 알고리즘 확인
sysctl net.ipv4.tcp_congestion_control

# 사용 가능한 알고리즘 확인
sysctl net.ipv4.tcp_available_congestion_control

# BBR 활성화
echo "net.core.default_qdisc = fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

BBR은 패킷 손실이 아니라 대역폭과 RTT 측정으로 혼잡을 판단해, 짧은 RTT 환경에서 cubic보다 응답성이 좋습니다.

5단계 — UDP 게임 서버 최적화

대부분의 실시간 게임(FPS, MOBA 등)은 UDP를 사용합니다. UDP 특유의 튜닝 포인트가 있습니다.

# UDP 메모리 풀 (16MB)
sysctl -w net.ipv4.udp_mem="65536 131072 262144"

# UDP 수신 큐 깊이
sysctl -w net.core.netdev_max_backlog=10000

게임 서버 프로세스의 소켓 버퍼 크기도 코드에서 직접 늘려야 합니다.

int size = 4 * 1024 * 1024;  // 4MB
setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));

6단계 — MTU와 패킷 단편화

기본 MTU는 1500입니다. PPPoE 회선이 섞이면 1492로 떨어지며, 단편화가 일어나면 한 패킷의 손실이 두 배 영향을 줍니다.

# MTU 확인
ip link show eth0

# 경로상 단편화가 일어나는지 테스트
ping -c 3 -M do -s 1472 example.com   # 1472 + 28 = 1500

Frag needed가 보이면 경로상 MTU가 1500보다 작은 구간이 있습니다. 게임 서버에서는 페이로드를 1400 이하로 유지하는 것이 안전합니다.

7단계 — DDoS 보호

게임 서버는 일반 사이트보다 DDoS 표적이 되기 쉽습니다. 특히 UDP 서비스는 reflection 공격 발생 시 응답을 못 보내게 됩니다.

# UDP 응답 속도 제한 (서비스 포트 외)
iptables -A INPUT -p udp -m limit --limit 1000/s --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

# SYN Flood 방어
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_synack_retries=2

L3/L4 단의 대형 공격은 호스팅사 네트워크에서 막아야 합니다. TCP-80.NET의 전용서버는 모두 L3/L4 DDoS 방어가 무료 기본 포함이며, 전용 DDoS 보호 서비스로 L7까지 강화할 수 있습니다.

8단계 — 모니터링

지연/손실은 자주 측정해야 의미가 있습니다.

# 실시간 RTT/손실
mtr --report --report-cycles 100 client-ip

# 인터페이스 패킷 통계
ip -s link show eth0

# 드롭 발생 여부
netstat -s | grep -i drop

# softirq 부하 (특정 코어가 100%인지)
mpstat -P ALL 1

지속적인 모니터링은 모니터링 가이드를 참고하세요. Netdata로 NIC 큐별 RX/TX, softirq, CPU 분포까지 한 화면에서 볼 수 있습니다.

마무리

게임 서버 튜닝은 “어느 한 가지 설정으로 모든 게 빨라지는” 마법이 없습니다. 위치 선정 → 인터럽트 분산 → 버퍼/혼잡제어 → DDoS 보호 의 단계를 차례로 점검하면, 같은 하드웨어에서 1~3ms를 줄일 수 있습니다.

TCP-80.NET은 도쿄 IDC 직영으로 한국 회선까지의 경로가 짧고 안정적입니다. 게임 서버용 전용서버 구성에 대한 문의는 @tcp80net으로 부탁드립니다.

k3s가 적합한 경우

k3s는 풀 K8s와 API 호환입니다. kubectl 명령, Deployment YAML 등이 그대로 동작합니다. 차이는 etcd 대신 SQLite를 쓰고, 불필요한 컨트롤러를 제거해 가볍게 만든 점입니다.

1단계 — 사전 준비

일본 서버 1대(Ubuntu 22.04 LTS, 메모리 2GB 이상 권장)를 준비합니다. swap이 켜져 있으면 비활성화해야 합니다.

# swap 비활성화 (k8s 권장)
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

# 커널 모듈 적재
sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl 설정
cat <<EOF | sudo tee /etc/sysctl.d/99-k3s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
sudo sysctl --system

2단계 — k3s 설치

공식 설치 스크립트는 한 줄입니다.

curl -sfL https://get.k3s.io | sh -

설치가 끝나면 자동으로 systemd 서비스가 등록되고 클러스터가 동작합니다.

sudo systemctl status k3s
sudo k3s kubectl get nodes
# NAME       STATUS   ROLES                  AGE   VERSION
# server1    Ready    control-plane,master   30s   v1.30.x+k3s1

kubectl을 root 없이 사용하려면 kubeconfig를 사용자 홈으로 복사합니다.

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config
chmod 600 ~/.kube/config

kubectl get pods -A

3단계 — 기본 컴포넌트

k3s는 다음을 기본으로 포함합니다.

• Traefik — Ingress 컨트롤러 (L7 라우팅, 자동 HTTPS)
• CoreDNS — 클러스터 내부 DNS
• ServiceLB(Klipper) — Service: LoadBalancer 타입 자동 처리
• Local Path Provisioner — PersistentVolumeClaim을 호스트 디렉토리에 매핑
• Metrics Server — kubectl top 동작

별도 설치 없이 첫 배포부터 외부 접근, HTTPS, 영구 볼륨이 모두 가능합니다.

4단계 — 첫 배포 (Nginx 예시)

# nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels: { app: nginx }
  template:
    metadata:
      labels: { app: nginx }
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector: { app: nginx }
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: traefik
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx
                port:
                  number: 80
  tls:
    - hosts: [app.example.com]
      secretName: nginx-tls

kubectl apply -f nginx.yaml
kubectl get ingress

도메인의 A 레코드를 일본 서버 IP로 향하게 하면 https://app.example.com으로 접근 가능합니다.

5단계 — Let’s Encrypt 자동 인증서 (cert-manager)

# Helm 설치
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# cert-manager 설치
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

ClusterIssuer 등록:

# letsencrypt.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

kubectl apply -f letsencrypt.yaml

이후 Ingress의 tls: 섹션과 cert-manager.io/cluster-issuer 어노테이션만 추가하면 인증서가 자동 발급·갱신됩니다.

6단계 — 모니터링과 로그

가벼운 환경에서는 Prometheus 풀스택보다 간단한 도구가 적합합니다.

# 컨테이너 단위 리소스 확인
kubectl top pods -A
kubectl top nodes

# 특정 파드 로그
kubectl logs -f deploy/nginx

# 컨테이너 안으로 진입
kubectl exec -it deploy/nginx -- /bin/sh

운영 모니터링이 필요하다면 k9s라는 TUI 도구가 매우 유용합니다.

curl -sS https://webinstall.dev/k9s | bash
k9s

7단계 — 백업

k3s의 상태는 SQLite 파일 하나에 저장됩니다.

# k3s 정지
sudo systemctl stop k3s

# 백업
sudo cp /var/lib/rancher/k3s/server/db/state.db /backup/k3s-$(date +%F).db

# 시작
sudo systemctl start k3s

자동화된 백업이 필요하면 cron으로 매일 새벽 실행되도록 설정합니다.

운영 시 주의점

• 단일 노드의 한계 — 노드가 죽으면 모든 서비스가 죽습니다. 진짜 HA가 필요하면 노드 3대 + embedded etcd 모드로 구성하세요.
• 로컬 볼륨의 종속성 — Local Path Provisioner는 호스트 디렉토리를 사용하므로, 노드를 옮기면 데이터도 함께 이동시켜야 합니다.
• 메모리 모니터링 — k3s 자체는 가볍지만 그 위에서 도는 워크로드(Java, MySQL 등)가 메모리를 잡아먹습니다. 1GB VPS는 권장하지 않습니다.
• 포트 충돌 — k3s는 6443(API), 10250(kubelet) 포트를 사용합니다. 외부에서 직접 접근할 일이 없다면 방화벽으로 막아두세요.

마무리

k3s는 “쿠버네티스 학습 비용은 그대로 가져가되, 운영 비용은 한 대 분량으로” 줄이고 싶을 때 가장 합리적인 선택입니다. TCP-80.NET의 일본 VPS 4GB 플랜이면 k3s + 웹 + DB + 캐시까지 모두 운영 가능합니다.

설치 중 막히는 부분이 있으면 @tcp80net으로 문의해 주세요. 한국어로 도와드립니다.

IPv6를 도입해야 할 때

다음 중 하나라도 해당된다면 도입을 고려해야 합니다.

• 일본 모바일·가정 사용자 비중이 큰 서비스
• 신규 도메인 등록 시 가능한 표준을 모두 갖추고 싶을 때
• IPv4 주소 추가 발급이 어렵거나 비싼 환경
• 메일 서버 운영 — 일부 메일 서비스(Gmail 등)는 IPv6 발신자에 더 엄격해서 정확한 PTR/SPF 정렬이 필수
• 향후 CDN·외부 SaaS 연동에서 IPv6-only 엔드포인트를 만나는 경우

반대로 IPv4만으로 충분한 사내 서비스, 단순 백엔드라면 굳이 도입할 필요가 없습니다.

1단계 — 서버에 IPv6가 할당되어 있는지 확인

ip -6 addr show
# 또는
ifconfig | grep inet6

IPv6 주소가 보이지 않거나 link-local(fe80::)만 보인다면 호스팅사에 글로벌 IPv6 주소를 요청해야 합니다. TCP-80.NET 서버를 사용 중이라면 텔레그램 @tcp80net으로 IPv6 할당을 요청하면 됩니다.

라우팅 확인:

ip -6 route show
ping6 -c 3 ipv6.google.com

ipv6.google.com 응답이 정상이면 외부 IPv6 통신이 동작하는 상태입니다.

2단계 — 듀얼 스택 구성

대부분의 환경은 IPv4와 IPv6를 동시에 운영하는 듀얼 스택(Dual Stack) 입니다. 서비스별로 어떤 스택을 사용할지 결정합니다.

3단계 — DNS AAAA 레코드 등록

서버의 글로벌 IPv6 주소를 도메인의 AAAA 레코드로 등록합니다.

타입: AAAA
이름: @
값: 2001:db8:1234:5678::10
TTL: 300

www, API 서브도메인 등 외부 노출이 필요한 모든 호스트에 동일하게 등록합니다.

전파 후 외부에서 검증:

dig AAAA example.com +short
# → 2001:db8:1234:5678::10

4단계 — Nginx 듀얼 스택 바인딩

기본 설정은 IPv4만 듣는 경우가 많습니다. 다음 두 줄을 함께 적어 IPv6도 듣게 합니다.

server {
    listen 80;
    listen [::]:80;

    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name example.com www.example.com;
    # ...
}

[::]는 모든 IPv6 인터페이스에서 듣는다는 의미입니다. Apache, Caddy, Traefik도 동일한 개념의 듀얼 바인딩 설정을 지원합니다.

설정 적용 후 확인:

ss -tlnp | grep -E ':(80|443)'
# tcp LISTEN ... 0.0.0.0:80
# tcp LISTEN ... [::]:80

5단계 — 방화벽 규칙

IPv4와 별도로 IPv6 규칙을 설정해야 합니다. iptables는 ip6tables, ufw는 자동으로 양쪽 규칙을 만들어 줍니다.

ufw 사용 시

# /etc/default/ufw 에서 IPV6=yes 인지 확인
sudo grep IPV6 /etc/default/ufw

# 규칙 추가 (ufw가 ip4·ip6 양쪽에 자동 적용)
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

iptables 직접 사용 시

# IPv4
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# IPv6 — 별도로 설정해야 함
ip6tables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# 영구 저장 (Debian/Ubuntu)
apt install iptables-persistent
netfilter-persistent save

nftables 사용 시 (최신 권장)

table inet filter {
    chain input {
        type filter hook input priority 0;
        ct state established,related accept
        iif lo accept
        tcp dport { 22, 80, 443 } accept
        # IPv6 ND/RA는 반드시 허용해야 IPv6 자체가 동작
        icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert, echo-request } accept
        drop
    }
}

중요: IPv6는 ICMPv6 메시지에 의존합니다. NDP(Neighbor Discovery), RA(Router Advertisement) 를 차단하면 IPv6 자체가 동작하지 않습니다. 무작정 ICMP 전체를 막으면 안 됩니다.

6단계 — 메일 서버라면 PTR과 SPF

IPv6로 메일을 발송하면 수신 측은 IPv6 PTR(역방향 DNS) 을 매우 엄격히 봅니다. PTR이 없거나 일치하지 않으면 Gmail은 거의 무조건 차단합니다.

# 발신 서버 IPv6의 PTR 확인
dig -x 2001:db8:1234:5678::10

PTR이 비어 있다면 호스팅사에 등록을 요청해야 합니다(개별 사용자가 직접 설정 불가). SPF 레코드도 IPv6를 포함해야 합니다.

v=spf1 ip4:203.0.113.10 ip6:2001:db8:1234:5678::10 ~all

7단계 — 검증

브라우저로 https://test-ipv6.com 접속해 자신의 환경이 IPv6로 외부에 잘 닿는지 확인합니다. 서버 측 검증은 다음 도구를 사용합니다.

# 외부에서 서버에 IPv6로 접속되는지
curl -6 https://example.com -I

# IPv4와 IPv6 동시에 시도
curl -v https://example.com 2>&1 | grep -E "Trying|Connected"

자주 발생하는 문제

브라우저는 한국이고 사이트 응답이 매우 느려졌다

• 한국 가정 ISP는 IPv6 보급률이 일본보다 낮습니다. AAAA 레코드를 등록했는데 IPv6 경로가 비정상이면 브라우저가 타임아웃 후 IPv4로 폴백하느라 첫 응답이 느려집니다.
• 해결: 서버 측 IPv6가 정상인지 다시 확인하고, 비정상이면 일단 AAAA 레코드를 제거.

일부 사용자만 접속이 안 된다

• 사용자의 IPv6 경로 문제일 가능성이 큽니다. 동일 ISP의 다른 사용자는 정상이라면 사용자 측 라우터 설정 문제로 추정됩니다.

SSH 접속에서 IPv6 주소가 자꾸 사용된다

• ~/.ssh/config에 AddressFamily inet을 명시하거나 ssh -4로 명시 호출하면 IPv4를 강제할 수 있습니다.

마무리

IPv6는 거창한 기술이 아니라 “한 줄짜리 추가 설정의 모음”입니다. AAAA 레코드 한 줄, listen [::]: 한 줄, ip6tables 규칙 몇 줄로 시작할 수 있습니다.

TCP-80.NET의 일본 전용서버와 VPS는 요청 시 IPv6 주소를 발급해 드립니다. PTR 등록도 함께 지원하니 메일 서버 운영 계획이 있다면 @tcp80net으로 미리 알려주세요.

전체 그림

배포 단계는 4가지입니다.

1. 개발자가 main 브랜치에 push
2. GitHub Actions가 빌드 및 테스트
3. SSH로 일본 서버에 접속해 새 코드 동기화
4. 서비스 재시작 (systemctl 또는 docker)

각 단계를 하나씩 살펴보겠습니다.

1단계 — 서버에 배포 전용 사용자 만들기

root로 직접 배포하면 사고 위험이 큽니다. 권한이 제한된 deploy 사용자를 따로 만듭니다.

# 일본 서버에서 실행
sudo adduser --disabled-password --gecos "" deploy
sudo mkdir -p /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chown -R deploy:deploy /home/deploy/.ssh

# 애플리케이션 디렉토리 권한 부여
sudo mkdir -p /var/www/myapp
sudo chown -R deploy:deploy /var/www/myapp

# systemctl restart 권한만 sudo 없이 허용
echo 'deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp' | sudo tee /etc/sudoers.d/deploy

NOPASSWD로 허용하는 명령은 딱 필요한 것만 명시해야 합니다. ALL을 주면 사실상 root입니다.

2단계 — SSH 키 페어 생성

로컬 PC에서 배포 전용 키를 만듭니다. 평소 개인 키와 분리하는 것이 좋습니다.

ssh-keygen -t ed25519 -f ~/.ssh/deploy_key -N "" -C "github-actions-deploy"

생성된 공개키를 일본 서버의 deploy 사용자에게 등록합니다.

# 로컬에서 일본 서버로 전송
ssh-copy-id -i ~/.ssh/deploy_key.pub deploy@your-server-ip

# 또는 수동으로
cat ~/.ssh/deploy_key.pub | ssh root@your-server-ip "cat >> /home/deploy/.ssh/authorized_keys && chown deploy:deploy /home/deploy/.ssh/authorized_keys && chmod 600 /home/deploy/.ssh/authorized_keys"

연결 테스트:

ssh -i ~/.ssh/deploy_key deploy@your-server-ip "whoami && pwd"
# → deploy
# → /home/deploy

3단계 — GitHub Repository Secrets 등록

GitHub 저장소 → Settings → Secrets and variables → Actions에서 다음 시크릿을 등록합니다.

SSH_PRIVATE_KEY는 cat ~/.ssh/deploy_key 결과를 그대로 복사해서 붙여넣습니다. -----BEGIN OPENSSH PRIVATE KEY----- 부터 -----END OPENSSH PRIVATE KEY----- 까지 모두 포함해야 합니다.

4단계 — GitHub Actions 워크플로

.github/workflows/deploy.yml 파일을 생성합니다. 아래는 Node.js 앱 기준 예시입니다.

name: Deploy to Japan Server

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install & build
        run: |
          npm ci
          npm run build
          npm test

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: $
          username: $
          key: $
          port: $
          script: |
            cd /var/www/myapp
            git fetch origin main
            git reset --hard origin/main
            npm ci --production
            sudo systemctl restart myapp

PHP/Python/Go도 빌드 단계만 바꾸면 동일한 구조로 적용 가능합니다.

5단계 — 정적 사이트(Jekyll, Hugo, Next 빌드 결과)인 경우

빌드 결과물을 서버로 전송하는 형태가 더 깔끔합니다. rsync를 사용합니다.

      - name: Build site
        run: |
          bundle install
          bundle exec jekyll build

      - name: Setup SSH key
        run: |
          mkdir -p ~/.ssh
          echo "$" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          ssh-keyscan -p $ $ >> ~/.ssh/known_hosts

      - name: Rsync to server
        run: |
          rsync -avz --delete -e "ssh -i ~/.ssh/deploy_key -p $" \
            _site/ $@$:/var/www/myapp/

--delete 옵션은 서버 쪽 불필요 파일을 제거하므로 의도하지 않은 파일이 남는 일을 막습니다.

6단계 — Docker 사용 시

이미지를 GitHub Container Registry에 올리고, 서버에서 pull → restart 하는 방식이 일반적입니다.

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: $
          password: $

      - name: Build & push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/$:latest

      - name: Deploy
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: $
          username: $
          key: $
          script: |
            cd /opt/myapp
            docker compose pull
            docker compose up -d
            docker image prune -f

docker compose up -d는 변경된 컨테이너만 재생성하므로 다른 서비스에는 영향이 없습니다.

보안 체크리스트

배포 자동화는 잘못 만들면 자동 해킹 도구가 됩니다. 반드시 확인하세요.

• deploy 사용자에게 비밀번호 로그인 차단 (PasswordAuthentication no)
• deploy 사용자의 sudo 권한은 재시작 명령으로만 제한
• SSH 포트는 22 외 다른 포트로 변경 (자동화 도구의 무차별 공격 회피)
• authorized_keys에는 GitHub Actions용 키 외 다른 키 없음
• 워크플로 파일에 직접 IP/비밀번호를 적지 말고 항상 Secrets 사용
• pull_request 트리거에는 secrets가 노출될 수 있으므로 신중히 사용

흔한 트러블슈팅

Permission denied (publickey)

• 서버의 /home/deploy/.ssh/authorized_keys 권한이 600인지, 디렉토리는 700인지 확인
• 등록한 시크릿이 공개키가 아닌 개인키인지 확인 (실수가 매우 잦습니다)

Host key verification failed

• ssh-keyscan 단계가 누락되었거나, 서버가 호스트 키를 변경했을 때
• appleboy/ssh-action 사용 시 자동 처리되지만, 직접 ssh 호출 시에는 명시 필요

빌드는 성공했는데 서버에서 옛날 버전이 도는 경우

• git pull이 충돌로 실패한 채 무시되었을 가능성
• git reset --hard origin/main으로 강제 동기화하거나, 빌드 결과를 rsync하는 방식으로 전환

마무리

자동 배포의 본질은 “에러는 자동화하지 않고, 안전한 동작만 자동화”입니다. 테스트 단계를 충실히 두면 잘못된 코드가 일본 서버에 닿기 전에 차단할 수 있습니다.

TCP-80.NET의 일본 VPS는 SSH 포트 변경, 방화벽 설정 등에 대해 텔레그램으로 한국어 안내를 제공합니다. CI/CD 환경 구성 중 문의가 있으시면 @tcp80net으로 부담 없이 문의해 주세요.

왜 일본 서버 + Cloudflare 조합인가

특히 오리진 IP 은폐는 보안상 큰 차이를 만듭니다. 공격자가 IP를 특정하지 못하면 직접 공격이 불가능해지기 때문입니다.

1단계 — 도메인을 Cloudflare에 추가

1. https://dash.cloudflare.com 가입 후 Add a Site 선택
2. 도메인 입력 → 무료 플랜 선택
3. Cloudflare가 기존 DNS 레코드를 자동으로 가져옵니다

기존 레코드가 누락되거나 잘못 가져온 경우 직접 추가해야 합니다. 특히 메일 관련 MX, SPF(TXT) 레코드는 누락되기 쉽습니다.

2단계 — 네임서버 변경

도메인 등록업체(가비아, Whois, 일본 Onamae 등)에서 네임서버를 Cloudflare가 안내한 두 개로 변경합니다.

예시:
  ada.ns.cloudflare.com
  ben.ns.cloudflare.com

전파에는 보통 수 분에서 24시간이 걸립니다. Cloudflare 대시보드의 Overview 탭에서 활성화 여부를 확인할 수 있습니다.

3단계 — A 레코드와 프록시 설정

A 레코드는 일본 서버 IP를 가리키게 하되, 주황색 구름(프록시 ON) 으로 설정합니다.

타입: A
이름: @
값: 203.0.113.10  (일본 서버 IP)
프록시 상태: 프록시됨 (Proxied) — 주황 구름

• 회색 구름(DNS only): 사용자는 서버 IP를 직접 알게 됨 → 공격에 노출
• 주황 구름(Proxied): 사용자는 Cloudflare IP만 봄 → 오리진 IP 은폐

www 서브도메인도 동일하게 설정하거나 CNAME으로 루트를 가리키게 합니다.

4단계 — SSL/TLS 모드

Cloudflare 대시보드 → SSL/TLS → Overview에서 모드를 선택합니다.

Full (strict) 모드를 사용하려면 오리진 서버에 유효한 인증서가 있어야 합니다. Let’s Encrypt를 그대로 써도 되고, Cloudflare가 무료로 제공하는 Origin Certificate(15년 유효)를 사용하는 것이 편합니다.

5단계 — 오리진 보호 (가장 중요)

Cloudflare 프록시를 설정해도 누군가 과거 IP를 알고 있다면 직접 공격이 가능합니다. 서버 방화벽에서 Cloudflare IP만 허용해야 진정한 보호가 됩니다.

# Cloudflare가 게시하는 IP 목록 (최신본은 cloudflare.com/ips 참조)
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)

# 80, 443 포트는 Cloudflare IP만 허용
for ip in $CF_IPS; do
  iptables -A INPUT -p tcp -m multiport --dports 80,443 -s $ip -j ACCEPT
done

# 그 외 직접 접근은 차단
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP

ufw를 사용하는 경우:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow from $ip to any port 80,443 proto tcp
done

Nginx에서 실제 클라이언트 IP를 로그에 남기려면 real_ip 모듈을 설정합니다.

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... (Cloudflare IP 전체 목록을 추가)
real_ip_header CF-Connecting-IP;

6단계 — 캐시 정책

기본 설정에서도 정적 자산(이미지, CSS, JS)은 캐시되지만, HTML까지 캐시하려면 Page Rules 또는 Cache Rules를 추가합니다.

Cache Rules 예시:
  Hostname equals example.com
  → Cache Level: Cache Everything
  → Edge TTL: 2 hours
  → Browser TTL: 4 hours

WordPress 같은 동적 사이트는 로그인 사용자에게 캐시된 페이지가 보이지 않도록 다음 쿠키를 Bypass Cache 조건으로 추가합니다.

wp-.*
wordpress_logged_in_.*
comment_author_.*

7단계 — WAF / Bot 차단

Security → WAF → Custom Rules에서 패턴 기반 차단 규칙을 만들 수 있습니다.

규칙 예시:
  - User-Agent에 "sqlmap" 또는 "nikto" 포함 → Block
  - Country가 특정 국가가 아니면서 /wp-login.php 접근 → Challenge
  - 분당 100회 이상 동일 IP 요청 → Rate limit

Bot Fight Mode를 켜면 알려진 악성 봇과 데이터센터 IP를 자동으로 차단합니다(무료 플랜에서 사용 가능).

흔히 빠지는 함정

1. MX 레코드를 프록시하지 않기 — 메일 관련 레코드(MX, mail.도메인)는 회색 구름(DNS only)으로 두어야 합니다. 프록시할 수 없는 프로토콜입니다.
2. DNS 전파 전 강제 HTTPS 켜기 — Full (strict)로 켜둔 상태에서 오리진에 인증서가 없으면 에러 526이 발생합니다. 먼저 인증서 설치 → 모드 변경 순으로 진행하세요.
3. 오리진 IP 누출 — Cloudflare 적용 후에도 메일 서버, FTP, cPanel 등이 직접 같은 IP를 사용하면 IP가 알려집니다. 메일 발송은 별도 IP에서 하거나 외부 SMTP를 쓰는 것이 안전합니다.
4. 개발 모드 켜둔 채 방치 — Cloudflare의 “Development Mode”는 캐시를 끄는 임시 옵션입니다. 3시간 후 자동 해제되지만, 의도치 않게 켜둔 채 광고를 돌리면 캐시 효과가 사라집니다.

마무리

Cloudflare는 일본 서버의 약점인 글로벌 응답 속도를 보완하면서, 동시에 오리진 보호와 L7 방어까지 무료로 제공합니다. 오리진 방화벽 → Cloudflare IP 허용 리스트 설정은 반드시 함께 적용해야 효과를 볼 수 있습니다.

TCP-80.NET의 일본 VPS와 전용서버는 모두 L3/L4 네트워크 단 DDoS 방어가 기본 포함되므로, Cloudflare와 결합하면 L3~L7 전 계층 방어를 갖출 수 있습니다.

다계층 방어 구조

DDoS 방어는 한 가지 기술로 해결되지 않습니다. 공격 트래픽이 서버에 도달하기까지 여러 계층을 거치면서 단계적으로 걸러지는 다계층(Multi-layer) 방어 구조가 핵심입니다.

각 단계를 통과할 때마다 공격 트래픽이 제거되어, 최종적으로 서버에는 정상 트래픽만 도달합니다.

1단계 — ISP / 상위 네트워크 방어

서버가 위치한 데이터센터의 상위 네트워크(ISP)에서 수행하는 방어입니다. 대용량 트래픽 공격을 가장 먼저 걸러냅니다.

BGP Blackhole Routing

공격이 감지되면 해당 IP로 향하는 트래픽을 네트워크 경계에서 모두 폐기(Blackhole) 하는 방식입니다.

정상적인 라우팅:
  인터넷 → ISP → 데이터센터 → 서버 (공격 트래픽도 함께 도달)

BGP Blackhole 적용 후:
  인터넷 → ISP → /dev/null (트래픽 전체 폐기)

• 장점: 수백 Gbps 공격도 즉시 차단 가능
• 단점: 정상 트래픽도 함께 차단됨 — 서비스 중단과 같은 효과
• 용도: 공격 규모가 너무 커서 다른 방어가 불가능할 때 최후의 수단

BGP Flowspec

Blackhole보다 정밀한 방식입니다. 특정 프로토콜, 포트, 패킷 크기 등을 기준으로 필터링 규칙을 동적으로 배포합니다.

예시 Flowspec 규칙:
  목적지: 203.0.113.10
  프로토콜: UDP
  포트: != 53 (DNS 제외)
  동작: DROP

→ 해당 IP로 오는 UDP 트래픽 중 DNS 외 전부 차단
→ 정상적인 DNS 응답은 통과

ACL 기반 필터링

라우터/스위치 레벨에서 출발지 IP, 프로토콜, 포트 기반으로 패킷을 차단합니다.

# 일반적인 ACL 필터 예시 (Cisco IOS 형식)
access-list 101 deny udp any host 203.0.113.10 eq 80
access-list 101 deny icmp any any echo
access-list 101 permit ip any any

2단계 — 스크러빙 센터

DDoS 방어의 핵심 기술입니다. 공격 트래픽과 정상 트래픽을 분리(Scrubbing) 하여, 정상 트래픽만 오리진 서버로 전달합니다.

동작 과정

1) 트래픽 우회(Diversion)

공격이 감지되면 서버로 향하는 트래픽을 스크러빙 센터로 우회시킵니다.

평상시:
  사용자 → ISP → 데이터센터 → 서버

공격 감지 시:
  사용자 → ISP → [스크러빙 센터] → 데이터센터 → 서버

우회 방법은 크게 두 가지입니다:

• BGP 경로 변경: 서버 IP의 라우팅 경로를 스크러빙 센터로 변경
• DNS 변경: 도메인이 스크러빙 센터의 IP를 가리키도록 변경 (프록시 방식)

2) 심층 패킷 분석(DPI)

스크러빙 센터에 도착한 트래픽은 패킷 단위로 정밀 분석됩니다.

분석 항목:
├── 프로토콜 유효성 — TCP 핸드셰이크가 정상적인가?
├── 페이로드 패턴 — 알려진 공격 시그니처와 일치하는가?
├── 통계적 이상 — 평소 대비 트래픽 패턴이 비정상인가?
├── IP 평판 — 이 IP가 봇넷에 속한 것으로 알려져 있는가?
└── 행위 분석 — 실제 브라우저/클라이언트 행위와 일치하는가?

3) 필터링 및 전달(Injection)

분석 결과에 따라 악성 트래픽은 폐기하고, 정상 트래픽만 GRE 터널이나 직접 연결을 통해 오리진 서버로 전달합니다.

3단계 — 서버 레벨 방어

상위 단계에서 대부분의 공격이 걸러지지만, 서버 자체에서도 추가 방어를 설정해야 합니다. 특히 L7(애플리케이션) 공격은 정상 요청과 구분이 어려워 서버 레벨 방어가 중요합니다.

SYN Cookie — SYN Flood 방어의 핵심

SYN Flood는 TCP 3-way 핸드셰이크를 악용한 공격입니다. 공격자가 대량의 SYN 패킷을 보내고 ACK를 보내지 않으면, 서버의 연결 테이블이 가득 차서 정상 접속이 불가능해집니다.

SYN Cookie의 원리:

일반적인 TCP 핸드셰이크:
  클라이언트 → SYN → 서버 (서버가 연결 정보를 메모리에 저장)
  서버 → SYN-ACK → 클라이언트
  클라이언트 → ACK → 서버 (연결 성립)

SYN Cookie 적용 시:
  클라이언트 → SYN → 서버 (메모리에 저장하지 않음!)
  서버 → SYN-ACK → 클라이언트
    └→ 시퀀스 번호에 연결 정보를 암호화하여 포함 (= Cookie)
  클라이언트 → ACK → 서버
    └→ 서버가 ACK의 시퀀스 번호에서 연결 정보를 복원
    └→ 정상 ACK가 돌아온 경우에만 연결 성립

핵심은 ACK가 돌아올 때까지 서버 메모리를 전혀 사용하지 않는다는 것입니다. 공격자가 아무리 많은 SYN을 보내도 메모리가 고갈되지 않습니다.

# Linux에서 SYN Cookie 활성화
sysctl -w net.ipv4.tcp_syncookies=1

# 영구 적용
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

Connection Tracking 제한

Linux의 conntrack은 모든 네트워크 연결을 추적합니다. DDoS 공격 시 이 테이블이 가득 차면 정상 연결도 거부됩니다.

# 현재 conntrack 사용량 확인
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# 최대값 상향 (메모리에 여유가 있을 때)
sysctl -w net.netfilter.nf_conntrack_max=1048576

# 연결 추적 타임아웃 단축
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

iptables Rate Limiting

동일 IP에서 과도한 요청을 보내는 경우 iptables로 제한할 수 있습니다.

# 동일 IP에서 초당 새 연결 20개 제한
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 20/s --limit-burst 40 -j ACCEPT

# 비정상 패킷 차단
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Nginx Rate Limiting

L7 공격에 대한 방어입니다. 동일 IP에서 과도한 HTTP 요청을 제한합니다.

# /etc/nginx/nginx.conf
http {
    # 요청 속도 제한 존 정의 (IP당 초당 10요청)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

    # 연결 수 제한 존 정의 (IP당 동시 연결 20개)
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    server {
        # 요청 속도 제한 적용 (burst 허용 20개, 초과 시 지연 없이 거부)
        limit_req zone=req_limit burst=20 nodelay;

        # 동시 연결 수 제한
        limit_conn conn_limit 20;

        # 요청 본문 크기 제한 (Slowloris 변형 방어)
        client_body_timeout 10s;
        client_header_timeout 10s;
        client_max_body_size 1m;
    }
}

BGP Anycast — 대규모 방어의 핵심 인프라

전 세계에 분산된 여러 지점에서 동일한 IP 주소를 광고하여, 사용자(또는 공격자)의 트래픽이 가장 가까운 지점으로 자동 라우팅되게 하는 기술입니다.

Anycast 없이:
  모든 공격 트래픽 → 서버 1대로 집중 → 대역폭 초과 → 서비스 다운

Anycast 적용:
  공격 트래픽 → 전 세계 PoP(Point of Presence)으로 분산
  ├→ 도쿄 PoP: 30Gbps 처리
  ├→ 싱가포르 PoP: 25Gbps 처리
  ├→ LA PoP: 20Gbps 처리
  └→ 프랑크푸르트 PoP: 25Gbps 처리
  총 100Gbps 공격이 4곳으로 분산 → 각 지점에서 처리 가능

Cloudflare, Akamai 같은 대형 DDoS 방어 업체가 수십 Tbps 규모의 공격을 방어할 수 있는 이유가 바로 이 Anycast 네트워크 덕분입니다.

L7 방어 — 봇과 사람을 구분하는 원리

L3/L4 공격은 패킷 수준에서 비교적 쉽게 구분할 수 있지만, L7 공격은 정상적인 HTTP 요청과 동일한 형태를 띠기 때문에 구분이 어렵습니다.

JavaScript Challenge

사용자의 브라우저에 JavaScript를 실행시켜, 실제 브라우저인지 확인합니다.

1. 서버가 JavaScript 챌린지 페이지 응답
2. 정상 브라우저: JS 실행 → 계산 결과 전송 → 통과
3. 봇/스크립트: JS 실행 불가 → 차단

행위 기반 분석 (Behavioral Analysis)

정상 사용자와 봇의 행동 패턴 차이를 분석합니다.

Rate Limiting + IP 평판

• 동일 IP에서 비정상적으로 많은 요청 → 속도 제한 후 차단
• 알려진 봇넷 IP, TOR 출구 노드, 데이터센터 IP 등을 평판 DB로 관리
• 평판이 낮은 IP에 더 강한 검증 적용

방어 방식 비교 요약

마무리

DDoS 방어의 핵심은 단일 솔루션이 아닌 다계층 구조에 있습니다. 상위 네트워크에서 대용량 공격을 흡수하고, 스크러빙 센터에서 정밀 필터링하며, 서버 레벨에서 잔여 공격을 처리하는 구조가 효과적입니다.

직접 모든 방어를 구축하기보다는, 네트워크 단 방어가 기본 제공되는 호스팅을 선택하는 것이 현실적입니다. TCP-80.NET은 모든 서버에 L3/L4 네트워크 공격 차단을 기본 무료 제공하며, L7 공격 방어가 필요한 경우 전용 DDoS 방어 서비스를 추가할 수 있습니다.

1. 메모리 부족으로 인한 성능 저하

데이터베이스 성능 문제의 가장 흔한 원인은 메모리 부족입니다. 특히 InnoDB의 Buffer Pool 크기가 부족하면 디스크 I/O가 급증하면서 전체 쿼리 속도가 느려집니다.

증상

• 쿼리 응답 시간이 점점 길어짐
• iostat에서 디스크 사용률 90% 이상
• free -h에서 available 메모리가 거의 없음
• OOM Killer가 DB 프로세스를 강제 종료

해결 방법

# 현재 Buffer Pool 크기 확인
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

# 전체 메모리의 60~70%를 Buffer Pool에 할당 (예: 8GB 서버)
# /etc/mysql/mysql.conf.d/mysqld.cnf 에 추가
innodb_buffer_pool_size = 5G
innodb_buffer_pool_instances = 4

# OOM Killer 방지 — DB 프로세스 우선순위 조정
echo -17 > /proc/$(pidof mysqld)/oom_adj

핵심 포인트: 서버 메모리가 4GB 이하라면 데이터베이스 전용 서버로 쓰기엔 부족합니다. 최소 8GB 이상을 권장합니다.

2. 디스크 I/O 병목

HDD를 사용하는 서버에서 데이터베이스를 운영하면 랜덤 읽기/쓰기 성능이 심각하게 떨어집니다. 특히 트래픽이 몰리는 시간대에 쿼리 지연이 발생합니다.

진단 방법

# 디스크 I/O 상태 확인
iostat -xz 1 5

# 주요 지표:
# %util — 90% 이상이면 병목
# await — 10ms 이상이면 지연 발생 중
# r/s, w/s — 초당 읽기/쓰기 횟수

# MySQL의 I/O 대기 상태 확인
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A 5 "FILE I/O"

# 어떤 프로세스가 I/O를 많이 쓰는지 확인
iotop -oP

해결 방법

• NVMe SSD로 교체 — 가장 효과적 (IOPS 100배 이상 향상)
• innodb_flush_method = O_DIRECT 설정으로 OS 캐시 이중화 방지
• innodb_io_capacity, innodb_io_capacity_max 값을 SSD에 맞게 상향

# SSD 환경에 맞는 I/O 설정
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

3. 슬로우 쿼리 누적

운영 초기에는 빨랐던 쿼리가 데이터가 쌓이면서 점점 느려지는 것은 매우 흔한 문제입니다. 인덱스 누락, 불필요한 풀 테이블 스캔이 주요 원인입니다.

슬로우 쿼리 로그 활성화

# /etc/mysql/mysql.conf.d/mysqld.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

분석 및 최적화

# 슬로우 쿼리 요약 (상위 10개)
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 특정 쿼리의 실행 계획 확인
mysql -e "EXPLAIN SELECT * FROM orders WHERE user_id = 12345;"

# 인덱스 추가
mysql -e "ALTER TABLE orders ADD INDEX idx_user_id (user_id);"

# 현재 실행 중인 쿼리 확인
mysql -e "SHOW FULL PROCESSLIST;"

주의: 인덱스를 무작정 추가하면 INSERT/UPDATE 성능이 저하됩니다. EXPLAIN 결과를 확인한 뒤 필요한 인덱스만 추가하세요.

4. 커넥션 폭주 및 max_connections 초과

트래픽이 급증하거나 애플리케이션에서 커넥션을 제대로 반환하지 않으면 DB 접속이 거부됩니다.

증상

ERROR 1040 (HY000): Too many connections

진단

# 현재 커넥션 수 확인
mysql -e "SHOW STATUS LIKE 'Threads_connected';"

# 최대 커넥션 설정 확인
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# 어떤 호스트에서 많이 접속하는지 확인
mysql -e "SELECT host, COUNT(*) as cnt FROM information_schema.processlist GROUP BY host ORDER BY cnt DESC;"

해결 방법

# max_connections 상향 (기본값 151은 대부분 부족)
max_connections = 500
wait_timeout = 300
interactive_timeout = 300

근본 해결: 애플리케이션에서 커넥션 풀을 사용하세요. PHP는 pdo_mysql의 persistent connection, Node.js는 mysql2의 Pool, Python은 SQLAlchemy의 QueuePool 등을 활용합니다.

5. Lock 경합과 Deadlock

동시에 여러 트랜잭션이 같은 데이터를 수정하려 할 때 Lock 경합이 발생합니다. 심하면 Deadlock으로 트랜잭션이 강제 롤백됩니다.

진단

# InnoDB Lock 대기 상태 확인
mysql -e "SELECT * FROM information_schema.innodb_lock_waits\G"

# 최근 Deadlock 정보
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A 30 "LATEST DETECTED DEADLOCK"

# Lock 대기 중인 쿼리 목록
mysql -e "SELECT * FROM sys.innodb_lock_waits\G"

해결 방법

• 트랜잭션 범위를 최소화 — 필요한 쿼리만 트랜잭션 안에
• UPDATE/DELETE 시 인덱스를 반드시 사용 (인덱스 없으면 테이블 전체 Lock)
• 여러 테이블을 수정할 때 항상 같은 순서로 접근
• innodb_lock_wait_timeout 값 조정 (기본 50초)

6. 백업 실패 및 복구 불가

“백업이 있다”와 “복구 가능한 백업이 있다”는 완전히 다릅니다. 실제로 복구를 시도하면 실패하는 경우가 많습니다.

mysqldump 백업 (소규모 DB)

# 전체 데이터베이스 백업
mysqldump --all-databases --single-transaction --routines --triggers \
  --quick --lock-tables=false > /backup/full_$(date +%Y%m%d_%H%M%S).sql

# 특정 DB만 백업
mysqldump --single-transaction mydb > /backup/mydb_$(date +%Y%m%d).sql

# gzip 압축 백업
mysqldump --single-transaction mydb | gzip > /backup/mydb_$(date +%Y%m%d).sql.gz

xtrabackup (대규모 DB, 무중단 백업)

# Percona XtraBackup 전체 백업
xtrabackup --backup --target-dir=/backup/full/

# 증분 백업
xtrabackup --backup --target-dir=/backup/inc1/ \
  --incremental-basedir=/backup/full/

# 복구 준비
xtrabackup --prepare --target-dir=/backup/full/

자동 백업 cron 설정

# /etc/cron.d/db-backup
# 매일 새벽 3시 전체 백업
0 3 * * * root mysqldump --all-databases --single-transaction | gzip > /backup/daily_$(date +\%Y\%m\%d).sql.gz

# 30일 이상 된 백업 자동 삭제
0 4 * * * root find /backup/ -name "*.sql.gz" -mtime +30 -delete

반드시 확인: 백업 후 정기적으로 복구 테스트를 실행하세요. 복구되지 않는 백업은 없는 것과 같습니다.

7. 보안 취약점

리눅스에서 직접 DB를 운영하면 보안 설정도 직접 해야 합니다. 기본 설정 그대로 두면 외부에서 침투당할 수 있습니다.

필수 보안 설정

# MySQL 보안 초기 설정 (설치 직후 실행)
mysql_secure_installation

# 외부 접속 차단 — bind-address 설정
# /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1

# 불필요한 원격 접속 계정 제거
mysql -e "SELECT user, host FROM mysql.user WHERE host != 'localhost';"
mysql -e "DROP USER 'root'@'%';"

# 방화벽으로 3306 포트 차단
ufw deny 3306

권한 최소화 원칙

-- 애플리케이션용 계정은 필요한 권한만 부여
CREATE USER 'webapp'@'localhost' IDENTIFIED BY 'strong_password_here';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'webapp'@'localhost';

-- SUPER, FILE, PROCESS 권한은 절대 애플리케이션에 부여하지 말 것
-- 관리 작업용 별도 계정 사용

8. 복제(Replication) 지연 및 장애

Master-Slave 구조에서 복제 지연이 발생하면 읽기 분산의 의미가 없어지고, 데이터 불일치 문제가 생깁니다.

복제 상태 확인

# Slave 서버에서 복제 상태 확인
mysql -e "SHOW SLAVE STATUS\G" | grep -E "Seconds_Behind|Running|Error"

# 핵심 확인 항목:
# Slave_IO_Running: Yes
# Slave_SQL_Running: Yes
# Seconds_Behind_Master: 0 (지연 없음)

복제 지연 해결

# Slave 서버 성능 튜닝
slave_parallel_workers = 4
slave_parallel_type = LOGICAL_CLOCK
slave_preserve_commit_order = 1

# Binary Log 포맷 설정 (ROW 권장)
binlog_format = ROW

9. 디스크 용량 부족

데이터베이스 파일, 바이너리 로그, 슬로우 쿼리 로그 등이 디스크를 꽉 채우면 DB가 갑자기 멈출 수 있습니다.

모니터링

# 디스크 사용량 확인
df -h /var/lib/mysql/

# MySQL 데이터 디렉토리 크기
du -sh /var/lib/mysql/

# 데이터베이스별 용량 확인
mysql -e "SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)' FROM information_schema.tables GROUP BY table_schema ORDER BY SUM(data_length + index_length) DESC;"

# 바이너리 로그 크기 확인
mysql -e "SHOW BINARY LOGS;"

해결 방법

# 오래된 바이너리 로그 삭제
mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"

# 자동 삭제 설정
# /etc/mysql/mysql.conf.d/mysqld.cnf
expire_logs_days = 7
# MySQL 8.0+
binlog_expire_logs_seconds = 604800

10. 업그레이드 및 마이그레이션 문제

MySQL 5.7에서 8.0으로, 또는 MariaDB로 전환할 때 호환성 문제가 발생할 수 있습니다.

업그레이드 전 체크리스트

# MySQL 업그레이드 체커 실행
mysqlcheck --all-databases --check-upgrade

# MySQL 8.0 업그레이드 체커
mysql_upgrade_checker

# 현재 사용 중인 deprecated 기능 확인
mysql -e "SHOW WARNINGS;" 2>&1 | grep -i deprecated

# 현재 버전 확인
mysql -V

안전한 마이그레이션 순서

1. 백업 — 반드시 풀 백업 후 복구 테스트까지 완료
2. 스테이징 테스트 — 동일 환경에서 먼저 업그레이드 테스트
3. 호환성 확인 — 쿼리 문법, 기본값 변경사항 확인
4. 점검 시간 확보 — 충분한 유지보수 시간 확보 후 진행
5. 롤백 계획 — 실패 시 원복 절차 준비

마무리 — 안정적인 DB 운영을 위한 핵심 원칙

리눅스 서버에서 데이터베이스를 안정적으로 운영하려면 지속적인 모니터링과 선제적 대응이 필수입니다. 문제가 발생한 뒤 대응하는 것보다, 미리 감지하고 예방하는 것이 훨씬 효과적입니다.

서버 환경에 맞는 최적의 DB 구성이 필요하시면 TCP-80.NET에 문의해 주세요. NVMe SSD 기반의 일본 서버에서 안정적인 데이터베이스 운영을 지원합니다.

서비스 기본 질문

Q. 일본 서버와 한국 서버, 무엇이 다른가요?

일본 서버는 물리적으로 일본 도쿄 데이터센터에 위치한 서버입니다. 한국과의 지리적 거리가 가까워 왕복 지연(RTT)이 20~40ms 수준입니다. 일본 IP 주소를 가지므로 일본 현지 서비스 이용, 일본 대상 웹 서비스 운영에 유리합니다.

Q. 전용서버와 VPS의 차이가 무엇인가요?

• VPS: 물리 서버를 가상화로 나눠 여러 사용자가 공유. 가격이 저렴하고 소규모 서비스에 적합
• 전용서버: 물리 서버 전체를 혼자 사용. 높은 성능, 안정성, 보안이 필요한 서비스에 적합

자세한 비교는 전용서버 vs VPS 비교 글을 참고하세요.

Q. 서버 개설 후 얼마나 빨리 이용할 수 있나요?

• VPS: 결제 확인 후 당일 ~ 익일 내 개설
• 전용서버: 결제 확인 후 1~2 영업일 내 개설 (하드웨어 준비 시간 필요)
• 가상 데스크톱: 결제 확인 후 당일 내 개설

Q. 어떤 OS를 선택할 수 있나요?

Linux 계열:

• Ubuntu 22.04 LTS, 20.04 LTS
• Debian 12, 11
• CentOS 7 (지원 종료, 비권장)

Windows 계열:

• Windows Server 2019
• Windows Server 2022

원하는 OS가 있으면 텔레그램으로 문의해 주세요.

가격 및 결제 질문

Q. 일본 VPS 가격이 어떻게 되나요?

TCP-80.NET 일본 VPS는 월 ₩100,000부터 시작하며, 4개 플랜을 제공합니다. 전용서버는 월 ₩300,000부터 5개 플랜이 있습니다.

Q. 결제 방법은 무엇을 지원하나요?

텔레그램 @tcp80net으로 문의하시면 결제 방법을 안내해 드립니다.

Q. 환불은 가능한가요?

서비스 시작일로부터 7일 이내에 취소 요청 시 전액 환불이 가능합니다. 자세한 내용은 환불 정책을 확인해 주세요.

기술적인 질문

Q. 서버에 root 권한이 제공되나요?

네, 전용서버와 VPS 모두 root 권한이 기본 제공됩니다. 서버를 완전히 자유롭게 관리할 수 있습니다.

Q. 관리형 서비스(OS 설치 지원 등)를 제공하나요?

TCP-80.NET은 OS 설치와 기본 설정에 대한 한국어 기술 지원을 텔레그램으로 제공합니다. 기본 서버 설정, Nginx·Apache 설치, 방화벽 설정 등을 지원합니다.

Q. 대역폭 한도가 있나요?

기본 제공되는 네트워크 포트와 트래픽 정책에 대한 자세한 내용은 텔레그램으로 문의해 주세요.

Q. 서버 재부팅은 직접 할 수 있나요?

• VPS: 텔레그램 요청으로 재부팅 지원
• 전용서버: IPMI를 통해 직접 원격 재부팅 가능

보안 질문

Q. DDoS 방어가 포함되어 있나요?

네, 모든 서버에 네트워크 레이어(L3/L4) DDoS 방어가 무료로 기본 포함됩니다. 더 강력한 보호가 필요하다면 전용 DDoS 방어 서비스를 별도로 이용할 수 있습니다.

Q. 서버가 해킹당했을 때 지원해 주나요?

TCP-80.NET의 해킹 방지 보안 서비스를 이용하시면 전문적인 보안 대응을 받을 수 있습니다. 기본 서버는 고객이 직접 관리하며, 보안 설정에 대한 일반적인 안내는 텔레그램으로 제공합니다.

Q. 일본 법률상 문제가 되는 서비스에는 사용할 수 없나요?

불법 콘텐츠 배포, 스팸, 해킹 등 일본 또는 국제 법률에 위반되는 서비스는 이용 약관에 따라 서비스가 즉시 해지됩니다.

기타 질문

Q. 한국어 지원이 가능한가요?

네, TCP-80.NET은 텔레그램 @tcp80net을 통해 24시간 365일 한국어 지원을 제공합니다.

Q. 서버 위치를 변경할 수 있나요?

현재 TCP-80.NET은 일본 도쿄 데이터센터를 운영합니다. 다른 위치로의 이전은 지원하지 않습니다.

Q. 장기 계약 할인이 있나요?

장기 계약 또는 다수 서버 이용 시 할인에 대한 문의는 텔레그램으로 주세요. 상황에 따라 협의가 가능합니다.

Q. 업타임(가동률) 보장이 있나요?

TCP-80.NET은 이중화 네트워크와 UPS를 갖춘 도쿄 데이터센터에서 99.9% 이상의 네트워크 가동률을 목표로 운영합니다.

더 궁금한 사항이 있으시면 텔레그램 @tcp80net으로 언제든지 문의해 주세요. 24시간 한국어로 답변드립니다.

주요 로그 파일 위치

시스템 로그 분석

실시간 로그 확인

# 실시간 시스템 로그 모니터링
journalctl -f

# 특정 서비스 로그
journalctl -u nginx -f
journalctl -u mariadb -f

# 최근 N줄 확인
journalctl -u nginx --lines=50

부팅 오류 확인

# 마지막 부팅의 커널 로그
dmesg | grep -i error
dmesg | grep -i fail

# 시스템 부팅 로그
journalctl -b

Nginx 로그 분석

접속 통계 분석

# 가장 많이 접속한 IP TOP 20
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# HTTP 상태 코드 분포
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# 404 에러 URL 목록
awk '$9 == "404" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# 500 에러 발생 시각
grep ' 500 ' /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1-2

# 가장 많이 요청된 URL TOP 10
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 오늘의 총 요청 수
grep "$(date '+%d/%b/%Y')" /var/log/nginx/access.log | wc -l

봇 트래픽 감지

# 비정상 User-Agent 확인
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# 스캐너·봇 IP 확인 (단시간 다수 요청)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | awk '$1 > 1000 {print}'

인증 로그 보안 분석

# SSH 로그인 실패 IP 목록
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# 성공적인 SSH 로그인 기록
grep "Accepted" /var/log/auth.log | tail -20

# sudo 사용 기록
grep "sudo" /var/log/auth.log | tail -20

# 무차별 공격 감지 (분당 10회 이상 실패)
grep "Failed password" /var/log/auth.log | awk '{print $1,$2,$3}' | sort | uniq -c | sort -rn | head -10

logrotate로 로그 자동 관리

로그 파일이 계속 쌓이면 디스크가 가득 찹니다. logrotate로 자동으로 압축·삭제합니다.

기본 설정 확인

cat /etc/logrotate.conf
ls /etc/logrotate.d/

커스텀 로그 로테이션 설정

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily           # 매일 로테이션
    rotate 30       # 30개 보관
    compress        # gzip 압축
    delaycompress   # 최신 1개는 압축 보류
    missingok       # 파일 없어도 에러 없음
    notifempty      # 빈 파일은 로테이션 건너뜀
    create 0640 www-data adm  # 새 파일 권한
    postrotate
        nginx -s reopen  # Nginx에 로그 파일 재열기 신호
    endscript
}

logrotate 즉시 실행 (테스트)

logrotate -d /etc/logrotate.d/nginx  # dry-run
logrotate -f /etc/logrotate.d/nginx  # 강제 실행

디스크 용량 모니터링

로그가 디스크를 가득 채우지 않도록 정기적으로 확인합니다.

# 디스크 사용량
df -h

# 가장 큰 파일 찾기
du -sh /var/log/* | sort -rh | head -10

# 큰 로그 파일 즉시 비우기 (파일 삭제 X, 내용만 비움)
> /var/log/nginx/access.log

중앙화 로그 관리 (선택)

여러 서버를 운영하거나 로그 분석을 고도화하려면 중앙화 로그 시스템을 도입합니다:

• rsyslog: 로그를 원격 서버로 전송
• ELK Stack: Elasticsearch + Logstash + Kibana로 대용량 로그 분석
• Loki + Grafana: 경량 로그 집계 및 시각화

마치며

로그는 서버 운영의 블랙박스입니다. 평소에 로그를 점검하는 습관을 들이면 장애 발생 시 원인을 빠르게 파악하고, 보안 침해를 사전에 감지할 수 있습니다. 일본 서버 로그 설정에 대한 문의는 TCP-80.NET 텔레그램 @tcp80net으로 주세요.

IPMI란?

IPMI(Intelligent Platform Management Interface)는 서버 메인보드에 내장된 독립적인 관리 컨트롤러입니다. 서버의 전원이 꺼져 있거나 OS가 응답하지 않는 상태에서도 작동합니다.

주요 기능:

• 원격 전원 제어: 서버 전원 켜기/끄기/재시작
• 원격 콘솔(KVM): 마치 물리적으로 모니터를 연결한 것처럼 서버 화면 제어
• OS 재설치: 원격에서 ISO 이미지를 마운트해 OS 재설치
• 하드웨어 상태 모니터링: CPU 온도, 팬 속도, 전원 상태 확인
• 시스템 이벤트 로그: 하드웨어 이상 이벤트 기록 확인

IPMI 접근 방법

전용서버를 받으면 별도의 IPMI IP 주소, 포트, 사용자/비밀번호가 제공됩니다.

웹 브라우저 접속

https://IPMI-IP주소/

브라우저에서 IPMI 웹 인터페이스에 접속합니다. 일반적으로 Java 또는 HTML5 기반 KVM 뷰어를 제공합니다.

ipmitool 명령줄 도구

# 설치
apt install ipmitool -y

# 서버 상태 확인
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 chassis status

# 전원 관리
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 chassis power status
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 chassis power on
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 chassis power off
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 chassis power reset

# 하드웨어 센서 정보
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 sdr

# 시스템 이벤트 로그
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 sel list

주요 활용 시나리오

시나리오 1: SSH 접속이 안 될 때

OS는 실행 중인데 SSH가 응답하지 않는 경우, IPMI KVM으로 서버 화면에 직접 접속해 원인을 확인하고 SSH 서비스를 재시작할 수 있습니다.

1. IPMI 웹 접속 → Remote Control → KVM 콘솔 실행
2. 서버 화면 확인 (로그인 프롬프트 또는 패닉 메시지)
3. 직접 로그인해 SSH 서비스 재시작

systemctl restart sshd

시나리오 2: 서버가 완전히 응답하지 않을 때

OS 크래시나 커널 패닉으로 서버가 완전히 굳은 경우:

1. IPMI에서 전원 강제 리셋

   ipmitool ... chassis power reset
   

2. 서버 재시작 후 원인 파악 (dmesg, /var/log/syslog)

시나리오 3: OS 재설치

잘못된 설정이나 심각한 보안 침해 시 OS를 처음부터 재설치해야 할 때:

1. IPMI 웹 → Virtual Media → ISO 이미지 마운트
2. 서버를 해당 ISO로 부팅 설정
3. KVM 콘솔에서 OS 설치 진행

시나리오 4: 하드웨어 이상 감지

# CPU 온도 확인
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 sdr | grep Temp

# 팬 속도 확인
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 sdr | grep Fan

# 전원 공급 상태
ipmitool -I lanplus -H IPMI-IP -U admin -P 비밀번호 sdr | grep Power

IPMI 보안 설정

IPMI는 강력한 하드웨어 제어 권한을 가지므로 보안이 중요합니다.

1. 기본 비밀번호 변경: IPMI 웹 인터페이스에서 즉시 변경
2. 접근 IP 제한: IPMI 포트(623, 443 등)에 대한 접근을 특정 IP로 제한
3. 강력한 비밀번호 사용: 16자 이상 복잡한 비밀번호 설정
4. 불필요한 서비스 비활성화: 사용하지 않는 IPMI 기능 비활성화

VPS와의 차이

VPS는 가상화 환경이라 IPMI 대신 호스팅 업체의 관리 패널에서 전원 제어와 콘솔 접속을 제공합니다. 전용서버의 IPMI는 물리 하드웨어를 직접 제어하므로 더 강력하고 안정적입니다.

TCP-80.NET의 일본 전용서버에는 IPMI가 기본으로 포함됩니다. IPMI 접속 정보는 서버 개설 시 함께 제공됩니다.

마치며

IPMI는 일본 전용서버를 물리적 접근 없이도 완전하게 관리할 수 있게 해주는 핵심 기능입니다. 서버가 응답하지 않는 상황에서도 원격으로 복구할 수 있어 운영 안정성이 크게 높아집니다. IPMI 설정과 활용에 대한 문의는 TCP-80.NET 텔레그램 @tcp80net으로 주세요.

서버 유형별 특징 요약

비용 비교: 동일 스펙 기준

중급 웹 서버 스펙 기준 (4 vCore, 8GB RAM, 200GB SSD)

※ 클라우드 요금은 트래픽, 스토리지 I/O, 지원 플랜 등 추가 비용이 발생합니다.

고성능 서버 스펙 기준 (8코어, 32GB RAM, NVMe)

클라우드가 유리한 경우

1. 트래픽 예측 불가능: 갑자기 트래픽이 폭증했다가 다시 줄어드는 서비스
2. 짧은 운영 기간: 이벤트성 서비스로 수일~수주만 운영
3. 글로벌 멀티리전: 여러 국가에 동시에 서버가 필요한 경우
4. 관리형 서비스 필요: RDS, Elastic Cache 등 관리형 DB·캐시 사용
5. 팀 규모가 크고 DevOps 조직이 있는 경우

전용서버·VPS가 유리한 경우

1. 안정적인 트래픽: 예측 가능한 트래픽으로 월정액이 경제적
2. 장기 운영: 1년 이상 안정적으로 운영하는 서비스
3. 게임서버·채팅 서버: 네트워크 I/O가 많고 지연이 중요한 서비스
4. 대용량 스토리지: 클라우드 스토리지 비용이 높을 때
5. DDoS 방어 필요: TCP-80.NET은 기본 DDoS 방어 무료 포함
6. 비용 예측 중요: 스타트업이나 소규모 팀

숨겨진 클라우드 비용 항목

클라우드는 기본 인스턴스 요금 외에 추가 비용이 많습니다:

• 트래픽(Egress) 비용: AWS 도쿄 리전 기준 GB당 약 $0.114
  • 월 1TB 트래픽 = 약 $114 (약 ₩150,000) 추가
• 스토리지 I/O: EBS IO2 등 고성능 스토리지 사용 시 별도 과금
• 로드밸런서: ALB 기본 약 $16~25/월 + 처리 데이터 요금
• 지원 플랜: Developer 지원 $29/월, Business 지원 월 사용량의 10%
• NAT Gateway: 내부 트래픽 라우팅에도 과금

실제 예산 시뮬레이션

소규모 웹 서비스 (월 트래픽 500GB 기준)

TCP-80.NET VPS (일본)

• 서버 비용: ₩150,000/월
• 추가 비용: 없음 (DDoS 방어 포함)
• 합계: ₩150,000/월

AWS EC2 + RDS (도쿄)

• EC2 t3.medium: 약 ₩50,000/월
• RDS db.t3.small: 약 ₩80,000/월
• 트래픽 500GB: 약 ₩70,000/월
• 합계: 약 ₩200,000/월 (+ 지원 비용)

결론: 무엇을 선택해야 할까?

1~2년 이상 안정적으로 운영하는 서비스라면 전용서버·VPS가 대부분 비용 효율적입니다. 월 고정 비용이 예측 가능하고, 동일 스펙 대비 클라우드보다 저렴한 경우가 많습니다.

트래픽 변동이 극심하거나 글로벌 멀티리전이 필요한 서비스는 클라우드가 유리합니다.

TCP-80.NET은 일본 VPS와 전용서버를 월정액 고정 비용으로 제공하며, 예산 계획에 도움이 필요하면 텔레그램 @tcp80net으로 문의해 주세요.

PHP-FPM이란?

PHP-FPM은 PHP 요청을 처리하는 FastCGI 프로세스 관리자입니다. Nginx에서 PHP 요청이 오면 Unix 소켓 또는 TCP 소켓으로 PHP-FPM에 전달되어 처리됩니다.

주요 설정 파라미터:

• pm: 프로세스 관리 방식 (static, dynamic, ondemand)
• pm.max_children: 최대 PHP 워커 프로세스 수
• pm.start_servers: 시작 시 생성할 프로세스 수
• pm.min_spare_servers: 최소 유휴 프로세스 수
• pm.max_spare_servers: 최대 유휴 프로세스 수

PHP-FPM 설정 파일 위치

# Ubuntu 22.04 기준
/etc/php/8.1/fpm/pool.d/www.conf     # 풀 설정
/etc/php/8.1/fpm/php.ini             # PHP 설정
/etc/php/8.1/fpm/php-fpm.conf        # FPM 전체 설정

스펙별 pm.max_children 계산

pm.max_children을 너무 크게 설정하면 RAM이 부족해지고, 너무 작게 설정하면 요청이 대기합니다.

계산 공식:

pm.max_children = (가용 RAM - OS 사용 RAM) / PHP 워커당 평균 RAM

PHP 워커 하나가 사용하는 평균 RAM은 50~100MB입니다.

현재 PHP 워커 RAM 사용량 확인:

ps aux | grep php-fpm | awk '{print $6}' | sort -n | tail -5

PHP-FPM 풀 설정 최적화

; /etc/php/8.1/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data
listen = /run/php/php8.1-fpm.sock

; 프로세스 관리 방식
; - static: 고정 프로세스 수 (고트래픽에 적합)
; - dynamic: 트래픽에 따라 동적 조절
; - ondemand: 요청이 있을 때만 생성 (저트래픽)
pm = dynamic

; 4GB RAM 서버 기준
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 5
pm.max_spare_servers = 15

; 메모리 누수 방지: 일정 요청 처리 후 재시작
pm.max_requests = 500

; 요청 타임아웃
request_terminate_timeout = 60s

; 느린 로그 (2초 이상 소요 요청 기록)
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 2s

; 프로세스 상태 페이지 (Nginx에서 내부적으로만 허용)
pm.status_path = /php-fpm-status

PHP.ini 성능 설정

; /etc/php/8.1/fpm/php.ini

; 메모리 제한
memory_limit = 256M

; 업로드 제한
upload_max_filesize = 50M
post_max_size = 50M

; 실행 시간 제한
max_execution_time = 60
max_input_time = 60

; 에러 표시 (프로덕션에서는 off)
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

OPcache 활성화 (필수)

OPcache는 PHP 스크립트를 컴파일된 형태로 메모리에 저장해, 매 요청마다 파싱·컴파일하는 오버헤드를 제거합니다. 활성화만으로 PHP 성능이 2~5배 향상됩니다.

; OPcache 설정
opcache.enable = 1
opcache.enable_cli = 0
opcache.memory_consumption = 128    ; 메모리 할당 (MB)
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 1     ; 파일 변경 감지 (개발 환경: 1, 프로덕션: 0)
opcache.revalidate_freq = 60        ; 변경 확인 주기 (초)
opcache.fast_shutdown = 1

OPcache 상태 확인:

<?php
$status = opcache_get_status();
echo "Hit rate: " . $status['opcache_statistics']['opcache_hit_rate'] . "%";

PHP-FPM 상태 모니터링

Nginx에서 PHP-FPM 상태 페이지를 내부 접근으로 노출:

location /php-fpm-status {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

curl http://localhost/php-fpm-status
# 출력: pool, process manager, active processes, total requests 등

설정 적용 및 확인

# PHP-FPM 설정 테스트
php-fpm8.1 -t

# 재시작
systemctl restart php8.1-fpm

# 상태 확인
systemctl status php8.1-fpm

마치며

PHP-FPM 최적화는 서버 업그레이드 없이 성능을 크게 향상시킬 수 있는 방법입니다. 특히 OPcache 활성화는 모든 PHP 서비스에서 반드시 해야 하는 설정입니다. 일본 서버 PHP 환경 최적화에 대한 문의는 TCP-80.NET 텔레그램 @tcp80net으로 주세요.

Redis가 필요한 이유

웹 서비스에서 데이터베이스는 대부분 디스크에서 데이터를 읽습니다. Redis는 데이터를 메모리(RAM)에 저장하므로 조회 속도가 데이터베이스 대비 수십~수백 배 빠릅니다.

대표적인 활용 사례:

• 오브젝트 캐시: DB 쿼리 결과를 Redis에 저장해 반복 쿼리 제거
• 세션 저장: PHP, Node.js 세션을 Redis에 저장
• 속도 제한(Rate Limiting): API 요청 횟수 제한
• 메시지 대기열: 비동기 작업 처리
• 실시간 기능: 채팅, 알림 등 Pub/Sub 구현

1단계: Redis 설치

apt update
apt install redis-server -y

# 서비스 시작 및 자동 시작
systemctl enable redis-server
systemctl start redis-server

# 버전 확인
redis-server --version

# 동작 테스트
redis-cli ping
# 응답: PONG

2단계: Redis 기본 설정

nano /etc/redis/redis.conf

메모리 제한 설정

# 최대 메모리 설정 (서버 RAM의 25~30%)
maxmemory 512mb

# 메모리 초과 시 정책 (캐시 용도라면 allkeys-lru)
maxmemory-policy allkeys-lru

보안 설정 (비밀번호)

# 비밀번호 설정
requirepass 강력한비밀번호

# 외부 접근 차단 (로컬만 허용)
bind 127.0.0.1 ::1

영속성 설정 (선택)

캐시 목적이라면 영속성을 비활성화해 성능을 높일 수 있습니다:

# RDB 스냅샷 비활성화 (캐시 전용)
save ""

# AOF 비활성화
appendonly no

systemctl restart redis-server

3단계: 주요 Redis 명령어

# Redis CLI 접속
redis-cli -a 비밀번호

# 기본 조작
SET key value          # 값 저장
GET key                # 값 조회
DEL key                # 키 삭제
EXISTS key             # 키 존재 확인
EXPIRE key 3600        # TTL 설정 (초)
TTL key                # 남은 TTL 확인

# 문자열
SET user:1:name "홍길동"
GET user:1:name

# 해시 (오브젝트 저장)
HSET user:1 name "홍길동" email "hong@example.com"
HGET user:1 name
HGETALL user:1

# 리스트 (대기열)
RPUSH queue:email "task1"
LPOP queue:email

# 모니터링
INFO memory         # 메모리 사용량
INFO stats          # 통계
DBSIZE              # 총 키 수

4단계: 언어별 Redis 연동

PHP (WordPress 오브젝트 캐시)

apt install php8.1-redis -y
systemctl restart php8.1-fpm

WordPress에서 Redis Object Cache 플러그인 설치 후 wp-config.php에 추가:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PASSWORD', '비밀번호');
define('WP_REDIS_DATABASE', 0);

Node.js (ioredis)

npm install ioredis

const Redis = require('ioredis');
const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  password: '비밀번호',
});

// 캐시 패턴
async function getUser(id) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);

  const user = await db.findUser(id);  // DB 조회
  await redis.setex(`user:${id}`, 3600, JSON.stringify(user));  // 1시간 캐시
  return user;
}

Python (redis-py)

pip install redis

import redis
import json

r = redis.Redis(host='127.0.0.1', port=6379, password='비밀번호', decode_responses=True)

def get_cached_data(key, fetch_func, ttl=3600):
    cached = r.get(key)
    if cached:
        return json.loads(cached)

    data = fetch_func()
    r.setex(key, ttl, json.dumps(data, ensure_ascii=False))
    return data

5단계: 세션 저장소로 활용

PHP 세션을 Redis에 저장

apt install php8.1-redis -y

# /etc/php/8.1/fpm/php.ini
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=비밀번호"

세션 관리가 Redis로 이관되어 여러 서버 간 세션 공유도 가능해집니다.

Redis 성능 확인

# 성능 벤치마크
redis-benchmark -a 비밀번호 -q -n 100000

# 히트율 확인 (keyspace_hits / (keyspace_hits + keyspace_misses))
redis-cli -a 비밀번호 info stats | grep keyspace

캐시 히트율이 80% 이상이면 Redis가 효과적으로 동작하는 것입니다.

마치며

Redis를 일본 서버에 도입하면 데이터베이스 부하를 크게 줄이고 응답 속도를 개선할 수 있습니다. 특히 트래픽이 많은 서비스에서 효과가 두드러집니다. Redis 설정에 대한 문의는 TCP-80.NET 텔레그램 @tcp80net으로 주세요.

왜 일본에 게임서버를 두나요?

1. 한·일 간 낮은 레이턴시

서울에서 도쿄까지의 물리적 거리는 약 1,200km입니다. 광케이블로 연결되는 한·일 인터넷 회선은 왕복 지연(RTT)이 일반적으로 20~40ms 수준입니다. 대부분의 실시간 게임에서 40ms 이하는 ‘쾌적한’ 수준으로 분류됩니다.

반면 미국 서버(약 150~200ms)나 유럽 서버(약 250~300ms)는 체감 지연이 훨씬 큽니다.

2. 아시아 전역 커버

일본 도쿄는 아시아 인터넷 허브입니다. 한국뿐 아니라 일본, 대만, 홍콩, 동남아시아 플레이어도 비교적 낮은 핑으로 접속할 수 있어 아시아 유저 대상 글로벌 게임서버에 적합합니다.

3. 안정적인 인프라

일본 도쿄 데이터센터는 이중화된 전력 공급(UPS + 발전기)과 네트워크 이중화를 갖추고 있습니다. 게임서버는 24시간 365일 무중단 운영이 기본이기 때문에 이 안정성이 중요합니다.

게임서버 호스팅 서버 선택 가이드

소규모 게임서버 (10~30명): VPS

Minecraft 사설서버, 소규모 FPS 서버, 친목용 게임서버는 VPS로 충분합니다.

• 권장 스펙: 2 vCore 이상, RAM 4GB 이상, 100GB SSD
• 예상 비용: 월 ₩150,000~250,000
• 적합한 게임: Minecraft, Terraria, 소규모 FPS

TCP-80.NET 일본 VPS는 최대 4 vCore, 12GB RAM까지 지원합니다.

중·대규모 게임서버 (50명 이상): 전용서버

MMO, 배틀로얄, 대규모 멀티플레이어 게임은 전용서버가 필요합니다. 물리 서버를 단독으로 사용하기 때문에 리소스 경합 없이 안정적인 성능을 보장합니다.

• 권장 스펙: Intel Xeon 멀티코어, RAM 32GB 이상
• 예상 비용: 월 ₩300,000~1,200,000
• 적합한 게임: MMORPG, 대규모 배틀로얄, 게임 호스팅 플랫폼

TCP-80.NET 일본 전용서버는 Eco부터 High-End까지 5개 플랜을 제공합니다.

게임서버 호스팅 시 반드시 확인해야 할 3가지

1. DDoS 방어

게임서버는 DDoS 공격의 주요 표적입니다. 특히 경쟁이 치열한 게임에서는 악의적인 플레이어나 경쟁 서버 운영자가 DDoS를 시도하는 경우가 있습니다.

TCP-80.NET은 모든 서버에 네트워크 레이어(L3/L4) DDoS 방어를 무료로 제공합니다. 더 강력한 보호가 필요하다면 전용 DDoS 방어 서비스를 추가할 수 있습니다.

2. 포트 개방과 방화벽 설정

게임마다 사용하는 포트가 다릅니다. 서버 호스팅 업체가 포트 개방과 방화벽 설정을 지원하는지 확인하세요. TCP-80.NET은 OS 설치 후 필요한 포트 설정을 텔레그램으로 지원합니다.

3. IPMI 하드웨어 원격 관리

전용서버의 경우 OS 문제나 서버 다운 시 하드웨어 레벨에서 원격 접근할 수 있는 IPMI가 필수입니다. TCP-80.NET 전용서버에는 IPMI가 기본으로 포함됩니다.

게임서버 구축 시 추천 OS

마치며

일본 게임서버 호스팅은 한국과 아시아 유저 모두에게 안정적인 레이턴시를 제공합니다. 서버 규모와 예산에 맞게 VPS 또는 전용서버를 선택하고, DDoS 방어는 처음부터 챙겨두는 것이 좋습니다.

게임서버 구성에 대한 문의는 텔레그램 @tcp80net으로 연락해 주세요. 서버 개설부터 OS 설치, 방화벽 설정까지 24시간 한국어로 지원합니다.

일본서버호스팅이란?

일본서버호스팅은 일본 현지 데이터센터(IDC)에 위치한 서버를 임대해 웹사이트, 게임서버, 데이터베이스, 업무 시스템 등을 운영하는 서비스입니다.

한국에서 일본 서버를 사용하는 주요 이유는 다음과 같습니다:

• 낮은 레이턴시: 한국과 일본은 지리적으로 가까워 왕복 지연이 20~30ms 수준
• 일본 IP 주소: 일본 현지 서비스 이용, 인터넷 뱅킹, 마케팅 등에 활용
• 안정적인 인프라: 일본 도쿄 데이터센터는 높은 전력 안정성과 네트워크 이중화를 갖춤
• DDoS 방어: 전문 일본서버호스팅 업체들은 DDoS 방어 서비스를 기본 제공

일본서버호스팅 종류별 비교

1. 일본 VPS (가상 서버)

VPS는 물리 서버를 가상화 기술로 분할한 서버 환경입니다. 독립된 OS와 리소스를 제공하면서도 전용서버보다 비용이 저렴합니다.

적합한 용도:

• 소규모~중규모 웹사이트 및 쇼핑몰
• 스타트업·1인 개발자의 개발 서버
• 블로그, 커뮤니티, 소규모 API 서버
• Node.js, Python, PHP 기반 웹 서비스

장점:

• 월 10만원 수준의 합리적인 가격
• 빠른 서버 개설 (당일 개설 가능)
• 다양한 OS 선택 (Ubuntu, Debian, CentOS, Windows Server)

단점:

• 물리 서버 리소스를 다른 VPS와 공유
• 대규모 트래픽 처리에 한계

TCP-80.NET 일본 VPS는 1 vCore부터 4 vCore까지 4개 플랜을 제공하며 월 ₩100,000부터 시작합니다.

2. 일본 전용서버 (Dedicated Server)

전용서버는 물리 서버 하드웨어 전체를 단독으로 사용하는 서비스입니다. 최고 성능이 필요한 서비스에 적합합니다.

적합한 용도:

• 대규모 웹 서비스 및 트래픽이 많은 커머스
• 게임서버 호스팅 (MMORPG, FPS, 샌드박스 등)
• 고성능 데이터베이스 서버
• 영상 스트리밍, 대용량 파일 서버
• 금융·결제 서비스처럼 높은 안정성이 요구되는 환경

장점:

• CPU, RAM, 스토리지를 100% 단독 점유
• 예측 가능한 성능 (리소스 경합 없음)
• IPMI 하드웨어 원격 관리 기본 제공
• Dell, HP 등 정품 벤더 서버 사용

단점:

• VPS보다 상대적으로 높은 비용

TCP-80.NET 일본 전용서버는 Intel Xeon 기반 5개 플랜으로 월 ₩300,000부터 제공합니다.

3. 일본 가상 데스크톱 (RDP)

일본 IP를 가진 Windows 가상 데스크톱으로, RDP(원격 데스크톱 프로토콜)로 접속해 일반 PC처럼 사용합니다.

적합한 용도:

• 일본 인터넷 뱅킹·금융 서비스 이용
• 일본 한정 소프트웨어 또는 앱 사용
• 업무용 Windows 프로그램 원격 실행
• 일본 IP가 필요한 마케팅·광고 운영

TCP-80.NET 일본 가상 데스크톱은 월 ₩150,000부터 시작합니다.

일본서버호스팅 선택 기준 요약

DDoS 방어와 보안은 필수

어떤 서버를 선택하든 DDoS 방어와 해킹 보안은 반드시 확인해야 합니다. TCP-80.NET은 모든 서버에 네트워크 레이어 DDoS 차단을 무료로 기본 제공합니다. 추가 보안이 필요하다면 WAF(웹방화벽)·해킹 보안 서비스와 전용 DDoS 방어존을 별도로 이용할 수 있습니다.

마치며

일본서버호스팅을 선택할 때는 서비스 규모, 예상 트래픽, 필요한 OS 환경을 먼저 파악하는 것이 중요합니다. 소규모 서비스는 VPS로 시작해 트래픽이 늘면 전용서버로 업그레이드하는 방법도 효과적입니다.

TCP-80.NET은 일본 도쿄 데이터센터를 직접 운영하며 24시간 한국어 지원을 제공합니다. 서버 선택에 대한 궁금한 점은 텔레그램 @tcp80net으로 문의해 주세요.

UFW vs iptables

대부분의 일본 서버 운영에는 UFW로 충분합니다.

UFW 기본 설정

1. UFW 기본 정책 설정

# 들어오는 트래픽 기본 차단
ufw default deny incoming

# 나가는 트래픽 기본 허용
ufw default allow outgoing

2. 필요한 포트 허용

# SSH (포트 번호는 실제 설정한 번호로)
ufw allow 22222/tcp

# 웹 서비스
ufw allow 80/tcp
ufw allow 443/tcp

# 특정 포트 허용
ufw allow 3306/tcp   # MySQL (필요한 경우만)
ufw allow 6379/tcp   # Redis (필요한 경우만)

3. 특정 IP에서만 허용

# 특정 IP에서만 SSH 허용
ufw allow from 123.456.789.0 to any port 22222

# 특정 IP 대역 허용
ufw allow from 123.456.0.0/16 to any port 3306

4. UFW 활성화

ufw enable
ufw status verbose

UFW 주요 명령어

# 규칙 목록 확인 (번호 포함)
ufw status numbered

# 특정 번호 규칙 삭제
ufw delete 3

# 특정 포트 차단
ufw deny 8080/tcp

# 특정 IP 차단
ufw deny from 192.168.1.100

# UFW 비활성화 (주의)
ufw disable

# 모든 규칙 초기화 (주의)
ufw reset

iptables 고급 설정

UFW가 내부적으로 iptables를 사용하지만, 더 세밀한 제어가 필요한 경우 직접 iptables를 사용합니다.

SYN Flood 방어

# SYN 쿠키 활성화 (커널 레벨)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# SYN 패킷 속도 제한
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

포트 스캔 방어

# NULL 패킷 차단
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Xmas 패킷 차단
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# 비정상 패킷 차단
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

IP당 연결 수 제한

# 하나의 IP에서 최대 20개 연결 허용
iptables -A INPUT -p tcp -m connlimit --connlimit-above 20 -j REJECT

# 분당 연결 속도 제한
iptables -A INPUT -p tcp --dport 80 -m limit --limit 30/min --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

iptables 규칙 영구 저장

apt install iptables-persistent -y
netfilter-persistent save
netfilter-persistent reload

스크립트로 규칙 관리

방화벽 규칙이 복잡해지면 스크립트로 관리하는 것이 편리합니다:

#!/bin/bash
# /usr/local/bin/firewall.sh

# 기존 규칙 초기화
iptables -F
iptables -X

# 기본 정책
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# loopback 허용
iptables -A INPUT -i lo -j ACCEPT

# 기존 연결 허용
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH (포트 22222)
iptables -A INPUT -p tcp --dport 22222 -j ACCEPT

# HTTP/HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# ICMP (ping)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

echo "방화벽 규칙 적용 완료"
iptables -L -n -v

방화벽 설정 확인

# UFW 상태
ufw status verbose

# iptables 규칙 확인
iptables -L -n -v --line-numbers

# 열린 포트 확인
ss -tnlp

# 외부에서 포트 스캔 (다른 서버에서 실행)
nmap -sV 서버IP

마치며

방화벽은 일본 서버 보안의 첫 번째 방어선입니다. UFW로 기본 설정을 마친 후 필요에 따라 iptables로 세밀하게 조정하세요. TCP-80.NET은 서버 방화벽 설정 지원을 텔레그램 @tcp80net으로 제공합니다.

모니터링이 필요한 이유

• CPU 과부하 사전 감지: 서버 다운 전에 알림 수신
• 메모리 부족 대응: OOM(Out of Memory) 킬러 발동 전 조치
• 디스크 용량 관리: 디스크 풀로 인한 서비스 중단 방지
• 서비스 다운 감지: 웹서버, DB 장애를 즉시 알림

1. 기본 CLI 모니터링 도구

htop — CPU·메모리 실시간 확인

apt install htop -y
htop

• F2: 설정 (CPU 표시 방식 등)
• F3: 프로세스 검색
• F9: 프로세스 종료 신호 전송

iostat — 디스크 I/O 모니터링

apt install sysstat -y
iostat -x 1    # 1초마다 갱신

• %util 항목이 90% 이상이면 디스크 I/O 병목

nethogs — 프로세스별 네트워크 사용량

apt install nethogs -y
nethogs eth0

특정 프로세스가 비정상적으로 많은 네트워크 대역폭을 사용하는지 확인할 수 있습니다.

ss — 네트워크 연결 상태

# ESTABLISHED 연결 수 확인
ss -s

# 특정 포트 연결 확인
ss -tnp | grep :80
ss -tnp | grep :3306

2. Netdata — 실시간 웹 기반 모니터링

Netdata는 설치가 간단하고 실시간으로 CPU, 메모리, 디스크, 네트워크, Nginx, MySQL 등 다양한 메트릭을 시각화합니다.

# 설치
wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sh /tmp/netdata-kickstart.sh --non-interactive

설치 후 http://서버IP:19999에서 실시간 대시보드 확인이 가능합니다.

외부 접근 시 보안 설정

Netdata 포트는 외부에 노출되지 않도록 로컬 바인딩 후 Nginx로 프록시하거나, IP 제한을 설정하세요:

# UFW로 19999 포트 접근 제한
ufw allow from 내IP주소 to any port 19999

3. 알림 설정 — 문제 발생 시 즉시 통보

간단한 서버 상태 확인 스크립트

#!/bin/bash
# /usr/local/bin/check-server.sh

CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
MEM=$(free | grep Mem | awk '{printf "%.0f", $3/$2 * 100}')
DISK=$(df -h / | awk 'NR==2 {print $5}' | cut -d'%' -f1)

# 임계값 초과 시 알림 (텔레그램 봇 예시)
THRESHOLD_CPU=80
THRESHOLD_MEM=85
THRESHOLD_DISK=90

if [ "$CPU" -gt "$THRESHOLD_CPU" ]; then
    echo "경고: CPU 사용률 ${CPU}% 초과" | mail -s "서버 경고" admin@example.com
fi

웹 서비스 업타임 확인

#!/bin/bash
# 웹 서비스 응답 확인
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com)

if [ "$HTTP_CODE" != "200" ]; then
    echo "사이트 다운! HTTP 코드: $HTTP_CODE" | mail -s "장애 알림" admin@example.com
fi

crontab에 등록:

*/5 * * * * /usr/local/bin/check-server.sh
*/5 * * * * /usr/local/bin/check-uptime.sh

4. 외부 업타임 모니터링 서비스

서버 자체의 모니터링 스크립트는 서버가 다운되면 알림을 보낼 수 없습니다. 외부 모니터링 서비스를 병행하세요.

추천 무료 서비스:

• UptimeRobot: 5분 간격으로 서비스 상태 확인, 이메일/텔레그램 알림
• Freshping: 1분 간격 모니터링, 여러 위치에서 확인
• HetrixTools: IP·도메인 블랙리스트 모니터링 포함

UptimeRobot 설정 방법

1. uptimerobot.com 가입
2. Add New Monitor → HTTP(s) 선택
3. URL 입력 및 알림 설정 (텔레그램 또는 이메일)
4. 5분 간격 자동 확인 시작

5. 로그 분석으로 문제 패턴 파악

# 최근 Nginx 에러 로그 확인
tail -100 /var/log/nginx/error.log

# 가장 많이 접속한 IP TOP 10
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 500 에러 발생 URL
awk '$9 == "500" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# 오늘의 접속 수
grep "$(date '+%d/%b/%Y')" /var/log/nginx/access.log | wc -l

서버 상태 한눈에 보기

# 시스템 요약 정보
echo "=== CPU ===" && top -bn1 | grep "Cpu(s)"
echo "=== Memory ===" && free -h
echo "=== Disk ===" && df -h /
echo "=== Load ===" && uptime
echo "=== Services ===" && systemctl is-active nginx mariadb

마치며

일본 서버를 24시간 안정적으로 운영하려면 모니터링은 필수입니다. Netdata로 실시간 상태를 확인하고, UptimeRobot으로 외부에서 업타임을 감시하면 대부분의 장애를 사전에 대응할 수 있습니다. 서버 모니터링 설정에 대한 문의는 텔레그램 @tcp80net으로 주세요.

Nginx vs Apache 선택

일본 서버에서 자체 서비스를 운영한다면 대부분의 경우 Nginx를 권장합니다.

1단계: Nginx 설치

apt update
apt install nginx -y

systemctl enable nginx
systemctl start nginx

# 버전 및 설정 확인
nginx -v
nginx -t

2단계: 기본 설정 최적화

# /etc/nginx/nginx.conf
user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

http {
    # 기본 설정
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    server_tokens off;  # Nginx 버전 정보 숨김

    # 타임아웃
    keepalive_timeout 30;
    keepalive_requests 1000;
    client_body_timeout 10;
    client_header_timeout 10;
    send_timeout 30;

    # 버퍼 설정
    client_body_buffer_size 128k;
    client_max_body_size 50m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 16k;

    # MIME 타입
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 로그
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log warn;

    # Gzip 압축
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_min_length 1000;
    gzip_types
        text/plain text/css text/xml text/javascript
        application/json application/javascript application/xml
        application/rss+xml font/truetype font/opentype
        image/svg+xml;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

3단계: 가상 호스트(Server Block) 설정

# /etc/nginx/sites-available/mysite.conf
server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    root /var/www/mysite;
    index index.html index.php;

    # 보안 헤더
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;

    location / {
        try_files $uri $uri/ =404;
    }

    # PHP 처리 (PHP-FPM 사용 시)
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # 정적 파일 캐싱
    location ~* \.(jpg|jpeg|png|gif|webp|ico|svg|css|js|woff|woff2|ttf)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # 숨김 파일 차단 (.git, .env 등)
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

설정 활성화:

ln -s /etc/nginx/sites-available/mysite.conf /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

4단계: 리버스 프록시 설정 (Node.js/Python 앱)

upstream myapp {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 80;
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://myapp;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 90;
        proxy_connect_timeout 90;
    }
}

5단계: 접속 제한 설정 (보안)

http {
    # IP당 연결 속도 제한
    limit_req_zone $binary_remote_addr zone=general:10m rate=30r/m;
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location / {
            limit_req zone=general burst=10 nodelay;
            limit_conn addr 20;
        }

        # 로그인 페이지 강화
        location /login {
            limit_req zone=login burst=5;
        }
    }
}

유용한 Nginx 명령어

nginx -t              # 설정 파일 문법 확인
nginx -s reload       # 무중단 설정 재로드
nginx -s stop         # 즉시 중지
systemctl reload nginx # 설정 재로드 (권장)

# 로그 실시간 모니터링
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

마치며

Nginx를 올바르게 설정하면 일본 서버에서 빠르고 안전한 웹 서비스를 운영할 수 있습니다. 설정에 어려움이 있으시면 TCP-80.NET 텔레그램 @tcp80net으로 문의해 주세요.

MariaDB vs MySQL 선택

MariaDB는 MySQL의 오픈소스 포크로, MySQL과 완전히 호환되며 성능 개선과 추가 기능을 제공합니다. Ubuntu 22.04의 기본 저장소에서 바로 설치할 수 있어 편리합니다.

1단계: MariaDB 설치

apt update
apt install mariadb-server mariadb-client -y

# 서비스 시작 및 자동 시작 설정
systemctl enable mariadb
systemctl start mariadb

# 버전 확인
mysql --version

2단계: 보안 초기 설정

mysql_secure_installation

대화형 설정에서:

• root 비밀번호 설정: 강력한 비밀번호 설정 (Y)
• 익명 사용자 제거: Y
• 원격 root 로그인 차단: Y
• test 데이터베이스 삭제: Y
• 권한 테이블 재로드: Y

3단계: 데이터베이스 및 사용자 생성

-- root로 접속
mysql -u root -p

-- 데이터베이스 생성
CREATE DATABASE myapp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 전용 사용자 생성 (localhost만 허용)
CREATE USER 'myapp_user'@'localhost' IDENTIFIED BY '강력한패스워드';

-- 권한 부여
GRANT ALL PRIVILEGES ON myapp_db.* TO 'myapp_user'@'localhost';

-- 권한 적용
FLUSH PRIVILEGES;

-- 생성 확인
SHOW DATABASES;
SELECT User, Host FROM mysql.user;

4단계: 성능 튜닝 설정

서버 RAM에 따라 MariaDB 설정을 최적화합니다.

# /etc/mysql/mariadb.conf.d/99-optimize.cnf

[mysqld]
# InnoDB 버퍼 풀 (RAM의 50~70%)
# 4GB RAM 서버 기준
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2

# 로그 설정
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2  # 성능 우선 (1은 안전 우선)

# 연결 수
max_connections = 150
thread_cache_size = 16

# 쿼리 캐시 (MariaDB 10.4 이상에서는 비권장)
query_cache_type = 0
query_cache_size = 0

# 임시 테이블
tmp_table_size = 64M
max_heap_table_size = 64M

# 슬로우 쿼리 로그
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

systemctl restart mariadb

5단계: 원격 접속 설정 (선택사항)

보안상 DB는 localhost에서만 접속하는 것이 원칙이지만, 개발 편의를 위해 특정 IP에서 원격 접속을 허용할 수 있습니다.

MariaDB 바인딩 설정

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
bind-address = 0.0.0.0  # 모든 IP 허용 (방화벽으로 제한)

특정 IP 원격 접속 사용자 생성

-- 특정 IP(예: 123.456.789.0)에서만 접속 허용
CREATE USER 'remote_user'@'123.456.789.0' IDENTIFIED BY '강력한패스워드';
GRANT SELECT, INSERT, UPDATE ON myapp_db.* TO 'remote_user'@'123.456.789.0';
FLUSH PRIVILEGES;

방화벽에서 DB 포트 제한

# 특정 IP에서만 3306 포트 허용
ufw allow from 123.456.789.0 to any port 3306

6단계: 데이터베이스 모니터링

-- 현재 연결 수
SHOW STATUS LIKE 'Threads_connected';

-- 슬로우 쿼리 수
SHOW STATUS LIKE 'Slow_queries';

-- InnoDB 버퍼 풀 효율
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';

-- 실행 중인 쿼리 확인
SHOW PROCESSLIST;

보안 체크리스트

마치며

일본 서버에서 MariaDB를 올바르게 설정하면 안전하고 빠른 데이터베이스 환경을 구축할 수 있습니다. DB 설정에 도움이 필요하시면 TCP-80.NET 텔레그램 @tcp80net으로 문의해 주세요.

서버 한계 파악하기

스케일링 전략을 세우기 전에 현재 서버의 병목 지점을 파악해야 합니다.

# CPU 사용률 확인
top
htop

# 메모리 사용률 확인
free -h

# 디스크 I/O 확인
iostat -x 1

# 네트워크 트래픽 확인
iftop
nethogs

# Nginx 접속 수 확인
nginx -V 2>&1 | grep -o with-http_stub_status_module
curl http://localhost/nginx_status

전략 1: 수직 확장 (Scale Up)

현재 서버의 리소스를 늘리는 가장 간단한 방법입니다.

• VPS 업그레이드: 더 높은 vCore, RAM 플랜으로 변경
• 전용서버 업그레이드: 더 높은 사양의 전용서버로 이전

장점: 설정 변경 없이 즉시 성능 향상 단점: 물리적 한계 존재, 비용 증가, 업그레이드 시 재시작 필요

TCP-80.NET은 서버 업그레이드 문의를 텔레그램으로 빠르게 처리합니다.

전략 2: 캐시 최적화 (가장 효과적)

서버를 업그레이드하기 전에 캐시를 잘 활용하면 동일한 서버에서 몇 배 더 많은 트래픽을 처리할 수 있습니다.

Nginx FastCGI 캐시 (PHP 서비스)

http {
    fastcgi_cache_path /tmp/nginx_cache
        levels=1:2
        keys_zone=MYAPP:100m
        max_size=1g
        inactive=60m
        use_temp_path=off;
}

server {
    fastcgi_cache_key "$scheme$request_method$host$request_uri";

    location ~ \.php$ {
        fastcgi_cache MYAPP;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;

        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

Redis 오브젝트 캐시

데이터베이스 쿼리 결과를 Redis에 캐싱하면 DB 부하를 크게 줄입니다.

apt install redis-server -y

# Nginx Proxy 캐시 (Node.js/Python 앱)
proxy_cache_path /tmp/proxy_cache levels=1:2 keys_zone=PROXY:10m;

location / {
    proxy_cache PROXY;
    proxy_cache_valid 200 5m;
    proxy_pass http://localhost:3000;
}

전략 3: CDN 활용

정적 파일(이미지, CSS, JS, 폰트)을 CDN에서 제공하면 서버 부하를 크게 줄일 수 있습니다. 일반적으로 웹 트래픽의 60~80%는 정적 파일 요청입니다.

Cloudflare 설정

1. Cloudflare에 도메인 등록
2. DNS를 Cloudflare로 변경
3. 캐싱 정책 설정:
   • Browser Cache TTL: 1일 이상
   • Cache Level: Standard
   • Rocket Loader: JavaScript 비동기 로드

Cloudflare의 일본 PoP(도쿄 등)에서 정적 파일을 제공해 서버 부하를 줄이고 응답 속도를 높일 수 있습니다.

전략 4: Nginx 연결 수 최적화

# /etc/nginx/nginx.conf
worker_processes auto;  # CPU 코어 수에 맞게 자동 설정
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

http {
    keepalive_timeout 30;
    keepalive_requests 1000;
    client_body_timeout 10;
    client_header_timeout 10;
    send_timeout 10;
}

전략 5: 데이터베이스 최적화

트래픽 급증 시 DB가 가장 먼저 병목이 됩니다.

슬로우 쿼리 찾기

-- MariaDB 슬로우 쿼리 로그 활성화
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;

인덱스 최적화

-- 자주 조회되는 컬럼에 인덱스 추가
CREATE INDEX idx_user_email ON users(email);
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';

Read Replica 분리

읽기 쿼리가 많은 서비스는 별도 읽기 전용 DB 서버를 두어 부하를 분산합니다.

트래픽 급증 전 체크리스트

• Nginx 설정 최적화 완료
• Redis 캐시 설정 완료
• CDN 연동 완료
• DB 인덱스 최적화 완료
• 모니터링 설정 (CPU/RAM/DB 알림)
• 서버 업그레이드 옵션 확인

마치며

트래픽 급증은 좋은 신호이지만, 대비가 없으면 서비스 장애로 이어집니다. 먼저 캐시 최적화로 최대한 버티고, 필요하면 서버 업그레이드를 진행하세요. TCP-80.NET은 긴급 업그레이드와 기술 지원을 텔레그램 @tcp80net으로 신속하게 처리합니다.

백업의 3-2-1 원칙

전문적인 백업 전략의 기본 원칙:

• 3개 복사본: 원본 포함 3개의 데이터 복사본 유지
• 2가지 저장 매체: 서로 다른 유형의 저장소에 저장
• 1개 원격 저장: 최소 1개는 오프사이트(원격 위치)에 저장

1. 데이터베이스 백업

MySQL / MariaDB 백업

#!/bin/bash
# /usr/local/bin/backup-db.sh

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/db"
DB_NAME="myapp"
DB_USER="root"
DB_PASS="패스워드"

mkdir -p $BACKUP_DIR

# 전체 데이터베이스 백업
mysqldump -u $DB_USER -p$DB_PASS \
  --single-transaction \
  --quick \
  --lock-tables=false \
  $DB_NAME | gzip > $BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz

# 30일 이상 된 백업 삭제
find $BACKUP_DIR -name "*.sql.gz" -mtime +30 -delete

echo "DB 백업 완료: ${DB_NAME}_${DATE}.sql.gz"

PostgreSQL 백업

sudo -u postgres pg_dump myapp | gzip > /backup/db/myapp_$(date +%Y%m%d).sql.gz

2. 파일 백업 (웹 루트, 업로드 파일)

rsync를 이용한 로컬 백업

#!/bin/bash
# 웹 루트 백업
rsync -avz --delete \
  /var/www/html/ \
  /backup/www/

# 업로드 파일 백업
rsync -avz \
  /var/www/html/uploads/ \
  /backup/uploads/

증분 백업 (rsync + 날짜 디렉토리)

DATE=$(date +%Y%m%d)
YESTERDAY=$(date -d "yesterday" +%Y%m%d)

rsync -avz --delete \
  --link-dest=/backup/www/$YESTERDAY \
  /var/www/html/ \
  /backup/www/$DATE/

--link-dest 옵션으로 변경된 파일만 새로 복사하고 나머지는 하드링크로 처리해 저장 공간을 절약합니다.

3. 원격 백업 (오프사이트)

로컬 백업만으로는 서버 전체 장애나 데이터센터 문제 시 복구가 불가능합니다. 원격 위치에 추가 백업을 저장하세요.

AWS S3 또는 호환 오브젝트 스토리지 업로드

apt install awscli -y
aws configure  # AWS 자격 증명 설정

# S3에 업로드
aws s3 cp /backup/db/ s3://my-backup-bucket/db/ --recursive
aws s3 cp /backup/www/ s3://my-backup-bucket/www/ --recursive

rclone을 이용한 다양한 클라우드 업로드

rclone은 AWS S3, Google Cloud Storage, Backblaze B2 등 다양한 클라우드 스토리지를 지원합니다.

apt install rclone -y
rclone config  # 클라우드 스토리지 설정

# 백업 업로드
rclone copy /backup/db remote:my-backup/db

4. 자동 백업 스케줄 설정

crontab으로 자동화

crontab -e

# 매일 새벽 2시 DB 백업
0 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1

# 매일 새벽 3시 파일 백업
0 3 * * * rsync -avz /var/www/html/ /backup/www/ >> /var/log/backup.log 2>&1

# 매일 새벽 4시 원격 백업 (S3)
0 4 * * * aws s3 sync /backup/ s3://my-backup-bucket/ >> /var/log/backup.log 2>&1

# 매주 일요일 전체 DB 덤프
0 1 * * 0 mysqldump -u root myapp | gzip > /backup/weekly/myapp_$(date +\%Y\%m\%d).sql.gz

5. 백업 복구 테스트

백업은 복구가 가능해야 의미가 있습니다. 정기적으로 복구 테스트를 실시하세요.

# DB 복구 테스트 (테스트 DB에서 수행)
gunzip -c /backup/db/myapp_20260119.sql.gz | mysql -u root test_restore

# 파일 복구 테스트
rsync -avz /backup/www/ /tmp/restore_test/

백업 용량 계획

마치며

일본 서버 운영에서 백업은 비용이 아니라 보험입니다. 백업 없이 운영하다가 장애가 발생하면 복구 비용이 훨씬 크게 발생합니다. 오늘 바로 백업 자동화를 설정하세요. 백업 설정이나 스토리지 구성에 대한 문의는 텔레그램 @tcp80net으로 주세요.

SSL 인증서가 필요한 이유

1. 보안: 클라이언트와 서버 간 통신 암호화
2. SEO: 구글은 HTTPS 사이트를 검색 순위에서 우대
3. 신뢰성: 브라우저 주소창의 자물쇠 아이콘
4. 필수 요건: 결제 페이지, 로그인 페이지는 HTTPS 필수

Let’s Encrypt 무료 SSL 인증서

Let’s Encrypt는 비영리 인증기관(CA)에서 제공하는 무료 SSL 인증서로, 90일마다 자동 갱신이 가능합니다. 상업용 유료 인증서와 동일한 수준의 보안을 제공합니다.

Certbot 설치

apt install certbot python3-certbot-nginx -y

단일 도메인 인증서 발급

certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot이 자동으로:

1. 도메인 소유권 확인 (Let’s Encrypt ACME 챌린지)
2. 인증서 발급
3. Nginx 설정에 SSL 추가
4. HTTP → HTTPS 리다이렉트 설정