Kubernetes 로 개발을 하다보면 이를 위한 cluster 가 하나씩은 있어야 한다. 로컬에 vm 이나 클라우드에 싱글 vm 을 받았다면 아래와 같이 kubeadm 을 활용하여 나만의 클러스터를 구축할 수 있다...

안녕하세요. 지난 8월, 에이닷 3.0이 새로운 모습으로 시장에 공개되었습니다.에이전트로서의 정체성을 한층 강화한 에이닷 3.0에서는 뮤직 에이전트 역시 완성도를 높이기 위한 다양한 변화를 시도했는데요.오늘은 뮤직 에이전트 개편 과정에서 활용된 기술 중 하나인 Multi Prompt Fine-tuning에 대해 소개해 드리겠습니다.파인튜닝(Fine-tuning) 은 사전 학습된 LLM을 특정 작업이나 도메인에 맞게 미세 조정하는 기술인데요.일반적으로는 하나의 작업이나 프롬프트를 하나의 LLM에 학습시키는 방식으로 사용됩니다.멀티 프롬프트 파인튜닝(Multi Prompt Fine-tuning) 이란, 일반적인 파인튜닝 과정과 달리 다양한 특화 작업을 하나의 LLM에 학습시키는 기술을 의미합니다.멀티 프롬프트 파인튜닝을 활용하면 모델 서빙 비용 절감, 일반화 능력 향상 등 다양한 개선을 기대할 수 있는 것으로 알려져 있습니다.뮤직 에이전트의 완성도를 향상시키는 과정에서 프롬프트의 수가 늘어나게 되었고, 각 프롬프트의 품질을 높히기 위하여 파인튜닝이 필요한 상황이 되었습니다.다만, 모든 프롬프트를 개별 모델로 학습하여 배포하기에 운영비용 측면에서 부담이 존재하였기 때문에 다소 모험적인 멀티 프롬프트 파인튜닝을 시도하게 되었습니다.지난 8월 개편 당시, 저희는 gpt-3.5-turbo 모델을 기준으로 멀티 프롬프트 파인튜닝을 시도했는데요.실험 초기에는 "LLM인데 여러 프롬프트를 한 번에 학습하는게 당연하지 않을까?"라는 생각으로 시작했지만,막상 실제로 학습데이터를 구성하여 학습을 수행하였을 때 예상치 못한 문제들을 마주치게 되었습니다.그래서 이번 섹션에서는 저희가 겪은 이슈들 중에서, 비슷한 시도를 하시는 분들께 도움이 될 만한 내용을 공유해 드리려 합니다.모델 통합 초기에 추가 실험 진행 여부를 고민하게 될 정도로 개인적으로는 매우 심각한 에러 상황이었습니다.초기 실험에서 저희는 각 프롬프트 별 학습 데이터를 임의로 섞어서 통합 학습 데이터를 구성한 후 모델을 학습시켰는데요.이렇게 학습된 모델을 테스트하는 과정에서 다음과 같은 에러가 간헐적으로 발생하였습니다.관련 문서와 마이크로소프트 문의 결과에 따르면 해당 현상은 LLM이 유니코드 문자를 생성할 때, 발생할 수 있는 gpt-3.5-turbo 모델의 버그인 것으로 확인되었습니다.저희는 해당 유니코드 생성 오류가 발생한 상세 원인을 학습 데이터 구성 방식에 있을 것이라고 가정하고,아래와 같이 하나의 배치에 동일한 학습 데이터가 배치되도록 구성을 변경하여 다시 모델을 학습시켜 보았고, 해당 방법을 통하여 유니코드 생성 오류가 해결되는 것을 확인할 수 있었습니다.모델 통합을 계획할 때 저희는 나름의 확신이 있었습니다.LLM에서 시스템 프롬프트가 코드의 if/else처럼 작동하여, 서로 분리된 영역에서 학습이 이루어질 것이라고 생각했기 때문인데요.하지만 실제로 학습 결과를 검증해 보니 예상치 못한 문제들을 마주하게 되었습니다.예를 들어, A 프롬프트에서 학습한 문체가 B 프롬프트에 활용되는 케이스

NEXT, N: 새로운 도약, 변화하는 네이버내일부터 양일간 DAY 1, DAY 2 각각 참가신청을 앞두고 팀네이버 개발자의 노하우와 경험을 MLOps, LLM, VISION, WEB 4개의 기술로 나누어 살펴봅니다.그 외에도 다양한 기술 세션이 있으니 잊지말고 내일 오후 3시 참가 신청 놓치지마세요!참가신청 페이지 바로가기 >>1. 속도와 효율의 레이스! : LLM 서빙 최적화의 모든것.초대형 언어 모델(LLM)을 효과적으로 운영하는 노하우와 최적화 방법, 그리고 AI 최적화 접근법에 대해 다룹니다. 이론적 내용부터 시작하여 측정 결과를 비교함으로써 최적화 방향에 대해 논의할 예정입니다. 내용은 다양한 분야의 참석자도 이해하기 쉽도록 기초부터 차근차근 설명할 예정입니다.2. HyperCLOVA X, MLOps로 Hyperscale AI 개발의 새로운 장을 열다네이버 초거대 AI 모델 HyperCLOVA X를 뒷받침하고 있는 AI/ML 플랫폼으로서 어떠한 문제를 겪고 해결해 왔는지, 그로 인한 결과가 무엇이고, 앞으로 어떠한 것을 준비하고 있는지 이야기합니다. 또한, MLOps 관점에서 HyperCLOVA X가 만들어지는 과정에서 어떠한 사례들이 있었는지 공유하려 합니다.3. FMOps로 스텝업: Place Vertical AI 서비스를 위한 FMOps 구축기Foundation Model 서비스를 구축하고 운영하는 데 관심 있는 분들과 대규모 모델 추론 서버 구축 및 성능 최적화에 관심 있는 있는 분들을 대상으로 Place Vertical AI Service소개와 FMOps 개념과 구축 과정, 시스템 레이어별 고도화 이야기를 공유합니다. 1. 검색과 피드의 만남: LLM으로 완성하는 초개인화 서비스네이버 서비스 홈피드의 초개인화 추천을 위한 LLM 활용 방안에 대해 공유합니다. 사내 LLM 모델인 Hyperclova X 를 기반으로 (1) 검색 의도 세분화 (2) 문서의 세부 주제 분류 를 모델링한 방식을 설명하고, 이를 기반으로 홈피드의 고도화된 유저 컨텍스트를 구축 및 실제 서비스에 적용하기까지 경험했던 노하우와 팁들을 소개합니다.2. 사용자 경험을 극대화하는 AI 기반 장소 추천 시스템 : LLM과 유저 데이터의 융합AI 기반의 장소 추천 시스템을 주제로, LLM을 추천 모델에 적용하는 과정에서 있었던 고민들과 실제 서비스 적용까지의 기술 노하우들을 공유합니다. 추천을 위한 LLM 모델을 어떻게 Fine tuning 했는지와 같은 LLM 모델이 주 내용이 아니며, LLM Model이 실제 비지니스에 적용되기까지 고군분투한 내용이 주이며, 새로운 language/vision 모델이 서비스를 전부 대체하는게 아니라, 기존의 추천 모델/데이터와 어떻게 시너지를 내고, 서비스 경험을 극대화할 수 있을지를 소개합니다. 또한 데이터 수집부터 서빙까지 vector 기반 모델/서비스에 대한 실질적인 운영을 알려드립니다.3. 네이버 검색이 이렇게 좋아졌어? LLM의 Re-Ranking Ability 검색에 이식하기LLM의 generation 능력을

'데마에칸(出前館)'은 2000년부터 서비스를 시작한 일본의 음식 배달 No.1 서비스로 2020년 당시, 아직 LINE이었던 LY Corporation에서 인수했습니다. 현재 일 본의 배달 서비스 시장은 한국보다 작은데요. 그만큼 성장 여력이 많다고도 할 수 있습니다.ABC Studio는 2021년 봄부터 데마에칸의 전체적인 리뉴얼을 진행하고 있습니다. 그중에서 'Recode'라는 이름으로, 서비스 스펙은 동일하지만 코드 베이스와 아키텍처를 100% 교체하는 작업을 진행했는데요. 이 글에서는 여러 가지 리뉴얼 방식 중 기존 코드를 새로운 코드 베이스로 교체하는 기술로 결정한 이유와 그 실행 과정을 소개하겠습니다. 아참, 프로젝트 이름을 Recode로 정했더니 Record로 잘못 쓰는 사람들이 많았습니다. 비슷한 프로젝트를 진행하실 예정이라면 다른 이름을 사용하시길 바랍니다. :)엔지니어라면 누구나 꿈꾸는 일이 있습니다. 마법의 빗자루로 하루아침에 레거시를 청소하고, 핑거 스냅 한 번으로 모든 사용자가 최신 버전을 사용하도록 만드는 일입니다(현실에서는 그렇게 강제했다간 사용자의 절반이 사라질 수 있습니다). 왜 한 번에 갈아엎는 작업은 스펙이 아무리 명료해도 어려울까요? 비즈니스는 하루도 쉬지 않고 전진해야 하는 상황에서, 회사가 다른 시급한 사항만큼이나 기술력 향상의 가치를 알아줘야 하고, 쉽지 않을 갈아엎는 작업에 대한 프로덕트 팀 내부의 합의도 필요하고, 합의한 뒤에는 그 프로덕트 팀의 고충을 이해해 줄 경영진과 사업 팀, 마케팅 팀, QA 팀, CS 팀 등 다른 구성원들의 공감대가 필요하기 때문입니다.앞서 열거한 주변 팀들의 희망 사항을 나열해 보면 아래와 같습니다.• 경영진: GMV(gross merchandise volume) 목표치를 달성해 시장에서 이기고 주주들에게 긍정적으로 응답하고 싶다.• 사업 팀: 새로운 초대형 파트너와의 계약이 임박했다. 새로운 결제 방식을 추가해 공급할 때까지 얼마나 걸리는지 알려 달라. 늦으면 그들이 경쟁사와 독점 계약할 위험이 있다(아... 글만 썼는데도 스트레스가...).• 마케팅 팀: 연휴에 반값 할인 행사를 하고 싶다. 쿠폰을 대량 발급하고 메신저 광고를 진행할 것이니 접속량이 피크에 달할 것으로 예상된다.• QA 팀: 새로 작성한 코드는 버그가 많을테니 아주 오랫동안 시간을 넉넉하게 잡고 QA를 해야 할 것이다. 3개월은 어떨까?• CS 팀: 당분간 버그가 많이 나올 텐데 콜센터에서 제대로 대응하지 못할 위험이 있다.모두가 공감할 수 있는 가치는 무엇이었을까요? 그리고 각각을 어떻게 설득할 수 있을까요? 개발자라면 누구나 레거시를 청소하고 싶을 것 같지만 과연 그럴까요? 대화해 보면 레거시 청산으로 얻을 좋은 개발 경험보다는 당장 어떻게든 비즈니스 요구 사항을 구현해 회사의 매출과 경제적 성장에 기여하는 것을 더 중요하게 생각하는 경우도 많았습니다. 그것이 좀 더 가시적인 성과이며, 이는 평가와 보상으로까지 이어지기 때문입니다. 따라서 회사 차원에서 이번 노력의 가치와 공헌을 잘 이해하

안녕하세요. 오늘은 토스 데이터 플랫폼팀에서 데이터 효율성을 높이기 위해 도입한 ‘Iceberg’에 대해 이야기해 보려고 합니다. Iceberg에 대한 기본적인 정보는 다른 곳에서도 쉽게 찾아볼 수 있지만, 저는 특히 유지보수와 운영 측면에 집중해서 이야기하려 합니다.최근 데이터의 양과 다양성이 급격히 증가하면서, 효율적인 데이터 파이프라인 구축의 중요성이 그 어느 때보다 커졌는데요. 특히, 실시간 데이터 조회와 수정, 운영 비용 절감, 스키마 진화의 간소화, 쿼리 성능 최적화와 같은 도전 과제들이 주요 이슈로 떠오르고 있습니다.이러한 문제를 해결하기 위해, 토스 데이터 플랫폼 팀은 작년 하반기부터 올해 상반기까지 ‘Iceage 프로젝트’를 진행하며 DataLake에 Iceberg 포맷을 도입해 효율적인 데이터 파이프라인을 구축했습니다. 이번 글에서는 Iceberg 도입을 통해 얻은 경험을 바탕으로, 유지보수와 운영 과정에서의 실질적인 팁과 인사이트를 공유하려 합니다. 글에 공유된 모든 예시는 Spark(버전 3.5.2)와 Iceberg(버전 1.5.2) 기준으로 작성되었습니다.저희 팀의 최종 목표는 다양한 데이터 소스(Kafka, CDC 등)로부터 입수된 데이터를 Iceberg 포맷으로 관리하여, 실시간으로 데이터를 조회하고 수정할 수 있는 효율적인 데이터 파이프라인을 만드는 것입니다. 이를 통해 운영 비용을 절감하고, 데이터 처리 효율성을 높이며, 스키마 진화와 쿼리 성능을 최적화하고자 했습니다.• None : 입수 후 5분에서 15분 이내에 데이터를 조회하고 수정할 수 있는 구조를 만들어서 사용자에게 실시간 데이터를 제공하고자 했습니다.• None : JSON으로 입수되는 데이터를 Parquet, Kudu로 적재하기 위한 비용을 절감하고, 리소스를 효율적으로 사용할 수 있는 파이프라인을 구축했습니다.• None : Iceberg의 스키마 에볼루션 기능을 활용해 스키마 변경 시 발생하는 복잡한 커뮤니케이션을 줄이고 리소스 사용을 최소화했습니다.• None : Iceberg의 히든 파티셔닝과 파티션 에볼루션을 통해 쿼리 성능을 최적화할 수 있었습니다.• None : Kafka Connect 기반의 입수 작업 메타데이터와 리니지 관리를 통해 운영 효율성을 크게 향상시켰습니다.• None : Iceberg의 트랜잭션 지원 덕분에 데이터의 일관성과 무결성을 유지할 수 있었습니다.• None Iceberg 메타데이터를 이용한 테이블 모니터링 시스템 구축 : Iceberg의 메타데이터를 활용해 테이블의 상태를 실시간으로 모니터링하고, 문제 발생 시 빠르게 대응할 수 있는 시스템을 구축했습니다.기존 데이터 파이프라인에는 어떤 문제가 있었고, 왜 위와 같은 목표를 세우게 됐는지 살펴보겠습니다.문제 #1: Kafka 데이터 처리와 CDC 입수의 문제점기존 데이터 처리에서는 Kafka와 CDC 데이터 입수 과정에서 여러 가지 문제가 있었습니다.• None Kafka 데이터를 JSON 형식으로 입수하고 Parquet 형식으로 변환하는 과정에서 고정된 리

복잡한 분기와 타입 추론의 고통개발을 하다 보면, 조건에 따라 서로 다른 로직을 실행해야 할 때가 많아요. 이러한 상황에서 우리는 흔히 문을 사용하죠. 하지만 복잡한 조건들이 겹쳐질수록 분기문은 점점 난잡해지고, 이를 유지 보수하는 것이 어려워집니다. 특히, 타입스크립트와 같은 강력한 타입 시스템에서는 타입이 추가될 때마다 모든 분기 조건을 다 신경 써야 하는데, 이를 놓치면 버그가 발생할 가능성이 커져요.저 또한 과거 프로젝트에서 타입이 추가되었음에도, 기존 분기문에서 해당 타입을 고려하지 않아 발생한 버그를 경험한 적이 있어요. 이러한 문제는 분기문의 복잡성을 줄이고, 타입 추론을 더욱 쉽게 할 수 있는 도구가 필요하다는 고민을 불러일으켰습니다.이러한 문제를 해결하기 위해 도입된 도구 중 하나가 바로 입니다. 이 라이브러리는 TC39에서 제안한 패턴 매칭을 기반으로 하고 있으며, 복잡한 조건부 분기를 간결하게 작성할 수 있게 도와줘요.과연 ts-pattern은 타입스크립트에서 if문을 대체할 수 있을까?• None 최근 벤치마크 , 삼항 연산자에 비해 성능이 현저히 떨어집니다.• None 문은 초당 약 10억 회 이상의 연산을 처리할 수 있는 반면, 초당 130만 회 정도의 연산을 수행하며 99% 더 느립니다.은 다양한 데이터 구조와 복잡한 타입 추론을 지원하기 위해, 입력 타입의 가능한 모든 경우를 사전에 계산하는데요. 내부 코드를 살펴보면 파일에서는 클래스 기반으로 패턴 매칭을 구현하고, this를 사용해 상태를 함수 체이닝을 통해 공유합니다. 이러한 방식은 안전한 타입 매칭을 제공하지만, 자바스크립트 엔진이 최적화된 기본 와 비교하면 성능이 떨어질 수밖에 없어요.이 성능 이슈는 복잡한 분기 로직에서 을 무조건 사용해야 하는지에 대해 고민하게 만들었습니다.우리는 실제로 ts-pattern을 어떻게 사용하고 있었나?실제로 제가 을 사용한 코드를 돌아봤을 때, 대부분 복잡하지 않은 코드에서 사용되고 있었어요. 복잡한 분기 로직이나 타입 체크가 필요한 상황에서는 이 큰 도움이 되었지만, 그렇지 않은 경우에는 오히려 오버엔지니어링처럼 느껴졌고요.특히 문법을 사용해 조건에서 처리되지 않은 모든 경우를 타입스크립트 컴파일러가 감지하고 타입 체크를 할 수 있다는 점에서는 유용했지만, 간단한 조건 분기를 처리할 때는 기존 방식이 더 효율적일 수 있다는 생각이 들었어요.또한 다시 한번 생각해봐야 할 질문은, “정말 을 사용할 만큼 복잡한 분기가 자주 발생하는가?”입니다. 복잡한 분기가 필요할 때도 있지만, 그런 상황에서는 “오히려 코드를 더 간결하게 만들 수 있는 방법을 고민하는 것이 본질적인 해결책이 아닐까?” 라는 생각도 해보았어요.복잡한 분기문을 간결하고 안전하게 처리하는 방법1. 복잡한 분기문을 단순하고 안전하게 처리하기복잡한 분기는 피할 수 있다면 나 를 사용해 더 단순하게 표현하는 것이 좋아요. 특히 early return 패턴을 활용하면 조건을 명확하게 처리할 수 있어요.을 사용해 더 선언적으로 분기 처리를 다룰 수 있습니다.여기서

bread.young 비동기 관련 로깅은 항상 고민하는 포인트 중 하나라고 생각하는데요, 비동기를 독립적인 새로운 Context로 생각하여 신규 고윳값을 부여해 관리하는 아이디어가 인상 깊었습니다.💡rain.drop 시리즈의 마지막 포스팅이네요! 개발을 하다 보면 상황에 따라 WebFlux 환경에서 개발하기도, 혹은 배치성 API를 개발하기도 하는데요. 이러한 상황 속에서 겪게 되는 로깅의 불편함은 Part 2와 달리 새로운 해결책이 필요합니다! 포도는 어떻게 개선했을까요? 같이 들여다보아요~!!안녕하세요. 해외결제서비스유닛에서 서버 개발 업무를 맡고 있는 포도입니다.지난 포스팅인 Part1 - 이슈 트래킹 기반 마련하기, Part2 - Thread Context 적극 활용하기에서는 좀 더 정교한 이슈 트래킹을 위해서 발전하는 과정을 설명하였습니다. 이번 포스팅은 “좀 더 정교한 이슈 트래킹”의 마지막 편으로 Multi Thread Context를 통해 한층 더 발전한 이슈 트래킹 전략을 설명하려고 합니다.앞서 Part2에서는 좀 더 기민하게 대응할 수 있는 이슈 트래킹 전략을 구성했습니다. 하지만 실제로 서비스를 운영해 보면 몇 가지 Edge 케이스에서 한계점을 겪게 됩니다. 바로 다음과 같은 상황입니다.• 비동기 로직의 이슈 트래킹이번 포스팅인 Part3의 본문에서는 하나의 Thread Context가 아닌 Multi Thread Context를 사용하여 위의 한계점을 극복하는 내용을 설명하려고 합니다. Part3는 Part1, Part2의 내용을 기반으로 작성되었습니다.따라서 본문 내용에 앞서 Part1, Part2 내용을 읽어보시기를 권장합니다.본문에 앞서 Part1, Part2의 내용을 정리하면 다음과 같습니다.Part1에서는 ELK 환경에서의 Request 요청 로깅과, Sentry를 사용하여 이슈 트래킹의 기반을 마련하였습니다. 따라서 이슈를 파악할 수 있는 정보들의 가시성을 확보하고, 개발자에게 알림을 제공하여 이슈 발생 시 기민하게 대응할 수 있는 기반을 마련하였습니다.Part2에서는 Part1 기반의 문제점을 Thread Context를 사용하여 좀 더 발전한 과정을 설명하였습니다. 수많은 요청 로그에서 예외가 발생한 로그를 찾는 어려움을, Thread Context에 라는 요청 키값을 공유함으로써 원클릭으로 로그에 접근하는 지름길을 만들어 해결했습니다.또한 요청 로그에 남기지 못한 정보들을 를 사용하여, 비즈니스에서 가시성을 확보하고 싶은 데이터의 정보들을 자유롭게 담을 수 있는 구조를 완성하였습니다. 그 결과 라는 필드를 통해 다음과 같이 원인 분석에 필요한 정보들의 가시성을 자유롭게 확보할 수 있었습니다.이제 Part3에서는 Part2의 전략을 사용하면서 발견한 Edge 케이스들을 Multi Thread Context를 사용하여 극복한 방법을 공유드리겠습니다.서비스를 설계하다 보면 배치성 API가 필요할 때가 있습니다.배치성 API는 API 요청 시 배치성 비즈니스가 실행되는 것을 의미합니다. 해외결제서비스도 Jo

안녕하세요. 에이닷 iOS App을 개발하고 있는 김혜지입니다.현재 저희 팀은 SwiftUI로 에이닷 iOS app을 개발하고 있습니다.SwiftUI는 아직 그 역사가 짧다 보니 예상치 못한 문제들이나 어떻게 개발하는 것이 맞는지에 대한 고민이 잦은데요🥲이번 포스팅 역시 팀원분들과 이야기하다 나온 주제에서 영감을 얻었습니다.SwiftUI로 개발하다 보면 아래와 같이 에 helper property로 를 만드는 경우가 있습니다.와 에서 를 생성했을 때의 차이가 있다는 것을 알게되어 여러분께 한 번 말씀드려보고자 이 글을 쓰게 되었습니다.SwiftUI로 개발하고 계시거나 Swift Concurrency를 사용하시는 개발자 분들이라면 관심을 가지실 주제일 것 같습니다이 글은 SwiftUI와 Actor isolation을 포함한 Swift Concurrency를 이해하고 계시면 더욱 읽기 좋습니다.SwiftUI로 개발하면서 modifier 참 많이 사용하는데요. 혹시 이 modifier는 어느 쓰레드에서 실행이 되는지 아시나요?아래 코드의 주석 // 1과 // 2 모두 main thread 에서 실행되는 것이 보장될까요?새로 추가한 method는 로 annotate 되어 main thread에 대한 isolation이 보장된 곳에서만 호출이 가능합니다.를 키워드 없이 호출할 수 있는 가 main actor isolation, 즉 main thread에서 실행이 보장된 곳이겠죠.• None 1번 : main thread 에서의 실행이 보장됨• None 2번 : main thread 에서의 실행이 보장되지 않음사실 1번 의 main thread 실행은 당연한 것입니다. 이유는 다음과 같습니다.• None 의 파라미터는 로 annotate 되어 있음.하나씩 자세히 알아보겠습니다.의 정의는 다음과 같습니다.는 라고 명시적으로 annotate 되어있네요...2. 의 파라미터는 로 annotate 되어 있음modifier의 정의만으로는 파라미터에 대한 비밀을 알 수가 없군요... 그래서 SwiftUI module interface를 한 번 열어보았습니다.로 annotate 되어 있네요. annotation은 클로져들이 actor context를 inherit 하게 만들어줍니다.하지만 2번 도 때로는 main thread에서 도는 것이 보장될 수도 있습니다.위 코드를 빌드해보면 2번 task 에서도 async 키워드 없이도 test 메소드를 호출할 수 있는 것을 확인할 수 있습니다.이게 왜 되는지 결론부터 말하자면 global actor inference에 의해 를 갖고 있는 우리의 가 가 되었기 때문인데요...이 기묘한 상황을 이해하기 위해 Swift Evolution의 문서를 바탕으로 Global Actor Inference에 대해 간단하게 이야기 해보겠습니다.라고 합니다. 내가 global actor로 명시하지 않은 곳들에서도 global actor isolation이 추론(infer)될 수 있다고 하네요. 조금 더 읽어보겠습니다.actor-quali

• None JdbcPagingItemReader는 Spring Batch에서 제공하는 ItemReader로, 데이터베이스로부터 데이터를 페이지 단위로 읽는다.• None 대규모 데이터 처리 효율성: 메모리 사용량을 최소화하고 커밋 간격을 설정하여 대규모 데이터를 효율적으로 처리할 수 있다.• None 쿼리 최적화: SQL 쿼리를 직접 작성하여 최적화된 데이터 읽기가 가능하다.• None 커서 제어: 데이터베이스 커서를 사용하여 데이터 순회를 제어할 수 있다.• None DataSource: 데이터베이스 연결 정보를 설정한다.• None SqlQuery: 데이터를 읽을 SQL 쿼리를 설정한다.• None RowMapper: SQL 쿼리 결과를 Item으로 변환하는 역할을 한다.• None PageSize: 페이지 크기를 설정한다.• None SkippableItemReader: 오류 발생 시 해당 Item을 건너뛸 수 있도록 한다.• None ReadListener: 읽기 시작, 종료, 오류 발생 등의 이벤트를 처리할 수 있도록 한다.• None SaveStateCallback: 잡 중단 시 현재 상태를 저장하여 재시작 시 이어서 처리할 수 있도록 한다.• None 쿼리 Provider는 실제 배치를 위해서 데이터를 읽어올 쿼리를 작성한다.• None setDataSource: 데이터소스를 설정한다.• None setSelectClause: select에서 프로젝션할 필드 이름을 지정한다.• None output 디렉토리에 customer_new_v1.csv 파일이 생성되고 내용은 다음과 같다.• None 지금까지 JdbcPagingItemReader를 이용하여 데이터베이스의 내용을 읽어서, 파일로 저장해 보았다.• None JdbcPagingItemReader은 데이터소스를 주입받고, QueryProvider를 이용하여 쿼리를 작성하는 코드도 작성해보았다.• None 페이징 처리의 성능을 개선하면, 매우 큰 데이터도 효율적으로 수행할 수 있다.• None 페이징은 pageSize로 지정된 수만큼 읽어오고, 이를 청크로 전달된다는 것도 확인할 수 있었다.• None JdbcBatchItemWriter Spring Batch에서 제공하는 ItemWriter 인터페이스를 구현하는 클래스이다.• None 데이터를 JDBC를 통해 데이터베이스에 저장하는 데 사용된다.• None DataSource: 데이터베이스 연결 정보를 지정한다.• None SqlStatementCreator: INSERT 쿼리를 생성하는 역할을 한다.• None PreparedStatementSetter: INSERT 쿼리의 파라미터 값을 설정하는 역할을 한다.• None ItemSqlParameterSourceProvider: Item 객체를 기반으로 PreparedStatementSetter에 전달할 파라미터 값을 생성하는 역할을 한다.• None 데이터베이스 연동: JDBC를 통해 다양한 데이터베이스에 데이터를 저장할 수 있다.• None 성능: 대량의 데이터를 빠르

안녕하세요, 토스 코어 Data Warehouse 팀의 김문수입니다.Spark 작업이 효율적으로 실행되는지 모니터링하기 위해서 Spark Analyzer를 만든 경험을 공유하려고 합니다. 저희와 비슷한 고민을 가진 분들께 도움이 되길 바랍니다.• None Spark Job이 많아 관리가 어려워지고, 어디서부터 성능을 개선해야 할지 막막한 분• None Spark 클러스터 비용이 많이 나오거나, 리소스가 부족해서 고통받는 분• None 많은 유저들이 만들어 낸 Spark Job을 직접 고칠 수 있게 돕고 싶은 분일단 돌아가게 만든 작업들이 모이면, 비싸고 느린 데이터 파이프라인이 됩니다.Spark는 굉장히 강력한 도구이지만, 잘못 사용하면 비효율적으로 동작하여 시스템에 부담을 줄 수 있습니다. 토스코어에서는 하루 평균 6천 개 이상의 Spark 작업이 매일 또는 특정 주기로 실행되고 있는데요. 여러 팀에서 각기 다른 수준과 방식으로 작업을 추가하고 운영하다 보니 효율성이 떨어지는 작업이 종종 추가되기도 합니다. 그리고 비록 처음에는 효율적으로 만들었다고 하더라도, 시간이 지나면 처리하는 데이터의 양상이 달라져서 비효율적으로 동작하는 경우도 있습니다.이러한 비효율적인 작업을 모니터링하고 개선할 방법을 고민하던 중, Uber의 Spark Application 안티 패턴을 다룬 블로그 글에서 영감을 받았습니다. Spark 메트릭을 계산해, 성능 개선이 필요한 작업이 있으면 시스템이 자동으로 경고를 보내는 구조를 만들고자 했습니다.그러던 와중에 DataFlint라는 플러그인을 사용하게 되었습니다. DataFlint는 Spark Application UI와 History Server를 통해 다양한 메트릭을 시각적으로 보여주어 문제를 직관적으로 파악할 수 있게 도와주는 도구입니다.DataFlint만으로도 Alert 화면에서 이 작업에 대한 문제를 바로 알 수 있어서 도움이 되고, 필요로 하는 핵심적인 metric이 구현되어서 좋긴 합니다만, 화면에 일일이 들어가서 확인하는 것은 비효율적이었습니다. (하루 평균 6천 개…!)그래서 처음에는 Spark History Server에서 애플리케이션 목록을 구해서 DataFlint로 분석하고, 이를 기반으로 알림을 주기적으로 보내는 시스템을 구상했어요. 그런데 역시 쉽지가 않더라고요. DataFlint는 당시 오픈소스로는 REST API를 제공하지 않고 있기 때문이었어요. 고민이 됐습니다. “API는 없더라도 화면에는 보이니까 web parsing을 해야 할까?” 하고요.결국 Spark History Server의 API와 자체적으로 계산할 수 있는 메트릭을 활용하는 방향으로 선회했습니다. 직접 계산하는 것이 커스텀 메트릭을 추가하거나 임계치를 조정할 때 훨씬 유연하겠다는 결론을 내렸기 때문이에요.이제 가능성을 봤으니, 구조를 고민하고 구현하면 됩니다. Spark History Server에서 Spark Job의 메트릭을 수집하고 이를 분석하는 두 가지 주요 단계로 작업을 구성했어요.첫 번째 단계는 작업 이력