내보내기(0) 인쇄
모두 확장

서비스 버스 정전 및 재해에 대비한 서비스 버스 응용 프로그램 보호 모범 사례

업데이트 날짜: 2014년 4월

중요 업무용 응용 프로그램은 갑작스러운 정전이나 재해가 발생하는 경우에도 계속 작동해야 합니다. 이 항목에서는 잠재적인 Microsoft Azure 서비스 버스 정전이나 재해로부터 응용 프로그램을 보호하는 데 사용할 수 있는 기술을 설명합니다.

정전은 Microsoft Azure 서비스 버스의 일시적인 사용 불가로 정의됩니다. 정전은 메시징 저장소 같은 일부 Service Bus 구성 요소나 전체 데이터 센터에도 영향을 미칠 수 있습니다. 문제가 해결된 다음에는 Service Bus를 다시 사용할 수 있습니다. 일반적으로 정전으로 인해 메시지나 기타 데이터가 손실되지는 않습니다. 구성 요소 오류인 경우 Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)을 사용할 수 없거나 특정 메시징 저장소를 사용할 수 없습니다. 데이터 센터 전체의 정전은 데이터 센터 전원 또는 데이터 센터 네트워크 스위치의 결함 등으로 인해 발생하며 수 분에서 수 일간 지속될 수 있습니다.

재해는 Service Bus 스케일 장치나 데이터 센터에 대한 영구적인 손실로 정의됩니다. 따라서 데이터 센터를 다시 사용할 수 없을 수도 있습니다. 일반적으로 재해로 인해 메시지나 기타 데이터의 일부 또는 전체가 손실됩니다. 화재, 홍수 또는 지진 등이 재해에 해당합니다.

Service Bus는 여러 메시징 저장소를 사용하여 큐 또는 항목에 보낸 메시지를 저장합니다. 분할되지 않은 큐 또는 항목은 하나의 메시징 저장소에 할당됩니다. 이 메시징 저장소를 사용할 수 없으면 해당 큐 또는 항목의 작업이 모두 실패합니다.

모든 Service Bus 메시징 엔터티(큐, 항목, 릴레이)는 서비스 네임스페이스에 있습니다. Service Bus 엔터티 액세스에 필요한 토큰을 제공하는 ACS도 마찬가지입니다. 서비스 네임스페이스는 데이터 센터와 연결되어 있습니다. Service Bus 및 ACS는 데이터에 대한 자동 지리적 복제를 사용하도록 설정되어 있지 않으며, 서비스 네임스페이스가 여러 데이터 센터에 걸쳐 위치하는 것도 허용하지 않습니다.

ACS를 사용할 수 없는 경우 클라이언트가 더 이상 토큰을 얻을 수 없습니다. 유효한 토큰이 없으면 이러한 클라이언트가 Service Bus 엔터티에서 작업을 수행할 수 없습니다. ACS 작동이 중지될 당시에 토큰을 보유한 클라이언트는 해당 토큰이 만료될 때까지 Service Bus를 계속 사용할 수 있습니다. 기본 토큰 수명은 3시간입니다.

ACS 정전으로부터 보호하려면 SAS(공유 액세스 서명) 토큰을 사용합니다. 이 경우 클라이언트는 암호 키를 사용하여 자체 생성된 토큰을 서명하는 방식으로 Service Bus를 직접 인증합니다. ACS에 대한 호출은 더 이상 필요하지 않습니다. SAS 토큰에 대한 자세한 내용은 Service Bus 인증을 참조하십시오.

분할되지 않은 큐 또는 항목은 하나의 메시징 저장소에 할당됩니다. 이 메시징 저장소를 사용할 수 없으면 해당 큐 또는 항목의 작업이 모두 실패합니다. 반면에 분할된 큐는 여러 조각으로 구성됩니다. 각 조각은 서로 다른 메시징 저장소에 저장됩니다. 분할된 큐 또는 항목으로 메시지를 보내면 Service Bus가 해당 메시지를 조각 중 하나에 할당합니다. 해당 메시징 저장소를 사용할 수 없으면 Service Bus는 다른 조각에 메시지를 씁니다(가능한 경우). 분할된 엔터티에 대한 자세한 내용은 메시징 엔터티 분할을 참조하십시오.

두 데이터 센터 간의 장애 조치(failover)를 허용하려면 각 데이터 센터에 Service Bus 및 ACS 서비스 네임스페이스를 하나씩 만들면 됩니다. 예를 들어 Service Bus 서비스 네임스페이스 contosoPrimary.servicebus.windows.net은 미국 중북부 지역에 있을 수 있고, contosoSecondary.servicebus.windows.net은 미국 중남부 지역에 있을 수 있습니다. Service Bus 메시징 엔터티가 데이터 센터 정전 시에도 액세스 가능한 상태를 유지하도록 하면 두 서비스 네임스페이스에 모두 해당 엔터티를 만들 수 있습니다.

릴레이 끝점의 지리적 복제는 Service Bus 정전 발생 시 릴레이 끝점을 노출하는 서비스에 연결할 수 있도록 해줍니다. 지리적 복제를 수행하기 위해서는 서비스에서 다른 서비스 네임스페이스에 릴레이 끝점을 두 개 만들어야 합니다. 두 서비스 네임스페이스는 다른 데이터 센터에 위치하고 두 끝점의 이름은 달라야 합니다. 예를 들어 기본 끝점은 contosoPrimary.servicebus.windows.net/myPrimaryService에서 연결할 수 있지만 보조 끝점은 contosoSecondary.servicebus.windows.net/mySecondaryService에서 연결할 수 있습니다.

그러면 서비스가 두 끝점에서 모두 수신해 클라이언트가 두 끝점 중 하나를 통해 서비스를 호출할 수 있습니다. 클라이언트 응용 프로그램은 임의로 릴레이 중 하나를 기본 끝점으로 선택해서 활성 끝점으로 요청을 보냅니다. 오류 코드가 있어 작업에 실패하면 이 릴레이 끝점을 사용할 수 없음을 나타냅니다. 응용 프로그램은 백업 끝점에 대한 채널을 열고 요청을 다시 실행합니다. 이때 활성 및 백업 끝점의 역할이 바뀝니다. 클라이언트 응용 프로그램은 이전 활성 끝점을 새 백업 끝점으로 간주하고, 이전 백업 끝점을 새 활성 끝점으로 간주합니다. 양쪽 보내기 작업에 모두 실패하면 두 엔터티의 역할이 바뀌지 않은 상태로 남아 오류가 반환됩니다.

Service Bus 릴레이된 메시지를 사용한 지리적 복제 샘플에는 릴레이 복제 방법이 설명되어 있습니다.

조정된 메시징을 사용하는 경우 데이터 센터 정전 시 복구하기 위해 Service Bus에서는 능동 복제와 수동 복제의 두 가지 접근 방법을 지원합니다. 각 접근 방법에서 데이터 센터 정전 시에도 지정된 큐나 항목에 액세스할 수 있도록 하면 두 서비스 네임스페이스에서 모두 해당 큐나 항목을 만들 수 있습니다. 두 엔터티의 이름은 같아도 됩니다. 예를 들어 기본 큐는 contosoPrimary.servicebus.windows.net/myQueue에서 연결할 수 있지만, 보조 큐는 contosoSecondary.servicebus.windows.net/myQueue에서 연결할 수 있습니다.

영구적인 발신자-수신자 통신이 응용 프로그램에 필요하지 않을 경우, 응용 프로그램은 지속형 클라이언트 쪽 큐를 구현하여 일시적인 Service Bus 오류로부터 메시지 손실을 방지하고 발신자를 보호할 수 있습니다.

능동 복제는 모든 작업에서 두 서비스 네임스페이스의 엔터티를 모두 사용합니다. 메시지를 보내는 클라이언트는 동일한 메시지의 복사본을 두 개 보냅니다. 첫 번째 복사본은 기본 엔터티(예: contosoPrimary.servicebus.windows.net/sales)로 전송되고, 두 번째 복사본은 보조 엔터티(예: contosoSecondary.servicebus.windows.net/sales)로 전송됩니다.

클라이언트는 두 큐에서 모두 메시지를 받습니다. 수신자는 첫 번째 메시지 복사본을 처리하지만 두 번째 복사본은 표시되지 않습니다. 중복되는 메시지를 표시하지 않으려면 발신자가 각 메시지에 고유한 식별자 태그를 지정해야 합니다. 두 메시지 복사본은 동일한 ID로 태그를 지정해야 합니다. MessageId, Label 또는 사용자 지정 속성을 사용하여 메시지에 태그를 지정할 수 있습니다. 수신자는 이미 받은 메시지의 목록을 유지 관리해야 합니다.

Service Bus 조정된 메시지를 사용한 지리적 복제 샘플에는 메시징 엔터티의 능동 복제가 설명되어 있습니다.

note참고
능동 복제 접근 방법을 사용하면 작업 수가 두 배가 되므로 비용이 더 상승할 수 있습니다.

오류가 없는 경우 수동 복제는 두 메시징 엔터티 중 하나만 사용합니다. 클라이언트는 능동 엔터티로 메시지를 보냅니다. 활성 엔터티를 호스팅하는 데이터 센터를 사용할 수 없음을 나타내는 오류 코드가 있어 활성 엔터티의 작업에 실패할 경우 클라이언트는 메시지 복사본을 백업 엔터티로 보냅니다. 이때 활성 엔터티와 백업 엔터티의 역할이 바뀝니다. 보내는 클라이언트는 이전 능동 엔터티를 새 백업 엔터티로 간주하고, 이전 백업 엔터티를 새 능동 엔터티로 간주합니다. 양쪽 보내기 작업에 모두 실패하면 두 엔터티의 역할이 바뀌지 않은 상태로 남아 오류가 반환됩니다.

클라이언트는 두 큐에서 모두 메시지를 받습니다. 수신자는 같은 메시지의 두 복사본을 받을 가능성이 있으므로 중복된 메시지가 표시되지 않도록 해야 합니다. 능동 복제에 설명된 것과 같은 방법으로 중복된 메시지를 표시하지 않을 수 있습니다.

일반적으로 수동 복제의 경우 대부분이 하나의 작업만 수행되므로 능동 복제보다 더 경제적입니다. 대기 시간, 처리량, 비용 측면에서 비복제 시나리오와 동일합니다.

다음 시나리오에서 수동 복제를 사용하면 메시지가 손실되거나 두 번 수신될 수 있습니다.

  • 메시지 지연 또는 손실: 발신자가 기본 큐로 m1 메시지를 전송하면 수신자가 m1을 받기 전에는 이 큐를 사용할 수 없게 됩니다. 이 발신자는 후속 메시지 m2를 보조 큐로 보냅니다. 기본 큐를 일시적으로 사용할 수 없는 경우, 수신자는 이 큐가 다시 사용 가능한 상태가 되었을 때 m1을 받을 수 있습니다. 재해가 발생한 경우에는 수신자가 m1을 받지 못할 수도 있습니다.

  • 중복 수신: 발신자가 기본 큐로 m 메시지를 보낸다고 가정하면, Service Bus에서 m을 성공적으로 처리해도 응답을 보내는 데 실패합니다. 보내기 작업의 시간이 초과된 후에 발신자가 보조 큐로 똑같은 m 복사본을 보냅니다. 기본 큐가 사용 불가능해지기 전에 수신자가 첫 번째 m 복사본을 받을 수 있으면 거의 동시에 두 가지 m 복사본을 모두 받습니다. 기본 큐가 사용 불가능해지기 전에 수신자가 첫 번째 m 복사본을 받을 수 없으면 수신자는 먼저 두 번째 m 복사본만 받은 다음 기본 큐가 사용 가능해지면 첫 번째 m 복사본을 받습니다.

Service Bus 조정된 메시지를 사용한 지리적 복제 샘플에는 메시징 엔터티의 수동 복제가 설명되어 있습니다.

응용 프로그램이 Service Bus 엔터티를 사용하지 못해도 괜찮지만 메시지를 손실하지 않아야 할 경우, 발신자는 Service Bus에 발송되지 않은 모든 메시지를 로컬에 저장하는 지속형 클라이언트 쪽 큐를 사용할 수 있습니다. Service Bus 엔터티를 다시 사용할 수 있게 되면 버퍼링된 모든 메시지가 이 엔터티로 전송됩니다. 지속형 메시지 발신자 샘플은 MSMQ의 지원을 통해 이 큐를 구현합니다. 또는 메시지를 로컬 디스크에 쓸 수 있습니다.

지속형 클라이언트 쪽 큐는 메시지 순서를 유지하며, Service Bus 엔터티를 사용할 수 없는 경우 예외로부터 클라이언트 응용 프로그램을 보호합니다. 이 큐는 간단한 분산 트랜잭션과 함께 사용할 수 있습니다.

참고 항목

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2014 Microsoft