RabbitMQ용 Amazon MQ의 성능 최적화 및 효율성 모범 사례

처리량을 극대화하고 지연 시간을 최소화하며 효율적인 리소스 사용률을 보장하여 RabbitMQ용 Amazon MQ 브로커 성능을 최적화할 수 있습니다. 애플리케이션 성능을 최적화하려면 다음 모범 사례를 완료하세요.

1단계: 메시지 크기를 1MB 미만으로 유지

최적의 성능과 안정성을 위해 메시지를 1MB(메가바이트) 미만으로 유지하는 것이 좋습니다.

RabbitMQ 3.13은 기본적으로 최대 128MB의 메시지 크기를 지원하지만 대용량 메시지는 노드 간에 메시지를 복제하는 동안 게시를 차단하고 잠재적으로 높은 메모리 압력을 생성하는 예측할 수 없는 메모리 경보를 트리거할 수 있습니다. 메시지가 너무 크면 브로커 재시작 및 복구 프로세스에도 영향을 미칠 수 있으며, 이로 인해 서비스 연속성에 대한 위험이 증가하고 성능 저하가 발생할 수 있습니다.

클레임 검사 패턴을 사용하여 대용량 페이로드 저장 및 검색

대용량 메시지를 관리하려면 메시지 페이로드를 외부 스토리지에 저장하고 RabbitMQ를 통해 페이로드 참조 식별자만 전송하여 클레임 검사 패턴을 구현할 수 있습니다. 소비자는 페이로드 참조 식별자를 사용하여 대용량 메시지를 검색하고 처리합니다.

다음 다이어그램은 Amazon MQAmazon S3 MQ를 사용하여 클레임 확인 패턴을 구현하는 방법을 보여줍니다. RabbitMQ

다음 예제에서는 Amazon MQ, AWS Java 2.x용 SDK 및 Amazon S3를 사용하여이 패턴을 보여줍니다.

1. 먼저 Amazon S3 참조 식별자를 포함할 메시지 클래스를 정의합니다.

   class Message {
       // Other data fields of the message...
   
       public String s3Key;
       public String s3Bucket;
   }
   

2. Amazon S3에 페이로드를 저장하고 RabbitMQ를 통해 참조 메시지를 전송하는 게시자 메서드를 생성합니다.

   public void publishPayload() {
       // Store the payload in S3.
       String payload = PAYLOAD;
       String prefix = S3_KEY_PREFIX;
       String s3Key = prefix + "/" + UUID.randomUUID();
       s3Client.putObject(PutObjectRequest.builder()
           .bucket(S3_BUCKET).key(s3Key).build(), 
           RequestBody.fromString(payload));
       
       // Send the reference through RabbitMQ.
       Message message = new Message();
       message.s3Key = s3Key;
       message.s3Bucket = S3_BUCKET;
       // Assign values to other fields in your message instance.
   
       publishMessage(message);
   }
   

3. Amazon S3에서 페이로드를 검색하고, 페이로드를 처리하고, Amazon S3 객체를 삭제하는 소비자 메서드를 구현합니다.

   public void consumeMessage(Message message) {
       // Retrieve the payload from S3.
       String payload = s3Client.getObjectAsBytes(GetObjectRequest.builder()
           .bucket(message.s3Bucket).key(message.s3Key).build())
           .asUtf8String();
       
       // Process the complete message.
       processPayload(message, payload);
       
       // Delete the S3 object.
       s3Client.deleteObject(DeleteObjectRequest.builder()
           .bucket(message.s3Bucket).key(message.s3Key).build());
   }
   

2단계: basic.consume 및 수명이 긴 소비자 사용

수명이 긴 소비자와 basic.consume 함께를 사용하면를 사용하여 개별 메시지를 폴링하는 것보다 더 효율적입니다basic.get. 자세한 내용은 개별 메시지에 대한 폴링을 참조하세요.

3단계: 사전 가져오기 구성

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);

참고

RabbitMQ 자바 클라이언트 라이브러리에서 global 플래그의 기본값은 false로 설정되므로 위의 예제는 간단히 channel.basicQos(10)으로 작성할 수 있습니다.

4단계: 쿼럼 대기열에서 Celery 5.5 이상 사용

분산 작업 대기열 시스템인 Python Celery는 작업 로드가 높을 때 중요하지 않은 메시지를 많이 생성할 수 있습니다. 이 추가 브로커 활동이 트리거 RabbitMQ용 Amazon MQ: 높은 메모리 사용량 경보 되어 브로커를 사용할 수 없게 될 수 있습니다. 메모리 경보를 트리거할 가능성을 줄이려면 다음을 수행합니다.

모든 Celery 버전

1. 대기열 이탈을 완화task_create_missing_queues하려면 끄세요.

2. 그런 다음를 꺼worker_enable_remote_control서 celery@...pidbox 대기열의 동적 생성을 중지합니다. 이렇게 하면 브로커의 대기열 이탈이 줄어듭니다.

   worker_enable_remote_control = false

3. 중요하지 않은 메시지 활동을 더욱 줄이려면 Celery 애플리케이션을 시작할 때를 포함하지 -E 않거나 --task-events 플래그를 지정하여 Celery worker-send-task-events를 끕니다.

4. 다음 파라미터를 사용하여 Celery 애플리케이션을 시작합니다.

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

Celery 버전 5.5 이상의 경우

1. Celery 버전 5.5, 쿼럼 대기열을 지원하는 최소 버전 또는 이후 버전으로 업그레이드합니다. 사용 중인 Celery 버전을 확인하려면를 사용합니다celery --version. 쿼럼 대기열에 대한 자세한 내용은 섹션을 참조하세요Amazon MQ 기반 RabbitMQ의 쿼럼 대기열.

2. Celery 5.5 이상으로 업그레이드한 후를 "쿼럼"task_default_queue_type으로 구성합니다.

3. 그런 다음 브로커 전송 옵션에서 게시 확인도 켜야 합니다.

   broker_transport_options = {"confirm_publish": True}