미국의 오프라인 DVD 매장을 사라지게 한 Netflix 온라인 싸이트의 기술 배경을 설명한다.
인터넷을 통해서 TV 나 DVD 를 볼 수 있도록 하는 서비스이다. webkit을 UI 프레임웍으로 쓰는 것으로만 알고 있었는데. 자료들을 보니. 아마존 클라우드를 이용해서 서비스가 되고 있었다.
관련 내용을 OSCON 2011에서 발표했다.
발번역 시작한다.
* Data Plane
- S3에 Asset(HD Video, Audio, 자막)을 copy해 둔다.
- EC2을 이용해서 인코딩한다. (비디오/비디오 스피드, 포맷, 볼수 있는 50개의 파일로 분리)
- 많은 데이터들은 CDN(Akamai, LimeLight, LEVEL3)를 이용한다.
- Performance 그래프
* Control Plane
- Metadata Curation (ynopsis, 장르, 태그, 번역) 을 다양한 언어로 보여준다.
- in-house용 Mysql 기반의 Metadata Editor 작성 S3로 export함
- metadata는 S3에 저장하고 최대한 RAM에 올림
- 10개의 GB Head을 가진 Tomcat을 기반으로하는 플랫폼으로 가지고 있으며, Tomcat간에는 REST를 서로 호출한다.
- s3 안에 petabyte 로그 정보가 있음.
Hadoop 기반의 분산되어 있는 로그 파일을 수집하는 Chukwa와 Hive 분석 솔루션을 가지고 분석가능함
* 저장 툴
- Mysql
- Canssandra.
1. 회원 관리에 사용. 세계 4군데로 나누어서 정보를 관리
2. 북마킹
3. 개인 정보 (선호, 보고싶은 영화)
- 로그 분석
1. 로그 처리 및 데이터 추출 (AWS Elastic Map Reduce, Hive 이용)
2. Cassandra / brisk 를 teradata로 추출
좀 더 자세한 정보를 보려고 했더니. slideshare에 있었다.
Velocity Conference 2011에 발표했던 자료이다.
okcupid.com 에 접속해서, 내가 원하는 조건을 가지고 내가 원하는 타입을 찾아낼 수 있다.
내가 원하는 타입이 match 율에 따라서 보여준다.
중요한 점은 웹 페이지에서는 개인적인 정보(preference)를 가지고 있지 않다. 즉 개인 정보는 최대한 보호할 수 있다.
DB에 개인정보를 보면 질문에 대한 답(취향), 숨겨질 정보, 투표, demo data(자신의 외모,키), demo prefs(내가 찾는 이성 정보) 등이 저장되어 있다.
만약 웹서버에서 DB에 접속해서 개인 정보를 얻어오려고 한다면, 얼마나 많이 검색해야 할까? 1K 디스크 seek만 해도 천3백만명이면, 1억 3천만개의 seek를 해야 한다.
우리는 scalable, low cost, fast, reliable 관점으로 시스템을 구축했다.
* scalable 관점
worker는 분산 아키텍처기반으로 나누어져 있다. 이렇게 하면 2배이상의 효율을 얻어낼 수 있다.
웹 서버의 요청을 받아 merger를 통해 worker로 정보를 읽어오게 하고, 그것을 하나로 데이터를 만들어 웹 서버로 전달했다.
* low cost 관점
c++은 java보다 3배 빠르고, 4배 메모리를 적게 먹어서 서버를 적게 사용할 수 있었다.
12core에 맞게 12개의 worker를 두었다.
* fast 관점
어떻게 해야 가장 빨리 검색할 수 있을까? location, last login을 기준으로 검색해야 했다.
quadtree를 이용해서 지역과 last login정보를 검색하도록 해서 high dimension tree보다 2배 이상 빨리 검색할 수 있었다.
(@김용환 코멘트 : 사실 이미지 검색쪽에서 많이 사용되었던 알고리즘이다. jpeg2000에서 이 알고리즘을 보고 좋아했었다. location 시스템에서 quadtree는 속도가 엄청빠르다. 일부 표준 문서에 jpeg2000으로 이미지를 압축해서 보내는 것을 넣는 것을 했었다.)
(@김용환 코멘트 : quardtree가 속도가 좋을 수 밖에 없는 것은 바로 밀집성과 연관되어 있다. 지도에서 보면, 미국 동북부 지방, 캘리포니아 지방에 사각형이 세밀하게 있고, 텍사스쪽은 허허 벌판이다. 즉 사람 정보가 거의 없다는 것을 의미한다. 인구의 밀집성에 맞춘 검색에 적합하다고 할 수 있다.)
* Reliable 관점
work 장비가 죽어도, 작동되게 하기 위해서 여러개의worker 인스턴스가 동작될 수 있다.
worker 장비의 속도는 생명이기 때문에 일반적인 정보를 caching한다. 리스타트하면서 DB 정보를 읽어온다.
10만명의 개인 사용자 정보를 읽어오는 worker가 있다면, 디스크 정보 얻어오려면 10만번을 해야 한다. 이 방법은 좋지 않았다.
그래서 nosql을 사용해서 10만명의 정보를 읽어왔다. 좋았다. (@김용환 코멘트 : 얼마나 좋은지 지표를 주면 좋았을 뻔)
맘에 들지 않지는 사람은 hide를 시킬 때, 이 정보를 mysql, worker, nosql로 복제를 해야 한다.
nosql은 SSD를 사용해서 효과를 얻을 수 있다. SSD는 4배 정보 비싸지만 12배 정보 write 속도가 빠르다.
이 방식을 사용하여 3배 정보의 비용 절감 효과를 보았다. (@김용환 코멘트 : 예전에 프로젝트할 때 부팅 속도빠르게 플래쉬를 쓰려고 했었다. 빠른 부팅속도, 빠른 IO를 사용하여 성능을 최적화는 것도 좋은 방법 중의 하나)
SSD에서는 write는 read를 block한다.
write 때문에 read 속도가 팍 늘어나는 것을 볼 수 있다.
이런 부분 때문에 최대한 write를 피해야 하고, SSD 벤치마킹을 잘해서 critical한 부분에서는 read 속도 때문에 문제가 되지 않도록 충분히 피해야 한다.
Last Look
- C++
- Optimized heavily
- Single threaded procs
- SSDs
성공할 수 없었던 자바의 특징을 먼저 설명하였다. (장점은 아래 PPT 참조) 특별히, 다른 언어에서 사용하는 일부 기능 생략도 성공 중의 하나였다.(lexical macros, multiple implementation inheritance, operator overloading, 헤더 파일, 다큐먼트). 이 분이 얘기한 자바의 단점 또는 추한 부분을 얘기했다.
1. int->float, long->double형으로 형을 변환(conversion)하면서 생기는 문제(widening)
2. compound 할당 연산자가 작은 타입으로 변환하는 casting 문제 (narrowing)
3. equals를 구현(override)하였지만, ==, != 연산자는 주소를 가지고 비교한다.
4. constant 변수가 inline된다.
5. 불필요한 비안정성을 이끌었던 디폴트 생성자는 처음부터 없어야 한다
6. 생성자에서 override된 메소드를 호출하는 것이 가능(legal)하면 안된다. 미묘한 버그를 생산할 수 있다.
7. unsigned 타입의 부재
8. 단일화된 Exception 상속개념이 없다.
9. switch 문이 잘 구조화되지 않았다.
10. Arrays의 toString을 잘 구현해야 내용물이 출력한다. 자바를 처음 배우는 친구들이 매번 실수한다.
11. Exception이 막 발생한 (pending) exception을 제거하고 새로운 것으로 만들 수 있다.
12. Cloneable 인터페이스에 clone 이라는 함수가 없다.