Netflix’s Transition to High-Availability Storage Systems을 보고 빠른 내용으로 요점 정리한 내용이다.
Oracle DB(RDB)의 데이터를 아마존의 AWS의 Simple DB로 전환하면서 고민했던 내용이 담겨있어서, 참조하기에 아주 좋은 경험담이다. 또한 Simple DB에 대한 이해도를 높일 수 있다.
2008년 Netflix는 이미 데이터센터를 가지고 잇었다. 만약 이게 문제가 나면(single of failure), 서비스 장애가 되는 구조였다. 점점 서비스 트래픽이 올라감에 따라 파워, 공간, 품질과 가용성을 높이기 위해서 2010년 Netflix는 새로운 데이터센터를 지을지 아웃소싱할지 고려하였다.
용량과 스케일 관점으로 보고, 결국 아웃소싱 클라이드인 아마존 AWS를 선택했다.
계획은 오라클의 데이터를 AWS의 DB로 이동시키고, Web Server App들도 AWS의 서버에 App으로 이전하는
것으로 했다. 실제 마이그레이션 작업은 한달정도 걸렸다.
SimpleDB와 S3가 아래의 기능이 있었기 때문에 가능했다.
• Disaster Recovery
• Managed Fail-over and Fail-back
• Distribution (i.e. cross-zone, not cross-region currently)
• Persistence
• Eventual Consistency1
• Support for a subset of SQL
CAP에 AP만 고려했고, AWS에서 동작하며 분산처리 되는 것이 SiimpleDB와 S3였다. Simple DB가 가장 적합했지만, 큰 데이터가 들어올 때는 S3를 이용했다. Simple DB의 schema-less한 기능을 가지고 value값에 attribute을 여러개를 넣어서 정보를 저장했다.
RDB의 relation을 Simple DB로의 정규화(Normalization)을 진행했다.
1차 정규화는 레코드 타입의 모든 정보는 모두 넣는다. 그러나 반복되는 필드나 그룹은 제외한다.
2차 정규화는 key의 subset에 대해서 관련있는 필드값이 오면 따로 뺀다.
즉, 아래와 같은 테이블이 존재한다.
park, warehouse, quantity, warehouse-address
여기서 part, warehouse-> quantity, warehouse-> warehouse-address의 의존도를 가지면,
테이블을 분리한다.
table1)
park, warehouse, quantity
table2)
warehouse, warehouse-adress
이렇게 하면서 단점이 생긴 부분들은 4가지이다.
첫번째 하나의 테이블을 둘로 나누면서 공간이 많이 사용했다.
두번째 하나 에서 수정할 것을 둘로 나누어서 수정해야 했다.
세번째 둘로 수정이 가하다 보니 inconsistency가 존재할 수 있다.
네번째, warehouse가 없을때는 row를 가지지 않는다. 이 때문에 warehouse-address에 대한 손실이 있을 수 있었다.
이렇게 하면서 겪은 것을 정리하면,
RDB를 key-value로 마이그레이션하는 것은 어렵다. 주의 깊게 잘 정의 해야 한다.
DB에 있는 기능 중 Simple DB에 없는 것이 있다.
DB의 Transaction은 Simple DB에서는 Conditional put/delete 를 할 수 있고, Cassandra는 Batch mutate + colution에 모두 write 하는 기능을 사용해서 해결 가능하다.
schema-less한게 모호함을 줄 수 있는데, schema validator를 만들어서 올린다.
Sequence가 없으니. Simple의 UUID라는 것을 이용한다. 만약 ordering을 하려면, distributed sequence generator 또는 클라이언트에서 보낸 timestamp값을 가지고 odering을 한다.
PL/SQL, Trigger는 포기한다.
CLOCKs는 NTP로 대체한다.
그러면, constraint와 foreign key는 어플단에서 구현해야 한다.
simple DB는 오라클의 좋은 기능들 (backup, recovery, native type, 내부 함수[soring, condition], limit partitioning, NULL, Write 속도)이 없고, case sensitive해서 attribute name때문에 장애로 이어질 수 있다.
Simple DB의 sparse-table은 null이 index가 되지 않아서, 다음과 같은 쿼리는 full scan이 된다.
"select field1 from domain where fild2 is null"
(그리고, null값이 들어간 테이블을 소팅하면 attribute 정보가 유실될 수 있으니, 아래와 같이..)
이것은 field2_null 이라는 필드를 만들어서, null 체크하는 값을 넣어야 한다.
select field1 from domain where field2_null ='y'
Simple DB의 성능은 index selectivity에 있다.
index selectivity = 전체 distinct한 atrribute / item 개수
즉 distict한 값이 1에 가까워야 성능이 좋다. 만약 distinct한 값이 적으면 성능은 안좋다.
하나의 10G 또는 10억 으로 제한이 걸려있는 Simple DB의 데이터를 다 쓰지 말고, 적당히 스케일링 해서 나눈다.(shard) 가능한 Write 의 scale을 지원하는 BatchPutAttribute과 BatchDeleteAttributes 함수를 사용해라.
DB의 replication은 최근 데이터를 5초마다 Oracle에 poll하면서 이루어진다.
이렇게 Netflix는 AWS의 리소스를 잘 활용하여 서비스에 집중하고 있다. 만약 DB가 필요하다면 RDS를 쓸 것이다.
2010년까지는 이렇게 말했지만. 2011년에는 약간 달라졌다.
PPT를 보면, RDS 대신 Cassandra를 선택한 것으로 보인다. Simple DB보다 데이터를 저장하는 형태(Colum Family)가 더 좋고 CAP의 AP를 추구하고 있다는 점에서 선택한 것으로 보인다.
카산드라 API 중. Netflix 가 사용했던 API를 소개한다.
- 중간에 다시 보기 (Quorum)
datastore.get("Netflix", "Sid_Anand", Streaming Bookmarks -> Tron, ConsistencyLevel.QUORUM)
- 언제 회수되었나 (Fastest)
datastore.get_slice("Ntflix", "Sid_Anand", (DVD) Rental History -> 5678, ["Ship_TS", "Return_TS"], ConsistencyLevel.ONE)
- 얼마나 많이 DVD를 빌렸나? (fatest read)
datastore.get_count("Netflix", "Sid_Anand", (DVD)Rental History, ConsistencyLevel.ONE)
- write
datastore.batch_mutate("Netflix", mutation_map, ConsistencyLevel.QUORUM)
빠른 검색을 위해서 rows와 top-level columns은 저장되고, 인덱스된다. 또한. 다음의 것들은 큰 도움이 된다.
- Row : Bloom Filter
- Key Cache
- OS Page Cache를 크게 잡음
disk 읽는 것과 compaction이 일어날 만한 것이 있으면 성능이 나빠진다.
(카산드라는 Bigle Table에서 영향을 받았기 때문에 Hbase나 Amazone의 Dynnamo와 비슷하다.)
분산처리 모델은 총 5개를 참고했다 했다.
- Merkle Trees + Gossip -> Anti-Entropy (peer단위 전염 이론에 근거해 여러 개의 node가 최신 데이터로 복제하게함)
- Read-Repair(정합성이 깨지면 최신데이터로 복구)
- Consistent Hashing
- Staged Event Dreiven Architecture paper
- Dynamo paper
Netflix에게는 Cassandra 가 좋은 이유
1. Rich Value Model : value는 set of column 또는 super-column이다.
2. Data Limit이 없다.
SimpleDB은 제한이 있다. 1 item당 256 attributes, 1 domain당 1 billion attributes, 1 KB attribute value length
3. 데이터가 점점 커지면서 클러스터링이나 reshading이 관리 가능한 장점
Simple DB는 하나하나 개발자가 하나하나 해줘야 한다.
4. 타입 처리가 편함
Simple DB는 모두 UTF-8 스트링이지만, Cassandra는 native type과 소팅을 위한 type이 있음. 그리고, byte[]가 존재
5. 오픈 소스이고, 자바이다.
backup & recovery, recovery 정책을 마음대로 할 수 있다. 얼랭이 쿨하지만, 자바는 최고이다.
6. update-delete 변칙이 없다.
7. Consistency와 Avaiabilty에 대한 tradeoff를 조절할 수 있다.
- Strong consistency : Quorum Read/Write(중간 보던 영화 다시 보기)
- Eventual consistency
R=1, W=1 (fastest read and fastest write)
R=1, W=QUORUM (fastest read and potentially-slowser write)
R=QUORUM, W=1 (potentially-slower read and fastest write)
Netflix의 NoSQL Use-cases = public NoSQL + public cloud + customer traffic + R/W workload + high traffic conditions
중요 레퍼런스 :
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwcmFjdGljYWxjbG91ZGNvbXB1dGluZ3xneDo2NDc2ODVjY2ExY2Y1Zjcz
PDF 파운 ->
https://sites.google.com/site/practicalcloudcomputing/index/Netflix%E2%80%99sTransitiontoaKey_v3.1.pdf?attredirects=0&d=1
요약기사
http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-to-high-availability-storage-syste.html
참고 레퍼런스
1.
http://techblog.netflix.com/2011/03/nosql-netflix-talk-part-1.html
2.
http://wiki.apache.org/cassandra/API
아마존_AWS_서비스_연구3.docx
