[Tomcat] bindOnInit : Socket listener binding 시점을 결정

문제상황

Client로부터의 요청이 많이 들어오는 환경에서 Load Balancer 하위의 WAS Cluster 중,

1. Autoscaling out이 수행되어 신규 WAS가 기동되었을 때

2. 긴급한 소스 및 설정 반영을 위해 WAS를 중지 후 기동하였을 때

3. 인스터스 자원이 부족하여 해소를 위해 WAS를 재기동하였을 때

해당 WAS에서 Client의 요청에 응답하지 못하는 상황이 발생할 수 있다. 분명 Load Balancer는 WAS의 소켓이 떠서 트래픽을 전달하였지만 WAS의 Connector가 아직 기동하지 않아서 요청을 받아주지 못한것이다.

일반적인 해결방법

1. Load Balancer에서 HealthCheck방식을 WAS의 소켓 점검이 아닌, WAS의 특정 페이지를 호출하여 200 상태코드를 받는것으로 변경한다. 이 방법은 Http Request가 가능한 Load Balancer만 가능하다.

2. 평균적인 WAS의 기동시간을 측정하여 Load Balancer가 이보다 긴 대기 시간 이후 WAS로 트래픽을 전달하게 한다. 만약 예상치 못하게 설정된 대기 시간보다 WAS의 기동시간이 오래 걸리면 역시 문제가 계속 존재하게 되는것이고, 이런 점까지 감안하여 대기 시간을 더 넉넉하게 설정하게 되면 WAS로 트래픽이 유입되는 시점이 늦어져 부하게 기민하게 대응하지 못하게 된다.

WAS의 설정으로 해결

WAS의 Connector 속성 중 bindOnInit 속성 값 변경으로 해결한다. binOnInit은 Connector와 Socket listener를 바인딩 하는 시점을 결정하는 속성이다.

• bindOnInit="true"일 경우 Connector가 생성되는 시점에 Socket listener가 바인딩 된다. 즉, 아직 Connector가 정상 기동되지 않은 상태에서 Socket이 먼저 연결되어 트래픽이 유입되어버리는 상황이 발생할 수 있다. Connector 삭제에 적용되는 매커니즘 역시 동일하다.

• bindOnInit="false"일 경우 Connector가 생성되고 기동이 완료 될 때 Socket listener가 바인딩 되므로, Socket listener가 뜸과 동시에 서비스 접속이 가능하다. Connector 삭제에 적용되는 매커니즘 역시 동일하다.

적용 방법 : server.xml을 열어 http connector 혹은 ajp connector 영역에 작성한다.

<Connector executor="ajpThreadPool" ... bindOnInit="false" />
<Connector executor="httpThreadPool" ... bindOnInit="false" />

정리

위와 같은 상황은 부하가 많지 않을 경우 쉽게 발생하지 않고, 부하가 많더라도 Socket listerner가 Connector에 바인딩 되는 시간이 길기 않기 때문에 소수의 사용자들에게만 일시적으로 어플리케이션 접속 불가 현상이 발생할 것이다. 또한 위에서 기술한 일반적 해결방법들로도 해결이 가능하다. 하지만 WAS의 설정 변경으로 이 문제를 원천 차단할 수 있기 때문에 이 방법의 적용을 권장한다.