'mongoDB'에 해당되는 글 11건

이번시간에도 지난번 포스팅에 이어서 watcher기능의 실습에 대해 올려보도록 하겠다.

1. watcher기능 

이제 본격적으로 watcher기능을 추가해서 작성하도록 하겠다. 그 전에 만들었던 zkClient2.js파일을 살짝 

변형해서 만들면 된다. 그렇게해서 최종적으로 완성한 코드는 다음과 같다. 파일명은 watcher.js로 저장한다.

그리고 이 결과를 실행하면 다음과 같은 화면이 나오면 정상적으로 실행된 것이다.

그리고 iTune에서 watcher.js파일을 실행한 상태에서 command+D를 눌러서 zkCli명령어를 입력해서 zkClient server에 접속해서 test노드를 만든다. test노드를 만들게 되면 다음과 같은 화면이 나온다.

왼쪽화면에 보면 Watcher가 ‘/test’ znode가 created 된 것을 감 지해 “Node exists.” 문구가 출력되게 되는 화면을 볼 수 있다. 

2. mongo rs의 상태정보 얻어오는 법

앞서서 mongo rs를 만들어보았다. 하지만 주키퍼로써는 어떻게 얻어오는지에 대해 살펴보도록 하겠다.

먼저 다음 명령어를 통해서 mongo rs를 실행시켜준다.

•  sudo mongod --port 20000 --dbpath /data/db/replSet1 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet1.log
•  sudo mongod --port 30000 --dbpath /data/db/replSet2 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet2.log
•  sudo mongod --port 40000 --dbpath /data/db/replSet3 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet3.log
•  sudo mongod --port 20017 --dbpath /data/db/replSet_Arbiter --replSet Mongo_study --smallfiles --noprealloc --nojournal --logpath /data/db/replSet_Log/mongo-replSet_Arbiter.log

그리고 GetmongoStat.js로 파일이름을 설정하고 다음과 같이 입력해준다.

이걸 실행시킬때 주키퍼서버가 연결되어있다는 가정하에 실행되어야 정상적으로 동작할 것이다. 이처럼 주키퍼를 이용해서 mongo rs 정보까지 확인할 수 있다. 주키퍼는 분산데이터시스템인 용도 외에도 참 활용할 분야가 많다. 앞으로도 주키퍼에 대해 또 알게된 점이 있다면 포스팅해보도록 하겠다. 일단 주키퍼 포스팅은 여기서 마무리 하도록 하겠다.

이번 시간엔 watcher기능이 실제론 어떻게 동작하고 쓰이는지 직접 실습해본 결과를 포스팅 해보려고한다.

1. znode를 생성해주는 클라이언트 만들기

① 먼저 아래의 명령어를 실행시켜서 모듈을 설치해준다.

· npm install node-zookeeper-client

만약 저 명령어를 실행시켜서 위와 같은 화면이 나온다면 정상적으로 설치가 완료된것이다.

② 파일이름은 zkClient.js로 정해주고 다음과 같이 코드를 작성해준다.

③ 이제 zookeeper을 설치해줘야한다. 다음과 같은 명령어를 실행해서 설치해준다.

· brew install zookeeper 

그리고 zkClientstart 명령어를 써서 zookeeper server을 동작시킨다.

정상적으로 실행되면 위의 화면이 나온다. 내꺼 같은 경우엔 미리 zookeeper server를 돌려놓은 상황이다.

④ 이제 zkClient.js를 실행시켜보면된다. 파일을 실행시키면 다음과 같은 화면이 나온다.

위의 화면이 나온다면 정상적으로 실행된 것이다. zkCli 명령어를 입력해서 클라이언트에 접속하고 ls /를 입력해보면

test node가 생성되었을 것이다. 

2. znode가 존재하는지 확인해주는 클라이언트 작성하기

① 파일이름은 zkClient2.js로 설정해주고 다음과 같이 코드를 입력해준다.

② zkClient2.js를 실행시켜보면 다음과 같은 화면이 얻어졌다면 실행이 잘된것이다.

아까 처음에 test 노드를 만들어놨기 때문에 test노드가 존재한다고 표시가 된다는 것을 알 수 있다.

3. Child Node 확인하는 방법

① 먼저 zkCli명령어를 사용해서 zkServer에 접속하고 /shard1 Persist Node를 생성해준다.

만약 생성이 잘 되었다면 위 화면과 같은 결과가 나타날 것이다.

② /shard1 노드의 자식을 Ephemeral Node로 각각 replSet1, replSet2, replSet3, arbiter znode로 생성       해준다.

만약에 생성이 잘 되었다면 위화면과 같은 화면이 출력될 것이다.

자, 이제 Child Node 생성이 끝났다. 본격적으로 child Node를 확인하는 주키퍼 클라이언트를 구현해보자.

③ child Node를 확인하는 클라이언트 구현

파일이름을 zkClient3.js로 설정하고 다음과 같이 코드를 작성해준다.

코드를 작성하고 zkClient3.js를 실행시켜 주면 다음과 같은 화면이 나온다.

정상적으로 잘 실행 되었다면 위와 같이 아까 만들었던 Child Node를 확인할 수 있을 것이다.

그리고 참고로 하나 더 말하자면 자식 노드를 모두 Ephemeral Node로 생성했기 때문에 zkCli를 종료하면 해당 자식노드가 모두 삭제되는 것을 확인 할 수 있다.

4. znode에 data를 입력하는 zookeeper Client 생성하기

① 먼저 파일 이름을 zkClient4.js로 저장하고 다음과 같이 코드를 입력한다.

② 그리고 zkClient4.js를 실행해주면 다음과 같은 화면이 나온다.

이렇게 실행이 되었으면 정상적으로 실행된 화면이다.

5. znode의 data를 받아오는 zookeeper Client 생성하기

① zkClient5.js로 파일을 저장하고 다음과 같이 코드를 입력한다.

② zkClient5.js를 실행시키면 다음과 같은 화면이 나온다.

위 화면과 같이 출력되면 정상적으로 실행된 화면이다.

6. 원하는 znode를 삭제하는 zookeeper Client 생성하기

① zkClient6.js로 파일을 저장하고 다음과 같이 코드를 입력한다.

② zkClient6.js를 실행시키면 다음과 같은 화면이 나온다.

1. watch 

Watch 기능은 Zookeeper 클라이언트가 특정 znode에 Watch를 설정해 놓아야 사용할 수 있다.

[그림1 원하는 znode에 Watch 설정]

아래와 같은 데이터 형태에서 /app1/p_2 znode에 Watch를 설정하여 Watcher를 생성했다고 가정해보자.

[그림2 /app1/p_2 znode에 Watch 설정]

/app1/p_2 znode가 변경이 되면 watch를 설정한 client에게 event change를 알려준다.

[그림3 /app1/p_2 znode가 변경됨을 알림]

event change를 알리고 나면 해당 Watcher는 삭제된다.

[그림4 event change를 알리고 해당 Watcher 삭제]

Watcher가 감지하는 znode의 ‘변경’ event는 4가지 종류가 있습니다.

NODE_CREATED: 노드가 생성 됨을 감지

NODE_DELETED: 노드가 삭제 됨을 감지

NODE_DATA_CHANGED: 노드의 데이터가 변경 됨을 감지

NODE_CHILDREN_CHANGED: 자식 노드가 변경 됨을  감지 

Watch를 설정해 생성된 Watcher가 해당 znode의 변경을 알아내 Watch를 설정한 클라이언트에게 event를 전달하면 해당 Watcher는 삭제된다는 것

즉 한 번 설정해 놓으면 지속적으로 감시해주는 Watch 기능이 아니라 event change가 발생하면 이를 알려주고 삭제돼버리는 one time trigger라는 점을 반드시 기억해야한다.

그럼 event에 대해 조금 더 알아보면 리눅스에서 event type를 확인하는 방법은 다음과 같다.

1. 처음에 node를 치고

2. 그다음 >에 var zookeeper = require('node-zookeeper-client');를 입력해준다. 그러면 undefined가 생성될 것이다.

3. 그다음 >에 zookeeper.Event를 치면 event type 4가지를 확인할 수 있다.

아래 그림과 같이 /app1/p_2 znode에 Watcher를 생성했다고 가정해보면

[그림5 /app1/p_2 znode에 Watcher 생성]

만약 /app1/p_2 znode가 변경이 되면 Watch를 설정한 해당 Client에게 알려주고 Watcher는 사라지게 된다. 위에서 설명한 것 다시한번 설명하고 있다.

[그림6 event change를 알리고 해당 Watcher 삭제]

변경 사항이 해당 znode의 ‘삭제’였다면 아래 그림과 같이 진행된다.

[그림7 event change를 알리고 해당 Watcher 삭제]

아래와 같이 /app1/p_2 znode가 없는 상태라고 가정해보면

[그림8 /app1/p_2 znode가 없는 상태]

존재하지 않는 znode라도 Watch 설정이 가능하다. 즉 /app1/p_2 znode에 Watch를 설정할 수 있다.

[그림9 /app1/p_2 znode에 Watch 설정]

/app1/p_2 znode가 생성된다면 NODE_CREATED event를 Watch를 설정한 Client에게 전달하고 Watcher는 삭제된다.

[그림10 event change를 알리고 해당 Watcher 삭제]

2. mongo rs server

“mongod” Command를 통해 mongo rs server를 생성한다.

[그림11 mongo rs: Primary1, Secondary2, Arbiter1]

이 때, 함께 Zookeeper Server에 Ephemeral Node를 생성해준다.

[그림12 각 mongo rs 멤버에 해당되는 Ephemeral Node 생성]

해당 znode가 생성된 것을 Watcher가 감지하고 zookeeper에 rs의 상태를 rs mongo server에게 받아와 갱신한다.

[그림13 znode  생성 감지 및 rs 상태 갱신]

에러가 생겨 특정 mongo server가 죽었을때는?

[그림14 Primary 장애 발생]

Zookeeper Server와 connection이 끊겨 해당 Ephemeral Node가 삭제된다.

[그림15 Primary에 해당되는 Ephemeral Node 삭제 됨]

이를 Watcher가 감지해 변경된 rs의 상태를 zookeeper에 갱신해준다.

[그림16 DELETED event를 감지하고 rs 상태 갱신]

죽었던 mongo server를 되살리게 된다.

[그림17 죽었던 기존 Primary를 되살림]

이를 감지해 다시 rs의 상태를 zookeeper에 갱신한다.

[그림18 rs 상태 갱신]

이처럼 watcher의 기능은 매우 활용도가 높으며, 이와 같은것 이외에도 활용가능성이 풍부한 기능이다.

[그림19 zookeeper 활용의 예]

그림 19와 같이 여러가지 서버를 관리해줄때 활용도가 높은 것이 바로 zookeeper이다. 현재 네이버 본사에서는 zookeeper을 사용하고 있다고 한다.

[그림20 zookeeper 활용의 예]

[그림21 zookeeper 활용의 예]

[그림22 zookeeper 활용의 예]

<출저: https://unagi44.wordpress.com/Developer Lee>

zookeeper은 이처럼 다양한 분야에서 많이 활용할 수 있다. watch의 기능을 이용해서 Node를 관리 할수도 있기 때문에 죽었었던 서버도 다시 되살릴 수 있다. Zookeeper이라고 하면 모르는 사람이 많을 수도 있는데 알고 나면 굉장히 유용한 것이라는 것을 알 수 있다. 다음 포스팅에서는 실제로 Watch기능이 어떤식으로 만들어지고 동작하는지에 대해 자세히 포스팅 해보도록 하겠다. 끝으로 Zookeeper에 대해 포스팅을 허락해준 친구에게도 고마움을 전한다.

Zookeeper란 한 마디로 정의하면 “분산 처리 환경에서 사용 가능한 데이터 저장소”다. 기능은 매우 단순하지만 분산 서버 환경에서는 활용 분야가 넓다. 많은 서버를 관리할때도 유용하게 생기는 툴이다.

설명을 하기에 앞서 Zookeeper를 직접 사용해야 이해가 빠르다.

1. Zookeeper의 설치

이 명령을 사용해서 zookeeper을 설치해준다.

• brew install -g zookeeper

아래 명령은 config 파일과 zkServer.sh, zkCli.sh이 어디에 있는지 알아보는 방법이다.

• cd /usr/local/etc/zookeeper
• ls zoo.cfg

아래 명령은 config 파일 유무를 체크하는 방법이다.

• cd /usr/local/Cellar/zookeeper/3.4.6_1(현 문서 작성 시점)/libexec/bin
• ls zkServer.sh zkCli.sh

아래 명령어는 zookeeper server를 실행하는 명령어이다.

• zkServer start

참고로 server를 중지하는 명령어는 “zkServer stop”이다.

2. Zookeeper의 실행

아래 명령어를 통해 zookeeper server에 접속해준다.

* zkCli

이렇게 접속이 되면 정상적으로 실행된 화면이다.

다음 명령어들을 직접 수행해 보면

[그림2 ls /]

[그림3 create /test ‘’]

본 실습은 Mac을 기준이다. 

이제 진짜로 mongodb Replica Set을 만들어보자. 먼저 mongodb를 설치해야한다.

•  brew install mongodb

다음으로 Replica Set member(Primary1, Secondary2, Arbiter1)와 log를 위한 디렉토리를 생성한다.

•  sudo mkdir /data/db/replSet1
•  sudo mkdir /data/db/replSet2
•  sudo mkdir /data/db/replSet3
•  sudo mkdir /data/db/replSet_Arbiter
•  sudo mkdir /data/db/replSet_Log

아래의 4개 명령어를 수행하여 Replica Set 4개를 실행한다. 

•  sudo mongod --port 20000 --dbpath /data/db/replSet1 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet1.log
•  sudo mongod --port 30000 --dbpath /data/db/replSet2 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet2.log
•  sudo mongod --port 40000 --dbpath /data/db/replSet3 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet3.log
•  sudo mongod --port 20017 --dbpath /data/db/replSet_Arbiter --replSet Mongo_study --smallfiles --noprealloc --nojournal --logpath /data/db/replSet_Log/mongo-replSet_Arbiter.log

모두 정상적으로 따라왔다면 현 prompt에서 다음과 같이 명령어를 수행시켜 준다.

•  rs.add(“localhost:40000”)
•  rs.addArb(“localhost:20017”)
•  rs.add(“localhost:30000”)

이제 rs member 4개가 정상적으로 동작을 하게된다.

다음으로 rs 설정을 변경하는 법을 알아보겠습니다. 아래 그림처럼 config 변수에 rs의 config 내용을 받아온다.

실행을 정상적으로 시켰다면 대강 이런 화면이 나올 것이다.

[그림1 rs config 내용 받아오기]

제대로 받아왔는지 확인해보려면 아래의 명령어를 통해 rs 멤버들의 설정을 확인해 보면 된다.

실행시키면 이런 화면이 출력이된다. 아래에 조금 더 내용이 있지만 좀 길어서 대강 저렇게 나온다만 이야기 하겠다.

[그림2 rs config 확인하기]

아래 그림처럼 원하는 rs 멤버만 콕 집어서 확인할 수도 있다.

[그림3 특정 rs member의 config 확인하기]

“localhost:20000” host를 가지는 멤버의 “votes”와 “priority”를 수정해보자.

[그림4 특정 rs member의 config 변경하기]

“rs.conf()” 명령어를 통해 한 번 확인해 보면 설정이 잘 변경됐음을 확인할 수 있다. 여기서 한가지 주의해야 할 점은 “localhost:30000” host를 가지는 rs 멤버의 설정을 변경해 본다. 단, priority를 가장 높은 값을 갖도록 설정해야 한다.

실행을 하면 아래와 같은 그림이 펼쳐진다.

[그림5 priority 변경 후 발생하는 상황]

이번시간엔 zookeeper의 필요성에 대해 포스팅 해보려고 한다. 이 포스팅 내용자체가 mongodb Replica Set의 개념이 있어야 이해가 가능한 내용이기때문에 꼭 mongodb 내용부터 확실하게 이해를 하고 봐야 이해가능한 내용이다.

1. Mongodb Replica Set의 여전히 해결되지 않는 문제점

‘Mongodb Replica Set 만들기’에서 살펴본 바 같이 rs가 Primary1, Secondary2, Arbiter1 으로 구성돼 있다면 Primary가 죽었다고 하더라도 2개의 Secondary 중 하나가 Arbiter의 존재로 인해 Primary로 선출된다.

하지만 여전히 문제점은 존재하게 된다. 

[그림1 Election for New Primary: Secondary2, Arbiter1]

죽었던 Primary는 어떻게 살려내야할까? 만약 Arbiter가 죽으면 이건 또 어떻게 해결할 수 있을까?

아래의 그림은 아비터가 죽었다고 가정한 가상의 모식도이다.

[그림2 rs(Primary1, Secondary2, Arbiter1) 멤버 중 Arbiter가 죽은 경우]

그리고 이 상태에서 Primary가 죽게된다면 어떻게 될까? Election을 통해 Primary가 선출되지 않을 것이다. 그렇게 된다면 선출할 수 있는 권한을 가진 Arbiter가 없기때문에 큰 문제가 발생한다. 이건 Arbiter를 다시 꼭 살려야한다.

하지만 다행히도 Arbiter는 죽을 일이 거의 없긴하다. 투표권을 행사하지만 Replication 되지도 않으며 Client에게 Read를 수행하는 경우도 없기 때문이다.

현 상황은 ‘그림1’ 과정을 거쳐 Primary 하나와 Secondary 하나, Arbiter 하나가 살아있는 상태라고 가정한 그림이다.

[그림3 ‘그림1’과정을 거친 후 rs 멤버의 모습]

이번시간에는 데이터베이스의 Sharding에 대해 포스팅해보려고 한다. Sharding에 대한 개념 자체는 크게 어려운 건 아니지만 알아두면 굉장히 유용한 개념이다.

데이터베이스에서의 Sharding이라 하면 관계형데이터베이스를 여러개로 분할해서 데이터를 저장하는 기능을 뜻한다. 현시대에는 사람들의 사용이 증가하면서 엄청난양의 데이터를 저장해야하기 때문에 자연스럽게 Sharding의 기능이 많이 필요하게 되었다. sharding의 방법은 수평적 sharding과 수직적 sharding이 있다.

Figure 1 Vertical Sharding

Figure 2 Horizontal Sharding

<사진출저: 조대협의 블로그>

Sharding의 기능이 여러모로 좋긴하다. 데이터베이스를 한군데에 몰리게 되면 요즘같이 사용자도 많은 시대에 서버과부하가 걸릴 확률도 매우 높고 만약 그 DB가 다운되어서 정지된다면 모든게 다 중단될 것이다. 하지만 이렇게 Sharding방법으로 여러개의 데이터를 나누어서 저장하는 방식은 굉장히 혁신적이었다. 하지만 이것도 모두 장점만이 있는건 아니다. 단점도 존재하게 되는데 직접 Application에서 구현할 경우 Key에 따라서 DB Instance를 선택적으로 고를 수 있는 구조를 가져야 하며, 특히 다른 Shard간의 데이터 Join등은 불가능하기 때문에, 구현을 할때에는 잘 고려해서 설계해야한다. 그리고 Sharding기능을 쓰게되면 Application의 복잡도가 올라가기 때문에 여러가지 요소들을 잘 고려해서 설계를 해야한다. 또한 하나의 트랜잭션에는 두개의 Sharding이 한번에 접근 할 수가 없기때문에 이 또한 잘 반영해서 설계해야한다.

지난 3개의 포스팅을 통해 Replica Set과 Election 및 Secondary가 두 개일 경우 Arbiter가 있어야 하는 이유에 대해 알게 됐을 것이다. 그런데 여기서 한가지 궁금한 점이 있을 것이다. 애초에 아비터 없이 Secondary만 3개 있으면 되지 않을까?

아래와 같이 백엔드에서 Read가 600만큼 req가 오고 있는 것이 보일 것이다.

[그림1 Read req가 600인 경우]

Secondary에서 300씩 처리하는데 가장 이상적이라고 한다면 Primary 하나와 Secondary 두개가 가장 이상적일 것이다.

[그림2 Read req가 600이고 primary1, secondary2인 rs의 경우]

물론 read req가 900이라면?

[그림3 Read req가 900인 경우]

각 Secondary가 300씩 처리하는게 이상적이라면 Primary 하나와 Secondary 세 개가 적당할 것이다.

[그림4 Read req가 900이고 primary1, secondary3인 rs의 경우]

하지만 Primary 입장에서 생각을 해보게 된다면 ‘그림5’와 같이 Primary는 각 Secondary에게 Replication 해 주어야 한다.

[그림5 mongodb rs: Primary1, Secondary2]

Secondary가 세 개라면 그만큼 Primary의 부담도 더 증가 한다는 뜻이된다. 반면 Arbiter는 Primary로부터 Data Replication을 지원받을 필요가 없으며 실제로 지원받지도 않는다. 그저 Primary 선출시 투표권을 가지고 있을 뿐이다.

<출저: https://unagi44.wordpress.com/Developer Lee>