Amazon MQ에 연결

다음 설계 패턴은 Amazon MQ 브로커에 대한 애플리케이션의 연결 효과를 개선할 수 있습니다.

Amazon MQ 탄력적 네트워크 인터페이스를 수정하거나 삭제하지 않음

처음으로 Amazon MQ 브로커 생성할 때 Amazon MQ는 Virtual Private Cloud(VPC)에서 사용자 계정 아래에 탄력적 네트워크 인터페이스를 프로비저닝하므로 많은 EC2 권한이 필요합니다. 네트워크 인터페이스를 통해 클라이언트(생산자 또는 소비자)가 Amazon MQ 브로커와 통신할 수 있습니다. 네트워크 인터페이스는 사용자 계정의 VPC에 속해 있음에도 불구하고 Amazon MQ의 서비스 범위 내에 있는 것으로 간주됩니다.

주의

이 네트워크 인터페이스는 수정하거나 삭제하면 안 됩니다. 네트워크 인터페이스를 수정하거나 삭제하면 VPC와 브로커 간의 연결이 영구적으로 손실될 수 있습니다.

항상 연결 풀 사용

단일 생산자와 단일 소비자가 있는 시나리오(예: Getting Started with Amazon MQ 자습서)에서는 모든 생산자와 소비자에 대해 단일 ActiveMQConnectionFactory 클래스를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);

// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);

// Establish a connection for the consumer.
final Connection consumerConnection = connectionFactory.createConnection();
consumerConnection.start();

하지만 생산자와 소비자가가 여러 개인 현실적인 시나리오에서는 여러 생산자에 대해 많은 수의 연결을 생성하려면 비용이 많이 들고 비효율적일 수 있습니다. 이러한 시나리오에서는 PooledConnectionFactory 클래스를 사용하여 여러 개의 생산자 요청을 그룹화해야 합니다. 예를 들면 다음과 같습니다.

참고

메시지 소비자는 PooledConnectionFactory 클래스를 사용하면 안 됩니다.

// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);

// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);

// Create a pooled connection factory.
final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory();
pooledConnectionFactory.setConnectionFactory(connectionFactory);
pooledConnectionFactory.setMaxConnections(10);

// Establish a connection for the producer.
final Connection producerConnection = pooledConnectionFactory.createConnection();
producerConnection.start();

항상 Failover Transport를 사용하여 여러 브로커 엔드포인트에 연결

애플리케이션이 여러 브로커 엔드포인트에 연결해야 하는 경우(예: 활성/대기 배포 모드를 사용하는 경우나 온프레미스 메시지 브로커에서 Amazon MQ로 마이그레이션하는 경우 장애 조치 전송을 사용하여 소비자가 둘 중 하나에 임의로 연결하도록 허용할 수 있습니다. 예를 들면 다음과 같습니다.

failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-east-2.amazonaws.com:61617)?randomize=true

메시지 선택기 사용하지 않기

JMS 선택기를 사용하여 필터를 주제 구독에 연결할 수 있습니다(그러면 콘텐츠를 기반으로 메시지를 소비자에게 라우팅할 수 있음). 하지만 JMS 선택기를 사용하면 Amazon MQ 브로커의 필터 버퍼가 가득 차서 메시지를 필터링할 수 없습니다.

일반적으로 소비자가 메시지를 라우팅하도록 두지 마세요. 소비자와 생산자를 최적으로 결합 해제하려면 소비자와 생산자가 모두 한시적이어야 하기 때문입니다.

지속 구독보다 가상 대상을 선호

지속 구독은 주제에 게시된 모든 메시지를 소비자가 수신하도록 보장할 수 있습니다. 예를 들어 끊어진 연결이 복원된 후 메시지를 모두 수신할 수 있습니다. 하지만 지속 구독을 사용하면 상충되는 소비자의 사용을 제외하고 대규모의 성능 문제가 발생할 수 있습니다. 그 대신 가상 대상 사용을 고려하세요.

Amazon VPC 피어링을 사용하는 경우 CIDR 범위 10.0.0.0/16의 클라이언트 IP 사용 안 함

온프레미스 인프라와 Amazon MQ 브로커 간에 Amazon VPC 피어링을 설정하는 경우 CIDR 범위 10.0.0.0/16의 IP와 클라이언트 연결을 구성해서는 안 됩니다.