[카테고리:] AWS

마이크로 캐싱이란?

마이크로 캐싱은 아주 짧은 TTL(보통 1~10초) 동안 응답을 캐시에 저장해 두고, 같은 요청이 들어오면 백엔드 대신 캐시에서 바로 응답하는 기법입니다. 짧은 TTL이라 실시간성은 유지하면서도, 순간 트래픽 폭주(새로고침, 인기 API 호출 등)를 효과적으로 흡수할 수 있습니다.

필요한 이유

• 사용자가 새로고침을 여러 번 하거나, 다수 유저가 동시에 동일 API를 호출하면 백엔드(DB, 애플리케이션)에 부하가 급증합니다.
• 대부분의 API/페이지는 몇 초 단위로 변경되지 않기 때문에 짧게라도 캐시하면 부하를 크게 줄일 수 있습니다.

⚙️ 동작원리

1. 첫 요청 → 캐시에 없음 → 백엔드 호출 → 응답 저장
2. TTL(예: 3초) 안의 동일 요청 → 캐시에서 바로 응답
3. TTL 만료 → 백엔드 재호출 후 캐시 갱신

Nginx는 $upstream_cache_status 값으로 캐시 상태를 알려줍니다.

$upstream_cache_status 값과 의미

기본 설정 예시 (API)

• /etc/nginx/nginx.conf ➡️ http{} 블록

# 캐시 저장소
proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my_cache:50m max_size=1g inactive=10m use_temp_path=off;

# 인증 헤더 감지(개인화 요청은 캐시 제외)
map $http_authorization $auth_cache_bypass {
    default 1;
    ""      0;
}

• server{} 블록

# API만 마이크로 캐싱
location ^~ /api/ {
    proxy_pass http://localhost:port;

    proxy_cache my_cache;
    proxy_cache_key "$scheme$host$request_uri";
    proxy_cache_valid 200 3s;          # TTL 3초
    proxy_cache_lock on;               # 동시 폭주 방지
    proxy_cache_use_stale updating;    # 갱신 중에는 이전 캐시 사용

    # 안전장치: 인증 요청/쿠키 발행 응답은 캐시 제외
    proxy_no_cache       $auth_cache_bypass $upstream_http_set_cookie;
    proxy_cache_bypass   $auth_cache_bypass $upstream_http_set_cookie;

    add_header X-Cache-Status $upstream_cache_status always;
}

🧱 테스트 방법

# 첫 호출 → MISS
curl -I https://example.com/api/data | grep -i x-cache-status

# TTL 내 재호출 → HIT
curl -I https://example.com/api/data | grep -i x-cache-status

🚨 주의

• 개인화 데이터(로그인 사용자별 데이터)는 절대 캐시하면 안 됨 → Authorization/Cookie 조건으로 캐시 우회
• POST, PUT 요청은 Nginx 기본 설정상 캐시되지 않음
• TTL이 너무 길면 데이터 최신성이 떨어지고, 너무 짧으면 효과가 적음 → 2~3초부터 시작해서 조정
• 쿼리스트링이 다르면 별도 캐시로 저장되므로, 불필요한 랜덤 파라미터는 제거

⛺️ 확장: 정적 파일 + 마이크로 캐싱

왜 정적 파일에도 마이크로 캐싱을 걸까?

• 백엔드가 정적 파일(JS, CSS, 이미지 등)을 직접 서빙하는 경우, 많은 유저가 동시에 요청하면 백엔드 리소스를 불필요하게 소모합니다.
• 특히 빌드 시 해시(app.abc123.js)가 붙은 파일은 변경 시 파일명이 바뀌므로 오래 캐시해도 안전합니다.
• Nginx가 서버 앞단 캐시(프록시 캐시)로 한 번만 백엔드에 요청하게 하면, 다수의 요청을 빠르게 처리할 수 있습니다.

🧱 설계 원칙

1. 요청에 쿠키가 있어도 캐시 허용
   • 정적 파일에는 보통 개인화 데이터가 없음.
2. 응답에 Set-Cookie가 있으면 캐시 금지
   • 혹시라도 백엔드가 정적 파일 응답에 세션 쿠키를 발행하는 경우 안전하게 우회.
3. 브라우저 캐시도 함께 설정
   • 해시가 있는 파일은 1년 + immutable 권장.
4. 서버 캐시 TTL은 짧게
   • 마이크로 캐싱 용도로 1분~10분 정도가 적당.

⚙️ Nginx 설정 예시

# 정적 파일(해시 포함) + 마이크로 캐싱
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff2?)$ {
    proxy_pass http://localhost:port;                # 백엔드 서빙 유지

    # --- 서버 앞단 캐시(Nginx 프록시 캐시) ---
    proxy_cache my_cache;
    proxy_cache_key "$scheme$host$request_uri";
    proxy_cache_valid 200 10m;                        # TTL: 10분 (해시 없는 파일은 더 짧게)
    proxy_cache_lock on;                              # 동시 폭주 방지
    proxy_cache_use_stale updating;

    # 요청 쿠키는 허용, 응답 Set-Cookie 시 캐시 제외
    proxy_no_cache       $auth_cache_bypass $upstream_http_set_cookie;
    proxy_cache_bypass   $auth_cache_bypass $upstream_http_set_cookie;

    # --- 브라우저 캐시 ---
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable" always;

    # 상태 확인용 헤더
    add_header X-Cache-Status $upstream_cache_status always;
}

⚠️ 해시 없는 파일(예: /styles/main.css)이라면 proxy_cache_valid를 더 짧게(예: 1~5분) 두고, 브라우저 캐시도 max-age=300 정도로 조정하세요.

🧱 테스트 방법

# 첫 요청: MISS
curl -I https://example.com/_next/static/chunks/app.abc123.js | grep -i x-cache-status

# TTL 내 재요청: HIT
curl -I https://example.com/_next/static/chunks/app.abc123.js | grep -i x-cache-status

# 브라우저 캐시 헤더 확인
curl -I https://example.com/_next/static/chunks/app.abc123.js | egrep -i 'cache-control|expires'

🧤 운영 TIP

• 정적 전용 서브도메인(예: static.example.com)을 사용하면 브라우저가 쿠키를 아예 붙이지 않아 캐시 효율 ↑.
• 빌드 툴(Next.js, React, Vue 등)의 filename hashing을 켜두면 캐시 무효화 걱정 없이 TTL을 길게 가져갈 수 있음.
• Nginx 프록시 캐시 + 브라우저 캐시를 동시에 쓰면 최초 1회만 백엔드 요청, 그 이후는 대부분 브라우저 또는 Nginx에서 응답.

🧤 알아두어야 할 것

🖥 서버 캐싱 (서버 단 캐시)

• 위치: Nginx(리버스 프록시)나 CDN, API Gateway 같은 서버 측
• 동작:
  1. 첫 요청 → 서버가 백엔드에 요청해 응답 저장
  2. TTL 안의 재요청 → 서버 캐시에서 바로 응답
  3. TTL 지나면 백엔드 재요청

• 장점:
  • 백엔드 부하 감소 (API·정적 파일 모두 가능)
  • TTL 내에 여러 유저 요청을 합쳐서 처리 가능
  • 브라우저 캐시를 무시하고도 동작 가능 (모든 클라이언트 공통)
• 단점:
  • TTL 안에서는 변경된 데이터가 바로 반영 안 될 수 있음
  • 서버 디스크/메모리 사용

예시: proxy_cache (Nginx), CloudFront, Varnish, Redis 기반 캐시

🌐 브라우저 캐싱 (클라이언트 단 캐시)

• 위치: 사용자의 웹 브라우저 로컬 저장소
• 동작:
  1. 첫 요청 시 응답을 브라우저가 저장
  2. TTL 또는 조건부 요청(ETag, Last-Modified) 안에서는 서버에 재요청 없이 바로 로컬에서 로드
  3. TTL 지나면 서버에 새로 요청
• 장점:
  • 요청 자체를 줄여 네트워크 속도 향상
  • 서버에 트래픽이 아예 가지 않음
• 단점:
  • 브라우저별·사용자별로 캐시가 따로 있음
  • TTL 안에 새 버전 배포 시 즉시 반영 안 됨
  • 캐시 무효화(무효화 정책, 파일명 변경) 필요

예시: Cache-Control: max-age=31536000, immutable, ETag + If-None-Match

🔥 빌드할때 왜 해시 기반 파일명으로 할까?

📌 해시 기반 파일명의 핵심 목적: 

캐시 무효화(Cache Busting)

• 브라우저 캐싱은 빠른 로딩을 위해 오래 저장하지만, 이게 변경 반영에는 치명적일 수 있음.
• 파일명이 고정이면 (app.js), 브라우저는 TTL 동안 절대 새로 다운로드 안 함.
• 그래서 파일 내용이 바뀔 때마다 내용 기반 해시(MD5/SHA1 등)를 파일명에 포함시켜 버전처럼 사용.

🛠 동작 방식

1. 빌드 시 JS/CSS 내용의 해시를 계산
2. 해시를 파일명에 삽입
3. HTML에서 그 새 파일명을 참조
4. 브라우저는 이름이 다르면 다른 파일로 인식 → 즉시 새로 다운로드

✅ 장점

1. 1년 캐시 가능
   • 파일명이 바뀌면 브라우저는 무조건 새로 받음 → TTL 무시
2. 불필요한 네트워크 요청 제거
   • 내용이 안 바뀌면 계속 기존 캐시 사용
3. CDN/프록시 캐시 효율 극대화
   • 전 세계 캐시 서버에 동일한 파일명이 유지

⚠️ 단점

• 빌드 과정에서 HTML/JS 내부의 파일 경로를 전부 갱신해야 함
• 해시 값이 조금이라도 달라지면 완전히 새 파일로 인식 → 캐시 100% 무효화 (좋기도 하고, 비효율일 수도 있음)

📍 정리

• 해시 기반 파일명 덕분에 Cache-Control: max-age=31536000, immutable 같은 1년 브라우저 캐싱 정책을 안전하게 쓸 수 있음.
• 해시 없이 고정 파일명이라면, 이렇게 길게 캐싱하면 배포 때 문제 생김.

하나의 서버에서 2개의 웹 프론트 서버가 서로 다른 도메인으로 SSL(443포트) 사용 가능하다. 단, 아래 조건을 만족해야 한다.

✅ 전제 조건

1. 도메인이 서로 다름
   • 예: a.example.com, b.example.com
2. 각 도메인에 대해 유효한 SSL 인증서
   • Let’s Encrypt 등에서 도메인 별 인증서 발급
3. 리버스 프록시(Web 서버)가 하나만 443 포트를 바인딩
   • Nginx나 Apache 같은 리버스 프록시를 사용해 도메인에 따라 백엔드 서버로 트래픽 분기

🧱 구조 예시

[Client]
   |
443 포트 요청 (도메인 A 또는 B)
   ↓
[Nginx Reverse Proxy]  (SSL 인증서 설정, 443 포트 점유)
   ├──> http://localhost:3001 (도메인 A용 웹 앱)
   └──> http://localhost:3002 (도메인 B용 웹 앱)

# nginx conf 예시

# a.example.com에 대한 설정
server {
    listen 443 ssl;
    server_name a.example.com;

    ssl_certificate     /etc/ssl/certs/a_cert.pem;
    ssl_certificate_key /etc/ssl/private/a_key.pem;

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

# b.example.com에 대한 설정
server {
    listen 443 ssl;
    server_name b.example.com;

    ssl_certificate     /etc/ssl/certs/b_cert.pem;
    ssl_certificate_key /etc/ssl/private/b_key.pem;

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

📝 요약

📌 SSL 없이도 가능? (HTTP:80)

SSL 인증서를 사용하지 않고 하나의 서버에서 두 개의 웹 프론트 서버를 서로 다른 도메인으로 띄우는 것도 가능하다. 이 경우엔 443 포트가 아니라 80포트로 사용하게 된다.

✅ 요약: SSL 없이 가능한가?

⚠️ 주의할 점

• 중간자 공격(MITM)에 취약 → 로그인, 개인정보 송수신이 있다면 반드시 SSL 사용 권장
• 일부 브라우저에서는 HTTPS 필수로 요구 → 특히 PWA, 모바일 앱, OAuth, API 연동 등에서 문제 발생 가능

💬 결론

✅ 도메인이 있다면 포트를 나눌 필요 없음. Nginx 같은 리버스 프록시로 하나의 포트(80/443)에서 라우팅 가능

❌ 도메인이 없으면 포트를 나눠야 함. 각 서비스가 독립된 포트를 차지해야 하므로

AWS Load balancer로 구축된 웹 서버와 API 서버가 있다.

• A load balancer — Nginx 웹 서버 (instance 3대)
• B load balancer — API 서버 (instance 3대)

이렇게 각각 2개의 로드밸런서를 구축하고 아무런 문제 없이 운영하고 있는데 오류가 발생했다.

오류의 내용은, timeout error 였다.

2024/11/05 14:40:24 [error] 905#0: *974 upstream timed out (110: Connection timed out) while reading response header from upstream

이런 내용의 에러 였다.

구글링을 해보니, 프록시 서버에서의 읽는 시간과 연결 시간이 너무 짧게 설정되어 있어서 해당 오류가 뜬다고 나와있다.

nginx.conf 파일을 살펴보니 따로 timeout에 대해 설정이 되어 있진 않았다. 설정이 되어있지 않다면 디폴트값은 다음과 같다.

proxy_connect_timeout: 60초
proxy_read_timeout: 60초
proxy_send_timeout: 60초

일단 로드밸런서의 서버 리소스는 충분했고, DB 지연시간이나 DB CPU가 많이 먹는 상태는 아니었기 때문에 1순위로 timeout 설정이 잘못되어 졌다고 생각했다.

오류가 난 서버에 위 설정을 두배정도인 120s 로 설정 했다.

proxy_connect_timeout 120s;
proxy_read_timeout 120s;
proxy_send_timeout 120s;

그리고, 한가지 더 의심이 갔던 부분은 로드밸런서를 구성할 때 대상그룹의 상태검사 부분에서 health check 하는 부분이 있다.

여기서도 timeout — 제한시간이라는 이름으로 응답에 관련한 항목이 있다.

이 부분도 web 서버의 로드밸런서와 api 서버의 로드밸런서가 서로 시간이 상이했기 때문에 upstream timeout 에러가 났다고 추측했다.

제한시간 타임을 조금 늘리고, 각각의 로드밸런서의 시간을 동일하게 맞췄다.

그리고 나서는 따로 오류가 나지 않는 상태.

관련 패키지 및 버전

nginx — 1.26.2, node.js — 16.20.2, npm — 8.19.4, pm2–5.4.2

selinux 설정 끄기

sudo getenforce # enforce 상태 확인.
sudo setenforce 0 # enforce 상태 변경. (끄기)

📌 selinux 영구적으로 끄는 법

# 파일 수정.
sudo vi /etc/selinux/config
# 이 항목을 찾는다.
SELINUX=enforcing
# 다음과 같이 변경.
SELINUX=disabled
# 시스템 재부팅.
sudo reboot
# 적용되었는지 확인.
sestatus

커널 sysctl 수정 (소켓 maxconn 셋팅값 수정.) -> maxconn 값은 상황에 따라 수정 가능

# maxconn 상태 조회.
sudo sysctl -a | grep net.core.somaxconn
# maxconn 상태 수정.
sudo /sbin/sysctl -w net.core.somaxconn=4096

---
net.core.somaxconn = 65535

port 체크

sudo netstat -nltup

시스템 업데이트 및 필수 패키지 설치

sudo dnf update -y
sudo dnf install -y curl wget tar gcc-c++ make

Nginx 셋팅 (version : 1.26.2)

# 필요한 패키지 설치
sudo dnf install -y gcc pcre-devel zlib-devel make openssl-devel
# Nginx 소스 다운로드
wget https://nginx.org/download/nginx-1.26.2.tar.gz
# 압축 해제 및 설치
tar -zxvf nginx-1.26.2.tar.gz
cd nginx-1.26.2
# Nginx 컴파일 및 설치
./configure
make
sudo make install
# Nginx 실행 확인
/usr/local/nginx/sbin/nginx -v

Nginx 환경변수 설정

vi ~/.bashrc # 해당 파일에 아래와 같은 내용 추가.
export PATH=$PATH:/usr/local/nginx/sbin
source ~/.bashrc # 적용.
nginx -v # 확인.

Nginx 서비스 설정

root ~ # vi /etc/systemd/system/nginx.service

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
PrivateTmp=true

[Install]
WantedBy=multi-user.target

---

systemctl daemon-reload
systemctl status nginx
systemctl start nginx
systemctl enable nginx

Node.js 16.20.2 설치

# nvm 설치
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
source ~/.bashrc
# nvm으로 Node.js 16.20.2 설치
nvm install 16.20.2
nvm use 16.20.2
# 설치된 Node.js 버전 확인
node -v
npm -v

NPM 8.19.4 설치

#### 위에서 버전이 나오면 따로 설치 안해도 됨.
npm install -g npm@8.19.4
# 설치된 NPM 버전 확인
npm -v

PM2 5.4.2 설치

npm install -g pm2@5.4.2
# PM2 버전 확인
pm2 -v

PM2 사용법

# 애플리케이션 시작
pm2 start app.js
# 모든 애플리케이션 목록 확인
pm2 list
# 애플리케이션 로그 확인
pm2 logs
# 애플리케이션 재시작
pm2 restart app
# PM2 상태 저장 (서버 재부팅 시 자동 시작)
pm2 save
pm2 startup

ollama를 외부접속하게 만들려고 한다. 그래서 ollama 설치 후, systemd 등록 파일로 프로세스를 띄웠다.

[Unit]
Description=Ollama Service
After=network.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=root
Restart=always
RestartSec=3

Environment="OLLAMA_HOST=0.0.0.0"

[Install]
WantedBy=multi-user.target

default 가 127.0.0.1:11434로 프로세스가 띄워지기 때문에 외부에서 접속할 수 있게 0.0.0.0:11434으로 띄워야 한다. Environment="OLLAMA_HOST=0.0.0.0" 으로 등록하여 anywhere로 접근하게 만들었다.

하지만, TCP6로만 열리고, TCP4로는 열리지 않았다.

이런 문제를 해결하기 위해 nginx로 로드밸런서 처리를 하여 외부에서 ollama를 접속할 수 있게 만들었다.

# /etc/nginx/site-availables/

server {
    listen 11433; # ollama port

    location / {
        proxy_pass http://[::1]:11434;  # Ollama 서버의 IPv6 주소와 포트
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

nginx에서 이렇게 설정하여, nginx에 들어오는 트래픽을 ollama로 들어가게 설정하였다.

새로운 설정 파일 활성화

sites-enabled 디렉터리에 올바른 파일이 없기 때문에, 이전에 생성한 ollama 설정 파일을 활성화.

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/default

Nginx 설정 다시 확인

올바른 파일이 활성화되었는지 확인.

sudo nginx -t