English
日本語
繁體中文
ไทย
Tiếng ViệtLINE Timeline에 필요한 머신 러닝과 추천 모델을 만들고 있는 Data Science Dev의 조영인입니다. 1편과 2편에 이어 이번 3편에서는 Discover에 진입한 사용자에게 보여줄 콘텐츠를 어떻게 선정하고, 어떤 순서로 배치하는지에 대해 설명하겠습니다.
LINE Timeline의 새로운 도전 3편 – Discover 추천 모델
Category Archives: Back-End
LINE Timeline의 새로운 도전 2편 – Discover 딜리버리 시스템 소개
Yongseop Kim, Cheolseok Bang
지난 1편, LINE Timeline의 새로운 도전 1편 – 추천 콘텐츠 탐색을 위한 Discover와 새로운 구독 모델 Follow에 이어서 이번에는 Discover 딜리버리 시스템을 좀 더 자세하게 소개하려고 합니다. Discover 딜리버리 시스템은 크게 Discover Feed와 Discover 에이전트, Discover ML(Machine Learning) 서버로 구성됩니다. 이번 글에서는 Discover Feed와 Discover 에이전트를 중점적으로 살펴보고, 다음 글에서 Discover ML 서버를 다루겠습니다.
오픈챗(OpenChat)은 LINE 친구를 맺지 않고도 관심사가 비슷한 익명의 사용자들과 함께 대화를 나눌 수 있는 오픈 채팅방 서비스입니다. 각 채팅방에서 서로 다른 프로필을 사용할 수 있고, 내가 가입하기 전의 오픈챗 대화 내용도 볼 수 있는 것이 특징입니다. LINE 친구가 아닌 사용자들과 익명으로 대화할 수 있다는 점이 오픈챗의 특징인데요. 이런 특징은 장점인 동시에 단점이 될 수 있습니다. 욕설이나 광고, 성인 이미지 등의 부적절한 콘텐츠에 노출될 수 있고, 오프라인 만남 등을 목적으로 하는 오픈챗이 많이 생겨날 수도 있기 때문입니다. 특히 사용자들이 오픈 초기, 서비스의 성격이 완전히 자리 잡기 전에 이런 단점들에 많이 노출되는 것은 좋지 않습니다. 서비스에 대해 잘못된 인식을 심어줄 수 있는 것은 물론, LINE 메신저 서비스 전체에 대해 나쁜 인상을 줄 수도 있기 때문입니다.
오픈챗 클린 스코어는 이런 배경에서, 서비스 메인 페이지에 노출해도 될 만한, 최대한 깨끗한 소수의 ‘화이트’ 오픈챗을 찾아낼 목적으로 개발되었습니다.오픈챗 클린 스코어는 이런 배경에서, 서비스 메인 페이지에 노출해도 될 만한, 최대한 깨끗한 소수의 ‘화이트’ 오픈챗을 찾아낼 목적으로 개발되었습니다.
안녕하세요. 이번 글에서는 CrashLoopBackoff 상태에 있는 Prometheus 컨테이너 이슈의 원인을 조사하고 해결하는 과정에서 겪은 흥미로운 경험을 공유하려고 합니다. 사실 이런 현상이 발생하는 원인과 해결책은 너무 뻔하고 간단해서 굳이 이런 주제를 다루는 데 시간을 투자할 가치가 있나는 질문을 던질 수도 있습니다. 하지만 저와 마찬가지로, 이 문제를 조사하는 과정의 각 단계를 자세히 이해하고자 하는 독자가 있을 거라고 생각하며 시작하겠습니다. 이 글을 읽으면서 얻을 수 있는 것들을 아래와 같이 정리해 봤습니다.
LINE 통화: 최고의 품질을 위한 8년간의 여정
Dongwon Lee
요즘엔 대부분의 사람들이 기존의 유료 통화 대신에 메신저에서 대화하다가 클릭 한 번으로 통화할 수 있는 인터넷 전화를 사용합니다. 인터넷 전화는 통화 품질도 좋고, 무엇보다 전 세계 누구와 통화해도 무료라는 점이 매력적이죠. 이런 장점 덕분에 인터넷 전화 서비스는 본격적으로 시작된 지 채 10년도 지나지 않아 기존의 유료 통화를 빠른 속도로 대체해 나갔습니다. 하지만 인터넷 전화는 그 특성상 통화 중에 음성이 끊기거나 통화 자체가 안되는 경우가 가끔씩 발생합니다. 유료 서비스라면 해당 통신사에 불만을 접수해서 통화 품질을 개선하도록 만들 수 있겠지만, 인터넷 전화는 무료 서비스이기 때문에 통화 음질이 좋지 않다면 사용자들은 통화 품질을 개선하기보다는 다른 서비스로 발길을 돌리는 쪽을 선택하게 됩니다. 따라서 사용자가 무료 통화 서비스를 계속 사용하길 원한다면 좋은 통화 품질을 유지하는 것이 매우 중요합니다. 이번 글에서는 LINE 무료 통화 서비스가 최고의 품질을 유지하기 위해 얼마나 많은 노력을 기울이고 있는지 공유하겠습니다.
Kafka를 이용한 작업 큐 라이브러리 ‘Decaton’ 활용 사례
Kazuki Matsushita
얼마 전, LINE에서 개발한 라이브러리 Decaton이 오픈소스로 공개됐습니다. Decaton은 Kafka를 이용한 비동기 처리 작업 큐(queue) 라이브러리로 LINE에서 널리 사용하고 있습니다.
사실 Kafka에서 스트림을 다루는 공식 라이브러리로 Kafka Streams를 이미 제공하고 있습니다. 하지만, Kafka Streams가 당시 저희 요구 사항에 맞지 않아 별도로 Kafka를 이용한 라이브러리인 Decaton을 개발하게 되었습니다. Decaton은 Kafka Streams보다 효율적으로 메시지를 처리하면서 프로그램 자체도 간단하게 구성할 수 있습니다. 이번 글에서는 LINE에서 Decaton을 어떻게 활용하고 있는지 사례를 통해 공유하려고 합니다.
고 처리량 분산 비율 제한기
Viacheslav Kapilevich
보통 프로덕션 등급의 시스템은 서로 의존하는 여러 개의 컴포넌트로 구성됩니다. 최근 몇 년간 마이크로 서비스 아키텍처가 대중화되면서 컴포넌트의 수가 증가했고, 그에 따라 각 컴포넌트 사이의 연결 수도 증가했는데요. 이때 각 컴포넌트에 과부하가 걸리지 않도록 보호하면서 전체 시스템의 서비스 품질을 보장하기 위해 ‘비율 제한기(rate limiter)’를 사용할 수 있습니다.
이미 많은 글과 튜토리얼에서 단일 호스트에서 실행되는 서비스를 위한 서버 측 비율 제한기(rate limiter)를 다루고 있기 때문에 이번 글에선 고 처리량(high-throughput) 분산 시스템을 위한 클라이언트 측 비율 제한기에 대해 이야기하려고 합니다. 저는 2020 LINE New Year 캠페인 시스템을 개발하면서 클라이언트 측 비율 제한기에 대해 생각해 보게 되었습니다. 이 캠페인은 LINE 서비스 입장에서 연중 가장 많은 트래픽이 유입되는 1월 1일 자정에 시작했는데요. 당시 저희가 직면한 과제 중 하나가 사용자 경험을 저하시키지 않으면서 내부 서비스에 과부하가 걸리는 것을 막는 일이었습니다.
안녕하세요. LINE 미디어 플랫폼 개발과 운영 업무를 담당하고 있는 하태호입니다. 지난 글(4편)에선 앞서 블로그(서버 사이드 테스트 자동화 여정 1편, 2편, 3편)를 통해 소개했던 자동화 시스템에 이어서 성능 테스트를 자동화하게 된 계기와 목표, 구성한 환경에 대해 소개했는데요. 이번 글에선 자동화된 성능 테스트의 리포트를 생성한 방법과 자동화된 성능 테스트를 실제로 적용하면서 겪었던 일을 공유하겠습니다.
안녕하세요. LINE 미디어 플랫폼 개발과 운영 업무를 담당하고 있는 하태호입니다. LINE 내 수많은 서비스가 사용하는 미디어 플랫폼은 앞서 블로그(서버 사이드 테스트 자동화 여정 1편, 2편, 3편)를 통해 소개했던 자동화 시스템을 이용해 지속적으로 테스트하고 있습니다. 개발자들은 자동화 시스템에 계속 추가되는 테스트 케이스 덕분에 단순한 API 호출과 관련된 문제만 확인하는 것이 아니라, 실제 서비스에서 API를 호출하는 흐름 중에 발생하는 문제도 코드 리뷰 시작 전부터 확인하는 등 많은 도움을 받고 있는데요. 이번 글에서는 더 나아가 성능 테스트를 자동화하며 겪은 일들을 공유하고자 합니다.
Armeria의 서킷 브레이커 사용해 보기
Seunghwan Joo
안녕하세요. LINE에서 OpenChat 서비스의 백엔드를 개발하고 있는 주승환입니다. 이번 글에서는 간단한 코드 예제와 함께 Armeria의 서킷 브레이커 기능을 사용해 보며 정리한 내용을 공유하고자 합니다.