잘 쓰고있던 MySQL 대신 MongoDB를 도입한 썰.ssul

  사내에서는 메인 데이터베이스는 MySQL, 사용목적에 맞게 Redis, Elastic Search, Bigquery 다양한 데이터베이스를 쓰고 있다. 하지만, 새로운 요구사항의 데이터의 적재가 필요한 상황을 맞이하게 되었다. 일단 운영하고 있는 데이터베이스에 때려 넣을까 솔직히 고민했지만, 생각하면 생각할수록 요구사항에 맞는 데이터베이스가 없었고, 새로운 데이터베이스인 MongoDB를 도입하게 되었다. 오늘은 그 썰을 풀어볼까 한다.

 

두둥두둥

 

당시 요구사항은 다음과 같았다.

• 방대한 양의 비정형 데이터를 적재해야하는 상황 (feat.팔로잉 기반 피드 아키텍처 설계하기)

• 정합성은 조금 떨어지더라도, 고가용성을 지원해야한다.

• 데이터 포맷이 향후 달라질 가능성이 있어서 유연한 스키마 구조를 가질 수 있다.

• 방대한 양을 감당할 수 있도록 높은 확장성을 가지고 있어야한다.

• 엄청난 빈도의 쓰기 연산을 감당할 수 있다.

• 조인은 필요없다.

 

MongoDB 장점

• 뛰어난 Read/Write 성능

• 높은 확장성

     • 데이터와 트래픽 증가에 따라 수평확장(scale-out) 가능

     • MongoDB는 데이터 샤딩을 지원

     • 이러한 샤딩과정은 서비스 중단없이 온라인으로 진행된다. 만약 특정 샤드에 데이터가 몰리면 다른 샤드로 데이터를 이동 시켜 전반적으로 모든 샤드가 균등하게 데이터를 저장할 수 있도록 해주며, 이러한 동작을 밸런싱이라고 한다.

 

• 스키마 프리

     • 사용할 컬럼을 미리 정의하지 않고 언제든지 필요한 시점에 데이터 저장가능하다.

     • 하지만 MongoDB는 모든 부분에 있어서 스키마 프리라고 보기는 어렵다, MongoDB는 보조 인덱스를 생성할 수 있는데, 보조인덱스는 스키마 프리가 아니라 항상 인덱스르 구성하는 필드를 정의해야한다.

 

 

 

MongoDB 단점

• 복잡한 Join 사용시 성능 제약

     • RDBMS와 같지는 않지만 Aggregation 기능을 이용하면 RDBMS와 비슷한 형태의 조인 처리를 수행할 수 있다. 하지만 샤딩 환경에서는 성능이 느려지기 때문에 권장하지 않는다고 한다.

 

• 트랜잭션 지원

     • MongoDB 4.0이 릴리즈 되면서 Replica Set에서 작동하는 다중 도큐먼트 트랜잭션에 대한 지원을 추가되었다.

     • 또, MongoDB 4.2의 릴리스와 함께 다중 도큐먼트 트랜잭션에 대한 지원이 Sharded Cluster로 확장되었다.

     • (짝수 버전이 안정화 버전, 홀수는 개발중인 버전)

     • 하지만 트랜잭션 지원이 RDBMS 보다는 미약하다.

 

MongoDB 특징

• BSON 형태로 저장

     • JSON 데이터를 그대로 저장하는 것이아닌, BSON(Binary Json)으로 변환하여 저장하므로 공백이나 마크업 문자로 인해 부가적으로 저장공간이 변하진 않는다.

 

• 커서 사용

     • MongoDB는 쿼리 결과로 커서를 사용, 이 커서를 통해서 반복적으로 실제 도큐먼트 (레코드)를 가지고 올 수 있다.

     • MongoDB에서 쿼리 결과로 커서를 반환하는 이유는 쿼리결과를 클리아이언트 서버 메모리에 모두 담아두지 않아도 처리할 수 있게하기 위해서다. 물론 커서를 읽을때마다 그때마다 도큐먼트를 가져오는 것은 아니고 필요할때마다 지정된 페이지 사이즈 단위로 서버로부터 전송받아 MongoDB 클라이언트 서버에 캐싱한 후에 유저에게 서비스하는 것이다.

 

레플리카셋 구성 방법

https://www.mongodb.com/docs/manual/replication/

• 프라이머리, 센컨드리. 아비터 조합!

• 아비터란?

     : 아비터 모드로 시작된 몽고디비는 레플리카 셋의 노드들과 히트비트만 주고 받으며, 데이터를 주고 받지 않는다. 프라이머리가 불능일때 프라이머리 노드의 선출에만 참여한다.

 

도입시 주의점 1) 슬로우쿼리 설정

[ MongoDB 로그파일 ]

 

  100밀리초가 넘게 걸린 쿼리는 MongoDB 서버의 로그파일에 모두 로깅된다. 100밀리초는 기본값이며, MongoDB 서버의 설정파일에서 slowMs 옵션을 조정하면된다. MongoDB 서버의 로그레벨을 디폴트 값 보다 더 자세히 또는 더 단순하게 변경하고자 한다면, 다음과 같이 db.setLogLevel()명령을 통해 서브 모듈별로 로그레벨을 조정할 수 있다. MongoDB 로그 사용시 주의점은 로그의 사이즈가 무제한으로 늘어난다는 것이다.이때문에 용량 문제가 생길 수 있으니, logrotate 설정이 필요하다.[1] 이번 포스팅이 너무 길어져서 다른 포스팅에서 더 구체적으로 설명해두었다. MongoDB에 Logrotate 설정하기

 

	db.setLogLevel(1);
	// 구성 요소에 대한 상세 수준 설정
	// systemLog.component.storage.journal.verbosity에 대해서 2로 설정
	db.setLogLevel(2, "storage.journal");

view raw mongodb_setLogLevel.js hosted with ❤ by GitHub

 

 

[ MongoDB 쿼리 프로파일링 ]

 

  MongoDB 서버의 로그 파일에는 매우 많은 정보가 기록되어 슬로우 쿼리 수집이 어려울 수 있다. 이런 경우에는 데이터베이스별로 저장되는 쿼리 프로파일링을 이용하는 것이 좋다. MongoDB는 100ms 이상 걸린 슬로우 쿼리에 대해서 해당 컬렉션이 존재하는 DB의 system.profile 컬렌션에 기록한다.

 

• 프로파일링 레벨 조정

   • 주의 ) MongoDB의 로그파일에는 적용되지 않고, system.profile 컬렌션에 기록되는 슬로우 쿼리 로깅에만 적용된다.

	db.getProfilingStatus()
	db.setProfilingLevel(1, 100) // 실행시간이 100ms 이상 걸린 쿼리만 로깅
	// 실행 시간 상관없이 모든 쿼리를 로깅
	db.setProfilingLevel(2)

view raw ProfilingLevel.js hosted with ❤ by GitHub

• 제한 용량

    system.profile은 1MB 정도의 슬로우 쿼리만 저장할 수 있다. 1MB 이상되면, 오래된 로그부터 삭제한다.

 

• 시간순 정렬하여 확인 쿼리

   슬로우 쿼리 로그를 확인할 때는 다음과 같이 역순으로 정렬해야 시간순으로 편히 볼 수 있다.

db.system.profile.find().sort({$natural:-1}).limit(3).pretty()

view raw profileFind.js hosted with ❤ by GitHub

 

 

[ 슬로우 쿼리 분석 ]

 

슬로우 쿼리 로그에서 주로 성능과 관련해서 살펴봐야하는 부분

• planSummary

   : 쿼리의 실행 계획

• keysExamined

   : 쿼리를 처리하기 위해서 인덱스에서 읽은 인덱스 키의 개수

• docsExamined

   : 쿼리를 처리하기 위해서 컬렉션의 데이터 파일에서 읽은 도큐먼트의 개수

• numYields

   • Yield : 장시간 쿼리가 실행되면 다른 커넥션들이 쿼리를 실행할 수 있도록 잠금을 해제했다가 다시 잠금을 획득하는 과정

   • 쿼리를 실행하는 도중에잠금을 얼마나 획득했는가를 의미

 

 

도입시 주의점 2) 쿼리 실행계획 분석 + 인덱스 설정

  처음 사용해보는 Database다보니, 쿼리 실행계획을 예측하기 어려웠다. 때문에 인덱스 설정에도 고민이 되었었다. 사용하는 모든 쿼리를 하나씩 돌려가면서 실행계획을 분석하고 인덱스를 만들어줬었다. 이번 포스팅이 너무 길어져서 다른 포스팅에서 더 구체적으로 설명해두었다. MongoDB에서 실행 계획 확인하는 방법

대충 이런식으로 쿼리 실행계획 보면서 인덱스 설정을 해주었다.

 

도입시 주의점 3) op: 'getmore' + batchSize

  MongoDB 클라이언트는 기본 배치 크기(default batch size)가 설정되어있고, 필요에 따라 이 값을 변경해 성능을 향상시킬 수 있다. 쿼리로그를 하나씩 보다보니 op:getmore 이 비정상적으로 많이 발생하는 것을 발견했고, 이를 수정했었습니다. 원래 MongoDB에서는 batchSize나 limit을 정해주지 않으면, 기본적으로 batchSize를 101로 지정한다. (batch 한번당 데이터가 1MB가 넘어가지 않는 선에서) 하지만 당시 사용하던 MongoDB 클라이언트에서 batchSize의 default가 2였기 때문에 getMore를 계속 실행한다는 문제점이 있었다. 실제로 LINE 기술 블로그에서는 이때문에 성능 문제를 겪었다고 한다. [3]

 

 

	[
	{
	op: 'getmore',
	ns: 'DB명.컬렉션명',
	command: {
	getMore: Long("8919504496005620780"),
	collection: '컬렉션명',
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584024, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	originatingCommand: {
	find: '컬렉션명',
	filter: { 컬럼명1: 6180 },
	projection: { 컬럼명2: 1, _id: 0 },
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584014, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	cursorid: Long("8919504496005620780"),
	keysExamined: 0,
	docsExamined: 0,
	cursorExhausted: true,
	numYield: 0,
	nreturned: 0,
	locks: {
	Global: { acquireCount: { r: Long("1") } },
	Mutex: { acquireCount: { r: Long("1") } }
	},
	flowControl: {},
	readConcern: { level: 'local', provenance: 'implicitDefault' },
	responseLength: 233,
	protocol: 'op_msg',
	millis: 0,
	planSummary: 'IXSCAN { 컬럼명1: 1, 컬럼명2: 1 }',
	execStats: {
	stage: 'PROJECTION_COVERED',
	nReturned: 46,
	executionTimeMillisEstimate: 0,
	works: 47,
	advanced: 46,
	needTime: 0,
	needYield: 0,
	saveState: 23,
	restoreState: 23,
	isEOF: 1,
	transformBy: {},
	inputStage: {
	stage: 'IXSCAN',
	nReturned: 46,
	executionTimeMillisEstimate: 0,
	works: 47,
	advanced: 46,
	needTime: 0,
	needYield: 0,
	saveState: 23,
	restoreState: 23,
	isEOF: 1,
	keyPattern: { 컬럼명1: 1, 컬럼명2: 1 },
	indexName: 'idx_컬럼명1_N_컬럼명2',
	isMultiKey: false,
	multiKeyPaths: { 컬럼명1: [], 컬럼명2: [] },
	isUnique: false,
	isSparse: false,
	isPartial: false,
	indexVersion: 2,
	direction: 'forward',
	indexBounds: {
	컬럼명1: [ '[6180, 6180]' ],
	컬럼명2: [ '[MinKey, MaxKey]' ]
	},
	keysExamined: 46,
	seeks: 1,
	dupsTested: 0,
	dupsDropped: 0
	}
	},
	ts: ISODate("2022-05-26T16:53:48.026Z"),
	client: '10.128.15.193',
	allUsers: [],
	user: ''
	},
	{
	op: 'getmore',
	ns: 'DB명.컬렉션명',
	command: {
	getMore: Long("8919504496005620780"),
	collection: '컬렉션명',
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584024, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	originatingCommand: {
	find: '컬렉션명',
	filter: { 컬럼명1: 6180 },
	projection: { 컬럼명2: 1, _id: 0 },
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584014, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	cursorid: Long("8919504496005620780"),
	keysExamined: 2,
	docsExamined: 0,
	numYield: 0,
	nreturned: 2,
	locks: {
	Global: { acquireCount: { r: Long("1") } },
	Mutex: { acquireCount: { r: Long("1") } }
	},
	flowControl: {},
	readConcern: { level: 'local', provenance: 'implicitDefault' },
	responseLength: 287,
	protocol: 'op_msg',
	millis: 0,
	planSummary: 'IXSCAN { 컬럼명1: 1, 컬럼명2: 1 }',
	execStats: {
	stage: 'PROJECTION_COVERED',
	nReturned: 46,
	executionTimeMillisEstimate: 0,
	works: 46,
	advanced: 46,
	needTime: 0,
	needYield: 0,
	saveState: 22,
	restoreState: 22,
	isEOF: 0,
	transformBy: {},
	inputStage: {
	stage: 'IXSCAN',
	nReturned: 46,
	executionTimeMillisEstimate: 0,
	works: 46,
	advanced: 46,
	needTime: 0,
	needYield: 0,
	saveState: 22,
	restoreState: 22,
	isEOF: 0,
	keyPattern: { 컬럼명1: 1, 컬럼명2: 1 },
	indexName: 'idx_컬럼명1_N_컬럼명2',
	isMultiKey: false,
	multiKeyPaths: { 컬럼명1: [], 컬럼명2: [] },
	isUnique: false,
	isSparse: false,
	isPartial: false,
	indexVersion: 2,
	direction: 'forward',
	indexBounds: {
	컬럼명1: [ '[6180, 6180]' ],
	컬럼명2: [ '[MinKey, MaxKey]' ]
	},
	keysExamined: 46,
	seeks: 1,
	dupsTested: 0,
	dupsDropped: 0
	}
	},
	ts: ISODate("2022-05-26T16:53:47.824Z"),
	client: '10.128.15.193',
	allUsers: [],
	user: ''
	},
	{
	op: 'getmore',
	ns: 'DB명.컬렉션명',
	command: {
	getMore: Long("8919504496005620780"),
	collection: '컬렉션명',
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584024, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	originatingCommand: {
	find: '컬렉션명',
	filter: { 컬럼명1: 6180 },
	projection: { 컬럼명2: 1, _id: 0 },
	batchSize: 2,
	'$db': 'DB명',
	'$clusterTime': {
	clusterTime: Timestamp({ t: 1653584014, i: 1 }),
	signature: {
	hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
	keyId: Long("0")
	}
	},
	lsid: { id: UUID("40c94449-4136-4014-8f5a-93fdc0635af1") }
	},
	cursorid: Long("8919504496005620780"),
	keysExamined: 2,
	docsExamined: 0,
	numYield: 0,
	nreturned: 2,
	locks: {
	Global: { acquireCount: { r: Long("1") } },
	Mutex: { acquireCount: { r: Long("1") } }
	},
	flowControl: {},
	readConcern: { level: 'local', provenance: 'implicitDefault' },
	responseLength: 287,
	protocol: 'op_msg',
	millis: 0,
	planSummary: 'IXSCAN { 컬럼명1: 1, 컬럼명2: 1 }',
	execStats: {
	stage: 'PROJECTION_COVERED',
	nReturned: 44,
	executionTimeMillisEstimate: 0,
	works: 44,
	advanced: 44,
	needTime: 0,
	needYield: 0,
	saveState: 21,
	restoreState: 21,
	isEOF: 0,
	transformBy: {},
	inputStage: {
	stage: 'IXSCAN',
	nReturned: 44,
	executionTimeMillisEstimate: 0,
	works: 44,
	advanced: 44,
	needTime: 0,
	needYield: 0,
	saveState: 21,
	restoreState: 21,
	isEOF: 0,
	keyPattern: { 컬럼명1: 1, 컬럼명2: 1 },
	indexName: 'idx_컬럼명1_N_컬럼명2',
	isMultiKey: false,
	multiKeyPaths: { 컬럼명1: [], 컬럼명2: [] },
	isUnique: false,
	isSparse: false,
	isPartial: false,
	indexVersion: 2,
	direction: 'forward',
	indexBounds: {
	컬럼명1: [ '[6180, 6180]' ],
	컬럼명2: [ '[MinKey, MaxKey]' ]
	},
	keysExamined: 44,
	seeks: 1,
	dupsTested: 0,
	dupsDropped: 0
	}
	},
	ts: ISODate("2022-05-26T16:53:47.626Z"),
	client: '10.128.15.193',
	allUsers: [],
	user: ''
	}
	]

view raw getmore.js hosted with ❤ by GitHub

 

마무리

   MongoDB 적용은 사실 상당히 가성비있게 적용했었다. 주어진 시간이 그리 많았던 것은 아니기때문에, 우선 Real MongoDB 책을 빠르게 훑었다.[4] 책 중에서는 빠른 도입 + 성능을 위해서 레플리카 셋, 인덱스, 데이터 모델링, 쿼리 최적화 부분만 힘줘서 읽고 나머지는 넘기거나 빠르게 훑었다. 이후에는 “don't use mongodb” “mongoDB 장애” 키워드로 검색하면서 최대한 장애를 미리 예방하려고 했었다.

  도입한지 6개월정도가 되었는데 아직까진 크게 문제없이 사용하고 있다. MySQL을 완벽하게 대체할 수 있다! 라는 의견에는 아직까진 모르겠지만, MongoDB만의 장점이있고, 만약 정합성이 중요하지 않은 기능이라면 적극적으로 사용해도 좋을 DB라고 생각한다. 돌이켜보면 이때 처음으로 RDBMS이 아닌, NoSQL인 MongoDB를 공부하면서 설레고 재밌어했었던것 같다.

 

 

[1] https://www.mongodb.com/docs/manual/reference/method/db.setLogLevel

[3] https://engineering.linecorp.com/ko/blog/LINE-integrated-notification-center-from-redis-to-mongodb

[4] 대용량 데이터 처리를 위한 Real MongoDB : 이성욱, 2018, 위키북스