Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

이번 장에서는 미들웨어 설정에 대하여 자세히 살펴볼 것이다. MCollective 를 배우는 목적이라면 이 장에서 설명하는 것을 모두 이해할 필요는 없다. MCollective가 지금의 환경에서 정상 동작을 하고 요구사항에 맞다면 이번 장을 자세히 읽어야 한다.

이번 장을 주의깊게 읽어야 하는 이유는 다음과 같다.

  • 미들웨어 브로커에 연결을 하는데 어려움을 겪고 있다
  • 더 많은 호스트를 처리하기 위해 ActiveMQ를 튜닝한다.
  • 원격 site 에 network of brokers 를 구현하고 싶어 한다.
  • master/slave redundancy 를 찾고 있다.

미들웨어에서 어떠한 설정을 변경하든지, 대부분의 변경 작업은 관리하는 서버의 성장을 어떻게 다룰지와 관련이 있다. 미들웨어 설정을 자세히 이해하는 것이 필수적이다.

Messaging Brokers

MCollective 는 클라이언트, 서버, 리스너 간에 메시징 서비를 제공하기 위해서 publish/subscribe 미들웨어를 사용한다. 디자인 측면에서 MCollective는 미들웨어 브로커와 통신하기 위해 connector plugins를 사용하며 이를 통해서 미들웨어와 통신 형태에 대해 유연성을 부여한다. core 설치를 할때는 다음의 미들웨어 플러그인을 지원한다. (그렇지만 다른 기술에 기반하여 자신만의 미들웨어 connector 를 만들 수 있다)

이 와 같은 미들웨어 기술은 널리 사용되고 있고 개발자 커뮤니티를 통해서 활발하게 지원이 된다. 이러한 것들은 소규모 배포, 대규모 클러스터, 대규모 계층적 배포 등에서 사용할 수 있다. 이러한 기술은 몇천대 이상의 환경에서도 널리 사용되고 있다.

Apache Apollo 는 ActiveMQ를 대체하기 위한 차세대 메시징 서버이다. Apache Apollo 는 ActiveMQ connector를 이용하여 MCollective에 사용할 수 있다. 그렇지만 이 책을 쓸 당시까지는 클러스터링을 지원하지 않았다.

유명하고 활발하게 개발되고 있는 오픈 소스 메시지 브로커를 사용하기 때문에 MCollective는 상용 소프트웨어에 묶이지 않는 인프라를 구축할 수 있다. p17의 "Configuring ActriveMQ" 의 activemq.xml 파일의 미들웨어 설정에 대하여 살펴보자.

Network Security

다음은 미들웨어 브로커를 설정할 때 보안상 고려해야 할 부분이다.

Transport Connectors

사용하지 않는 transport connector 는 비활성화해야 한다. 예를 들어 ActiveMQ 미들웨어에 대한 TLS 암호화를 활성화했다면, 비암호화된 connector 에 대해서는 주석 처리를 한다.

호스트에 여러 개의 IP 를 가지고 있는 경우, ActiveMQ에서 해당 IP에 대해서 응답을 하려면 0.0.0.0 이나 ::0 을 해당 IP로 변경해야 한다. 모든 서버와 클라이언트는 이 IP에 접근할 수 있어야 한다. 각 IP로 분리하는 것이 필요하다면 반복해서 설정을 하면 된다.

 

방화벽 설정

MCollective 는 미들웨어 브로커의 적절한 TCP 포트로 inbound 세션을 연결할 수 있어야 한다. 다음 테이블 목록은 미들웨어 브로커와 관리자 인터페이스에서 사용하는 포트를 명시하고 있다.

Middleware

Usage

TCP Port

Action

ActiveMQ

RMI Port

1098

Limit to management hosts

ActiveMQ

JMX Console

1099

Limit to management hosts

ActiveMQ

Web Console and Jolokia

8161

Limit to management hosts

ActiveMQ

STOMP unencrypted

61613

Allow

ActiveMQ

STOMP+SSL

61614

Allow

ActiveMQ

OpenWire unencrypted

61616

Limit to brokers

ActiveMQ

OpenWire+SSL

61617

Limit to brokers

RabbitMQ

STOMP unencrypted

61613

Allow

RabbitMQ

STOMP+SSL

61614

Allow

iptables 를 이용하는 방법은 생략.

IPv6 Dual-Stack Environments

생략

ActiveMQ 설정 구조

ActiveMQ 설정은 꽤 길며 현재 파일의 위치가 헷갈린다. 시작하기 전에 간단하게 파일의 구조를 살펴보자.

  • There is a single broker element that handles all MCollective configuration.
  • Flow control and,  garbage collection : policyEntry elements 에 정의되어 있다.
  • Users : authenticationUser elements.
  • Access rules : authorizationEntry elements.
  • System resource limits : systemUsage elements.
  • Network connectors for clients : transportConnector elements.
  • Network connectors for other brokers : networkConnector elements.
  • The SSL keyStore and trustStore : sslContext element.

ActiveMQ 5.8과 5.9에 대한 activemq.xml 예제는 https://github.com/jorhett/learning-mcollective/tree/master/examples 에서 볼 수 있다. 이 예제들은 이 책에서 설명하고 있는 것을 담고 있으며 Puppet module 의 ActiveMQ 템플릿을 통해서 생성한 결과를 담고 있다.

https://github.com/jorhett/learning-mcollective/blob/master/examples/activemq_59.xml

자세한 설정 정보 보기

앞 섹션에서는 다음의 정의에 대해서는 빠져있다.

Broker Definition

broker element 는 모든 서버와 클라이언트가 통신을 할 ActiveMQ 자바 애플리케이션을 정의한다.

brokerName 은 단일 인스턴스에 대해 어떠한 이름이라도 사용할 수 있으며 localhost 값으로도 충분하다. network of brokers 에서는 각 브로커마다 유일한 이름이 필요하다. 이에 대해서는 "ActiveMQ Clusters"에서 설명을 할 것이다.

networkConnectorStartAsync 는 ActiveMQ가 병렬로 모든 네트워크 커넥션을 활성화할지를 가리킨다. 이 파라미터는 network of brokers 를 가질 경우에만 필요하지만 기본값을 사용하면 된다.

schedulePeriodForDestinationPurge 에 60,000 milliseconds (60초)를 지정하였는데 ActiveMQ가 매분마다 불필요한 큐(stale queues)를 검색하는 것을 말한다. 이 설정은 policyEntry gcInactiveDestinations 가 활성화되어 있는 큐에 대해서 작동을 한다. 이러한 큐는 놀고 있고 비어있을 때 가비지 컬렉트 된다.  자세한 정보는 http://activemq.apache.org/delete-inactive-destinations.html 참고.

Topic and Queue Tuning

MCollective는 producer flow control(http://activemq.apache.org/producer-flow-control.html) 을 사용하지 않을 때 가장 동작을 잘한다. Producer flow control 은 메모리나 디스크 용량이 초과했을 때 producers 를 늦출 때 사용한다. This usually only occurs when you have many applications delivering large volumes of data to a slow processor that works through a queue on its own timeline.

MCollective 요청은 작고 빠르며 일시적이다. 대부분의 질의에 대한 타임아웃은 10초이다. agent 나 clients 는 일반적으로 대규모 데이터를 보내지는 않으며 client 는 가능한한 빠르게 응답을 받을 것을 예상하고 있다. Mcollective  client 와 server가 flow control 의 overhead 없이 사용할 수 있도록 하는게 좋다.

> 문자는 어떤 문자를 포함하는 와일드카드이다. 첫번째 문자로 사용을 했기 때문에 모든 토픽과 큐는 이 룰에 연관된다.

pending subscriber messages  를 위한 vmCursor 값은 MCollective 가 모든 토픽 정보를 메모리에 올려서 빠르고 효율적으로 배포할 수 있도록 해준다. http://activemq.apache.org/message-cursors.html.

다음 설정에서는 5분 동안 활동하지 않는 큐를 정리한다. (5분안에 새로운 요청이 큐에 들어오지 않으면 큐를 정리하고 메모리를 회복함):

모든 요청은 응답을 수집하기 위하여 새로운 reply queue 를 생성한다. request timeout(기본은 10초) 이후에 클라이언트는 reploy queue 를 리스닝하는 것을 멈춘다. 가비지 컬렉션이 없으면 ActiveMQ의 메모리가 모두 소모될때까지 reply queue 의 숫자가 증가할 것이다. 이러한 룰을 통해 방치된 reply queues 를 정리한다.

policyEntry for queues 는 두가지 파라미터를 가지고 있다.:

  • gcInactiveDestinations : 브로커가 정책에 일치하는 큐에 대해 가비이 컬렉션을 하도록 함. (지금 예에서는 모든 큐에 대해서 적용)
  • inactiveTimeoutBeforeGC : 5분동안 idle 상태에 있는 경우 큐를 제거하도록 함.

매우 많은 reply queues 가 있고 빠르게 정리가 된다면, inactiveTimeoutBeforeGC 값을 기본값이 1분(60000)으로 조정할 수 있다.

토픽에서 pending queue messages 를 위한 vmQueueCursor 값은 MCollective 가 모든 큐를 메모리에 유지하여 빠르고 효율적으로 배포하도록 설정을 한다. http://activemq.apache.org/message-cursors.html.

Authentication and Authorization

미들웨어 인증에서 가장 중요한 부분은 nodes queue 와 agent topics 이다. 이것들은 요청에 응답해야 할 서버들에 메시지를 전달한다.

To consider the marionette metaphor, these are your strings. node queue 에 대한 메시지는 하나의 노드에만 전달이 된다. agent topc 에 publish 한 메시지는 해당 agent 가 설치된 모든 mcollectived 대문에서 받고 처리가 된다.

Users and groups

users 와 할당할 그룹을 정의한다.

authorizationPlugin 섹션에 정의되는 모든 authorization rules 은 usernames이 아닌 groups 을 사용한다. 원한다면 추가로 usernames와 비밀번호를 만들 수 있지만 이것은 어떤 명령어가 서버에서 실행 가능한지를 제어하는 것은 아니라는 것을 기억해야 한다. 이것은 오직 각 topic이나 queue 에 누가 요청을 보낼 수 있는지를 제어하는 것이다. 일반적으로 middleware authentication 에서 이 세가지 그룹을 이용하도록 하고 authorization rules 를 사용하여 제어하는 것이 가장 좋다. p163 “Authorization” 참고.

우리의 초기 설정에서는 오직 두 user 만 가지고 있다는 것을 알아챘을 것이다. 우리는 broker user를 포함할 것이며 p113 “ActiveMQ Clusters” 에서 소개할 것이다.

Topics and queues the clients send to

첫 번째로 알아야 할 것은 brokers 그룹을 정의하고 여기에 모든 queue 와 topic 에 쓰기 권한을 주는 것이다. (클러스터 설정에서 데이터를 relay 하기 위해 브로커에서만 사용을 함. p113 “ActiveMQ Clusters” 에서 설명할 것임):

다 음은 clients 에게 MCollective topics 와 queues 에 글로벌하게 읽기, 쓰기 권한을 준다. > 문자는 와일드카드이며 MCollective에 있는 모든 topics 나 queues 에 접근을 허용한다.:

admin permission 은 클라이언트가 해당 토익이나 큐가 없으면 생성할 수 있도록 허용한다.

이 예에서 우리의 collective 이름은 mcollective 이고 이것이 기본값이다. 12장에서 여러개의 collectives를 사용하는 것에 대해서 논의할 것이다. 이 때 각 collective의 이름에 대해 마지막 두 라인을 설정해야 한다.  At that time, you’ll need to duplicate the last two lines with each collective’s name.

Topics and queues the servers read from

서버 노드에서 MCollective agent topics 에 대해 읽거나 생성하는 것을 허용한다.

agent topics 은 해당 agent를 가진 여러 노드를 위해 클라이언트에서 요청을 하는 곳이다. 예를 들면 mco puppet runonce 명령은 mcollective.puppet.agent topic 으로 보내질 것이다.:

여기에서는 서버 노드에서 MCollective node queue 에 대해 읽거나 생성하는 것을 허용한다. MCollective node queue는 단일 MCollective 서버를 위해 명령을 위치하는 곳이다.

topics 과 queues에서는 명시적으로  write 퍼미션을 사용하지 않는다. 왜냐하면 위의 wildcard client rules 에서 클라이언트가 이러한 큐에 대한 쓰기 권한을 허용하고 있기 때문이다. 서버는 이러한 큐에 대해서는 쓰기권한이 있으면 안된다. The topics and queues don’t use an explicit write permission because the wildcard client rules above them allow clients to write to any of these queues. The servers should not write to these queues.

Topics and queues the servers write to

다 음은 서버 노드에서 agent topics을 생성하거나 데이터 제공하는 것을 허용할 것이다. the registration agent (이러한 정보는 서버 연결을 할때 그리고 주기적으로 보내진다. 21장에서 registration 에 대해서 더 자세히 논의할 것이다):

그러고나서 서버가 해당 정보 수집을 위해서 성성된 큐에 응답하는 것을 허용할 것이다.:

<authorizationEntry queue="mcollective.reply.>"

write="servers" admin="clients"

/>

예 를 들어, filemgr agent 에 명령을 내리고 해당 요청에 할당한 유일한 숫자가 170075 이면 filemgr_170075 로 명명된 reply queue 가 생성될 것이다. 필터에 해당하는 각 서버는 mcollective.reply.filemgr_170075 큐에 응답을 보낼 것이다. client는 큐에서 각 응답을 읽을 수 있다.

Transport Connectors

transportConnector element는 서버와 클라이언트가 IP 네터워크를 통해서 미들웨어 브로커와 연결하는 방법을 정의한다.

모 든 MCollective 메시지는 Streaming Text Oriented Messaging Pro‐tocol (STOMP) 패킷으로 포맷이 된다. 다음 설정은 ActiveMQ’s New I/O (NIO) library 를 사용하는 STOMP 프로토콜을 생성한다.

NIO 인터페이스는 훨씬 더 좋은 성능을 낸다. NIO 없이 stomp connector 를 쓰는 것은 아주 작은 규모에만 적합하다.

하나의 인터페이스네 특정한 IP 주소를 사용할 수 있으며 원한다면 TCP port를 변경할 수 있다. 다음 예제에서는 TCP port 6163과 함께 특정 IP4와 IPV6 주소를 보여준다:

p113 “ActiveMQ Clusters” 에서 다른 ActiveMQ brokers 와 링크하기 위해 어떻게 networkConnector elements 를 사용하는지 배울 것이다.

11장은 MCollective 노드와 미들웨어 브로커간에 트래픽을 보호하기 위해 어떻게 TLS 암호화를 활성화하는지 배울 것이다.

Management Interfaces

ActiveMQ 를 오직 MCollective와 사용을 한다면 ActiveMQ에 대한 관리 콘솔이 꼭 필요한 것은 아니다. MCollective 애플리케이션의 필요성은 일반적으로 작고 임시적이기 때문에 대규모 데이터 스트림이나 긴 질의에 대한 튜닝은 필요가 없다.

그렇지만 다음 섹션에서 설명을 하는 내용은 ActiveMQ를 구현하면서 문제가 있어서 디버깅을 할 때 유용하다.

Web Console

Web Console을 활성화하면 ActiveMQ의 큐와 토픽을 확인할 수 있는 웹 인터페이스를 제공한다. 각 토픽과 큐를 통해서 얼마나 많은 메시지들이 처리가 되는지, 많이 쌓여있는 큐를 확인하 는 등의 작업이 가능하다.

ActiveMQ box 의 8161 port를 이용하여 콘솔에 접근할 수 있다.http://activemq.example.net:8161/admin

WebConsole 을 활성화 하려면 ActiveMQ 파일에서 Jetty 부분을 편집하면 된다.

7장에서 설명한 Puppet module 을 사용하고 있으면 다음과 같이 비밀번호를 이용하여 보안을 강화할 수 있다.

기본은 Web Console 연경은 암호화가 되어 있지 않다. 이 부분을 사용하려면 conf/jetty.xml 파일에서 SecureConnector element 의 주석을 제거해 준다.

더 자세한 정보는 http://activemq.apache.org/web-console.html 참고.

Jolokia API and HawtIO

생략

JMX MBean Console

생략

Statistics plugin

생략

결론

이번 섹션에서는 초기 셋업시 사용한 기본 설정의 각 튜닝 파라미터에 대해 알아 보았다.

MCollectie 에서 사용하는 토픽과 큐에 대한 구조를 살펴보았다.

TransportConnector element 와 왜 Java NIO connector 가 필요한지 설명하였다.

ActiveMQ 디버깅을 위한 여러가지 관리 인터페이스를 살펴보았다.

다음 섹션에서는 대규모 환경에서 보안과 안정성을 강화하는 방법을 설명할 것이다.

ActiveMQ Clusters

collective 를 수천대 노드로 확장하거나 여러 sites 를 가지고 있다면 다음을 원할 것이다.

  • sites 간에 메시지를 전달하기 위해 network of brokers 구성
  • 사이트에 redundancy 를 제공하기 위해 master/slave 동기화 구성
  • 사이트 간의 트래픽 암호화

이 모든 옵션을 쓰거나 조합해서 사용할 수 있다.

Network of Brokers

network of brokers 구성은 서로 다른 물리적인 지역에 ActiveMQ 서버를 두려고 하고 ActiveMQ 서버들을 단일하고 일관된 메시지 space 로 운영하는 경우 유용하다. 다음은 linkage 를 세팅하기 위해 두개의 ActiveMQ 시스템을 추가할 때 사용한다.

networkConnector 에 대한 튜닝 옵션은 다음 참고. http://activemq.apache.org/networks-of-brokers.html

broker user를 brokers group에 두면 받아들이는 ActiveMQ 서버에 모든 토픽과 큐를 쓸 수 있다. replication 이 작동하려면 이러한 작업이 필요하다.

각 지역에서는 클라이언트가 가까운 미들웨어 브로커로 연결을 하도록 설정할 수 있다. 모든 메시지는 두 지역간에 전송이 될 수 있어서 단일 collective 가 sites 에 걸쳐 정확하게 작동할 수 있도록 할 수 있다. redundancy 를 걱정한다면 클라이언트에서 로컬 사이트가 다운되었을 때 다른 사이트로 fail over 하도록 설정할 수 있다.

The Puppet Labs site indicates that you will need two connections, one for topics and another for queues, at http://bit.ly/UttA1X. My tests were unable to confirm this—I used these settings successfully with clients and servers on each side.

이 책에 포함된 Puppet module 에서는 간단하게 hosts Hiera 파라미터에 여러 개의 브로커를 추가하고 broker 비밀번호를 제공해서 간단하게 구성을 할 수 있다.

브로커에 접속하기 위한 다른 파라미터들은 모두 동일하다.

클 라이언트나 서버에서 오직 로컬 노드만 사용하도록 제한을 하고 싶을 때도 있다. 각 모듈은 각자의 레이어에서 값을 변경할 수 있다. 두가지 방법이 있다. The easiest is only to inform the brokers of all nodes:

또는 서버에서는 로컬 로드를 사용하고 브로커와 클라이언트는 모든 노드를 사용하도록 설정할 수도 있다.

대 규모 환경(2,000-3,000 노드이며, 브로커간의 지연시간에 달려있음)에서 discovery 는 기본값인 2초 보다는 길 수 있다.  5,500 노드를 가진 실환경에서 모든 노드에서 지속적으로 응답을 받는데는 discovery 에 10초가 필요하다는 것을 발견하였다. client app에서 discovery timeout (Part III에서 설명할 것임)을 늘리거나 모든 CLI 명령에서 타이핑하는 것을 피하기 위해 환경 변수를 설정할 수있다.

$ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 10 --timeout 5"

Master/Slave Redundancy

단일 지역에서 빠르게 failover 응답을 하고 싶다면 master/slave cluster 셋업을 원할 수 있다. 이러한 설정에서는 두 브로커에 아래와 같은 동일한 설정을 원할 것이다.

networkConnector uri 를 신경써서 보자. 처음에 적은 호스트가 master 이며 그 뒤에 적은 모든 호스트네임은 slave 이다.모든 ActiveMQ 브로커에서 동일한 순서로 목록을 가지고 있어야 한다.

networkConnector 에 대한 튜닝 옵션은 http://activemq.apache.org/networks-of-brokers.html 참고.

서버와 클라이언트에서 slave 로 fail over 를 하려면 서버와 클라이언트 설정 파일에서 다음 내용을 변경해야 한다.

이 책에서 제공하는 Puppet module 에서 master/slave 설정을 하려면 다음의 Hiera 파라미터를 설정하면 된다.

borkers 에 접속하는 모든 다른 파라미터는 동일해야 한다.

Broker Links 암호화

site 간에 링크를 SSL/TLS 암호화하고 싶을 것이다. 이렇게 하라면 P129 "Anonymous TLS"의 KEYsTORE 와 p132 의 "CA-Verified TLS Servers" 의 trustStore 를 만들어야 한다.

그러고나서 적절한 프로토콜을 사용할 수 있도록 site 간에 ActiveMQ 설정을 조정해야 한다.

Puppet module 에서는 다음과 갈이 Hiera 파라미터를 변경하면 된다.

결론

이번 섹션에서는 다중 브로커 사용을 하는 두가지 모델을 살펴보았다.

  • 서로 다른 site 간에 연결을 제공하기 위한 network of brokers
  • 하드웨어 장애를 극복하기 위한 master-slave redundancy

You can blend both of these options to connect a master/slave pair of brokers to brokers at remote sites.

대규모 환경에서 브로커 설정하기

대규모 브로크 설정으로는 두가지 타입이 있다.

  • 단일 broker 를 사용하는 많은 클라이언트
  • 전세계상에 분포되어 있는 많은 사이트 brokers

동일한 조직에서 두가지 설정을 사용할 수 있다. 각각의 필요성에 대해서 다룰 것이다.

저 자는 자주 "고성능의 ActiveMQ 설정"에 대한 요청을 본다. 이러한 설정에 대한 기본 권장사항은 있다. 그렇지만 MCollective 환경이 size 나 네트워크 지연시간등이 커짐에 따라 네트워크와 요구사항에 맞게 조정을 해야 한다.

In my personal time, I race motorcycles on closed courses for fun. Let’s think about tuning using motorcycle (or car) racing as an analogy.

A street motorcycle/car works on all streets without custom changes because the needs are simple. You only go about half as fast as it can go, and you don’t brake to the limits every time you stop. This is like a basic middleware broker: it can easily handle a few hundred nodes without any tuning.

 

Once you are trying to run at top speed, maintain the highest corner speed, or brake down from the highest speed without losing control, your demands are much higher. So you have to tune your motorcycle/car to perform at that level.

 

You can get some basic tuning assistance from anyone, but to run with the very best, you must tune your motorcycle to the conditions at each track you go to. Everything from riding style to corner banking to air temperature will play into the tuning equations. The most successful race teams tune their race bike/car to the specific needs of that specific track on that specific day.

 

Small sites (street drivers) can use MCollective without any special tuning. Big sites with big demands (racers) need to tune MCollective for the special needs of their own

racetrack, which will be different than every other racetrack.

 

This analogy only goes so far—thankfully, you won’t need to retune MCollective every day. As your environment grows, you’ll need to tune MCollective differently for your specific network (track) and for your specific usage (riding style). What works on a different network or to support different applications won’t necessarily work for you.

이 번 섹션에서는 대규모 클라이언트나 대규모 볼륨 트래픽을 위해서 ActiveMQ 를 튜닝하는 방법에 대해 다룰 것이다. MCollectie 와 관련없이 ActiveMQ에서 튜닝할 파라미터가 많이 있다. 여기에서는 이런 부분에 대해서는 생략을 하고 MCollective 와 연관된 내용만 다룰 것이다.

MCollective 에서 필요한 부분 이해하기

Puppet Lab의 문서에서는 미들웨어 규모에 대해 매우 보수적인 권장사항을 가지고 있다.

http://docs.puppetlabs.com/mcollective/deploy/middleware/activemq.html#settings-for-networks-ofbrokers

Scale — we recommend a maximum of about 800 MCollective servers per ActiveMQ broker, and multiple brokers let you expand past this.

이것은 안전한 룰이다. 실제로는 어떠한 환경에 있느냐에 따라 달라진다. 저자는 브로커당 내베에 달하는 sites 에 간여한 적이 있었다. 또한 이 숫자보더 다 낮은 수치를 보이는 sites 도 있었다. 정확한 필요성에 대한 답변을 위해 필요한 것은 이를 해결하기 위해 더 많은 시간을 써야 한다는 것이고 시간에 걸쳐 설정을 변경해야 한다는 것이다.

먼저, 당신의 네트워크에서 어떤 것이 MCollective 를 빠르게 할 수 있는지 살펴보자.

  • Bigger network pipes , Low-latency links

아 주 소규모 환경에 MCollective 는 상당한 네트워크 트래픽을 발생시킬 수 있는데 이 경우 대규모 데이터 전송을 하는 agent 를 만들거나 쓰는 것은 당신이라는 것을 알 것이다. 대부분의 요청과 응답은 크기가 매우 작으며 매우 작은 규모의 패킷을 수백개 발생시킬 것이다.

MCollective 는 브로커간에 network links 에 대한 지연시간에 매우 민감하다. 저자는 가능하다면 star 보다는 mesh 로 모든 networks of brokers를 구현하는게 가장 좋다는 것을 발견하였다. mesh 에서는 전송하기 전에 중앙 라우팅 큐를 거치는 대신에 단일 hop 으로 destination 에 트래픽을 보낼 수 있다.

https://en.wikipedia.org/wiki/File:NetworkTopology-FullyConnected.png

https://en.wikipedia.org/wiki/Star_network

  • Dozens of CPU Cores , Gigbabytes of RAM

ActiveMQ 는 수직적(서버 하드웨어 사양을 업그레이드 하는 것)으로 확장할 수 있는 것으로 보이지는 않는다. ActiveMQ를 좀 더 사양이 좋은 하드웨어 박스로 옮겼지만 성능상의 이점은 없었다. 저자의 경험으로 볼때 OpeStack/KVM 또는 VMware ESX 가상 호스트를 사용을 할 때도 비슷한 스펙의 bare metal 호스트와 동일한 성능을 냈다. 대부분의 환경에서 ActiveMQ 큐가 부하가 걸려서 CPU 활용은 매우 낮은 상태에서 운영이 되었다.

더 높은 성능을 위해서 ActiveMQ 을 튜닝하는 가장 좋은 방법은 더 많은 메모리를 이용하는 것이다. 기본 설치를 할 경우에 Java 애플리케이션은 512MB 의 제한이 있고 ActiveMQ broker 는 20MB의 램만 사용을 한다. 오늘날 작은 시스템이라고 하더라도 이보다는 훨씬 더 많은 메모리를 가지고 있고 저자는 주로 이 제한보다 4배 또는 8배로 설정해서 사용을 했다. Java는 오직 자신에게 필요한 만큼만 사용을 한다. 저자는 ActiveMQ 5.8이나 5.9에서 치명적인 메모리 leakage 는 보지 못했다.

  • Less collectives with more machines , Localized collectives avoid transit

5,000 도를 가진 collective 에 질의를 던지면 discovery 하는 동안에 모든 5,000 호스트에 요청을 브로드캐스트할 것이다. 각 호스트는 필터를 읽고 응답을 할지를 결정해야 한다. collectives 를 나누고 대부분의 메시지를 로컬 subcollective 로 보낸다면 cross-site 네트워크 트래픽을 상당히 줄일 수 있다. 12장에서 이에 대해서 설명을 할 것이다.

기본 튜닝을 위한 추천사항

고성능의 미들웨어를 설정하기 위해 모든 site 에서 필요한 일반적인 설정에 대해서 설명을 한다.

  • Set org.apache.activemq.UseDedicatedTaskRunner to false in the wrapper configuration file, or use -Dorg.apache.activemq.UseDedicatedTaskRunner=false in the command-line arguments. (무슨 내용인지 이해는 안 감.)
  • 시스템에서 활용 가능한 메모리의 대부분을 Java Max Memory 로 사용할 수 있도록 튜닝을 함. A dedicated broker isn’t doing much else with that memory, is it? 대부분의 플랫폼에서 activemq-wrapper.conf  파일에  설정을 하거나 명령 라인에서 -Xmx512m 옵션을 준다.
  • p101의 “Detailed Configuration Review” 에서 이야기를 한대로 producer flow control 을 비활성화 했는지 확인한다. 유실되는 큐 메시지를 본다면 systemUsage/systemUsage/memoryUsage 를 Java Max Memory 크기의 70%로 설정을 한다. 수천대의 클라이언트를 지원하거나 대규모 reply queues 를 지원하는 broker 에서는 수기가바이트가 되어야 할 것이다.
  • 다 른 네트워크를 많이 가지고 있거나 널리 분산된 sites를 가지고 있는 경우에는 각 지역에 subcollectives를 만든다. p145 “Localizing Traffic”에서 이에 대해 설명을 한다. 필요하다면 전체 collective 에 요청을 할 수도 있지만 이것이 기본은 아니다.  If you have many distinct networks or widely dispersed sites, create subcollectives for each location or region, as discussed in  on page 145. You can still initiate requests to the entire collective when necessary, but it shouldn’t be your default.

몇천대의 서버 지원하기

ActiveMQ 브로커에서 몇천의 연결을 처리하려면 노드의 TCP stack을 튜닝해야 한다. 저자와 다른 사람들이 발견혔던 유용한 몇가지 추천사항이 있다. 리눅스가 아닌 시스템에서 적절한 튜닝 지점을 찾아야 할 것이다.

# More file descriptors == more open TCP connections

ulimit -Hn 8192

ulimit -Sn 8192

 

# Close and reuse finished TCP sessions faster

/sbin/sysctl -w net.ipv4.tcp_fin_timeout=15

/sbin/sysctl -w net.ipv4.tcp_tw_reuse=1

 

# Identify failed TCP links faster

/sbin/sysctl -w net.ipv4.tcp_keepalive_time=300

/sbin/sysctl -w net.ipv4.tcp_keepalive_intvl=30

/sbin/sysctl -w net.ipv4.tcp_keepalive_probes=5

 

# Allow connection backlog of 2000 connections

# Required as STOMP clients reconnect quickly

/sbin/sysctl -w net.core.somaxconn=2000

/sbin/sysctl -w net.core.netdev_max_backlog=2000

 

# Increase size of TCP read and write buffers

/sbin/sysctl -w net.core.rmem_default=256960

/sbin/sysctl -w net.core.rmem_max=5242880

/sbin/sysctl -w net.core.wmem_default=256960

/sbin/sysctl -w net.core.wmem_max=5242880

 

# Disable timestamps

/sbin/sysctl -w net.ipv4.tcp_timestamps=0

각 플랫폼별로 적절한 파일에 저장을 하여 영구적으로 사용을 할 수 있도록 해야 한다. 리눅스에서는 ulimit 변경은 /etc/security/limits.conf 에 저장을 하고 sysctl 변경은 /etc/sysctl.conf 파일이다.

중 요한 변경 중 하나는 discovery timeout 값을 변경하는 것이다. 2,000-3,000 노드 이상의 큰 규모라면 (브로커간의 지연시간에 의존하는) discovery 는 기본값인 2초보다는 더 걸린다. 5,500 노드를 가진 실환경에서 discovery 가 모든 노드에서 지속적으로 응답을 받으려면 10초가 필요하다는 것을 발견하였다.

client apps 에서 discovery timeout(Part III에서 논의함) 를 늘릴수 있도록 하거나 모든 CLI 명령에서 타이핑을 하지 않도록 환경 변수를 설정한다.

$ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 10 --timeout 5"

클라이언트에게 모든 노드가 로컬이면 timeout for requests 를 동일한 크기로 늘릴 필요는 없다.(question)  Discovery 는 requests timeout 의 두배는 되어야 한다. As you can see, we did not need to extend the timeout for requests to the same length when all nodes were local to the client. Discovery needed to have twice the timeout as the requests themselves.

글로벌하게 분산된 서버에 대한 고려 사항

첫 번째로 고려를 할 수 있는 것은 지연시간이 큰 대륙강의 링크인 상황과 같이 글로벌하게 분산된 브로커를 고려한다면, 각 지역별로 다른 collectives 를 사용하여 가능한한 트래픽을 로컬에서 처리하는 방식이 있다. local collectives 로 노드를 분리하고 로컬 collective에 대부분의 메시지를 보내면 cross-site 네트워크 트래픽은 현저히 줄어들 것이다. 12장에서 설명을 한다.

두번째로 생각할 수 있는 것은 broker links 를 가능하다면 start 설정으로 하거나 modified start 설정으로 하는 것이다. 당신은 클라이언트와 서버 사이에 hops(요청을 처리해야 하는 브로커의 수)을 최소화하기를 원할 것이다. 이렇게 하면 reply 의 지연시간을 줄일 수 있으며 timeout 에 처하는 상황을 줄일 수 있다. (내용은 이해가 안 감..)

대규모 네트워크에서 timeout는 언제나 피할 수 있는 것이 아니다. 대륙간의 네트워크는 브로커 사이에 높은 지연시간을 만들 수 밖에 없다. 이러한 요청사항에 따라서 처리를 해야 한다:

  • 튜닝 가능한 하나의 옵션은 discovery timeout 이다. 7개의 글로벌 사이트를 가진 실환경에서 모든 노드에서 응답을 받는 discovery 에 5초가 필요했었다.
  • 또 하나의 튜닝 가능한 옵션은 request timeout 이다. 같은 환경에서 최소한의 적절한 request timeout 은 동일한 숫자였다.

커맨드라인 애플리케이션에서 다음과 같이 환경변수를 설정할 수 있다.

$ export MCOLLECTIVE_EXTRA_OPTS="--discovery-timeout 5 --timeout 5"

custom client 애플리케이션에서는 application 자체에서 timeouts을 설정할 수 있으며 Part III 에서 설명을 한다.

ActiveMQ 5.9.1 로 업그레이드하기

ActiveMQ 5.8 에 비하면 5.9 가 대량의 SSL/TLS 클라이언트를 처리하는데 훨씬 더 좋았다.

원 래 ActiveMQ는 작은 숫자의 연결된 노드를 위해 개발이 되었다. ActiveMQ 사용이 많아지면서 기본 connector 는 대규모의 클라이언트를 처리하지 못했다. 새로운 connector 는 Java Non-blocking I/O (NIO) 라이브러리에 기반하여 새로 만들어 졌다. 이 connector 를 Active 5.8 에서도 사용 가능하지만 SSL 연결은 처리를 하지 못했다.

저자의 경험에 의하면 표준 stomp+ssl connector 는 500 active 연결이 넘으면 실패하기 시작한다. 대부분의 TCP 연결은 되지만 STOMP negotiatin 은 성공을 하지 못한다.

ActiveMQ 5.9 는 stomp+nio+ssl connect를 제공하며 대규모의 SSL 클라이언트를 처리할 수 있다.

알려진 문제점 확인하기

이책을 쓸 당시 다음과 같은 문제점들이 있었음. 자세한 내용은 책 참고.

  • The ActiveMQ connector does not close TCP sessions when it fails to complete an SSL connection
  • ActiveMQ 5.8.0 has only a half-second tolerance for heartbeat failures
  • No more than 500 SSL/TLS connections per broker

ActiveMQ 5.9.1로 업그레이드를 하면 STOPM+NIO+SSL (https://activemq.apache.org/configuring-transports.html) 를 transport 로 사용할 수 있다.

결론

  • 가능한한 많은 메모리를 Java engine 에 사용하고 borker 의 크기도 이에 맞춤. 브로커는 오직 필요한 메모리만 사용을 할 것임
  • oepn files 의 숫자를 늘리고 네트워크 연결을 위한 read, write 버퍼를 늘린다. sysctls 이용.
  • 대규모 클러스터나 지역적으로 분산된 사이트에서는 트래픽을 분리하기 위해 여러개의 collectives를 사용함.
  • 수백대 이상의 서버에서 TLS 인증을 사용하려면 SSL-enabled NIO connector를 사용하기 위해 ActiveMQ 5.9.1 로 업그레이드를 한다.
  • 서버와 클라이언트간에 메시지가 전달될 브로커 숫자를 제한하기 위해서는 start 또는 modified start  설정을 사용한다.
  • 설정상의 잘못은 서버나 클라이언트를 작동하지 않게 하기도 하고 연결을 시도하려고 한다. 미들웨어 호스트에서 IP 주소당 열린 커넥션 숫자를 확인하고 잘못 설정된 노드를 찾아내야 한다.
  • 모든 서버가 클라이언트에 응답을 전달하기 위해 필요한 discovery, request timeouts 를 늘여야 한다.

network of brokers 가 성장함에 따라 최고의 성능을 내기 위해서는 주의깊게 튜닝 작업이 필요하다. 여기서 설명한 튜닝 작업은 MCollective 와 연관이 되는 부분들로 제한이 된다. ActiveMQ connectors 를 튜닝하는 대부분의 문서는 network of borkers 의 성능에 관련이 있다.

Labels
  • No labels