1% 네트워크 V : 서버측의 LAN에는 무엇이 있는가

V : 서버측의 LAN에는 무엇이 있는가

1% 네트워크 원리 을 읽고 정리한 문서입니다 ;)

웹서버의 설치장소

요즈음의 인터넷 환경에서는 위협의 증가와 IP 주소의 부족으로 인해 서버 앞 단에 방화벽을 두는 것이 일반적이다. 이는 특정 서버에서 동작하는 특정 어플리케이션에 액세스하는 패킷만 통과시키고, 나머지는 차단한다.

프로바이더 등이 운영하는 데이터센터 시설에 서버를 설치하는 경우도 존재한다. 이 경우 NOC에 직접 접속되었거나 IX에 고속 회선으로 접속되어 있기에 쾌적환 네트워크 환경이 보장된다.

하지만 어떠한 경우라도, 패킷은 라우터에서 중계되고 최종적으로 서버에 도착한다는 점은 달라지지 않는다.

방화벽의 원리와 동작

방화벽의 기능을 수행할 다양한 방법이 고안되었지만, 성능과 가격, 편의성 등의 이유로 지금은 패킷 필터링형이 가장 많이 보급되었다.

패킷의 헤더에는 통신 동작을 제어하는 제어 정보가 들어있으므로 이것을 조사하면 여러 가지 사항을 알 수 있다.

패킷 필터링의 조건을 설정할 때는 우선 패킷의 흐름에 착안한다. 웹서버 입장에서, 인터넷에서 보내오는 패킷은 흐름의 종점이 웹 서버가 되므로, 이것을 조건으로 설정하고 허용 규칙을 추가한다.

하지만 TCP에는 패킷을 받으면 정확하게 도착했는지를 송신측에 알리는 수신 확인 응답의 구조가 존재하므로, 웹 서버에서 인터넷측으로 흐르는 패킷 또한 존재한다. 그렇기에 송신처가 웹 서버의 주소와 일치하는 패킷도 통과시키게 된다.

어플리케이션을 한정할 때는 포트를 이용하며, 포트 번호를 조건으로 추가하여 원하는 어플리케이션의 네트워크 동작만 허용시켜야 한다.

패킷이 흐르는 방향이 아니라 액세스 방향을 판단하여 정지시켜야 하는데, 이 때 TCP 헤더의 컨트롤 비트를 사용하게 된다.

이렇게 컨트롤 비트를 사용하여 조건별로 허용 차단 규칙을 넣게 되면, 웹 서버가 기점이 되어 인터넷에 접속하려고 하는 것을 막을 수 있다.

UDP는 TCP와 달리 접속 단계의 동작이 없기에, TCP처럼 컨트롤 비트에 의해 액세스 방향을 판별할 수 없다.

패킷 필터링형 방화벽은 주소 변환의 기능도 가지고 있으므로, 이에 따른 설정도 필요하다.

방화벽은 이러한 규칙들에 의해 패킷을 판별한 후, 차단하는 대상이라면 패킷을 버리고 이 버린 기록을 남겨 추후 분석할 수 있게끔 하는 것이 일반적이다.

만일 버린 패킷의 기능 등 심화된 기능들이 필요한 상황이 아니라면, 패킷 필터링을 가진 라우터를 방화벽으로도 사용할 수 있다.

이렇게 설정하더라도, 패킷 중에 특수한 데이터가 포함되어 이것이 어플리케이션의 버그와 위험 부분을 건드린다 하여도 이는 방화벽이 감지하고 막을 수 있는 대상이 아니다.

정리

• 방화벽은 패킷 필터링형이 주로 쓰이며, 이는 송수신처 IP와 포트, 컨트롤 비트의 규칙을 가지고 들어오고 나가는 패킷을 허용할 것인지 매번 확인한다.
• 이러한 방화벽을 구축하는 것은 보안 향상에 지대한 역할을 하지만, 어플리케이션의 취약점을 감경해주는 역할을 하지는 않는다.

복수 서버에 리퀘스트를 분배한 서버의 부하 분산

서버에 액세스가 증가할 때는 회선을 빠르게 하는 것만으로 부족하고, 서버의 처리 능력이 관건이 되는 경우가 있다. 특히 CGI 등의 어플리케이션에서 페이지를 동적으로 만드는 경우는 더욱 중요하다.

서버를 고성능 기종으로 교체하는 방법도 있긴 하지만, 이는 한계 또한 존재하며 효율성이 낮기에, 복수의 서버를 사용하여 처리를 분담하는 분산 처리를 사용한다.

가장 간단한 분산 처리 방법은 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 것이다.

이를 위해 DNS 서버에서 분배하는 방법을 사용할 수 있는데, 이렇게 되면 DNS서버는 도메인 조회가 있을 때마다 등록된 여러 IP 를 라운드 로빈으로 순회하여 리턴해 준다.

하지만 이는 서버들의 하트비트 체크 또한 불가능하고, 기존 연결이 유지되어야 하는 동적 페이지 등의 경우에는 연결이 끊어지게 되어 사실상 사용이 매우 제한적이다.

위의 문제를 해결하기 위해 로드 밸런서 라고도 불리는 부하 분산 장치 기기가 고안되었다. 이는 L4 스위치라고 부르는 경우 또한 많다.

우선 DNS 서버에 기존 웹 서버 대신 이 L4 장비를 등록하고, 이제 이 기기가 연결을 어떠한 웹 서버에 전송할지 판단하게 한다.

만일 복수 페이지에 걸쳐있지 않은 단순한 액세스라면 웹 서버의 부하 상태가 가장 낮은 웹 서버로 연결될 것이고, 복수 페이지에 걸쳐있는 액세스였다면 이전의 리퀘스트와 같은 웹 서버로 전달되어야 한다.

이렇게 하려면 대화가 복수 페이지에 걸쳐있는지 판단하는 것이 요점인데, HTTP 연결 특성 상 모든 리소스에 대한 요청은 그때 그때 연결되고 종료되므로 기존 HTTP 방식으로는 판단할 수 없다.

리퀘스트의 송신처 IP 주소로 판별하기도, 프록시 서버의 가능성과 NAT 뒤에 존재하는 클라이언트일 확률이 높아 유의미하게 지표로 사용되기는 힘들다.

따라서 양식에 입력한 데이터를 보낼 때 그 안에 전후의 관련을 나타내는 정보를 부가하거나, 이러한 정보를 HTTP 헤더 필드(쿠키)에 추가로 부가하는 방법이 쓰이고 있다.

정리

• 서버의 연산 부하를 줄이기 위해, L4 계층에 로드 밸런서를 두어, DNS 연결을 이 기기로 등록시킨다.
• 이 로드 밸런서 장비는 단순 대화인지, 이전 요청에 이어지는 대화인지를 판별하여 어떤 웹 서버로 연결할 지 판별하고 포워딩시킨다.

캐시 서버를 이용한 서버의 부하 분산

부하 분산을 하는 방법 중 하나로, 역할에 따라 서버를 나누어서, 캐시 서버를 사용할 수 있다.

프록시라는 구조를 사용해서 데이터를 캐시에 저장하는 서버로서, 웹 서버와 클라이언트 사이에서 웹 서버에 대한 액세스 동작을 중개하는 역할을 한다.

웹 서버 대신 DNS 서버에 등록된 캐시 서버는 웹 서버에서 받아 보존해 둔 데이터를 읽고, 웹 서버측에서 데이터가 변경되었는지 확인하기 위해 웹 서버에 via 라는 헤더 필드를 추가하여, if-modified-since라는 필드를 통해 유효한 캐시인지 확인한다.

본래 프록시는 클라이언트측에 붙은 개념이었고, 이는 현재 포워드 프록시라고 부르는 것이다.

클라이언트측에서 캐시 기능을 사용하고, 추가로 방화벽을 실현하기 위해 존재했던 개념으로서, 포워드 프록시에서 리퀘스트 메시지를 일단 받아 인터넷을 향해 대신 전송함으로서, 위험한 사이트나 필요 없는 사이트에 대한 액세스는 금지할 수 있다.

단 이 포워드 프록시 사용을 위해서는 브라우저의 프록시 서버 세팅을 해야 하기에, 장애의 원인이 되기도 하였다.

따라서 이를 개량한 리버스 프록시가 존재하는데, 이는 브라우저에 프록시를 설정하지 않아도 사용 가능한 프록시 개념으로서, 서버측에 설치하는 캐시 서버에 채택하고 있는 방식이다.

리퀘스트 메시지에서 패킷의 헤더를 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 있는데, 이 방법을 트랜스페어런트 프록시라고 부른다. 네트워크의 길이 한 곳으로 수렴되게 만들고, 그 곳에 이 트랜스페어런트 프록시를 설치함으로서, 사용자가 이 프록시의 존재를 알아차릴 필요가 거의 없게끔 한다.

정리

• 캐시 서버는 웹서버 앞단에 위치하여, 사용자의 응답을 받아 캐시 리소스를 탐색 후 갱신 여부를 본 서버에 조회한 뒤 응답을 회신해준다

콘텐츠 배포 서비스

서버측에 캐시 서버를 두는 것은 웹 서버의 부하를 경감하는 효과는 있지만, 인터넷을 흐르는 트래픽을 억제하는 효과는 없다. 따라서 만일 클라이언트측에 캐시 서버가 존재한다면 대용량 데이터를 포함하는 콘텐츠를 송수신할 때 효과가 크다.

클라이언트측에 두는 캐시 서버는 해당 네트워크 관리자가 관리 주체이므로 매우 제한적이라 사용이 어렵기에, 몇몇 중요한 프로바이더와 계약하여 웹 서버 운영자도 제어할 수 있는 캐시 서버를 제공하는 사업자가 등장했는데, 이를 콘텐츠 배포 서비스(CDN)이라고 한다.

이러한 콘텐츠 배포 서비스를 사용할 때, 클라이언트로부터 가장 가까운 캐시 서버를 찾아서 그곳으로 중재하는 구조가 필요한데, 이를 위해 세 가지의 방식이 사용된다.

• DNS서버를 세밀하게 설정하여 라운드 로빈이 아니라 클라이언트와 가장 가까운 거리 순의 캐시 서버 IP를 리턴해주는 방식
• 사용자의 IP 주소를 분석 후 HTTP의 location 헤더를 사용하여 가장 가까운 캐시 서버 주소로 리다이렉트 시키는 방식
• 클라이언트에서 여러 캐시 서버로 패킷을 직접 보내 RTT가 짧은 서버를 직접 찾아내는 방식

캐시 서버의 효율을 좌우하는 요소 중 하나는 캐시의 내용을 어떻게 갱신하는지인데, 만일 웹 캐시 서버와 같이 사용자의 요청에 따라 그때그때 캐싱하고 갱신여부를 판별하는 방식은 효율이 좋지 않다.

따라서 웹 서버에서 원래 데이터를 갱신할 때 이를 즉시 캐시 서버들에 반영해야 하고, 콘텐츠 중 달라지는 부분과 달라지지 않는 부분을 구분하여 달라지지 않는 부분만 캐시에 저장해야 한다.

정리

• CDN을 이용하면 사용자의 가까이에 캐시 서버를 위치시킴으로서 네트워크 혼잡을 피할 수 있다
• CDN 서버를 선택하기 위해 DNS 방식, 리다이렉트 방식, RTT 방식이 사용된다
• 원본 서버에서 콘텐츠가 갱신된다면 이를 즉시 캐시서버에 반영하도록 한다