'전체 글'에 해당되는 글 209건

이번시간엔 멀티프로세싱이라는 개념을 포스팅해보려고 한다. 정보처리산업기사,기사공부를 하다보면 운영체제(4과목)에서 등장하는 개념이다. 자격증시험에서도 중요하게 다루어지고 있고 회사면접을 갔을때도 물어볼 수 있는 단골개념이다. 이처럼 중요한 개념이지만 4년제 컴퓨터공학과를 졸업한 학생들에게 물어보면 대다수의 학생들이 잘모른다는 이야기를 얼핏 들은 적이 있다. 그래서 내가 공부를 한 것을 바탕으로 글을쓴다.

◎ 멀티프로세싱이란?

멀티프로세싱이라고 하면 무엇이 떠오를까? 아마 용어자체의 의미에서 눈치를 챘을 수도 있다. 바로 프로세서가 서로 협력해서 일을 하는 과정이다. 소수의 프로세서를 처리할때는 단일 프로세서가 더 빠를 수도 있겠지만 사실 컴퓨터를 쓰다보면 엄청 많은 프로세서를 볼 수 있다. 그래서 많은 프로세서를 처리할때는 멀티프로세서가 훨씬 빠르다. 그럼 처리를 할때는 어떤식으로 처리를 할까? 멀티프로세서는 주로 병렬식으로 처리하는 방법을 쓰고 있다. 다음 그림을 보면 이해가 쉽게 될 수 있다.

<사진출저: 유자차 한 스푼>

위에 그림에 잘 나와있듯이 병렬처리방식으로 처리하고 있다. 근데 그림을 자세히 보면 한번에 한가지일을 맡아서 처리하는게 아니라 서로 도와주면서 처리한다는 걸 보여주고있다. 멀티프로세서는 서로 일을 분산해서 처리할 뿐만아니라 서로 도와주면서 처리하기 때문에 더 효용성이 높을 수 밖에 없다. 또한 만약 시스템이 정지가 되어도 프로세스가 다 분산이 되어있기 때문에 시스템이 다운되지 않는다. 단지 조금 느려질 뿐이다. 이처럼 신뢰성이 보장되기 때문에 멀티프로세스를 널리 사용한다. 그리고 비용면에서도 단일프로세스에 비해 저렴하다. 이러한 이유가 프로세스는 단일장치, 대용량 저장장치, 전원공급장치를 공유하고 있기때문에 비용이 저렴하다. 한마디로 서로 공유하고 도와주면 처리시간도 단축되고, 비용이 절감이 된다.

이번시간에도 지난번 포스팅에 이어서 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 정보까지 확인할 수 있다. 주키퍼는 분산데이터시스템인 용도 외에도 참 활용할 분야가 많다. 앞으로도 주키퍼에 대해 또 알게된 점이 있다면 포스팅해보도록 하겠다. 일단 주키퍼 포스팅은 여기서 마무리 하도록 하겠다.

리눅스를 쓰면서 수많은 명령어들이 있지만 정말 자주 쓰이는 명령어들이 있다. 그걸 한번 써보고 해서 몇가지 포스팅해본다.

1. rmdir - 디렉토리 삭제

2. touch - 파일크기가 0인 파일을 생성 (하드디스크 오류를 판단할때 주로 쓰임)

3. cat - 파일의 내용을 화면에 출력

4. find - 특정명령을 찾는 명령어

5. grep - 특정패턴을 이용해서 파일을 찾는 명령어 --> 이 명령어는 유용하게 쓰인다. 복잡한 파일 찾기에 많이 유용하다.

6. file - 파일의 종류를 확인

7. ping + 테스트하려는IP주소입력 -  IP 네트워크를 통해 특정한 호스트가 도달할 수 있는지의 여부를 테스트하는 데 쓰이는 명령어

8. netstat -네트워크의 상태

9. nbtstat -IP충돌이 발생했을시, 충돌된 컴퓨터를 찾기위한 명령어

10. which - 특정명령어의 위치를 찾아주는 명령어

11. date - 시간, 날짜등을 변경하는 명령어

12. rdate - 원격지에 있는 시간,날짜등을 받아서 시스템에 설정해주는 명령어

13. rpm - rpm을 설치하고 삭제하고 관리하는 명령어

<출저: http://vaert.tistory.com/103>

몇가지 중요한 명령어들은 지난번에 포스팅 해놔서 따로 포스팅은 해놓지 않았다. 리눅스가 쉬운건 아니지만 하나씩 해보면 언젠가 잘 다룰 수 있을 것이라고 생각한다. 

리눅스 쓸때 파일관리를 할때 유용한 명령어가 몇개 있다. 파일 보안에도 유용하게 쓰이는 명령어들을 몇개 포스팅 

해보았다.

1. .bash_history 점검

크래커가 침투하여 활개치고 난후, 활동한 내용의 종적을 감추기 위해 로그 파일과 히스토리 파일을 제거하는 경우가 있다. 히스토리 파일이 크기가 0 이라면 침투를 의심할 수 있다.

sudo find / -name.bash_history -exec ls -la {} \;

2. /dev 디렉토리의 검사

3. 유저 권한 없는 파일

사용자가 할당되지 않은 파일들을 찾아 제거한다. 

sudo find / -nouser -o -nogroup -print

근래에는 잘 사용되지 않지만 .rhost 파일도 검사하여 삭제한다.

sudo find / -name.rhosts -print

<출저 : http://webdir.tistory.com/257>

이번시간엔 임계구역에 대해 포스팅 해보려고 한다. 사실 임계구역이라는 개념은 조금만 이해해보면 간단한 개념이다.

그럼 임계구역이라는게 어떤것인지 살펴보자.

1. 임계구역이란?

임계구역이란 둘 이상의 스레드가 동시에 접근해서는 안되는 공유 자원(자료 구조 또는 장치)을 접근하는 코드의 일부를 말한다. 쉽게말해 임계영역에 접근하려고 하는 스레드들은 동시에 임계영역에 접근할 수 없다는 이야기이다. 한 임계구역당 하나의 스레드만이 접근을 할 수 있다.

2. 임계구역의 동기화?

동기화(asynchronous)라는 용어에 정의에 대해서 알고 있는가? 흔히 동기화라 하면 어떤걸 일치시켜준다는 의미로 널리 쓰인다. 하지만 임계구역에서의 동기화의 의미는 기존에 쓰였던것과는 약간 다르다. 임계구역에 접근하는 스레드 순서가 잘 지켜지고 있는지에 대한 의미이다. 1번에서도 설명했듯이 임계구역엔 동시에 여러 스레드가 접근하지 못한다. 그러기때문에 스레드도 들어오는 순서가 있고 그 순서가 잘 지켜져야 원활하게 수행이 된다. 

사실 이렇게 말로만 풀어서는 임계구역이 정확히 뭔지에 대한 파악은 좀 어렵고 감이 안올 수 있다. 아래의 그림을 보자.

이번 시간엔 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 ‘’]