마이크로 캐싱이란?마이크로 캐싱은 아주 짧은 TTL(보통 1~10초) 동안 응답을 캐시에 저장해 두고, 같은 요청이 들어오면 백엔드 대신 캐시에서 바로 응답하는 기법입니다. 짧은 TTL이라 실시간성은 유지하면서도, 순간 트래픽 폭주(새로고침, 인기 API 호출 등)를 효과적으로 흡수할 수 있습니다.필요한 이유사용자가 새로고침을 여러 번 하거나, 다수 유저가 동시에 동일 API를 호출하면 백엔드(DB, 애플리케이션)에 부하가 급증합니다.대부분의 API/페이지는 몇 초 단위로 변경되지 않기 때문에 짧게라도 캐시하면 부하를 크게 줄일 수 있습니다.⚙️ 동작원리첫 요청 → 캐시에 없음 → 백엔드 호출 → 응답 저장TTL(예: 3초) 안의 동일 요청 → 캐시에서 바로 응답TTL 만료 → 백엔드 재호출 후 캐시 갱..

하나의 서버에서 2개의 웹 프론트 서버가 서로 다른 도메인으로 SSL(443포트) 사용 가능하다. 단, 아래 조건을 만족해야 한다.✅ 전제 조건도메인이 서로 다름예: a.example.com, b.example.com각 도메인에 대해 유효한 SSL 인증서Let’s Encrypt 등에서 도메인 별 인증서 발급리버스 프록시(Web 서버)가 하나만 443 포트를 바인딩Nginx나 Apache 같은 리버스 프록시를 사용해 도메인에 따라 백엔드 서버로 트래픽 분기🧱 구조 예시[Client] |443 포트 요청 (도메인 A 또는 B) ↓[Nginx Reverse Proxy] (SSL 인증서 설정, 443 포트 점유) ├──> http://localhost:3001 (도메인 A용 웹 앱) └──> ..

apache와 nginx에서 쓰는 SSL 파일형식이 다름. 각각 만들어줘야 하지만, 통합해서 쓸 수 있는 방법이 있음.인증서와 체인 파일을 하나로 합친 파일을 생성하고, 이를 웹 서버에서 공통적으로 사용하도록 설정하면 됨.cat star_crt.pem ChainCA.crt RootCA.crt > fullchain.pemfullchain.pem 파일과 Private.key 파일을 웹 서버 설정apache 설정 ServerName example.com SSLEngine on SSLCertificateFile /path/to/fullchain.pem SSLCertificateKeyFile /path/to/Private.keynginx 설정server { listen 443 ssl; ..

apache와 nginx에서 쓰는 SSL 파일형식이 다름. 각각 만들어줘야 하지만, 통합해서 쓸 수 있는 방법이 있다.인증서와 체인 파일을 하나로 합친 파일을 생성하고, 이를 웹 서버에서 공통적으로 사용하도록 설정하면 된다.cat star_crt.pem ChainCA.crt RootCA.crt > fullchain.pemfullchain.pem 파일과 Private.key 파일을 웹 서버 설정apache 설정 ServerName example.com SSLEngine on SSLCertificateFile /path/to/fullchain.pem SSLCertificateKeyFile /path/to/Private.keynginx 설정server { listen 443 ssl;..

Host nginx reverse proxysudo apt updatesudo apt -y install nginxsudo nginx -vdocker run -dit -e SERVER_PORT=5001 -p 5001:5001 -h alb-node01 -u root --name=alb-node01 dbgurum/nginxlb:1.0docker run -dit -e SERVER_PORT=5002 -p 5002:5002 -h alb-node02 -u root --name=alb-node02 dbgurum/nginxlb:1.0docker run -dit -e SERVER_PORT=5003 -p 5003:5003 -h alb-node03 -u root --name=alb-node03 dbgurum/nginxlb:..

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이런 내용의 에러 였다.구글링을 해보니, 프록시 서버에서의 읽는 시간과 연결 시간이 너무 짧게 설정되어 있어서 해당 오류가 뜬다..

ollama를 외부접속하게 만들려고 한다. 그래서 ollama 설치 후, systemd 등록 파일로 프로세스를 띄웠다.[Unit]Description=Ollama ServiceAfter=network.target[Service]ExecStart=/usr/local/bin/ollama serveUser=rootRestart=alwaysRestartSec=3Environment="OLLAMA_HOST=0.0.0.0"[Install]WantedBy=multi-user.targetdefault 가 127.0.0.1:11434로 프로세스가 띄워지기 때문에 외부에서 접속할 수 있게 0.0.0.0:11434으로 띄워야 한다. Environment="OLLAMA_HOST=0.0.0.0" 으로 등록하여 anywhere로..