AWS DocumentDB Failover 동작 방식에 대한 이해

 

 

 

 

 

AWS DocumentDB 를 몇가지 테스트 해보며 내용을 정리해 본다.

이번 포스팅에는 DocumentDB 의 Failover 동작 절차에 대해 알아보자.

DocumentDB 의 경우 MongoDB replicaSet 을 이용해 고가용성을 유지하는데,

각 멤버에서 장애가 발생했을 경우 어떤식으로 동작하는지 알아보았다.

 

크게 1) Secondary 장애시 2) Primary 장애시 3) Console을 통해 Failover 를 수행시 어떻게 동작하는지 알아보자.

 

1) Secondary 멤버가 다운 되었을때

  Secondary 멤버가 다운된 경우에는 특별한 이상 없이 서비스가 지속된다.

  다만, Read preference 를 설정하여, secondary 로 읽기 명령을 수행한 경우에는 다운된 secondary 쪽으로 읽기 명령을 보낸 경우 순간적으로 error 를 발생할 수 있다. 

  테스트를 해보니 secondary 로 read preference 설정시 읽기의 경우 1초 내외로 conneciton error 가 발생되는 경우가 있었다. 

  primary 로 설정시는 서비스에 영향이 없다.

{
    "set" : "rs0",
    "date" : ISODate("2019-05-23T02:45:35Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "mongodb-instance-0.ap-northeast-2.docdb.amazonaws.com:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 2105
        },
        {
            "_id" : 1,
            "name" : "mongodb-instance-1.ap-northeast-2.docdb.amazonaws.com:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 2105
        },
        {
            "_id" : 2,
            "name" : "mongodb-instance-2.ap-northeast-2.docdb.amazonaws.com:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "self" : true,
            "uptime" : 2105
        }
    ],
    "ok" : 1
}

 

 

2) Primary 멤버가 다운 되었을때

  Primary 멤버가 다운 된 경우, DocumentDB는 기존의 MongoDB의 방식과는 조금 다르게 동작한다.

  기존 MongoDB 의 ReplicaSet 의 경우는 Secondary 멤버중 하나가 선출되어 Primary 로 승계되는데 반해

  DocumentDB의 경우는 아예 ReplicaSet 재설정을 시도한다.

 

  Primary 멤버를 리부팅해서 테스트 해보니 아래와 같이 ReplicaSet 이 새롭게 설정되는 모습을 볼 수 있다.

 

  (1) Primary 가 재부팅되면 먼저 MongoDB의 접속이 끊어지게 된다.

MongoDB shell version v3.6.3
connecting to: mongodb://mongodb-cluster.cluster.ap-northeast-2.docdb.amazonaws.com:27017/
2019-05-29T02:11:35.524+0000 W NETWORK  [thread1] Failed to connect to 172.16.34.150:27017, in(checking socket for error after poll), reason: Connection refused
2019-05-29T02:11:35.524+0000 E QUERY    [thread1] Error: couldn't connect to server mongodb-cluster.ap-northeast-2.docdb.amazonaws.com:27017, connection attempt failed :
connect@src/mongo/shell/mongo.js:251:13
@(connect):1:6
exception: connect failed

 

 (2) 몇 초가 지난후 재 접속해서 rs.status() 를 확인해 보면, ReplicaSet에는 Primary 한대만 구성되어 있는 것을 볼 수 있다.

     Cluster endpoint 와 member는 도메인으로 기존과 동일하게 유지해 주기 때문에 Client쪽에는 특별히 처리할 것은 없다. 

 

     Primary 의 uptime이 reset 된 것을 보니 ReplicaSet 을 새롭게 구성한 것으로 확인된다.

rs0:PRIMARY> rs.status()

{
	"set" : "rs0",
	"date" : ISODate("2019-05-29T02:11:37Z"),
	"myState" : 1,
	"members" : [
		{
			"_id" : 0,
			"name" : "mongodb-instance-0.ap-northeast-2.docdb.amazonaws.com:27017",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"self" : true,
			"uptime" : 1
		}
	],
	"ok" : 1
}

   

    (3) 수 초내에 ReplicaSet 의 모든 멤버가 합류하며 정상화 되는 것을 볼 수 있다.

rs0:PRIMARY> rs.status()

{
	"set" : "rs0",
	"date" : ISODate("2019-05-29T02:11:46Z"),
	"myState" : 1,
	"members" : [
		{
			"_id" : 0,
			"name" : "mongodb-instance-1.ap-northeast-2.docdb.amazonaws.com:27017",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 10
		},
		{
			"_id" : 1,
			"name" : "mongodb-instance-2.ap-northeast-2.docdb.amazonaws.com:27017",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 10
		},
		{
			"_id" : 2,
			"name" : "mongodb-instance-0.ap-northeast-2.docdb.amazonaws.com:27017",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"self" : true,
			"uptime" : 10
		}
	],
	"ok" : 1
}

 

 

  이런 방식으로 동작하는 이유는 DocumentDB 의 특수한 구성에서 기인한다.

 

  DocumentDB 의 각 멤버 노드는 Instance로 생성되며 각 AZ에 자리잡게 되고,

  데이터의 입출력을 담당하는 컴퓨팅 파워 제공 역할만 담당하게 된다.

 

  실제 데이터는 Cluster volume 이라는 Shared 형태의 스토리지에 저장되며

  자동으로 각 AZ에 6 copy 로 분산 복제하여 저장하게 된다. 

 

 

[ DocumentDB: How it works 출처: docs.aws.amazon.com ]

 

 

 

  이렇기 때문에 각 멤버 노드는 데이터 저장소로서의 역할로 부터 자유롭기 때문에 얼마든지 삭제 후 재생성 할 수 있게 된다.

 

  기존 MongoDB의 ReplicaSet 의 경우는 Primary 가 다운된 경우,

  Secondary 중 하나가 Primary 로 승격되며 서비스는 지속 가능했지만 귀찮은 후속 작업들이 동반 되어야 했다.

 

  장애난 이전의 Primary 가 복구된 이후에는

  Secondary 로 다시 ReplicaSet 멤버로 join 한 후에 Sync 를 맞춰 줘야 하는 작업을 해줘야만 한다.

 

  하지만, DocumentDB는 데이터가 Cluster volume 에 유지중이고,

  ReplicaSet 을 새롭게 구성하기 때문에 이런 후속 작업 절차가 필요 없다.

 

 

 

3) AWS 콘솔에서 명시적으로 Failover 를 수행했을 경우

  DocumentDB 는 콘솔에서 직접 Failover 를 실행할 수 있다.

 

  Failover 를 하면 Primary 멤버가 다른 노드로 변경된다.

  Client 가 Cluster endpoint 를 바라보고 있었다면, endpoint에 대한 변경은 없기 때문에 Failover 이후 특별히 작업을 해줄 것은 없다. 

 

  내부적인 변경 절차는 2) 번의 경우와 동일하다.  

  ReplicaSet 을 새롭게 구성해서 올라오게 된다.