처음 파일 백업 및 공유용으로 NAS를 구매했을 때에는 파일 공유 외에는 별 다른 기능이 없었습니다. 이후 후 가벼운 웹서버 기능이 들어가면서 자동 설치로 워드프레스 등을 사용할 수 있었는데요. 몇 년 전부터는 아예 도커에 이미지를 올릴 수 있는 기능까지 추가되더라고요. 소규모 스타트업이라면 이것 하나로 메일 서비스, 백오피스, 웹사이트까지 다 운영을 할 수 있겠죠? 스타트업이 아니더라도 심심하신 분들이라면 관심이 좀 있을지도 모르겠네요. 저처럼…
방구석에서 나만 쓰는 시스템이라면 사실 별 다른 작업 없이도 NAS에서 제공하는 기능들을 쉽게 사용하실 수 있습니다. 하지만, 바깥쪽 하고 연결된 서비스를 구성하고 싶으신 – 예를 들면 블로그 운영 같은 – 분들이라면 네트워크에 대한 기본지식이 없이 작업하시기 어려움이 있을 거예요. 인터넷을 뒤지면 현재 봉착한 문제를 해결하는 것쯤은 쉽게 하실 수 있겠지만, 나중에 구조를 변경하거나 확장하려 할 때 또 처음부터 고생을 하게 되실 수 있는 거죠. 그래서, 저와 비슷한 취미를 가지고 계신 분들을 위해 조금 쉽게 네트워크 서비스가 작동하는 구조를 설명드려볼까 합니다. 좀 더 구체적으로 말씀드리자면,
외부에서 도메인 네임을 통해 방구석 NAS에 올려둔 도커 서비스(웹사이트)에 접근하는 네크웍 구조에 대한 설명
정도가 되겠네요. 자 가봅니다.
먼저 제가 도메인을 가지고 있는 상황이라 가정해볼게요. 이 도메인 네임은 네임서버 서비스를 통해 제 공인 IP와 연결해두었을 겁니다. 그러면, 도커에 올린 서비스까지는 아래와 경로로 접근이 될 겁니다.
사용자가 URL(도커에 올린 서비스로 연결된 도메인)을 브라우저에 입력하면 네임서버를 통해 미리 연결해 둔 제 공인 IP를 찾아 서비스를 요청할 겁니다. 일반 웹 서비스이니 80 포트로 호출을 하겠죠? 그때 가장 먼저 만나게 되는 게 제 공유기예요. 그러면, 공유기에서는 사용자의 요청을 수행할 수 있는 서버 쪽으로 연결해주는 작업을 해야 합니다. 저 공유기의 바깥쪽은 외부고, 안쪽은 내부이며 이 두 네트워크는 서로 독립적으로 존재합니다. 공유기가 그 둘을 연결해주고 있는 거예요. 단지 연결뿐 아니라 공유기 안쪽 내 방 네트워크 전체를 구성하는 일을 하고 있죠. 두 네트워크가 분리되어 있으므로 외부 사용자는 NAS 내부의 IP를 알 수가 없고, 접근도 할 수 없습니다. 이때 공유기가 중재자 역할을 해주고 있는 거예요.
포트 포워딩: 컴퓨터 네트워크에서 패킷이 라우터나 방화벽과 같은 네트워크 게이트웨이를 가로지르는 동안 하나의 IP 주소와 포트 번호 결합의 통신 요청을 다른 곳으로 넘겨주는 네트워크 주소 변환(NAT)의 응용이다.
위키백과: 포트 포워딩
위키에 나와있는 포트 포워딩의 정의인데, 간단하게 사용자의 요청을 받아 그 내용을 처리할 수 있는 쪽(서버겠죠)으로 신호를 포워드 한다고 생각하시면 됩니다. 그렇게 신호가 NAS로 전달되면 NAS는 내부의 특정 도커 쪽으로 또 해당 요청을 전달해야겠죠.
리버스 프락시: 컴퓨터 네트워크에서 클라이언트를 대신해서 한 대 이상의 서버로부터 자원을 추출하는 프락시 서버의 일종이다. 그런 다음 이러한 자원들이 마치 웹 서버 자체에서 기원한 것처럼 해당 클라이언트로 반환된다. 관련 클라이언트들을 위해 임의의 서버에 접속하는 중간 매개체인 포워드 프락시 forward proxy 와는 반대로, 리버스 프락시는 관련 서버들을 위해 임의의 클라이언트가 해당 서버에 접속하는 중간 매개체이다.
위키백과: 리버스 프락시
NAS에서 내부의 도커 쪽에 요청을 전달할 때는 리버스 프락시를 사용합니다. 설명이 약간 복잡한데, 리버스 프락시를 설명하기 전에 먼저 포워드 프락시(보통 프락시라 부르면 포워드 프락시를 이야기합니다)에 대해 이야기해볼게요. 포워드 프락시는 사용자의 요청을 중간에 가로채서 원하는 것을 가져다주는 서비스예요. 사용자가 A라는 가게에서 사과를 사고 싶을 때, 심부름꾼처럼 활용한다고 보시면 됩니다. 그렇게 되면 사용자가 A라는 가게에 가지 않아도 – 가게 앞의 CCTV에 찍힐 일도 없음 – 사과를 얻을 수 있죠. 포워드 프락시 서버는 A라는 가게의 사과를 많은 사람들이 요청하면, 미리 사과를 사다 놓기도 해요. 그러면, 좀 더 빨리 사과를 받을 수 있겠죠? CDN 서비스들도 – 실제는 훨씬 복잡한 서비스나 기법들을 사용하지만 – 기본적으로는 이 구조를 활용하는 겁니다.
그렇다면, 리버스 프락시는 뭘까요? 사용자는 리버스 프락시 서버를 A라는 사과가게로 알고 요청을 한다고 생각하시면 됩니다. 프락시 서버는 미리 사과를 구매할 수 있는 가게(서버)를 알고 있다가 그쪽으로 요청해서 사과를 받아 사용자에게 전달하죠. 이해를 돕기 위한 설명이라 상세한 내용을 알고 싶으시면 꼭 해당 용어로 상세검색을 해보시기를 권합니다.
그림을 한번 다시 그려볼게요.
사실 NAS는 제품 이름이고, 해당 제품 안에 리버스 프락시 서버(서비스)와 도커 서비스가 같이 돌아가고 있는 거예요. 최신 NAS를 가지고 계신 여러분은 AWS 서비스를 손바닥 안에 보유하고 계신 겁니다. 관심 없으시겠지만…
그러면, 이제 실제로 공유기부터 하나하나 어떤 식으로 세팅을 해야 하는지에 대해 이야기를 해볼게요. 먼저 앞에서 이야기했던 대로 도메인만을 호출하면 웹서비스용 포트인 80 포트로 요청이 들어옵니다. 물론 공유기로요. 그러면, 공유기에서는 해당 요청을 리버스 프락시 서버로 포워드 해야 합니다. 여기서 이해를 돕기 위해 설정을 한번 해보죠.
- 도메인: domain.com
- 도메인과 연결된 공인 IP: 1.1.1.1
- NAS의 내부 IP: 192.168.1.2
- 리버스 프락시 서버 포트: 80/443
- 도커 로컬 포트: 8081
- 도커 컨테이너 포트: 80
먼저 사용자가 브라우저에 도메인을 입력하고 호출하면 기본 포트인 80으로 요청이 공유기에 도착하게 됩니다. 그러면, 공유기는 해당 요청을 포트 포워드로 리버스 프락시 서버에 전달해야겠죠? 이때 포트 포워드 내용은 80 포트를 NAS의 IP인 192.168.1.2의 같은 포트로 포워딩하게 설정해두면 됩니다.(SSL 사용을 위한 443 포트도 동일하게 설정을 해두세요)
만약 NAS가 아니라 아예 리버스 프락시를 위한 서버에 연결하는 것이라면 더 이해가 편할 텐데요. NAS는 대부분의 서비스를 DSM DiskStation Manager 이라는 나스 운영체제에 기능으로 만들어두었기 때문에 오히려 구조적인 이해를 하는데 어려움이 있습니다. 이 DSM을 하나의 웹서비스로 생각하시면 조금 이해가 편하실 거예요. 그리고, 이 DSM 웹서비스는 80 및 443 포트로 접근하도록 되어 있습니다. 그런 이유로 공유기에서 80 및 443으로 들어오는 요청을 그대로 NAS의 80 및 443 포트로 전달하는 거예요. 그렇게 되면 DSM의 리버스 프락시에서 해당 요청을 받을 수 있도록 세팅이 되는 겁니다.
다음은 리버스 프락시 서버의 세팅입니다. 만약 domain.com 외에도 domain2.com을 하나 더 사용하고 싶다고 가정해보죠. 그렇다면 동일한 공인 IP(1.1.1.1)의 80 포트로 두 요청이 모두 들어올 겁니다. 이 요청은 그대로 리버스 프락시 서버로 전달되겠죠. 그렇다면, 리버스 프락시 서버에서는 IP가 아닌 요청 Domain을 확인해야 부합되는 도커 쪽에 제대로 연결을 해줄 수 있을 겁니다. 그렇게 세팅 쪽에 호스트 이름(도메인)과 포트를 입력하고, 이를 전달할 대상 호스트(도커, 보통 localhost로 입력)와 도커의 로컬 포트를 지정해주면 모든 세팅이 완료됩니다. 그렇게 요청이 도커의 로컬 포트로 전달되면, 다시 도커에 정의되어 있는 컨테이너 포트로 전달되어 실제로 사용자에게 전달할 페이지를 뚝딱뚝딱 만들어 던지게 되는 거죠.
이런 방식으로 설정을 하면 NAS의 퍼포먼스가 허락하는 한도 내에서 여러 개의 도메인에 연결된 개별 웹서비스들을 제공할 수 있게 됩니다. 서비스별로 도커에 올리면 위의 내용 만으로 쉽게 운영이 가능하고, 한 도커에 올린 웹서비스에 여러 사이트를 올리고 싶다면 해당 도커의 웹서버 안에서 가상 호스트를 사용하시면 됩니다.
사실 기업에서 운영되는 센터도 위의 구조로 운영되는 거예요. 물론 사용자가 많다면 더 좋은 사양의 독립된 서버를 구성해야겠지만, – 소셜 네트워크 기업이 아닌 – 동시 사용자가 많지 않은 일반 제조업이나 스타트업의 소개 페이지는 이 정도로도 충분할 겁니다. 사실 하드웨어가 비약적으로 발전해서 가능한 이야기이긴 하지만… 물론 정보보호나 리스크 헷지 관점에서의 이중화나 보안솔루션 등은 비즈니스 특성을 고려하며 고민하셔야겠죠?
어쨌든, 정리한 내용이 나스를 사용하시는 분들께 좋은 정보가 되었으면 좋겠네요. 🙏🏻
