며칠 전 회사에서 도메인 네임을 신청했다. app.회사이름을 A 와 B 라는 이중화된 서버로 할당해달라는 것.
이를 위해 시스템팀에서는 Z 라는 이름을 Virtual IP 를 L4 장비에 할당하여 Load Balancing 하게 하였다. (아래 그림 참조)
문제는 app.회사이름으로 연결이 되지 않는다고 앱 개발실에서 연락이 온 것.
확인해보니 Z 의 IP 로 웹서버가 연결되지 않았다.
시스템팀에 내려가니 하필 아무도 없어 SM 들에게 직접 문제의 해결을 요청했다.
SM들이 작업을 하는데 옆에 붙어서 계속 지켜보았다. 어떤 이유인지 쉽게 되지 않아 헤매는 듯 하였다.
이때 최근까지 WAS 및 네트워크를 담당하다가 보안팀으로 옮겨간 동기가 나타나서 무척 반가운 마음에 붙잡고 문제의 해결을 요청했다.
그런데 문제가 해결되지 않자 원인을 엉뚱한 곳으로 돌린 것.
“웹 서버에서 IP 를 지정해주는 게 있는데 그게 IP A 나 B 만 지정해준 것 같으니 Z에 대해서도 열리게 * 로 지정해줘요.”
“아니, 그건 서버에서 bind할 IP(and port)를 지정하는 부분이고, 여기서 필요한 건 그게 아니잖아.”
“뭘 안다 그래요 내가 전 WAS 담당자인데 내 말이 맞으니까 그렇게 해요.”
여기에서 그 동기가 말한 설정 부분은 IIS를 비롯한 거의 모든 웹서버에 있는, 어떤 IP에 대한 특정 포트를 listen할 것인가에 대한 이야기였다.
그리고 A, B 서버는 모두 각각 하나씩 유일하게 할당되어있는 IP에 대해 그 특정 포트를 listening 하고 있다.
이외에도 Virtual Host 를 결정해주는 부분도 웹서버에 있는데, 각 IP 에 특정한 호스트 이름으로 들어온 요청들을 별개의 가상 서버인 것처럼 서비스해주는 것.
하지만 이마저도 Z의 IP를 지정할 필요가 없고 * 혹은 A, B 가 각자의 IP를 지정하기만 하면 되는 것이다.
실제로 웹서버가 받는 메시지는 GET http://app.회사이름/index.html HTTP/1.1 과 같은 형태의 도메인 네임을 가진 메시지이고,
IP 는 Network Layer 에서 붙인 헤더에 있는데, L4 장비가 Z의 IP로 들어온 세그먼트를 까다가
Network Layer에서 나온 IP의 Z를 A, B로 바꿔치기하여 패킷을 재작성하고 A, B로 보내는 것이다.
그러므로 A, B 가 받는 패킷에는 Z 의 IP가 존재하지 않는다.
이미 Network Layer 의 목적지 IP 가 A, B 로 치환되었기 때문이다.
이후 IP 가 나올 수 있는 부분이 Application Layer 의 HTTP Header 에서 다시 한 번 있기는 한데, 이는 Virtual Host 에 대한 부분이며, 이 또한 현 상황에서는 IP 주소가 아닌 app.회사이름의 도메인명이 넘어오기 때문에 역시나 관계없는 이야기가 되겠다.
내가 SM에게 해당 부분을 지웠다가 다시 설정해달라고 하여 해결은 하였으나, 속 터질 뻔 했다.
뭐 사실 우리 회사에서는 흔한 일이다.
1. L4 에서 IP 를 변경해주는 것은 Network Layer(Layer 3)의 내용이다.
2. 웹서버는 자신이 bind할 IP와 port 를 지정한다.
3. 웹서버가 받는 받는 패킷의 Application Layer 는 URL 이 도메인 네임을 이용했을 경우 도메인 네임을 받는다.
4. 전산 전공이면 OSI 7 Layer 는 좀 달달 외우자!
