지난 SK 플래닛 테크플래닛 2012에서 발표했던 'Redis, MongoDB 그리고 MySQL과 함께하는 모바일 애플리케이션 로그 수집과 분석'의 PDF 버전입니다.
스마트스터디( http://smarstudy.co.kr )가 200개 이상의 앱을 런칭하고 더 나은 서비스를 만들기 위해 사용하고 있는 로그 수집과 분석 시스템에 대한 소개 문서입니다.
하둡과 카산드라로 대표되는 빅데이터 시장에서, 제한된 자원과 인력으로 기존의 기술을 최대한 활용하고 있는 방법에 대해 발표하였습니다.
저는 성공담보다는 실패담을 더 신용합니다. 이번 발표에서도 'MongoDB는 나쁘다, Redis가 좋다'의 이야기보다는 이러한 상황에서 어떻게 대응했고, 이런 단점이 있어서 이렇게 극복했다는 이야기를 하고 싶었습니다.
감사합니다.
This document discusses the results of a NoSQL database benchmark test conducted by NHN on Cassandra, HBase and MongoDB. It describes the test environment and four test cases performed: data insertion, random reads and updates on existing data, reads only on existing data, and random reads and inserts with additional data added. The test measured average transactions per second for each database and test case. Cassandra and HBase performance varied depending on compaction levels while MongoDB update and insert performance lagged the others.
Spark Streaming allows for scalable, high-throughput, fault-tolerant stream processing of live data streams. It works by chopping data streams into batches, treating each batch as an RDD, and processing them using RDD transformations and operations. This provides a simple abstraction called a DStream that represents a continuous stream of data as a series of RDDs. Transformations applied to DStreams are similarly applied to the underlying RDDs. Spark Streaming also supports window operations, output operations, and integrating streaming with Spark's ML and graph processing capabilities.
This document discusses the results of a NoSQL database benchmark test conducted by NHN on Cassandra, HBase and MongoDB. It describes the test environment and four test cases performed: data insertion, random reads and updates on existing data, reads only on existing data, and random reads and inserts with additional data added. The test measured average transactions per second for each database and test case. Cassandra and HBase performance varied depending on compaction levels while MongoDB update and insert performance lagged the others.
Spark Streaming allows for scalable, high-throughput, fault-tolerant stream processing of live data streams. It works by chopping data streams into batches, treating each batch as an RDD, and processing them using RDD transformations and operations. This provides a simple abstraction called a DStream that represents a continuous stream of data as a series of RDDs. Transformations applied to DStreams are similarly applied to the underlying RDDs. Spark Streaming also supports window operations, output operations, and integrating streaming with Spark's ML and graph processing capabilities.
This document provides an overview of NoSQL databases. It begins by defining NoSQL as non-relational databases that are distributed, open source, and horizontally scalable. It then discusses some of the limitations of relational databases that led to the rise of NoSQL, such as issues with scalability and the need for flexible schemas. The document also summarizes some key NoSQL concepts, including the CAP theorem, ACID versus BASE, and eventual consistency. It provides examples of use cases for NoSQL databases and discusses some common NoSQL database types and how they address scalability.
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
The document discusses the author's experience working at a startup company. It describes the startup office environment and culture, which emphasizes an agile and flexible work style. The author advises readers to take chances and get experience working at startups early in their careers to help them learn and grow professionally. They should start small with projects but work steadily to build skills and experience.
This document provides an overview of NoSQL databases. It begins by defining NoSQL as non-relational databases that are distributed, open source, and horizontally scalable. It then discusses some of the limitations of relational databases that led to the rise of NoSQL, such as issues with scalability and the need for flexible schemas. The document also summarizes some key NoSQL concepts, including the CAP theorem, ACID versus BASE, and eventual consistency. It provides examples of use cases for NoSQL databases and discusses some common NoSQL database types and how they address scalability.
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
The document discusses the author's experience working at a startup company. It describes the startup office environment and culture, which emphasizes an agile and flexible work style. The author advises readers to take chances and get experience working at startups early in their careers to help them learn and grow professionally. They should start small with projects but work steadily to build skills and experience.
WHAT / WHY / HOW WE’RE ENGINEERING AT SMARTSTUDY (English)Hyun-woo Park
This document describes what SmartStudy does as an engineering company, why they do it, and how they do it. It summarizes:
1) SmartStudy develops mobile apps, log crawlers, log analyzers, push solutions, web-based tools, and open source projects to help products and services, not just for new technologies.
2) They do this to understand user behavior from logs and provide insights, as well as build tools that are easily updatable and globally accessible.
3) SmartStudy engineers work across multiple platforms, use open source technologies, and aim to refine code into shared libraries over time to prevent duplicative work.
Using AWS CloudFront with S3 at SMARTSTUDYHyun-woo Park
This document discusses using Amazon S3 and CloudFront together. S3 provides durable storage of files across multiple regions, while CloudFront is a content delivery network (CDN) that distributes files across its global edge network for fast delivery. The author's company uses S3 and CloudFront to serve large multimedia files to a global mobile audience. They upload files to S3 and use the s3cmd tool to sync files to CloudFront for distribution, taking advantage of features like automatic invalidation of cached files. Overall, the combination of S3 and CloudFront provides redundant, fast, and cost-effective global content delivery.
31. 모바일 환경
•항상 로그 전송이 가능한 상태는 아님.
•JSON 형태로 로컬 저장소에 보관하다,
•n개까지 모으거나, 필요한 경우 즉시 발송.
•서버에서는 받은 후, 낱개로 풀어서 저장.
32. 장애 대응
•HTTP / HTTPS 로 전송
•200 OK 응답을 받지 못한 경우 장치에 보관
•IDC 이전시 효과적으로 활용
33. Speaker’s note
• 기존에 하던 방식과 비슷하지만, 서버의 응답을 확인해
서 200 OK 를 받지 않으면 로컬 큐에서 해당 로그를 제
거하지 않고, 다음에 다시 보낼 수 있도록 합니다.
• 이를 이용해, 올해 IDC를 이전하면서 약 5-6시간 정도의
장애가 있었는데 해당 기간의 로그를 잃어버리지 않고,
대부분 회수할 수 있었습니다.
• 물론, 네트워크가 활성화되지 않은 상태에서 한 번 켜고,
다시 켜지 않으면 해당 로그는 잃어버리지만, 감당할 수
있는 범위의 loss라고 판단했습니다.
34. 로그 스토리지 검토
•자원 = 개발자 + 시간 + 돈
•자원이 부족했기에 제한된 선택만 가능
•대용량 처리 능력보다 사용 편의성에 중점
•Hadoop, Cassandra 등은 개발 역량과다
운용비용 부족
35.
36. 해결
•기존 : MySQL은 지속적으로 확장하기 어렵다.
•ReplicaSet, Sharding을 지원한다.
•기존 : 어쨌든 스키마를 매번 만들어야 한다.
•JSON 형식으로 자유롭게 저장 가능.
•기존 : 쌓는 중엔 형식 변경 비용이 비싸다.
•원한다면 언제든지 내용을 바꿀 수 있다.
37.
38.
39. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
40. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php
IL E D
mod_php mod_php
FA
900+ connections
41. Speaker’s note
• 접속자가 늘어나 900 커넥션이 넘어가자 더 이상 동작
할 수 없는 상황에 이르게 됩니다.
• 락 작업과 쓰기에 바빠 더 이상의 접속을 허용하는 것이
무의미해집니다.
• MongoDB는 시스템 ulimit의 80%가 기본 커넥션 제한
값이고, 최대 2만개의 연결을 허용하지만, 천개쯤만 되어
도 장애 상태가 되었습니다.
42. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
900+ connections
43. Server Server Server
•
Apache httpd
Apache httpd mpm_prefork 사용 httpd
Apache httpd Apache
•프로세스마다 커넥션을 요구 mod_php
mod_php mod_php
•연결 폭주, 서비스 장애 발생
•MongoDB Global write lock 문제
900+ connections
위 상황은 MongoDB 1.6.3 을 가정함
44. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
Predis Predis Predis
Redis Redis Redis
45. Speaker’s note
• 매 사용자 연결 마다 커넥션을 맺는 것이 불합리하므로,
한 곳에 모아 일괄적으로 넣으면 어떨까 생각이 들어
redis를 도입했습니다.
• MySQL 같은 경우에도 여러 트랜잭션으로 insert 하는
것에 비해 한 트랜잭션에 몰아 넣는 것이 효율적이므로,
같은 방식으로 적용해봤습니다.
• 이에 php의 Predis 모듈을 활용하게 되었습니다.
46. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
Predis Predis Predis
Redis Redis Redis
47. Server Server Server
Redis
Apache httpd
mod_php
Apache httpd
mod_php
Apache httpd
mod_php
• Predis
In-memory Key-Value Storage by Predis C
Predis ANSI
•Replication, Cluster 지원
•다양한 데이터 타입 지원
Redis Redis Redis
•strings, hashes, lists, sets, sorted sets
48. Link
• @charsyam blog (very useful)
• http://charsyam.wordpress.com/category/cloud/redis/
• Redis를 이용한 MongoDB 기반 로그 수집기 성능 개선
• http://blog.naver.com/ez_/140158788246
• Predis, using redis on PHP
• http://blog.naver.com/ez_/140158670703
49. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
•Redis를 일종의 버퍼로 사용
•Predis bulkInsertPredis
모아서 가능 Predis
•로그 수 파악을 위한 캐시 UPDATE 명령 절약
•피크시 200 log/sec 에서 ~3MB의 메모리 사용
Redis Redis Redis
50. Speaker’s note
• percona에서 제공하는 모니터링 플러그인을 사용해서
모니터링합니다.
• http://www.percona.com/software/percona-monitoring-plugins
• cacti로 관찰한 것 뿐 아니라, mongostat 이나 mongod
의 웹 페이지를 통해 mongo의 상태를 보는 것도 좋습니
다.
• 서비스/이벤트, 즉 로그의 종류에 따라 몇 개나 쌓았는지
를 기록하는데, 이를 로그를 쌓으면서 같이 업데이트 합
니다. 이 쿼리 또한 벌크로 넣으면서 절약할 수 있었습니
다.
51. Server Server Server
•MongoDB 버전에 따라 write lock 개선
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
Version Level Description
Predis
1.6 Predis
Global Predis
2.0 Global locking-with-yield
2.2 Database
Redis
Future
Redis
Collection
Redis
52. Speaker’s note
• 1.6 시절과 달리 MongoDB 는 많은 발전을 이뤄, redis /
memcached 등의 레이어를 두고 쓰던 사용자들 중 일부
는 2.0으로 업그레이드 하며 캐시 레이어를 제거했다는
글을 쓰기도 했습니다.
• locking-with-yield 기능을 통해 page fault 상황에서 쓰
기 성능이 극적으로 개선된 벤치마크를 살펴볼 수 있습
니다.
• 앞으로는 전역 lock, 데이터베이스 단위 lock을 넘어 콜
렉션, 즉 테이블 수준의 락을 지원한다고 합니다. 언젠가
는 RDB 수준의 object 단위 락도 기대할 수 있지 않을
까 보고 있습니다.
53. Link
• Removing Memcached because it’s too slow
• http://blog.serverdensity.com/removing-memcached-because-its-too-slow/
• 번역 : http://charsyam.wordpress.com/2012/06/08/
• Goodbye global lock – MongoDB 2.0 vs 2.2
• http://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/
• 번역 : http://charsyam.wordpress.com/2012/05/24
54. Server Server Server
Apache httpd Apache httpd Apache httpd
mod_php mod_php mod_php
Predis Predis Predis
Redis
55. Speaker’s note
• 여러 대의 Redis 를 써야할 정도로 Redis에 부하를 주지
않아, 1대의 Redis로 옮겼고, 그 배경에는 서로 다른
Redis 에 데이터를 부어 넣음에 따른 로그의 순서 문제
도 있었습니다.
• Redis에 들어가 있는 순서대로 MongoDB에 들어가게
되는데, 1분 단위로 서로 다른 타이밍에 MongoDB에 부
어 넣으면서, 순차적이지 않은 문제가 있어 변경하게 되
었습니다.
57. Master Replication Diagram
Slave
IL E D
Analytics
Active / Standby
FA Map / Reduce
~10,000,000 logs/일
58. MongoDB
•
Master
Redis를 버퍼로 사용
Replication Diagram
• 서비스는 ReplicaSet UPDATE 명령
•실로그 수 파악을 위한 캐시추천 Analytics절약
Slave
•150 log/sec 에서 2TB x 6 RAID 10사용 사용
• 16GB RAM, SATA ~3MB의 메모리 장비
•MongoDB 점검이나 이관시에 매우 유용
•현재 약 13억 건, 1TB의 데이터를 축적
•도저히 장비 1대로 Map / Reduce 할 수가 없음
•Sharding 등을 포기하고 다른 방법을 시도
60. Active / Standby Map / Reduce
MySQL /MyISAM
•SQL에 친숙하다
•운용 경험이 있다
•계속 쌓기만 하면 빠른 편
61. Active / Standby Map / Reduce
Master
Slave Slave
•16GB RAM, SATA 2TB x 4 RAID 10 장비 사용
62. Speaker’s note
• MongoDB와 마찬가지로 3대의 MySQL 을 구동하고 있
으며,
• 2+1대를 운용하는 것은, 한 대의 장비에 장애가 생겼을
경우, 2대로 구성된 M/S 구조라면 HA가 바로 깨어지는
문제가 있을 뿐 아니라, 성능 개선이나 확장을 위해 Slave
장비를 교체하는 경우에도 마찬가지입니다.
• 현재 하나의 Slave는 통계 전용으로 쓰고, 하나는 서비스
에서 읽기 전용 데이터를 읽는데 사용해 낭비를 최소화
하고 있습니다.
65. SQL to MongoDB
SQL
SELECT DISTINCT last_name FROM users
MongoDB E
db.users.distinct('last_name') FAK
Speaker’s note : distinct 로 10,000개 이상을 처리할 수 없습니다.
66. SQL to MongoDB
SQL
SELECT team, SUM(score) AS total, COUNT(*)
FROM scoreboard
GROUP BY team
ORDER BY total DESC
67. SQL to MongoDB
MongoDB
db.scoreboard.group({
key: { team: true },
initial: { total: 0, count:0 },
reduce: function(obj, prev) {
prev.total += obj.score;
prev.count += 1;
G O D
Y
}
})
M
H NO SO
O RT
68. SQL to MongoDB
SQL
SELECT msg FROM feed
WHERE user_id IN
( SELECT id_to FROM friend
WHERE id_from = x )
ORDER BY written_dt
DESC LIMIT 10
69. SQL to MongoDB
MongoDB
db.feed.find(
{ user_id: { $in: db.friend.group( {
cond: { id_from: x }, initial:
O
{ friends: [] },
RE
RDC
reduce: function(obj, prev) {
} H A
prev.friends.push(obj.id_to);
} )[‘friends’] }, { msg:1, _id:0 } )
.sort( { written_dt: -1 } )
.limit( 10 );
70. Active / Standby Map / Reduce
PV / UV
DAU / MAU
PU / ARPU
NRU / RR
71. MongoDB to MySQL
•1분 단위로 전송
•_id 값을 이용해 중복 피함
•String을 Integer로 변환 > GROUP 용이
•익숙한 SQL을 통해 원하는 데이터 추출
•추출된 데이터를 다시 MySQL에 저장
72. Speaker’s note
• 로그를 생성한 시점의 디바이스 시간이 JSON에 포함되
어 있고, Redis가 받은 시간과 MongoDB로 넣은 시간까
지 기록하므로, 여러 로그를 한 번에 수집하고, 1분 단위
로 벌크 인서트를 수행하더라도, 로그들 사이의 상대적
인 시간 관계를 확인할 수 있습니다.
• 개인 식별자, 기기 종류, 앱 ID, 이벤트 ID, 시간, 타임존,
언어 설정 등을 수집합니다.
• String에서 Integer로 변환하기 위한 Lookup 테이블을
생성하고, 이를 지속적으로 업데이트 합니다.
87. 바퀴의 재발명
baas.io http://baas.io/
Google Analytics http://google.com/analytics
Flurry http://www.flurry.com/
88. Speaker’s note
• 이미 다양한 로그 수집 애플리케이션이 존재하므로, 알
아보지 않고 새로운 것을 만드는 것은 낭비입니다.
• 수집하고자 하는 내용과 분량에 따라 적합한 솔루션을
선택해 기회 비용을 낭비하지 않을 수 있습니다.
• 로그 수집뿐 아니라 분석과 통계까지 제공하는 다양한
솔루션을 활용할 수도 있습니다.