안녕하세요. 황진성입니다.
오늘 Kafka 한국 사용자 모임 밋업에 다녀온 후기를 작성하고 약간의 잡담을 해보겠습니다.
약간의 텍스트 기록과 제 기억으로 작성된 포스트이기 때문에 실제 발표 순서+내용과 다를 수 있습니다.
+ 2023.08.16 추가 | 발표자료는 여기에서 볼 수 있습니다!
1부: 1000만 회원, MAU 500만을 위한 빅데이터 아키텍처
무신사에서 데이터 엔지니어로 재직 중이신 유환성 님이 발표해 주셨습니다.
내용 정리
발표자님이 입사했던 4년 전, 무신사는 직원이 250명쯤이었다. 최근에는 1400명까지 늘었는데, 구성원뿐만 아니라 무신사 유저도 많이 늘고 거래량도 많이 늘었다. 그 과정에서 데이터 아키텍처 구조 개선이 필요한 순간들이 있었다.
어떤 해결하고자 하는 문제가 발생했을 때, 2가지 선택지가 있다.
- 현재 구조에서 해결 가능한가?
- 해결한다.
- 현재 구조에서 해결 불가능한가?
- 신중하게 구조 개선을 진행하고, 아키텍처 의사 결정 기록을 정성 들여 작성한다. 예를 들어 Spark 작업을 위해 AWS EMR을 사용하기로 했다면 그 이유에 대해 상세히 기록한다.
실제로 일정 기간 동안 발생한 데이터를 조회하고 싶은데, 아래와 같은 문제들이 있었다.
- 운영 DB에 바로 접속해야 한다.
- index가 걸려있지 않아서 조회가 (거의) 불가능하다.
- 단 1일 치 거래만 조회해도 수십 초가 걸린다.
- ...
DB 데이터를 파일 기반으로 저장해서 분산 처리할 수 있는 환경을 구축해서 이 문제를 해결했다. 하지만 실시간성이 떨어져서 Near realtime으로 개선하게 되는데, AWS API Gateway + Kinesis -> EMR을 활용해서 실시간 데이터 수집 및 가공이 가능했다.
하지만 Managed service라 그런지 비용이 생각보다 너무 비쌌다... 심지어 Auto scailing을 자동으로 진행해 주는데, 트래픽이 몰렸을 때 늘리기 시작하다 보니 그 과정에서 처리되어야 하는 데이터들에 Timeout이 발생하기도 했다. 추후 AWS MSK가 런칭하면서 마이그레이션 했고, 비용 절감이 되었다.
---
많은 회사에서 비즈니스 문제가 곧 기술 문제로 직결되는 경우가 많다. 데이터를 잘 활용하기 위해 데이터 플랫폼을 잘 만들어둬야 하는데, 그만큼 데이터의 구조를 잘 만들어 두는 것 또한 중요하다.
여러 팀에서 데이터를 활용해서 비즈니스 업무를 진행하는데, 데이터를 제공해 줘도 각 팀마다 데이터를 가져가는 방식이 달라서 의견의 불일치가 발생하는 경우가 많았다. 이 문제를 데이터와 데이터를 활용하는 팀 사이에 데이터 거버넌스 레이어를 추가해서 해결했다.
현재 metric 100여 개, dimension 1000여 개가 존재하고, 조합하면 약 10만 개의 지표를 추출할 수 있는 데이터 거버넌스를 구축했다.
---
더 많은 동료들이 어떻게 하면 데이터에 접근을 잘할 수 있을까?
일단 데이터 팀부터 살펴봤을 때,
Scala Spark와 Pyspark는 과거에 퍼포먼스 차이가 꽤 났지만, 최근에 Dataframe의 도입으로 퍼포먼스 간격이 많이 줄어들었다. 또한 Scala Spark을 사용하면 직원 채용이 힘들었는데, Pyspark 유저가 훨씬 많아서 채용도 더 쉽게 진행할 수 있었다.
신규 채용 후 업무 온보딩까지 시간이 오래 걸리곤 했었는데,
- SQL, Python Notebook, BI 환경 제공,
- Workflow 환경 제공
- 데이터레이크 제공
- 표준 가이드와 카탈로그 만들기
- 사람이 아닌 가이드 + 프로세스로 일하기
를 도입하면서 온보딩 시간이 훨씬 짧게 걸리는 것을 확인했다. 가이드만 봐도 어떻게 데이터를 다룰지 유추해서 업무를 진행할 수 있게 되었다.
회사 전체 구성원들에게는, 데이터 활용 수준에 따라 다른 환경을 제공한다.
[데이터를 볼 수 있는 < 데이터를 다룰 수 있는 < 데이터 분석을 할 수 있는] 구성원 그룹에 따라 각기 다른 화면을 제공한다.
---
QnA
- 비용 문제로, 짧은 주기의 작업은 EMR을 항상 띄워서 쓰고, 큰 데이터를 처리해야 하면 필요할 때 EMR 클러스터를 띄워서 처리하고 릴리스한다.
- 실시간 추천을 위해 DynamoDB를 사용하지 않고 DocDB를 사용하는 이유는 DynamoDB는 Write도 비용이기 때문이다.
내 생각
카프카 밋업이었지만, 카프카에 대해 경험이 적었던 저에게 더 좋았던 발표였습니다. 비록 데이터 엔지니어링 관련해서는 경험도 지식도 부족했지만, 흥미롭게 느꼈던 부분을 나열하자면 다음과 같습니다.
- 대용량 데이터를 적절한 비용으로 처리하기 위해 아키텍처를 개선했던 내용이 재밌었습니다. 처음부터 완벽하게 구성한 것이 아니라, 문제가 발생할 때마다 신속하게 개선을 결정하고 실행으로 옮긴 것이 좋았습니다.
- 채용을 위해서 채용 시장에서 공급이 많은 기술을 택하는 것도 팀 발전을 위해 도움이 된다는 것을 알게 되었습니다. 기술 전환이란 매우 까다롭고 복잡하고 시간이 오래 걸리는 문제지만, 그럼에도 불구하고 진행한 것이 좋았습니다. 시니어 엔지니어의 마음을 간접적으로 볼 수 있었습니다.
- 구성원들의 데이터 숙련도에 따라 서로 다른 플랫폼을 제공한다는 점이 좋았습니다. 무신사 데이터 팀이 다른 조직 구성원들을 배려하는 느낌이 들었습니다.
2부: 카프카 클러스터 인증(AuthN)/인가(AuthZ)의 중요성
스피타에서 CTO 겸 Research Engineer로 재직 중이신 송정욱 님이 발표해 주셨습니다.
내용 정리
인증/인가가 필요한 경우
- Producer : message form이 맞지 않는 데이터를 produce 하는 경우
- Consumer : 이상한 곳에서 consume 해가는 경우
- Kafka CLI : 누구나 다운로드하여서 모든 작업을 할 수 있기 때문에 Consumer, Producer가 사용하고 있는 Topic을 삭제한다던가 offset을 변경한다던가... 하는 경우
- Admin Client API : 어디서나 열려있기 때문에 Kafka CLI와 마찬가지이다.
인증은 SASL_PLAINTEXT, SASL_SSL 두 가지 방식만 제공된다.
SSL 방식을 사용하면 암복호화를 진행해서 Kafka의 장점인 zero-copy를 못하기 때문에 CPU 부하가 많아지고 느려질 수 있다.
Throttling: 카프카에 내장된 기능이다.
전체 서비스 품질(QoS)을 보장하기 위해 특정 작업 혹은 클라이언트의 대역폭을 제한한다. Consumer는 얼마큼 사용될지 대충 예상할 수 있지만 Producer는 예측이 힘들기 때문에 대역폭을 제한한다.
---
QnA
Q. 카프카의 큰 장점 중 하나가 내부 데이터 전달 과정에서 애플리케이션 버퍼를 거치지 않고 리드 버퍼 - 네트워크 버퍼 간 직접 데이터를 전달하기 때문인데, 인증 과정이 추가돼도 이 구조는 유지되는가?
A. 리소스 접근 시에만 인증/인가를 진행하기 때문에 영향을 전혀 미치지 않는다고 말하긴 힘들지만 충분히 사용 가능하다.
내 생각
Kafka를 공부하며 보안에 대해서는 전혀 고려해 본 적이 없었습니다. 회사에서도 관련 부서에서 작업해 주는 것만 사용하다 보니 몰라도 되는 것으로 생각했을지도 모르겠습니다. 아는 것이 거의 없어서 한 귀로 듣고 한 귀로 흘린 세션인 것 같은데 조금 더 공부해서 왔다면 더 많은 것을 배우는 시간이었을 것 같습니다.
밋업을 다녀와서 드는 생각과 고민들을 독백 형태로 적어봤습니다.
요즘 일이...
요즘에 일을 열심히 하고 있는 것 같은데 뭔가 속도도 느리고 퍼포먼스도 나오지 않아서 고민이다. 개발을 하면 할수록 아는 것보단 모르는 게 더 많은 수준을 넘어, 모르는게 대부분인 지경까지 와버린 것 같다. 차라리 몰랐으면 대충 개발하고 넘어갔을 텐데, 하면 할수록 속도가 더 느려지고 신중해지는 건 당연한 건지도 모르겠지만 아무튼 혼란스럽다. 이번 스프린트에 모든 일을 할 수 있을 거라 생각했는데, 끝내지 못할 것 같아 스스로 야근을 하기도 하는데 분명 좋지 못한 습관인 듯하다.
각 Phase 별로 배포하는 방법이 달라서 익숙해지는데 좀 걸렸던 것 같다.
어떤 기능을 구현하기 위해 DB 테이블을 설계하고, Bulk insert를 어떻게 하고,
어디서 어디까지 서비스 로직에서 처리하고, 어디부터 kafka consumer에서 처리하고,
JPA TransactionManager를 만드는데 설정 정보는 어떻게 넣어주고,
DB 서버가 다른 경우에 트랜잭션 보장은 어떻게 해주고,.... 등등 고민이 많았던 스프린트였다.
코드 리뷰에서 중복 코드도 발견되고, Self invocation도 발생하지 않는 코드인데 불필요하게 서비스를 분리하기도 했었다.
너무 역량 부족이라는 생각이 들기도 했고, 주변에 뚝딱 일 잘하는 신입 혹은 주니어를 보면 자존감이 많이 떨어지기도 했다. 그럼에도 뭐 어찌하나 싶다. 열심히 살다 보면 스스로에게 만족스러운 시기가 올 거라 기대하고 있다.
밋업에 참여한 이유가
먼저 친구(🙋♂️)가 같이 가자고 제안했었는데, 처음엔 고민을 해보겠다며 미뤘었다.
주말 저녁에, 예전부터 알고 지내던 형을 잠깐 만나서 이런저런 회사 얘기도 하고 고민도 털어놨었는데, 주변에 괜찮다고 생각하는 사람들에게 찾아가서 고민 상담을 해보라고 했다. 처음에는 당연 회사 팀 사람들이 떠올랐지만, 뭔가 어리광 부리는 것 같고 앞으로도 계속 일해야 하는 사이에 고민 상담은 사이드 이펙트가 꽤 커 보였다. (그럼에도 불구하고 더할 나위 없이 최고의 팀원들이다!!)
그러다가 문득 밋업에 오는 사람들에게 커피 한잔 하며 얘기해 보는 것은 어떨까 생각했다. 주말에, 퇴근 후에 소중한 시간을 내서 밋업에 참여하시는 분들은 나름 진심으로 일을 사랑하는 분이라는 생각이 들었다. 마침 일정표를 보니 중간에 20분간 휴식 및 네트워킹 시간도 있어서 이때다! 싶었다. 명함도 여러 장 챙겨가봤다. 하지만 예상과는 달리 휴식 없이 쭉 진행됐고, 발표가 끝나자 모두 나가는 분위기여서 나도 나왔는데 약간 아쉬웠다. 명함은 zero-give zero-take
결론은, 기술 밋업은 처음이었는데 기술적으로나 기술 외적으로나 꽤 유익했다.
퇴근 후 모여 앉아 발표자에게 집중하고 생산적인 질문을 하고, 구면인 분들은 만나서 인사하는 모습을 보니 나도 저들 중 한 명이 되고 싶다는 생각이 들었다. 그러기 위해서는 조금 더 많은 경험과 커뮤니케이션 스킬이 필요할 것 같다. 세상에 고수는 많으니 자만은 사치고 겸손이 기본이라는 생각이 들었다.
좀 더 열심히 살아야지!
+ (좌) 샌드위치 과일 도시락 (우) 원판 돌리기 당첨돼서 받은 후원사 책만의 에코백
