Advent Calendar

엑셀 피벗 테이블을 ElasticSearch와 Kibana로 만들어 보자

안녕하세요. 작년 8월에 LINE에 합류해 주로 서버 구축 및 관리를 담당하고 있는 Yasunori Kuji입니다. Elasticsearch와 Kibana의 조합은 로그 분석할 때 많이 사용하는데요. 이번 글에서는 각각의 특성을 살려 엑셀 피벗 테이블의 대용으로 사용할 수는 없는지 시도해 본 결과를 말씀드리려고 합니다.

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의 설정을 모두 활성화한 상태

TensorFlow.js: 웹 프론트엔드에서 머신러닝 활용하기

안녕하세요! LINE에서 프런트엔드 개발을 담당하고 있는 Jun입니다. 최근 프런트엔드 분야는 흥미로운 기술이 가득해서 전부 다 파악하는 게 힘들 정도인데요. 개인적으로 가장 관심이 가는 건 머신러닝입니다. 오늘은 웹 프런트엔드에서 머신러닝 활용하기를 주제로, TensorFlow.js를 사용해서 간단하게 머신러닝을 구현해 본 경험을 공유하겠습니다.

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를 읽어 보아도 원하는 답이 나오지 않더군요. 그래서 아예 직접 정리를 해보았습니다.

LIFF(LINE Front-end Framework)에서 TIC-80을 작동시켜보자

안녕하세요. LINE Fukuoka에서 LINE 메신저 앱 개발을 담당하고 있는 안드로이드 엔지니어 Seisuke입니다. 지난달(2018년 11월)에 열린 사내 해커톤에서 Fantasy Console이라는 다소 낯선 장르의 제품인 ‘TIC-80’을 LIFF에서 작동시켜 보았는데요. 여기서 얻은 지식을 혼자 알고 있기는 아까워 블로그를 작성하게 되었습니다.

LTO(Linear Tape-Open) 드라이브

안녕하세요. LINE 앱의 안드로이드 클라이언트 개발을 맡고 있는 Tamaki(@r_ralph_h)입니다. 오늘 포스팅에서는 일반 소비자용으로는 조금 생소한 ‘LTO 드라이브’를 실제 사용해 본 소감을 전해 드릴까 합니다. LTO 드라이브란? LTO의 정식 명칭은 ‘Linear Tape-Open’으로, 자기(磁氣) 테이프 미디어의 일종입니다. 잘 알려진 자기 테이프 미디어로는 오디오 카세트 테이프나 VHS(video home system), 8mm 비디오 테이프 등이 있습니다. 테이프 미디어는 미디어 용량에 […]

Atomic 처리와 cache stampede 대책을 위해 Redis Lua script를 활용한 이야기

안녕하세요? LINE에서 게임 플랫폼 개발을 맡고 있는 Kagaya입니다. 신입 사원 1년차였던 2016년에 마이크로 서비스용 프로젝트 생성 도구 Lazybones를 사용해 보니(일본어 글)를 포스팅한 데 이어 한번 더 기고하게 되었습니다. 반갑습니다. Redis와 LINE GAME Platform LINE GAME Platform은 주 데이터베이스의 하나로 인메모리(in-memory) NoSQL 데이터베이스인 Redis를 사용하고 있으며, 이를 주로 캐시로 이용합니다. 이를테면 LINE이나 Facebook 등의 계정으로 인증하는 […]

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

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

Code splitting을 쉽게 하기 위해 만든 grow-loader

안녕하세요, 저는 LINE MANGA팀의 자바 스크립트 개발자, @sunderls입니다. 일본에서는 LINE으로 만화를 볼 수 있다는 것, 알고 계셨나요? 혹시 여러분은 LINE MANGA1) 서비스를 이용해 보셨나요? 예전에 블로그를 통해서도 나누었듯이(LINE MANGA: Page Stack을 이용해서 페이지 전환 처리하기), LINE MANGA는 웹 기반으로 구현되어 있습니다. 이 서비스는 LINE 앱 안에서 구동되는 서비스이기 때문에, LINE 앱을 이용할 때와 마찬가지로 편안하고 매끄러운 UX를 제공하고자 저희는 많은 노력을 쏟았습니다. 우리는 우리의 목표를 달성하고자 code-splitting을 도입하였는데, 이 글을 통해 code-splitting을 손쉽게 적용할 수 있도록 개발한, LINE의 오픈 소스 프로젝트인 grow-loader를 여러분께 소개하고자 합니다.