zookeeper 운영시 권장 사항

– Recommendations for operating zookeeper.

주키퍼를 운영하면서 얻은 나름의 경험을 정리해봅니다. 시간이 지나면서 이 글의 내용이 맞지 않게 될 수도 있겠지만, 현 시점에서 주키퍼를 운영하시거나 운영할 계획이 있는 분들에게 참고가 되었으면 합니다.

1. zookeeper is not DB, not noSQL, not Cache solution.
주키퍼를 DB나 캐시용으로 쓰지 마십시오. 처음에는 단순히 코디네이터 용도로 쓰다가 편의성 때문에 DB 처럼 쓰는 경우가 있는데 절대 금물입니다.
특히 heavy write는 주키퍼 클러스터의 성능에 매우 많은 영향을 끼치므로 피해야 합니다.

2. do servers only for zookeeper
가능하면 주키퍼를 위한 전용 서버를 구축하기를 권장합니다. 비용상의 문제로 별도의 한 서버에 다른 솔루션과 병행 운영을 해야 한다면, 해당 솔루션이 CPU나 I/O에 줄 수 있는 영향을 반드시 파악해야 합니다.

3. same network, same rack
주키퍼 클러스터는 최소 latency를 가지는 네트워크 상에 있어야 합니다. 가능한 같은 스위치 내, 같은 랙에 있는 것이 좋습니다. (당연히 서로 다른  IDC에 있는 서버끼리 주키퍼 클러스터를 구성하는 것은 말도 안되는 설정입니다.) EC2 같은 가상 환경에서 주키퍼 클러스터를 운영한다면 가상 머신을 호스팅하고 있는 물리 서버의 네트워크 거리를 확인하시기 바랍니다.

4. more servers, low (write) performance
주키퍼 서버를 많이 두는 것은 그만큼 가용성을 확보한다는 의미가 있습니다. 또한 서버가 많을 수록 read 성능은 증가하나 write 성능은 감소합니다. 그 동안의 경험상 주키퍼 클러스터는 5대로 구성하는 것이 가장 안정적이었습니다. 1대는 주키퍼 서버 자체의 장애에 취약하고, 3대는 장애가 날 경우 flapping 현상 등 주키퍼 노드끼리 혼란스러워하는 현상이 일어나기 쉽습니다.

5. off swap, tune GC, don’t specify memory too big to avoid stop-the-world
주키퍼가 사용하는 메모리는 가능하면 스왑 영역에 들어가지 않게 하는 것이 좋습니다. 주키퍼의 메모리 영역이 스왑 메모리를 사용하는 순간 I/O 성능은 급격히 떨어지고 이는 GC에도 영향을 미칩니다. 그리고 일반적으로 Full GC를 하는 동안 주키퍼의 실행은 잠시 멈추는데(stop-the-world), 이 시간이 길어지면 다른 주키퍼 노드가 타임아웃으로 오인할 가능성이 있습니다. 대게 한 클러스터의 주키퍼는 같은 설정을 가지고 있으므로, 어느 한 노드에서 이런 현상이 일어난다는 것은 다른 노드도 이런 위험성을 내포하고 있다는 뜻이 됩니다. 결국 클러스터 전체가 불안정성을 가지고 운영되는 셈입니다. 만약 이러한 현상이 일어난다면 GC 튜닝에 공을 들여야 합니다. JVM 프로세스가 메모리를 많이 사용하면 할 수록 일반적으로 Full GC 시간도 길어집니다.

– 많은 수의 문자열을 저장하는 것을 피할 것.
– GC 튜닝은 throughput 성능보다는 pause time을 줄이는 방향으로 할 것 -> 주키퍼에 저장하는 데이터 패턴에 따라 G1 GC가 유용한 경우가 많음.

6. specify session timeout – not too short and not too long
세션 타임 아웃 시간을 너무 짧게 잡아서도 안되고 너무 길게 잡아서도 안됩니다. 너무 짧게 잡으면 네트워크 지연이나 GC로 인한 정지 시간 등의 상황을 오인할 우려가 있고, 너무 길게 잡으면 장애시나 write시에 문제가 생길 수도 있습니다.
흔히 하는 실수가 session timeout과 connection timeout을 동일하게 여기는 것인데, session timeout = connection time * 호스트수 입니다. 만약 클러스터의가 다섯 대의 주키퍼로 구성되어 있고 connection timeout을 2초로 하고 싶다면, session timeout을 10초로 설정해야 합니다.

7. log level, log directory
특별한 이유가 아니라면 LOG 레벨을 DEBUG나 INFO로 설정하지 마세요. 그리고 가능한 로그 파일은 주키퍼 데이터가 저장되는 하드디스크가 아닌 별도의 하드디스크에 저장하는 것이 좋습니다.

8. do test, test, test
서비스에 투입하기 전에 반드시 주키퍼 클러스터를 테스트해볼 것을 권장합니다. 이전 구성한 주키퍼 클러스터와 똑같은 서버에 똑같은 설정으로 새로운 클러스터를 구성했다고 하더라도, 네트워크가 바뀌었다는 이유만으로 문제가 되는 경우가 있습니다.
https://github.com/phunt/zk-smoketest 에서는 주키퍼 클러스터를 테스트해볼 수 있는 도구를 제공합니다.

9. don’t rely on zookeeper too much
아직 주키퍼는 완전히 안정화되었다고 말하기가 어렵습니다. 아직까지도 약간의 불안정한 요소만으로도 원하지 않는 결과를 전달하는 경우가 많습니다. 전적으로 주키퍼에 의존하지 않도록 하세요. 정말 주키퍼에 의존할 수 밖에 없다면 두 개의 클러스터를 사용하는 것도 나쁘지 않습니다. 어플리케이션 차원에서의 이중 검사(dual-checking) 또한 권장됩니다.

Advertisements

2 Responses to zookeeper 운영시 권장 사항

  1. 핑백: 프로그램 개발, 사이트 구성에 필요한 고가용성 등 필요요건 조사 » Mr. Kim Blog | Mr. Kim Blog

  2. 엄성권 says:

    소중한 경험을 공유해 주셔서 감사합니다

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: