[124]네이버에서 사용되는 여러가지 Data Platform, 그리고 MongoDB

5. Web server
Database
(RDBMS)
초창기에는 거의 모든 서비스가 Web server <-> RDBMS server의 2 tier 구조

6. Cache
(Redis,
ARCUS)
서비스가 점점 커지면서, DB Query는 점점 복잡하고 무거워 짐
빠른 응답을 보장하기 위해, DB 앞에 Cache 추가
Web server
Database
(RDBMS)

7. 지표를 저장하기에는 RDBMS 는 공간과 비용에서 문제가 발생
원활한 데이터 처리를 위해 HBase 사용
Cache
(Redis,
ARCUS)
Web server
Database
(RDBMS)

9. 기존에 저희가 지원하고 있던 Data Platform에서는 Cover 되지 않는 영역이 필요해 짐
MongoDB를 설치해서 자체적으로 운영하는 개발팀이 늘어남
 schema-less 하고 sharding과 secondary Index ,Transaction 처리가 가능한
Data Platform MongoDB도 지원하게 됨

10. Schemaless : 사전에 데이터에 대한 구조나 정의를 하지 않아도 됨
서비스의 종류가 많아지면서 공통적인 부분을 플랫폼화
공통 플랫폼은 각 서비스의 요구사항에 따른 스키마 처리와 데이터 처리가 고민이 됨
 RDBMS 라면, 각 서비스 별 별도의 table 로 관리해야 하거나, column 추가& 삭제 등의
서비스 중 overhead 발생
공통
플랫폼

11. tableA {
userNumber int
,userCellPhoneNumber char(13) }
RDBMS
MongoDB
1row 당 17 byte
1document 당 46 byte
(_id 포함 시 58byte)
RDBMS 에 비해서 disk read /write ( IO) 가 큰 폭으로 증가할 수 있으며,
DB Memory Buffer 에도 상대적으로 적은 수의 document 가 존재
-> 성능상 취약해 질 가능성 큼

12. 서비스 규모가 커지면서 데이터 사이즈가 증가하며, Scale up의 한계가 대두됨
RDBMS는 응용에서 샤딩으로 Scale out 구현 할 수 있지만 확장성이 떨어지며,
개발 및 관리의 overhead 발생  Auto Sharding이 가능한 Data Platform이 필요

13. 단순 bigdata성 데이터는 HBase를 사용하고 있음 ( 인프라 운영비용 절감 )
조회 조건이 다양해짐에 따라 Secondary Index에 대한 기능이 필요해짐
HBase는 제품 자체에서 Secondary Index를 제공해주지 않음
Coprocessor, hIndex , Phoenix 을 통해 secondary Index와 비슷하게 구현은 가능
HBase Rowid 가 아닌 조건으로의 조회는 전제 region full scan 으로 처리되어야 함

14. MongoDB Chunk 논리적 분리
Collection A
DATA FILE
ChunkHFile
방식 장점 단점
HBase
각 리전별로 별도의 HFile 로 존재->
HDFS 에 별도의 물리적 File로 리전별 할당
리전간 HFile move가 용이 secondary index 불가능
MongoDB
청크별로 별도 file 이 있는 것이 아니며,
하나의 collection 에서 샤딩키에 따른 논리적 할당
secondary index 가능 chunk migration시 부하가 있음

15. NoSQL을 사용하면서, Transaction 기능을 원하는 경우가 있음
MongoDB는 WiredTiger storage 엔진을 사용할 경우 높은 수준의 ACID 지원
 ~ 3.6 까지 1 document ( row level lock )
 4.0 부터 단일 replica set에서 Multi-Document Transaction
s.start_transaction()
orders.insert_one(order, session=s)
stock.update_one(item, stockUpdate, session=s)
s.commit_transaction()

16. REST API 사용이 확대되면서, 메시지 포맷을 JSON으로 사용할 경우
Web Server와 DB Server간 데이터 주고받는 과정에서 JSON 을 선호
 JSON 포맷을 편하게 지원해줄 Data Platform이 필요
{
"name": " ",
"country": "ko",
“job": "dba",
}

17. 서비스 커지고, 중요도가 높아짐에 따라 IDC 이중화 (DR: disaster recovery) 요구됨
 MongoDB는 IDC 간 Auto failover가 가능한 Data Platform
 IDC DR을 필요로 하는 서비스에 도입할 수 있음
-> MongoDB 충족 -> 주요 서비스에 도입 되려고 시도 되는 편 (아직은 아님)

19. 제조사 권장은 Mongos (router) 를 client 와 같이 배포 권장 -> 사용하고 있지 않음
MongoDB 가 Main Data Platform 이 아닌 경우 배포/관리 의 어려움 때문 (& 권한관리)
Web server
mongos
Web server
mongos
Web server
mongos
config
mongod
primary
mongod
secondary
mongod
secondary
config
mongod
primary
mongod
secondary
mongod
secondary

20. Sharding 에서의 L4 (network switch) 사용을 초기에는 권장했으나 getmore 이슈로 제거
Getmore - 20건 단위로 데이터 전달하는 과정
mongod
primary
mongod
secondary
mongod
secondary
mongod
primary
mongod
secondary
mongod
secondary
Web server
Web server
Web server
mongos
L4
Config Server

21. Mongos 와 shard server 사이에 커넥션 관리에 문제가 있음
다음과 같은 옵션을 적용하여 사용
shardingTaskExecutorPoolHostTimeoutMS : 3600000
ShardingTaskExecutorPoolMaxSize : 20
ShardingTaskExecutorPoolMinSize : 10
Web server mongos mongod
primary
mongod
secondary
mongod
secondary
[default]
Max: Unlimited
Min: 1개 (per core)
[tuning]
Max: 20개 (per core)
Min: 10개 (per core)
Config
Server

22. Node.js 모듈인 mongoose 는 성능 이슈로 인해 권장하지 않음
Node.js 드라이버 3.X 버전은 커넥션 반환 관련 이슈가 있음
 Node.js 드라이버 2.X 사용 권장

23. WiredTiger 스토리지 엔진만 사용,
MMAPV1 및 3rd party ( mongo rocks , tokumx ) 지원하지 않음
MMAPv1  성능상 문제 ( document level lock 등)
3rd party  트러블 슈팅 문제 등
하위 버전에서 발생된 이슈가 해결된 안정화된 최신버전을 사용
아직 하위 버전을 사용하고 있다면 다음의 경우 업그레이드를 고려해주시기 바랍니다.

24. 3.0, 3.2.x 이하버전에서 WiredTiger 엔진 사용시에 문제 발생 할 수 있습니다.
eviction : Memory Buffer 에서 오래된 data 삭제하는 작업
이슈가 어느정도 해결된 3.2.11 또는 3.4 이상 버전을 사용하길 권장하며,
버전을 올린 이후 안정적으로 운영되고 있습니다.
bytes currently in the cache / maximum bytes configured
pages evictied by application threads
pages walked for eviction

25. checkpoint : memory buffer 와 disk 사이의 데이터 불일치를 해소하기 위해서
memory -> disk 로 data sync 하는 작업
WiredTiger 스토리지 엔진, 샤프 체크포인트 방식
체크포인트가 실행되는 시점에 한번에 디스크 쓰기 발생
Write heavy 한 환경에서 Checkpoint시 성능이 하락됨
주기적으로 Disk IO가 높아진다면 checkpoint가 문제일 가능성이 있음

27. Mongodb는 background index 생성 가능 ( = RDBMS 의 online index create )
내부적으로 매우 짧은 시간을 주기로 인덱스 생성 / 생성 중단 / 쿼리 수행 과정을 반복
인덱스 생성 process 시, db lock 이 유발되어 쓰기 쿼리 지연이 발생
 Background Index 생성은 새벽에 진행

28. 컬렉션의 모든 데이터와 인덱스를 다시 작성하고 조각모음을 수행하여, 불필요한 디스크
공간을 해제하는 작업
작업 중 질의 수행이 안되기 때문에 서비스에서 제외하고 진행해야 함
secondary DB를 재구성하는 것으로 공간을 확보하고 있음

29. MongoDB의 Chunk Migration은 많은 비용이 듦
여러 이유로 Balancing작업이 실패할 수 있음
 Config server에서 changelog 를 자주 살펴봄
 응답 속도에 민감한 서비스는 새벽시간에만 수행되도록 조절

30. Clusterd index : 해당 key 값 기준으로 실제 데이터가 정렬되어 있음
Clustered Index 가 없어서,
Clustered Index 방식을 활용한 범위 검색 등에는 MongoDB 권장 하고 있지 않습니다.
data File
Internal Index (clustered type) Secondary Index (B-tree type)
Index File
Index entries
data
Index entries
data
Index key ,
pointer
_id, data
random I/O 발생

31. Sharding 환경에서 unique Index는 전체 shard 내에서 유니크 하지 않음
 인덱스가 local 기반이라, 각 shard 별로 유니크 함
 전체 DB내에서의 Unique를 보장하기 위해서는 sharding key 에 포함 필요
Collection A
Data File
Collection B
Data File
Collection A
Data File
Collection B
Data File

32. 법적 조치 대상에 해당 하는 Data Platform 으로 MongoDB 사용하고 있음
법적 요건을 지키기 위해서는 여러 영역을 확인해야 함.
DB영역의 법적 요건 ( IP 기반 access control) 을 지키기 위해서
MongoDB 3.6 버전의 authenticationRestrictions 기능 사용 중
bind_ip 는 DB ACL을 제한하는 기능이 아님

34. NoSQL 의 특징과 RDBMS 의 특징을 고루 가지고 있는 DBMS

35. Checkpoint 등 일부 성능상 문제점 해결 시급
Mongos <-> shard 사이에 커넥션 안정화
한글 전문 검색 문제 해결 필요 등등 아직까지 문제점 많음…
WiredTiger 엔진에서 B-tree 이외에 LSM 도 지원이 됐으면…

36. NoSQL특성상 RDBMS만큼의 ACID와 안정성을 보장해주지 않기 때문에,
우리나라에서 Main Stream 으로 도입될 가능성은 높지 않다고 보여집니다.
다만 사용처는 점점 확대될 것으로 보이고 있으며, 저희 회사에서도 적극 지원하려고
합니다.

37. NBP는 네이버 클라우드 플랫폼을 통해
네이버의 인프라 기술을 클라우드로 제공하고 있습니다.
완전 관리형 DB 상품인 Cloud DB for MySQL / MSSQL / Redis,
Cloud Hadoop 상품에 이어 MongoDB 상품도 준비중입니다.