기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

RabbitMQ용 Amazon MQ 모범 사례

이 단원을 참조하여 Amazon MQ에서 RabbitMQ 브로커를 이용할 때 성능을 극대화하고 처리량 비용을 최소화할 수 있는 방법을 신속히 찾으세요.

자동 마이너 버전 업그레이드 켜기

최신 브로커 버전 보안 및 버그 수정, 성능 개선 사용. Amazon MQ에 대한 자동 마이너 버전 업그레이드를 활성화하여 최신 패치 버전으로 업그레이드를 관리할 수 있습니다.

더 이상 사용되지 않는 기능 사용

Amazon MQ 에서 RabbitMQ용 버전 3.13을 사용하는 경우 RabbitMQ 관리 UI에 다음과 같은 배너가 표시됩니다. Deprecated features are being used.

이는 Amazon MQ의 RabbitMQ가 RabbitMQ 에서 더 이상 제공되지 않는 다음 기능을 사용하거나 Amazon MQ의 RabbitMQ 에 대해 자동으로 구성되기 때문입니다. Amazon MQ

이 배너는 작업이 필요하지 않은 버전 3.13에 대한 정보 배너입니다. Amazon MQ 브로커는 이러한 기능을 계속 사용합니다.

최상의 처리량을 위해 올바른 브로커 인스턴스 유형을 선택합니다.

브로커 인스턴스 유형의 메시지 처리량은 애플리케이션 사용 사례에 따라 달라집니다. 와 같은 작은 브로커 인스턴스 유형은 애플리케이션 성능을 테스트하는 데만 사용해야 t3.micro 합니다. 프로덕션에서 더 큰 인스턴스를 사용하기 전에 이러한 마이크로 인스턴스를 사용하면 애플리케이션 성능을 개선하고 개발 비용을 절감할 수 있습니다. 인스턴스 유형 m5.large 이상에서는 고가용성 및 메시지 내구성을 위해 클러스터 배포를 사용할 수 있습니다. 더 큰 브로커 인스턴스 유형은 클라이언트 및 대기열의 프로덕션 수준, 높은 처리량, 메모리의 메시지 및 중복 메시지를 처리할 수 있습니다. 올바른 인스턴스 유형을 선택하는 방법에 대한 자세한 내용은 크기 조정 지침을 참조하세요.

여러 채널 사용

연결 이탈을 방지하려면 단일 연결을 통해 여러 채널을 사용합니다. 애플리케이션은 채널에 대한 1:1 연결을 피해야 합니다. 프로세스당 하나의 연결을 사용한 다음 스레드당 하나의 채널을 사용하는 것이 좋습니다. 채널 누출을 방지하기 위해 과도한 채널 사용을 피합니다.

지연 대기열 활성화

대량의 메시지를 처리하는 매우 긴 대기열을 사용하는 경우 지연 대기열을 활성화하면 브로커 성능이 향상될 수 있습니다.

RabbitMQ는 기본적으로 메시지를 메모리에 캐시하며 브로커에 사용 가능한 메모리가 추가로 필요할 때만 메시지를 디스크로 이동합니다. 메모리에서 디스크로 메시지를 이동하려면 시간이 걸리고 메시지 처리가 중지됩니다. 레이지 대기열은 가능한 한 빨리 디스크에 메시지를 저장하여 메모리에서 디스크로 이동하는 속도를 크게 높임으로써 메모리에 캐시되는 메시지가 줄어듭니다.

지연 대기열을 활성화하려면 선언할 때 queue.declare 인수를 설정하거나 RabbitMQ 관리 콘솔을 통해 정책을 구성할 수 있습니다. 다음의 예제에서는 RabbitMQ Java 클라이언트 라이브러리를 사용하여 지연 대기열을 선언하는 방법을 보여줍니다.

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

3.12.13 이상의 모든 Amazon MQ for RabbitMQ 대기열은 기본적으로 지연 대기열로 작동합니다. 최신 버전의 Amazon MQ for RabbitMQ로 업그레이드하려면 섹션을 참조하세요Amazon MQ 브로커 엔진 버전 업그레이드.

영구 메시지 및 내구성 있는 대기열 사용

영구 메시지는 브로커가 중단되거나 다시 시작하는 상황에서 데이터 손실을 방지할 수 있습니다. 영구 메시지는 도착하는 즉시 디스크에 기록됩니다. 그러나 지연 대기열과 달리 영구 메시지는 브로커에 추가 메모리가 필요하지 않는 한 메모리와 디스크 모두에 캐시됩니다. 추가 메모리가 필요한 경우 메시지는 디스크에 대한 메시지 저장을 관리하는 RabbitMQ 브로커 메커니즘(일반적으로 지속성 계층이라고 함)에 의해 메모리에서 제거됩니다.

메시지 지속성을 활성화하려면 대기열을 durable로 선언하고 메시지 전달 모드를 persistent로 설정할 수 있습니다. 다음의 예제에서는 RabbitMQ Java 클라이언트 라이브러리를 사용하여 지속형 대기열을 선언하는 방법을 보여줍니다. AMQP 0-9-1로 작업할 때 전송 모드 “2”를 설정하여 메시지를 영구 메시지로 표시할 수 있습니다.

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

대기열을 지속형으로 구성하면 다음 예제와 같이 MessageProperties를 PERSISTENT_TEXT_PLAIN으로 설정하여 영구 메시지를 대기열에 보낼 수 있습니다.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

대기열을 짧게 유지

클러스터 배포에서 대기열에 메시지 수가 많으면 리소스가 과도하게 사용될 수 있습니다. 브로커가 과도하게 사용되면 RabbitMQ용 Amazon MQ가 재부팅하여 성능이 더욱 저하될 수 있습니다. 재부팅되면 과도하게 사용된 브로커가 REBOOT_IN_PROGRESS 상태에서 응답하지 않게 될 수 있습니다.

유지 관리 기간 중 Amazon MQ는 모든 유지 관리 작업을 한 번에 한 노드에서 수행하여 브로커가 계속 작동하도록 합니다. 따라서 각 노드의 작동이 다시 시작할 때 대기열을 동기화해야 할 수 있습니다. 동기화 중에 미러에 복제해야 하는 메시지는 해당 Amazon Elastic Block Store(Amazon EBS) 볼륨에서 메모리에 로드되어 배치로 처리됩니다. 메시지를 배치로 처리하면 대기열을 더 빠르게 동기화할 수 있습니다.

대기열이 짧게 유지되고 메시지가 작으면 대기열이 성공적으로 동기화되고 예상대로 작업이 재개됩니다. 그러나 배치의 데이터 양이 노드의 메모리 한도에 가까워지면 노드에서 고용량 메모리 경보가 발생하여 대기열 동기화가 일시 중지됩니다. 의 RabbitMemUsed 및 RabbitMqMemLimit브로커 노드 지표를 비교하여 메모리 사용량을 확인할 수 있습니다. CloudWatch 메시지가 사용 또는 삭제되거나 배치의 메시지 수가 줄지 않으면 동기화가 완료될 수 없습니다.

대기열 동기화가 클러스터 배포를 위해 일시 중지된 경우 메시지를 사용하거나 삭제하여 대기열의 메시지 수를 줄이는 것이 좋습니다. 대기열 깊이가 줄고 대기열 동기화가 완료되면 브로커 상태가 RUNNING으로 변경됩니다. 일시 중지된 대기열 동기화를 해결하기 위해 대기열 동기화 배치 크기를 줄이는 정책을 적용할 수도 있습니다.

또한 자동 삭제 및 TTL 정책을 정의하여 리소스 사용량을 사전에 줄이고 소비자NACKs로부터 최소로 유지할 수 있습니다. 브로커의 메시지를 다시 대기열에 추가하는 것은 집CPU약적이므로 의 수가 많으면 브로커 성능에 영향을 미칠 NACKs 수 있습니다.

게시자 확인 및 소비자 전달 확인 구성

브로커에 메시지가 전송되었는지 확인하는 프로세스를 게시자 확인이라고 합니다. 게시자는 메시지가 안정적으로 저장되면 애플리케이션에 알립니다. 게시자는 브로커에 저장된 메시지의 속도를 제어하는 데 도움이 될 수 있음을 확인합니다. 게시자가 확인하지 않으면 messgae가 성공적으로 처리되었다는 확인이 없으며 브로커가 처리할 수 없는 메시지를 삭제할 수 있습니다.

마찬가지로 클라이언트 애플리케이션이 메시지 전송 및 소비 확인을 브로커에 다시 전송하면 소비자 전송 확인이라고 합니다. RabbitMQ 브로커 작업 시 데이터 안전을 보장하려면 확인과 확인이 모두 필수적입니다.

소비자 배달 승인은 일반적으로 클라이언트 애플리케이션에서 구성합니다. AMQP 0-9-1 작업 시 basic.consume 메서드를 구성하여 승인을 활성화할 수 있습니다. AMQP 0-9-1 클라이언트는 confirm.select 메서드를 전송하여 게시자 확인을 구성할 수도 있습니다.

일반적으로 배달 승인은 채널에서 활성화합니다. 예를 들어 RabbitMQ Java 클라이언트 라이브러리를 사용할 때 다음 예제와 같이 Channel#basicAck를 사용하여 간단한 basic.ack 긍정 승인을 설정할 수 있습니다.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

소비자가 배달을 승인하지 않는 시기를 감지consumer_timeout하도록 를 구성할 수 있습니다. 소비자가 제한 시간 값 내에 확인을 보내지 않으면 채널이 닫히고 를 수신합니다PRECONDITION_FAILED. 오류를 진단하려면 UpdateConfigurationAPI를 사용하여 consumer_timeout 값을 높입니다.

미리 가져오기 구성

RabbitMQ 미리 가져오기 값을 사용하여 소비자가 메시지를 소비하는 방식을 최적화할 수 있습니다. RabbitMQ는 채널이 아닌 소비자에게 사전 가져오기 수를 적용하여 AMQP 0-9-1에서 제공하는 채널 사전 가져오기 메커니즘을 구현합니다. 미리 가져오기 값을 사용하여 지정된 시간에 소비자에게 전송되는 메시지 수를 지정합니다. 기본적으로 RabbitMQ는 클라이언트 애플리케이션에 무제한 버퍼 크기를 설정합니다.

RabbitMQ 소비자의 미리 가져오기 수를 설정할 때는 다양한 요소를 고려해야 합니다. 먼저, 소비자의 환경 및 구성을 고려합니다. 소비자는 처리 중인 모든 메시지를 메모리에 유지해야 하므로 미리 가져오기 값이 높으면 소비자의 성능에 부정적인 영향을 줄 수 있으며 경우에 따라 소비자가 모두 함께 중단될 수도 있습니다. 마찬가지로, RabbitMQ 브로커 자체는 보내는 모든 메시지를 소비자 승인을 받을 때까지 메모리에 캐시된 상태로 유지합니다. 미리 가져오기 값이 높으면 소비자의 자동 승인 구성되어 있지 않은 경우 및 소비자가 메시지를 처리하는 데 비교적 오래 걸리는 경우 RabbitMQ 서버의 메모리가 빠르게 부족해질 수 있습니다.

위의 고려 사항에 유의하여 RabbitMQ 브로커나 해당 소비자가 많은 수의 처리되지 않거나 승인되지 않은 메시지로 인해 메모리가 부족해지는 상황을 방지하기 위해 항상 미리 가져오기 값을 설정하는 것이 좋습니다. 대량의 메시지를 처리하도록 브로커를 최적화해야 하는 경우 다양한 미리 가져오기 수로 브로커와 소비자를 테스트하여 소비자가 메시지를 처리하는 데 걸리는 시간에 비해 네트워크 오버헤드가 크게 중요하지 않게 되는 값을 결정할 수 있습니다.

다음 예제에서는 RabbitMQ Java 클라이언트 라이브러리를 사용하여 단일 소비자의 미리 가져오기 값을 10으로 설정하는 방법을 보여줍니다.

ConnectionFactory factory = new ConnectionFactory();

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

channel.basicQos(10, false);

QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);

Celery 구성

Python Celery는 유용한 정보를 찾고 처리하기가 더 어려워질 수 있는 불필요한 메시지를 많이 보냅니다. 노이즈를 줄이고 처리를 더 쉽게 하려면 다음 명령을 입력합니다.

celery -A app_name worker --without-heartbeat --without-gossip --without-mingle

네트워크 실패 자동 복구

RabbitMQ 노드에 대한 클라이언트 연결이 실패할 경우 상당한 가동 중지를 방지하기 위해 자동 네트워크 복구를 항상 활성화하는 것이 좋습니다. RabbitMQ Java 클라이언트 라이브러리는 4.0.0 버전부터 자동 네트워크 복구를 기본적으로 지원합니다.

연결의 I/O 루프에서 처리되지 않은 예외가 발생하거나, 소켓 읽기 작업 시간 초과가 감지되거나, 서버가 하트비트를 놓치는 경우 자동 연결 복구가 트리거됩니다.

클라이언트와 RabbitMQ 노드 간의 초기 연결이 실패하는 경우에는 자동 복구가 트리거되지 않습니다. 연결을 다시 시도하여 초기 연결 실패를 해결하도록 애플리케이션 코드를 작성하는 것이 좋습니다. 다음 예제에서는 RabbitMQ Java 클라이언트 라이브러리를 사용하여 초기 네트워크 실패를 다시 시도하는 방법을 보여 줍니다.

ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings

try {
  Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
  Thread.sleep(5000);
  // apply retry logic
}

RabbitMQ 브로커용 클래식 대기열 v2 활성화

다음과 같은 성능 개선을 위해 브로커 엔진 버전 3.10 및 3.11에서 Classic Queue v2(CQv2)를 활성화하는 것이 좋습니다.

3.12.13 이상의 모든 Amazon MQ for RabbitMQ 대기열CQv2은 기본적으로 사용됩니다. 최신 버전의 Amazon MQ for RabbitMQ로 업그레이드하려면 섹션을 참조하세요Amazon MQ 브로커 엔진 버전 업그레이드.

에서 CQv1로 마이그레이션 CQv2

를 사용하려면 먼저 classic_mirrored_queue_version 기능 플래그를 활성화CQv2해야 합니다. 기능 플래그에 대한 자세한 내용은 기능 플래그를 활성화하는 방법을 참조하세요.

에서 CQv1로 마이그레이션하려면 새 대기열 정책을 생성하거나 queue-version 정책 키 정의가 로 설정된 기존 대기열 정책을 편집해야 CQv2합니다2. 정책 적용에 대한 자세한 내용은 섹션을 참조하세요RabbitMQ용 아마존 MQ에 정책 적용. 대기열 정책 CQv2 활성화에 대한 자세한 내용은 RabbitMQ 설명서의 Classic Queues를 참조하세요.

마이그레이션을 시작하기 전에 다른 최고 성능 모범 사례를 따르는 것이 좋습니다.

대기열 정책을 사용하는 경우 대기열 정책을 삭제하면 CQv2 대기열이 다시 로 다운그레이드됩니다CQv1. RabbitMQ는 CQv2 대기열의 온디스크 표현을 변환CQv1하므로 대기열을 로 다운그레이드하는 것은 권장하지 않습니다. 심도가 높은 대기열의 경우 이 때문에 메모리 사용량이 많고 시간이 오래 걸릴 수 있습니다.