공식 홈페이지는 여기: LINE Developer Day 2015 Seoul

나중에 모든 세션 동영상과 발표자료를 공개한다고 하니, 보고 느낀 소감이나 생각만 정리해본다. 오늘 공식 홈페이지에 발표자료가 공개되었다(UPDATE: 2015/11/27).

내가 들었던 세션은 아래 목록과 같다.

주로 게임 트랙을 들었는데, 플랫폼 트랙은 Armeria(?)라는 LINE의 개발 프로젝트가 반응이 좋았다고 한다(오픈 소스로 내놓으신다면서요?)


LINE Bubble 2 Development Story

원래 개발자를 위한 행사라서 그런 것이었나? 내게 기술 스택 공개는 좀 생소한 일이었는데, 개발자가 아니라서 낯선 풍경은 행사 내내 계속되었다. 개발 초기 스택과 개발 중에 변경된 스택을 함께 보여주었다(아래 사진 참조). 흰색이 개발 초기, 파란색이 나중에 도입된 것들이다. 이 역시 개발자마다 호불호가 있어서 IDE는 개발자 취향이라 했다(근데 Java가 8.0에서 7.0으로? 잘못 표기된 듯?).

Technology Stack_Server

TV 광고 캠페인을 진행할 때마다 새 사용자가 많이 유입되었다(역시 게임은 마케팅을 잘해야 한다). 아래 사진을 보면 가입자 수가 계단처럼 증가한 것을 볼 수 있다. 계단에 해당하는 시점이 광고가 있었던 시기다.

Server Failure

사용자가 많아질 수록 게임 서버 개발팀은 일이 많아진다는 의미이기도 하다(슬라이드 제목이 Server Failure ㅋㅋ). 그래도 개발팀에게 고무적이었던 건 유입된 사용자가 계속 유지되었다는 사실이다. 사용자의 증가가 얼마나 이뤄질지 예측하기 매우 힘들었는데, LINE Game Cloud로 해결했다고 한다.

라인이 제공하는 게임이 전세계를 대상으로 이뤄지다보니, 글로벌한 이슈들이 있었다. 특히나 동남아시아의 네트워크는 망 연결 상태가 열악해 게임을 다운로드하려 해도 1%에서 응답이 없다든가, 다운로드 실패 후 반복적인 재시도가 이뤄지면서 트래픽이 몰리는 문제 등이 있었다.

국가마다 망 특성을 타기도 하나보다. 일본에서 특정 통신사를 사용하는 사용자들에게서 게임이 실행되지 않았는데, 특정 통신사 망에서 HTTP 요청 헤더의 accept-encoding:gzip을 제대로 처리하지 못하는 문제가 있어 해당 통신사 단말기를 수배해 확인하고 처리했다는 에피소드. nMobile이 큰 도움이 되었다고 한다. 다른 세션에서는 HAProxy를 이용해 사용자와 근접한 데이터 센터에서 트래픽을 로드밸런싱한다는 이야기를 하기도 했다(LINE Game Cloud).

앱 출시 직후 사용자의 리뷰를 모니터하는 것도 매우 중요한 일이다. 사용자 리뷰를 보다보니, 유독 대만에서 별점 1개가 많았는데, 모두 게임 중 앱이 멈춰버려 튕겨나가는 문제에 관한 것이었다. 특정 제조사의 특정한 안드로이드 버전에서만 발생한다는 것을 확인하고 해결.

게임의 가장 중요한 요소는 난이도 조정인데, 출시 전에 모바일 시뮬레이터를 이용해 난이도를 수치화해 측정하고, 직접 게임을 해보면서 난이도를 조정했다고 한다. 한가지 팁이라면 출시할 때에는 난이도를 조금 높게 잡고, 사용자 반응을 모니터하면서 조금씩 낮춰주는 것이 좋다고…

사용자 데이터 분석을 위해서는 빅 데이터 기반의 서버 기술을 활용했다. 라인이 구성한 빅 데이터 분석 플랫폼은 AirBorne이라는 이름이 붙었는데, 하루에 2억 6천만 건의 게임 데이터가 쌓인다고 한다. 원래 AirBorne은 게임 어뷰징이나 해킹을 탐지하기 위한 보안 데이터 분석 시스템의 일부로 개발되었다. AirBorne은 Spark, Mesos, Zeppelin, HDFS를 활용한 대용량 보안 데이터 분석을 보면 되겠다.

그 외에, LINE의 문화를 소개했는데, 사내에서 게임 공모전을 한다고 한다. 게임 공모전에서 우승한 게임은 출시할 수 있도록 회사가 지원해주는데, 최근에 런칭한 게임이 CUBE HEROES란다.

아, LINE Bubble2에 이스터 에그가 있다고 한다. 찾아보시라.

LINE Game Cloud

IT 인프라를 관리하는 입장에서 제일 곤란한 건 낭비가 없으면서도 서비스에 충분한 리소스 확보가 아닐까? 서비스에 어느 정도 리소스가 필요한지, 가용성은 어떻게 확보할 것인지 늘 관심이 클테다. 그리고, 이 모든 과정이 자동화되지 않으면 손이 많이 가리라…

LINE Developer Day 2014에서 이어지는 세션이라고 제목에 “Part 2″가 붙었다. 작년에 Front Proxy를 도입해 로드밸런싱을 구현하고 Cloud로 시스템을 옮겨보겠다고 한 모양이다. 그 연장선 상에 있는 이야기를 하겠다며 발표를 시작했다. 키워드는 HAProxy와 Docker였다. 그리고, 다음 목표는 SDN(내년엔 들을 수 있으려나?).

LINE Game Cloud Architecture 1

HAProxy는 각 서비스 권역 거점(POP)에서 사용자 기기를 대상으로 이뤄지는 통신을 담당한다. POP 사이는 이중화된 전용선을 사용한다(하나는 대서양을 건너고, 하나는 태평양을 건너는 식). 동남아시아는 네트워크 상태가 특히 열악했기 때문에 더 필요했던 것같다. 사용자 기기는 가장 가까운 HAProxy에 붙는데, 이 프록시 서버가 서비스 요청 상태에서 가장 빠른 Docker 서버 인스턴스로 연결해준다.

아래 사진이 LINE Game Cloud의 구조를 잘 보여준다. 역시 Docker는 뜨거운 아이템이라는 것을 실감할 수 있었다. 그림에서는 그저 Back-end Services로 표시되어 있을 뿐이지만, 이 서비스 인스턴스는 모두 Docker에서 실행된다. 더불어 자신의 서비스 인프라에 맞게 잘 관리할 수 있도록 관리도구를 준비하고 모니터링하는 엔지니어링이 얼마나 필요한 것인지도 알 수 있었다. 여기서 주목할 것은 Service Document Editor와 RIAK, Node Agent다.

HAProxy Architecture

사용자 접점을 담당하는 프론트 엔드(HAProxy)와 실제 서비스를 담당하는 백 엔드(Docker 서버 인스턴스)를 분리하면서 백 엔드는 언제든 확장 가능한 구조가 되었다. Docker를 구성하면서 염두에 둔 건 stateless server라고 덧붙였다. 서비스에 상태가 있으면 서버의 로드/언로드마다 문제가 있기 때문이다. 발표자가 내세운 또 다른 가장 큰 장점 중 하나는 L4와 L7 바인딩이 자유로워졌다는 것이다. QA, 개발, 서비스 환경에 일일이 사람 손을 타지 않고 동시 배포가 가능한 환경이 되었다는 것도 강점.

사진에서는 Service Document Editor(줄여서 S.D.E)로 표시된 부분이 관리의 키다(이 부분은 Gall Johan 설명을 담당했다). S.D.E는 Lisp에서 파생된 언어인 Clojure를 사용한다(Lisp의 특성을 계승했다면 꽤나 표현이 자유롭지 않을까?). 처음엔 서버의 정보와 목록만 저장했다고 한다. 그러다가 이 문서대로 서버 구성이 이뤄지면 좋겠다는 생각이 들어(자동화!) 전체 서버 구성을 컨트롤할 수 있도록 환경 설정 정보를 담는 구조로 변경했다고 한다. S.D.E의 설정 정보는 Orchestration 엔진을 거쳐 node agent에서 실제 환경 설정 정보로 변환되어 Docker 인스턴스에 적용된다.

LINE Game Cloud 구성을 위해 빌드/배포 환경도 손봤다.

Build/Deploy Method Change

서비스 인프라 관리에는 kibana, nSight for Docker를 사용했다고 한다(nSight가 뭔지는 잘 모르겠다… 자신들에게 맞도록 손봤다고 들은 것같은데, 정확하지 않다).

다음 개선 계획으로는 SDN을 도입하는 것과 QUIC을 이용하는 서비스란다. QUIC은 올해 안으로 모든 게임 서비스에 적용할 계획이고, 실제로 적용하는 게임들이 있다.

Applying QUIC Protocol on LINE Games

Google Chrome이나 Chromium 웹 브라우저에서 쓸 수 있는 통신 프로토콜인 QUIC은 정말 수작이다. TCP 443이 막혀있는 곳에서도 쓸 수 있어서, 방화벽 정책을 우회해 SSL/TLS 서비스를 제공할 수 있다. 이미 Google은 이 프로토콜을 RFC 표준화하는 작업을 착수했다[1].

LINE이 QUIC을 사용하는 이유는 다른데 있다. 서버 리소스를 많이 차지하는 TCP를 대체할 수 있다는 것이다. (이미 이야기했던) 동남아에서라면 TCP 핸드셰이킹은 부담스러운 일이다. 아래 있는 사진 하나면 왜 굳이 QUIC을 쓰려고 하는지 이해가 갈 듯. 물론, 아무 통신이 없던 클라이언트라면 첫 연결에서는 핸드셰이킹이 발생하는데, 그 이후엔 없다.

QUIC을 쓰는 이유

그리고, 다른 프로토콜과 비교하면 아래 사진과 같은 장점도 있다. 흠… 근데 나는 모르는 내용이… -_-;a

QUIC을 쓰는 이유

기존 게임 소스 코드를 건드리지 않고 최대한 활용하도록 하는 것이 구현 목표중 하나였다고 한다. Chromium 소스를 가져와 수정했다. 현재 QUIC이 적용된 게임은 2 종류라고(근데 까먹음)…

QUIC 기능은 프론트 엔드에서 동작한다. 그래서 QUIC 연결이 TCP 기반 HTTPS 연결을 대체하도록 리버스 프록시가 필요해졌고, 프론트 엔드 구성은 아래 사진과 같아졌다.

QUIC Reverse Proxy

QUIC이 아직 IETF에 정식으로 등록된 프로토콜은 아니고, Chromium에서도 소스 수정이 활발하다고 한다. 아직 안정화가 부족하지는 않을까 싶지만, 자사의 서버와 클라이언트 사이에서만 적용한다면 큰 문제는 없을 듯.

Game Security Response Architecture(AIR)

개인적으로 제일 관심이 많은 세션이었다. 점심 식사 후 우연히 서동필님을 만났는데, 많이 긴장하신 듯 점심을 못먹었다고. ㅋ

사실 안랩에서는 파티션을 사이에 두고 있었지만 대화할 기회가 별로 없었는데, 난 동필님이 무슨 발표를 하는지 무척 궁금했다. 동필님에겐 안랩 이후 어떤 변화가 있었을까? 각설하고…

해외에 서비스하는 LINE 입장에서 다뤄야 할 보안 환경은 녹록치 않다. 우리나라는 루팅한 Android 폰이나 탈옥(jailbreak)한 iOS 기기를 위험하다고 인터넷 뱅킹을 금지하지만 루팅이 하나의 문화처럼 자리잡은 국가도 있고, 사용자 계정을 차단하기 일주일 전에 사용자에게 고지해야 하거나, 고지가 필요없는 곳도 있다. 보안을 위해 단말기에서 통제해야 하는 범위가 어디까지인지 선을 긋기 쉽지 않다. 샌드박스가 기본적으로 적용되는 모바일 운영체제 환경에서 보안 기능을 구현하는 것도 난제다. 보통 보안 기능은 배포되는 앱의 보안 모듈로 존재하는데, 모듈을 우회해 다른 접근을 시도하는 악성 행위들은 어떻게 차단해야 할까?

이런 제약조건 하에 게임 어뷰징을 차단하고자 LINE이 선택한 방식은 간접적인 통제를 실행하는 것이었는데, 앱의 내부를 들여다 볼 수 없도록 패킹하고, 설령 패킹을 해제해도 알아볼 수 없도록 코드 난독화(code obfuscation)하는 것, 그리고 클라이언트의 이상 행동을 모니터하고 어뷰징으로 예상되는 이상 징후를 포착할 수 있도록 빅 데이터를 이용한 어뷰징 탐지이다. 각 기술은 각각 놓고 볼 때 특별해 보이지 않는다. 그렇지만 발표를 들으면서 각 기술은 그저 그런 기술을 가져다 쓴 것이 아니란 생각이 들었으나… 내가 개발자는 아닌 관계로 깊이있는 설명은 못하겠다.

AIR Workflow

AirPack

AirPack은 Android에 적용한 난독화 기술이다. 이 기술을 구현하기 위해 Java로 작성된 바이트코드, C/C++/어셈블리로 작성되는 라이브러리, C#으로 작성되는 DLL 파일들을 분석하고, 대응할 수 있도록 구현했다. 이미지와 같이 정적인 파일들은 난독화 대상에서 제외했다. 앞으로는 난독화 모듈들의 상호 의존성을 높여서 분석하기 더 어렵게 만들것이라 한다.

Obuscation Orchestration

AirAmor

Android, iOS 환경에서 실행되는 개발용 프레임워크로 구성되어 있어 게임을 개발할 때 가져다 쓰면 된다(내겐 안랩의 HackShield가 비슷한 제품이지 않을까 싶다. 달라도 너무 다른가? -_-;a). AirAmor는 사용자의 운영 환경을 탐지하고 탐지된 환경에 맞춰 앱에서 발생하는 주요 이벤트를 모니터하고, 발생한 이벤트를 정규화된 로그로 작성한다. 작성된 로그는 AirBorne으로 전송한다. 그리고 설명엔 없었지만, 아마도 어뷰징 단말기에 대해 뭔가 차단 기능도 할 것같다.

image

AirBorne

AirBorne은 AirAmor로부터 수집된 데이터를 받아 처리하는 빅 데이터 분석 시스템이다. 위에서 걸었던 링크와 함께 이 기사도 함께 보시라: [유재석의 데이터 인사이트] (25) 라인플러스 게임보안개발실…스파크+메소스로 10분 당 15TB 처리. 이 시스템을 구성하면서 이전에 하루 데이터 분석에 필요한 시간이 920분에서 20분으로 줄었다고 한다.

AirAbuseTracker

어뷰징을 트래킹하고 정보가시성을 제공하는 시스템으로만 이해했다. 하나의 게임에서 어뷰징 징후가 포착되면 다른 게임에서도 유사한 패턴이 보일 가능성이 높다고 한다. 어뷰징 가능성이 높은 사용자와 기기를 계속 추적한다고… -_-;a 덧붙여 D3.js를 사용했다고 들었다(요즘 핫하다는…). 모든 데이터는 드릴-다운 방식으로 볼수 있다고 한다.

Air AbuseTracker

장기적으로는 Air 서비스를 구성한다는데, 어떤 의미인지 실감이 나질 않는다.

정확하게는 모르겠지만 Air를 확장하면 FDS(Fruad Detection System, 이상 금융거래 탐지)로 발전할 수 있지 않을까 싶다.

개인적으로는 제일 관심이 없었던 딴짓 세션. 키워드는 하드코어 게임, IP, 포화상태… 처음엔 Internet Protocol인 줄 알았는데, 지적 재산권을 의미하는 것이었다.

내겐 앉아있는게 하드코어였… 발표하신 Lungtu의 CPO Liu Chen님, 미안합니다. ㅠㅠ

Collaborative Mindset of Security (and Others)

기대하지 않았다가 즐거웠던 세션. LINE 메신저를 대상으로 진행했던 보안 강화 프로젝트 2건과 버그 바운티 에피소드.

메신저의 보안을 강화하기 위해 2개의 프로젝트가 있었다고 한다. 하나는 단말기 수준에서 메시지의 안전한 삭제에 관한 것이고, 또 다른 하나는 종단 간 통신 암호화(LINE에서는 Letter Sealing이라 부른다).

메시지의 안전한 삭제는 메시지를 삭제하기 전에 메시지 필드를 더미값으로 채우고 파일 메타데이터를 날려버리는 식으로 진행되었고, 종단 간 암호화는 각 단말기에 메신저 설치 시 생성되는 비대칭 키를 이용한 메시지 암호화 키 전송 및 적용에 관한 것이었다. 아래 그림은 Letter Sealing을 소개하며 나온 기존 전자서명 및 메시지 암호화에 관한 슬라이드다.

Typical encryption sequeces & trustibility of CA

늘 그렇듯이, 비대칭 키 방식을 쓰는 경우 CA를 믿을 수 있어야 한다. 그런데, 우리의 정서는 CA를 믿나? 아마도 국정원의 해킹 사건을 아는 사람이라면 쉽게 믿지 못할 것이다. LINE은 이런 점을 우려했는지, 타원곡선에 기초한 디피-헬만(ECDH) 알고리즘을 사용하면서 CA를 두지 않는 방식을 선택했다. 어쩌면 PGP와 비슷한 메커니즘인지도 모르겠다. ECDH는 RSA보다 키 길이가 짧아도 보안 강도가 우수해서 스마트폰 환경에서도 부담을 덜 주는 훌륭한 선택이기도 하다. 더 효율적인데 RSA를 더 많이 사용하는 이유는 뭘까?

UPDATE(2015/11/25): Letter Sealing은 기본 설정이 *사용 안 함*이므로 사용자가 직접 설정을 변경해줘야 한다. 그리고, 현재는 텍스트에만 적용된다. 이미지, 동영상은 제외된다는 의미.

image

발표를 듣다가 의문도 생겼다. 수사기관의 감청/도청 영장이 있을 때 어떻게 대응할런지? 의외로 답은 싱거웠는데, 라인이 일본회사라 우리나라의 사법권이 미치지 않는다는… :-* 그리고, 메시지 암호화 키는 메시지를 전송할 때마다 바꾼다나… (믿어야 하나?)

그리고, 보안 엔지니어와 개발 엔지니어의 역할에 대한 이야기가 있었다. (나도 겪는 일이기지만) 보안 관련 업무를 담당하는 입장에서는 무조건 위협에 노출되지 않기를 바라기 때문에 취약성이 발견되면 즉시 해결되기를 원한다. 그렇지만 개발하는 입장에서는 모든 취약성이 발생한다고 보기도 어렵고, 다른 개발 우선순위에 밀리기 쉽다. 현실에서 적정선은 어디일까?

Round-Table Discussion

마지막으로는 미처 참가자들이 물어보지 못한 질문을 받을 수 있게 모든 발표자들을 한데모아 질문을 받았다. 분위기는 화기애애했고, 내가 듣지 못한 세션에서 무엇이 이슈인지 알 수 있었다. 플랫폼 관련 트랙에서는 무언가 LINE이 메시지의 비동기 처리를 하는데 사용할 목적으로 작성한 프레임워크가 있는 듯했다. 이걸 오픈소스로 제공하겠다는 이야기가 있었는데, 어떻게 될지는 잘 모르겠음…


모든 시간을 마친 후, Developer’s Dinner Party가 있었고, 1등 뉴 맥북, 2등 플레이스테이션4, 3등 아이워치, 4등 기계식 키보드(어디껀지는 기억 안 남) 추첨이 있었다. 뽑기운이 내게 있을리가…

다 듣고 나니 하… 소화하기 힘들다… -_-

[1] QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2, QUIC Loss Recovery And Congestion Control