기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 문제 해결: 일반 Amazon MQ 이 단원의 정보를 사용하여 Amazon MQ 브로커를 사용할 때 발생할 수 있는 브로커 연결 문제, 브로커 재부팅 등과 같은 일반적인 문제를 진단할 수 있습니다. **Contents** + [브로커 웹 콘솔 또는 엔드포인트에 연결할 수 없습니다.](#issues-connecting-to-console-or-endpoint) + [브로커가 실행 중이고 `telnet`을 사용하여 연결을 확인할 수 있지만, 클라이언트 측에서는 연결할 수 없고 SSL 예외를 반환하고 있습니다.](#issues-ssl-certificate-exception) + [브로커를 생성했지만 브로커 생성에 실패했습니다.](#issues-creating-a-broker) + [브로커가 다시 시작되었는데 이유를 잘 모르겠습니다.](#w2aac40b9c13) ## 브로커 웹 콘솔 또는 엔드포인트에 연결할 수 없습니다. 웹 콘솔 또는 와이어 레벨 엔드포인터를 사용하여 브로커에 연결할 대 문제가 발생하는 경우 다음 단계를 수행하는 것이 좋습니다. 1. 방화벽 뒤에 있는 브로커에 연결하려고 하는지 확인합니다. 브로커에 대한 액세스를 허용하도록 방화벽을 구성해야 할 수도 있습니다. 1. 원하는 작업이 [FIPS](https://aws.amazon.com/compliance/fips/) 엔드포인트를 사용하여 브로커에 연결하는 것이 맞는지 확인합니다. Amazon MQ는 API 작업을 사용할 때 FIPS 엔드포인트만 지원하며, 브로커 인스턴스 자체에 대한 와이어 수준 연결에 대해서는 지원하지 않습니다. 1. 브로커의 **Public Accessibility(퍼블릭 액세스 가능성)** 옵션이 **Yes(예)**로 설정되어 있는지 확인합니다. 해당 옵션이 **No(아니요)**로 설정된 경우 서브넷의 네트워크 [액세스 제어 목록(ACL)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 규칙을 확인합니다. 사용자 지정 네트워크 ACL을 생성한 경우 브로커에 대한 액세스를 제공하기 위해 네트워크 ACL 규칙을 변경해야 할 수도 있습니다. Amazon VPC 네트워킹에 대한 자세한 내용은 *Amazon VPC 사용 설명서*에서 [인터넷 액세스 활성화](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)를 참조하세요. 1. 브로커의 보안 그룹 규칙을 확인합니다. 다음 포트에 대한 연결을 허용하고 있는지 확인합니다. **참고** Amazon MQ용 ActiveMQ와 Amazon MQ용 RabbitMQ에서 연결에 서로 다른 포트를 사용하므로 다음 포트는 엔진 유형에 따라 분류됩니다. **Amazon MQ용 ActiveMQ** + 웹 콘솔 - 포트 `8162` + OpenWire - 포트 `61617` + AMQP - 포트 `5671` + STOMP - 포트 `61614` + MQTT - 포트 `8883` + WSS - 포트 `61619` **Amazon MQ용 RabbitMQ** + 웹 콘솔 및 관리 API - 포트 ` 443` 및 `15671` + AMQP - 포트 `5671` 1. 브로커 엔진 유형에 대해 다음 네트워크 연결 테스트를 실행합니다. **참고** 퍼블릭 액세스 가능성이 없는 브로커의 경우 Amazon MQ 브로커와 동일한 Amazon VPC 내의 Amazon EC2 인스턴스에서 테스트를 실행하고 응답을 평가합니다. ------ #### [ ActiveMQ on Amazon MQ ] **Amazon MQ용 ActiveMQ 브로커의 네트워크 연결을 테스트하려면** 1. 새 터미널 또는 명령줄 창을 엽니다. 1. 다음 `nslookup` 명령을 실행하여 브로커 DNS 레코드를 쿼리합니다. [활성/대기](amazon-mq-broker-architecture.md#active-standby-broker-deployment) 배포의 경우 활성 및 대기 엔드포인트를 모두 테스트합니다. 활성/대기 엔드포인트는 고유한 브로커 ID에 추가된 접미사 `-1` 또는 `-2`로 식별됩니다. 엔드포인트를 사용자 정보로 대체합니다. ``` $ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com ``` 쿼리가 성공하면 다음과 비슷한 출력이 표시됩니다. ``` Non-authoritative answer: Server: dns-resolver-corp-sfo-1.sfo.corp.amazon.com Address: 172.10.123.456 Name: ec2-12-345-123-45.us-west-2.compute.amazonaws.com Address: 12.345.123.45 Aliases: b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com ``` 확인된 IP 주소는 Amazon MQ 콘솔에 제공된 IP 주소와 일치해야 합니다. 이는 DNS 서버에서 도메인 이름이 올바르게 확인되고 다음 단계로 이동할 수 있음을 나타냅니다. 1. 다음 `telnet` 명령을 실행하여 브로커의 네트워크 경로를 테스트합니다. 엔드포인트를 사용자 정보로 대체합니다. *port*를 웹 콘솔의 경우 포트 번호 `8162`로 대체하거나 필요한 경우 추가 포로토콜을 테스트하려면 다른 와이어 레벨 포트로 대체합니다. **참고** 활성/대기 배포의 경우 `telnet`을 대기 엔드포인트로 실행하면 `Connect failed` 오류 메시지를 받습니다. 대기 인스턴스 자체가 실행 중이므로 이는 정상적인 현상이지만 ActiveMQ 프로세스가 실행 중이 아니고 브로커의 Amazon EFS 스토리지 볼륨에 액세스할 수 없습니다. 두 `-1` 및 `-2` 엔드포인트 모두에 대해 명령을 실행하여 활성 및 대기 인스턴스를 모두 테스트해야 합니다. ``` $ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port ``` 활성 인스턴스의 경우 다음과 비슷한 출력이 표시됩니다. ``` Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com. Escape character is '^]'. ``` 1. 다음 중 하나를 수행하세요. + `telnet` 명령이 성공하면 [`EstablishedConnectionsCount`](activemq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics) 지표를 확인하고 브로커가 최대 [와이어 레벨 연결 한도](amazon-mq-limits.md)에 도달하지 않았는지 확인합니다. 브로커 `General` 로그를 검토하여 한도에 도달했는지 확인할 수도 있습니다. 이 지표가 0보다 크면 현재 하나 이상의 클라이언트가 브로커에 연결되어 있는 것입니다. 지표에 연결이 0으로 표시되는 경우 브로커 지표가 매분 게시되므로 `telnet` 경로 테스트를 다시 실행하고 연결을 끊기 전 1분 이상 기다립니다. + `telnet` 명령이 실패하면 브로커의 [탄력적 네트워크 인터페이스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) 상태를 확인하고 상태가 `in-use`인지 확인합니다. 각 인스턴스의 네트워크 인터페이스에 대해 [Amazon VPC 흐름 로그를 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)하고 생성된 흐름 로그를 검토합니다. `telnet` 명령을 실행할 때 브로커의 IP 주소를 찾고 반환 패킷을 포함하여 연결 패킷이 `ACCEPTED`인지 확인합니다. 자세한 내용 및 흐름 로그 예제를 확인하려면 *Amazon VPC 개발자 안내서*의 [흐름 로그 레코드 예](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)를 참조하세요. 1. 다음 `curl` 명령을 실행하여 ActiveMQ 관리 웹 콘솔에 대한 연결을 확인합니다. ``` $ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:8162/index.html ``` 명령이 성공하면 출력은 다음과 비슷한 HTML 문서여야 합니다. ``` Apache ActiveMQ ... ``` ------ #### [ RabbitMQ on Amazon MQ ] **Amazon MQ용 RabbitMQ 브로커의 네트워크 연결을 테스트하려면** 1. 새 터미널 또는 명령줄 창을 엽니다. 1. 다음 `nslookup` 명령을 실행하여 브로커 DNS 레코드를 쿼리합니다. 엔드포인트를 사용자 정보로 대체합니다. ``` $ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com ``` 쿼리가 성공하면 다음과 비슷한 출력이 표시됩니다. ``` Non-authoritative answer: Server: dns-resolver-corp-sfo-1.sfo.corp.amazon.com Address: 172.10.123.456 Name: rabbit-broker-1c23e456ca78-b9000123b4ebbab5.elb.us-west-2.amazonaws.com Addresses: 52.12.345.678 52.23.234.56 41.234.567.890 54.123.45.678 Aliases: b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com ``` 1. 다음 `telnet` 명령을 실행하여 브로커의 네트워크 경로를 테스트합니다. 엔드포인트를 사용자 정보로 대체합니다. *port*를 웹 콘솔의 경우 포트 `443`으로 대체하거나 와이어 레벨 AMQP 연결을 테스트하려는 경우 `5671`로 대체할 수 있습니다. ``` $ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port ``` 명령이 성공하면 다음과 비슷한 출력이 표시됩니다. ``` Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com. Escape character is '^]'. ``` **참고** telnet 연결은 몇 초 후 자동으로 닫힙니다. 1. 다음 중 하나를 수행하세요. + `telnet` 명령이 성공하면 [`ConnectionCount`](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics-rabbitmq) 지표를 확인하고 브로커가 [`max-connections`](rabbitmq-resource-limits-configuration.md) 기본 정책에 설정된 값에 도달하지 않았음을 확인합니다. 브로커 `Connection.log` 로그 그룹을 검토하여 한도에 도달했는지 확인할 수도 있습니다. 이 지표가 0보다 크면 현재 하나 이상의 클라이언트가 브로커에 연결되어 있는 것입니다. 지표에 연결이 0으로 표시되는 경우 `telnet` 경로 테스트를 다시 실행합니다. 브로커가 CloudWatch에 새 연결 지표를 게시하기 전에 연결이 종료되는 경우 이 프로세스를 반복해야 할 수 있습니다. 지표는 매분 게시됩니다. + 퍼블릭 액세스 가능성이 없는 브로커의 경우 `telnet` 명령이 실패하면 브로커의 [탄력적 네트워크 인터페이스](https://docs.aws.amazon.com/UserGuide/using-eni.html?icmpid=docs_ec2_console) 상태를 확인하고 상태가 `in-use`인지 확인합니다. 각 네트워크 인터페이스에 대해 [Amazon VPC 흐름 로그를 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)하고 생성된 흐름 로그를 검토합니다. `telnet` 명령을 호출할 때 브로커의 IP 주소를 찾고 반환 패킷을 포함하여 연결 패킷이 `ACCEPTED`인지 확인합니다. 자세한 내용 및 흐름 로그 예제를 확인하려면 *Amazon VPC 개발자 안내서*의 [흐름 로그 레코드 예](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)를 참조하세요. **참고** 퍼블릭 액세스 가능성이 있는 Amazon MQ용 RabbitMQ 브로커에는 이 단계가 적용되지 않습니다. 1. 다음 `curl` 명령을 실행하여 RabbitMQ 관리 웹 콘솔에 대한 연결을 확인합니다. ``` $ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:443/index.html ``` 명령이 성공하면 출력은 다음과 비슷한 HTML 문서여야 합니다. ``` RabbitMQ Management ... ``` ------ ## 브로커가 실행 중이고 `telnet`을 사용하여 연결을 확인할 수 있지만, 클라이언트 측에서는 연결할 수 없고 SSL 예외를 반환하고 있습니다. 브로커 [유지 관리 기간](maintaining-brokers.md) 중에 브로커 엔드포인트 인증서가 업데이트되었을 수 있습니다. Amazon MQ 브로커 인증서는 브로커의 지속적인 가용성과 보안을 유지하기 위해 주기적으로 교체됩니다. 클라이언트의 트러스트 스토어에 대해 인증하기 위해 [Amazon Trust Services](https://www.amazontrust.com/repository/)에서 Amazon 루트 인증 기관(CA)을 이용하는 것이 좋습니다. 모든 Amazon MQ 브로커 인증서는 이 루트 CA로 서명됩니다. Amazon 루트 CA를 사용하면 브로커에 인증서 업데이트가 있을 때마다 새 Amazon MQ 브로커 인증서를 더 이상 다운로드할 필요가 없습니다. ## 브로커를 생성했지만 브로커 생성에 실패했습니다. 브로커가 `CREATION_FAILED` 상태인 경우 다음을 수행합니다. + IAM 권한을 확인합니다. 브로커를 생성하려면 AWS 관리형 IAM 정책을 사용하거나 사용자 지정 IAM 정책에 `AmazonMQFullAccess` 올바른 Amazon EC2 권한 집합이 있어야 합니다. 필요한 Amazon EC2 권한에 대한 자세한 내용은 [Amazon MQ 브로커를 생성하는 데 필요한 IAM 권한](security-api-authentication-authorization.md#security-permissions-required-to-create-broker)을 참조하세요. + 브로커에 대해 선택하는 서브넷이 공유 Amazon Virtual Private Cloud(VPC)에 있는지 확인합니다. 공유 Amazon VPC에서 Amazon MQ 브로커를 생성하려면 Amazon VPC를 소유하는 계정에서 생성해야 합니다. ## 브로커가 다시 시작되었는데 이유를 잘 모르겠습니다. 브로커가 자동으로 다시 시작한 경우 다음 이유 중 하나 때문일 수 있습니다. + 예약한 주별 유지 관리 기간 때문에 브로커가 다시 시작되었을 수 있습니다. 주기적으로 Amazon MQ는 메시지 브로커의 하드웨어, 운영 체제 또는 엔진 소프트웨어에 대한 유지 관리를 수행합니다. 유지 관리 기간은 다양하지만 메시지 브로커에 대해 예약된 작업에 따라 최대 2시간까지 지속될 수 있습니다. 브로커는 2시간의 유지 관리 기간 중 언제든 다시 시작될 수 있습니다. 브로커 유지 관리 기간에 대한 자세한 내용은 [Amazon MQ 브로커의 유지 관리 기간 예약](maintaining-brokers.md) 섹션을 참조하세요. + 브로커 인스턴스 유형이 애플리케이션 워크로드에 적합하지 않을 수 있습니다. 예를 들어, `mq.t3.micro`에서 프로덕션 워크로드를 실행하면 브로커 리소스가 부족해질 수 있습니다. CPU 사용률이 높거나 브로커 메모리 사용량이 높으면 브로커가 예기치 않게 다시 시작될 수 있습니다. 브로커에서 사용 중인 CPU 및 메모리 양을 확인하려면 엔진 유형에 대한 다음 CloudWatch 지표를 사용합니다. + **Amazon MQ용 ActiveMQ** - 할당된 Amazon EC2 컴퓨팅 유닛(ECU) 중 브로커가 현재 사용하는 비율은 `CpuUtilization`을 확인합니다. ActiveMQ JVM 메모리 한도 중 브로커가 현재 사용하는 비율은 `HeapUsage`를 확인합니다. + **Amazon MQ용 RabbitMQ** - 할당된 Amazon EC2 컴퓨팅 유닛(ECU) 중 브로커가 현재 사용하는 비율은 `SystemCpuUtilization`을 확인합니다. 사용된 RAM 볼륨(바이트)은 `RabbitMQMemUsed`을 확인하고 RabbitMQ 노드에서 사용하는 메모리 비율은 해당 값을 `RabbitMQMemLimit`로 나눕니다. 브로커 인스턴스 유형 및 워크로드에 적합한 인스턴스 유형을 선택하는 방법에 대한 자세한 내용은 [Broker instance types](broker-instance-types.md) 섹션을 참조하세요.