가장 연결 가능한브로커

1. 워크플로를 시작하려면 먼저 전환이 실행되는 날짜와 시간을 스케줄링해야 합니다. 이 스케줄링 작업에 따라 전환 중에 Universal Broker 서비스를 설정하는 데 사용할 구성 옵션을 정의합니다.
2. 스케줄링한 시작 시간이 되기 적어도 15분 전에 콘솔에서 진행 중인 모든 작업을 완료하고 유지하려는 변경 내용을 저장합니다. 모든 구성 마법사 및 대화상자를 닫습니다. 또한 Microsoft Azure의 모든 포드가 온라인 상태이고 정상적인 준비 완료 상태인지 확인합니다.
3. 전환이 시작될 때 콘솔에서 로그아웃했다가 다시 로그인하라는 메시지가 표시됩니다.
4. 전환의 첫 번째 단계에서는 다음을 예상할 수 있습니다.
   • 콘솔의 편집 컨트롤에 액세스할 수 없으며 콘솔에 전환 중이라는 배너가 표시됩니다.
   • Microsoft 가장 연결 가능한브로커 Azure의 모든 포드는 이름이 Default-Site 인 사이트에 추가됩니다.
   • VDI 데스크톱 할당은 Universal Broker 에 의해 브로커링된 다중 클라우드 할당으로 변환됩니다. 기본 할당 설정에서 연결 선호도는 가장 가까운 사이트 로 설정되고, 범위는 사이트 내 로 설정됩니다.
   • 세션 기반 데스크톱 및 애플리케이션 할당은 변경되지 않은 상태로 유지됩니다. 전환 가장 연결 가능한브가장 연결 가능한브로커 로커 후 이러한 할당의 리소스가 Universal Broker 에 의해 브로커링됩니다.
   • 모든 할당은 최종 사용자가 사용할 수 있는 상태로 유지되고 이 시간 동안 모든 활성 사용자 세션은 계속 열려 있으며 완전히 작동합니다.

사용자 개인정보 보호 및 데이터 사용

App Store는 사용자가 전 세계의 재능 있는 개발자들이 만든 앱을 발견할 수 있는 안전하고 신뢰할 수 있는 공간으로 설계되었습니다. 사용자의 신뢰를 유지하는 것이 가장 중요하므로 App Store의 앱에는 개인정보 보호, 보안 및 콘텐츠에 대한 높은 기준이 적용됩니다. 새로운 앱 및 앱 업데이트를 제출하려면 제품 페이지에서 일부 앱의 데이터 수집 방식에 대한 정보를 제공해야 합니다. iOS 14.5, iPadOS 14.5 및 tvOS 14.5 이후 버전에서는 타사 소유의 앱과 웹 사이트 전반에서 사용자를 추적하려면 앱에서 사용자에게 허가를 받아야 합니다.

앱에서 데이터를 사용하는 방법 설명하기

App Store는 사용자가 앱을 다운로드하기 전에 앱의 개인정보 처리 방침을 확인할 수 있도록 지원합니다. 사용자는 각 앱의 제품 페이지에서 앱이 수집할 수 있는 일부 데이터 유형과 해당 정보가 사용자 추적에 사용되는지 또는 사용자 신원 또는 기기에 연결되는지 여부를 확인할 수 있습니다.

새로운 앱 및 앱 업데이트를 제출하려면 App Store Connect에 개인정보 처리 방침에 관한 정보를 제공해야 합니다. 타사 코드(예: 광고 또는 분석 SDK)를 사용하는 경우 타사 코드에서 수집하는 데이터, 해당 데이터의 사용 방법 및 해당 데이터를 사용하여 사용자를 추적하는지 여부를 설명해야 합니다.

추적 권한 요청하기

iOS 14.5, iPadOS 14.5, tvOS 14.5 이후 버전에서는 사용자를 추적하거나 사용자 기기의 광고 식별자에 접근하려면 AppTrackingTransparency 프레임워크를 통해 사용자의 허가를 받아야 합니다. 추적이란 맞춤형 광고 또는 광고 측정 목적으로 앱에서 수집된 사용자 또는 기기 데이터와 다른 회사의 앱, 웹 사이트 또는 오프라인 속성에서 수집된 사용자 또는 기기 데이터를 연결하는 행위를 말합니다. 또한 추적은 사용자 또는 기기 데이터를 데이터 브로커와 공유하는 것을 의미하기도 합니다.

추적의 예로 다음이 포함되며, 이에 국한되지 않습니다.

• 타사 소유의 앱 및 웹 사이트에서 수집한 사용자 데이터에 기반하여 앱에 맞춤형 광고를 표시하는 경우.
• 데이터 브로커와 기기 위치 데이터 또는 이메일 목록을 공유하는 경우.
• 이메일, 광고 ID 또는 기타 ID 목록을 타사 광고 네트워크와 공유하고 해당 정보를 다른 개발자의 앱에서 해당 사용자를 다시 대상으로 삼거나 유사 사용자를 찾는 데 사용하는 경우.
• 이러한 목적으로 SDK를 사용하지 않더라도, 광고를 맞춤화하거나 광고 효율성을 측정하기 위해 앱의 사용자 데이터와 다른 개발자의 앱 사용자 데이터를 결합하는 타사 SDK를 앱에 배치하는 경우 (예: 앱에서 수집하는 데이터의 용도를 변경하는 분석 SDK를 사용하여 다른 개발자의 앱에서 맞춤형 광고 실행).

다음 활용 사례는 추적으로 간주하지 않으며 AppTrackingTransparency 프레임워크를 통해 사용자의 허가를 받지 않아도 됩니다.

• 앱의 사용자 또는 기기 데이터가 사용자 기기에서만 타사 데이터와 연결되어 있고, 기기에서 사용자 또는 기기를 식별할 수 있는 방식으로 전송되지 않는 경우.
• 개발자가 데이터를 공유한 데이터 브로커가 사기 행위 탐지, 사기 방지 또는 보안 목적으로만 데이터를 사용하는 경우. (예: 데이터 브로커를 신용 카드 사기 방지 목적으로만 사용).
• 데이터 브로커가 개인신용평가기관이며 (1) 소비자의 신용도에 대해 보고하거나 (2) 소비자의 신용을 판단하기 위한 특별한 목적을 위해 신용도에 관한 정보를 획득하려는 목적으로 데이터를 공유하는 경우.

AppTrackingTransparency 프레임워크 사용하기

사용자를 추적하고 기기의 광고 식별자에 접근할 수 있는 권한을 요청하려면 가장 연결 가능한브로커 AppTrackingTransparency 프레임워크를 사용하십시오. 또한 사용자 추적 사유를 설명하는 목적 문자열을 시스템 메시지에 포함해야 합니다. 사용자로부터 추적을 사용하도록 허가를 받지 않는 한, 기기의 광고 식별자 값은 모두 0이며 위에서 설명한 대로 사용자를 추적할 수 없습니다.

AppTrackingTransparency 메시지를 선택할 때마다 표시할 수 있지만 기기의 광고 식별자 값은 메시지가 표시되고 사용자가 허가한 경우에만 반환됩니다. 사용자가 공유하겠다고 선택한 항목이 무엇인지 이해할 수 있도록 목적 문자열을 사용하여 해당 데이터가 어떻게 사용되는지 설명하도록 합니다. 사용자가 앱의 추적 요청을 허용했지만 앱에 대한 추적을 끈 경우에는 추적 허가를 변경할 수 있도록 설정으로 가는 단축키 를 제공하여 사용자에게 앱에 대한 환경설정을 변경하도록 요청할 수 있습니다.

공급업체 ID(IDFV) 가 동일한 콘텐츠 공급자의 앱 전체를 분석하는 데 사용될 수 있습니다. 사용자로부터 추적을 허가받지 않는 한, 다른 데이터와 IDFV를 결합하여 타사 소유의 앱 및 웹 사이트에서 사용자를 추적할 수 없습니다.

자세한 내용은 다음을 참고하시기 바랍니다.

자주 묻는 질문

추적 허용에 동의하는 기능을 제어하거나 App Tracking Transparency 요청을 통해 사용자가 추적 허용에 동의하도록 권장할 수 있습니까?

사용자에게 추적 허가 요청을 표시하기 전에 추적 허가를 요청하는 이유에 관해 설명할 수 있습니까?

예, 사용자에게 데이터 사용에 관해 투명하게 밝히는 경우 가능합니다. App Store 심사 지침: 5.1.1(iv)항에 따라 앱에서 사용자의 권한 설정을 가장 연결 가능한브로커 가장 연결 가능한브로커 반영해야 하며, 불필요한 데이터 접근에 대한 동의를 부당한 방법으로 유도하거나 조작 또는 강요해서는 안 됩니다.

추적 허가 요청을 통해 사용자로부터 허가를 받지 못한 경우, IDFA 이외의 식별자(예: 해시 처리된 이메일 주소 또는 해시 처리된 전화번호)를 사용하여 해당 사용자를 추적할 수 있습니까?

아니요. 사용자를 추적하려면 AppTrackingTransparency 프레임워크를 통해 사용자의 허가를 받아야 합니다.

사용자가 웹 사이트에서 별도의 절차를 통해 추적을 허가했으나 App Tracking Transparency 요청에는 허가를 거부하는 경우, 타사 소유의 앱 및 웹 사이트에서 해당 사용자를 추적할 수 있습니까?

개발자는 App Tracking Transparency 요청을 통해 앱에서 수집하고 추적에 사용하는 데이터에 대해 허가를 받아야 합니다. 이때 앱 외부에서 별도로 수집하고 해당 앱과 관련이 없는 데이터는 해당되지 않습니다.

기기 또는 사용자를 식별하는 데 지문 또는 기기의 신호를 사용할 수 있습니까?

아니요. Apple Developer Program 사용권 계약에 따라, 기기에서 해당 기기를 고유하게 식별할 목적으로 데이터를 추출할 수 없습니다. 사용자 또는 기기 데이터의 예로는 사용자의 웹 브라우저 속성 및 해당 구성, 사용자의 기기 및 구성, 사용자의 위치, 사용자의 네트워크 연결이 포함되나 이에 국한되지 않습니다. 이러한 방식을 시행하는 것으로 확인된 앱이나 SDK(광고 네트워크, 어트리뷰션 서비스, 분석이 포함되나 이에 국한되지 않음)를 참조하는 앱은 App Store에서 거부될 수 있습니다.

개인신용평가기관과 데이터를 공유하여 부정행위를 확인하고, 신용 조회의 일환이나 신용평가를 목적으로 개인신용평가기관과 개별적으로 데이터를 공유하는 경우 추적 권한을 요청해야 합니까?

아니요. 데이터 브로커가 공유받은 데이터를 부정행위 탐지, 사기 방지 또는 보안 목적으로만 사용하는 경우 사용자로부터 허가를 받지 않아도 됩니다. 또한 개인신용평가기관과 데이터를 공유하며 (1) 소비자의 신용도에 대해 보고하거나 (2) 소비자의 신용을 판단하기 위한 특별한 목적을 위해 신용도에 관한 정보를 획득하려는 목적으로 데이터를 공유하는 경우 사용자로부터 허가를 받지 않아도 됩니다.

타사 딥 링크 또는 디퍼드 딥 링크 도구를 사용하려면 AppTrackingTransparency 프레임워크를 사용하여 사용자로부터 허가를 받아야 합니까?

예. 응용 프로그램에서 광고 타겟팅, 광고 측정 또는 데이터 브로커와의 공유를 위해 고유 식별자를 전달하거나 서로 다른 회사의 응용 프로그램 간에 사용자의 공유 ID를 생성하는 타사 서비스를 사용하는 경우 앱에서 AppTrackingTransparency 프레임워크를 사용하여 사용자로부터 허가를 받아야 합니다.

다른 회사의 SDK를 통합했습니다. 해당 회사에서 내 앱 사용자를 추적하고 데이터를 수집하는 것에 대한 책임이 내게 있습니까?

예. 개발자는 자신의 앱에 포함된 모든 코드에 대한 책임이 있습니다. 직접 작성하지는 않았지만 자신의 앱에 사용된 코드의 데이터 수집 또는 추적 방식에 대해 잘 모르는 경우 해당 SDK 개발자에게 문의하는 것이 좋습니다.

다른 회사에서 제공하는 단일 로그인 기능을 통합했습니다. 해당 회사의 데이터 수집 및 추적 방식에 대한 책임이 내게 있습니까?

예. 개발자는 자신의 앱에 포함된 모든 코드에 대해 책임이 있으며, 여기에는 타사에서 제공한 단일 로그인(SSO)도 포함됩니다. 앱에 포함된 SSO 기능으로 인해 사용자가 추적 대상이 될 경우, App Tracking Transparency 요청을 사용하여 먼저 사용자의 허가를 받아야 합니다.

데이터 브로커는 어떤 회사를 의미합니까?

일부 관할 지역에서는 데이터 브로커를 법으로 규정합니다. 일반적으로 데이터 브로커는 자사와 직접적인 관계가 없는 특정 최종 사용자의 데이터를 정기적으로 수집, 판매, 허가하거나 제3자에게 개인 정보를 공개하는 회사입니다.

'추적' 정책이 적용되는 식별자 또는 데이터는 무엇입니까?

광고, 광고 측정 또는 데이터 브로커와의 공유를 목적으로 앱의 데이터를 타사 데이터(앱에서 사용하는 SDK 포함)와 결합하는 데 사용하는 사용자 또는 기기 수준 식별자에 가장 연결 가능한브로커 적용됩니다. 여기에는 기기의 광고 식별자, 세션 ID, 지문 ID, 기기 그래프 식별자가 포함되나 이에 국한되지 않습니다. 위에 나열된 목적을 위해 앱에서 이러한 식별자를 수신하거나 공유하는 경우 AppTrackingTransparency 프레임워크를 사용하여 사용자 동의를 얻어야 합니다.

앱의 WebView 내에서 추적이 발생하는 경우 AppTrackingTransparency 메시지를 사용해야 합니까?

예. 앱 기능을 위해 WebView를 사용하는 경우 사용자가 오픈 웹을 탐색할 수 있도록 설정하지 않는 한 앱의 기본 기능과 동일한 방식으로 처리해야 합니다.

IDFA 값을 이용하기 위해 AppTrackingTransparency 허가를 받아야 하는 OS 버전은 무엇입니까?

iOS/iPadOS 14.5 이후 버전을 사용하는 사용자의 IDFA 값을 이용하려면 먼저 AppTrackingTransparency 메시지를 통해 사용자로부터 허가를 받아야 합니다. 추적에 대한 더 자세한 지침은 App Store 심사 지침: 5.1.1 (iv)항을 참고하십시오.

ePrivacy 또는 GDPR과 같은 규정을 준수하기 위해 다른 권한을 추가로 요청할 수 있습니까?

예, 정부 규정을 준수하기 위해 화면을 포함하도록 선택할 수 있습니다. 그러나 AppTrackingTransparency 메시지에 대한 사용자의 응답과 다른 메시지에 대한 응답이 상충하더라도 항상 AppTrackingTransparency 메시지에 대한 사용자의 응답을 존중해야 합니다. 지침 5.1.1 (iv)항 에는 "앱은 사용자의 권한 설정을 반영해야 하며, 불필요한 데이터 접근에 대한 동의를 부당한 방법으로 유도하거나 조작 또는 강요해서는 안 됩니다."라고 나와 있습니다. 여기에는 다른 권한 요청에 대한 사용자의 응답만을 존중하여 AppTrackingTransparency에 대한 응답을 변조하는 것이 포함됩니다. 권한 요청 추가를 위해 추적을 하지 않는 한 타사 동의 관리 플랫폼을 사용하여 이러한 권한 요청을 추가할 수 있습니다.

앱 설치 기여도 부여하기

광고주는 개인의 정보를 보호하며 산업을 선도하는 Apple의 기술인 SKAdNetwork 및 비공개 클릭 측정을 사용하여 사용자의 개인 정보를 보호하면서 앱 내 광고 캠페인 및 모바일의 웹 광고를 어트리뷰션할 수 있습니다.

브로커 기본값

RabbitMQ용 Amazon MQ 브로커를 생성할 때 Amazon MQ는 브로커 성능을 최적화하기 위해 기본 집합의 브로커 정책 및 vhost 제한을 적용합니다. Amazon MQ는 vhost 제한을 기본( / ) vhost에만 적용합니다. Amazon MQ는 새로 생성된 vhost에 대해 기본 정책을 적용하지 않습니다. 새 가장 연결 가능한브로커 브로커와 기존 브로커 모두에 대해 이러한 기본값을 유지하는 것이 좋습니다. 하지만 언제든 이러한 기본값을 수정, 재정의 또는 삭제할 수 있습니다.

Amazon MQ는 브로커를 생성할 때 선택하는 인스턴스 유형 및 브로커 배포 모드에 따라 정책과 제한을 생성합니다. 기본 정책은 다음과 같이 배포 모드에 따라 이름이 지정됩니다.

단일 인스턴스 – AWS-DEFAULT-POLICY-SINGLE-INSTANCE

클러스터 배포 – AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ

단일 인스턴스 브로커의 경우 Amazon MQ는 정책 우선 순위 값을 0 으로 설정합니다. 기본 우선 순위 값을 재정의하려면 높은 우선 순위 값으로 사용자 지정 정책을 직접 생성할 수 있습니다. 클러스터 배포의 경우 Amazon MQ는 브로커 기본값의 우선 순위 값을 1 로 설정합니다. 클러스터의 고유한 사용자 지정 정책을 생성하려면 1 보다 큰 우선 순위 값을 할당합니다.

클러스터 배포에서 ha-mode 및 ha-sync-mode 브로커 정책은 클래식 미러링 및 고가용성(HA)에 필요합니다.

기본 AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ 정책을 삭제하면 Amazon MQ는 우선 순위 값이 0 인 ha-all-AWS-OWNED-DO-NOT-DELETE 정책을 사용합니다. 그러면 필수 ha-mode 및 ha-sync-mode 정책이 계속 적용됩니다. 고유한 사용자 지정 정책을 생성하는 경우 Amazon MQ는 정책 정의에 ha-mode 및 ha-sync-mode 를 자동으로 추가합니다.

주제

정책 및 제한 설명

다음 목록에서는 Amazon MQ가 새로 생성되는 브로커에 적용하는 기본 정책 및 제한에 대해 설명합니다. max-length , max-queues 및 max-connections 의 값은 브로커의 인스턴스 유형 및 배포 모드에 따라 다릅니다. 해당 값은 권장 기본값 단원에 나와 있습니다.

queue-mode: lazy (정책) - 지연 대기열을 활성화합니다. 기본적으로 대기열은 메시지의 인 메모리 캐시를 유지하여 브로커가 메시지를 소비자에게 가능한 한 빨리 전달할 수 있도록 합니다. 이로 인해 브로커의 메모리가 부족해지고 고용량 메모리 경보가 발생할 수 있습니다. 지연 대기열은 가능한 쉽게 메시지를 디스크로 이동하려고 합니다. 따라서 정상 작동 조건에서 메모리에 유지되는 메시지 수가 줄어듭니다. 지연 대기열을 사용하면 RabbitMQ용 Amazon MQ에서 더 큰 메시징 로드와 더 긴 대기열을 지원할 수 있습니다. 특정 사용 사례에서는 지연 대기열을 사용하는 브로커의 성능이 약간 느려질 수 있습니다. 이는 인 메모리 캐시에서 메시지를 전달하는 것이 아니라 메시지가 디스크에서 브로커로 이동되기 때문입니다.

max-length: number-of-messages (정책) - 대기열의 메시지 수에 대한 제한을 설정합니다. 클러스터 배포에서 이 제한은 브로커 재부팅과 같은 경우에나 유지 관리 기간 이후에 대기열 동기화 일시 중지를 방지합니다.

overflow: reject-publish (정책) - max-length 정책을 사용하는 대기열에서 대기열의 메시지 수가 max-length 값에 도달한 후 새 메시지를 거부하도록 합니다. 대기열이 오버플로 상태이더라도 메시지가 손실되지 않도록 하가 위해 브로커에 메시지를 게시하는 클라이언트 애플리케이션은 게시자 확인을 구현해야 합니다. 게시자 확인을 구현하는 방법에 대한 자세한 내용은 RabbitMQ 웹 사이트에서 게시자 확인 을 참조하세요.

max-queues: number-of-queues-per-vhost (vhost 제한) - 브로커의 대기열 수에 대한 제한을 설정합니다. max-length 정책 정의와 마찬가지로 클러스터 배포에서 대기열 수를 제한하면 브로커 재부팅이나 유지 관리 기간 이후에 대기열 동기화 일시 중지가 방지됩니다. 대기열을 제한하면 대기열을 유지하기 위해 과도한 양의 CPU가 사용되는 것도 방지됩니다.

max-connections: number-of-connections-per-vhost (vhost 제한) - 브로커에 대한 클라이언트 연결 수의 제한을 설정합니다. 권장 값에 따라 연결 수를 제한하면 과도한 브로커 메모리 사용으로 브로커에서 고용량 메모리 경보가 발생하고 작동이 일시 중지될 수 있는 문제가 방지됩니다.

권장 기본값

max-length 및 max-queue 기본 제한은 평균 메시지 크기 5kB를 기준으로 테스트 및 평가됩니다. 메시지가 5kB보다 훨씬 큰 경우 max-length 및 max-queue 제한을 조정하고 줄여야 합니다.

다음 표에는 새로 생성된 브로커의 기본 제한 값이 나와 있습니다. Amazon MQ는 브로커의 인스턴스 유형 및 배포 모드에 따라 이러한 값을 적용합니다.

인스턴스 유형	Deployment mode(배포 모드)	max-length	max-queues	max-connections
t3.micro	단일 인스턴스	해당 사항 없음	500	500
m5.large	단일 인스턴스	해당 사항 없음	20,000건	4,000
	클러스터	8,000,000	4,000	15,000
m5.xlarge	단일 인스턴스	해당 사항 없음	30,000개	8,000
	클러스터	9,000,000	5,000	20,000건
m5.2xlarge	단일 인스턴스	해당 사항 없음	60,000	15,000
	클러스터	10,000,000	6,000	40,000
m5.4xlarge	단일 인스턴스	해당 사항 없음	150,000	30,000개
	클러스터	12,000,000	10,000개	100,000건

수동으로 기본 정책 및 제한 적용

다음 단원에서는 Amazon MQ 권장 기본값을 사용하여 사용자 지정 정책 및 제한을 적용하는 방법을 설명합니다. 권장되는 기본 정책 및 제한을 삭제한 후 다시 생성하거나 추가 vhost를 생성한 후 새 vhost에 기본 정책과 제한을 적용하려는 경우 다음 단계를 사용할 수 있습니다.

다음 단계를 수행하려면 관리자 권한이 있는 RabbitMQ용 Amazon MQ 브로커 사용자가 있어야 합니다. 브로커를 처음 생성할 때 만든 관리자 사용자를 사용하거나 나중에 가장 연결 가능한브로커 만들었을 수 있는 다른 사용자를 사용할 수 있습니다. 다음 표에는 필요한 관리자 사용자 태그 및 권한이 정규식(regexp) 패턴으로 나와 있습니다.

태그	regexp 읽기	regexp 구성	regexp 쓰기
administrator	.*	.*	.*

RabbitMQ 사용자를 생성하고 사용자 태그 및 권한을 관리하는 방법에 대한 자세한 내용은 사용자 단원을 참조하세요.

RabbitMQ 웹 콘솔을 사용하여 기본 정책 및 가상 호스트 제한을 적용하려면

왼쪽 탐색 창에서 Brokers(브로커)를 선택합니다.

브로커 목록에서 새 정책을 적용할 브로커의 이름을 선택합니다.

브로커 세부 정보 페이지의 Connections(연결) 섹션에서 RabbitMQ 웹 콘솔 URL을 선택합니다. RabbitMQ 웹 콘솔이 새 브라우저 탭 또는 창에 열립니다.

브로커 관리자 사용자 이름 및 암호를 사용하여 RabbitMQ 웹 콘솔에 로그인합니다.

RabbitMQ 웹 콘솔의 페이지 상단에서 Admin(관리자)을 선택합니다.

Admin(관리자) 페이지의 오른쪽 탐색 창에서 Policies(정책)를 선택합니다.

Policies(정책) 페이지에서 브로커의 현재 User policies(사용자 정책) 목록을 볼 수 있습니다. User policies(사용자 정책) 아래에서 Add / update a policy(정책 추가/업데이트)를 확장합니다.

새 브로커 정책을 생성하려면 Add / update a policy(정책 추가/업데이트)에서 다음을 수행합니다.

Virtual host(가상 호스트)의 드롭다운 목록에서 정책을 연결할 vhost의 이름을 선택합니다. 기본 vhost를 선택하려면 /를 선택합니다.

추가 vhost를 생성하지 않은 경우 Virtual host(가상 호스트) 옵션이 RabbitMQ 콘솔에 표시되지 않으며 정책은 기본 vhost에만 적용됩니다.

Name(이름)에 정책의 이름을 입력합니다(예: policy-defaults ).

Pattern(패턴)에 regexp 패턴 .* 를 입력합니다. 이 경우 정책이 브로커의 모든 대기열과 일치합니다.

Apply to(적용 대상)의 드롭다운 목록에서 Exchanges and queues(교환 및 대기열)를 선택합니다.

Priority(우선 순위)에 vhost에 적용된 다른 모든 정책보다 큰 정수를 입력합니다. 지정된 시간에 RabbitMQ 대기열 및 교환에 정확히 하나의 정책 정의 집합을 적용할 수 있습니다. RabbitMQ는 가장 높은 우선 순위 값과 일치하는 정책을 선택합니다. 정책 우선 순위 및 정책을 결합하는 방법에 대한 자세한 내용은 RabbitMQ Server 설명서에서 정책 을 참조하세요.

Definition(정의)에 다음 키-값 페어를 추가합니다.

queue-mode = lazy . 드롭다운 목록에서 String(문자열)을 선택합니다.

overflow = reject-publish . 드롭다운 목록에서 String(문자열)을 선택합니다.

단일 인스턴스 브로커에는 적용하지 마세요.

max-length 가장 연결 가능한브로커 = number-of-messages . 브로커의 인스턴스 크기 및 배포 모드에 따라 number-of-messages 를 Amazon MQ 권장 값으로 바꿉니다(예: mq.m5.large 클러스터의 경우 8000000 ). 드롭다운 목록에서 Number(숫자)를 선택합니다.

단일 인스턴스 브로커에는 적용하지 마세요.

Add / update policy(정책 추가/업데이트)를 선택합니다.

새 정책이 User policies(사용자 정책)의 목록에 표시되는지 확인합니다.

클러스터 브로커의 경우 Amazon MQ는 ha-mode: all 및 ha-sync-mode: automatic 정책 정의를 자동으로 적용합니다.

오른쪽 탐색 창에서 Limits(제한)를 선택합니다.

Limits(제한) 페이지에서 브로커의 현재 Virtual host limits(가상 호스트 제한) 목록을 볼 수 있습니다. Virtual host limits(가상 호스트 가장 연결 가능한브로커 제한) 아래에서 Set / update a virtual host limit(가상 호스트 제한 설정/업데이트)를 확장합니다.

새 vhost 제한을 생성하려면 Set / update a virtual host limit(가상 호스트 제한 설정/업데이트) 아래에서 다음을 수행합니다.

Virtual host(가상 호스트)의 드롭다운 목록에서 정책을 연결할 vhost의 이름을 선택합니다. 기본 vhost를 선택하려면 /를 선택합니다.

Limit(제한)의 드롭다운 옵션에서 max-connections를 선택합니다.

Value(값)에 브로커의 인스턴스 크기 및 배포 모드에 따라 Amazon MQ 권장 값을 입력합니다(예: mq.m5.large 클러스터의 경우 15000 ).

Set / update limit(제한 설정/업데이트)를 선택합니다.

위 단계를 반복하고 Limit(제한)의 드롭다운에서 max-queues를 선택합니다.

새 제한이 Virtual host limits(가상 호스트 제한)의 목록에 표시되는지 확인합니다.

RabbitMQ 관리 API를 사용하여 기본 정책 및 가상 호스트 제한을 적용하려면

왼쪽 탐색 창에서 Brokers(브로커)를 선택합니다.

브로커 목록에서 새 정책을 적용할 브로커의 이름을 선택합니다.

브로커 페이지의 Connections(연결) 섹션에서 RabbitMQ 웹 콘솔 URL을 기록합니다. 이는 HTTP 요청에서 사용하는 브로커 엔드포인트입니다.

새 터미널 또는 원하는 명령줄 창을 엽니다.

새 브로커 정책을 생성하려면 다음 curl 명령을 입력합니다. 이 명령에서는 대기열이 %2F 로 인코딩된 기본 / vhost에 있다고 가정합니다. 정책을 다른 vhost에 적용하려면 %2F 를 vhost의 이름으로 바꿉니다.

username 과 password 를 관리자 사용자 이름과 암호로 바꿉니다. 브로커의 인스턴스 크기 및 배포 모드에 따라 number-of-messages 를 Amazon MQ 권장 값으로 바꿉니다. policy-name 을 정책의 이름으로 바꿉니다. broker-endpoint 를 이전에 기록한 URL로 바꿉니다.

브로커의 사용자 정책에 새 정책이 추가되었는지 확인하려면 다음 curl 명령을 입력하여 모든 브로커 정책을 나열합니다.

새 max-connections 가상 호스트 제한을 생성하려면 다음 curl 명령을 입력합니다. 이 명령에서는 대기열이 %2F 로 인코딩된 기본 / vhost에 있다고 가정합니다. 정책을 다른 vhost에 적용하려면 %2F 를 vhost의 이름으로 바꿉니다.

username 과 password 를 관리자 사용자 이름과 암호로 바꿉니다. 브로커의 인스턴스 크기 및 배포 모드에 따라 max-connections 를 Amazon MQ 권장 값으로 바꿉니다. 브로커 엔드포인트를 이전에 기록한 URL로 바꿉니다.

새 max-queues 가상 호스트 제한을 생성하려면 이전 단계를 반복하되 다음과 같이 curl 명령을 수정합니다.

브로커의 가상 호스트 제한에 새 제한이 추가되었는지 확인하려면 다음 curl 명령을 입력하여 모든 브로커 가상 호스트 제한을 나열합니다.

Amazon MQ 브로커 연결 문제를 해결하려면 어떻게 해야 합니까?

Amazon MQ 브로커 연결 문제는 여러 가지 이유로 발생할 수 있으며 여러 유형의 오류가 발생할 수 있습니다. Amazon MQ가 연결 관련 오류를 반환하는 가장 일반적인 이유는 다음과 같습니다.

• 잘못 구성된 로컬 방화벽 및 라우팅 테이블
• 잘못 구성된 보안 그룹 및 NACL(네트워크 액세스 가장 연결 가능한브로커 제어 목록)
• 잘못된 포트 번호에 연결
• DNS 확인 문제
• 지원되지 않는 SDK 클라이언트
• 잘못된 브로커 가시성 설정
• 잘못 구성된 SSL/TLS
• 만료된 브로커 엔드포인트 인증서

다음은 브로커 연결 문제가 있을 때 Amazon MQ에서 반환할 수 있는 몇 가지 오류 메시지의 예입니다.

• SSLHandshakeException
• JMSException
• UnknownHostException
• SocketTimeoutException

해결 방법

Amazon MQ 브로커 연결 문제를 해결하려면 다음을 수행합니다.

로컬 방화벽 및 라우팅 테이블이 올바르게 구성되었는지 확인합니다.

퍼블릭 접근이 가능한 있는 브로커의 경우

• 애플리케이션이 인터넷에 액세스할 수 있습니다.
• 로컬 방화벽과 라우팅 테이블이 공용 인터넷 트래픽을 허용합니다.
• 서브넷 NACL 및 브로커의 보안 그룹은 Amazon MQ에서 지원하는 포트를 통한 통신을 허용합니다.
• Amazon Virtual Private Cloud(Amazon VPC)의 브로커는 인터넷 게이트웨이에 대한 기본 경로가 있는 퍼블릭 서브넷에 있습니다. 자세한 내용은 Amazon VPC 사용 설명서의 인터넷 액세스 활성화 단원을 참조하십시오.

프라이빗 브로커의 경우

• Amazon MQ 브로커와 연결된 AWS 클라우드 서비스별 구성이 올바르게 설정되었습니다.
• 로컬 방화벽과 라우팅 테이블은 연결된 가상 사설 네트워크(VPN) 간의 인바운드 및 아웃바운드 트래픽을 허용합니다.
• 서브넷 NACL 및 브로커의 보안 그룹은 Amazon MQ에서 지원하는 포트를 통한 통신을 허용합니다.

Amazon MQ 브로커의 네트워크 연결 테스트

Amazon MQ 개발자 안내서의브로커 웹 콘솔 또는 엔드포인트에 연결할 수 없습니다.단원의 5단계에 있는 지침을 따르십시오.

참고: nslookup 명령 요청 시간이 초과되거나 명령 출력의 응답 섹션에 값이 없는 경우 다음을 수행합니다.

• 로컬 DNS 캐시를 지웁니다.
• 로컬 네트워킹 장비 및 클라이언트를 다시 시작합니다.
• 로컬 DNS 서버가 올바르게 구성되었는지 확인합니다.

지원되는 SDK 클라이언트를 사용 중인지 확인

사용 중인 브로커 엔진과 호환되는 최신 SDK 클라이언트 구현을 사용하고 있는지 확인합니다.

ActiveMQ용 Amazon MQ의 경우 AMQP 1.0 프로토콜을 사용해야 합니다. RabbitMQ용 Amazon MQ의 경우 AMPQ 0-9-1 프로토콜을 사용해야 합니다.

SSL/TLS를 사용하여 AWS 리소스와 통신하고 있는지 확인합니다.

참고: Amazon MQ는 현재 상호 전송 계층 보안(TLS) 인증을 지원하지 않습니다.

잘못된 SSL/TLS 버전 및 지원되지 않는 암호 집합을 사용하면 SSL 오류가 발생합니다. 자세한 내용은 Amazon MQ 개발자 안내서에서 Amazon MQ의 데이터 보호를 참조하십시오.

RabbitMQ 및 ActiveMQ에 대해 지원되는 암호 목록은 Amazon MQ 개발자 안내서의 전송 중 데이터 암호화를 참조하십시오.

참고: 일부 클라이언트 라이브러리는 SSL을 명시적으로 활성화해야 합니다. 다음은 Java 및 Ruby 프로그래밍 언어에 대한 명시적 SSL 활성화의 예입니다.

(Java) 명시적 SSL 활성화 코드 예제

(Ruby) 명시적 SSL 활성화 코드 예제

Amazon MQ 브로커 엔드포인트 인증서가 최신 상태인지 확인합니다

자세한 내용은 Amazon MQ 개발자 안내서의 SSL 예외 섹션을 참조하십시오.

Amazon Trust Services Certificate(CA)가 신뢰 저장소에 있는지 확인하는 방법에 대한 지침은 다음 문서를 참조하십시오. AWS가 자체 인증 기관으로의 이전을 준비하는 방법

가장 연결 가능한브로커

You are using an outdated browser. Please upgrade your browser to improve your experience.

이 항목에서는 Horizon Cloud 테넌트에 대한 브로커 전환 프로세스와 이러한 전환을 수행하여 얻을 수 있는 이점을 소개합니다. 단일 포드 브로커와 Universal Broker 환경 간의 차이점과 브로커 전환 이전, 도중 및 이후에 예상할 수 있는 결과에 대해 알아봅니다.

브로커 전환 프로세스란?

브로커 전환을 완료하면 Horizon Cloud 테넌트 환경이 단일 포드 브로커 사용에서 Universal Broker 를 사용하여 최종 사용자 할당에서 리소스를 브로커링하는 방식으로 변경됩니다. 새로운 테넌트 전체 브로커로서, Universal Broker 가장 연결 가능한브로커 는 사용자의 연결 요청을 관리하고 요청된 할당에서 사용 가능한 최상의 리소스로 라우팅합니다.

브로커 전환 프로세스는 최종 사용자 할당을 다음과 같이 변경합니다.

• VDI 데스크톱 할당은 Universal Broker 에 의해 브로커링된 다중 클라우드 할당으로 변환됩니다. 다중 클라우드 할당에는 여러 포드의 VDI 데스크톱이 포함할 수 있습니다.
• 세션 기반 데스크톱 및 애플리케이션 할당은 변경되지 않은 상태로 유지됩니다. 세션 기반 데스크톱 또는 애플리케이션 할당에는 단일 포드의 리소스만 포함할 수 있지만 이제 이러한 할당은 Universal Broker 에 의해 브로커링됩니다.

전환 기능은 현재 환경에서 단일 포드 브로커를 사용하며 Horizon Cloud - Universal Broker로 전환하기 위한 시스템 요구 사항에 설명된 사전 요구 사항을 충족하는 경우에 사용할 수 있습니다.

Universal Broker 로 전환해야 하는 이유는 무엇입니까?

VMware의 최신 클라우드 기반 브로커링 기술인 Universal Broker 사용으로 전환할 경우 다음과 같은 주요 이점을 얻을 수 있습니다.

여러 포드의 VDI 데스크톱을 사용하는 최종 사용자 할당 단일 포드 브로커링을 사용할 경우 VDI 할당의 모든 데스크톱이 동일한 포드에서 제공되어야 합니다. 데스크톱 브로커링은 포드별로 수행됩니다.

Universal Broker 를 사용하는 경우 다중 클라우드 할당으로도 알려진 여러 포드에서 VDI 데스크톱 할당을 생성할 수 있습니다. 최종 사용자는 할당에 액세스하고 해당 할당에 포함된 포드에서 데스크톱을 수신할 수 있습니다. 자세한 내용은 VMware Horizon Service Universal Broker 소개 및 해당 하위 항목을 참조하십시오.

이전과 같은 세션 기반 데스크톱 및 애플리케이션 할당을 계속 사용할 수도 있습니다. 차이점은 이러한 할당의 세션 기반 데스크톱 및 애플리케이션이 포드별 브로커링 대신, Universal Broker 에 의해 브로커링된다는 것입니다.

모든 원격 리소스에 대한 단일 연결 FQDN 단일 포드 브로커링를 사용할 경우 최종 사용자는 각 포드의 FQDN(정규화된 도메인 이름)에 개별적으로 연결하여 해당 포드의 할당에 액세스해야 합니다. 브로커링이 포드별로 수행됩니다.

Universal Broker 를 사용할 경우 Universal Broker 구성 설정에 정의한 단일 FQDN에 연결하여 모든 할당에 액세스할 수 있습니다. 단일 FQDN을 통해 사용자는 환경의 모든 사이트에서 Microsoft Azure의 Horizon Cloud 포드와 VMware SDDC 기반 플랫폼의 Horizon 포드를 포함하는 모든 참여 포드의 할당에 액세스할 수 있습니다. 포드 간의 내부 네트워킹은 필요하지 않습니다.

성능 최적화를 위한 전역 포드 연결 및 인식 Universal Broker 는 다중 클라우드 할당에 참여하는 모든 포드와 직접 연결을 유지하고 각 포드의 가용성 상태를 계속 인식합니다. 따라서 Universal Broker 는 최종 사용자의 연결 요청을 관리하고 이러한 포드에서 직접 가상 리소스로 라우팅할 수 있습니다. 성능 및 지연 시간 문제를 줄일 수 있는 GSLB(전역 서버 로드 밸런싱) 또는 포드 간 네트워크 통신이 필요하지 않습니다. 스마트 브로커링 Universal Broker는 지리적 사이트 및 포드 토폴로지의 인식을 기준으로 최단 네트워크 경로를 따라 할당에서 최종 사용자로 리소스를 브로커링할 수 있습니다.

전환하지 않는 이유가 있습니까?

이 Universal Broker 릴리스에는 몇 가지 기능 제한 사항이 있습니다. 사용 사례에 Universal Broker 에서 지원하지 않는 기능이 필요한 경우 Universal Broker 에서 해당 기능을 지원할 때까지 단일 포드 브로커링을 사용하여 테넌트 환경을 유지하는 것이 좋습니다. 현재 Universal Broker 제한 사항의 목록은 Universal Broker - 기능 고려 사항 및 알려진 제한 사항의 내용을 참조하십시오.

브로커 전환 동안 어떤 과정이 진행됩니까?

전환 워크플로는 몇 가지 단계로 구성됩니다. 전환 수행에 대한 자세한 단계별 지침은 단일 포드 브로커에서 Universal Broker로의 전환 스케줄링 및 완료를 참조하십시오.

다음은 전환 전과 전환 중에 발생하는 프로세스에 대한 개략적인 개요입니다.

1. 워크플로를 시작하려면 먼저 전환이 실행되는 날짜와 시간을 스케줄링해야 합니다. 이 스케줄링 작업에 따라 전환 중에 Universal Broker 서비스를 설정하는 데 사용할 구성 옵션을 정의합니다.
2. 스케줄링한 시작 시간이 되기 적어도 15분 전에 콘솔에서 진행 중인 모든 작업을 완료하고 유지하려는 변경 내용을 저장합니다. 모든 구성 마법사 및 대화상자를 닫습니다. 또한 Microsoft Azure의 모든 포드가 온라인 상태이고 정상적인 준비 완료 상태인지 확인합니다.
3. 전환이 시작될 때 콘솔에서 로그아웃했다가 다시 로그인하라는 메시지가 표시됩니다.
4. 전환의 첫 번째 단계에서는 다음을 예상할 수 있습니다.
   • 콘솔의 편집 컨트롤에 액세스할 수 없으며 콘솔에 전환 중이라는 배너가 표시됩니다.
   • Microsoft Azure의 모든 포드는 이름이 Default-Site 인 사이트에 추가됩니다.
   • VDI 데스크톱 할당은 Universal Broker 에 의해 브로커링된 다중 클라우드 할당으로 변환됩니다. 기본 할당 설정에서 연결 선호도는 가장 가까운 사이트 로 설정되고, 범위는 사이트 내 로 설정됩니다.가장 연결 가능한브로커
   • 세션 기반 데스크톱 및 애플리케이션 할당은 변경되지 않은 상태로 유지됩니다. 전환 후 이러한 할당의 리소스가 Universal Broker 에 의해 브로커링됩니다.
   • 모든 할당은 최종 사용자가 사용할 수 있는 상태로 유지되고 이 시간 동안 모든 활성 사용자 세션은 계속 열려 있으며 완전히 작동합니다.

전환의 이 단계가 완료되면 콘솔에서 로그아웃했다가 다시 로그인하라는 메시지가 표시됩니다.

참고: 전환의 이 단계는 일반적으로 최대 30분이 걸립니다. 하지만 시스템 및 네트워크 상태와 환경의 전체 할당 수 및 전용 사용자-데스크톱 매핑에 따라 이 단계를 완료하는 데 몇 시간이 걸릴 수 있습니다.

이제 전체 브로커 전환이 완료된 것입니다.

브로커 전환 후 예상되는 결과

브로커 전환 후 테넌트 환경에 대한 변경 내용의 자세한 목록을 보려면 Universal Broker로 전환한 후 테넌트 환경의 새로워진 사항을 참조하십시오.

전환을 완료한 후 Universal Broker 환경이 제공하는 이점을 활용할 수 있습니다. 다음 목록은 다음에 수행할 작업에 대한 간략한 설명과 세부 페이지에 대한 링크를 제공합니다.

• 사이트 및 다중 클라우드 VDI 할당 설정을 수정하여 Universal Broker 기능을 최대한 활용하십시오. 예를 들어 기존 할당에 더 많은 포드를 추가하거나 사이트 설정을 조정하여 Universal Broker 에서 사용자에게 리소스를 할당하는 방식을 세부적으로 조정할 수 있습니다. 자세한 내용은 Universal Broker 환경에서 할당 생성 및 관리 및 Universal Broker 환경에서 사이트 사용을 참조하십시오.
• Horizon Cloud 테넌트와 Workspace ONE Access 간에 기존 통합이 형성된 경우 Universal Broker 를 사용하도록 해당 통합을 업데이트해야 합니다. 자세한 지침은 Universal Broker가 있는 Horizon Cloud 환경 - 테넌트를 Workspace ONE Access 및 Intelligent Hub 서비스와 통합을 참조하십시오.

참고: VMware Workspace ONE Access 제품 팀에서 확인한 대로 Universal Broker 가 Horizon Cloud on Microsoft Azure 배포에 사용되면 해당 구성에서 VMware Workspace ONE Access 제품의 가상 애플리케이션 수집 기능이 지원되지 않습니다. 그 이유는 Universal Broker 가 이전 스타일의 포드별 브로커링보다 최신의 브로커링 기술이기 때문입니다. 즉 Universal Broker 를 Workspace ONE Access 와 통합하면 Horizon Cloud 가장 연결 가능한브로커 on Microsoft Azure 배포에 대한 레거시 가상 애플리케이션 수집이 사용되지 않습니다. 따라서 Universal Broker 에는 Horizon Cloud on Microsoft Azure 배포에 대한 가상 애플리케이션 수집 개념이 전혀 없으므로 Universal Broker 및 Horizon Cloud on Microsoft Azure 구성을 사용하는 가상 애플리케이션 수집은 지원되지 않습니다.

Horizon Cloud on Microsoft Azure 배포에 대해 Universal Broker 가 구성되어 있고 해당 Horizon Cloud on Microsoft Azure 배포에서 Workspace ONE Access 및 Intelligent Hub 서비스를 사용하려는 경우 콘솔의 정리 작업의 일부로 통합 프로세스에서 이러한 배포에 있을 수 있는 기존 가상 애플리케이션 수집을 정리해야 합니다. 정리 작업을 완료하면 통합된 Universal Broker , Workspace ONE Access 및 Intelligent Hub 서비스의 최신 기능을 사용하여 동일한 애플리케이션이 Workspace ONE Access 및 Intelligent Hub 서비스에서 계속 작동합니다.

PubSub+
Event Broker

모든 환경에서 실행할 수 있는 소프트웨어, 목적지향적 하드웨어 및 관리형 서비스를 함께 활용하여 분산되어 있는 기업 전체에 event를 스트리밍할 수 있는 유일한 통합 event broker 기술입니다.

PubSub+ Event Broker는 처리량이 어마어마한 트랜잭션을 빛의 속도로 처리할 수 있게 해줍니다."

Event-driven 혁신을 가능하게 하는 PubSub+ Event Broker

Solace PubSub+ Event Broker는 cloud, 온프레미스 및 IoT 환경 전반에서
event와 정보를 효율적으로 스트리밍합니다. PubSub+의 '+'는 게시/구독을 넘어 요청/응답, 스트리밍과 재생을 비롯한 다양한 message 교환 패턴뿐 아니라 최고의 전송과 전송 보장(guaranteed delivery) 등 다양한 서비스 품질을 지원한다는 의미입니다. PubSub+는 Appliance, 소프트웨어 및 서비스 형태로 제공되며, 모두 동일한 기능과 관리 환경을 제공합니다.

Event Mesh를 구축하여 어디서나 데이터 공유

PubSub+는 event broker에 연결하여 event mesh(비 cloud, 프라이빗 cloud, 퍼블릭 cloud 등 배포된 곳과 관계없이 애플리케이션 간 동적 event 라우팅을 가능하게 하는 아키텍처 레이어)를 생성할 수 있게 해주며, 이를 통해 microservice를 연결 및 조정하고, 온프레미스 기록 시스템의 event를 cloud 서비스로 푸시하고, LoB와 IoT 모두에서 디지털 혁신을 실현할 수 있습니다.

세 가지 적용 방식

Cloud

Event Broker: Cloud는 관리형 서비스입니다. Messaging 인프라 운영은 Solace에게 맡기고 단 몇 분만에 event broker 서비스를 시작하여 원하는 만큼 확장해보세요. 지금 무료로 사용해보세요.

소프트웨어

Event Broker: Software는 고객이 선호하는 cloud, 컨테이너와 iPaaS/PaaS 환경에 손쉽게 배포할 수 있습니다. 지금 바로 제작에 활용 가능한 무료 에디션을 사용해보세요.

Event Broker: Hardware는 턴키 기기의 손쉬운 운영과 낮은 TCO로 최고의 성능과 용량을 제공하는 컴팩트한 형태의 서비스입니다.