Service Broker 개발 계획
Service Broker 응용 프로그램을 설계할 때는 다음 사항을 검토하십시오.
응용 프로그램에서 예상되는 입력 및 출력의 유형/볼륨과 관련된 메트릭
제안된 응용 프로그램의 요구 사항
이러한 요소를 이해하면 비즈니스 목표에 부합하는 시스템을 개발할 수 있습니다.
검사 목록 계획
응용 프로그램을 계획할 때는 다음 질문을 고려해 보십시오.
응용 프로그램에서 Service Broker의 역할은 무엇입니까?
이 질문에 대한 대답은 응용 프로그램이 사용하는 메시지 유형, 응용 프로그램의 구조 및 응용 프로그램의 저장소/처리 요구를 계획하는 데 도움이 됩니다.
예를 들어 응용 프로그램은 Service Broker를 통해 메시지를 처리할 리소스가 생길 때까지 큐에 메시지를 저장하여 메시지 도착률의 급격한 변동을 처리할 수 있습니다. 이 경우 응용 프로그램이 사용하는 메시지 유형은 기존 응용 프로그램의 입력 및 출력과 거의 일치해야 합니다. 기존 작업량에 따라 응용 프로그램의 저장소 및 처리 요구를 예측할 수 있습니다.
이와 반대로 새 응용 프로그램을 설계하는 경우 Service Broker를 사용할 때 가장 많은 이점을 얻을 수 있는 작업을 신중하게 고려해야 합니다. Service Broker를 사용하면 기존 응용 프로그램이 완전히 실패하는 경우에도 안정성을 제공받을 수 있는 대신 최상의 경우 예상 가능한 처리 시간이 늘어납니다.
예를 들어 온라인 주문 입력 응용 프로그램은 주문 제출 시 주문을 완전히 처리하고 최종 확인을 제공할 필요가 없습니다. 대신 이 응용 프로그램은 주문을 처리하고 전자 메일을 통해 최종 확인을 제공하는 서비스에 주문을 제출할 수 있습니다. 이러한 설계를 사용하면 주문 응용 프로그램이 네트워킹 문제로 인해 주문을 확인하지 못하는 경우에도 계속해서 주문을 받을 수 있습니다. 네트워킹 문제가 해결되면 이 응용 프로그램이 주문을 처리합니다. 이 경우 응용 프로그램의 저장소 및 처리 요구는 예상 주문 수, 각 주문 메시지의 크기 및 각 주문을 처리하는 데 소요되는 시간에 따라 달라집니다.
원하는 태스크를 완료하기 위해 대화에 필요한 정보는 무엇입니까? 끝점에서 이 정보를 서로에게 제공하기 위해 교환하는 메시지의 스키마는 무엇입니까?
대부분의 서비스는 반구조화된 정보를 교환합니다. 따라서 XML 인코딩을 사용하면 좋습니다. 이진 인코딩은 이미지와 같은 이진 파일을 교환하는 데 유용합니다. 메시지가 도착했다는 사실만 알리기 위해 메시지를 사용하는 경우에는 빈 메시지를 사용합니다.
올바른 메시지 유형을 선택하면 나중에 응용 프로그램을 업데이트해야 할 가능성이 낮아집니다. 메시지 유형 인코딩에 따라 업데이트 작업에는 XML 스키마 파일 업데이트에서 응용 프로그램의 코딩을 상당히 변경하기까지 모든 작업이 포함될 수 있습니다. 현재 필요하지 않지만 나중에 필요할 것으로 예상되는 데이터 항목이 있는 경우 해당 항목을 포함하는 것이 좋습니다. 시작할 때 스키마에 이러한 요소를 정의하는 경우 해당 요소를 지원해야 할 때 스키마를 변경할 필요가 없습니다.
메시지 처리 논리가 실행될 위치는 어디입니까?
응용 프로그램을 Service Broker에 의해 활성화되는 저장 프로시저, 백그라운드 서비스, 예약된 이벤트 및 외부 응용 프로그램으로 설계할 수 있습니다. 최종 결정은 응용 프로그램에서의 Service Broker 역할에 따라 달라집니다. 예를 들어 응용 프로그램이 예측 가능한 비율로 도착하는 연속적인 메시지 스트림을 처리하는 경우 백그라운드 서비스를 사용할 수 있습니다. 도착하는 메시지 수에 따라 응용 프로그램이 동적으로 확장되어야 하는 경우 큐에 의해 활성화되는 저장 프로시저를 사용할 수 있습니다. 응용 프로그램이 메시지를 큐에 보관하고 설정된 시간에 메시지를 모두 처리하는 경우 예약된 이벤트를 사용하여 응용 프로그램을 시작할 수 있습니다.
프로그램에서 웹 페이지 또는 파일과 같은 데이터베이스 외부의 리소스에 액세스해야 하는 경우 외부 응용 프로그램을 사용할 수 있습니다. 외부 응용 프로그램을 사용하면 처리가 데이터베이스 서버 대신 중간 계층 서버에서 발생하므로 응용 프로그램의 확장성을 향상시킬 수 있습니다. Service Broker는 큐에 대한 원격 트랜잭션 액세스를 제공하므로 Service Broker를 사용하는 응용 프로그램은 쉽게 확장할 수 있습니다. Transact-SQL 명령을 데이터베이스로 보내고 결과를 처리할 수 있는 응용 프로그램은 Service Broker를 사용할 수 있습니다.
각 외부 프로그램은 큐를 사용하는 다른 프로그램과 격리됩니다. 따라서 외부 프로그램은 큐에 대한 액세스를 관리하기 위해 특별히 주의할 필요가 없습니다. 또한 응용 프로그램이 메시지를 처리하는 중 연결이 실패하면 트랜잭션이 롤백되고 Service Broker가 메시지를 큐로 돌려 보냅니다. 네트워크 문제로 인해 응용 프로그램에서 메시지가 손실되지는 않습니다.
응용 프로그램을 구현하는 데 사용할 계획인 기술은 무엇입니까?
SQL Server에서 데이터베이스에 연결하고 Transact-SQL 문을 실행할 수 있는 모든 기술을 사용하여 외부 응용 프로그램을 구현할 수 있습니다. 그러나 응용 프로그램은 일반적으로 .NET Framework 호환 언어 및 ADO.NET에서 개발됩니다. Transact-SQL 또는 .NET Framework 호환 언어 중 하나로 저장 프로시저를 구현할 수 있습니다. Transact-SQL은 데이터베이스 엔진에 비해 더 나은 성능을 제공할 수 있습니다. CLR 호환 언어는 더 나은 유연성, 프로그램 흐름에 대한 제어 강화, 프로세서를 많이 사용하는 응용 프로그램의 성능 향상 및 .NET Framework에 대한 직접 액세스와 같은 이점을 제공할 수 있습니다.
응용 프로그램이 가장 많이 사용할 서버 구성 요소는 무엇입니까?
최적의 응용 프로그램 성능을 얻기 위해 충분한 리소스가 있는지 시스템 관리자와 함께 확인합니다. 또한 가장 자주 사용할 구성 요소를 파악해야 합니다. 예를 들어 응용 프로그램이 처리 작업량을 균등하게 분산하기 위해 큐를 사용하거나 메시지 보존을 설정하는 경우 큐가 증가할 수 있는 디스크 공간이 충분한지 확인합니다. 반대로 메시징 볼륨이 크지만 큐 대기 시간이 짧은 응용 프로그램은 네트워크 대역폭을 더 많이 사용하지만 디스크 공간은 더 적게 사용할 수 있습니다.
메시지의 우선 순위를 서로 다르게 지정할 것입니까?
부하가 높은 시스템에서 Service Broker 대화 우선 순위는 많은 양의 덜 중요한 작업에 의해 중요한 작업이 차단되지 않도록 합니다. 또한 대화 우선 순위는 다양한 서비스 수준을 지원하는 설계를 가능하게 합니다.