TECH BLOG

코습장

커밋 메시지에는 무엇을 했는지보다 왜 했는지를 남기세요

전체 글 4

Kafka 안정적이고 효율적으로 돌아가게 만들기

Kafka를 띄우는 것과 안정적으로 운영하는 것은 전혀 다른 얘기다.설치해서 돌리는 건 몇 분이면 되지만, 몇 주·몇 달을 사고 없이 흘려보내려면 처음부터 고려해야 하는 것들이 따로 있다.이 글은 내가 프로젝트를 진행함에 따라서 좀더 고려했으면 좋았을법한 여러가지 정보들에 대해서 써내려간것이용량 항상 체크하기Kafka는 기본값으로 /tmp/kafka-logs에 데이터를 쌓는다. 아무것도 바꾸지 않으면 자동으로 여기 쌓이게 되는데, 문제는 /tmp가 보통 OS 루트 디스크(/) 위에 있다는 점이다.루트는 대개 용량이 작게 잡혀 있어서 데이터가 계속 쌓이면 루트 자체가 터지고, 그러면 Kafka뿐 아니라 그 호스트의 다른 프로세스까지 동반 위험에 빠진다. 이러한 용량문제를 해결하고 프로젝트 특성에 맞게 안정..

흩어진 Cron Script들을 통합하게 된 이야기

? ABC ! 현재 운영중인 프로젝트에는 여러 클러스터(PC)에 cron으로 여러가지 스크립트가 제각각 돌고있었다.백업하는 스크립트, compact 스크립트, 파일 위치 변경 등 여러 스크립트들이 PC 여러곳에서 돌고있었는데운영하면서 드는 생각이 시간이 지날수록 "지금 뭐가 돌고 있고, 뭐가 성공했고 뭐가 실패했는지" 를 한눈에 파악하기가 힘들어졌다. 그리고 가장 큰 불안, 불편요소가 두가지 있었는데 첫번째로 어느 PC의 어떤 스크립트가 언제돌았는지, 성공 및 실패 여부를 매번 각 호스트에 들어가 로그를 뒤져야 알수있었다에러가 발생하면 스크립트가 돌아간 시간대의 로그를 가져와서 직접 확인하고, 너무 불편하고 은근 리소스를 잡아먹는 일이였다 두번째로 현재는 A 스크립트가 끝나..

Spark Analysers 도입

모두가 Spark 전문가일 수는 없다. 그래서 사람이 일일이 잡지 않고, History Server 메트릭으로 안티패턴을 자동으로 잡아내는 분석기를 도입했다비효율적인 Spark 잡은 리소스를 상당히 많이 잡아먹는다. 하지만 이런 Spark 잡은 일일이 개발자가 잡아내는것은 사실상 불가능에 가깝다 느려지는 쿼리를 발견할때마다 Spark DAG를 분석하고 튜닝하고 이러한 과정은 많은 리소스가 들기 때문이다가장 큰 문제는 팀내에서는 다양한 사람들이 Spark를 이용해서 기능구현을 함에따라서 지식 깊이에 따라서 같은 기능이지만 속도차이가 유의미하게 발생하였다 이거를 일일이 체크하는것도 많은 리소스가 들었으며, 모니터링 및 계측 도구를 참고해서 성능 개선하는것도 많은 시간이 들었다그리고 시간이 지남에 따라서 빠르..

Spark 소형 파일 문제와 Iceberg를 택한 이유

데이터양은 얼마 안 되는데 Spark 조회만 느립니다. 어디를 봐야 원인이 나오고, 고친 뒤에는 무엇이 남을까요?왜 필요한가모델 학습 관련된 작업을 하던 중 학습과 추론 과정에서 소요시간이 너무 길게 잡히는 것을 확인했습니다.물론 학습에 필요한 데이터가 많기 때문에 어쩔 수 없이 오래 걸리는 건 당연하다고 생각했죠하지만 내가 생각했던 데이터량 대비 소요시간이 너무 길어 해당 현상을 조사하기 시작했습니다.우선 문제가 되는 API(학습 및 추론)의 소요시간을 측정해보기 시작했습니다. 학습 데이터 조회를 위해 약 10억 정도의 데이터를 조회하는 경우 위와같이 시간이 오래 걸리는것을 확인하게 되었다해당 글은 원인 확인을 위해 내가 확인했던 방법과 어떻게 해결하는지에 대한 과정을 담아 다른사람에게도 좋은 인사이트..