리디북스 서버 스택 소개

2대의 서버로 시작한 리디북스는 각 기능의 요구사항에 최적인 솔루션들을 채용하고, 고가용성(High Availability)을 지향하면서 매우 복잡하고 다양한 구성으로 변모해왔습니다. 이 글에서는 리디북스가 어떤 스택에서 서비스를 제공하고 있는지 간략히 소개하려고 합니다. 각 스택의 선택 이유나 문제에 부딪히며 배운 노하우 등은 차차 포스팅하겠습니다.

대략적인 구조

리디북스 백엔드 구조도

로드 밸런싱

로드 밸런싱은 소프트웨어 로드 밸런서인 HAProxy를 이용하고 있습니다. HAProxy는 L4, L7 스위치의 기능 및 로드 밸런싱을 제공하고 구성 역시 매우 간편합니다. 리디북스는 고가용성을 위해 Active – StandBy 서버 한 쌍이 가상 IP를 공유하고, keepalived를 통해 서로의 상태를 확인하며 자동 failover 됩니다. 각 서버군이 사용하는 네트워크 트래픽에 따라 스위치와 연결되어 있는 네트워크의 속도가 다른데, 이를 효율적으로 사용하기 위해 HAProxy 서버 쌍을 2개 구성하여 DNS를 통해 HAProxy로 들어오는 트래픽도 분산하는 방식으로 네트워크 효율화를 이루었습니다.

웹 서버

Ubuntu 14.04 LTS 기반에 웹서버로는 Apache, Nginx를 사용하고 있습니다. 서점 용 웹 서버, 정적 파일 서버(CSS, JS 등), 통계용 서버, 책 파일에 DRM을 씌워 전송하는 다운로드 서버 등 여러 개의 웹 서버 그룹을 나누어 관리하는데, 각 서버가 하는 역할이나 테스트를 통해 확인한 병목 지점을 고려해 웹서버를 채택합니다.

API 서버

리디북스는 서점이나 앱에서 이용하는 수많은 API가 존재하는데 종류에 따라서는 초당 수만 개의 호출이 발생하는 경우도 있습니다. 이러한 트래픽을 감당하기 위해 비동기 처리가 필요한 경우 Node.js를 주로 이용하여 구현하고 있습니다. Node.js 프로세스는 PM2를 통해 클러스터 모드로 실행되어 요청을 처리합니다. 클러스터 모드는 프로세스에 대한 로드 밸런싱을 지원하며 프로세스를 순차적으로 재시작할 수 있어 무정지로 서비스를 재시작할 수 있습니다

데이터베이스

서비스 초기에 MySQL을 사용했고 현재는 MariaDB로 변경한 상태입니다. 한때 DB가 SPOF(Single Point Of Failure)였던 시기를 겪으면서 read/write의 분산을 위해 많은 노력을 들였습니다. 리디북스에서 실행하는 대부분의 데이터 연산은 읽기 동작이므로 애플리케이션 레벨에서 읽기/쓰기 접근을 구분하여 1차적으로 부하를 분산하고, HAProxy를 통해 여러 대의 slave로 분배해 2차적으로 부하를 분산합니다. 쓰기 동작이 빈번하거나 데이터 성격상 NoSQL이 필요한 경우 Couchbase와 Redis를 적극적으로 사용하고 있으며, MariaDB 상에서도 쓰기 동작의 분산 필요성이 대두됨에 따라 상반기에 샤딩을 준비하고 있습니다. 사용자 행동, 트랜잭션 로그 등 하루에도 방대한 양이 쏟아지는 데이터의 경우 Azure 내에 구성한 Hadoop 클러스터에 보관하며, Hive 저장소를 BI(Business Intelligence) 시스템 기반으로 활용하고 있습니다.

파일 시스템

리디북스에서 다루는 책 파일은 매우 방대하고 중요한 데이터입니다. 어떠한 일이 있어도 데이터 유실이 발생해서는 안되며, 일부 하드웨어 혹은 노드에 장애가 발생하더라도 서비스 장애 없이 파일을 서빙할 수 있어야 합니다. 저희는 GlusterFS로 6대의 노드를 클러스터를 구성하고 이를 파일 접근이 필요한 서버에서 NFS-like 형태로 마운트하여 사용하고 있습니다. 동일 데이터는 여러 노드(3 replica)에 분산 저장되며, 각 노드에도 RAID 구성을 하여 빠른 장애 대응 및 데이터 유실 방지에 노력하고 있습니다.

검색

리디북스의 책/저자 검색 등은 ElasticSearch를 통해 이루어집니다. 형태소 분석기는 오픈소스인 은전한닢에 따로 정의한 dictionary를 조합해 사용하고 있고, 2대의 노드로 클러스터가 구성되어 있습니다. 추가/변경되는 도서 정보는 증분 색인을 통해 실시간으로 검색 서버에 반영됩니다.

작업큐

이메일 발송, PUSH 발송 등의 작업들은 웹 애플리케이션이 직접 실행할 경우 페이지 응답속도를 떨어뜨리고, 진행상황 파악이나 실패 시 재시도하는 등의 실행 관리가 어렵습니다. 이런 문제를 해결하기 위해 Beanstalk라는 Work Queue에 작업을 일단 쌓아두고, 여러 대의 서버에서 실행되고 있는 컨슈머들이 작업을 가져와 순차적으로 진행하는 형태로 구성되어 있습니다.

모니터링

장애 발생 포인트와 시점을 예측할 수 없는 만큼 장애 발생의 빠른 인지를 위해 모니터링은 매우 중요합니다. 리디북스는 99.999%의 고가용성(High Availability)을 목표로, 버그와 장애 없는 안전한 운영을 위해 아래와 같이 다양한 오픈소스 및 유료 솔루션을 도입하여 활용하고 있습니다.

• 30+ 이상의 서버 리소스를 모니터링하기 위한 Munin(On-Premise) 및 NewRelic(SaaS)
• 서버에서 발생하는 각종 오류와 예외를 모니터링하기 위한 Sentry
• 로그인, 결제 등 서점의 핵심적인 기능의 정상 여부를 모니터링하는 Pingdom
• 각종 배치작업과 주기적으로 실행되는 스크립트를 모니터링하기 위한 PushMon
• Node.js 프로세스나 Redis 상태 모니터링을 위한 Keymetrics(SaaS)
• 데이터의 무결성을 주기적으로 감지하는 각종 In-house 스크립트

리디 기술 블로그