현재 제가 일하고 있는 환경에서는 로드밸런싱(Load Balancing)을 하기 위해 L4 스위치(이하 L4)를 이용합니다. 많은 분들이 잘 알고 계시겠지만 L4는 전방에 위치하면서 특정 서버군으로 들어오는 요청을 서버군 내의 각 장비로 균형있게 전달해주는 역활을 합니다.

그런데 L4를 이용하여 로드밸런싱을 하려면 최소한 물리적 장비가 2대 이상 있어야 합니다. 따라서 요청이 매우 적어 장비 1대만으로도 충분히 서비스가 가능할지라도, 로드밸런싱을 위해서 최소 2대를 배치해야 합니다.

소프트웨어 로드밸런싱이 가지는 의미는 위와 같은 점에서 찾을 수 있다고 생각합니다. 아파치-JK-톰캣으로 연결되는 소프트웨어 로드밸런싱은 1대의 장비만으로도 서버가 감당할 수 있는 만큼의 로드밸런싱을 가능하게 해줍니다. 주목해야 할 점은 최소 2대의 장비가 필요했던 것을 1대의 장비로 해결할 수 있다는 점입니다. 거기에 스위칭 비용도 약간의 CPU와 메모리만 사용하면 되니 거의 공짜라고 할 수 있겠습니다.

그렇다면 성능은요? 예 아쉽게도 성능은 하드웨어로 구동되는 L4 로드밸런싱에 비해 떨어질 수 밖에 없습니다. 하지만 때로는 성능이 큰 관심사가 아닐 때도 있습니다. 바로 요청이 거의 없는많지 않은 서비스의 경우입니다. 이런 서비스들에 로드밸런싱을 도입하려는 이유는 성능보다는 안정성 때문일 것입니다. 즉 하나가 서비스 불능 상태에 빠지더라도 나머지 하나가 서비스를 정상적으로 해주길 바라는 경우인 것이죠.

이번에 저희 팀의 상황도 위와 같이 성능보다는 안정성이 필요한 상황이였습니다. 1대의 장비에 2개의 서비스를 설치했습니다. 그리고 각 서비스들의 요청은 아파치와 JK를 통해 2개의 톰캣으로 로드밸런싱 되게 만들었습니다. 총 4개의 톰캣 프로세스가 동작하게 된 것입니다.  만약 기존대로 L$를 이용했었더라면 얼마나 더 많은 비용이 들었을까요?

사실 이번의 소프트웨어 로드밸런싱은 운영팀에 제안으로 이루어진 일입니다. 저는 이것이 정말 현명한 제안이였다고 생각합니다. 게다가 제안을 실행에 옮기고 나니 제 마음도 많이 기쁘네요. :)

HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms.

http://tools.ietf.org/html/rfc2045#section-5

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.