Evernote가 가진 기술과 기업 문화

Evernote의 아키텍처와 그들의 기업 문화에 대해 정리한걸 공유합니다. 비슷한 류의 서비스 개발을 구상하고 계시다면 Evernote 아키텍처가 좋은 힌트를 제공할 것입니다.

서비스 규모

CEO : 필 리빈(Phil Libin).
직원수 : 230명.
개발자 : 175명.
요청 건수 : 하루에 1억 5천만 요청(1억5천만 RPD).
회원 수 : 3,800만(2012.08).
프리미엄 계정수 : 100만(2012.08).
노트파일 수 : 10억개.
DropBox와 더불어 Freemium 전략이 성공하는 대표적인 서비스.

아키텍처

Evernote의 아키텍처는 노트의 작성과 보관을 목적으로 설계된 소프트웨어 서비스의 조합이다. 노트는 형식변형이 가능한 텍스트, 웹페이지 전체/일부, 사진, 음성 메모, 수기노트 등이 될 수 있다. 또한 노트에 파일 첨부도 가능하다. 노트는 폴더의 정렬, 태깅, 주석, 편집, 코멘트 추가, 검색등도 지원하고 있다. Evernote는 다양한 OS 플랫폼(Android, Mac OS X, iOS, Microsoft Windows, WebOS) 지원, 온라인 동기화, 백업 서비스도 제공한다. 이런 서비스의 특성에 맞게 아키텍처가 구성되어 있는듯 하다. 그리고 무료 온라인 사용자의 업로드는 월 60M로 제한되지만, 1년에 $45를 지불하는 프리미엄 사용자는 자장용량이 1000MB까지 커진다. 따라서, 이익을 확보하기 위해서는 아키텍처는 고액의 비용을 발생시키지 않고 대량의 데이터를 저장해야한다는 대의 명제가 있는 셈이다.

1. 데이터 센터

Evernote는 California, Santa Clara의 데이터 센터에서 2개의 전용 플로어를 가지고 있다. 그리고 클라우드를 사용한다면 Evernote의 비즈니스 모델을 적용하는데 저렴한 비용으로 충분히 처리할 능력과 저장 공간을 제공할 수 없다. 그래서 서비스의 특성상 극단적인 피크가 오지않기 때문에 코로케이션방식의 사이트 운영은 합리적이며 VM을 운영하는 것은 상당한 신뢰성을 가진다고 판단했다.

2. 네트워크

Evernote의 실질적인 모든 트래픽은 www.evernote.com 도메인의 HTTPS 프로토콜에서 이루어진다. 여기에는 WEB 처리 뿐만 아니라 Thrift 기반의 API를 사용하는 클라이언트 동기화도 포함된다. 그 결과, 하루 1억 5천만 HTTPS 요청이 발생하고, 피크 트래픽이 250Mbps가 된다.(불행이도 야간 운영팀에게 데일리 피크는 태평양 시간으로 오전 6시 30분에 일어난다.) 우리는 BGP를 사용하여 트래픽을 완벽하게 분리된 두 개의 네트워크에 배분하고 있다. 2개의 네트워크는 주공급업체는 NTT America, 그리고 보조는 level 3다. 이것은 Vyatta의 방화벽을 통해 필터링 된 후 이번 1월에 새로 배포된 A10로드 밸런서(스위치)에 의해 분배된다. 이를 통해 이전의 로드 밸런서에서 SSL 통신 성능의 한계를 극복할 수 있었다. 우리는 하나의 AX 2500과 장애 조치 서버를 사용해 현재의 트래픽을 충당 할 수 있었지만, 미래의 성장에 대비해 쿨러스터 준비 환경에서 N+1 구성을 시험하려하고 있다.

3. 샤드

1) 과거의 샤드 아키텍처

Evernote는 소셜 네트워크가 아니라 개인 메모 서비스이므로 개인 사용자 데이터를 별도의 샤드로 분할하여 저장함으로써 선형 확장성을 실현하는 것이 비교적 쉽다는 강점을 가지고 있다. Evernote 서비스의 코어는 "Shards"라는 서버 군이다. "Shards" 서버의 각 쌍은 두 개의 서로 다른 가상 머신상에서 움직이고 있고 각각의 샤드는 100,000명의 Evernote사용자의 데이터와 트래픽을 처리하고 있다. 우리는 과거에 900만명 정도의 사용자가 있었으므로, 약 90개의 샤드가 필요하다.

물리적으로, 하나의 샤드는 두개의 SuperMicro 박스로 구성되어 있으며, 그 안에는 각각 2개의 쿼드 코어 인텔 프로세서(L5630 processors)와 많은 RAM(48GB)과, RAID로 미러링된 Seagate 엔터프라이즈 스토리지를 가지고 있다. 각각의 박스에서, 우리는 2개의 Xen 가상 머신(VM) 관리하에 Debian Linux가 호스팅되고 있다. 박스의 기본 VM에서는 핵심 애플리케이션 스택이 구동되고 있다 : Debian + Java6 + Tomcat + Hibernate + Stripes + GWT + MySQL(메타 데이터) + 로컬 계층 파일 시스템(파일 데이터)이 그들이다.

메타 데이터를 저장하는 MySQL은 300GB인 시게이트의 Cheetah 하드 드라이브를 RAID-1으로 운영하고 있고, 3TB의 Seagate® Constellation 드라이버는 7200 rpm이며 RAID-10으로 운영되며 여기에는 대용량 파일과 사용자별 루신 인덱스값이 여러 파티션별로 분할되어 저장된다. 하나의 박스 안에 주 VM의 모든 사용자 데이터는 DRBD를 사용하여 다른 박스의 보조 VM과 동기 복제가 이루어지고 있다. 즉 사용자의 모든 데이터는 적어도 4개의 다른 스토리지와 2개의 물리적 서버, 게다가 매일밤 백업과 함게 관리되는 것을 의미한다. 만약 서버에 문제가 생기면 기본 VM 서비스는 다른 서버의 보조 VM가 맡아서 운영하며 Heartbeat를 통해 다운타임을 최소화하게 된다.

각각의 사용자 데이터는 완전히 하나의 가상 서버로 통합되어 있기 때문에 각각의 샤드는 다른 샤드와 통신을 하지않고 독립적으로 운영될 수 있다. 이렇게 하면 하나의 샤드에 장애가 발생하더라도 다른 샤드에는 영향을 주지 않도록 되어 있다. 사용자와 샤드를 연결하는 데 필요한 작업은 대부분 로드 로드밸런서가 맡고 있다. 로드 밸런서는 이를 위해 URL 및 쿠키에서 해당 샤드 정보를 찾기 위한 규칙들을 가지고 있다.

그리고 각 서버의 비용은 약 만달러, 소비 전력은 각 373와트 정도이며, 사용자당 0.1달러, 3.7밀리와트 정도이다.

2) 새로운 샤드 아키텍처

새로운 "Shards"는 과거의 10개의 4U서버를 갖춘 랙에서 4개의 4U 대용량 파일 저장 서버와 14개의 1U 메타데이터 + 애플리케이션용 샤드가 혼합된 랙으로 교체된다. 1U 샤드에서는 더욱 심플한 두대의 가상 머신이 운영된다. 그 가상머신에는 300GB의 Intel 320 SSD로 구성된 단일 RAID-5상에 단일 파티션을 사용한다. 두 파티션은 DRBD로 복제되며 VM이미지는 한번에 한 서버에서만 운영된다. SSD 드라이버는 IO 처리량과 수명(쓰기 내구성)을 증가시키기 위해 80%까지만 사용하고 나머진 예비 공간으로 한다.

DRBD 복제가 가상의 멀티 드라이버 오류를 커버해 주고 리빌딩(RAID 구성) 시간이 짧기 때문에 우리는 추가 15%의 성능 손실을 방지하기 위해서 RAID-6의 사용보다 각 박스에 여분의 SSD를 준비했다. 그리고 대량의 리소스 파일 저장소를 로컬 디스크 대신에 대용량 RAID-6 파일 시스템이 가동중인 이중화된 WebDAV 서버 풀의 주 서버를 사용하고 있다.

메타 데이터 트랜젝션이 완료되기 전에 새 리소스 파일이 에버노트에 추가될때마다, 우리의 어플리케이션이 동일한 랙의 두개의 서로다른 파일 서버에 해당 파일의 복사본을 동기적으로 기록한다. 오프사이트 이중화는 앱에 의해 처리되는데, 그 앱은 비동기 백그라운드 쓰레드를 통해 오프사이트 WebDAV 서버에 각각의 새로운 파일을 복제시킨다.

결과적으로 새로운 샤드 아키텍처를 구성함으로 인해, 적어도 4년동안은 샤드마다 200,000 사용자를 처리하기에 충분한 IO처리량과 스토리지를 확보하게 되었다. 샤드 14대와 파일 서버 4대의 랙은 약 13만 5천 달러의 비용과 3,900와트의 전력이 소모되어 사용자당 0.05달러의 비용과 1.4밀리 와트의 소비전력을 가진다. 따라서 주 서버에 관해서는 미래에 필요한 서버 수 및 서버 운영에 필요한 전력 소비를 60%정도 줄일 수 있었다. 그리고 다른 서비스 구성 요소(전원, 라우터, 부하 분산, 이미지 처리 서버 등)에서의 전력 소비도 고려하면 이전 아키텍처와 비교하여 전체에서는 한 사용자 당 50%의 전력 소비 절감에 해당한다고 추측했다.

4. 사용자 정보 저장

거대한 볼륨의 대부분 데이터는 위의 첫번째 그림인 Evernote 전체 아키텍처 그림에서 싱글 NoteStore라는 샤드에 저장되어 있다. 그러나 그 샤드는 UserStore라는 회원 데이터베이스(MySQL)을 싱글 마스터로 공유하고, 각각의 사용자 계정에 대한 작은 정보, 즉, 아이디, MD5 패스워드, 사용자 샤드 ID 등이 저장되어 있다. 이 데이터베이스는 RAM에 들어달만큼 작지만, 우리는 높은 중복 실현을 위해 RAID 미러링, DRBD에 의한 보조 시스템에 복제, 매일 밤 백업을 동일한 조합으로 가져간다.

CREATE TABLE notebooks (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
name varchar(100) COLLATE utf8_bin NOT NULL,
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE notes (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
notebook_id int UNSIGNED NOT NULL,
title varchar(255) NOT NULL,
...
FOREIGN KEY (notebook_id) REFERENCES notebooks(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Evernote에서는 RDB의 ACID의 장점을 끌고 가면서 Scale Out를 유지하는 방법으로 테이블 단위(테이블 칼럼에 Shardid(guid)를 두어서 - hash, userid, notebook_id 등)로 회원별, 큰텐츠별 메타 데이터를 DB 분산해서 관리하면 NoSQL의 장점을 어느 정도 커버할 수 있었다. 자세한 내용은 여기를 참조.

5. AIR 프로세서

노트의 이미지에 포함된 단어를 검색할 수 있도록 하기 위해 매일 새로운 이미지를 처리하는데 28개의 서버풀에서 8코어 CPU를 사용하고 있다. 처리량이 많은 날은 130만에서 140만정도의 이미지를 변환하고 있다. 현재는 이러한 Linux 및 Windows를 조합하여 처리하고 있지만, 이달 말에 모든것을 Debian으로 통일해서 기존의 문제가 많은 레거시 종속성을 제거하고자 한다. 이들 서버는 우리의 R&D팀이 개발한 소프트웨어인 Advanced Imaging and Recognition(AIR)의 파이프라인 형태로 운영되고 있다. 이 소프트웨어는 각 이미지를 정리한 다음 단어의 영역을 인식하고 그 다음 추측 기능이 있는 여러 인식 엔진을 적용하여 각 단어 영역에서 해석 가능한 단어의 가중치 목록을 생성한다. 우리의 전문팀이 개발한 이 인식 엔진은 필기 인식 엔진과 우리가 아는 최상의 상용 파트너 라이센스를 받은 기술이 포함되어 있다.

인덱싱 시스템

Evernote 인덱싱 시스템은 텍스트에서 미디어 파일까지 검색 할 수 있도록 설계되어 어떠한 정보도 검색할 수 있다. 현재는 image/PDF 및 디지털 잉크 문서까지 가능하며 다른종류의 미디어 타입도 확장해 지원할 수 있도록 준비하고 있다. 생성된 Index는 인식된 단어, 대체 맞춤법, 관련 신뢰 수준, 위치 정보를 포함한 XML 또는 PDF 문서 형식으로 배포된다.

인덱싱 시스템은 이중화된 Debian64 전용 서버 군에서 구현되었는데, 그 서버들은 AMP processor와 복수(일반적으로 서버의 CPU 코어와 동수)의 ENRS 프로세스가 실행되고 있다. ENRS(EN Recognition Server)는 Java6 웹 서버 어플리케이션에서 래핑된 네이티브 라이브러리 군으로 구현되어 있다. 현재는 2개의 컴포넌트인 AIR와 ANR을 제공하고 있다. AIR는 다양한 이미지 파일과 PDF를 취급하고 있고, ANR은 디지털 잉크 문서를 취급한다. AMP는 HTTP REST API에서 서버와 통신하여 대용량 미디어 파일의 교환을 하는데 있어, 높은 처리량을 유지하기 위한 유연한 시스템 구성이 가능하다.

AMP에는 사용자 데이터 샤드에서 자원을 받아 생성된 Index를 리턴한다. 이 인덱스는 EN Web Servcie 대한 검색 Index가 추가될 것이고, 미디어의 로컬 검색을 가능하게 하기 위해 휴대폰이나 데스크탑의 Evernote 클라이언트에 전달 된다. 사용자의 요청에 잦아듬으로 인한 샤드 트래픽 부담을 최소화하기 위해 AMP는 서로 큐 정보를 브로드캐스트하고, EN Service의 부하와 프로세스 우선 순위에 최적화된 단일 분산 미디어 프로세서를 구축하고 있다. Evernote 인덱싱 시스템은 다양한 콤포넌트가 하나 밖에 남아 있지 않아도, 처리(운영하는데) 할 수 있는 충분한 회복력을 가지고 있다.(그리고 현재 37개의 AMP processors와 500개 이상의 ENRS 서버 프로세스는 하루에 2백만개의 미디어 파일을 처리하고 있다.)

ENRS 서버의 일부인 AIR를 자세히 살펴 보자. AIR의 인식 철학은 일반 OCR 시스템과 달리 그 목적은 인쇄 가능한 텍스트가 아니라 포괄적인 검색 Index를 생성하는 것이다. 그 핵심은 어떠한 종류와 품질의 이미지라도 많은 단어를 찾아내는 것이다. 불완전·불명확·멍한 단어의 대체 항목도 생성할 수 있는 유연성도 가지고 있다. 현실 세계의 이미지를 처리하므로, AIR서버는 다른 가정에 맞춘 여러 "경로"로 처리 한다. 이미지가 클수도 있고, 약간의 단어만을 포함했을 수도 있다. 다른 방향으로 단어가 흩어져 있을수도 있다. 글꼴역시 같은 영역안에 작을수도 클수도 있다. 텍스트도 흰색 바탕에 검은 글자, 검정 바탕에 흰색 글자가 섞여 있을지도 모른다. 다른 언어와 알파벳이 혼합하고 있을지도 모른다. 아시아 언어로는 동일 영역에서 가로와 세로가 혼재되어 있을지도 모른다. 표준 OCR에서는 비슷한 수준의 그레이로 같은 비슷한 글꼴색이 섞여 있을지도 모른다. 인쇄된 텍스트는 자필 코멘트가 포함되어 있을지도 모른다. 광고 영상 소재는 비뚤어지고, 비스듬해지고, 사이즈가 변경되어 있을지도 모른다. AIR 서버가 하루 200만번 직면하고 있는 몇 안되는 문제를 나타낸 것이다.

다음 그림은 AIR 서버의 주요 빌딩 블록(단일 "pass")이다. 호출 매개 변수에 의해 다른 종류의 프로세스(scale, orientation 등)를 결정하고 있다. pass에 따라 pass(scaled, converted to gray, binarized)를 위해 이미지 셋트를 준비하기 시작한다. 이미지·그래픽·표·마크업태그·비 텍스트 부산물들은 실제 단어에 초점을 맞추기 위해 가능한 제거하는게 필요가있다. 후보 단어가 발견 된 후, 텍스트 행과 블록을 조립한다.

각 블록의 각 행은 내부에서 개발한거나 다른 업체의 라이센싱한 인식 엔진을 통과해 분석해 간다. 여러 인식기를 사용하는 것은 다른 종류의 텍스트와 언어를 식별하는 데 중요할 뿐만 아니라 "투표" 매커니즘을 구현할 수 있다. 같은 단어를 다양한 엔진에 의해 생성된 대안 단어를 분석해 false 인식의 억제와 합의된 변종에 더 신뢰를 줄 수 있다. 이러한 신뢰성 있는 대답이 텍스트 행의 구조 재결정, 단어 그룹핑, 검색 실수(false positives)를 줄이기 위해 애매한 부분을 제거하는 등 텍스트 행을 재구성하는 "pass" 프로세스가 검색의 신뢰를 크게 향상시킨다.

이미지를 렌더링하거나, 모듈 분석에 의해 생성되는 pass 수가 먼저 결정된다. 그러나 이 인식 과정에서 수는 증감한다. 예쁜 문서를 스캔하는 경우, 표준 OCR 처리만으로 충분하다. 희미한 상황에서 휴대 카메라로 촬영된 복잡한 풍경은 텍스트 데이터를 검색하기 위해 풀 "pass"를 사용하여 깊은 분석을 할 필요가 있다. 복잡한 배경에 색깔있는 많은 단어는 색 분할에 특화한 pass가 추가로 필요하게 된다. 작고 희미한 텍스트는 다른 인식 처리를 하기 전에 텍스트 이미지를 복원하기 위해 비싼 reverse digital filtering 기술이 필요하다. 일단 모든 pass가 완료되면, AIR 처리에 중요한 최종 결과를 조립하기 위해 다음 공정을 진행한다. 복잡한 이미지는 다른 pass가 동일한 영역의 분석 결과를 생성하고 있을지도 모른다. 이러한 모든 충돌은 해결하고, 최상의 분석 결과를 선택하고, 잘못된 많은 대안들은 거절되고, 최종 블록과 텍스트 행을 구축 할 필요가 있다. 내부 문서 구조가 결정되면 요청된 출력 포맷을 생성하는 최종 공정이 남아있다. PDF 문서는 이미지가 인식된 텍스트 상자로 대체된 PDF이다. 위치 정보를 통해 사용자가 문서에 포함된 단어를 찾았다면 해당 문서의 단어나 이미지 위에 검색 단어를 강조하는 것을 허용한다.