테스트 서버 환경 구축

Nginx와 테스트 대상 블로그 앱, 테스트 DB를 이용해서 실제 운영 환경과 유사한 테스트 서버 환경을 구축하고, 이를 활용하여 블로그의 페이지네이션 기능을 검증하여 실제로 운영서버에 배포하는 과정을 마쳤습니다.

핵심

테스트 중 데이터베이스 조회가 안됐습니다. 원인은 .env에서 DB_SCHEMA를 쓰지 않아서 테스트 블로그가 블로그 포스팅들을 test_blog 스키마가 아닌 public 스키마에 접근했던 것이었습니다. 또한, postgres 프로세스가 사용 중인 포트도 5432가 레플리카 DB고 5433가 테스트 DB라서 포트 환경변수도 수정해야했습니다. 테스트 블로그는 5433에 연결하도록 말입니다. 각각을 환경변수에 추가 및 수정해주고 백엔드를 restart하니 정상동작했습니다.

학습 주제

질문과 탐구

test.chanwook.kr이라는 서브도메인을 통해 외부에서 접근 가능한 테스트 환경을 구축하고, 그 안에서 페이지네이션 기능이 올바르게 동작하는지 확인했습니다. 그 과정에서 나온 주요 질문들은 다음과 같습니다.

• 공유기 포트포워딩만으로 도메인별 트래픽 분기가 가능한가?
• Nginx를 이용한 리버스 프록시 설정 방법은 무엇인가?
• 테스트 서버 환경에서 PostgreSQL 데이터베이스를 안전하게 관리하고, 운영 환경과 분리하는 방법은 무엇인가?
• relation "posts" does not exist와 같은 PostgreSQL 오류의 원인은 무엇이며, 어떻게 해결하는가?
• search_path 역할과 적용 방법은 무엇인가?
• 수정이 필요한 환경변수는 무엇이고 어떻게 바꿔야 하는가?

이러한 질문들을 바탕으로 Nginx 설정, PostgreSQL 스키마 관리, 그리고 Node.js 백엔드 환경 변수 설정까지 여러 단계를 탐구하며 문제점을 해결해 나갔습니다.

핵심 학습 내용

Nginx를 활용한 도메인 기반 트래픽 분기

가정용 공유기의 포트포워딩 기능만으로는 도메인별로 다른 내부 포트로 트래픽을 보내는 것이 어렵다는 것을 알게 되었습니다. 대신, Nginx의 리버스 프록시 및 가상 호스트(Virtual Host) 기능을 활용하는 것이 정석임을 배웠습니다.

• 기본 구조: 공유기에서는 80/443 포트만 Nginx 서버(worker1)로 전달하고, Nginx에서 server_name을 기준으로 각 도메인을 알맞은 내부 서비스로 프록시합니다.
• 예시 Nginx 설정:

server {
    listen 80;
    server_name test.chanwook.kr;

    location / {
        proxy_pass http://192.168.0.102:4321; # 테스트 프론트엔드
        # ... proxy_set_header 설정 ...
    }

    location /api/ {
        proxy_pass http://192.168.0.102:3000; # 테스트 백엔드
        # ... proxy_set_header 설정 ...
    }
}

PostgreSQL 스키마 분리와 search_path 설정

운영 DB와 테스트 DB를 분리하고, 테스트 DB 내에서 테이블 접근 문제를 해결하기 위해 노력했습니다.

• 문제 상황: 백엔드에서 SELECT * FROM posts;와 같은 쿼리를 실행했을 때, relation "posts" does not exist 오류가 발생하는 경우.
• 원인: PostgreSQL은 search_path에 설정된 스키마 순서대로 테이블을 찾는데, 기본값(public 등)으로는 test_blog 스키마의 테이블을 찾지 못하기 때문입니다.
• 해결책:
  Node.js .env 설정: DB_SCHEMA=test_blog 환경변수를 추가하여 백엔드 애플리케이션이 연결 시 test_blog 스키마를 사용하도록 합니다.
  애플리케이션 재시작: 설정 변경 후에는 Node.js 애플리케이션(pm2)을 재시작하여 새로운 connection pool이 적용되도록 해야 합니다.

Node.js 백엔드와 PostgreSQL 연동 시 주의사항

• process.env.DB_SCHEMA 활용: Node.js 애플리케이션에서 pg 라이브러리를 사용할 때, client.query(SET search_path TO ${schema});와 같이 .env 파일에서 설정된 DB_SCHEMA 값을 동적으로 적용하는 것이 유연한 테스트 환경 관리에 중요합니다.
• connection pool: Node.js 서버는 connection pool을 사용하여 DB에 연결하는데, ALTER DATABASE와 같은 DB 레벨 설정 변경이 이미 생성된 connection에는 즉시 적용되지 않을 수 있습니다. 따라서 pm2 restart --update-env 또는 pm2 restart all과 같이 애플리케이션을 완전히 재시작해야 합니다.

이해한 내용

이번 학습을 통해 test.chanwook.kr 서브도메인을 통해 외부에서도 접근 가능한 테스트 환경을 성공적으로 구축했습니다. Nginx 설정을 통해 test.chanwook.kr로 들어오는 트래픽이 worker2의 테스트 프론트엔드와 백엔드로 안전하게 전달되도록 구성했습니다.

특히 PostgreSQL에서 relation does not exist 오류가 발생하는 근본적인 원인이 search_path 설정과 Node.js 백엔드에서 DB_SCHEMA 환경변수를 제대로 사용하지 않았기 때문임을 명확히 이해했습니다. test_blog 스키마에 테이블이 존재함에도 불구하고, public 스키마만 탐색하도록 설정되어 있었던 것입니다.

DB User 별 search_path 설정과 .env 파일을 통한 DB_SCHEMA 환경변수 관리가 얼마나 중요한지 체감했습니다.

실전 적용

• 현재 환경: test.chanwook.kr 도메인을 통해 외부에서 접속 가능한 테스트 환경이 구축되었습니다.
• 페이지네이션 기능 테스트: 실제 운영 데이터와 유사하게 구성된 test_blog 스키마의 테스트 DB를 사용하여 페이지네이션 기능이 올바르게 동작하는지 검증할 수 있게 되었습니다.
• 안전한 기능 개발: 이 테스트 환경을 통해 새로운 기능 개발이나 대규모 데이터 테스트를 운영 환경에 영향을 주지 않고 안전하게 진행할 수 있습니다.
• 실습 계획:
  • 테스트 DB에 10,000개 이상의 더미 데이터를 삽입하여 페이지네이션 및 API 응답 속도를 측정합니다.
  • 다양한 케이스(예: 데이터 없음, 마지막 페이지 등)에서 페이지네이션이 정상적으로 작동하는지 테스트합니다.
  • test.chanwook.kr 환경에서 SSL 인증서 적용 여부를 다시 한번 확인합니다.

추가 학습 계획

• 블루그린 배포: 현재 테스트 환경 구조를 활용하여 무중단 배포(블루그린 배포)를 구현하는 방법을 학습하고 싶습니다. Nginx 설정 변경만으로 운영 환경 전환까지 가능하게 만드는 과정을 이해하고 싶습니다.
• CI/CD 파이프라인: GitHub Actions 등을 연동하여 코드 변경 시 자동으로 테스트 서버에 배포하고, 통과 시 운영 서버에 배포하는 CI/CD 파이프라인 구축에 대해 더 깊이 공부할 계획입니다.
• PostgreSQL 최적화: 테스트 DB에 대규모 데이터를 넣었을 때 성능 저하가 발생한다면, DB 인덱스 생성 및 쿼리 최적화 기법에 대해 학습할 필요가 있습니다.

참고 자료

• Nginx 공식 문서: https://nginx.org/en/docs/
• PostgreSQL Documentation: https://www.postgresql.org/docs/
• Node.js pg 라이브러리 문서: https://github.com/brianc/node-postgres