RabbitMQ는 AMQP (Advanced Message Queuing Protocol)를 이용한 Message Queue Broker이다.

이번 포스팅은 RabbitMQ 서버 설치와 클러스터링 구축에 대하여 설명한다.
 

 

1. RabbitMQ 설치

$ sudo apt-get install rabbitmq-server

 

 

2. 관리자 계정 추가

$ sudo rabbitmqctl add_user {ID} {Password}
  ex) sudo rabbitmqctl add_user programist programist123
$ sudo rabbitmqctl set_user_tags {ID} administrator
  ex) sudo rabbitmqctl set_user_tags programist administrator

 

 

 

3. Management 활성화 및 접속

$ sudo rabbitmq-plugins enable rabbitmq_management
$ sudo service rabbitmq-server restart

 

  - Management Plugin 활성화를 하면 다음과 같이 enable된 목록을 확인할 수 있다.

 

 

 

  - http://Localhost:15672로 접속하면 다음과 같이 로그인 창이 나오며, 추가된 관리자 계정으로 로그인을 하면 RabbitMQ 서버의 상태 및 설정을 웹으로 조종할 수 있다.

 

 

 

 

 

4. RabbitMQ Clustering을 위한 환경 구성

  - RabbitMQ Clustering 구성을 위해 다음과 같이 3대의 RabbitMQ Server 3대를 구성하였다.

 

 

 

RabbitMQ 노드는 쿠키를 사용하여 서로 통신 할 수 있는지 여부를 결정하며, 두 노드가 통신 할 수 있으려면 Erlang 쿠키라고하는 동일한 공유 암호가 있어야한다. 일반적으로 로컬 파일에 저장되며, 모든 클러스터 노드에는 동일한 쿠키가 있어야한다.

 

  - RabbitMQ 쿠키 설정

    = 3대의 RabbitMQ Server중 하나를 선택하여 cookie 값을 나머지 2대에 동일하게 수정한다.

$ cat /var/lib/rabbitmq/.erlang.cookie

 

  - Hostname 수정

$ vi /etc/hostname

  ex) RabbitMQ-Server-1 

 

  - 각각의 서버에 다음과 같이 hostname을 지정하였다.

    = 192.168.0.101 : RabbitMQ-Server-1

    = 192.168.0.102 : RabbitMQ-Server-2

    = 192.168.0.103 : RabbitMQ-Server-3

 

  - hosts 파일 수정

$ vi /etc/hosts

 

  - 다음과 같이 각각의 RabbitMQ 서버에 다음과 같이 hosts 파일을 수정한다.

 

 

 

5. Clustering 구성하기

가운데 Server인 RabbitMQ-Server-2를 Master로 두고 RabbitMQ-Server-1과  RabbitMQ-Server-3을 RabbitMQ-Server-2에 연결할 것이다.

 

  - Server 상태 확인 명령어

$ rabbitmqctl cluster_status

 

    = RabbitMQ-Server-1

 

 

 

    = RabbitMQ-Server-2

 

 

 

    = RabbitMQ-Server-3

 

 

 

RabbitMQ-Server-2에 RabbitMQ-Server-1과 RabbitMQ-Server-3 노드 연결하기 위해서는 rabbitmqctl 명령어를 이용하여 RabbitMQ-Server-1, RabbitMQ-Server-3에서 가동되고 있는 서버를 일단 중지시켜야 한다.

 

 - RabbitMQ-Server-1, RabbitMQ-Server-3 노드 추가 명령어

$ rabbitmqctl stop_app

$ rabbitmqctl join_cluster --ram rabbit@{hostname}

  ex) rabbitmqctl join_cluster --ram rabbit@RabbitMQ-Server-2

$ rabbitmqctl start_app

 

    = RabbitMQ-Server-1

 

 

 

    = RabbitMQ-Server-3

 

 

 

 - RabbitMQ-Server-2 Clustering 상태 체크

$ rabbitmqctl cluster_status

 

 

 

 - Web에서의 Clustering 상태 체크

 

 

 

 - RabbitMQ-Server-1, RabbitMQ-Server-3 노드 삭제 명령어

   (rabbitmqctl reset 명령어를 사용할 경우, 기존에 등록했던 계정들도 삭제되므로 사용 시 주의한다.)

$ rabbitmqctl stop_app

$ rabbitmqctl reset

$ rabbitmqctl start_app

 

    = RabbitMQ-Server-1

 

 

 

    = RabbitMQ-Server-3

 

 

 

 - RabbitMQ-Server-2 Clustering 상태 체크

$ rabbitmqctl cluster_status

 

 

 

 

테스트 환경 : Ubuntu 16.04

DNS Server는 도메인 네임을 IP 주소로 변환하는 작업을 담당한다.

도메인 네임은 사용자가 인터넷 접속을 할 때 사용하는 알기 쉬운 문자로 만들어진 주소이며, DNS의 순방향 질의와 역방향 질의를 통하여 DNS 응답 메시지를 받을 수 있다.

 

아래 그림은 DNS의 동작 형태를 설명한다.
실선은 DNS 순방향 질의과정(DNS Forward Lookup)을 보여주고, 점선은 DNS 역방향 질의과정(DNS Reverse Lookup)을 보여준다.
이때 순방향 질의는 도메인 네임을 이용하여 IP 주소로 변환하는 과정이고, 역방향 질의는 IP 주소를 이용하여 도메인 네임으로 변환하는 과정이다.

 

 

 

아래 그림은 존 파일의 구조를 보여준다.
순방향 질의는 도메인 네임을 순방향 존 파일에서 정보를 검색한 후 해당 IP 주소로 변환하여 응답해준다.
그리고 역방향 질의는 IP 주소를 역방향 존 파일에서 검색한 후 도메인 네임으로 변환하여 응답해준다.

 

 

 

이번 포스팅의 DNS Server 구축 및 테스트 환경 구성은 아래 그림과 같다.

 

 

 

Web Server인 192.168.0.102 서버에 접속하면, 다음과 같이 Apache2의 메인 페이지가 동작하는 것을 확인할 수 있다.

이를 DNS Server를 구축하여 도메인 네임(http://programist.com)으로 접속 가능하도록 아주 간단한 환경 구축 및 테스트를 설명한다.

 

 

 

  - Bind 패키지 설치

$ sudo apt-get install bind9 bind9utils bind9-doc 


 

 

  - IPv4 모드 설정

$ sudo vi /etc/default/bind9

 

 

 

  - 로컬 존 파일 환경 구성

$ sudo vi /etc/bind/named.conf

 

  - 순방향 존 파일 파일 경로 설정

    = 순방향 존 파일은 사용할 도메인네임을 지정하여 작성한다.

 

 

  - 역방향 존 파일 경로 설정

    = 역방향 존 파일은 사용할 DNS 서버의 IP를 역으로 지정하여 작성한다.

      ex)192.168.0.xxx이 사용할 DNS 서버의 IP 주소라면 역으로 0.168.192.in-addr.arpa로 작성한다. 

 

 

 

    = 수정된 named.conf는 아래와 같다.

 

 

 

  - BIND 설정 구문 검사

$ sudo named-checkconf


    = named.conf 설정에 대한 구문이 올바르게 작성되었다면 아래와 같이 메시지가 뜨지 않는다.

 

 

 

    = named.conf 설정에 대한 구문이 올바르게 작성되지 않았다면 아래와 같이 오류 메시지가 출력되는 것을 확인할 수 있다.

 

 

 

  - named.conf에서 작성된 경로인 "/etc/bind/zones" 디렉토리를 생성

$ sudo mkdir /etc/bind/zones

 

  - 순방향/역방향 존 파일 템플릿을 복사 

$ cp /etc/bind/db.local db.programist.com

$ cp /etc/bind/db.local db.192.168.0 


/etc/bind/db.local 파일에서 복사한 기본 템플릿은 아래와 같다.

 

 

 

  - 순방향 존 파일 작성

$ sudo vi /etc/bind/zones/db.progrmist.com

 

DNS Server IP는 192.168.0.101이며, Web Server IP는 192.168.0.102이므로 다음과 같이 존 파일을 수정한다.

다음과 같은 설정으로 ns.programist.com은 192.168.0.101으로 매핑될 것이며,

programist.com, www.programist.com는 192.168.0.102로 매핑되어 동작할 것이다.

 

 

 

  - 역방향 존 파일 작성

$ sudo vi /etc/bind/zones/db.192.168.0

 

순방향과 동일하게 매핑하여 192.168.0.101는 ns.programist.com으로 192.168.0.102는 programist.com, www.programist.com으로 작성한다.

 

 

 

  - 작성된 순방향/역방향 존 파일 구문 검사

$ sudo named-checkzone programist.com db.programist.com

 

 

 

$ sudo named-checkzone 0.168.192.in-addr.arpa db.192.168.0

 

 

  - BIND Service 재시작

$ sudo service bind9 restart

 

  - Client의 /etc/resolv.conf 설정 변경

$ sudo vi /etc/resolv.conf


Client에서 DNS Server의 도메인 네임 질의를 위하서 DNS 서버의 IP 주소와 도메인 네임을 변경한다.

 

 

 

  - nslookup를 활용한 순방향 DNS 조회

$ sudo nslookup programist.com

 

 

 

  - nslookup를 활용한 역방향 DNS 조회

$ sudo nslookup 102.168.0.101 


 

  - dig을 활용한 순방향 DNS 조회

$ sudo dig programist.com

 

 

 

  - dig을 활용한 역방향 DNS 조회

$ sudo dig 192.168.0.101

 

 

 

$ sudo dig 192.168.0.102

 

 

 

  - Client 웹 브라우저에서의 도메인 네임으로 Web Server 접근

 

 

 

테스트 환경 : Ubuntu 16.04

 

Suricata는 OISF에서 개발한 NIDS/IPS로, 2010년에 발표한 이후 빠르게 성장한 오픈소스 프로젝트이다.
​Suricata는 오랫동안 사용된 IDS인 Snort의 단일 스레드 방식에서 벗어나, 대용량 트래픽을 실시간으로 처리 할 수 있도록 멀티 코어/멀티 스레드를 지원하며, 기존의 Snort룰을 완벽하게 호환하기 때문에 Snort 사용에 익숙하다면 Suricata를 사용하는데 무리가 없을 것이다.

Suricata : https://suricata-ids.org

 

 

 

1. Suricata 설치
  - 필요 라이브러리 설치

$ sudo apt-get install libpcre3 libpcre3-dev libyaml-dev libpcap-dev libmagic-dev zlib1g-dev pkg-config

 

  - Suricata 다운로드 (https://suricata-ids.org/download)

$ wget https://www.openinfosecfoundation.org/download/suricata-3.2.1.tar.gz


  - Suricata 설치

    $ tar xvf suricata-3.2.1.tar.gz
    $ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
    $ make && make install && ldconfig
    $ make install-full
    $ suricata --build-info


다음과 같이 Suricata에서는 다양한 기능들을 지원한다. 혹여나 필요한 라이브러리가 있다면 필요에 맞게 Configure 설정을 하여 컴파일을 하도록 한다.

 

 

 

  - Suricata 실행

$ suricata -c /etc/suricata/suricata.yaml -i Ethernet_ID 


 

 

2. Suricata 설정 및 로그

  - Suricata 설정 경로 (/etc/suricata)

$ vi /etc/suricata/suricata.yaml 


 

 

- Suricata 로그 경로 (/var/log/suricata)

 

 

 

3. Suricata를 이용한 파일 추출
Suricata에서는 파일 시그니쳐 및 파일 확장자명을 이용한 파일 추출 기능을 제공한다.
  - Suricata를 이용한 네트워크 통신 파일 추출 룰 경로 (/etc/suricata/rules/files.rule)

 

 

 

  - Suricata 설정 수정

      = 추출할 파일의 룰 설정 파일 명시

$ vi /etc/suricata/suricata.yaml


 

 

      = 추출할 파일 저장 기능 및 로그 활성화

 

 

 

      = 추출할 파일의 stream 크기를 무제한 설정

 

 

 

  - NIC offloading 설정 변경

$ ethtool -k Ethernet_ID
$ ethtool -K eth0 tx off
$ ethtool -K eth0 rxvlan off
$ ethtool -K eth0 txvlan off


 

 

  - 추출된 파일 로그 확인 (/var/log/suricata/files-json.log)

 

 

 

  - 추출된 파일 저장 경로(/var/log/suricata/files)
      = file.ID ​형식으로 저장되며 메타 정보는 file.ID.meta를 통하여 파일에 대한 메타 정보를 확인할 수 있다.

 

 


 

테스트 환경 : Ubuntu 16.04

Apache Kafka는 LinkedIn에서 2011년 오픈 소스로 공개된 메시지 큐 시스템이다.
MQTT처럼 Broker(중개자) 서버를 두고, Producer/Consumer(생산자/소비자) 방식으로 동작한다. 이는 MQTT의 Broker 서버와 Publish/Subscribe 방식과 유사함을 알 수 있다.


 

 

Apache Kafka는 다음과 같이 Zookeeper 연동을 지원하며, Broker 서버를 클러스터로 구성 가능하다. 이를 통하여 메시징 큐의 안정화 및 분산 처리 작업이 가능하며 그 성능 또한 우수하다고 한다.

출처 : http://notes.stephenholiday.com/Kafka.pdf

 

 

 

1. Apache Kafka 설치
​  - Kafka 다운로드 (https://kafka.apache.org/downloads)


 

 

  - Kafka 압축 풀기

$ tar xvf kafka_2.11-0.10.2.1.tgz

 

Apache Kafka 테스트를 위한 네트워크 환경 구성은 아래와 그림과 같은 구조이며, 이를 바탕으로 설정 방법을 설명한다.

 

 

 

2. Zookeeper 설정
  - config/zookeeper.properties 수정

다음과 같이 각 Broker 서버에 설치된 Kafka의 config/zookeeper.properties에 다음과 같이 각 Broker 서버에 설정 정보를 입력 후 저장한다.

 

 

 

또한, 각 서버의 /tmp/zookeeper에 myid 파일을 생성하여, 각각 서버의 고유 ID값을 부여한다. 만약 /tmp/zookeeper 디렉토리가 없다면 생성한다.

 

  - Broker Server 1 (IP : 192.168.0.101)

$ mkdir /tmp/zookeeper
$ echo 1 > /tmp/zookeeper/myid


  - Broker Server 2 (IP : 192.168.0.102)

$ mkdir /tmp/zookeeper
$ echo 2 > /tmp/zookeeper/myid


  - Broker Server 3 (IP : 192.168.0.103)

$ mkdir /tmp/zookeeper
$ echo 3 > /tmp/zookeeper/myid

 

3. Kafka 설정
  - config/server.properties 수정

각 서버의 config/server.properties에 해당 설정 활성화 및 Broker Server 정보를 입력한다.

 

  - Broker Server 1 (IP : 192.168.0.101)

broker.id=1
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://192.168.0.101:9092
advertised.host.name=192.168.0.101
advertised.host.name=9092
zookeeper.connect=192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181

 

  - Broker Server 2 (IP : 192.168.0.102)

broker.id=2
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://192.168.0.102:9092
advertised.host.name=192.168.0.102
advertised.host.name=9092
zookeeper.connect=192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181

 

  - Broker Server 3 (IP : 192.168.0.103)

broker.id=3
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://192.168.0.103:9092
advertised.host.name=192.168.0.103
advertised.host.name=9092
zookeeper.connect=192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181

 

 

4. 서버 구동

$ bin/zookeeper-server-start.sh config/zookeeper.properties
$ bin/kafka-server-start.sh config/server.properties


서버 구동이 완료되면 다음과 이 Kafka 서버가 정상적으로 시작했음을 알 수 있다.


 

 

 

 

5. Topic 생성 및 삭제

  - Topic 생성

$ bin/kafka-topics.sh --create --zookeeper 192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181 --replication-factor 3 --partitions 1 --topic A

 

 

 

replication-factor : 인스턴스 개수
partitions : 병렬 처리를 위한 개수

 

  - Topic 리스트 확인

$ bin/kafka-topics.sh --list --zookeeper 192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181


 

 

  - Topic 삭제

$ bin/kafka-topics.sh --delete --zookeeper 192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181 --topic A

 

 

 

  -  Topic의 partition과 replication-factor에 대한 상세 정보 확인

$ bin/kafka-topics.sh --describe --zookeeper 192.168.0.101:2181, 192.168.0.102:2181, 192.168.0.103:2181

 

 

 

6. Producer/Consumer 테스트
  - Producer 테스트

$ bin/kafka-console-producer.sh --broker-list 192.168.0.101:9092,192.168.0.102:9092,192.168.0.103:9092 --topic A


 

 

  - Consumer 테스트

$ bin/kafka-console-consumer.sh --zookeeper 192.168.0.101:2181,192.168.0.102:2181,192.168.0.103:2181 --topic A --from-beginning


 

 

테스트 환경 : Ubuntu 16.04

MQTT (Message Queuing Telemetry Transport)는 1999년에 발표한 오픈 프로토콜로 낮은 대역폭, 높은 지연이나 신뢰 할 수 없는 네트워크를 위하여 설계된 경량적인(라즈베리파이에서도 사용가능) 메시지 프로토콜이다.

Google에서는 푸시 알림 서비스로 GCM(Google Cloud Messaging)을 제공하며, Apple에서는 APNs(Apple Push Notification service)을 서비스로 제공한다.

이와 마찬가지로 푸시 알림 서비스를 활용하는데 있어서, 자체적인 서비스를 만들고 싶다면 MQTT로 활용이 가능하다.


대표적으로, Facebook Messenger에서는 푸시 알림 서비스 방식으로 MQTT를 활용하고 있다고 한다.
출처 : https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

 

MQTT는 중개자(Broker) 서버를 두고, 발행/구독(Publish/Subscribe) 방식으로 동작하는 환경에서 이용하는 프로토콜이다.

 

 

발행자(Publisher)는 Topic을 발행하고, 중개자(Broker)를 통하여, 구독자(Subscriber)가 요구하는 Topic 정보를 얻는 구조로 되어 있다. Publisher(나)가 해당 Topic과 보낼 메세지를 Broker 서버에 전송하면, 해당 Topic을 구독하는 Subscriber(친구들)에게 Broker 서버에 설정된 일정 Keep Alive Timer를 통해 푸시 알림을 보내게 된다.

 

또한, MQTT 는 메시징에 대한 신뢰성 보장을 위하여 3단계의 QoS(Quality of Service) 지원한다. 물론 QoS 레벨이 높을수록 패킷 손실율은 줄어들지만, 종단 간 통신 지연시간은 늘어나게 된다.

 

 

 

QoS 0 은 메시지를 한번만 전달하고 전달 여부는 확인하지 않기 때문에 큰 페이로드를 가지는 메시지 일 경우, 메시지 손실이 발생하면 메시지가 전달 되지 않고 유실될 가능성이 높다.
QoS 1은 메시지를 전달하고, 1번의 Ack로 전달 여부를 확인한다. 하지만 PUBACK 패킷이 유실 된다면 메시지가 불필요하게 중복 전달 될 가능성이 있다.
QoS 2 는 4-Way Handshake을 통해 정확하게 한번만 전달한다.


또한, Topic은 계층적으로 구성이 가능하다.

 

 

 

다음과 같이 계층적으로 Topic을 생성하여 전달할 수 있다.

 

 

 

1. Broker Server 설치 (Mosquitto Broker Server)

  - 저장소 업데이트

$ sudo apt-get install python-software-properties
$ sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
$ sudo apt-get update


  - 저장소 업데이트 확인

 $ sudo apt-cache search mosquito


 

 

  - Mosquitto 서버 설치

$ sudo apt-get install mosquitto

 

 

 

2. Test용 MQTT Client 설치 및 테스트

  - MQTT Client 설치

$ sudo apt-get install mosquitto-clients

 

 

 

 - MQTT Subscribe Client를 이용한 메시지 구독

$ mosquitto_sub - h Server Address -t /Topic

 

 

 - MQTT Publish Client를 이용한 발행

$ mosquitto_pub - h Server Address  -t /Topic​ -m "Message"

 

 

 

 - MQTT Subscribe Client에서 해당 Topic에 대한 푸시 알림 메시지 구독 완료

 

 

 

MQTT Client는 다양한 언어의 형태와 라이브러리로 제공되고 있으며, 해당 정보에 대한 링크는 아래와 같다.
https://github.com/mqtt/mqtt.github.io/wiki/libraries



테스트 환경 : Ubuntu 16.04


+ Recent posts