세션 저장소 TripleS

NHN Business Platform 웹플랫폼개발랩 조규만

TripleS는 유선에서 무선으로의 환경 변화에 따라 대두된 네트워크상의 최적화 문제를 해결하고자 시작된 플랫폼입니다. TripleS는 네트워크상의 데이터에 초점을 맞추었습니다. 결과적으론 TripleS 적용을 통해 쿠키의 제약성에서 벗어날 수 있어 인터넷 웹 서비스를 더욱 빠르게 그리고 여러 서비스들간의 데이터 공유를 가능하게 했습니다.

TripleS

TripleS(Shared Session System)는 세션 데이터같이 크지 않은 데이터를 안정적이면서 빠르게 저장할 수 있도록 만들어진 분산 키-값(Key-Value) 저장소다. 사용자 세션 아이디인 UID를 키로 하고, 세션 데이터를 값으로 해서 저장할 수 있다. 저장한 데이터에 대해서는 세 개의 복제본이 유지되도록 하고 있기 때문에 TripleS에 장애가 발생한다 하더라도 애플리케이션 서버들은 안정적으로 데이터를 공유할 수 있다.

2012년 11월 현재, TripleS를 사용하고 있는 곳은 다음과 같다.

• 통합검색에서 최근 검색어, 내 검색어 저장
• 통합검색에서 검색어 하이라이트 반영 여부 저장
• 블로그, 카페, 지식인 공유 세션 데이터 저장
• 게임서비스에서 사용자 세션 저장
• Link 앱에서 사용 히스토리 저장
• Line Play에서 사용자 세션 및 공유 데이터 저장

TripleS를 개발한 이유

TripleS를 개발한 이유는 WAS(Web Application Server)들 간의 세션 데이터 공유 때문이다. HTTP 프로토콜은 Stateless 프로토콜이기 때문에 Stateful 효과를 만들기 위하여 HTTP 쿠키(Cookie)나 HTTP 세션(Session)을 사용하게 된다. 그러나 HTTP 세션은 NHN같이 대규모의 WAS를 운영하는 곳에서는 사용하기 적합하지 않다. 그래서 HTTP 쿠키를 사용하게 되는데, 쿠키의 단점은 매 HTTP 요청마다 쿠키를 실어 보내야 해서 쿠키가 커질 경우 네트워크 트래픽에 부담을 줄 수 있다는 것이다. 유선 네트워크에서 이 쿠키 크기는 별 문제가 되지 않지만 3G 모바일 네트워크에서 쿠키 크기는 성능에 매우 좋지 않은 영향을 미치게 된다.

<그림 1>은 3G 네트워크 환경에서 데이터 크기를 다르게 했을 때 응답 시간을 측정한 것이다. 그래프에서 알 수 있듯이 데이터 크기가 일정량 이상 증가하면 응답 대기 시간이 무한정 길어지는 일이 발생한다.

그림 1 3G에서 데이터 크기에 따른 응답시간 변화

그러나 쿠키 사용은 3G 모바일 네트워크에서만 문제가 되는 것은 아니다. 쿠키에는 데이터 개수와 데이터 크기에 대한 제한이 있기 때문이다. 쿠키 표준안인 RFC 2109에 따르면 쿠키는 300개까지 만들 수 있으며, 최대 크기는 4,096바이트이고, 하나의 호스트나 도메인에서 최대 20개까지 만들 수 있다. 그러나 브라우저들이 이 표준안을 지원하는 것은 아니다. 대부분의 브라우저는 표준안보다 더 적은 개수의 쿠키만을 지원한다. <표 1>에서 브라우저별 쿠키 지원 상황을 확인할 수 있다.

표 1 브라우저별 쿠키 제한

이런 쿠키의 제약 때문에 세션 처리를 위해 쿠키만 사용하는 것은 모바일 웹뿐만 아니라 유선 웹에서도 제약이 되는 것이다. 그래서 세션 정보를 키-값 형태로 저장할 수 있는 플랫폼이 필요했다. 이러한 이유로 TripleS가 만들어지게 된다.

꼭 쿠키에 담아야 하는 데이터만 쿠키에 담도록 하고 다른 세션 데이터들은 TripleS에 저장하도록 할 수 있다. TripleS는 애플리케이션 서버와 같은 로컬 네트워크를 사용하기 때문에 원격에 있더라도 빠른 읽기/쓰기가 가능하다.

TripleS 데이터모델과 API

TripleS는 앞서 밝혔듯이 키-값 저장소다. 값으로 저장할 수 있는 데이터의 형식은 Java 라이브러리를 사용할 때에는 Serializable 인터페이스를 구현하고 있는 객체이고, C/C++ 라이브러리를 사용할 때에는 문자열만 사용할 수 있다.

TripleS는 사용자의 세션 정보를 저장할 수 있도록 만들어진 것이기 때문에, TripleS는 일반적인 키-값 저장소와는 다른 키 체계를 사용하고 있다.

TripleS의 데이터 모델은 세션키 값에 해당할 수 있는 UID 값과 UID 내의 하위 그룹핑을 위한 SVC_CODE 값이 있으며 SVC_CODE 아래 저장되는 KEY_VALUE 구조다. UID와 SVC_CODE, KEY는 문자열이다. VALUE는 문자 또는 Java 객체(object)다. 간단하게 실 서비스상에서 매핑하여 쓰는 것을 설명하자면 UID로는 많은 경우 회원 ID를 사용하고 있고, SVC_CODE는 ‘blog’나 ‘cafe’와 같이 NHN의 서비스 명을 사용하고 있다. KEY_VALUE는 서비스에서 사용되는 쿠키 또는 서비스용 데이터에 해당한다.

TripleS에서는 이 UID를 이용하여 데이터를 저장할 때 데이터 분산 위치를 판별한다. 앞서 밝혔듯이 이 UID는 회원 ID로 사용할 수 있다.

TripleS가 제공하는 API는 get, set, replace, remove이다. 적은 것 같지만 이 네 가지의 API만으로도 충분하다고 생각한다.

TripleS 성능

TripleS 의 가장 큰 장점 두 가지는 데이터 저장/조회를 빠르게 할 수 있다는 것과 저장 공간을 쉽게 수평 확장시킬 수 있다는 것이다.

TripleS는 저장소(TripleS-Storage)로 고속 분산 저장 시스템인 nBase를 사용해 빠른 성능과 확장성을 만족시키고 있다. 2012년 11월 현재 기본 구성(nBase 3개 노드 구성)을 한 상태의 TripleS의 TPS는 1만~1만2천이다. 대부분의 응답시간은 10ms 이하이다.

여타의 2차 캐시 시스템과 다른 점은 데이터가 영구 저장된다는 것이다. 때문에 데이터 유실에 대한 고려가 필요 없다.

TripleS 구조

TripleS를 설계할 때 가장 주안점을 둔 것은 다음 세 가지이다.

• 빠른 읽기/쓰기 속도
• 매우 고른 성능
• 데이터 유실 방지

데이터 크기에 따라 다르겠지만 처음 설계할 때부터 하나의 세션 데이터를 읽는데 10ms 이내가 되어야 한다고 기준을 정했다. 만약 이보다 더 오래 걸릴 경우에는 사용자 체감 성능에 영향을 줄 수 있을 것이라고 판단했기 때문이다. 또한 매우 고른 성능을 보이도록 하는 것도 중요했다. WAS에 HTTP 요청이 인입될 때마다 WAS는 해당 HTTP 요청의 세션 ID에 대한 데이터를 TripleS에 요청할 것이기 때문에, TripleS는 매우 빈번한 요청을 처리할 수 있어야 하고, 균일한 좋은 성능을 낼 수 있도록 하는 것이 필요했다. 때문에 TripleS는 세션 데이터 저장을 위하여 nBase를 사용했다. nBase는 매우 빠른 처리 성능을 보일 뿐 아니라, 용량 확대가 용이하기 때문이다. 만약 TripleS의 용량을 확대해야 하는 경우가 발생한다면 nBase에서 노드를 추가하는 방식으로 손쉽게 용량 확장을 할 수 있다.

또한 데이터가 유실되지 않도록 하는 것도 중요했다. 때문에 세션 데이터는 3개의 복제본이 유지되도록 했다. <그림 2>에서 TripleS의 간략한 구조를 볼 수 있다.

그림 2 TripleS 구조

애플리케이션 서버는 TripleS에 접근하기 위하여 TripleS 클라이언트 라이브러리를 사용해야 한다. 그리고 TripleS는 수평 확장이 가능한데, 각 TripleS 노드의 동작 상태를 파악하기 위하여 ZooKeeper를 사용한다.

TripleS 클라이언트 라이브러리

TripleS는 Java와 C 라이브러리를 제공하고 있다. TripleS 클라이언트 라이브러리는 TripleS Storage 서버에 장애가 발생하면 자동으로 정상적인 TripleS Storage를 찾아 연결하는 기능을 가지고 있다. 이를 위하여 항상 연결 중인 TripleS Storage의 상태를 확인한다.

또한 ZooKeeper와 연동하여 TripleS Storage의 추가/제거 사실을 알 수 있다. 때문에 동작 중에 TripleS Storage가 추가 되거나 제거되더라도, TripleS를 사용하는 애플리케이션 서버는 재가동하지 않아도 새로 구성된 TripleS Stroage를 사용할 수 있다.

그림 3 TripleS-Storage 동적 추가/삭제

TripleS Storage

TripleS Storage는 nBase이다. 물론 nBase 대신 다른 저장소를 사용할 수도 있지만, TripleS의 저장 속도와 안정성은 상당 부분 nBase에 기대고 있는 상황이다.

TripleS-admin

TripleS Storage 부하 상태 등을 모니터링할 수 있다. 웹 브라우저에서 TripleS-admin에 연결하면 전체 TripleS 사용 상태를 그래프 같은 시각적인 정보로 알 수 있기 때문에 TripleS를 사용할 때는 모니터링이 매우 용이하다.

TripleS의 장애 대응

TripleS에는 전체 시스템의 일부에 장애가 발생해도 어떤 기능이나 성능에 영향이 발생하지 않도록 만들어졌다.

그림 4 TripleS-Storage 장애 대응 과정

연결 중인 TripleS-Storage에 장애가 발생했을 때는 다음과 같은 과정을 통하여 TripleS 클라이언트 라이브러리는 정상 동작하는 TripleS-Storage를 찾아 연결한다.

1. TripleS 클라이언트 라이브러리는 TripleS-Storage에 대한 연결이 끊어졌을 경우 connection-fail 수치를 1 증가시킨다.
2. TripleS 클라이언트 라이브러리는 이 connecton-fail 수치가 일정 시간 내에 connection-fail 수치가 3 이상 이르게 되면, 해당 TripleS-Storage를 사용하는 것이 적합하지 않다고 판단한다.
3. TripleS는 유효하지 않은 TripleS-Storage 를 제외한 연결되어 있는 TripleS-Storage 로 재전송 하게 된다. 이후 유효하지 않는 TripleS-Storage는 유효한 상태가 되기 전까진 서비스 요청이 보내지지 않는다.
4. (2) 과정에서 연결 상태가 정상적이지 않다고 판단한 TripleS-Storage에 대해서는 일정 주기 단위로 상태를 파악하여, 정상 동작함이 확인되면 다시 연결할 수 있도록 한다.

마치며

TripleS의 처음 시작은 모바일 환경에서 쿠키 사이즈를 줄이는 부분에 집중되었으나 실 서비스에 적용하면서 쿠키나 세션을 저장하는 용도 외에 무수한 서비스나 서버간의 공유 데이터를 저장하는 공간으로 활용함으로써 데이터의 공유와 효율성을 높일 수 있었다.

한 명의 사용자가 여러 개의 디바이스(PC, 스마트폰, TV 등)를 사용할 때 사용 이력을 TripleS에 저장하면 디바이스간의 N-스크린 효과를 볼 수 있다. 즉 사용하던 기기나 브라우저를 변경한다 하더라도 항상 사용자가 끊김없이 서비스를 연속해서 받을 수 있도록 할 수 있다.