개발을 하다보면, Queue를 써야 하는 경우가 종종 있습니다. 뭔가를 비동기 적으로 처리하기 위해서, 또는 다이렉트로 들어가는 부담을 줄이기 위해서…
그런데 그러다보면 항상 고민되는 것이 바로 HA 입니다. 뭐, Queue의 모든 데이터가 날아가도 된다. 이러면 사실 큰 문제가 아니겠지만… 일반적으로 Queue의 데이터를 그렇게 날려도 되는 경우는 많지 않습니다.
일반적으로 많이 사용하는 Queue 는 여기서 소개할 RabbitMQ, ActiveMQ, Redis 기반의 Resque나 SideKiq(Resque 보다는 Sidekiq이 ㅎㅎㅎ) 아니면, 로그나 이런 대규모 부하에서는 거의 디팩토인 kafka 가 있습니다.
일단 각각 장단점이 있기 때문에, 여기서는 꽤 안정성을 보장해 주는 RabbitMQ의 HA를 구성하는 설치에 대해서만 설명하도록 하겠습니다.(다만 RabbitMQ의 경우는 운영하다 Consumer 가 느리면… 뻗어버리는 단점이…)
사실 설치 자체는 RabbitMQ 사용법을 그대로 따르면 됩니다. 별로 어려운 것도 없습니다.
CentOS면 yum으로, Ubuntu 면 apt로 쉽게 설치가 가능합니다. Rabbitmq 공식 페이지를 참조하면 됩니다.
그리고 보통은 클러스터를 설정합니다. 이 설정 방법도 쉽습니다. erlang 쿠키를 맞춰주고, join_cluster 만 해주면 됩니다. RabbitMQ HA Guide를 참고하시면 쉽습니다.
그러면 무엇을 해야하는가? 바로 이 Cluster가 그냥 쓰면 장애의 원인이 되기 때문입니다. 기본적으로, RabbitMQ에서 Cluster 모드가 되면, 채널 정보가 보통 Disk Node 에 저장되게 되는데, 이 서버가 내려가면… 해당 채널들은 모두 사용이 불가능해집니다.(장애시, HA를 하려고 설정한건데… 도리어, 장애가 나는거죠. 물론 그냥 죽어도 장애긴 합니다.)
그럼 제대로 RabbitMQ에서 HA를 구성하는 방법은 무엇일까요?
바로 mirrored queue를 운영하는 것입니다. RabbitMQ는 mirroed queue 라고 해서, 해당 Queue의 내용이 클러스터된 서버내에 중복되어 저장되는 기능을 의미합니다. 다만, 디폴트 설정으로는 설정이 된 시점의 데이터 부터, 복사가 되고 그 이전의 데이터는 복사되지 않습니다. (물론 이것도 옵션에 의해서 모두 가져가도록 할 수 있습니다.)
Mirrored Queue가 구성하는 방법 역시 RabbitMQ HA Guide에 잘 나와있습니다.
rabbitmqctl set_policy ha-all "^ha\." '{"ha-mode":"all"}
이러면… ha. 으로 시작하는 queue 들은 mirrored 형태로 구성하겠다는 것입니다. 실제 web ui에서 보면 Queue 이름에 두대로 클러스터가 되었다면 ha.test +1, 세 대라면 ha.test +2 식으로 구성되어야만 제대로 설정이 된 것입니다.
이제 어떤 서버로 연결할 것인가의 이슈가 생깁니다. 앞에 Load Balancer 를 붙여서(haproxy든 L4든) 장애난 서버를 제외하고 연결하게 하면… 제대로 된 서비스가 가능해집니다.
