11 posts
들어가며: 늘어나는 서비스, 새로운 인프라, 끝없는 문의 여러분의 팀은 하루에 몇 번이나 같은 질문에 답하고, 같은 작업을 반복하고 계신가요? LINE Home DevOps 팀은 최근 팀원이 늘어났지만, VOOM 서비스를 안정적으로 운영하는 업무와 새로운 HomeTab 서비스 준비, 새로운 클라우드 인프라 플랫폼인 Flava로 전환하는 일이 겹치면서 오히려 더욱 바빠졌습니다. 어느 하나 포기할 수 없었기에 저희는 이 상황을 개선하기 위한 방법을 찾았고, 문득 팀의 에너지가 중요한 일이 아니라 반…
들어가며 안녕하세요. LINE Plus에서 Global E-Commerce 개발을 맡고 있는 장효택입니다. 기존 시스템을 새로운 환경으로 옮기거나 내재화하는 작업은 개발자에게 숙명과도 같습니다. 이때 가장 곤혹스러운 순간은 기존 로직의 근거가 되는 기획서가 없거나, 소스 코드조차 참조할 수 없는 블랙박스 상태일 때입니다. 저희는 외부 시스템에 의존하던 다양한 모듈을 내재화하는 과정에서 이 문제에 직면했습니다. ‘지금 우리가 만든 코드가 기존과 정말 동일하게 작동하는가?’라는 질문에 답하기 위해,…
시작하며 안녕하세요. SRE(Site Reliability Engineer)로 일하고 있는 어다희입니다. 저희 팀은 Media Platform SRE를 비롯해 글로벌 트래픽 관리 업무를 담당하고 있습니다. 그동안 ‘신뢰성 향상을 위한 SLI/SLO 도입’ 시리즈를 통해 SLI/SLO의 개념과 필요성을 살펴보고 플랫폼과 서비스에 적용한 사례를 공유해 왔습니다. 신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성 신뢰성 향상을 위한 SLI/SLO 도입 2편 - 플랫폼 적용 사례 신뢰성 향…
환경이 바뀌면서 과거에 내렸던 합리적인 결정이 더 이상 유효하지 않게 되는 일은 흔히 생깁니다. 이 글은 LINE 앱이 성장하면서 동적 설정 배포 시스템인 ‘서비스 설정’의 iOS 클라이언트가 어떤 도전을 받았고, 그 도전을 어떻게 헤쳐나갔는지 소개합니다. 서비스 설정이란? LINE 앱은 2주마다 새 버전이 배포됩니다. LINE 앱 안에는 여러 팀이 만들어 내는 수많은 서비스가 공존하기 때문에 개별 서비스의 요구 사항에 따라 배포 일정을 바꾸기는 곤란합니다. 이 제약 사항 때문에 ‘서비스 설정’…
들어가며: NeurIPS 2025가 제시하는 차세대 AI 안전 가이드 생성형 모델은 점점 더 우리 생활에 깊숙히 들어오고 있습니다. LY Corporation에서도 다양한 AI 서비스를 개발해 제공하고 있는데 이런 서비스에 가드레일(guardrails)이 없으면 다양한 공격을 받고 유해한 답변이 노출되거나, 개인 정보나 기밀 유출과 같은 오작동이 발생할 수 있습니다. 즉, 가드레일은 AI를 실서비스에서 운영 가능하게 만드는 필수 인프라입니다. 저희 조직은 사용자가 보다 안전한 환경에서 AI 서비…
들어가며 지난 엔터프라이즈 LLM 서비스 구축기 1: 컨텍스트 엔지니어링에서는 260개의 도구와 수백 페이지의 문서를 다루는 환경에서 LLM에게 필요한 정보만 골라서 제공하는 '점진적 공개' 전략을 공유해 드렸습니다. 1편이 AI에게 '무엇을 전달할 것인가?'에 대한 답이었다면, 이번 2편은 그 다음 질문으로 넘어갑니다. 정제된 맥락을 전달받는 에이전트를 '어떻게 만들 것인가?'입니다. 본격적인 이야기에 앞서, 먼저 현재 Flava AI 어시스턴트(이하 FAA)의 실전 성적표를 공개합니다. 저희…
TL;DR 네트워크 호출 없이 모바일 기기 내부에서 작동하는 이미지 이해 기능을 개발했습니다. 이 과정에서 거대 모델(teacher)의 정교한 표현력을 작은 모델(student)에게 전수하여 성능은 유지하면서 크기와 연산량을 획기적으로 줄이는 '지식 증류(knowledge distillation)' 기법을 핵심 전략으로 활용했습니다. 구체적으로는 모바일 앱에서 이미지 캡션 생성의 긴 지연을 해결하기 위해 일반적인 자기회귀(autoregressive, AR) 디코딩이 아닌 비자기회귀(non-aut…
들어가며 안녕하세요. LINE NEXT DevOps 팀에서 일하고 있는 이동원입니다. 저는 쿠버네티스 기반 인프라 운영과 CI/CD 구축, 모니터링 및 장애 대응 등 인프라 운영 관리 전반의 업무를 담당하고 있으며, 최근에는 AI를 활용한 개발 생산성 향상과 자동화에 깊은 관심을 두고 관련 학습과 실험을 병행하고 있습니다. 다양한 AI 모델과 도구를 테스트하며, 어떻게 하면 AI를 팀 전체의 개발 프로세스에 자연스럽게 통합할 수 있을지 고민하고 있습니다. 이번 글에서는 LINE NEXT에서 AI…
들어가며 안녕하세요. LINE VOOM 서비스의 포스트 서버를 개발하고 있는 서용준입니다. 이번 글에서는 저희 팀이 약 7개월에 걸쳐 슬로우 쿼리 문제를 해결한 과정과 그 과정에서 배운 교훈을 공유하고자 합니다. 저희 서비스에서는 헤비 유저의 소셜 프로필을 조회할 때 간헐적으로 슬로우 쿼리가 발생하고 있었습니다. 발생 빈도가 높지는 않았지만 한 번 발생하면 쿼리가 30초 이상 실행되다가 타임아웃이 발생했습니다. 결론부터 말씀드리면, MySQL 8.0.13의 함수형 인덱스(functional in…
안녕하세요. LY Corporation Observability Infrastructure 팀에서 사내 시계열 데이터베이스(time-series database, TSDB)의 개발 및 운영을 맡고 있는 오기준입니다. LY Corporation의 사내 프라이빗 클라우드 플랫폼은 단순한 가상 머신(virtual machine)을 제공하는 것을 넘어 쿠버네티스(Kubernetes) 기반의 컨테이너 환경과 데이터베이스, 로드 밸런서(load balancer) 등 방대한 서비스 포트폴리오를 제공하고 있습…
The LINE Billing Platform successfully migrated its large-scale payment database from Nbase-T to Vitess to handle high-traffic global transactions. While initially exploring gRPC for its performance reputation, the team transitioned to the MySQL protocol to ensure stability and reduce CPU overhead within their Java-based environment. This implementation demonstrates how Vitess can manage complex sharding requirements while maintaining high availability through automated recovery tools. ### Protocol Selection and Implementation - The team initially attempted to use the gRPC protocol but encountered `http2: frame too large` errors and significant CPU overhead during performance testing. - Manual mapping of query results to Java objects proved cumbersome with the Vitess gRPC client, leading to a shift toward the more mature and recommended MySQL protocol. - Using the MySQL protocol allowed the team to leverage standard database drivers while benefiting from Vitess's routing capabilities via VTGate. ### Keyspace Architecture and Data Routing - The system utilizes a dual-keyspace strategy: a "Global Keyspace" for unsharded metadata and a "Service Keyspace" for sharded transaction data. - The Global Keyspace manages sharding keys using a "sequence" table type to ensure unique, auto-incrementing identifiers across the platform. - The Service Keyspace is partitioned into $N$ shards using a hash-based Vindex, which distributes coin balances and transaction history. - VTGate automatically routes queries to the correct shard by analyzing the sharding key in the `WHERE` clause or `INSERT` statement, minimizing cross-shard overhead. ### MySQL Compatibility and Transaction Logic - Vitess maintains `REPEATABLE READ` isolation for single-shard transactions, while multi-shard transactions default to `READ COMMITTED`. - Advanced features like Two-Phase Commit (2PC) are available for handling distributed transactions across multiple shards. - Query execution plans are analyzed using `VEXPLAIN` and `VTEXPLAIN`, often managed through the VTAdmin web interface for better visibility. - Certain limitations apply, such as temporary tables only being supported in unsharded keyspaces and specific unsupported SQL cases documented in the Vitess core. ### Automated Operations and Monitoring - The team employs VTOrc (based on Orchestrator) to automatically detect and repair database failures, such as unreachable primaries or replication stops. - Monitoring is centralized via Prometheus, which scrapes metrics from VTOrc, VTGate, and VTTablet components at dedicated ports (e.g., 16000). - Real-time alerts are routed through Slack and email, using `tablet_alias` to specifically identify which MySQL node or VTTablet is experiencing issues. - A web-based recovery dashboard provides a history of automated fixes, allowing operators to track the health of the cluster over time. For organizations migrating high-traffic legacy systems to a cloud-native sharding solution, prioritizing the MySQL protocol over gRPC is recommended for better compatibility with existing application frameworks and reduced operational complexity.