Tag Archives: Server-dev

서버 사이드 테스트 자동화 여정 – 5. 성능 테스트 리포트 생성 및 자동화 시스템 업무 적용 결과

안녕하세요. LINE 미디어 플랫폼 개발과 운영 업무를 담당하고 있는 하태호입니다. 지난 글(4편)에선 앞서 블로그(서버 사이드 테스트 자동화 여정 1편, 2편, 3편)를 통해 소개했던 자동화 시스템에 이어서 성능 테스트를 자동화하게 된 계기와 목표, 구성한 환경에 대해 소개했는데요. 이번 글에선 자동화된 성능 테스트의 리포트를 생성한 방법과 자동화된 성능 테스트를 실제로 적용하면서 겪었던 일을 공유하겠습니다.

서버 사이드 테스트 자동화 여정 – 4. 성능 테스트 자동화 목표 설정 및 테스트 환경 구성

안녕하세요. LINE 미디어 플랫폼 개발과 운영 업무를 담당하고 있는 하태호입니다. LINE 내 수많은 서비스가 사용하는 미디어 플랫폼은 앞서 블로그(서버 사이드 테스트 자동화 여정 1편, 2편, 3편)를 통해 소개했던 자동화 시스템을 이용해 지속적으로 테스트하고 있습니다. 개발자들은 자동화 시스템에 계속 추가되는 테스트 케이스 덕분에 단순한 API 호출과 관련된 문제만 확인하는 것이 아니라, 실제 서비스에서 API를 호출하는 흐름 중에 발생하는 문제도 코드 리뷰 시작 전부터 확인하는 등 많은 도움을 받고 있는데요. 이번 글에서는 더 나아가 성능 테스트를 자동화하며 겪은 일들을 공유하고자 합니다.

Armeria의 서킷 브레이커 사용해 보기

안녕하세요. LINE에서 OpenChat 서비스의 백엔드를 개발하고 있는 주승환입니다. 이번 글에서는 간단한 코드 예제와 함께 Armeria의 서킷 브레이커 기능을 사용해 보며 정리한 내용을 공유하고자 합니다.

LINE 트랜스코딩 서버 아키텍처 개선기 – 2

안녕하세요. LINE에서 트랜스코딩(Transcoding) 서버 개발과 운영 업무를 담당하고 있는 백승훈입니다. 1편에서 LINE의 트랜스코딩 서버인 ‘리코더(Licoder, LIne TransCODER)’를 소개하고 그 기능과 인터페이스에 대해 말씀드렸는데요. 이번 글에서는 리코더의 초기 아키텍처를 설명하고 이 아키텍처가 LINE의 급격한 성장에 따라 어떻게 변화했는지 공유하겠습니다.

LINE 트랜스코딩 서버 아키텍처 개선기 – 1

안녕하세요. LINE에서 트랜스코딩(transcoding) 서버 개발과 운영 업무를 담당하고 있는 백승훈입니다. 우리는 생활 속에서 다양한 방식으로 동영상을 생산하고 소비하고 있습니다. 자신의 스마트폰으로 직접 동영상을 촬영하기도 하고, 누군가가 메신저로 공유해 준 동영상을 감상하기도 하고, 인터넷에 공개된 동영상을 다운로드하기도 합니다. 그런데 이렇게 다양한 곳에서 다양한 방식으로 얻은 동영상이 간혹 재생되지 않는 경우가 있습니다. 재생할 수 없는 이유에는 여러 가지가 있을 수 있지만, 대부분 스마트폰의 코덱이나 성능의 제약이 문제가 됩니다. LINE에서는 이런 문제를 어떻게 해결하고 있을까요?
이번 글에서는 전 세계의 LINE 사용자가 발생시킨 동영상 트래픽을 처리하고 있는 LINE 트랜스코딩 서버의 아키텍처에 대해 이야기하겠습니다.

LINE Timeline의 새로운 도전 1편 – 추천 컨텐츠 탐색을 위한 Discover와 새로운 구독 모델 Follow

LINE 타임라인 서비스에 ‘Discover’와 새로운 구독 모델인 ‘Follow’ 기능이 추가되었습니다. 사용자에게는 많이 낯설지 않은 기능일 것이나, 그 속에서 우리가 고민하고 노력했던 부분들이 무엇인지 공유하고 싶어 이 글을 작성하게 되었습니다. 이번 소개 글을 시작으로 조금 더 자세한 내용까지 전해 드리고자 총 3부작으로 기획했습니다.

  • LINE Timeline의 새로운 도전 1편 – 추천 컨텐츠 탐색을 위한 Discover와 새로운 구독 모델 Follow
  • LINE Timeline의 새로운 도전 2편 – Discover Delivery System 소개
  • LINE Timeline의 새로운 도전 3편 – Discover 추천 모델 자세히 살펴보기

Kubernetes로 클러스터 외부 자원 관리하기

안녕하세요. 저는 LINE에서 LINE 개발자를 위한 서비스, Pipeline을 개발하고 있습니다. Pipeline은 테스트부터 서비스 배포까지 가능한, Kubernetes 기반 워크플로(workflow) 서비스입니다. 사용자가 코드를 검증하기 위한 테스트나 코드를 배포하기 위한 빌드 또는 주기적으로 작업을 실행하기 위한 크론(cron) 작업과 같이 실행하고 싶은 작업을 워크플로 형태로 Pipeline에 정의하면, Pipeline이 사용자가 정의한 대로 작업을 실행합니다. 작업의 결과는 다양한 형태로 나타나는데요. 파일이 산출되기도 하고 서비스가 실행되기도 합니다.

이번 글에서는 외부에서 발생한 트래픽을 Kubernetes 클러스터에서 실행되는 서비스로 전달하기 위해 필요한 Pipeline 컴포넌트를 직접 개발한 경험을 나누고자 합니다.

LINE 메시징 서버가 새해 트래픽을 대비하는 과정

LINE의 트래픽은 메신저 특유의 독특한 패턴을 갖고 있습니다. 새해 0시가 되는 순간, 사용자들이 메신저로 새해 인사를 주고받으면서 평소 대비 메시지 발송 건수가 대폭 증가하는데요. 이때 서비스 국가별 시차와 문화에 따라서 다양한 트래픽 증가 패턴이 나타납니다. LINE에선 이런 순간적인 트래픽 증가를 문제없이 처리하기 위해 매년 다양한 준비를 하고 있는데요. 이를 ‘신년 대응’이라고 부르고 있습니다. 이번 글에서는 2020년 신년 대응에서 저희가 노력했던 일들과 그 결과에 대해서 소개하려고 합니다.

Armeria로 Reactive Streams와 놀자! – 2

안녕하세요. LINE+에서 오픈소스 Armeria와 Central Dogma를 개발하고 있는 엄익훈입니다. 지난 포스팅에선 Reactive Streams의 개념을 살펴보았는데요. 이번 포스팅에선 Reactive Streams를 오픈 소스 비동기 HTTP/2, RPC, REST 클라이언트/서버 라이브러리인 Armeria에서 사용하는 방법에 대해 공유하려고 합니다.

Armeria로 Reactive Streams와 놀자! – 1

LINE+에서 오픈소스 Armeria와 Central Dogma를 개발하고 있는 엄익훈입니다. 저는 Reactive Streams의 개념과, Reactive Streams를 오픈 소스 비동기 HTTP/2, RPC, REST 클라이언트/서버 라이브러리인 Armeria에서 사용하는 방법에 대해 공유하려고 하는데요. 이번 포스팅에선 먼저 Reactive Streams의 개념을 알아보겠습니다.