본문 바로가기
  • SDXL 1.0 + 한복 LoRA
  • SDXL 1.0 + 한복 LoRA
Study/빅데이터

[간보기 | Kafka] 정리를 마치며

by 마즈다 2016. 5. 20.
반응형


Kafka 정리를 마치며


분산 시스템 관리의 어려움

얼추 node 모듈을 이용한 kafka 서비스가 구현이 된 것 같았다.
트위터 Streaming API를 이용하여 데이터를 잘 가져오고,
producer는 이 데이터를 broker에게 잘 전달하고,
consumer는 broker로부터 데이터를 잘 가져와 로그를 뿌려주고…


하지만 어느 순간 이러한 프로세스가 중지되어있기 일쑤였다.
zookeeper쪽이나 kafka쪽이나 서버 콘솔에 출력되는 로그는
대체로 네트워크가 끊겼다는 메시지인데 도대체 이 문제가 어떤 원인으로
발생하는 지를 알 수가 없는 것이다.


애초에 분산 시스템에서 장애의 원인을 찾는 것은 매우 어려운 일이라는 것은
알고 있었지만 아무리 작은 클러스터라도 이 문제를 직접 겪으니 참
답이 안나온다.(물론 나의 경험과 지식의 부족이 가장 큰 역할을 했겠지만…ㅠ.ㅠ)


물리적인 네트워크가 문제인지, zookeeper에서 문제가 발생한 것인지
kafka에서 문제가 발생한 것인지…게다가 zookeeper와 kafka의 장애에 대한
상세한 자료들은 찾기가 쉽지 않아서…


결국 이 문제로 거의 2주 가량을 별다른 진척 없이 zookeeper와 kafka의
에러 로그에 대한 구글링만 하면서 보냈다.


혹시나 해서 몇대 안되는 클러스터에서 잔뜩 돌아가고 있던 HBase와
Storm 서버들도 모두 죽여버렸다.

최종적으로 구성된 나의 허접한 클러스터는 아래와 같다.



<가난한 자의 클러스터 이미지>


황당한 원인과 새로운 문제


사실 문제는 너무나 명백한 곳에 있었다.
현재 총 5대의 맥미니로 구성된 클러스터에서 4대는 서버 전용으로만
사용했으나 1대를 일반 가정용 용도로도 사용을 하는 과정에서 서버 전용의
4대는 절전 모드를 꺼놓았는데 이 한 대에 대해서는 절전모드를 켜놓은
상태였던 것이다. 그러니 절전모드로 들어가면서 이 한대에서 돌고있던
zookeeper, kafka는 물론 여기서 돌고 있던 node.js의 producer 모듈까지
모두 맛이 가버린 것이다. 


결국 전기세의 압박에도 불구하고 절전모드를 모두 해제하고 상황을 지켜보았더니
트위터 메시지 건수 기준으로 기존에 4~5천 건에서 죽던 프로세스가
대략 7만 건 이상을 처리할 수 있게 되었다.


하지만 아직도 갈 길이 먼 것이 약 7만 건 정도 처리를 하고 나면 zookeeper에서
Purge task가 발생을 하는데 이 시점에서 producer 프로세스가 멈춰버린다.
zookeeper의 purse 관련 설정에 대해 알아보고는 있으나 역시 자료도 많지 않고
나의 무식은 큰 장애가 되고 있고…ㅠ.ㅠㅠ


일단 다음 단계로


내가 하고자 하는 것은 트위터 데이터를 모아 형태소 분석을 거쳐 특정 시점에
가장 많이 언급된 단어들을 추출하고 그 단어에 대한 긍정/부정의 평가를 한 후
다시 그 단어가 언급된 공인 미디어를 검색하여 긍정/부정 평가에 대한
공신력을 추가하는 작업이다.


그 중에 이제 데이터 수집 단계를 진행하고 있으며 기왕이면 공부좀 해보자고
kafka에 손을 대본 것인데 역시 한계가 있다. 하지만 목표한 바를 진행하면서
최대한 틀린 부분을 바로 잡고 몰랐던 것을 채워 나가야겠다.


당장에 진행할 다음 단계는 현재 일없이 로그만 찍어대고 있는 consumer에
제대로 된 역할, 즉 Hadoop으로 파일을 저장하는 일을 좀 시키려고 한다.
역시 node 모듈을 사용할 것이고 그 과정 또한 차근차근 정리해 볼 생각이다.


선무당이 사람 잡는다.

잘 모르는 내용을 억지로 진행하다보니 잘못된 정보를 기록하게 되는 경우도
많은 것 같다. 앞으로는 가급적 핵심적인 내용은 잘 정리된 외부 사이트를
인용을 하고 내가 실제 눈으로 본 것들을 중심으로 정리를 해야겠다.

반응형