라인

RSS

게시글: 564
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

DevOps
신뢰성 향상을 위한 SLO/SLI 도입 3편 - 서비스 적용 사례
본 글은 신뢰성 향상을 위한 SLO(Service Level Objective)와 SLI(Service Level Indicator) 도입의 세 번째 이야기로, 실제 서비스에 적용한 사례를 다룹니다. SRE(Site Reliability Engineer) 팀은 사용자에게 안정적인 서비스를 제공하기 위해 SLO/SLI를 활용하며, 이 글에서는 구체적인 적용 방법과 그 효과를 공유합니다. SLO/SLI는 서비스의 가용성, 지연 시간 등 핵심 지표를 정의하고 측정하여 서비스 수준을 객관적으로 관리하는 데 도움을 줍니다. 이를 통해 잠재적인 문제를 사전에 감지하고 신속하게 대응함으로써 서비스의 전반적인 신뢰성을 향상시키는 것을 목표로 합니다. 실제 사례를 통해 SLO/SLI가 어떻게 서비스 운영에 기여하는지 이해할 수 있습니다.
SLOSLI신뢰성
라인·2026년 4월 22일
DevOps
LINE 서비스의 대규모 광고 데이터를 처리하기 위한 Spark on Kubernetes 적용기
LINE 광고 플랫폼은 하루 수십억 건 이상의 광고를 송출하고 천억 건에 준하는 데이터를 수집 및 가공합니다. 데이터 파이프라인 팀은 광고 효율 증대를 위해 실시간 데이터 처리, 가공, 저장, 전송 역할을 수행하며, 피처 증가로 인한 연산량 증가와 기존 Hadoop 기반 YARN 환경의 한계(자원 경합, 높은 운영 비용, 앱 의존성)를 겪고 있었습니다. 이러한 문제를 해결하기 위해 LINE은 인프라 독립성과 유연한 컨테이너 환경을 제공하는 Spark on Kubernetes를 도입했습니다. 이 글은 Spark on Kubernetes 도입 과정과 그 성과를 공유하며, 대규모 광고 데이터 처리를 위한 안정적이고 확장 가능한 데이터 파이프라인 구축의 중요성을 강조합니다.
SparkKubernetesData Pipeline
라인·2026년 3월 31일
DevOps
SRE 팀의 반복 작업을 10분의 1로 줄인 SRE 봇 개발기
LINE Home DevOps 팀은 늘어나는 서비스와 새로운 인프라 전환으로 인해 반복적이고 수동적인 작업에 많은 에너지를 소모하는 문제를 겪었습니다. 특히 배포 요청 처리에 평균 1시간이 소요되고, 사람의 실수로 인한 추가 공수 발생, 처리 과정의 불투명성 등의 비효율이 있었습니다. 이를 해결하기 위해 SRE 봇 프로젝트를 시작하여 Slack, Confluence, Jira를 연동하고 배포 요청 처리 과정을 자동화했습니다. 이 봇 개발을 통해 SRE 팀의 반복 작업을 10분의 1로 줄이고, 팀원들이 더 중요한 업무에 집중할 수 있도록 개선했습니다. 이 글은 SRE 봇 개발 과정을 통해 얻은 경험과 자동화의 중요성을 공유합니다.
SRE봇 개발자동화
라인·2026년 3월 24일
DevOps
신뢰성 향상을 위한 SLI/SLO 활용 1편 - SLI/SLO 프레임워크 및 서비스 상태 확인 도구 LINE Status 개발기
본 글은 LINE의 SRE 팀이 서비스 신뢰성 향상을 위해 SLI/SLO를 도입하고 운영하는 과정을 공유하는 시리즈의 첫 번째 편입니다. 이전 시리즈에서 SLI/SLO의 개념과 필요성, 플랫폼 및 서비스 적용 사례를 다루었다면, 이번 편에서는 SLI/SLO 프레임워크를 구축하고 서비스 상태 확인 도구인 'LINE Status'를 개발한 배경과 과정에 집중합니다. 반복적인 SLI/SLO 도입 및 운영 경험을 통해 서비스 특성에 무관한 공통 패턴을 발견하고, 이를 재사용 가능한 프레임워크로 정립하여 특정 서비스에 종속되지 않는 공통 기준과 흐름 안에서 SLI/SLO를 정의하고 운영할 수 있도록 했습니다. 이를 통해 사내에서 서비스 신뢰성을 논하는 공통 언어로 SLI/SLO를 확산시키고 자동화를 통해 확장해 나가는 과정을 설명합니다.
SRESLISLO
라인·2026년 3월 19일
DevOps
LY Corporation의 클라우드 인프라 개편: 거대한 두 개의 클라우드를 통합한 차세대 플랫폼 Flava의 아키텍처 소개
LY Corporation은 기존의 두 거대 프라이빗 클라우드(Verda, YNW)를 차세대 클라우드 플랫폼인 Flava로 통합하는 과정을 설명합니다. 이 글은 IaaS, 네트워크, 스토리지 등 인프라의 근간을 이루는 기술 스택에 초점을 맞춥니다. LY Corporation은 장애를 전제로 한 설계 철학을 바탕으로 무상태성 추구, 애플리케이션 주도의 가용성 확보, 신속한 복구를 핵심으로 삼아 인프라를 운영합니다. 특히 IaC(Infrastructure as Code)를 활용하여 환경을 즉시 재구축함으로써 서비스 지속성을 최우선으로 합니다. 이러한 접근 방식은 방대한 트래픽과 데이터를 효율적이고 무중단으로 운영하기 위한 LY Corporation의 전략을 보여줍니다.
클라우드 인프라프라이빗 클라우드IaaS
라인·2026년 3월 13일
DevOps
Claude Code Action: 조직 전반의 코드 품질을 지키는 AI 코드 리뷰 플랫폼화
LINE NEXT DevOps 팀은 AI 기반 코드 리뷰 도구인 Claude Code를 GitHub Actions에 통합하여 조직 전반의 코드 품질을 표준화하는 경험을 공유합니다. 서비스와 리포지터리 수가 빠르게 증가하는 환경에서 개별 팀이나 개인의 기준에 의존하는 대신, 조직 차원에서 일관된 개발 환경 및 품질 기준을 제공하는 것이 중요함을 강조합니다. AI 도구를 개별적으로 활용할 때 발생하는 리뷰 기준의 상이함과 같은 한계를 극복하고, Claude Code를 조직 표준 코드 리뷰 구성 요소로 재정의하여 일관된 개발 경험과 품질을 보장하는 과정에 초점을 맞춥니다. 이를 통해 성장하는 조직이 마주하는 코드 리뷰 품질 편차 문제를 해결하고 개발 생산성을 향상시키는 방안을 제시합니다.
Claude CodeAI 코드 리뷰GitHub Actions
라인·2026년 2월 13일
DevOps
미래의 클라우드를 창조하다
LY Corporation은 서비스 개발에 필요한 인프라와 플랫폼을 제공하기 위해 내부적으로 프라이빗 클라우드인 'Flava'를 구축하여 사용하고 있습니다. 이 글은 Flava가 어떻게 진화할지에 대한 두 가지 측면을 소개합니다. 첫 번째는 클라우드 본연의 측면으로, '플라바이제이션(Flavaization)', 사용 가능한 보안(usable security), 사용자 데이터 스토리지를 강화하는 것입니다. 특히 '플라바이제이션'은 현재 분산되어 운영되는 다양한 개발 플랫폼들을 하나의 통합된 클라우드 UX로 제공하여 개발자 경험을 향상시키는 것을 목표로 합니다. 이를 통해 개발자들은 각 플랫폼별 복잡한 권한 관리, 로깅, 모니터링 등을 익힐 필요 없이 일관된 방식으로 서비스를 개발할 수 있게 될 것으로 기대됩니다. 향후 1~2년 내 플라바이제이션 완수를 목표로 하고 있습니다.
프라이빗 클라우드Flava플랫폼
라인·2026년 2월 6일
DevOps
Scaling to Infinity: 한계를 넘어서는 LY Corporation의 관측 가능성 플랫폼 진화기
LY Corporation Observability Infrastructure 팀은 방대한 규모의 사내 프라이빗 클라우드 플랫폼과 수만 개의 애플리케이션 상태를 효과적으로 관리하기 위한 관찰가능성 플랫폼 구축 경험을 공유합니다. 관찰가능성은 시스템의 외부 출력으로 내부 상태를 추론하는 능력으로, 지표, 로그, 트레이스 세 가지 축의 데이터를 활용합니다. 본문에서는 특히 지표를 효율적으로 저장하고 처리하기 위한 기술 여정을 되짚어보고, 데이터 통합과 AI를 활용한 지능형 플랫폼으로의 진화 전략을 제시합니다. 이를 통해 개발자는 비즈니스 로직에 집중하고 운영자는 데이터 기반의 안정적인 시스템 관리가 가능해집니다.
관찰가능성observabilityKubernetes
라인·2026년 2월 4일
DevOps
Athenz 엔지니어는 왜 Kubestronaut에 도전했는가?
이 글은 LY Corporation의 보안 플랫폼 엔지니어인 김정우님이 Athenz 프로젝트 담당자로서 쿠버네티스 전문가 칭호인 Kubestronaut를 취득한 경험을 공유하는 내용입니다. Athenz는 CNCF 샌드박스 프로젝트로, 복잡한 쿠버네티스 환경에서 서비스 간 접근 제어를 담당하는 중요한 오픈소스 시스템입니다. 저자는 Athenz 운영 경험을 바탕으로 CKA, CKAD, CKS 등 총 5가지 CNCF 자격증을 취득하여 Kubestronaut가 되기까지의 여정을 상세히 설명합니다. 이 과정은 단순히 자격증 취득을 넘어 쿠버네티스에 대한 깊이 있는 이해와 숙련도를 증명하는 과정이며, 클라우드 네이티브 환경에서의 보안 및 운영 역량 강화에 대한 중요성을 강조합니다.
AthenzKubernetesKubestronaut
라인·2025년 12월 10일
DevOps
앱 성공을 위한 필수 요소: 장애 모니터링
모바일 앱 운영 성공을 위한 핵심 요소로 장애 모니터링의 중요성을 강조합니다. 회원 가입이나 결제 오류 발생 시 즉각적인 파악 및 대응이 사용자 이탈 방지에 필수적이며, 사전 테스트만으로는 운영 환경의 예기치 못한 장애를 완전히 막을 수 없음을 설명합니다. 장애 모니터링 방법으로 이벤트 수집/분석, 성능 모니터링, 사용자 피드백 수집, 실시간 알림, 지표/대시보드 구성을 제시합니다. 특히 Sentry, Firebase, New Relic과 같은 도구를 활용한 이벤트 수집 및 분석을 통해 사용자 영향도를 파악하고, 대시보드 구성 및 알림 설정을 통해 긴급 이슈에 신속하게 대응하는 방법을 다룹니다. 비정상 종료 사용자 비율, API 오류율, 주요 이벤트 실패율 등을 추적하여 앱 안정성을 확보하는 방안을 공유합니다.
장애 모니터링모바일 앱Sentry
라인·2025년 10월 17일
DevOps
Nginx 설정 통합과 Loki 연동으로 설계한 유연한 멀티사이트 아키텍처
LINE NEXT DevOps 팀은 다수의 서비스 론칭에 필요한 웹 서버(Nginx) 인프라 구성 시 발생하는 긴 리드 타임과 수동 설정의 비효율성을 해결하기 위해 아키텍처 개선을 진행했습니다. 기존에는 신규 서버 발급 및 Nginx 설정, 로드밸런서 세팅까지 최소 2주가 소요되었으나, 이를 3단계에 걸쳐 점진적으로 중앙 집중화된 통합 구조로 전환했습니다. 주요 개선 사항으로는 Nginx 설정 통합, 멀티사이트 구조 도입, Loki 연동을 통한 안정적이고 확장 가능한 로그 수집 체계 구축이 있습니다. 또한 사용자 IP 정보 수집, GeoIP 모듈 탑재, 유지보수 프로세스 구성, SSL 인증서 공통 관리 및 자동화 기능도 함께 구현하여 서비스 확장성과 운영 효율성을 높였습니다.
NginxLokiKubernetes
라인·2025년 8월 7일
DevOps
당신의 CPU는 열심히 일하고 있나요?
LINE+ Contents Service Engineering 조직에서는 쿠버네티스 스터디 그룹을 통해 CPU 리소스 관리 방안을 논의했습니다. 이 글은 쿠버네티스에서 CPU 요청량(`cpu.requests`)과 CPU 상한(`cpu.limits`) 설정을 소개하고, 특히 CPU 상한 설정의 제거 여부에 대한 팀별 테스트 및 토론 결과를 공유합니다. 백엔드 서버 팀은 CPU 상한 설정을 제거하는 것으로, 프런트엔드 서버 팀은 유지하는 것으로 결정했습니다. 이러한 상반된 결정의 배경과 각 팀의 테스트 결과를 통해 애플리케이션 성능 개선을 위한 CPU 리소스 활용 방안에 대한 인사이트를 얻을 수 있습니다.
KubernetesCPUResource Management
라인·2025년 4월 11일
DevOps
신뢰성 향상을 위한 SLI/SLO 도입 2편 - 플랫폼 적용 사례
본 글은 LINE의 미디어 플랫폼인 OBS에 SLI/SLO를 도입하여 신뢰성을 향상시킨 사례를 공유합니다. SRE 엔지니어링 팀은 LINE 서비스의 안정적인 제공을 위해 OBS 플랫폼의 신뢰성 확보가 중요하다고 판단했습니다. 기존 서비스 중심의 SLI/SLO 정의 방식과 달리, OBS는 약 160개 서비스에서 사용하는 핵심 플랫폼이므로 별도의 SLI/SLO 정의가 필요했습니다. 글에서는 플랫폼의 핵심 사용자 여정(CUJ)을 정의하는 과정에서의 어려움과 이를 극복하기 위한 접근 방식을 설명하며, SLI/SLO 도입을 통해 어떻게 플랫폼의 신뢰성을 측정하고 개선해 나갈 수 있는지에 대한 인사이트를 제공합니다.
SLISLOSRE
라인·2025년 2월 28일
DevOps
신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성
이 글은 LINE 앱의 서비스 신뢰성 향상을 위한 SLI/SLO 도입을 주제로 한 연재의 첫 번째 글로, SLI(Service Level Indicator)와 SLO(Service Level Objective)의 개념과 필요성을 소개합니다. SRE(Site Reliability Engineering) 팀은 고객에게 안정적이고 신뢰할 수 있는 서비스를 제공하기 위해 성능 개선, 자동화, 시스템 모니터링, 장애 대응 등의 엔지니어링 업무를 수행합니다. 서비스 신뢰성은 사용자가 느끼는 경험을 정량적인 데이터로 표현해야 하며, 이를 위해 SLI와 SLO 개념이 중요하게 작용합니다. SLI는 서비스 수준을 나타내는 지표이며, SLO는 해당 지표가 달성해야 하는 목표 수준을 의미합니다. 이 글은 이러한 개념들을 바탕으로 LINE 앱이 사용자에게 더 나은 서비스를 제공하기 위해 SLI/SLO를 도입하게 된 배경을 설명합니다.
SRESLISLO
라인·2025년 2월 21일
DevOps
CI 빌드 오류의 원인 분석에서 해결까지의 여정
LINE Plus의 MPR 팀은 LINE 클라이언트 앱의 빌드 개선 및 CI 파이프라인 관리를 담당하며, CI/CD 운영 중 발생한 흔하지 않은 이슈와 해결 과정을 공유합니다. 이 글은 약 10일간 소요된 문제 해결 과정을 상세히 기록하여, 유사 문제 발생 시 원인 분석 및 해결에 참고할 수 있도록 돕는 것을 목표로 합니다. 글에서는 Git을 소스 리포지터리로 사용하고, Jenkins와 Gradle을 활용한 CI 환경을 소개합니다. 또한, 빌드 정보 수집 및 분석을 위해 Develocity를 사용하며, 로그 집계를 위해 Logstash, Elasticsearch, Kibana, Grafana를 활용하는 시스템 구성을 설명합니다. 특히 Gradle과 Develocity의 기능 및 특징을 소개하며, 이들이 빌드 성능 최적화와 문제 진단에 어떻게 기여하는지 설명합니다.
CI/CDJenkinsGradle
라인·2025년 1월 6일
DevOps
Playwright와 Jira로 만드는 스마트 장애/변경 알림 및 관리 시스템
LINE NEXT DevOps 팀은 기존 TTS 시스템의 한계를 극복하고 장애/변경 알림 및 관리 시스템의 효율성을 높이기 위해 Playwright와 Jira를 활용한 새로운 시스템을 구축했습니다. 이 시스템은 Playwright를 이용한 E2E 모니터링, Jira를 통한 티켓 관리, 그리고 봇을 통한 Slack 알림 및 Jira 제어 기능을 통합합니다. 기존 시스템은 타사 의존적이고 제어권이 부족했으며, 특히 낮은 등급의 장애 처리 시간이 길다는 문제점이 있었습니다. 새로운 시스템 도입을 통해 장애 발생 시 신속한 알림과 효율적인 대응 프로세스를 구축하여 장애 지속 시간을 줄이고 전반적인 시스템 안정성을 향상시키는 것을 목표로 합니다. 이는 모니터링, 알림, 장애/변경 티켓 관리까지 이어지는 자동화된 워크플로우를 제공합니다.
PlaywrightJira알림 시스템
라인·2024년 10월 28일
DevOps
쿠버네티스 커스텀 리소스 정의하고 관리하기(feat.컨트롤러)
이 글은 쿠버네티스 컨트롤러를 활용하여 커스텀 리소스를 정의하고 관리하는 방법을 설명합니다. 컨트롤러는 쿠버네티스 리소스의 변경을 감지하고 '원하는 상태'로 조정하는 역할을 수행합니다. 디플로이먼트 예시를 통해 컨트롤러가 어떻게 파드의 개수를 관리하는지 직관적으로 보여주며, 실제 팀에서 컨트롤러를 활용하는 사례를 소개합니다. 이를 통해 쿠버네티스 리소스 관리의 효율성을 높이고 복잡한 시스템을 효과적으로 제어하는 방법을 공유합니다.
쿠버네티스컨트롤러커스텀 리소스
라인·2024년 8월 28일
DevOps
쿠버네티스에서 파드를 분산 처리하기 위한 토폴로지 분배 제약 조건 활용 사례 소개
이 글은 쿠버네티스에서 파드를 효과적으로 분산 처리하기 위한 '토폴로지 분배 제약 조건(topology spread constraints)' 활용 사례를 소개합니다. 파드 분산 처리는 서비스의 가용성, 고가용성, 지속성을 보장하고 단일 장애 지점을 최소화하는 데 필수적입니다. 쿠버네티스 스케줄러의 기본 분산 기능만으로는 복잡하고 대규모 서비스에서 부족할 수 있으며, 운영 중 설정 변경은 리스크를 동반하므로 초기부터 정교한 분산 처리를 고려해야 합니다. 글에서는 파드 분산 처리의 필요성을 설명하고, 토폴로지 분배 제약 조건의 장점과 구체적인 활용 방법을 다룹니다. 쿠버네티스 초심자도 쉽게 이해할 수 있도록 구성되어 있습니다.
쿠버네티스파드토폴로지 분배 제약 조건
라인·2024년 8월 16일
DevOps
Informer를 사용해 쿠버네티스 중계 API 서버의 성능 개선하기
본 글은 대규모 쿠버네티스 클러스터 환경에서 RBAC로 인한 사용자 권한 제약 문제를 해결하고 API 서버 성능을 개선한 경험을 공유합니다. 사내 데이터 플랫폼에서는 멀티 테넌트 환경으로 인해 사용자가 클러스터 레벨의 리소스 정보에 접근하는 데 제한이 있었습니다. 특히, 특정 파드 스케줄링 가능 여부를 확인하기 위해 노드 리소스 현황 파악이 필요했으나, 사용자에게 모든 파드 조회 권한을 부여하는 것은 보안상 문제가 있었습니다. 이를 해결하기 위해 Informer 라이브러리를 활용하여 쿠버네티스 API 서버를 중계하는 API 서버를 구축했습니다. Informer는 쿠버네티스 API 서버의 변경 사항을 효율적으로 감지하고 반영하여, 필요한 리소스 정보를 실시간으로 가져올 수 있게 합니다. 이를 통해 사용자에게 필요한 노드 리소스 정보를 안전하고 효율적으로 제공함으로써 API 서버의 성능을 크게 개선하고 사용자 경험을 향상시켰습니다.
KubernetesInformerAPI 서버
라인·2024년 7월 29일
DevOps
쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 - 3편
이 글은 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 시리즈의 마지막 편으로, LitmusChaos를 활용한 카오스 테스트 시스템 구축 사례를 소개합니다. 대상 애플리케이션은 Apache Flink 기반의 전처리기로, LINE 광고 데이터 파이프라인의 차세대 전처리기로 준비 중입니다. LitmusChaos를 통해 Flink 애플리케이션의 안정성과 복원력을 검증하기 위한 카오스 테스트를 진행했으며, 이는 시스템의 신뢰성을 높이고 잠재적인 장애에 대비하는 데 중요한 역할을 합니다. 이 시리즈는 Tekton 기반 성능 테스트 시스템 구축에 이어 카오스 엔지니어링까지 다루며, 쿠버네티스 환경에서의 스트리밍 파이프라인 검증 자동화 전반을 다룹니다.
KubernetesLitmusChaosChaos Engineering
라인·2024년 4월 19일