인스타카트의 Lakehouse 아키텍처와 Spark

인스타카트에 광고주들을 위한 Ad 플랫폼이 있고 광고주가 캠페인을 생성/수정/트랙하는데 필요한 예산, 비딩, 리포트 등의 데이터를 보여주기 위해 큰 데이터 파이프라인이 있습니다.하루에만 해도 200억건의 데이터가 들어오기에 기존 파이프라인의 아키텍처로는 확장성이나 비용적인 이슈들이 있어서 새로운 파이프라인을 만든 과정에 대한 블로그 글을 공유합니다. 👉 AS-IS Kinesis Firehose -> S3 -> Snowflake 기존 아키텍처는 AWS의 매니지드 Kinesis Firehose를 사용했는데 밑과 같은 문제점들이 있었습니다: - 매니지드여서 커스텀하게 로직이나 컴퓨팅 리소스를 조절하기 어려워서 비용이 데이터가 늘어날 수록 점점 커짐 - AWS Cloudwatch로 모니터링하는 것이 꽤나 비싸고, 커스텀한 지표를 보기가 어려움 - 파일 포맷을 csv, json, parquet만 지원 - 파일 사이즈를 1~128MB, 60~900초의 버퍼 주기밖에 설정하지 못함 - dynamic partitioning하려면 비용이 추가로 듬 👉 TO-BE Kafka -> Spark -> S3(Delta lake) -> Snowflake Kinesis Firehose를 Kafka/Spark로 대체했고, S3에 delta format으로 저장되게 했습니다: - 직접 EC2 instnace들에 구축하면서 최적의 리소스를 조절할 수 있어서 50% 비용 절감 효과를 봄 - Delta file 포맷을 사용하면서 read performance 늘어남 - Spark streaming listener를 활용해서 datadog에 지표들을 보냈고 opsgenie와 연동해서 데이터가 지연될때를 모니터링 할 수 있게 됨 물론 직접 관리해야하는 부분들이 생겨서 복잡성은 올라감. Kafka topic 파티션 수, 워커의 머신 타입, 데이터의 배치 사이즈등을 직접 조절하고 최적의 옵션을 찾아야했지만 더 유연하게 대응을 할 수 있게 되었고 비용도 많이 줄었습니다. https://tech.instacart.com/how-instacart-ads-modularized-data-pipelines-with-lakehouse-architecture-and-spark-e9863e28488d