이석찬 / 개발4실 LINE+

LINE은 어쩌다어떻게 글로벌 메신저 플랫폼이 되었는가

CONTENTS

LINE? Global Platform

LINE 원정대

Client Analytics Apps Global

Network

LINE Game

Big Data Security

490+ Million Users

Q&A

6+ Global Branch

6 Engineering

Base

4 Regional CS Center

Global Platform

8 Global POP

100+Gbps thru

100+ Peering 20,000 Servers

9 Supported

OS

20 : 80 Japan : World

1B Downs 71 Apps

Q&A

어느 정도 잘 하고 있다고 생각했는데 1.  Ranked #1 in 60 countries

2.  71/179 Family Apps, 17+ Language Support, 9 OS Supported and more 3.  Glocalization : emoji, stickers, UX, event

But, 개발자를 괴롭히는 2가지 문제들 1.  경쟁사보다 느려요, 메시지가 잘 가지 않아요

2.  배터리를 (처)먹어요!

Global Problem 2개

Q&A

1.  무엇이 문제인데? 카더라, 나는 겪었거던, 재현은 어떻게 하는지 몰라, …

2.  얼마나 빨라야 하는데? 그냥 경쟁 앱보다 빠르면 되잖아

3.  왜 느린가? 알면 얘기하겠어

4.  무엇을 해야 하나?

5.  누가 이 문제를 고쳐야 하나?

6. 왜 하필 지금? 그리고 나에게 묻죠?

문제를 맞이하는 자세

v 머피의 법칙: 왜 모든 문제는 boss의 폰에만 생기는가 ?

2012년 12월 Spain, 사용자가 갑자기 늘었어요 (마치 지금의 Telegram처럼)

2013년 2월 어느날, 출발 전날 Spain 비행기 티켓이 주어지고

…

2 ~ 6명의 Client/Server 개발자가 3 ~ 5일씩

GPRS, Edge, 3G/3G+, 4G/LTE and Airplane WiFi

호텔, 식당, 지하철, 버스, 관광지

엘리베이터, 비행기, 물 속, 높은 곳

문제를 찾으러 - LINE 遠征隊

Taiwan

Indonesia

India

Spain

LINE 遠征隊

문제(아)들

•  Welcome to Hell : Transparent Cache/Proxy

•  503, sessions, image, header … •  Transparent images, 사라진 Content-Length, X-Capital-Header:

•  차단 : IP, DNS blackhole, VoIP, DPI, 국가/종교의 이름으로 •  3G는 몹쓸 것, http://helloworld.naver.com/helloworld/111111 •  High DNS resolving failures : 40-60% at peak time on some carriers •  Philippines, Vietnam, Indonesia, India, China, Iran …

통신사의 흔한 문제들

이런 경우에는 •  “피하세요” : HTTPS and SPDY on 443/tcp

•  “대비하세요” : No one magic protocol, 언제라도 변경이 가능해야 합니다

•  SPDY, HTTPS, HTTP protocols are supported on a single 443/tcp

•  “우리 친구해요”: 통신사와 장비회사 모두랑, peering, zero rating

•  carrier-contact@linecorp.com

•  빠르게 : less round trips, less bytes, light UI

•  Async operations, pre-fetching, background sync

•  Warmup 3G(Ping) and TCP(pre-connection)

•  CDN, Cloud DNS on BGP Anycast

•  그래도 안 되면, 빠른 척이라도 UX : 어차피 떨어져 있어 몰라요

흔한 문제들에 대한 대응

•  출장을 가지 않고도 어떻게 문제를 찾고, 해결되었는지 알 수는 없을까

•  App Reviews

•  Client Analytics

•  New features

•  Zombie WiFi(Captive portal) 대응

•  More compact protocol

•  Typing ping

•  Troubleshooting, Improvements

•  SPDY protocol

•  In-flight WiFi

•  Battery 사용량 개선

진지했던 문제들

(반성) 2013.04, 싱가폴 사용자들이 앨범 뷰가 안 보인다고 리뷰 도배질을 1달 뒤에 알았다

없어서, 만들었더니 알게 된 것 •  Android : Package File invalid – Google, Android

•  iOS X beta : 제발 beta 사용하지 마세요

•  major, minor bugs, crashes

•  특정 국가, 통신사, Phone, OS, 특정일에만 발생하는 문제들

•  새로운 기능/UX에 대한 피드백 : 정말 국가마다 달라요

•  Features comparison by Apps

•  종교 전쟁 : WhatsApp vs LINE

•  그 중의 백미(白眉), 새 버전 발매하는 날의 Tag Cloud “튕겨요”

•  Weekly Review by Language/Region

App Reviews

App Reviews

App Reviews

•  User Behavior Analytics 할려다, Performance & problem trending

•  WiFi에 연결되어 충전 중일 때, App이 보낸 통계 데이타를 Big Data 분석

•  이제는 모든 국가, 통신사, OS & App version 구분하여 tracking 가능

•  하지만, 앱리뷰에 욕한 사람의 기록을 찾지 못해요 ㅠ.ㅠ (개인정보)

•  QMS, Gomez, Google Analytics 사용하지 않는 이유는?

Client Analytics

•  Time to send, receive Text / Audio / Video / Sticker / Themes •  Size and speed to send, receive Multimedia files •  Error types, error rates of each operations

•  Net connect and DNS resolving •  Battery usage in bg/fg, # of run per day

Client Analytics

Only SPDY

•  SPDY, SPDY, SPDY : 99.8% 이상의 사용자 접속

•  가능하면 http(s) 사용하지 않도록 변경

•  추가의 connection 만들지 않게 : +1 RTT, 배터리, TCP window size

•  SPDY의 server-side push 를 미래에 사용하기 위해서

More compact protocol

send “hello”Out (DATA)

send “hello”In (ACK)

get “hello”In (DATA)

get “hello”out (ACK)

WhatsApp 56 44 97 43 LINE 83 100 (63) 244 166

대만 Chunghwa : 밤 시각의 메시지 송신에 8~9초 걸리는 문제 분석

•  In 200byte + Out 200byte 정도면, 3G FACH ~ DCH transition delay 발생함 •  3G RRC transition delay를 피하도록, 가능한 FACH에 머물도록

•  평균 응답 크기, P4 : P5 = 244.8 : 194.7 (19.5% 감소) •  1000byte 이하 응답 평균 = 149.4 : 117.9 (21.2% 감소)

In-flight WiFi

네트웍 특성: 300~1000ms RTT, 1대가 download 5Mbps & upload 1Mbps 공유

바꾸어야 하는 것들

•  WiFi에서 사용하던 HTTPS 대신에 모두 SPDY로 변경할 필요성 대두

•  대신에 모든 커넥션을 암호화 해야 => “light but strong encryption” 새 숙제 •  NSpeedEm, Apple’s Network Link Conditioner를 이용한 simulation

Light but strong encryption

SSL은 mobile connection에 맞지 않음: 1 RTT 위해 max 1초 희생해야 한다.

대신에

•  Server Certificate를 앱 배포시 내장하고

•  자체적인 RSA + AES 암호화 방법을 구현 •  Redis를 통한 session cache 구현

장점 단점

HTTPS (공인) 추가 구현이 매우 간단 구현 방법 매우 안전(OS내장)

인증서 size, 다운로드 SSL handshaking 필요

HTTPS (사설) 구현이 간단하다 구현 방법 매우 안전(OS내장)

SSL handshaking 필요

Public Key + AES

키 사이즈가 작음 추가 구현 코스트 추가 메모리 사용 키 유출시의 대응 필요

•  버그의 수정: 수많은 looping 관련한 버그들

•  Server side ping than client side ping

•  Push notification 방법의 변경

•  Stop background polling for inactive users

•  빠른노티와 배터리와의 타협

•  휴면 사용자의 배터리는 소모되지 않도록

•  Timeout wake-lock

•  요즘 사용자들은 앱 리뷰에 “WLD에 몇회나 호출된다”는 말까지 적는다 ㅜ.ㅜ

•  Android 설정의 “Battery”, WLD, BetterBatteryStats 다 확인

Android battery 문제

Android battery 문제

Total mA Total 3G Total CPUGCM only 538 1,604 387 Client Ping 3, 731 12,474 1,333 Server Ping 2,596 8,126 1,482

Client Side Ping •  Timer: heartbeating every X seconds

•  Network: upstream

Server Side Ping –30% less than client side ping •  Timer : reset and start when received ping

•  Network: downstream

•  세상은 자주 바뀌고, 앱 심사는 오래 걸리고, 출시 전에 모든 버그를 잡을 수 없다면

•  해답: App의 동작 방식을, 서버에서 바꿀 수 있게 하자! since year 2012

•  By OS, App Version, Country, Carrier, WiFi or Mobile

•  UI, protocol, push, failover, max #, interval, address, …

•  새 기능의 안전한 출시, 문제에 대한 workaround에 적용을 위해 주로 사용(차단, 버그)

•  단, 서버에서도 국가별 설정이 가능하다 J (어떤 국가에서만 특정 기능을 제한할 때)

자유로운 설정/기능 변경

가능한 것들 •  Performance & battery (Android)

•  Fixing various problems w/ transparent caches

•  Fighting with blockings

•  1월 1일 0시 트래픽을 대비해서 2일 전부터 사진 크기를 줄일려면, 어떻게?

자유로운 설정/기능 변경

글로벌 POP 현황(2014.6월말 기준) 2. Global Network Async send operation

•  nearest POP responds OK first, with late notification if any errors

여기까지 요약하면

•  Captive portal

•  High failure rate in DNS resolving

•  IPv6 network : ready ?

•  아스트랄한 차단들 ..

•  …

나머지 Topic은 다음에…

Storage of LINE

Redis

•  대용량, 고성능 지원

•  50+ TB, 10+ clusters, 3000+ shards, 30M+ Op/sec

•  Shard 단위 Availability 보장

•  Redis의 기본적인 master-slave replication 활용

•  Auto promotion & recovery

•  Cluster 단위 robustness

•  Cluster manager를 통해, 일부 shard의 장애가 전체로 확산되는 것을 차단

•  Service 단위 Availability 보장

•  Redis 장애시, HBase로 fail-over

Redis – 이런 건 기본

•  다중 layer 분산 스토리지에서 Consistency와 Availability 지키기

•  부분 장애시, write call에 대한 보장은 어려운 문제.

•  Read와 Write에 대한 차별적 failover.

•  Read >> Write. Read의 availability에 집중. •  공격적 Failover

•  Redis는 single thread. 순간적인 준 장애 발생 가능.

•  Shard 상태를 모니터링, 선제적으로 failover 실행.

•  Dual-async fail over

•  Redis에 비해 HBase는 수십배 느림.

•  빠른 fail over를 위해, redis retry와 HBase retry를 동시에 수행.

•  Cluster 동적 확장

•  가상 클러스터

•  Sharding 방식 고도화

Redis – 어려운 숙제들

•  HBase, using persistent storage entirely

•  Running 10 x HBase clusters

•  Addressbook, messages x 2, backup, stats

•  Operation, archive-operation, event, channel, user

•  1.24 PB capacity for service data, 7PB for statistics, lots of FusionIO (300 ~)

•  Operation HBase cluster – 220K RPS from 150 node(153TB)

HBase, Bigger than bigger

•  대부분 통계/분석 용도로 사용, but response time/availability 서비스에는 안습

•  HBase @LINE의 특징

•  주요 데이타들은 dual cluster로 구성: cluster-wide failure에 대응

•  availability를 위하여 application쪽에서 다양한 로직이 구현

•  throughput보다는 response time 위주로 튜닝 (gc 튜닝, FusionIO 등)

•  immutable data의 경우 redis cache를 적극적으로 활용

•  통계 분석: 주요 데이타 cluster replication 후, 로그 데이타와 join 하여 분석

•  0.90 cdh3 버젼에서 시작, online upgrade가 안되서 개고생, 최근에 업그레이

드를 위해 여러가지 안을 시도 중 (offline 업그레이드는.. )

•  HBase cluster replication: pull based replicator (vs push based )

HBase, 한땀 한땀 만든

Abuser == Social Engineer

•  Global Platform means global eco(nomic)-systems for abusers •  Spamming, Stealing Accounts, Phishing

•  Brute force

•  90% of authentication failures : 5M ‘Gmail Passwords’ Leaked

•  abusing bots , Tor and China

•  로그온 5번 실패하면 해당 ID blocking ? 이 정도는 다 피해요

•  Add friend notification 개시 후 문제점: 대화명이 “LlNE lndonesia” ㅠ.ㅠ

•  건강한 멘탈과 분석 시스템, CS 대응이 중요

Abusing

Answers are •  Email & password는 공공재™

•  Strong Authentication

•  2nd factor, 3rd factor authentication

•  Smartphone(SMS) and App as OTP device

•  CAPTCHA, QR Code, PIN code by System OA

•  훌륭한 질문과 답

•  (X) 엄마가 태어난 도시는 ? 서울 (20% 확률)

•  (O) 엄마 & 동생 전화번호 뒷 4자리를 곱하면 ? 확률 1 of 10^8, 개인정보 아님

•  친구 관계를 이용한 질문들

•  15개의 사진 중에 친구의 프로필 사진 2개를 고르기

•  친구의 전화 번호를 입력해 주세요

Abusing

WE’RE HIRING

http://recruit.linepluscorp.com/ join@linecorp.com

LINE Developers Conference

11/26(수), COEX

더 궁금하신 분들은 http://developers.linecorp.com/blog/

Q&A

THANK YOU