Blog - LINE ENGINEERING

TAG ARCHIVES: Server-side

독립적이고 범용적인 올인원 메시징 플랫폼
송재욱2023-08-04
도메인을 이해하고, 문제를 정의한 후, 해법을 개발하는 일을 즐깁니다.
Tech-Verse 2022에서 송재욱 님이 발표한 독립적이고 범용적인 올인원(all-in-one) 메시징 플랫폼 세션 내용을 옮긴 글입니다. 안녕하세요. ABC Studio에서 MessagingHub를 만들고 있는 송재욱입니다. 이번 글에서는 어떤 과정을 거쳐서 독립적이고 범용적인 올인원(all-in-one) 메시징 플랫폼을 만들어 갔는지 소개하겠습니다. 먼저 MessagingHub가 무엇인지 소개하고, 'Messaging as a Service'에 대해 플랫폼 관점에서 말씀드린 뒤 MessagingHub의 주요 아키텍처와 흐름을 살펴보겠습니다. MessagingHub 소개 MessagingHub란 무엇이고, 왜 만들었고, 어디에 사용하는 것일까요? 이 글의 제목인 '독립적이고 범용적인 올인원 메시징 플랫폼'은 바로 MessagingHub를 가리키는 말입니다. MessagingHub는 이름에서 알 수 있듯 메시징에 초점을 둔 플랫폼으로, 독립적이고 범용적이라는
- Server-side
더 쉽고 안전한 LINE 계정 이전
마상욱2023-05-08
2016년부터 LINE 서버 개발에 참여해 현재 LINE 서비스 계정과 인증 도메인을 담당하는 서버 개발 팀을 이끌고 있습니다.
Tech-Verse 2022에서 마상욱 님이 발표한 Easier and Safer LINE Account Transfer 세션 내용을 옮긴 글입니다. 안녕하세요. LINE에서 계정과 인증 영역 서버 개발 팀을 이끌고 있는 마상욱입니다. 서버 개발자를 포함해 모든 LINE 개발자는 사용자에게 안전하고 편리한 기능을 제공하기 위해 노력하고 있으며, 그 과정에서 안정성과 사용자 경험 사이에서 균형을 맞춰야 하는 상황을 종종 마주합니다. 두 가지 모두 사용자를 위한 것이기 때문에 어느 쪽도 놓치지 않는 방법을 찾기 위해 모두가 노력하고 있는데요. 이번 글에서는 그와 같은 과정을 거쳐 계정 이전 기능을 개선한 사례를 소개하겠습니다. 먼저 계정 이전 기능과 Letter Sealing이 무엇인지 설명하고, 계정 이전 기능에 어떤 문제가 있었는지 짚어본 뒤 문제를 해결하기 위해 적용한 두 가지 개선 방법을 설명하겠습니다. 첫 번째는 생체 인증을 사용한 더 쉬운 계정 이전 기능이고 두 번째는
- Server-side
LINE 오픈챗 서버가 100배 급증하는 트래픽을 다루는 방법
김인제2023-04-21
LINE 오픈챗 서버를 개발하고 있습니다. 대규모 트래픽을 안정적으로 다루는 방법과 분산 시스템, 팀 프로세스, 문서화와 시각화, 자동화에 관심이 많습니다.
Tech-Verse 2022에서 김인제 님이 발표한 LINE 오픈챗 서버가 100배 급증하는 트래픽을 다루는 방법 세션 내용을 옮긴 글입니다. 안녕하세요. Square Dev 팀 김인제입니다. 이번 글에서는 LINE 오픈챗(OpenChat) 서버에서 100배 급증하는 트래픽을 다루는 방법을 소개하겠습니다. 아래는 이번 글에서 공유하고자 하는 핵심 내용을 슬라이드 한 장으로 요약한 것입니다. SNS 팔로워 수가 수백만 명인 유명한 가수의 콘서트를 팬들이 함께 보며 실시간으로 오픈챗에서 활발하게 메시지를 주고받았던 사례입니다. 수천 명의 사용자가 한 오픈챗 안에서 많은 메시지를 동시에 주고받다 보면 일반 오픈챗 대비 100배 이상 트래픽이 급증할 수 있습니다. 오픈챗 서버 팀에서는 이와 같은 챗을 '핫 챗'이라고 부르는데요. 이번 글에서는 오픈챗 서버 팀이 경험한 두 가지 핫 챗 패턴과 핫 챗 때문에 발생한 문제, 그 문제를 어떤 방식으로 해결했는지 공유하겠습니다. 글은 LINE
- Server-side
감자탕 먹고 Vue.js로 Figma 번역 플러그인 만든 이야기
김민섭2023-04-07
ABC Studio에서 백엔드 개발을 하고 있습니다.
안녕하세요. LINE+ ABC Studio에서 백엔드 개발을 하는 김민섭입니다. 이번 글에서는 최근 파파고를 이용해 Figma 번역 플러그인을 제작했던 경험을 공유하고자 합니다. 플러그인을 어떻게 제작하는지 상세히 안내하거나 코드 수준으로 다루려는 것은 아니고요. 플러그인을 만들면서 어려웠던 점과 해결한 방법, 그리고 팀에서의 제작 과정을 주로 다룰 예정입니다. Figma 플러그인을 개발할 때는 Figma Developers 사이트를 참고하면 좋습니다. HTML과 Node.js, Typescript 관련 지식이 필요하며, 복잡한 플러그인을 만들고 싶다면 Vue.js나 React와 같은 프런트엔드 프레임워크를 사용하면 좋습니다. Figma 번역 플러그인이 필요하다고? 저는 백엔드를 개발하고 있어서 Figma를 많이 사용하지는 않습니다. 주로 보는 용도로만 사용하는데요. 어느 날 팀 Slack 채널에 디자인을 담당하는 Jeans 님의 메시지가 올라왔습니다. 플러그인 제
- Server-side
- Front-End
메시징 서버 개발 프로세스 개선
Takatoshi Nao2023-02-13
LINE 메시징 서버를 개발하고 있습니다.
다들 건강하시죠? LINE 메시징 서버를 개발하고 있는 Nao입니다. 지난 2014년에 LINE 서버 개발과 릴리스 프로세스(일본어)를 소개했습니다. 이후 시간이 흐르면서 개발 환경과 코드가 변화했고, 이번 글에서는 그 후 개선한 점을 소개하고자 합니다. 기존 개발 프로세스 소개 LINE 메시징 플랫폼은 여러 서버 애플리케이션으로 구성돼 있습니다. 메시징 서버는 그중에서 메시징 기능을 담당하는 플랫폼으로, 다른 팀 개발자들과 협력해서 개발하고 운영하며 여러 프로젝트가 병행으로 진행됩니다. 따라서 여러 프로젝트에서 동시에 작업을 진행하면서 혼란스러울 때가 있고, 각 작업에서 어떤 내용이 진행되고 있는지 제대로 파악하기 어려울 때도 있습니다. 이런 문제를 개선하면서 공동으로 개발하기 위해 들이는 수고를 최소화하기 위해 시행착오를 거쳐가며 개발자끼리 여러 가지 룰이나 정책을 정립해 왔으며, 그 결과가 LINE 메시징 서버의 기존 개발 프로세스입니다. 기존 개발 프로세스에서는 기능 개발은
- Server-side
쿠버네티스 환경에서 Confluent Platform을 사용해 한 단계 진보한 데이터 파이프라인 구축하기
박찬우2023-01-20
2014년부터 LINE에서 글로벌 이벤트, 오픈챗 포스트, 코인 거래소, 블록체인 플랫폼, 커머스 서버 개발자로 일했고, 현재는 LINE VOOM 서버 개발자로 일하고 있습니다.
시작하기 전에 안녕하세요. LINE VOOM 서버 개발자 박찬우입니다. 최근 쿠버네티스 환경에서 Confluent Platform을 사용해 한 단계 진보한 데이터 파이프라인을 구축하는 프로젝트를 진행했습니다. 그 과정에서 쿠버네티스와 Confluent Platform, 그리고 데이터 파이프라인에 대해 모든 면에서 배운 점이 많았습니다. 가능하다면 이 경험을 최대한 자세히 공유드리고 싶지만, 지면의 한계와 더불어 글이 장황하게 늘어지지 않고 꼭 전달해야 할 부분을 독자 여러분께서 제대로 전달할 수 있도록 이번 글에서는 아래 두 가지 주제에 집중하려고 합니다. Confluent Platform을 쿠버네티스 환경에 구축하고 연관 시스템과 통합하는 과정 구축 후 기존 데이터 파이프라인과 비교해 어떤 면에서 나아졌는지 소개 '커스텀 Connector 및 컨버터 개발과 활용'과 관련해서도 공유드리고 싶은 내용이 많은데요. 이 주제는 추후 다른 분께서 별도 포스팅으로 자세히 소개해
- Server-side
- Java
- Data
사이드카 프록시로 구현한 서비스 인증
박찬우2022-12-30
2014년부터 LINE에서 글로벌 이벤트, 오픈챗 포스트, 코인 거래소, 블록체인 플랫폼, 커머스 서버 개발자로 일했고, 현재는 LINE VOOM 서버 개발자로 일하고 있습니다.
안녕하세요. LINE VOOM 서버 개발자 박찬우입니다. 최근 신규 프로젝트를 진행하면서 각 하부 모듈 인증을 공용화할 방법을 고민하게 됐습니다. 해당 프로젝트는 크게 두 가지, 세부적으로는 10개가 넘는 하부 모듈로 구성돼 있었는데요. 일부 모듈은 오픈소스를 활용했기 때문에 인증을 소스 코드 수준에서 일괄 적용하기 어려웠고, 유지 보수 비용도 과다하게 발생할 것으로 예상됐습니다. 고민 끝에 내린 결론은 사이드카 패턴을 이용한 인증 프록시를 별도로 개발해 적용하는 것이었습니다. 이번 글에서는 서비스 인증을 사이드카 프록시(Sidecar proxy)로 구현한 사례를 공유하려고 합니다. 이 글이 프로젝트 유지 보수 비용을 절감할 수 있는 한 방편으로 활용되기를 바라며 글을 시작하겠습니다. 참고. 이번 글에서 말씀드리는 내용은 프로젝트가 쿠버네티스 환경에서 작동한다고 전제합니다. 사이드카 프록시란 먼저 사이드카 프록시가 무엇인지 살펴보겠습니다. 사이드카 패턴 사이드카 패턴
LINE 알림 센터의 메인 스토리지를 Redis에서 MongoDB로 전환하기
김진수2022-10-19
Jinsoo is in charge of LINE Integrated Notification Center
안녕하세요. Social Integrations Platform Dev 팀에서 'LINE Integrated Notification Center'(LIN 혹은 알림 센터) 개발을 담당하고 있는 김진수입니다. LIN 프로젝트를 간단히 설명드리자면, 프로젝트 명에서 알 수 있듯 LINE 통합 알림 센터 제공을 목표로 진행하고 있는 프로젝트입니다. 사용자에게는 알림 센터로서 다양한 알림을 통합된 공간에 제공해 편의성을 높이는 것이 목적이며, 사내로는 여러 서비스에서 알림 센터를 별도로 구축할 필요 없이 LIN과 연동해 쉽고 편하게 알림 센터의 기능을 사용할 수 있도록 만드는 것이 목적입니다. 현재 LIN을 이용해 서비스하고 있는 알림 센터는 두 곳이 있습니다. 첫 번째는 LINE 홈 탭(첫 번째 탭)의 우측 상단에 위치한 종 모양의 홈 탭 알림 센터로 LINE에서의 사용자와 친구들의 전반적인 활동과 관련된 알림을 사용자에게 제공합니다. 두 번째는 LINE VOOM 탭(세 번
- Server-side
messaging-hub 트러블 슈팅
송재욱2022-10-14
도메인을 이해하고, 문제를 정의한 후, 해법을 개발하는 일을 즐깁니다.
안녕하세요. LINE+ ABC Studio에서 messaging-hub를 만들고 있는 송재욱입니다. messaging-hub는 독립적이고 범용적인 메시징 플랫폼이라는 방향으로 자체 개발하고 있는 시스템으로, 현재 일본의 No.1 푸드 딜리버리 서비스인 Demaecan에서 사용하고 있습니다. messaging-hub를 소개했던 이전 글(1편, 2편)에 이어 이번에는 서비스 운영 과정에서 진행한 몇 가지 트러블 슈팅 사례를 공유하겠습니다. 글은 다음과 같은 순서로 진행합니다. 첫 번째 사례: 불안정한 네트워크에서 '보냈는데 못 받은' 메시지 해결 방법 1: 연결 확인 과정 확립 해결 방법 2: 메시지 수신 확인 절차 확립 두 번째 사례: 평생 마주치고 싶지 않았던 Out Of Memory 해결 방법 1: 쿠버네티스 QoS 클래스 변경 해결 방법 2: JVM 옵션 설정 적용 결과 세 번째 사례: 웹소켓 연결이 동시에 끊겼는데 네트워크 장애가 아니라면? 웹소켓 연
- Server-side
Hive에서 실시간으로 쇼핑 데이터를 조회할 수 있게 ETL 개선하기
김성도2022-09-08
LINE에서 커머스 플랫폼 엔지니어로 일하고 있습니다.
안녕하세요. Global EC(Global E-Commerce, 이하 GEC)에서 쇼핑 개발을 담당하고 있는 김성도입니다. LINE 쇼핑에서는 실시간으로 상품 정보를 업데이트할 수 있는 LINE 쇼핑 플랫폼을 사용해 모든 상품 정보를 취합하고 있으며, 취합한 상품 정보는 사용자의 쇼핑 경험을 개선하기 위해 검색 엔지니어와 데이터 엔지니어에게 제공하고 있습니다. 수억 개에 이르는 상품 정보를 서비스에 영향을 주지 않으면서 ETL(Extract, Transform, Load)하는 작업은 쉽지 않은 일입니다. 그런데 여기에 한술 더 떠서 실시간으로 업데이트까지 하려면 어떻게 해야 할까요? 이번 글에서는 이 어려운 과제를 해결하기 위해 어떤 과정을 거쳤는지 소개하려 합니다. 글은 다음과 같은 순서로 진행합니다. 요구 사항 분석 데이터베이스 부하 감소 업데이트 주기 개선 정합성 유지 HBase를 사용한 1차 개선 1차 개선 구현 방법 1차 개선 아키텍처 1차 개선 결과 및 문제
- Server-side
- Data

1 2 3 4 5