네이버 라인은 왜 카카오톡보다 병목현상이 적을까?

실시간
뉴스

솔루션

네이버 라인은 왜 카카오톡보다 병목현상이 적을까?

디지털데일리 발행일 2012-05-14 08:06:51

이민형 기자

URL복사

[IT전문 미디어 블로그=딜라이트닷넷]

지난 달 28일 모바일메신저 카카오톡이 4시간동안 먹통이 된 적이 있었습니다. 카카오톡이 등장한 2010년 3월 이후 가장 오랫동안 서비스가 중단된 상황이었습니다.

같은 달 30일 카카오는 “IDC 전력계통 문제로 서비스가 4시간여 동안 중단됐다”며 “이번 장애 원인은 트래픽 과부하로 인한 전력공급에 대한 문제나, 서버군에 장애가 있었던 것은 아니라는 점은 분명히 말씀드린다”고 공식 자료를 배포했습니다.

이번의 서비스장애는 분명 카카오톡의 문제가 아니라 서버의 문제로 귀결되는 것처럼 보입니다. 하지만 사실 카카오톡의 장애는 이번이 처음이 아닙니다. 지금까지 약 4차례의 서버 장애를 경험했습니다.

카카오톡 장애로 인해 반사이익을 얻은 곳은 네이버 라인과 틱톡입니다. 두 서비스는 카카오톡과 같은 성격의 대체재입니다.

카카오톡, 네이버 라인, 틱톡 이 3개의 서비스를 모두 사용해 본 사람들은 카카오톡보다 네이버 라인이나 틱톡의 메시지 전송속도가 빠른 것을 느낄 것입니다.

다 같은 모바일메신저인데 전송속도에 차이가 있는 것은 서버 성능의 차이도 있겠지만, 애플리케이션의 아키텍쳐도 영향을 끼치지요.

이번 포스팅에서는 네이버재팬(네이버 라인은 네이버재팬이 개발)이 라인의 속도를 높이기 위해 어떠한 고민을 했는지 알아보도록 하겠습니다.

(굳이 네이버 라인을 꼽은 이유는 네이버재팬이 메신저 개발업체 중 유일하게 소스코드를 공개했기 때문입니다.)

네이버 라인의 시작부터 설명을 해야할 것 같습니다.

라인은 지난해 6월 일본 시장에 처음 등장했습니다. NHN 이해진 의장이 직접 프로젝트팀을 꾸려 선보인 모바일메신저로, 당초 NHN이 서비스하고 있던 네이버톡과 달리 인트턴트 채팅에만 초점을 맞췄습니다. 이후 네이버재팬은 모바일인터넷전화(m-VoIP)를 추가하며(2011년 10월) 사용자를 지속적으로 확보했습니다.

현재 라인은 전 세계 가입자수 3000만 명을 돌파하며 카카오톡을 추격하고 있는 중입니다.

네이버재팬 엔지니어 블로그(http://tech.naver.jp/blog/?p=1420)에 따르면 라인은 NoSQL DBMS(데이터베이스관리시스템)기반으로 만들어졌습니다.

NoSQL은 관계형 DBMS와 달리 비관계형 DBMS입니다. 때문에 대규모의 데이터를 유연하게 처리할 수 있는 특징이 있습니다.

관계형 DBMS로 모바일메신저나 소셜네트워크서비스(SNS)를 만들 경우, 새로운 업데이트가 있을 때 마다 일관성과 유효성을 체크하기 때문에 병목현상이 생길 가능성이 있습니다.

메신저 서비스에서 병목현상이란 새로운 메시지가 다량으로 송수신될 때, DBMS가 버티지 못한다는 의미입니다. 다량의 메시지를 서버가 감당하지 못한다고 해석할 수 있습니다.

이 때문에 트위터나 페이스북은 일찍부터 NoSQL을 사용하고 있습니다. 새로운 데이터(게시물)가 업데이트될 때 읽고, 쓰는 비율이 5:5가 될지라도 서비스가 유지될 수 있기 때문입니다.

다시 라인으로 돌아가면 당초 네이버재팬에서는 라인의 아키텍쳐로 레디스(Redis)를 사용했습니다. 레디스는 NoSQL 종류 중 하나입니다.

네이버재팬은 동기, 비동기가 자유롭고, 슬레이 복제도 가능하다는 레디스의 장점을 적극 살렸습니다. 그러나 레디스의 단점인 데이터 저장공간의 확장이 힘들다는 것을 간과했지요.

처음 네이버재팬에서는 라인의 사용자가 많아봤자 100만명이 안될 것이라고 예상했다고 합니다. 그러나 반년 만에 500만명의 사용자가 넘어서면서 기존에 쓰던 레디스 클러스터를 확장할 것인지, 아키텍쳐를 뜯어고칠 것인지를 고민하게 됐습니다.

그 과정에서 네이버재팬은 새로운 NoSQL을 사용하기로 결정하고 후보로 HBase, 카산드라, 몽고DB(MongoDB) 중 하나를 선택하기로 합니다. 선택기준은 모바일메신저에서 가장 중요한 세가지, 즉 확장성과 가용성, 비용이었습니다.

네이버재팬은 이 중 하둡 파일 시스템 위에서 빠르게 동작할 수 있는 HBase를 선택해 마이그레이션합니다. 데이터 저장과 가용성부분에서 카산드라가 다른 두가지 NoSQL을 제압했지만, 전체적인 요구사항을 HBase가 만족스러웠기 때문이라고 합니다.

라인은 레디스에서 HBase로 마이그레이션한 이후 더 빨라졌습니다. 클러스터를 공유할 수 있을 뿐더러 읽고 쓰는 것에 대한 균형 조정 기능도 갖추고 있어 한꺼번에 많은 데이터가 들어오더라도 해결할 수 있기 때문입니다.

기존 서비스의 한계를 클라우드와 오픈소스로 해결하고, 이 과정을 공개한 것은 동종업계에도 좋은 영향을 끼칠 것으로 보입니다.

[이민형 기자 블로그=인터넷 일상다반사]