시스템 구성은 3대의 서버가 각각 apache와 resin을 돌리고 있고 앞단에 LVS가 DR방식으로 구성되어 있으며 LVS가 Sticky Enable로 되어이지 않고 랜덤하게 리퀘스트를 분배하도록 되어 있습니다.

제가 의문이 생기는 부분은 다음 두가지 입니다.
- 리진 인스턴스 간의 통신에 장애가 발생한 원인 (네트워크 장애는 없었음)
- 세션클러스터링을 위한 리진 인스턴스 간의 통신에 장애가 발생했더라도 인스턴스 자체의 웹 서비스는 정상적이어야 하는데 왜 해당 인스턴스 조차 응답을 안하는지

제시하신 L4에서 Sticky를 지원하고 각 서버당 두개의 리진 인스턴스를 올리는 대안에 대해서는 공감합니다. 하지만 그 방식은 서버의 HW적인 장애가 발생하거나 두개 인스턴스가 동시에 장애가 발생하는 경우 페일오버가 되면 세션이 무조건 끊어진다는 단점이 있습니다. 따라서 저희는 이 구성이 최선의 선택이라고 생각되어 이렇게 구성한것입니다.

위 사항에 대한 문제가 해결되지 않는다면 리진의 TCP-Ring방식의 세션 클러스터링은 신뢰할 수 없다고 보입니다. 

그리고 이번 장애와는 직접적 관계가 없지만 리진의 세션클러스터링에서 아쉬운 부부입니다.
- 페일오버의(Sticky방식으로 동작하므로 리진자체에서 페일오버가 됨) 조건이 리진 인스턴스의 응답여부만을 따지기 때문에 리진은 응답하나 장애가 발생한 경우는 비정상 작동합니다. L4나 LVS와 같이 응답 패킷의 특정 문자열 체크하는 것이 필요합니다.
- 답변에서 언급하신 바와 같이 두대이상의 서버에 동시 장애가 발생하면 페일오버시 세션이 끊어질수 있습니다.

Resin의 Tcp-ring을 이용한 Session  Clustering 구성은
말씀하신바처럼 3대의 시스템에서 2대가 동시에 문제가 발생하였을 때
나머지 한대에서 문제가 발생한 2대에서 생성된 Session을 
보유하고 있을 확률은 50%입니다. 
만일 3대에서 1대의 서버가 문제가 발생한다면 100%의 확률로
Session을 Take-Over할 수 있습니다.
즉 TCP-RING방식은 나름대로의 한계점과 장점을 동시에
갖고 있는 Session Clustering방식입니다.

만일 3대의 시스템중 2대의 시스템에서 문제가 발생하였을 때
나머지 1대의 시스템에서 100% Session을 Take-Over하려면
JDBC-Store를 이용할 수 있습니다. 이는 각 서버별로
생성되는 Session을 한 곳의 DB에 저장하는 방식이므로
당연히 Fault Tolerant가 매우 높습니다
다만 이 방식 역시 DB에 많을 부하를 줄 가능성이 있으므로
역시 장단점을 갖고 있는 방식입니다.

TCP-RING이나 JDBC를 이용한 Session Clustering은 
각각 Resin인스턴스간의 소켓통신과 DB부하라는 단점을
가지고 있으며 특히 TCP-RING방식은 Resin자체가 서비스가 제대로 안되는 상황에서는
Session Backup과 Retrive를 위한 인스턴스간의 통신자체가 안될 가능성이
있습니다. 제가 보기에는 이러한 상황이었던 것으로 보입니다.

또하나 Resin에서 제공하는 Session클러스터링은
해당 File시스템을 이용하는 File-Store방식입니다.
이것은 인스턴스간의 통신이나 DB부하문제는 없으나 
단일시스템내의 인스턴스간에만 활용할 수 있습니다.

그리고 LVS에서 각각의 서버별로 랜덤하게 Request를 보내더라도
현재 구성하신 시스템에서는 각 시스템의 아파치플러그인이
로드발란싱과 다시하게 됩니다. 즉 LVS에서 1번으로 Request를 보냈다고 해도
1번의 Plugin이 1번의 Resin인스턴스에 Request를 할당하지는 않습니다.
Request의 Session을 보고 이에 해당하는 Resin에게 다시 보내게 됩니다.

참고하시기 바랍니다.