[DataLake] 데이터레이크 운영 시스템 도입기
안녕하세요. 주형권입니다.
2023년 6월 30일 기준으로 어느덧 GS리테일에 입사한 지 2달을 넘었습니다.
현재 잘 적응하고 있으며 입사 이후에 정말 많은 것들을 만들고 있습니다.
이번 글은 그 첫 번째 프로젝트에 대해서입니다.
저는 어느 회사를 가던지 무조건 처음에 하는 작업이 있습니다. 바로 모니터링 시스템을 만드는 작업입니다. 데이터엔지니어를 5년 정도 하면서 많은 실무자들이 개발 베이스로 일을 하다 보니 운영에 대해서 경험이 없는 경우가 많고 어떠한 것을 만들어야 할지 어떻게 만들어야 할지 모르는 경우가 매우 많았습니다. 운영이 생각보다 신경 쓸게 많고, 많은 지식을 요하는 경우가 있어서 쉬운 부분이 아닙니다. 그래서 이러한 노하우(?)를 공유하고 어떻게 도입하였는지 공유하여 많은 분들께서 도움이 되셨으면 합니다.
1. 데이터레이크 모니터링 시스템의 구성
이 부분은 이전에 정합성 체크 모니터링에서도 언급 한적이 있습니다. Airflow를 이용하여 Batch를 하고 이를 MySQL이나 Postgresql과 같은 RDB에 저장하고 BI 도구를 이용하여 시각화하는 부분입니다. 어찌 보면 작은 데이터 파이프라인과 데이터웨어하우스(?) 시스템이라고 생각할 수 있습니다.
현재의 회사의 시스템에 맞게 구성을 하다보니 약간 의아(?) 할 수 있다고 생각됩니다. 현재의 상황에서 빠르게 시스템을 도입하다 보니 여러분이 보시기에 응? 하시는 부분이 있을 수 있지만 현재 재기능을 전부 하고 있는 시스템이고 기존의 시스템에 전부 녹여서 했기에 추가 비용은 RDS를 추가적으로 띄우는 비용을 제외하면 거의 들어가지 않았습니다.
1.1. 데이터 처리
데이터 처리는 EKS의 Airflow를 사용 하였습니다. 그리고 PythonOperator를 사용 하였습니다. Python의 경우 AWS 기반으로 데이터를 가져오고 처리하다 보니 boto3을 이용하여 대부분을 처리하였습니다. 최대한 단순하게 처리하기 위해서 웬만한 데이터는 list형태로 만들거나 dictionary 형태로 만들어서 가공하여 처리하였습니다. (RDS를 최대한 작은 것으로 쓰려고)
데이터는 대부분 Batch 성이고 모니터링이라서 고가용성이 크게 중요하지 않다고 판단하여 Airflow가 EKS위에 있지만 Local Executor를 사용 하였습니다. 물론 고가용성이 중요하진 않다고 하지만 죽으면 모니터링이 잘 안 되거나 지표가 나오지 않으므로 Health Check 겸으로 Teams에 본인이 살아 있음을 알리는 메시지를 매일 오전에 보내도록 하였습니다.
모든 데이터의 수집은 Python으로 처리 하였으며 이후에 가공에 대해서는 RDS에서 Query를 사용하여 처리하기도 하였습니다. 가령 Join을 하거나 데이터의 여러 가지 처리를 한방에 해야 하는 경우 Python 코드의 길이가 길어지므로 RDS에서 Query로 어느 정도 처리 하기도 하였습니다. (DBA를 해서 그런지 SQL이 편한 건 어쩔 수 없다...)
1.2. 데이터 시각화
데이터의 시각화는 기존에 회사에서 사용하는 시각화 도구가 상용이라서 추가적인 라이센스 구입을 요청하기 어려워서 Superset을 선택하였습니다. 예전에 잠깐 해본 적이 있는데 꽤 괜찮은 도구라고 생각해서 Superset을 선택하였습니다. Superset의 경우 RDS 쪽에는 붙는 게 크게 문제가 없고 웬만한 RDB를 지원하기에 편하게 연동하여 시각화하였습니다.
저희는 MySQL을 모니터링 RDS로 선정하였고 이 RDS를 Superset에 연동하여 사용 하였습니다. Superset의 경우 유저 관리 및 권한 관리를 세분하게 할 수 있고 EKS 위에 있다 보니 VPN을 통한 접근 허용만 하게 하거나 회사 내부 계정을 이용하여 계정을 발급하여 인가된 사용자만 접근이 가능하도록 하는 이중 삼중의 보안과 체계적인 권한 관리를 제공하여 시각화뿐 아니라 여러 가지 부분에서도 손색이 없다고 느껴졌습니다.
그리고 Superset은 워낙 많은 종류의 Chart를 제공하여 다양한 시각화를 제공 할 수 있기에 굉장히 만족하면서 사용하고 있습니다. 또한 Python기반으로 만들어졌기에 Python을 조금 할 수 있다면 입맛에 맞게 여러 가지 부분을 수정할 수도 있었습니다. (가령.. 아래의 그림에서 도베르만 아이콘이라던가...)
1.3. 모니터링 알람
모니터링 알람의 경우 기존에 사용하는 메신저가 Microsoft의 Teams라서 Teams로 통일하기로 하였습니다. Slack과 이원화 되어 있어서 자칫 사용자가 2개의 메신저를 혼동하거나 너무 여기저기에서 알람이 오면 불편하고 Slack을 사용하지 않는 사용자의 경우는 계정을 따로 만들어야 하는 이슈가 있기 때문에 Teams를 통해서 알람을 받기로 통일하였습니다.
이 역시 PythonOperator를 통해서 Teams로 전송하였습니다. Teams가 좋으면서도 안 좋은 부분은 채널마다 커넥터(Webhook)를 따로 만들어서 해야 하는 번거로움이 있습니다. Slack의 경우 Webhook을 하나만 만들고 채널 ID만 변경해서 보낼 수 있지만 Teams의 경우는 일일이 커넥터를 만들어서 입력해야 합니다. (혹시 아시는 분... 메일 주세요.)
하지만 좋은 부분도 있습니다. 채널마다 따로 알람을 받을 수 있기에 원하는 채널만 알람을 채 둔다면 자칫 너무 많은 알람으로 인해서 사람들이 조금씩 신경을 안 쓰고 싶은 욕구를 방지할 수 있습니다.
Python을 이용한 Teams 전송은 아래의 블로그를 참고하였습니다.
[Python/Teams] 파이썬 프로세스에서 Teams로 메시지 보내기
Introduction 이전에 잠깐 파이썬 프로세스가 종료될 때에 팀즈나 이메일 등으로 알림을 받아보는 법에 대해서 알아봤었다. 링크 이전 글에서 소개한 툴은 딥러닝 모델의 학습에 특화된 알림 툴이
jh-bk.tistory.com
2. 데이터레이크의 플랫폼 이외의 정보
이 부분은 예전에도 잠깐 언급하였지만 데이터레이크 모니터링 시스템이라고 하여 데이터레이크의 플랫폼 부분 정보만 제공함을 넘어서 데이터를 사용하는 모든 사람이 사용하는 시스템을 만들고자 하였습니다. 우리만 사용하는 시스템을 넘어서 본부와 전사에서 데이터를 사용하고자 하는 사람이라면 누구나 접근하여 데이터레이크 시스템의 투명도와 정보력을 올리고 나아가서 데이터에 관련된 정보도 제공하고자 하였습니다.
2.1. 데이터 카탈로그
첫 번째로 데이터 자체의 정보를 제공합니다. GS 리테일의 경우 Athena 기반으로 데이터레이크를 구축하였으며 여기에서 저장된 데이터가 무엇이 있는지 데이터는 언제 업데이트되는지 데이터 테이블명, 칼럼명 등 기본적인 데이터 카탈로그를 제공하였습니다.
추가적으로 요청을 받아서 만든 내용인데, Athena에서 가장 많이 사용되는 DATABASE와 TABLE에 대한 집계 정보를 보여주는 지표를 만들어서 사용자들에게 제공하였는데 반응이 굉장히 좋았습니다.
2.2. AWS 비용 정보
최근에는 데이터를 사용하는 부서가 워낙에 많고 분석 및 시각화 조직에서도 각자의 AWS 계정을 가지고 하는 경우가 많습니다. 그래서 각각의 계정의 모든 비용을 관리하지 어려워서 해당 부서나 본부에서 알아서 관리하는 경우가 많은 것 같습니다. 그래서 이 부분을 확인하고 데이터와 관련된 AWS의 모든 계정의 비용 데이터를 S3로 받고 (이것을 관리하는 부서가 있어서 그대로 받았습니다.) 이를 Athena에 Table화 하고 이 Athena 테이블에 데이터를 Python을 이용하여 집계하고 모니터링 RDS에 FACT 형태로 만들어서 Superset으로 시각화하였습니다.
3. Navigation 제공
이 부분도 역시 요청을 받아서 만들었습니다. 사용자는 이러한 시스템을 경험해 본 적이 없기 때문에 무엇을 어떻게 봐야 할지 알 수가 없습니다. 그래서 아무리 시스템을 잘 만들어도 사용자가 사용하기 불편하면 아무런 소용이 없습니다. 그렇기에 Navigation 페이지를 만들어서 어떠한 지표가 어느 곳에 존재하는지 한눈에 볼 수 있는 문서를 만들고 지속적으로 업데이트하여 제공하였습니다.
사용자들은 단순히 문서를 통해서 어떠한 지표가 어디에 있는지 내가 원하는 형태의 데이터가 실제로 존재하는지에 대해서 빠르게 파악하고 엔지니어에게 즉시 요청하여 엔지니어는 이를 반영할 수 있도록 하였습니다.
4. 요구사항 적극 반영
사용자가 요구사항을 편하게 말할 수 있도록 Teams에서 채널을 만들어서 요구사항을 자유롭게 이야기할 수 있도록 하였습니다. 사용자는 본인의 의견을 구두가 아닌 메신저를 통해서 이야기하고 구체적으로 글을 남김으로써 엔지니어와 빠르고 쉽게 소통이 가능하게 하였습니다.
물론 결과물은... 단 6시간 만에 나왔다...
마치며...
데이터 엔지니어링에서 이제 운영은 빠질 수 없는 요소가 된 것 같습니다. 운영은 굉장히 어렵고 경험이 많이 필요하다고 생각합니다. 데이터 시장이 성장하고 궤도에 오른 지 얼마 안 된 만큼 많은 회사에서 경험을 없어서 운영을 하지 못하는 경우가 많습니다. 이 글이 그러한 분들에게 조금이나마 도움이 되셨으면 하는 바람입니다.
운영은 초반에는 크게 와닿지 않는 경우가 많습니다. 특히 스타트업의 경우 개발하고 나아가기 빠쁜데 운영을 위해서 이것저것 요구하거나 정책을 수립해야 하는 경우가 많습니다. 저의 경우도 여러 회사를 다녔지만 누군가 알아주길 바라서 운영을 했다기보다는 DBA를 했던 습관에 의해서 그냥 스스로 하고자 하는 개인적 만족으로 시작하였습니다. 하지만 이것을 만들어두고 짧게는 3개월 길게는 1년 안에 그 엄청난 효과를 볼 수 있습니다. 단순히 데이터를 쌓고 보여주는 것이 아닌 비용을 절감하는 효과와 데이터를 운영하는 엔지니어링팀의 인지도가 굉장히 많이 올라갑니다.
이는 단순히 업무적 성과를 넘어서 추후에 굉장히 여러 가지 효과를 불러옵니다. 실제로 그 수혜를 많이 입었고 이것이 저에게 하나의 커리어가 되었습니다. 처음에는 그냥 단순히 토이 프로젝트로 시작하였으나, 이 운영의 노하우에 반하여 많은 회사에서 저와 함께 하기를 바랐습니다. 이 글을 읽는 많은 데이터 종사자 분들도 같은 수혜를 입기를 바랍니다.
감사합니다.