Databricks와 함께한 데이터 플랫폼 구축 1년 회고

두오모 성당

 

안녕하세요. 주형권입니다.

태어나서 처음으로 회고라는 것을 해보네요. 회고라는 것이 무엇인지 몰라서 인터넷을 검색하다가 다양한 회고 기법에 대해서 보았고 잘 모르겠어서 AI에게도 질문을 하였습니다. 그래서 제가 내린 결론은 결국 형식과 틀은 없다입니다. 딱히 무언가 정해진 틀은 없는 거 같고 다양한 기법이 존재하는 거 같습니다. 

 

저는 이러한 기법을 사용하지 않고 제가 느꼈던 점과 어려웠던 점을 이야기 해보고 다른 사람들에게 영감을 주었으면 좋겠습니다. 항상 이야기하듯이 저의 경험과 기술은 정답이 아니며 참고를 하고 앞서 말했듯이 영감을 받기를 바랍니다. 딱 참고 정도 하면 좋겠습니다. 

 

이 회고는 제가 현재의 회사에 입사하고 처음으로 Databricks라는 데이터 플랫폼을 접하고 이를 기반으로 데이터 환경을 구축한 경험을 기반으로 작성하였습니다. 현재 입사 후 어느덧 1년이 지났고 지금까지 경험하였던 어려움과 새로운 경험 그리고 새로운 배움 그리고 이를 통해서 느끼는 생각과 앞으로 남은 과제까지 여러 가지 부분에 대해서 작성하였습니다. 

---

시작 : 입사 후 1~3개월의 상황 파악과 급한 불 끄기🔥

이 회사에 입사는 2024년 06월에 하였습니다. 슬슬 더워지기 시작 할때즈음에 입사를 하였고 입사 첫날 인사팀에 입사 관련하여 서류 작성과 회사 내부 복지나 여러 가지 제도등을 간략하게 들었습니다. 그리고 끝나자마자 일을 시작했습니다. 당장 다음 주에 오픈해야 하는 서비스가 있는데, 이걸 오픈해야 했거든요... 입사하고 아직 계정도 못 받았지만 일단 시작해야 하니 일단 상황 파악을 하고 이것을 잘 오픈하는 것이 급선무였습니다. 

 

어찌어찌 급한불은 끄고 상황을 하나씩 파악했습니다. 우선 현재 데이터 플랫폼이 Databricks라는 점을 듣고 Databricks에 대해서 공부를 시작하였습니다. 저는 태어나서 한 번도 Databricks를 해본 적이 없거든요.... 

 

인생 처음 접하는 Databricks

 

제가 공부만 하고 있을 순 없었습니다. 왜냐면 그럴 시간이 없었습니다. 이미 Databricks를 이용한 데이터 환경이 오픈을 하고 실제로 사용하는 사람도 있었습니다. 사용자는 많지 않지만 그래도 있으니 어떻게든 운영을 해야 했습니다. 우선 데이터는 잘 들어오는지 이 데이터들은 문제가 없는지 수명주기나 파티션등 여러 가지 등을 봐야 했습니다. 

 

0. 데이터 아키텍처 설계 : 어떤 곳이든 어떤 일이든 설계는 중요하다.✍🏻

 

어떤 분야를 떠나서 무슨 일을 하기 전에 계획을 수립 하는 것은 매우 중요합니다. 처음에 입사했을 때 데이터를 적재하고 는 있지만 ODS / MART / FACT와 같이 잘 나뉘진 아키텍처가 아니었고 데이터를 어떠한 네이밍에 맡게 적재하고 어떻게 어디에 얼마나 적재를 해야 하는지에 대해서도 정책이 없었습니다.

 

설계는 언제나 중요하며, 기반을 잘 다져야지 건물도 튼튼하다.

 

그래서 우선 만들어야 했던게 데이터 아키텍처였습니다. 우선이라고 했지만 사실상 1번의 모니터링 시스템과 거의 동시에 만들었습니다. 저의 모든 지식과 경험과 각종 글을 참고해서 꾸역꾸역 데이터 아키텍처를 설계하였습니다. 내부적인 아키텍처이기에 공개는 못하겠으나 Databricks의 Medallion 아키텍처와 같은 형식으로 데이터 아키텍처를 설계 하였습니다. 기존에 데이터를 어디에 어떻게 적재할지 몰랐으나 이런 식으로 데이터의 형태와 가공정도에 따라서 데이터를 분류하고 이를 기반으로 Naming Rules을 만들어서 적재적소에 데이터를 나누어서 적재하였습니다. 

 

 

대략적으로 위와 같이 설계하였고 운영을 하였습니다. 아마도 데이터를 하신 분들이라면 위의 아키텍처가 엄청나게 특별하거나 부족하거나 하기 보다는 그냥 보편적인 느낌일 수 있습니다. ODS -> Mart -> Fact로 이어지는 데이터와 개인이 쓸 수 있는 Personal 데이터를 만들어서 개인이 조작할 수 있도록 하고 인사이트를 도출하도록 하는 여러 가지는 아마 많은 회사에서 도입해서 사용하는 방식일 것입니다.

 

1. 일단 보고 이야기하자 : 모니터링 시스템 구축 🧐

 

일단 뭐가 어떻게 되어 있는지 현황을 파악하고 당장 모니터링을 통해서 현재의 현황을 보여주는 모니터링 시스템을 구축하여 대시보드를 구축하고 데이터 파이프라인이나 시스템 등이 문제가 있을 때 이를 실시간으로 알려주는 여러 가지 시스템이 필요했습니다. 

 

보고 이야기 하는 게 생각보다 중요하다.

 

뭐가 어떻게 돌아가는지 알아야지 어디서 문제가 있는지 알 수 있으니까요... 그러면서 자연스럽게 Databricks의 여러 가지 봐야 하는 부분에 대해서 공부를 하였습니다. Databricks에 어떠한 게 필요하고 무엇을 중점적으로 봐야 하고 성능을 끌어올리기 위해서는 무엇이 필요하고 무엇은 필요하지 않고 이것을 판단하려면 현황 파악을 해야 했습니다. 

 

만들었던 것 중에 크게 몇 가지만 나열하면 다음과 같은 것들을 만들었습니다. 이것은 Databricks뿐 아니라 AWS와 데이터 관련 모니터링도 포함 합니다. 저는 이것은 Superset을 이용해서 구축 하였으며 현재 이 모니터링 시스템은 🗿 모아이로 불리고 있습니다. 몇가지 중점적인 모니터링 관련해서 적어보면 다음과 같으며, 회사의 내부적인 부분도 있기에 전부 공개하지는 않았습니다.

 

• 🛢️ Databricks
  • Databricks 비용 관련 DBU 지표 
  • Workflow 작업 실패 실시간 감지 알림 (메신저 연동)
  • 오래 걸리는 작업 감지 알림 ( SQL / Notebook )
• ☁️ AWS
  • S3 Bucket 사이즈 지표
  • AWS 전체적인 비용 지표
• 🚀 Airflow 
  • Airflow Dag 실패 실시간 감지 알림
• 🗃️ 데이터 
  • 주요 테이블 건수 체크 

여러 가지 모니터링을 만들어서 상황 파악을 어느 정도 하였고 급한 부분을 수습하기에 이르렀습니다. 그중에 몇 가지 사례를 소개하려고 합니다.

 

2. vacuum : 청소기요? 🛋️

 

AWS S3의 사이즈를 보고 이상한 생각이 들었습니다. Databricks의 기본 저장소가 S3를 사용해서 Delta가 전부 S3에 있는데 Databricks에서 표기하는 테이블 사이즈와 S3의 사이즈가 너무 많이 차이가 났습니다. 수십~수백 TB가 차이가 나니 이건 왜 이럴까?라는 생각이 들었습니다. 그러다 알아낸 게 Databricks는 vacuum이라는 명령어가 있고 이를 수행 하는것이 굉장히 중요한 것이라는 것이였습니다. 

VACCUM 굉장히 중요하더라

 

일단 이놈이 뭔지부터 공부해서 왜 이게 필요한지를 알아봤습니다. 일단 말 그대로 청소하는 명령어였습니다. 여기서 줄줄이 이야기하면 이야기가 길어지니 관련된 내용은 제가 기존에 써둔 글을 참고하면 좋을 것 같습니다.

 

[Databricks] Optimize / VACUUM

 

결론적으로 총 합쳐서 수백 TB의 불필요한 AWS S3의 용량을 줄였습니다. 엄청나게 감소하였고 이로 인해서 저장 비용과 처리 비용이 굉장히 많이 감소하였습니다. 

 

3. 왜 느리지? : 파티션을 다시 구축하였다. 📘

 

파티션은 어느 빅데이터 또는 RDB 모든 데이터 관련 시스템에서 가장 중요하다고 볼 수 있습니다. 파티션이 없으면 엄청나게 느리게 데이터를 처리하고 불필요한 데이터까지 모두 읽어서 처리해야 하기 때문에 당연히 느릴 수밖에 없습니다. 그래서 가장 주요하게 사용되는 핵심 테이블부터 파티션을 재구성하기 시작하였습니다. 

 

현재 다니고 있는 회사가 약간 특이하게도 대규모 삭제를 하고 있다는 것입니다. 그래서 기존에 흔한(?) 데이터 플램폼과 같이 APPEND만 하는 방식과 달리 APPEND와 DELETE가 일어나야 합니다. 그래서 일자별로 파티션을 생성하면 전체 테이블을 모두 조회해서 지워야 하기에 파티션이 너무 많이 파편화됩니다. 그렇다고 다른 것으로 파티션을 걸자니 파티션의 단위가 너무 커져서 처리할 때 이점을 얻지 못합니다. 

 

결론적으로 가장 많이 그리고 가장 자주 사용 하는 패턴을 기반으로 만들었다.

 

뭐 당연하겠지만 WHERE에 가장 많이 사용하는 칼럼 그리고 가장 자주 사용하는 SELECT 패턴을 기반으로 하나씩 파티션을 재구축하기 시작하였습니다. 여기서 문제는 기존의 테이블이 너무나도 대규모라서 (크게는 1개에 50TB가 넘는) 일반적인 방법으로는 처리가 굉장히 어려웠습니다. 단순히 새로 만들고 부어 넣고 하려고 해도 계속해서 터져 버리는 Databricks를 보면서 현타가 왔습니다.

 

그때 공부해서 했던 게 바로 Shuffle partition이었습니다. Databricks는 Spark를 기반으로 만들어졌고 (혹시 아니면 말해주세요.) Spark 옵션에 대해서 공부를 하기 시작했습니다. 왜 터질까? 참고로 저는 Spark도 해본 적이 없습니다. 그래서 Databrick와 Spark를 동시에 공부하면서 많은 것을 배웠습니다. 

 

이후에 처리에 많은 시간이 소요되는 작업이 소요시간이 많이 감소되었습니다. 이로 인해서 자연스럽게 Databricks의 비용이 감소하는 효과까지 얻었습니다. 처리하는 양이 줄어들면 그만큼 자원의 소모가 적기에 효율적으로 작업을 할 수 있게 되었습니다. 

---

중간 : 숨을 고르면서 업무를 분배하였다. 🏝️

어느덧 6개월 정도의 시간이 흐르니 시스템이 많이 안정화되었습니다. 급한 불을 끄고 정책을 세우고 아키텍처를 만들고 어느 정도 데이터 플랫폼이 궤도에 올랐습니다. 혼자서는 이제 무언가를 하기엔 힘이 붙이기도 하였고 시니어 엔지니어로써 팀원들을 챙겨야 했고 팀원들에게 업무를 분배해서 각자의 확실한 색을 입혀주고 싶었습니다. 

 

그래서 이것을 정리하기 시작하였고 다음과 같이 업무를 정리하고 업무를 나누었습니다. 각자의 특색에 맞게 업무를 나눔과 동시에 팀원들의 커리어도 잘 챙겨야 했기에 많은 생각을 하면서 업무 분장과 프로젝트를 정리 나아갔습니다.

 

1. 나부터 정리를! : 업무를 표로 정리하고 자세하게 기입하였다. 📚

일단 저도 업무가 정리가 안되고 미친 듯이 달려왔기에 뭘 했고 뭘 해야 하고 무엇이 미흡한지 몰랐습니다. 그래서 우선 나부터 살고 보자는 생각으로 업무를 정리하였습니다. 그게 아마 입사 후 4~5개월 즈음이었던 거 같습니다. 제 머릿속에서도 정리가 안되는데 어떻게 남에게 주겠습니까? 

일단 내 업무를 정리부터 하자.

 

작년에 제가 해야 했지만 못했던 일과 하려고 했던 일 했던 일을 크게 나누어서 정리를 하였습니다. 분류를 정하고 이에 관련해서 내가 찾아본 아니면 읽으려고 했던 글이 있으면 링크를 걸어두고 제목과 내용 그리고 어디까지 하였는지 진척도까지 표로 정리하였습니다. 대략 이렇게 정리하였습니다. 

 

이렇게 정리하고 내가 지금 할 수 있는 것과 없는 것을 정확히 분류해서 가장 급한 것부터 우선순위로 쳐내야겠다 싶었습니다. 그렇게 정리를 하고 나니 이제 무엇을 해야 할지 보이기 시작하였습니다. 

 

2. 같이 하자 : 업무를 분배해서 함께 시너지를! 🤝

 

이제 업무를 정리하였고 급한 업무도 어느 정도 하였으니 분배를 해야 했습니다. 그래서 모든 팀원을 불러서 여기서 본인이 하고 싶거나 할 수 있다고 생각하는 업무를 고를 수 있도록 하였고 그렇게 프로젝트를 나누어서 수행하였습니다. 큰 프로젝트와 작은 상시 업무를 나눠서 고루 분배하고 본인들의 강점을 최대한 살릴 수 있도록 하였습니다. 

혼자서는 한계가 있고 나는 1명이다. 나누고 함께 가야지 오래간다.

 

이렇게 업무를 나누고 저는 실무적인 측면과 함께 프로젝트를 리딩하는 역할을 많이 맡아서 하였습니다. 고문 격으로 프로젝트에 참가하여 프로젝트를 봐주고 조언을 해주고 방향을 잡아주는 일이 많아졌습니다. 초반에는 많은 부분을 봐줘야 했지만 나중에 가면 갈수록 모든 팀원들의 눈높이가 향상되면서 제가 관여하지 않아도 잘 끝나는 프로젝트가 점차 늘어났습니다. 

 

그렇게 함으로써 저는 더욱 멀리 보게 되면서 팀의 더욱 많고 큰 프로젝트에 대해서 이야기를 할 수 있게 되었습니다. 여러 가지 프로젝트를 동시에 진행도 가능해지고 저뿐 아니라 팀원들도 현재의 팀에서 무엇을 하는지 명확히 이해하고 같은 방향과 목표를 가지고 일을 할 수 있도록 되었습니다. 

 

---

후반 : 데이터 플랫폼의 비용절감 그리고 사용성 증가를 위한 노력 👩🏻‍💻

후반부로 가면서 데이터 플랫폼이 거의 안정화되었습니다. 그러면서 이제는 안정화를 넘어서서 비용을 절감하고 사용성을 증가시키기 위한 노력이 필요했습니다. 아무래도 데이터 플랫폼이 많은 돈을 쓰다 보니 어느 회사나 비용의 압박은 언제나 받는 거 같습니다. 그래서 데이터 엔지니어는 해를 거듭할수록 어떻게든 돈을 아끼기 위해서 노력하는 거 같습니다. 예전에는 고민하지 않았던 부분까지도 보고 또 보고 하면서 비용을 아끼기 시작하는 거 같습니다. 

 

그리고 나아가 데이터 플랫폼을 만들고 아무도 사용하지 않으면 안 되기에 사용성을 증가시키기 위해서 노력해야 하는 거 같습니다. 처음 엔지니어를 시작할 때 이런 고민을 해본 적이 없었는데 이제는 데이터가 누구나 사용이 가능하도록 하는 것이 많은 회사의 목표이다 보니 이런 고민에 부딪히는 거 같습니다. 

 

1. 돈의 압박 : 정말 쥐어 짜내서 해야 한다. 💸

 

제가 데이터 플랫폼을 운영하면 정말 짜기로 유명한 엔지니어입니다. 진짜 회사 돈을 내 돈처럼 아껴서 쓰려고 합니다. 돈에 굉장히 민감합니다. 왜냐면 결국 비용이 많이 들면 그 압박은 고스란히 데이터 플랫폼을 운영하는 팀이 받습니다. 사용자는 최대한 이러한 압박을 받지 않도록 해야 하기에 여기저기서 눈치를 봐야 합니다. 

더러워서 내가 가끔 내주고 싶다.

 

라는 말을 가끔 속으로 하지만 절대 그럴 순 없기 때문에 한 푼 두 푼 아끼고 아껴서 해야 합니다. 처음부터 잘 만들어야지 돈도 그만큼 아낄 수 있습니다. 두 번 세 번 작업하면 그게 다 돈입니다. 내 돈은 아니지만 어차피 제가 할 일이니 최대한 돈 아껴서 하는 게 좋겠지요. (그냥 귀찮아서 크긴 하다...)

 

그래서 저는 최대한 오픈 소스를 많이 활용하고 모니터링도 타이트하게 하려고 노력합니다. 

 

위와 같이 수많은 (이것도 일부입니다.) 모니터링을 통해서 실시간 또는 주기적으로 알람을 받고 이를 끊임없이 검증하고 돈을 더 아낄 수 없을지 고민합니다. 그래야지 누수가 덜하거든요. 그리고 이런 거 준비를 해두면 나중에 위 (팀장님보다 더 위)에서 뭐라고(?) 할 때도 변명(?) 거리가 생깁니다. 우리는 진짜 타이트하게 하는데 많이 쓰는 걸 어떻게 합니까?라고 할 수 있습니다. 

 

말은 변명이지만 이건 사실입니다. 데이터가 많고 많은 사람이 쓰는데 어떻게 합니까? 못하게 할 수도 없고 아니면 느리다고 쓰지도 않을 테고 정말 답이 안 나옵니다. 그래서 그만큼 정당한(?) 사유를 만들어두고 하는 것은 꽤나 유용합니다. 

 

2. 혹시 우리 거 써볼래..? : 잘해줄게요 한번 해보세요. 😉

 

아마도 제가 가장 크게 힘들어하고 가장 크게 고민하고 가장 크게 하고 있는 부분이라고 생각합니다. 내가 아무리 좋은 플랫폼을 만들었다고 하여도 누구도 사용하지 않는다면 어쩔 수 없이 그 플랫폼이 얼마나 잘 만들었다고 한들 그것은 외면받지 마련입니다. 그렇기에 이것을 잘 사용할 수 있도록 하는 것도 이제는 데이터 엔지니어의 숙명과도 같은 일이 돼 가는 것 같습니다. 하지만 정말 하기 싫습니다. 엔지니어가 하는 일이 얼마나 많은데 이것까지 해야 한다니요...? 근데 어쩌겠습니까? 세상이 변해가는 거 같습니다. 물론 저도 적응이 안 됩니다. 그리고 정말 하기 싫습니다. 

잘 만들었으나 아무도 쓰지 않는다면 무슨 소용이겠는가?

 

그래서 어쩔 수 없이(?) 교육을 준비하고 교육 자료를 만들고 발표를 합니다. 

 

이러한 교육을 진행하고 사람들이 우리가 만든 데이터 플랫폼을 잘 쓰도록 유도했습니다. 요즘은 그래서 "내가 데이터 엔지니어인지 인터넷 강의 강사인지 모르겠다." 싶을 때도 있습니다. 이밖에도 사람들이 잘 따라 할 수 있도록 따라 하기 글을 계속해서 연재하고 업데이트하고 하다 보면 현타가 많이 오긴 합니다. 

 

그래도 한편으로 뿌듯한 것은 다양한 부서에서 사용하고 어떻게 쓰는지 문의가 하고 여러 가지 다양한 시그널이 있을 때는 보람을 느끼기도 합니다. 우리가 있다는 것을 어쩌면 알아주는 것이니까요. 하지만 현타와 뿌듯 사이의 충돌을 생각보다 자주 일어납니다. 아직도 충돌 중이고 아마 앞으로도 몇 년은 계속 충돌하지 않을까 싶습니다.

---

마무리 : 이제 뭐 하지? 그리고 뭘 더 해야 하지?⁉️

 

사실 저도 잘 모르겠습니다. 1년 동안 정말 많이 달려왔습니다. 이제는 무엇을 해야 할지 더 이상 찾기도 버겁습니다. 정말 쉴 새 없이 달리다 보니 이제는 달릴 기운도 없습니다. 그래서 숨 고르기 하면서 천천히 주변을 살피고 무엇이 미흡하고 무엇이 있으면 더 좋을지를 고민하고 있는 시기 같습니다. 

 

전부 했다고 할 수 없기에 이것보다 더 나은 것은 없는지 이것보다 더 쉽게는 안되는지를 고민하는 단계인 거 같습니다. 제가 예전에 면접을 가면 "네가 모든 데이터 환경을 구축하고 그다음 스태프로 무엇을 할 것이냐?"라는 질문에 저는 늘 똑같은 대답을 했습니다.

플랫폼 다 구축하면 비용 절감하고 안정화시켜야죠

 

이제는 이 대답에서 한발 더 나아가야 하지 않을까? 싶습니다. 아마도 그건 사용성 증가겠죠... (진짜 싫지만...) 저는 항상 이걸 전단지 돌린다고 비유합니다. 내가 어떠한 제품을 생산하다가 다 만들었으니 이제 전단지 돌린다고 말이죠. 이게 진짜 싫긴 한데, 중요하지 않다고 하기엔 또 아니라고 생각합니다. 

 

왜냐면 누군가는 써줘야 하거든요. 예전에는 데이터 플랫폼 소위 말해 정보계나 분석계의 사용자가 굉장히 한정적이라고 생각 합니다. 예를 들면 데이터 분석가 / 데이터 과학자 이외에 SQL이나 Python을 조금 하시는 분들이 대상자였다면 이제는 그 대상자의 한계가 없는 거 같습니다. 아니 정확히는 없애라고 많은 회사에서 요구를 하고 있습니다.

 

나는 데이터 엔지니어니깐 당연히 데이터 플랫폼 운영을 하고 데이터를 적재하고 데이터의 정합성을 검증하고 이런 전통적인 데이터 엔지니어에서 나아가서 이제는 어찌 보면 사용성을 증가시키는 데이터 엔지니어를 많이 필요로 하는 거 같습니다. 그냥 SQL 배우세요. Python 배우세요. 에서 끝나지 않고 어떻게 무엇을 얼마나 이용할지를 알려주고 누구나 쓸 수 있게 보편적으로 만들고 설명하는 부분도 하나의 과제로 주어진 거 같습니다. 

 

끝으로 어느덧 1년의 기간을 이 회사에서 보내면서 너무나도 많은 일이 있었고 앞으로도 있을 것 같습니다. 무사히 잘 지나갔으면 좋겠고 저의 글을 보고 많은 분들이 Databricks 나아가 데이터 플랫폼을 구축하고 운영하는 부분에 있어서 영감을 얻으시고 공감을 얻으시길 바랍니다. 

 

감사합니다.