1. Overview & IDEA - HW monitoring 2. Problem & PoC 3. DATA Design 4. Publisher 5. Database & logger 6. Visualization 7. ToBeContinue…?
하면서
거의 혼자한 느낌이다… 리팩토링이 이렇게 중요하구나 ㅋㅋㅋㅋ 를 깨달았는데 몇자 좀 끄적여 보면
1. 첫 술에 배부를 수 없다.
처음에 시작을 할때는 호기롭게 시작했으나 지금 돌아보니 중간중간 의사결정을 내리면서 잘 못했던 것들이 보였다.
- Serialization 당시에는 엄청 어렵게 해결했다고 생각했는데 결국 직렬화에 대해서 정확하게 알지 못해서 삽질을 한 2일 정도 했던 것같다.
- 정확하게 알기 위해서는 원인을 먼저 알고 그 다음 해결방안을 찾아야 하는데 그냥 삽질을 하니 문제가 되었던 부분이 좀 반성이 된다.
- 답답하면 바람을 쐬는게 낫다. 안된다고 통파고 있으면 답이 더 없어진다.
- 목적에 맞는 구조를 짜야한다.
- 글에는 없지만 당시에 ELK로 시각화를 했는데 지금 생각해보면 그리 좋은 선택이 아니었던 것 같다. docker로 팀원이 프로그래밍 했지만 실제 의미가 없었고 지금 했던 과정이 조금 더 쉽지만 더 빠르고 효과적으로 할 수 있었던 것 같다.
- 초반에 의사결정을 내릴 때 많은 리서치가 있었다면 좀 더 좋은 선택을 할 수 있지 않았나 한다.
- 완벽하게 할 수 없다는 걸 인정해야한다.
- 불과 몇주만에 이걸 혼자 할 수도 없고 정확하게 좋은 선택만 할 수는 없다. 하지만 진행하면서 어려웠던 부분을 적어놓고 시간이 날때 해결하면 더 좋은 결과를 얻을 수 있다는 것도 한번 배운 것 같다.
- 너무 갇히면 안된다.
- 솔직히 spring으로 해야할 이유가 1도 없다.
- producer는 간단하게 python으로 작업해도 충분했고 나머지는 거의 프로그래밍이 많이 필요하지 않았던 것 같다.
- 하지만 고집을 부려 java로 진행했고 앞에서 시간을 많이 쏟았던 것 같다.
- 목적에 맞는 선택을 하는게 여전히 중요하다.
- 사실 KAFKA는?
- 사실 카프카도 저렇게 해놓으면 절대 안된다..
- 토픽도 만들어 놓지 않고 무작위로 하게 되면 분명 어디선가 문제가 생길꺼고… key, header도 없이 데이터를 보내는건 많은 의미가 없지 않나 하는 생각이든다.
- 시간이 없었지만 좀 더 나은 방법을 찾았을 수는 없었을까 하는 생각이다.
2. 앞으로는???
기왕 한김에 influxdb, telegraf, kafka, grafana에 대해서 좀 더 자세히 알아보면 좋을 것 같다.
물론 원래 목표에 맞게 hadoop을 구축하고 모니터링 해볼 생각이다.
TOBE CONTINUE…