개요
이번에는 프록시 서버를 구현해보자!
- 원래는 프로젝트 내에서 Spring Clound Gateway를 사용해서 프록시 서버를 구현하려고 하였으나,
- 코틀린 버전 이슈가 있었고
- 범용적으로 사용되는 프록시 서버 중에 가장 많이 사용되는 것이 Nginx
- 그래서 Nginx를 프록시 서버로 사용해보려고 하고, Docker를 사용해서 Nginx 컨테이너를 띄우면, 요청을 보냈을 때 요청을 프록시를 해서 다른 서버로 보내는 역할을 하게 된다.
Nginx란?
Nginx 구조
Nginx 개요 기존 방식에서는 사용자 요청은 스레드 갯수로 따져가며 설계되다보니 많은 CPU, 메모리 자원이 활용되었다. 최근엔 동시접속자 수가 점점 늘어나고 있다보니 서버의 자원은 점점 느는
naeti.tistory.com
- 러시아에서 만들어진 웹 서버 프로그램
- 굉장히 가벼운 웹 서버
- 많은 요청이 들어왔을 때 좋은 성능을 보여줌
- Apache보다 더 많이 사용됨
- 가장 범용적으로 사용되는 웹 서버
Apache vs. Nginx
Apache
- request가 들어올 때마다 프로세스를 생성해서, 그 프로세스가 하나의 request를 처리
- request가 들어올 때마다 프로세스를 재할당을 해줘야 하기 때문에 오버헤드 발생
- Nginx 보다 무겁고 성능이 떨어진다.
Nginx
- 마스터 프로세스와 워커 프로세스를 Configuration에 따라서 미리 생성해 둠
- 마스터 프로세스는 설정 파일을 읽고, 워크 프로세스를 시작하며, 설정 변경 시 워크 프로세스를 재시작하는 등의 작업을 수행
- 워크 프로세스는 실제 요청을 처리
- 워커 프로세스의 개수를 적당히 정하는 것이 중요하다.
- 워커 프로세스 수가 적으면, 큐에 쌓이는 양이 많아서 응답 속도가 느려지고
- 너무 많은 프로세스를 띄우면 idle한 프로세스가 많기 때문에 자원의 효율성 측면에서 좋지 못함
- request가 들어오면 태스크 큐에 쌓아두고, 각각의 워크 프로세스가 여러 요청을 처리하는 형태
- 비동기(non-blocking) 처리가 가능하고, 이벤트 루프가 계속 돌면서 각각의 워커 프로세스가 태스크를 가져가서 처리
- 자원을 효율적으로 사용하고, 동시 처리에 뛰어난 성능을 보인다.
- 매번 프로세스를 생성하지 않기 때문에 오버헤드가 적고, 여러 개의 요청이 들어올 때 조금 더 좋은 퍼포먼스를 가진다.
정리하면,
- Nginx의 동작은 요청이 들어와서 테스크를 큐에 쌓아놓고, 워커 프로세스들이 이 데스크들을 처리를 한다.
- 그리고, 비동기 방식으로 처리를 하는 웹 서버
- 동시적인 처리에 굉장히 좋고
- 매번 프로세스를 할당하지 않기 때문에 조금 더 가벼운 웹 서버의 역할을 한다.
프록시란?
대리로 요청을 받고, 그 요청을 원래 보내려고 했던 목적지로 보내는 것
프록시 서버 종류
Forward Proxy
- 위치가 클라이언트 뒷단
- 클라이언트들이 request를 보낼 때, 바로 서버로 보내지 않고 모두 Forward Proxy로
- Forward Proxy가 직접적으로 서버에 요청을 보낸다.
- 특정 요청이 반복적으로 들어오는 경우 Forward Proxy에서 캐싱을 해둘 수 있다.
- 서버까지 도달하지 않고도 응답 가능
- 반복되는 요청이 서버에 부하를 주지 않음
- 클라이언트와 서버가 직접적으로 붙게 되면, 서버는 클라이언트의 정보를 대부분 알게 된다.
- 누군지 식별 가능
- 개인 정보 이슈 등
- 클라이언트와 서버 사이에 Forward Proxy를 두게 되면 서버는 어떤 클라이언트가 요청을 보낸 건지 알 수 없다.
- 보안적인 측면에서의 장점
- 장점
- 리소스 사용량 줄어듦
- 캐시 사용을 통한 빠른 응답
- 보안적으로 좋아짐!
Reverse Proxy
- 서버의 관점에서 바로 요청을 받는 것이 아니라 Reverse Proxy를 통해서 요청을 분할해서 받음
- 로드 밸런싱의 역할
- 요청이 가장 적은(커넥션이 가장 조금 맺어진) 서버에 보내기
- 가장 빨리 처리할 수 있는 서버에 보내기
- 보안적으로 좋아짐!
- 대부분의 서버는 회사 내부망에 존재 유저들은 외부망에 존재
- 외부망에서 내부망에 데이터를 요청하게 되는 것
- 외부망에서 내부망에 직접적으로 요청을 보낸다면, 내부망 서버들은 대부분 데이터베이스와 연결이 되어있기 때문에 유저의 요청이 흘러들어 가서 데이터베이스를 건드릴 수 있는 가능성이 있다.
- 따라서, Reverse Proxy를 둠으로써 유저가 직접적으로 닿을 수 없도록 함!
왜 작은 프로젝트인데도 프록시 서버를 두는 거야?
- 해당 프로젝트에서는 내부망에서 CB사로 요청을 보낼 때 결국 내부에서 외부로 요청을 보내는 것
- 그리고 응답을 받으면 외부에서 내부로 데이터가 들어옴
- 내부망과 외부망을 분리하고자 프록시 서버를 두는 것이다.
- 보안적인 관점이 가장 크다!
- 대부분의 핀테크 업체들은 회사 내 내부망도 있지만 전자금융거래법망(전금법망)을 사용.
- 이 전금법망은 인터넷과 완전히 차단됨
- 금융과 관련된 데이터들은 이 전금법망에서 처리하게 되고
- 외부와 통신을 할 때 조금 더 제한 사항이 많다.
- 외부랑 통신할 때는 노출구간을 최소화하기 위해 프록시 서버를 사용
- 대부분의 핀테크 서버는 전금법망 내에서 서버가 존재
- 서버는 외부와 통신할 일이 많음
- 프론트엔드 서버라면 유저가 프론트엔드 서버 쪽으로 요청을 보낼 것
- 백엔드 서버라면 다른 외부 금융사나 CB사에 요청을 보내거나 외부로부터 데이터를 받음
- 외부에 내부 서버를 직접적으로 노출하지는 않음
- 외부와 통신하기 위한 DMZ망(회색 지역)을 둔다.
- 이 DMZ망은 전근법망과 외부망 둘 다에 접근 가능
- DMZ망에 프록시 서버를 둔다.
- 그래서 외부와의 통신은 이 프록시 서버를 통해 들어가고 나가게 된다.
- 민감한 개인 정보가 노출되지 않도록 암호화 등 여러 가지 보안 장치를 하게 되는데...
- 외부와 통신할 때(금융사와 통신할 때) 인터넷을 사용하지 않고, 통신사에 요청해서 별도의 전용선을 구축
- 전용선을 통한 통신은 인프라적으로도 암호화를 진행해서 통신
- 로그를 확인할 때도 개인정보를 식별할 수 없도록 자체적인 암호화도 진행
- 개인 정보가 실제로 잘 관리가 되어야 위험으로부터 개인 정보를 잘 보호할 수 있음
- 프록시 서버를 둠으로써 보안 유지가 잘 되고 있는지 확인도 가능
- 전금법망 내에 프로젝트가 있다고 생각을 하고, CB 모듈이 외부에 있다고 생각을 해서 중간에 프록시 서버를 두는 것!
Nginx Docker 이미지 구현
docker run -d --name fintech-nginx nginxdocker exec -it fintech-nginx bash
consumer가 CB사로 요청을 보낼 때, 프록시 서버를 통하게끔 변경
hostname/css 로 들어오는 요청들을 css 모듈로 프록시
추가로, 도커 네트워크를 구성해서 컨테이너 이름으로 서로 통신할 수 있게끔 설정
nginx 폴더를 생성
default.conf
upstream css-api {
server fintech-css:8081;
}
server {
listen 8085;
location /css {
proxy_pass http://css-api/css;
}
}
Dockerfile
FROM nginx:latest
COPY default.conf /etc/nginx/conf.d/default.conf
CMD ["nginx", "-g", "daemon off;"]
Dockerfile로 이미지 굽기
docker build -t fintech-nginx:1.0.0 .
생성한 이미지를 컨테이너로 실행...하려고하면 아직 fintech-css가 없기 때문에 오류가 난다.
2024-05-24 12:05:19 2024/05/24 03:05:19 [emerg] 1#1: host not found in upstream "fintech-css:8081" in /etc/nginx/conf.d/default.conf:2
2024-05-24 12:05:19 nginx: [emerg] host not found in upstream "fintech-css:8081" in /etc/nginx/conf.d/default.conf:2
다음 시간에 전체 프로젝트 Docker image를 생성해 보고, Docker Compose를 해보도록 하자!
반응형
