GReader

GReader(지리더)는 구글리더를 대신할 프로젝트로 재미삼아 혼자 시작한 프로젝트입니다. 관리문제와 서버를 유지하는 비용문제로인해서 트래픽을 최소화 방법을 고민하던차에 결론을 정적페이지 기반으로 만들어서 구글리더와 비슷한 것을 만들자였습니다.

계획

• 정기적으로 수집하여 놓칠 수 있는 포스트를 연속적으로 유지될 수 있도록 한다.
• 클라이언트는 변화를 느낄 수 없고 어떠한 속도저하도 느낄 수 없어야 한다.
• 수집 실패 확률을 줄이기보다 단순한 피드보기를 99.999% 접속을 보장하도록 한다. 그래서 정적 페이지 기반으로 한다.
• 가입정보를 유지하여 필요한 피드만 수집하여 사용자에게 보여주도록 한다.
• 사용자가 가입정보에따른 피드 정보는 주기적으로 정적페이지로 발행하여 최신 데이터로 유지한다.

구성

• 피드 수집 서버
• 사용자 피드 가입 정보관리 및 깃허브 계정 관리 웹 어플리케이션
• 수집 피드 정보를 기반으로 한 페이지 웹 어플리케이션

위의 모듈은 각각 아래의 형태로 개발되었다. 1~2주 정도 짧은 시간에 프로토타이핑해서 기능이나 코드 퀄리티는 떨어진다.

• GReader Scrapper API 서버 - Scala/Spray/Akka/Redis 사용한 RESTful API 서버
• GReader Manager 서버 - Python/Flask/Redis 사용한 웹 어플리케이션 서버. jquery/bootstrap/angularjs/requirejs 등으로 프로토타입
• GReader App - Javascript/jQuery/AngularJS/RequireJS/Bootstrap 사용한 한 페이지 어플리케이션

원리

사용자는 GReader Manager 서버를 통해 깃허브 계정을 연동하며 피드 가입정보를 관리합니다. 사용자는 가입정보를 관리 서버에 요청하여 저장하고, 최신 피드 정보를 가지고 있는지 검사하고 최근 피드가 아니라면 피드를 수집하여 갱신합니다. 사용자는 피드가 수집되는 과정을 지켜볼 수 있다. 관리서버는 깃허브 계정과 연동하며 동기화 버튼을 클릭하면 (현재는 자동으로 동기화를 해주지 않는다.) 깃허브 정적페이지를 저장하는 레파지토리에 피드정보를 푸쉬한다.

성능

측정도구는 개틀링을 이용해서 처리했으며, 당연히 성능은 캐쉬 히트율에따라서 크게 달라집니다. 다음 상황을 가정하여 측정했습니다.

3개의 피드를 각 3000건 요청하는데 그 시간을 20초동안에 모든 리퀘스트를 요청합니다. 캐쉬 TTL은 5초로 가정. (일부러 줄인 것)

• 대략 500 tps 이상은 처리할 수 있습니다.

내부적으로 counter, gauge, meter, historam 등 메트릭을 유지하며 성능을 측정했습니다. 근데 기억이 안나요. 9주전에 해서요.

예제

실제 구동된 서버에서 반환받는 예제

• http://1.234.27.114:8891/v1/feeds/http://blog.geekple.com/feed/
• http://1.234.27.114:8891/v1/feeds/http://charsyam.wordpress.com/feed/

정적 페이지 RSS 리더 예제

• http://dani-kim.github.io/greader