Category Archives: Back-End

MySQL performance-schema-instruments 사용에 따른 성능 영향 실험

안녕하세요. LINE에서 주로 MySQL 기반 DB 오퍼레이션, 각종 DB 관리 툴, 검증 툴 등을 개발하고 있는 Otsuka(tom__bo)입니다. 이번 글에서는 MySQL의 성능 정보를 얻을 때 이용하는 performance_schema 데이터베이스와 information_schema 데이터베이스의 innodb_metrics 테이블을 모두 활성화하면, MySQL 전체 성능이 어느 정도 나빠지는지 실험한 내용을 소개하겠습니다.

SETUP_INSTRUMENTS
ALL ‘ENABLED’ COLUMN
SETUP_INSTRUMENTS
ALL ‘TIMED’ COLUMN
ALL
INNODB_METRICS
TPS 모두 DEFAULT일 때
대비 TPS 비율
AVERAGE
LATENCY
COMMENT
NO NO DISABLED 3506.25 1.031 2.28 performance_schema와 innodb_metrics의 설정을 모두 비활성화한 상태
NO NO DEFAULT 3496.40 1.029 2.29 performance_schema의 instruments를 모두 비활성화한 상태
DEFAULT DEFAULT DISABLED 3391.85 0.998 2.36 innodb_metrics의 설정을 모두 비활성화한 상태
DEFAULT DEFAULT DEFAULT 3399.32 1.00 2.35 디폴트 설정
DEFAULT DEFAULT ENABLED 3389.69 0.997 2.36 innodb_metrics의 설정을 모두 활성화한 상태
YES DEFAULT DEFAULT 2906.15 0.855 2.75 performance_schema의 instruments를 모두 활성화한 상태
YES YES DEFAULT 2837.44 0.835 2.82 performance_schema의 instruments, TIMED를 모두 활성화한 상태
YES DEFAULT ENABLED 2908.34 0.856 2.75 performance_schema와 innodb_metrics의 설정을 모두 활성화한 상태
YES YES ENABLED 2825.31 0.831 2.83 performance_schema(TIMED도 활성)와 innodb_metrics의 설정을 모두 활성화한 상태

GitHub Pull Request가 자동으로 close되는 경우는?

LINE 개발 팀에서 서버 쪽 개발을 담당하고 있는 Ohara(@kory1202)입니다. 저희 팀은 PR(Pull Request)을 master 브랜치(branch)로 생성하는 방식으로 Git을 운영하고 있습니다. 이런 방식으로 Git을 운영하면 PR을 merge했을 때 다른 PR이 ‘자동으로 close되는 상황’이 발생하곤 했는데요. 정확히 어떤 조건에서 자동 close되는 것인지 확실히 알 수 없었습니다. GitHub Help > Closing a pull request를 읽어 보아도 원하는 답이 나오지 않더군요. 그래서 아예 직접 정리를 해보았습니다.

Kotlin으로 서버사이드 개발과 Clova Skill Award 도전!

LINE Engineering Blog를 찾아주신 여러분, 안녕하세요? 오늘은 두 명이 공동으로 작성한 포스팅입니다. 저희 소개 먼저 드리겠습니다. LINE에서 게임 플랫폼 개발을 맡고 있는 Kagaya와 동영상 생중계 서비스 LINE LIVE의 Android 앱 개발을 맡고 있는 Akira입니다.

이번 포스팅에서는 아래 두 가지 이야기를 통해 서버사이드 Kotlin에 관한 노하우와 유스케이스를 공유할까 합니다.

  1. Kagaya가 담당하는 LINE GAME 플랫폼의 Kotlin 이용 현황 이야기
  2. ‘LINE 사내 Clova Skill Award’에 저희 둘이 팀으로 참가해서 Kotlin으로 영광의(?) 최우수상을 수상한 이야기

RedisConf18 발표 후기

안녕하세요, LINE의 Redis팀의 최종열(Jongyeol Choi)입니다. LINE에서는 각 서비스별로 다양한 스토리지 시스템을 사용하고 있습니다. 그 중에서 메시징 서비스에서는 Redis, HBase, Kafka 등의 오픈 소스 스토리지 시스템을 많이 사용하고 있는데요, 저는 그중에서 특히 Redis와 관련된 부분들의 개발을 담당하고 있습니다. 그래서 그 연장으로, 지난 4월 26일에, 미국 샌프란시스코에서 열린 RedisConf18 컨퍼런스에 발표자로 참가해서, “Redis at LINE, 25 Billion Messages Per Day”라는 주제로 발표를 했습니다. 발표 준비부터, 컨퍼런스의 분위기, 발표에 대한 반응 등을 소개하겠습니다.

RedisConf18 Venue

API the Docs 참관 후기

안녕하세요? 테크니컬 라이터 Serizawa입니다. LINE은 개발자들이 최신 기술 동향을 파악할 수 있도록 해외 컨퍼런스 참가를 지원합니다. 이번 포스팅에서는 제가 이 지원 제도를 이용해 다녀온 API 문서화 관련 컨퍼런스인 API the Docs에 대해 전해 드릴까 합니다.

API the Docs는 테크니컬 라이터, API 개발자, 프로덕트 오너, 에반젤리스트를 대상으로 한 API 문서화에 특화된 행사로, 해마다 여러 차례, 세계 각지에서 열립니다. 개발 경험(Developer eXperience, 이하 ‘DX’)의 중요 요소인 문서화에 관해서 최신 우수 사례나 경향 등을 공유하고 의견을 나누는 자리이지요.

LINE LIVE 서비스의 인코더 레이어 구조

안녕하세요, LINE에서 글로벌 인프라 시스템을 운영하는 조직에서 개발자로 일하고 있는 김수혁입니다. 2017년 12월 10일은 LINE LIVE 서비스가 공개된 지 2년이 되는 날이었습니다. 서비스 출시 후 수많은 개발자들의 노력으로 지금까지 큰 장애없이 원활하게 운영되고 있습니다. 이번 블로그에서는, 라이브 미디어 서비스를 구축하거나 운영해 본 경험이 없는 상태에서 초기 설계와 구축을 진행하면서 개인적으로 고민했던 내용을 정리해 보았습니다.

Prometheus를 서비스로 제공하기

안녕하세요, LINE 후쿠오카 개발 부서에서 근무하고 있는 폴 트레일러입니다. 저는 LINE Family App을 위한 다수의 서버를 모니터링하는 업무를 담당하고 있습니다.

대부분의 개발자들은 코딩과 신규 기능 개발에 더 큰 흥미를 느끼겠지만 기능이 제대로 동작하지 않을 때 그 원인을 파악하는 것 또한 매력적이며, 매우 유용하기도 합니다. 모니터링은 문제의 원인을 파악하는 데 큰 도움이 될 수 있는데, 개발자가 모니터링 환경을 직접 구축하고 설정하는 것은 까다로울 수 있습니다. 여기서 바로 제가 등장합니다. 저는 개발자들이 쉽게 서비스별 임계치를 모니터할 수 있도록 돕는 역할을 담당하고 있습니다. 개발자들이 쉽게 모니터링 대상을 등록하고, 담당 서비스에 대한 알림 요청을 설정할 수 있도록 Prometheus 설정 값들을 수월하게 관리하는 Promgen을 개발하여 여러분께 소개하고자 합니다.

모니터링 설정하기

대부분의 서비스는 간단하고 작은 규모로 시작하지만 시간이 지날수록 다양한 구성 요소들이 여럿 생겨나 수백 개의 서버들을 통해 제공되곤 합니다. 이런 환경에서 모니터링을 설정하는 것은 쉬운 일이 아닙니다. Promgen은 모든 모니터링 설정 항목들을 한 곳에서 한번에 볼 수 있도록 개발되었습니다.

targets

LINE LIVE의 PC 송출 기능을 위한 queue 구현

안녕하세요, LINE LIVE 개발을 담당하고 있는 Yappo입니다. 이번 블로그에서는 사용자의 PC에서 LINE LIVE 서비스를 송출하는 기능을 구현하기 위해 task 실행을 지연하는 queue를 만든 과정을 소개하겠습니다.

LINE LIVE의 송출 방식

기존에 LINE LIVE에서 제공하는 송출 방식은 LINE LIVE 앱에서 직접 송출하는 방식, LINE Official Account Manager와 RTMP 소프트웨어나 전용 장비를 사용하여 PC에서 송출하는 방식이 있었습니다. 다시 말해서, 사용자는 LINE LIVE 앱을 사용해야 방송을 할 수 있고 PC에서는 불가능했습니다. PC에서의 방송은 LINE OA 관리자만 가능했습니다.

아래 그림을 보면 두 송출 방식이 완전히 다른 구조로 구현되는 것처럼 보이지만 기본 설계는 동일합니다.


비콘을 이용한 geo-linked 애플리케이션

안녕하세요, 저는 대만에서 LINE Beacon 플랫폼의 사업 개발 및 기획을 맡고 있는 Charlotte Yu입니다.

저는 최근 LINE Beacon의 위치 인식 기술을 활용하는 방안을 모색하고 있습니다. LINE Beacon의 위치 인식 기술은 LINE이 지향하는 Smart Portal(스마트 포털)을 실현하고 사람과 사람, 사람과 정보, 사람과 서비스의 거리를 좁히는 “CLOSING THE DISTANCE”를 달성하는 데 중요한 역할을 하게 될 것입니다.

아직 초기 단계인 현 시점에서는 비콘을 성공적으로 보급하고 좋은 이용 사례를 소개하여 사용자 인지도와 이용률을 높이는 데 주력하고 있습니다.

우리의 전략은 LINE Beacon 플랫폼을 대만에서 인기 있는 다른 LINE 서비스 및 기능과 결합시켜 대만의 방대한 LINE 사용자에게 제공하는 것입니다. 그리고 앞으로는 위치 인식이 모바일 기술의 발전을 견인하는 원동력이 될 것이라는 판단 하에 가능한 많은 장소에 LINE Beacon을 설치하여 비콘 네트워크를 구축하고 있습니다. 이 두 가지, 즉 대만에서의 방대한 사용자 기반과 위치 인식 기술을 활용한 geo-linked 애플리케이션이 O2O 에코 시스템의 중요한 두 가지 요소입니다.

O2O 메시징은 온라인 플랫폼을 오프라인 상점으로 연결하는데 활용될 수 있습니다. O2O의 목표는 온라인 시장 혹은 온라인 플랫폼에서 대부분의 시간을 보내는 소비자들을 오프라인 상점으로 유도하는 것입니다. 그렇게 하려면 온라인 쿠폰이나 멤버십 카드를 제공하고 근접 마케팅을 펼쳐야 합니다. 그래서 저희는 다양한 비콘 애플리케이션을 만들어 가상 세계를 현실 세계로까지 확장해 줄 수 있는 온라인-오프라인 네트워크를 구축하고 있습니다.

O2O와 비콘은 일상에서 사용하는 제품에 LINE Coupon, LINE Points, LINE Shop Card 같은 기능을 연동함으로써 매출을 늘립니다. 근접한 LINE 사용자들에게 GeoAD(geo-linked advertisements)를 push하여 매장과 고객 홍보를 하고 공식 계정, LINE@ 계정 같은 LINE 비즈니스 계정으로 이벤트를 실시할 수 있습니다. 또한 LBS(location-based service, 위치 기반 서비스)에 기반한 쿠폰이나 스티커를 활용하여 LINE 사용자들이 상점을 방문하도록 합니다. 궁극적으로 LINE@ 운영자는 실내 내비게이션, 쇼핑 가이드 같은 LBS 애드온을 제공하여 사용자 경험을 개선하고 고객 유지율을 높일 수 있습니다.