April 25, 2013
Digg Architecture

Digg라는 소셜 북마크 서비스가 있다. 현재 2300만명 이상의 가입자를 확보하고 있으며 월 2억 3천만 이상의 페이지뷰가 발생하고 있다.

수억건의 요청(월)을 Digg는 어떤 방식으로 처리하는지 살펴보자.

#Platform

  • MySQL
  • Linux
  • PHP
  • Lucene
  • Python
  • APC PHP Accelerator
  • MCahce
  • Gearman - job scheduling system
  • MogileFS - Open source distribute filesystem
  • Apache
  • Memcached

Digg는 12개의 웹서버, 12개의 DB서버, 파일 서비스를 위한 약6~10대의 mogileFS서버 그리고 추천 엔진으로 운영하고 있는 6대의 그래프 데이터베이스 서버로 구성되어 있다.

#데이터베이스 - MySQL (4대로 구성)

#파일시스템 - MogileFS

  • 스토리 아이콘, 사용자 아이콘을 저장하고 제공하는 용도로 활용
  • MogileFS는 분산 파일 시스템으로, 라이브저널을 만든 개발자가 Perl을 이용하여 제작하였다. Hadoop처럼 큰 사이즈의 파일을 다루는 것이 아닌, 작은 용량의 파일을 다루는데 적합하게 설계되어 있다. 예전 프로젝트에서 MogileFS를 이용하여 Live Streaming을 구현한 경험이 있는데, 꽤 쓸만했던 기억이 난다.

#Cache - Memcached

  • 데이터베이스와 Application단에 고루 분포되어 있다.
  • 성능 향상을 위함

Digg로 부터 배울수 있는 점,

  • Box(Server)의 대수보다 어떻게 효율적으로 배치하고 구성할지가 관건
  • MySQL 엔진을 적절하게 사용
  • 트랜젝션이 필요하면 InnoDB, 필요치 않으면 MyISAM
  • Digg는 그들의 시스템이 scale-up에 대한 효과보다 scale-out을 했을때 효율적이라 판단했고, 아키텍처링을 통해 시스템을 성장 시켰다.
  • 정적 리소스를 Caching
  • Digg를 사용하는 사용자들이 서비스가 느리다고 불평했고, 원인은 백엔드가 아닌 java script 문제로 밝혀졌다. (Front-Backend까지의 진단이 필요)
  • 성능을 개선하기 위해 다양한 기술(APC PHP accelerator)을 조합하여 사용했다.

#Reference: http://highscalability.com/digg-architecture 

COMMENTS :: 댓글 달기
10:39am  |   URL: http://tmblr.co/ZkGPXyjTunLc
Filed under: digg Architecture 
April 22, 2013
Apache Zookeeper

ZooKeeper는 분산 코디네이터(coordinator)이며 JVM위에서 동작하고 Java로 만들어져 있다. Hadoop 생태계에서는 ZooKeeper는 어플리케이션들이 서로 잘 동작할 수 있도록 중재(설정 정보, 네이밍, 분산 동기화)하는 역할로 활용되고 있다.

ZooKeeper Server는 Leader와 Follower로 구성되어 있다. Leader는 서버들끼리 자동으로 선정하며 모든 데이터 Write를 주관하게 된다. 서버간의 데이터 불일치시 데이터 보정이 필요하고 이때 과반수 선정룰을 적용하게 된다. 따라서 홀수개의 서버로 구성해야 한다. 짝수로 구성시 동작하지 않는다.


ZooKeeper는 위와 같은 디렉토리 구조로 데이터를 저장한다.
데이터 저장 노드는 Persistent, Ephemeral, Sequence 총 3가지로 구분된다.

  • Persistent Node: 데이터가 삭제되지 않고 유지되는 노드이다.
  • Ephemeral Node: ZooKeeper서버에 접속한 클라이언트가 Ephemeral 노드를 생성했다면, 세션이 끊기기전까지 유지되는 노드이다.
  • Sequence Node: Node 생성시마다 Sequence번호가 자동으로 생성되는 노드를 의미한다. (이 기능을 활용하여 ZooKeeper가 지원하지 않는 분산락 기능을 구현할 수 있다.)

마지막으로 ZooKeeper서버의 증가에 따른 성능이다.

위의 Performance 자료에도 나와 있듯이, 서버수가 증가할 수록 성능은 저하된다.
즉, 데이터 변경이 잦은 상황에서는 ZooKeeper를 데이터 저장소로 사용하는 것은 부적합하다는 의미이다. (예전 프로젝트에서 이런 경험을 했던 사례가 있다.)

ZooKeeper는 훌륭한 분산 중재 솔루션이고 이미 많은 사례(HBase, Twitter Storm, Facebook 등등)를 통해서 입증되고 있다.

이러한 기술의 쓰임새에 대해서 고민해보고 적재적소에 적용할 수 있는 능력과 혜안을 가져야겠다.

Reference: http://zookeeper.apache.org/doc/current/zookeeperOver.html

COMMENTS :: 댓글 달기
4:52pm  |   URL: http://tmblr.co/ZkGPXyjGpGVu
Filed under: Zookeeper HA 
April 18, 2013
요즘 CEP에 대해서 조금씩 공부를 하고 있지만, 어떻게 활용할지 유즈케이스가 딱히 떠오르지 않는다.기존 DBMS에서는 데이터를 정적인 관점으로 바라봤다면, CEP는 데이터가 흘러가는 관점으로 바라보는 것이다.DBMS와 CEP엔진의 가장 큰 차이점은 DBMS에서는 데이터를 저장 후에 처리를 하는 반면, CEP엔진는 데이터가 발생한 즉시 처리한다는 점이다. ‘Trustin’이라는 사람에게 메일이 도착하면 사용자에게 알려주는 서비스를 만든다고 가정하면,DBMS의 경우에는 주기적으로 사서함을 Select하여야 할 것이다. 반면, CEP엔진의 경우 ‘Trustin’라는 사람이 메일을 보냈는지 데이터 스트림을 바라보면 될 것이다. 다양한 정보가 흘러가는 데이터 스트림을 real-time으로 모니터링 할 수 있는 CEP를 어떻게 활용해야 할까? Telco 도메인의 경우, 복제폰 사용자가 있는지를 확인 SLA (Service Level Agreements)  Online Advertisement - 행동 기반 타겟팅 Auditing - “Who” did “What” and “What” Fraud detection Up-sell/Cross-sell 고객이 새로운 폰 모델을 검색할 때 -> 쿠폰 제공 벨소리를 다운로드 할 때 -> 연관 컨텐츠 추천 Customer retention : React to potential customer desertion 고객이 자주 남은 사용량을 체크 할 때 계약 약관을 확인 할 때 Improve service consumption rates and self-service 고객이 벨소리, 영화, 테마 다운로드를 실패 했을 때 선불 요금제 고객, 추가 사용량 구매가 실패 했을 때 Advanced / pro-active customer service monitoring 더 없을까???


요즘 CEP에 대해서 조금씩 공부를 하고 있지만, 어떻게 활용할지 유즈케이스가 딱히 떠오르지 않는다.
기존 DBMS에서는 데이터를 정적인 관점으로 바라봤다면, CEP는 데이터가 흘러가는 관점으로 바라보는 것이다.
DBMS와 CEP엔진의 가장 큰 차이점은 DBMS에서는 데이터를 저장 후에 처리를 하는 반면, CEP엔진는 데이터가 발생한 즉시 처리한다는 점이다.

‘Trustin’이라는 사람에게 메일이 도착하면 사용자에게 알려주는 서비스를 만든다고 가정하면,
DBMS의 경우에는 주기적으로 사서함을 Select하여야 할 것이다. 반면, CEP엔진의 경우 ‘Trustin’라는 사람이 메일을 보냈는지 데이터 스트림을 바라보면 될 것이다.

다양한 정보가 흘러가는 데이터 스트림을 real-time으로 모니터링 할 수 있는 CEP를 어떻게 활용해야 할까?

Telco 도메인의 경우,

  • 복제폰 사용자가 있는지를 확인
  • SLA (Service Level Agreements) 
  • Online Advertisement - 행동 기반 타겟팅
  • Auditing - “Who” did “What” and “What”
  • Fraud detection
  • Up-sell/Cross-sell
    • 고객이 새로운 폰 모델을 검색할 때 -> 쿠폰 제공
    • 벨소리를 다운로드 할 때 -> 연관 컨텐츠 추천
  • Customer retention : React to potential customer desertion
    • 고객이 자주 남은 사용량을 체크 할 때
    • 계약 약관을 확인 할 때
  • Improve service consumption rates and self-service
    • 고객이 벨소리, 영화, 테마 다운로드를 실패 했을 때
    • 선불 요금제 고객, 추가 사용량 구매가 실패 했을 때
  • Advanced / pro-active customer service monitoring

더 없을까???

COMMENTS :: 댓글 달기
10:21pm  |   URL: http://tmblr.co/ZkGPXyizSR5F
Filed under: CEP 
April 17, 2013
YAGNI (You are not gonna need it)

XP에서 사용되는 용어중에 YAGNI라는 말이 있다.
프로그래머가 “이런 기능들이 필요할꺼야…”라고 미리 예상하여 해당 기능을 설계에 포함시키는 것을 경계하는 말이다.
만약, 예상이 빗나간다면 비용을 낭비한 결과가 초래될 것이다.

“필요할 때에 최소한의 설계를 하자.”

프로그래밍을 해본 사람이라면 공감할 것이다. 처음 설계대로 프로그래밍 되는가?
내가 모르는 기술적인 함정이 있을 수 있고, 요구사항이 변경될 수도 있다.
과연 이런 것들을 사전에 미리 예측하여 대비 할 수 있을까?라는 의문이 든다.

그렇다고, 필요할 때마다 설계를 해서 구현을 한다는 것 역시 쉽지 않은 일이다.
우리는 위와 관련하여 많은 경험을 해보았다.
요구사항이 변경되었을때, 짜집기식으로 코드를 끼워넣은 경험은 다들 있지 않은가?

결국, 이런 상황에 대비할 수 있는 방법은 ”Trade off를 고려하여 단순하게 설계하는 것”과 “*리펙토링으로 올바른 설계를 유지하는 것”일 것이다.

*리펙토링: 외적 행위는 유지하면서 내부 구조를 개선하는 작업

COMMENTS :: 댓글 달기
12:21am  |   URL: http://tmblr.co/ZkGPXyiqPEBU
Filed under: think 
April 8, 2013
사업자 보유 데이터의 활용

데이터를 활용하다보면 “이런 데이터를 사용하면 더 좋을텐데…”와 같은 욕심이 생긴다. 그리고 이미 데이터를 얻게 되었을 때의 효용과 데이터를 취득하고 유지하는 것에 대한 비용을 이해한 상태이기 때문에 “비경쟁부분에 속한 데이터를 구매해도 된다.”는 관점도 생겨날 것이다.

이런 상황에서는 데이터에 대한 구매자/판매자가 생겨날 것이고 서로에게 영향을 미치게 되고, 이로인해 데이터 유통이 활발해지면서 시장도 형성될 것이다.

이런 비즈니스 모델은 이미 SaaS와 같은 모델로 제공되고 있다.


인포침스(http://www.infochimps.com/)는 데이터 매매 중개 사업자이다.
image

데이터를 이쁘게 가공하여 판매하고 있다. 예를 들어, “약 2만개의 골프 코스 데이터”는 750달러에 판매되고 있다.

기업 입장에서 보기에 자사가 강점을 발휘하지 않는 부문(비경쟁부문)의 데이터는 판매해도 큰 문제는 없을 것이다. (물론, 허가가 있어야 겠지만…)

반면, 경쟁부문의 데이터는 판매하지 않을 것이다.

경쟁부문과 비경쟁부문의 데이터는 쉽게 찾아볼 수 있다.

고기 및 물수건을 납품하는 사업자의 영업 데이터는 영업 기록에 불과할지도 모르지만, 맛집 사이트의 입장에서는 하루에 소비되는 고기&물수건 수를 정확히 파악할 수 있고, 이로 인해 내방객 수를 알 수 있을 것이다.

A사의 입장에서는 영업 기록에 불과한 데이터가 B사의 데이터 분석 담당자에게는 아주 중요한 데이터가 될 수 있다.

앞으로 기업간 데이터 교류가 활발 해지지 않을까? DaaS(Data as a Service)라는 마케팅 용어와 함께…

Reference:

  • 빅데이터 비즈니스

COMMENTS :: 댓글 달기
8:14pm  |   URL: http://tmblr.co/ZkGPXyiCD-6q
Filed under: Big Data