추천 시스템의 심장, Feature Store 이야기 (1) — 혼란 속의 질서 찾기: Feature Store를 구축하다.Intro안녕하세요. ML Data Platform 팀에서 서버 엔지니어로 일하고 있는 Miti입니다!“머신러닝”, “개인화”, “추천”.이제는 모두에게 익숙한 단어들일 텐데요. 요즘은 유튜브, 인스타그램, 틱톡, X 등 대부분의 서비스가 머신러닝을 활용한 콘텐츠 추천 기능을 제공하고 있어요. 당근도 수년 전부터 유저들이 더 좋아하고 관심 가질 만한 콘텐츠를 제공하기 위해 추천 시스템을 구축해 왔고, 현재도 계속 고도화해나가고 있어요.보통 추천 시스템의 핵심 요소로 머신러닝 모델이나 딥러닝 알고리즘만을 떠올리곤 하는데요. 추천 시스템에는 그에 못지않게 중요한 핵심 요소가 하나 더 존재해요. 바로 Feature Store라는 플랫폼이죠. Feature Store는 추천 모델과 알고리즘의 추론 과정에 필요한 수많은 데이터들을 제공하는 역할을 해요. 모델과 알고리즘이 추천 시스템의 두뇌라면, Feature Store는 추천 시스템의 심장인 셈이죠!이번 시리즈에서는 Feature Store를 만들게 된 배경과 Feature Store를 구축하는 과정에서 사용했던 기술들, 그리고 시스템을 설계하고 운영하면서 내렸던 여러 가지 의사결정들을 공유해보려고 합니다. 이 시리즈는 다음 세 가지 주제에 따라 총 세 개의 글로 나누어 작성할 예정이에요.In-house Feature Store를 만들게 된 계기와 그 여정.한계에 다다른 Feature Store, 한계 돌파를 위한 새로운 설계.더 빠르고, 더 견고한 플랫폼을 위한 여러 가지 최적화 기법들.첫 번째 파트에서는 Feature Store를 만들게 된 배경과 요구사항 수집, 설계, 개발까지 이르는 전반적인 Feature Store 구축 과정을 이야기하려고 해요. 두 번째 파트에서는 계속 늘어나는 트래픽으로 인해 겪었던 성능적인 한계와 운영 중에 겪었던 기능적인 한계를 설명하고, 이를 극복하기 위해 새롭게 개발한 Feature Platform(Feature Store의 v2 버전이라고 생각하시면 돼요)을 다뤄보려고 해요. 마지막 세 번째 파트에서는 Feature Store와 Feature Platform의 성능을 견고하게 개선하기 위해 적용했던 여러 가지 최적화 기법과 의사결정을 소개할 예정이에요.그럼 이제 본격적으로 첫 번째 주제인 Feature Store 개발기에 관한 이야기를 해볼까요? 과거로 돌아가 Feature Store를 만들게 된 배경을 가볍게 되짚어 본 다음, In-house Feature Store를 구축해 온 여정을 함께 살펴보도록 합시다!니즈 (Needs)당근에서 Feature Store의 필요성을 느낀 건 2021년 초반, 추천 시스템이 도입된 지 약 2년 정도 지난 시기였어요. 당시 당근은 추천 시스템을 적극적으로 활용하면서 여러 지표에서 큰 성장을 이루고 있었어요. 최신순 피드를 넘어 각 유저에게 맞춤화된 피드를 보여주게 되면서 유저들의 만족도 또한 높아졌죠

• 카프카 스프링으로 변경된 아키텍처 및 코드 설명안녕하세요. 쏘카 서비스 엔지니어링본부 애셋(Asset)팀 백엔드 개발자 원스톤입니다. 저는 쏘카 존과 차량 도메인을 개발하고 있습니다.지속 성장하는 소프트웨어를 만들기 위한 코드의 품질 개선 노력들을 글로 풀어내려고 합니다. 먼저 차량재배치의 레거시 개선 작업이 필요했던 이유와 차량재배치 비즈니스의 도메인 지식과 코드 리팩터링을 순서대로 소개하겠습니다.차량재배치는 오래전 개발되어 방치되어 있었고 크게 두 가지 문제가 있었습니다.• 코드 레벨에서의 문제로 일부 기능 수정 또는 오류 발생 시 수정해야 하는 부분이 명확하지 않았습니다. 하나의 거대 클래스로 이루어진 모든 코드를 파악한 뒤 일부분을 수정하는 방식으로 유지보수하고 있어 사이드이펙트에 대한 두려움이 존재했습니다.• 기술 레벨에서의 문제로 기술조직 대부분이 사용 중인 AWS DMS와 카프카를 이용하지 않고 맥스웰과 키네시스를 이용하고 있었습니다. 맥스웰을 사용할 줄 아는 개발자는 극히 드물었고 사용하는 곳도 몇 군데 없었습니다. 문제가 발생했을 때 참고 문헌이 없어 해결하기가 쉽지 않았습니다. 맥스웰 기능에 문제가 생기면 수동으로 작업을 처리해야 했습니다. 해당 문제는 자주 발생했습니다. 결국, PM, 개발자, 사업부 모두의 동의를 얻어 일감으로 처리하게 됐습니다.쏘카는 존이라는 차량이 존재하는 공간을 갖고 있습니다. 매출 지표를 참고하거나 침수 등의 사유가 발생하면 한 존에서 다른 존으로 차량 이동을 수행합니다. 그것을 차량재배치로 정의합니다. 내부 시스템인 존관리시스템에서 차량재배치를 요청하고 실제 운전자가 차량을 이동시키면 이벤트를 받아 차량재배치를 수행합니다.기존 코드는 다음과 같이 하나의 클래스에 모든 로직이 있었습니다. 키네시스와 스프링 로직이 비즈니스 로직에 들어가 있어서 분석하기 힘들었고, 키네시스를 다른 기술로 바꾸면 모든 코드를 고쳐야했습니다. 게다가 테스트코드도 없었습니다.키네시스를 카프카로 변경하기 위해 비즈니스 로직만 재사용하고 나머지를 모두 분리하기로 했습니다. 간단하게 도식화한 다이어그램개발 전 간단한 다이어그램을 통해 구조를 잡았습니다. 키네시스 로직은 카프카 로직으로 변경하고 클래스를 분리했습니다. 스프링 로직은 상속을 사용하지 않고 어노테이션과 DI로 처리했습니다. 비즈니스 로직은 세 부분으로 나눴습니다. 는 카프카 로직이 전달하는 파라미터에 대한 검증을 진행하고, 는 차량재배치 비즈니스 로직을 처리합니다. 하지만 실제 동작은 전달받은 파라미터의 상태에 따라 또는 가 담당합니다.패키지는 다음과 같이 구성했습니다.크게 차량재배치 비즈니스 로직을 처리하는 과 기술적 로직을 처리하는 로 나눴습니다. 는 카프카 컨슈머가 전달받은 데이터를 자바 객체로 변환합니다. 로 처리한 후 객체를 로 전달합니다. 자바 객체의 유효성을 검증하고 를 통해 비즈니스 로직에 필요한 객체를 만들어 다음 계층으로 전달합니다. 전달받은 는 비즈니스 로직에 대한 유효성 검사와 동작을 수행합니다.는 카프카 토픽의 내용을 받고 컨버터를 사

AWS DMS, Kinesis, S3, Glue, Athena 를 이용한 변경 내역 기록과 검색안녕하세요 ~ 오늘은 AWS 를 이용해서 손쉽게 DB 변경 내역을 기록하고 또 기록된 내용 중 필요한 내용을 검색 할 수 있는 방법에 대해서 알아보도록 하겠습니다.구현된 서비스의 사용 시나리오가 풍부해지고 사용량이 증가함에 따라 과거 변경 내역을 확인해야 하는 상황이 이따금씩 발생합니다.특정 상황에 대해서 로그를 남기거나 관리자에게 알림이 오도록 설정하는 방법 등으로 대비할 수도 있지만 애석하게도 대비하지 못한 케이스는 늘 발생하곤 하며 상황에 따라서 데이터를 다시 얻거나 재현하기 위해 많은 자원을 소비할 수도 있습니다. 이럴 때 필요한 데이터의 변경 내역을 상시 기록하고 검색할 수 있다면 많은 도움이 될 수 있을 것 입니다.하지만 모든 경우에 대비하기 위해 변경 내역을 모두 저장하는 방법은 늘 옳은 방법은 아니며 상황에 따라 적절히 사용할 수 있는 수단 중의 하나 일 것 입니다.그럼 이제 알아보도록 하겠습니다. ^0^실시간 변경 내역 저장과 검색을 위한 AWS 서비스 아키텍처AWS Database Migration Service(AWS DMS)는 관리형 마이그레이션 및 복제 서비스이며 또한 Change Data Capture(CDC) 를 지원하여 데이터에 대한 변경을 식별하여 필요한 데이터 전송 및 전환 등과 같은 후속처리를 할 수 있습니다.다음은 DMS 의 기본적인 데이터 복제 프로세스입니다.DMS의 Replication task 는 Source endpoint 와 연결된 Source Database 로부터 변경된 데이터를 식별하여 Target endpoint 와 연결된 Target database 로 데이터를 전송하게 될 것입니다.우리는 Target endpoint 를 Kinesis Data stream 과 연결 후 Kinesis Firehose 를 통해 S3에 저장하고 Athena, Glue 를 이용하여 검색할 수 있도록 구성할 것이며 최종 아키텍처는 아래와 같습니다.변경 내역 검색을 위한 준비Athena 는 표준 SQL 을 사용하여 S3(Amazon Simple Storage Service)에 있는 데이터를 직접 간편하게 분석할 수 있는 대화형 쿼리 서비스입니다.Athena는 AWS Glue Data Catalog를 사용하여 S3 데이터에 대한 테이블 메타데이터를 저장하고 검색합니다.AWS Glue Data Catalog에서 데이터베이스 및 테이블 스키마를 만들려면 Athena 내에서 데이터 원본에 대해 AWS Glue 크롤러를 실행하거나 Athena 쿼리 편집기에서 데이터 정의 언어(DDL) 쿼리를 직접 실행합니다.Glue Data Catalog Database, Table 생성적절한 Name 을 입력한 후 Create database 선택하여 database 를 생성합니다.생성한 database 에 Table 을 생성합니다.데이터 저장소로 S3 를 선택 후 경로를 입력합니다. 빠른 검색을 위해 Parquet 을 사용합니다.Schem

안녕하세요, 인프라개발팀의 데이터 엔지니어 루 입니다. 이번 글은 EKS 환경 위의 애플리케이션과 API에서 보다 효율적인 로그 수집을 위해 EFK 스택을 도입한 이야기에 관해 다룹니다. 다음과 같은 분들이 읽으시면 도움이 되리라고 생각합니다. * 로그 수집 프로세스에 관심이 있는 개발자·엔지니어 * EFK / Kinesis 도입에 관심이 있는 분 * 여기어때컴퍼니의 로그 수집 파이프라인이 궁금하신 분 기존의 여기어때컴퍼니는 ELK 스택(elastic stack)을 사용하여 애플리케이션과 API, 서버에서 발생하는 로그 데이터를 검색·수집·모니터링 해 왔습니다. ELK 스택은 검색 및 분석 엔진인 Elasticsearch, 여러 소스에서 동시에 데이터를 수집해 변환한 후 목적지로 전송하는 데이터 처리 파이프라인인 Logstash, 차트와 그래프를 이용해 데이터를 시각화하는 Kibana를 말합니다. 로그를 조회하려면 서버에 접속해 직접 로그를 보는 방법도 있지만, 서버 수가 점점 늘어나거나, 서버와 연결이 원활하지 않을 경우 로그 확인이 어려울 수 있습니다. 만약 서비스에서 수집된 대량 로그를 실시간으로 조회하고, 특정 서버의 로그 검색을 쉽게 할 수 있다면 서비스 운영과 장애 대처 등 여러 상황에 많은 도움이 될 것입니다. 로그를 수집하고 모니터링하는 툴에는 많은 제품이 있고 각 프로젝트에서도 여러 제품을 사용하고 있지만, 여기어때컴퍼니에서는 * 사용자가 의도한 로그를 목적에 맞게 * 실시간, 대량으로 수집하고 * 통일된 인터페이스로 사용하기 위해 ELK, EFK 스택을 이용하여 로그 수집, 모니터링 환경을 구축하였습니다. LOGSTASH Logstash는 다양한 소스로부터 쉽게 로그를 수집할 수 있고, 필터를 사용하여 데이터들을 분석하기 쉬운 일관된 형태로 가공해 여러 플랫폼으로 정제된 데이터를 내보내는 로그 수집 프로그램입니다. 다음과 같은 장단점이 있습니다. 장점 * 별도의 코딩 없이 간단한 설정만으로 로그를 가공 * 엘라스틱서치의 인덱싱 성능을 최적화하기 위한 배치 처리, 병렬 처리가 가능 * 현재 처리 중인 이벤트의 최소 1회 전송을 보장 * 유동적인 데이터 처리 방식으로 수집 중인 데이터량이 급증하는 부하 상황에서도 안정성 보장 * 사용자가 많아 Logstash를 사용하다 문제가 발생해도 Elastic Discuss 포럼이나 Stackoverflow에서 같은 상황을 해결한 사람들의 사례를 찾기 쉬움 * 지속적인 버전 업그레이드 단점 * 조건문에 따른 데이터 라우팅이나 grok 패턴이 복잡할 수 있음 * JVM 힙 사이즈가 고정되어 있어 기본 메모리 사용량이 정해져 있음 Logstash의 경우, 애플리케이션 당 메모리를 1GB 정도 사용해 EKS 환경 위에서 사용하기엔 무거운 편이어서 메모리를 더 적게 사용하는 EFK 스택 도입을 고려하게 되었습니다. EFK에서 F는 보통 Fluentd를 지칭하나, 이 글에서는 더 가벼운 Fluent Bit을 의미합니다. Fluent Bit은 CNCF의 Graduated Project인 Flue