안녕하세요, 뉴넥스 AI 검색팀의 신누리입니다.현재 팀 내 유일한 검색 담당으로서, 뉴넥스의 패션 커머스 플랫폼들 -브랜디, 하이버, 서울스토어, 셀피- 전체 검색 프로덕트를 책임지고 있습니다. 구체적으로는 검색 데이터 파이프라인 구축 및 유지보수, 검색엔진 관리, 검색 API 개발, 검색 사전 관리 등 검색과 관련된 모든 부분을 매니징하고 있습니다.클라우드(AWS) PaaS 및 SaaS 환경에서 검색 시스템을 A부터 Z까지 설계하고 매니징하는 경험은 처음 이었지만, 이전에 온프로미스(On-Premise) 기반의 자바(Spring) 환경에서 검색 서비스를 개발하고 ElasticSearch를 활용한 경험이 있었기 때문에 운영과 관리가 용이한 검색 내재화를 목표로 시스템을 구축하게 되었고, 현재까지도 검색시스템을 안정적으로 운영하고 있습니다.이 경험을 바탕으로, 이번 포스팅에서 최소한의 휴먼 리소스로 여러 서비스의 검색 시스템을 운영할 수 있도록 구축한 검색 시스템을 소개하려 합니다.🤔 검색 시스템 구축 이전브랜디와 하이버는 기존에 SaaS 형태로 제공되는 타사의 검색 솔루션을 사용하고 있었습니다. 이는 상품 데이터를 주기적으로 JSON 파일로 추출하여 검색 솔루션과 연계하고, REST API를 통해 검색 질의를 수행하는 방식이었습니다. 이러한 접근법은 단순하고 편리한 점이 있었으나, 뚜렷한 한계점이 있었습니다.비즈니스 및 요구사항 변화에 대한 빠른 대응의 어려움 대표적으로 전시 정책 변경이 있습니다. 검색은 전시 정책과 밀접하게 연관되지만, 정책 변경 시 내부 시스템에는 즉시 반영되지만 외부 솔루션에는 적용이 지연되는 문제가 있었습니다.확장성 부족 새로운 서비스를 추가할 때, 비즈니스 특성을 빠르게 이해하고 도메인을 반영하기 위해서는 내부 인력의 긴밀한 협조가 필요했지만, 외부 솔루션 사용 시 이 과정이 더 어려웠습니다.증분 색인 주기 하루에 한 번 전체 색인 주기가 있었고, 30분마다 추가/수정/삭제된 상품들을 증분 색인을 통해 반영했습니다. 도메인에 따라 30분마다 충분할 수 있지만, 패션 커머스 플랫폼에서는 빠른 수정 사항 반영이 필요합니다.이러한 문제점들을 해결하고자, 저희는 더 유연하고 효율적으로 시스템을 운영하기 위해 내부에서 직접 검색 시스템을 구축하고 관리하기로 했습니다.🎈검색 파이프라인 도입기데이터가 검색 결과로 노출되기까지는 대부분 아래와 같은 단계로 이루어 집니다.데이터 추출 → 데이터 색인 → 검색 질의 및 응답💡색인이란데이터를 분석하고 구조화하여 검색 엔진이 빠르게 검색 결과를 반환할 수 있도록 데이터베이스나 인덱스를 구축하는 것앞으로 데이터추출과 데이터색인 과정을 편의상 ‘검색 파이프라인’이라고 부르겠습니다.즉, 검색 데이터 파이프라인은 체계적으로 설계된 프로세스로 주기에 따라 운영됩니다. 이 과정에서 유효한 데이터를 정교하게 추출(Extract)하고, 비즈니스 인텔리전스를 적용하여 최적화된 형태로 변환(Transformation)합니다. 최종적으로 이렇게 가공된 데이터는 검색 시스템의 효율적으로 색인(In

안녕하세요, 베이글코드의 데이터 엔지니어 하석윤 입니다. 베이글코드에서 사내 데이터 디스커버리 툴로 사용하고 있는 데이터헙(DataHub)을 도입한 여정을 소개드리고자 합니다 😁DataHub을 왜 도입하게 되었는가?DataHub을 띄우자!Metadata IngestionAirflow Integration어떻게 사용하고 있나요?DataHub을 운영하면서 겪은 어려움사내 유저들의 사용 후기DataHub을 왜 도입하게 되었는가?2020년부터 데이터팀은 아문센(Amundsen)라는 데이터 디스커버리 툴을 도입해 사용하고 있었습니다. 그러나…2022년 당시 데이터팀은 amundsen-databuilder 4.1.0 버전을 사용하고 있었습니다. 자동화를 위해 Airflow에 amundsen-databuilder 패키지도 설치 해뒀구요. 그런데 이것이 Airflow에 설치된 다른 pip 패키지들과 충돌을 일으켰고, 결국 Airflow 업그레이드 작업을 방해하는 요인이 되었습니다.결국 Amundsen을 대대적으로 업그레이드 하기로 계획했고, Amundsen에서 검색과 그래프 데이터베이스의 역할을 담당하는 ElasticSearch와 Neo4j도 함께 OpenSearch, AWS Neptune 등으로 교체하기로 하였습니다.하지만, 당시의 Amundsen이 AWS OpenSearchd와 Neptune 지원이 제대로 되지 않았습니다. Amundsen을 직접 커스텀해야 하는 일도 있었습니다.이렇듯 업그레이드 하는 작업이 생각보다 쉽게 이뤄지지 않았고, 덩달아 다른 작업들도 함께 블록 되는 것을 보고, 데이터팀에선 Amundsen은 폐기하고 다른 데이터 디스커버리 플랫폼을 찾아 새로 도입하기로 결정 했습니다.DataHub vs. Amundsen: Github StarsAmundsen을 대체할 새로운 디스커버리 도구를 찾던 중에 데이터헙(DataHub)라는 도구가 눈에 들어왔습니다. Github Star 갯수도 더 많고, Slack 커뮤니티도 활발한 데다가 DataHub 공식 유튜브에 각종 영상 자료도 많다는 점이 DataHub 도입을 결정하는데 긍정적인 요소가 되었습니다.DataHub을 띄우자!데이터팀은 모든 워크로드를 Kubernetes 환경 위에서 운영합니다. DataHub도 EKS 위에서 디플로이 하였는데요. DataHub 공식 helm chart를 사용해 EKS 클러스터에 디플로이 하였습니다.Datahub의 구조DataHub의 구조는 크게 Application Tier과 Persistent Tier로 나뉩니다. Application 단에서는 DataHub이 MSA 구조로 워크로드를 운영하는데, 쉽게 설명하면, frontend와 backend(GMS)로 구성되었다고 볼 수 있습니다. GMS는 “Generalized Metadata Service”의 약자로 메타데이터 정보를 Persistent Tier에 저장하고, 또 가져오는 역할을 수행합니다.Persistent 영역은 각종 메타데이터가 저장되는 곳입니다. Mysql에 Table, Database과 같은 데

"로봇을 위한 MLOps #1: Edge device와 K3s, Airflow" 편에서는 로봇을 위한 머신러닝 모델을 개발하는 과정을 소개하고 이를 위해 MLOps 인프라스트럭처를 어떻게 구축하였는지를 설명하였습니다. GPU workstation 및 엣지 디바이스(edge device)들에 워커(worker) 노드를 설치하고 Kubernetes 및 Airflow를 사용해 이들 노드에서 전체 파이프라인을 실행하는 방법을 살펴보았습니다.이번 편에서는 엣지 디바이스에서 작동하는 엣지 파이프라인(edge pipeline)의 구성, 그리고 이 파이프라인에서 사용한 도구들과 특징을 소개하겠습니다. 특히 다중 모델을 동시에 추론할 때의 성능을 평가하기 위하여 자체 개발한 도구인 Trt-Infersight를 이 글에서 처음으로 소개하고자 합니다.엣지 파이프라인의 필요성로봇, 자동차, 드론 등에 쓰이는 자율주행 기술은 이제 우리의 일상에서 흔히 접할 수 있게 되었습니다. 이러한 장비들에는 우리가 사용하는 컴퓨터와 유사한 기능을 하는 하드웨어가 탑재되어 있습니다. 이 하드웨어는 일반적으로 Arm 아키텍처를 기반으로 하는 CPU를 사용합니다. Arm 기반 CPU는 낮은 전력 소모 덕분에 발열도 적고 배터리도 적게 사용한다는 장점이 있기 때문이죠. 또한, 이 하드웨어는 보통 GPU를 포함하고 있어, 그래픽 디스플레이 처리뿐만 아니라 딥러닝 모델의 추론, 이미지 및 비디오 처리 등 고성능의 병렬 연산을 요구하는 작업을 수행할 수 있습니다.우리가 개발하는 자율주행 로봇 ‘딜리(Dilly)’에도 CPU, GPU뿐만 아니라 DLA(Deep Learning Accelerator), VIC(Video Image Compositor), HW encoder/decoder 등과 함께 여러 센서 인터페이스가 패키징된 NVIDIA Jetson 플랫폼을 기반으로 하는 임베디드 보드가 내장되어 있습니다. 임베디드 보드에 GPU, IMU, LiDAR, 카메라 등 다양한 센서들을 로봇에 연결할 수 있고, 자율주행과 관련된 복잡한 연산들이 로봇에서 효율적으로 수행될 수 있습니다. 이와 같은 임베디드 보드가 우리의 엣지 디바이스가 됩니다.엣지 디바이스에서의 AI 연산이 필요한 이유최근 on-device AI라는 용어를 많이 들어보셨을 텐데요. 이는 클라우드나 기타 서버에 의존하지 않고 엣지 디바이스 자체에서 AI 연산을 수행하는 것을 말합니다. 이를 위해서는 디바이스 내부의 연산 자원만을 활용하여 많은 연산을 하는 기술이 필요합니다.이러한 on-device AI 기술은 자율주행 로봇과 자율주행 자동차에 필수적입니다.첫째, 자율주행 기계들은 실제 주행 환경에서 일어나는 일들에 대해 실시간으로 기민하게 반응해야 하기 때문입니다. 연산을 할 때마다 서버와의 무선 통신이 필요하다면 시간 지연이 생길 것입니다.둘째, 주행 중 인터넷 연결이나 기타 무선 통신 연결이 잠시 단절되는 일이 종종 발생할 텐데, 그런 상황에서도 자율주행 기계는 멈추지 않고 작동해야 하기 때문입니다.셋째, 민감한 개인 정보를

서버리스에서 쿠버네티스로 - Airflow 운영 경험기서버리스 Airflow를 쿠버네티스 환경으로 전환하며 경험한 삽질들• 관리형 서비스에서 K8S로• 운영 이슈와의 조우• 워커의 사라진 실행 로그 찾기안녕하십니까 컬리 데이터서비스개발팀 데이터 엔지니어 김영준입니다. 컬리에서는 수많은 데이터 파이프라인과 MLOps, BI (Business Intelligence) 등 다양한 분야에서 워크플로 관리 플랫폼인 Airflow를 사용하고 있습니다. 최근 그중 데이터 파이프라인에 사용하던 Airflow를 관리형 서비스에서 Kubernetes (이하 K8S) 환경으로 이관을 진행하고 안정적인 운영을 위한 여러 작업을 진행하였습니다. 이 글에서는 그 과정에서 겪은 다양한 경험들을 공유해 보고자 합니다.관리형 서비스에서 K8S로컬리의 데이터 플랫폼은 K8S 환경과 여러 관리형 서비스들을 사용하여 구축되어 있으며 지속해서 기술 성숙도를 높이기 위해 노력하고 있습니다. 그런 노력중 하나로 오픈소스 기반의 관리형 서비스를 직접 관리하는 K8S 환경으로 전환하기 위해 도전하고 있으며 이번엔 데이터 파이프라인에 사용중인 Airflow의 운영 환경을 전환 하였습니다. 이를 통해 성능 및 비용 최적화를 달성하고 있으며 직접 부딪히며 기술의 수준을 끌어올리고 있기도 합니다.데이터 파이프라인에 사용중인 Airflow의 초기 구축은 AWS의 Managed Workflows for Apache Airflow 또는 GCP의 Composer 등과 같은 CSP (Cloud Service Provider)의 SaaS (Software as a Service)를 이용하여 손쉽고 빠르게 구축하였습니다. 시간이 지나고 기술 성숙도를 높여 K8S 클러스터 환경으로 전환하는 것에 도전하였습니다.Helm을 통해 K8S 환경에 배포한 Airflow는 위 다이어그램의 형태로 구성되어 있습니다. 각각의 컴포넌트는 Metadata DB와 정보를 주고받으며 상태를 동기화하고 사용자는 웹서버를 통해 Airflow의 상태를 확인할 수 있습니다. Airflow의 작업은 스케줄러(Scheduler)와 트리거(Trigger)에 의해 레디스 큐에 발행되며, Pod나 셀러리 워커(Worker)에 순차적으로 할당되어 실행됩니다.운영 이슈와의 조우Airflow GitSync는 DAG를 로컬 디렉토리가 아닌 Github Repository와 같은 git 저장소에서 관리하는 기술입니다. 여러 사람이 git을 통해 DAG 파일을 추가하거나 수정하는 등 관리하기에 편리하여 사용하고 있습니다.이관해 올 DAG들을 추가해주자 Airflow 스케줄러 (Scheduler)의 CPU 사용량이 급등하는 현상을 대시보드를 통해 확인했었습니다. 특히 저 당시에는 새로 배포한 Airflow 뿐만 아니라 개발용으로 배포되어 있던 Airflow도 같은 Git 레포지토리를 GitSync 해주고 있었기 때문에 배포되어 있던 두 가지 Airflow가 동시에 DAG 추가의 영향을 받았습니다.새로 배포한 Airflow는 스케줄러의 CPU 사용량이 0.25 core에서 0.45 core로 80% 증가, 개발용 Airflow는 스케줄러의 CPU 사용량이 0.4 core에서 2.7 core로 675% 증가했었습니다.스케줄러는 DAG의 실행을 관리하는 역할을 수행하기 위해 지속해서 DAG 파일을 구문분석하고 작업을 적재적소에 할당합니다. DAG가 추가되면서 스케줄러의 CPU 사용량이 증가한 상황이므로 CPU의 파일 I/O를 줄이면 좋겠다는 조언을 받아서 Airflow의 작동에는 큰 영향을 주지 않을 적절한 파라미터를 찾게 되었습니다. 스케줄러가 DAG에 대한 업데이트를 위해 구문분석하는 시간 주기인 값이었습니다. 값은 증가시키면 새로운 DAG 변경 사항의 반영이 느려지지만 파일 I/O의 빈도가 줄기 때문에 CPU 사용량이 줄어들기를 기대했습니다. 마침 DAG의 변경이 많지 않고 조금 늦게 반영이 되어도 문제가 없어서 이 값을 상향 조정시켜 주었습니다.다행히 CPU 사용량은 효과적으로 감소하였습니다. “장애는 발생하지 않았으니 상관없다.” 라 생각할 수 있지만, 충분히 해결 가능한 문제였기 때문에 바로 대응을 했던 이슈였습니다.나중에 알게 된 사실이지만 GitSync는 다른 컴포넌트들에서도 동작하는데 스케줄러에서 크게 영향을 받은 이유는 위 그림 처럼 Airflow 2.0 버전부터 GitSync한 DAG 파일을 직렬화하여 Metadata를 관리하는 DB에 저장하는 작업도 수행하기 때문이었습니다.Airflow의 워커는 스케줄러와 트리거가 DAG의 태스크를 차례대로 수행하는 핵심적인 역할을 합니다. DAG의 작업을 수행하기 위해 Celery를 사용하는 워커는 태스크가 할당되면 이를 처리하기 위해 필요한 자원을 요청합니다. 그런데 이 워커들이 자원을 많이 사용하다 보니 파드나 노드가 비정상적으로 종료되어 장애가 발생하는 이슈가 있었습니다.원인은 메모리 부족(OOM: Out of Memory)으로 워커에서 태스크를 수행하기 위해 자원을 요청하는 과정에서 자원이 충분하지 않거나 자원 경합이 발생하면 OOM 문제가 발생하여 파드나 노드가 비정상적으로 종료되는 문제였습니다. OOM 문제가 발생하면 애플리케이션이 중단될 수 있기 때문에 워크플로우 전체가 지연되거나 실패하게 됩니다. OOM 이벤트가 반복적으로 발생하면 시스템의 안정성과 성능에 심각한 영향을 미치며, 다른 파드나 서비스에도 연쇄적인 문제를 일으킬 수 있는 큰 문제입니다. 이 문제를 해결하기 위해 K8S와 Airflow에 관해 많은 연구와 시행착오를 겪었습니다.OOM 문제는 다양한 원인으로 발생할 수 있으므로 간단한 문제가 아니라고 생각합니다. 특히 여러 계층으로 애플리케이션을 관리하는 K8S 환경에서 Airflow를 운영하고 있었기 때문에 확인해야 할 부분이 많았습니다.Airflow가 동작하고 있는 K8S 환경은 효율적인 자원 활용을 위해 노드 내에서 한 파드가 자원을 상한선보다 적게 사용 중이라면 다른 파드가 이 파드의 자원을 사용할 수 있는 오버 커밋을 지원하고 있습니다. 하지만 이에 따라 한정된 자원을 더 할당받기 위해 요청을 하다가