현재 제가 일하고 있는 환경에서는 로드밸런싱(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. 

Webwork에는 재밌는 기능이 하나 있습니다. 그것은 요청 파라메터를 모델 객체로 바로 매핑 시켜주는 기능입니다. 예제 코드를 만들어 보았습니다.

public class Param extends ActionSupport {

    private final static Log log = LogFactory.getLog(Param.class);
    private Person person;
   
    public String execute() {
        log.info(person.getName());
        log.info(person.getAge());
        return SUCCESS;
    }
    public Person getPerson() {
        return person;
    }

    public void setPerson(Person person) {
        this.person = person;
    }

    private class Person {
        private String name;
        private Integer age;

        public Integer getAge() {
            return age;
        }
        public void setAge(Integer age) {
            this.age = age;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
    }
}

위와 같은 액션을 만든 후 아래와 같이 접근해보면,
http://localhost:8080/Param.action?person.name=Min&person.age=90

콘솔에 이름과, 나이가 찍히게 됩니다. GET파라메터가 객체로 바로 매핑 된 것입니다. 내부적으론 Person객체의 setter들이 호출 될 것입니다.

처음 보았을 때는 상당히 유용한 기능이라고 생각했습니다. 반복되는 코드의 작업을 줄여줄 것이라 생각했기 때문입니다. 하지만 좀 더 사용하다보니 절대 사용하지 말아야 하는 기능 중에 하나라고 생각하게 되었습니다.

이유는 "모델 객체가 요청 파라메터의 영역으로까지 영향을 미치게 되었기 때문"입니다. 즉 모델과 요청 파라메터 사이에는 강한 결합(Tight coupling)이 발생한 것입니다. 만약 위의 person.name, person.age와 같은 파라메터가 여기 저기(JSP or JS 등)에서 사용되고 있는 상황에서, 어떤 이유로 Person 객체의 name 필드가 nickname으로 수정되고 setter 또한 setNickname으로 수정되어야 한다고 가정 해봅시다. 이 때 여기 저기 노출되어 있는 파라메터명이 모두 수정(person.name->person.nickname)되어야 합니다. 아마 단순히 서블릿만을 사용해 본 신입 개발자도 의아한 표정으로 물어볼 것입니다.

"모델 클래스를 변경했을 뿐인데 왜 파라메터명들이 모두 바뀌어야하죠? 제 서블릿 코드는 자바 코드만 고치면 되는데요."

그렇습니다. 지금 상황에선 차라리 예전 서블릿에서 많이 쓰던 아래와 같은 코드가 낫습니다.

String name = request.getParameter("name");
String age = request.getParameter("age");
Person person = new Person();
person.setName(name);
person.setAge(age);

(참고. 서블릿과 구 프로그래밍 방식이 무조건 좋다는 말은 아닙니다. 요청과 모델 사이에 매핑 코드가 존재하는 구조가 좋다는 말입니다.)

위와 같은 코드는 모델이 바뀐다고 요청 파라메터까지 바뀌지 않아도 됩니다. 우리는 이것을 흔히 "느슨한 결합( Loose coupling)"이라고 얘기합니다. 사실 원래 신경쓰지 않아도 우리가 늘 해온대로만 코딩해도 느슨하게 이루어지던 부분입니다. 그런데 위의 경우에는 소위 새로운 무엇이라고 불리는 것이 오히려 기존의 장점을 없애고 해악을 끼쳤다고 볼 수 있겠습니다.

그렇기 때문에 우리는 새로운 기술을 적용할 때 좀더 신중해야합니다. 새로운 것이 항상 긍정적인 효과만을 가져다주진 않기 때문입니다. 그리고 위 서블릿의 예에서 볼 수 있듯이 오래된 방식이라고 해서 항상 퇴출해야 하는 것만은 아닙니다. 오래된 것은 오래된 것 나름대로의 숙성된 향이 있기 때문입니다. :)

예상 반론. 누군가는 변화가 발생했을 때 기존의 setter 인터페이스를 그대로 유지하면서 새로운 인터페이스로 위임하면 되지 않겠느냐고 말할 수 있겠습니다. 물론 이것은 분명히 하나의 해결책이 될 수 있습니다. 하지만 좋은 해결책은 아닙니다. setter가 많아짐으로 인해 클래스의 복잡도(setter가 많은 것도 복잡도가 높아지는 요인이라고 생각합니다)가 증가하기 때문입니다. 또한 구 setter들 위에 다른 개발자를 위해 주석을 달아놔야 할 것입니다. "기존 웹 파라메터와의 호환성을 위해 유지함"이라고 말입니다.

이 후 로컬 환경에는 클라이언트 모드를 사용하고 있습니다만, 사실 속도차를 체감하진 못합니다. 그래도 서버 모드보다는 나을 것입니다. 필요없이 복잡한 최적화를 하지 않을테니까요. :)