웹 서비스 기획의 기초, 분산 서버

조금 전 구글 지메일에서 파일을 다운로드하려는데 접속이 느려지더니 첨부 파일을 다운로드하는데 문제가 발생했다. 1.5KB/sec 정도의 속도로 느리게 다운로드가 진행되었다. 몇 번을 시도했지만 마찬가지였는데 5분 정도 지난 후 다시 다운로드를 시도하니 정상적인 속도로 첨부 파일을 받을 수 있었다.

이런 경우 문제는 2+3의 구조로 찾을 수 있다. '2'는 클라이언트와 서버 중 문제가 발생한 것이다. 내 컴퓨터 자체의 문제나 내가 속한 인터넷 서비스 제공자(ISP, Internet Service Provider)의 문제인 경우와 내가 접속한 서버 즉 구글 지메일 서버의 문제인 경우다. '3'은 둘 중 어디가 문제인가 혹은 문제가 없는가를 확인한 후 3가지 방법으로 또 다른 문제를 파악하는 것이다. 클라이언트 측 문제인 경우가 확인될 경우 행하는 방법과 서버 측 문제인 경우가 확실할 때 행하는 방법이다.

조금 전에 발생한 문제의 경우 traceroute라는 네트워크 명령어(윈도에서는 tracert 라는 명령어를 사용한다)를 통해 검증했을 때 내 컴퓨터에서 지메일로 접근하는 경로에 있는 많은 서버에서 특별한 문제가 발생하지 않았다. 다만 마지막 지메일에서 응답하는 서버 중 하나가 응답이 늦었는데 5분 정도 지난 후 다른 서버로 연결되어 문제를 해결하는 것을 알 수 있었다.

C:\Documents and Settings\Bluemoon>tracert gmail.com

Tracing route to gmail.com [64.233.161.83]
over a maximum of 30 hops:

  1     7 ms     9 ms     9 ms  10.51.0.1
  2     5 ms     8 ms     9 ms  172.21.21.1
  3    14 ms    24 ms    16 ms  172.20.0.66
  4    11 ms     9 ms     7 ms  211.180.12.169
  5     6 ms     9 ms     5 ms  210.120.248.82
  6   146 ms   147 ms   148 ms  203.255.234.222
  7   221 ms   156 ms   157 ms  203.255.234.170
  8   301 ms   221 ms   209 ms  216.239.48.1
  9   147 ms   203 ms   150 ms  209.85.130.6
 10   212 ms   150 ms   166 ms  66.249.94.226
 11   233 ms   259 ms   213 ms  66.249.95.214
 12   251 ms   162 ms   254 ms  209.85.248.222
 13   242 ms   250 ms   281 ms  64.233.175.171
 14   285 ms   347 ms   256 ms  216.239.48.190
 15   252 ms   240 ms   254 ms  od-in-f83.google.com [64.233.161.83]

Trace complete.

웹 서비스를 기획할 때 대용량의 저장 공간을 제공하는 서비스나 정보 이동이 극심할 것으로 예상하는 서비스, 대량의 사용자가 동시 접속하는 서비스의 경우 반드시 분산 서버 시스템을 고려해야 한다. 서비스의 항상성과 신뢰성을 유지하기 위해 서비스의 기획 초기부터 분산 서버 시스템을 고려해야 하고 그것은 서비스의 품질 뿐만 아니라 기술적 장벽이 되기도 한다. 방금 내가 경험한 지메일의 문제는 - 분명히 파악할 수 있는 것은 아니지만 - 지메일 특정 서버의 트래픽 과다로 인한 문제일 수 있다. 이런 경우 명석한 분산 서버가 존재하지 않으면 사용자는 해당 서버에 접속한 사람이나 트래픽이 줄어들 때까지 기다리는 수 밖에 없다.

대개의 웹 서비스 기획자들은 이런 문제를 그리 중요하게 생각하지 않고 이것에 대한 정확한 정보를 확보하지 못하고 웹 서비스를 기획하는 경향이 있다. 모두가 1천만 명 이상의 사용자를 위한 웹 서비스를 만들고 싶어하지만 정작 1천만 명이 사용하는 웹 서비스가 어떻게 구성되어야 하는지 아는 웹 서비스 기획자는 별로 없다. 그런 사람들이 그럴싸한 웹 서비스 기획안을 써 내곤 한다.

무식하여 용감한 것이 아니라 그냥 무식한 것이다. 웹 서비스 기획자가 그런 것을 모른다면 물어 보기라도 해야 할텐데 물어 보는 사람도 참 찾기 힘들다. 웹 서비스 기획은 인문학적 창작이기도 하지만 기술적 검증과 타협과 혁신과 학습이기도 하다. 기술적인 부분이 부족하면 내부의 전문가 - 대개 R&D 소속의 개발자들이다 - 에게 물어봐야 할텐데 무슨 자존심 때문인지 묻지 않는다. 그리고 개떡같은 웹 서비스를 기획한다. 껍데기만 그럴싸하고 만들 수 없는 웹 서비스를 기획한다.

물론 회사 R&D 소속의 개발자들이 멍청이일 가능성도 있다. 분산 서버의 구조에 대한 논문 하나 제대로 읽어 보지 못한 개발자들이라면 그런 사람들에게 물어봐야 제대로 답을 구하기 힘들다. 안타까운 일이지만 이런 개발자들이 제법 많은 것도 현실이다. 물어 보지 않는 기획자도 많고 그 질문에 답할 수 없는 개발자도 많다. 두 가지 문제를 모두 해결할 수 없다면 기획자가 먼저 문제를 해결해야 한다. 먼저 공부하고 질문하고 내부에서 답을 구할 수 없다면 바깥으로 뛰어 다녀라.

세상 어딘가에 반드시 답은 있다.