최초 문서 게시일: 2012년 6월 20일 수요일

2012년 6월 22일 업데이트 - 이 문서와 첨부된 다운로드가 업데이트되었습니다.

Exchange Client Network Bandwidth Calculator의 최신 릴리스(영문일 수 있음)에는 다양한 업데이트가 포함되어 있는데 그 중에서도 가장 중요한 항목은 아마 표준 시간대 지원일 것입니다. 개인적으로 약 1년 동안 표준 시간대 문제를 해결하는 방법을 모색해 왔으며 현실적으로 사용 가능한 해결 방법을 찾아내는 데 꽤 시간이 걸렸습니다. 그러나 결국에는 문제를 해결할 수 있었는데요, 먼저 표준 시간대 문제란 무엇인지를 살펴보겠습니다.

표준 시간대 문제

이 게시물에서는 모든 독자가 표준 시간대의 정의 및 용도에 대해 알고 있다고 가정합니다. 혹시라도 추가 정보가 필요하시다면 아래의 Wikipedia 문서를 확인해 보시기 바랍니다.

http://en.wikipedia.org/wiki/Time_zone(영문일 수 있음)

표준 시간대

네트워크 대역폭 예측 측면에서 표준 시간대와 관련한 실제 문제는 전 세계 여러 지역에서 동일한 네트워크 연결 또는 최종 서비스를 공유하는 사용자들의 작업을 모델링하려는 경우 발생합니다. 사용자 대부분의 피크 사용 시간은 각 지역의 표준 시간대를 기준으로 하므로 문제가 발생하는 것입니다.

예를 들어 사용자 수가 1,000명인 평균 규모 조직의 일반적인 영업일에는 대개 피크 시간이 오전 10시경(2시간 동안 지속됨)과 오후 2시경(4시간 동안 지속됨)의 2개입니다. 이러한 영업일을 나타내는 그래프가 아래에 나와 있습니다.

그래프

이제 뉴욕의 공유 리소스에 액세스하는 1,000명의 사용자를 각각 지원하는 전 세계 5개 도시의 요구 사항을 모델링한다고 가정해 보겠습니다. 이 단계에서는 공유 리소스가 부하 분산 장치에 연결되는 Exchange 2010 온-프레미스라고 가정합니다.

  • 런던(GMT) = 사용자 1,000명
  • 바르샤바(GMT+1) = 사용자 1,000명
  • 자카르타(GMT+7) = 사용자 1,000명
  • 레드몬드(GMT-8) = 사용자 1,000명
  • 뉴욕(GMT-5) = 사용자 1,000명

각 사용자 집합의 피크 시간을 예측한 다음 합산하는 기존 방식을 사용하여 이를 모델링하는 경우의 결과는 다음과 같습니다.

그래프

이 차트에서는 사용자 수가 1,000명인 각 지역에서 매일 피크 시간에 초당 1.56메가비트의 대역폭이 필요한 것으로 표시되어 있습니다. 따라서 뉴욕의 부하 분산 장치를 공유하는 모든 사용자를 포함하도록 해당 값을 모두 합하면 피크 요구 사항은 초당 7.81메가비트가 됩니다. 기존에는 이러한 방식으로 여러 지역에 분산되어 있는 사용자에 대한 대역폭 계획을 처리하고 피크 요구 사항을 예측한 다음 모든 내용을 표로 만들어 합산했습니다.

여기서 문제는, 표준 시간대의 차이로 인해 유럽 사용자의 퇴근 시간이 레드몬드 사용자에게는 기상 시간이고 자카르타 사용자에게는 취침 시간이라는 것입니다.

이러한 각 지역의 표준 시간대를 고려한다면 차트는 크게 달라집니다.

그래프

이 차트에서는 실제 작업이 결합되는 경우 기존 방식으로 계획했던 것과는 크게 다른 사용 프로필이 생성됨을 확인할 수 있습니다. 여기서 흥미로운 점은 피크 작업이 이전 차트보다 훨씬 낮은 초당 3.78메가비트라는 것입니다. 위에서 설명한 대로 원래 예측 값은 초당 7.81메가비트였습니다. 사용 프로필 역시 원래 예측과는 크게 다릅니다.

문제 해결 방법

위의 차트에서 눈치채셨을 수도 있지만, 새로운 릴리스에서는 표준 시간대 세부 정보를 포함할 수 있도록 네트워크 계산기가 확장되었습니다.

이와 같은 확장을 위해 피크 작업량만 예측하는 대신 이제는 제공되는 사용 패턴(예: 오전 피크 시간, 오후 피크 시간 등)을 기준으로 하여 시간별 대역폭 사용량을 예측합니다. 따라서 계산기가 피크 사용 시간뿐 아니라 해당 시간을 제외한 나머지 시간 전체의 사용량도 계산할 수 있습니다. 계산기를 통해 이와 같은 곡선이 확인되면 표준 시간대를 고려하여 데이터를 합산할 수 있습니다.

단일 통합의 필요성

위에서 설명한 것과 같은 단일 통합 작업을 수행하는 조직이 있냐고요? 물론 있습니다. 대부분의 조직에서는 작업을 최대한 통합하고자 합니다. 이를 위해 설계 팀에서는 여러 지역에 분산된 사용자(서로 다른 프로필을 사용하며 표준 시간대도 서로 다름)의 서비스 작업을 계획해야 합니다. 이러한 현상은 작업을 클라우드로 이동하는 경우에 특히 두드러지는데, Office 365에서는 단일 지역 테넌트 위치만 제공하므로 Office 365를 사용하는 글로벌 조직은 전혀 다른 지역과 표준 시간대에서 대개 공유 인프라를 통해 서비스에 액세스하는 대부분의 사용자에 대해 계획을 세워야 합니다.

제가 함께 작업을 하고 있는 대부분의 고객 역시 다수의 소규모 데이터 센터를 소수의 대규모 데이터 센터로 통합하고 있습니다. 이와 같이 통합된 사이트에서는 이전에 분산되어 있던 사용자의 작업을 처리할 수 있어야 합니다. 이러한 사용자들은 대개 여러 표준 시간대에 있기 때문에 해당 작업을 포함할 때는 다른 분산 작업을 결합하는 방법도 필요합니다.

물론 모든 사용자가 같은 표준 시간대에 있다면 이러한 문제에 전혀 신경 쓸 필요 없이 계산기를 일반적인 방식으로 사용하면 됩니다.

새로운 표준 시간대 기능 사용

지금까지 표준 시간대 지원이 필요한 시나리오에 대해 설명했습니다. 이제 새로운 기능을 사용하는 방법에 대해 설명하겠습니다.

먼저 입력 시트에서 TimeZone 구성 표를 구성해야 합니다. 여기에 입력하는 매개 변수가 작업을 결합하는 데 사용되는 사용 곡선 모양을 제어합니다. 이러한 값은 조직 내의 표준 사용 패턴을 반영해야 합니다. 제 경우에는 보통 실행 중인 Exchange 서버에서 성능 데이터를 파악하고, 고객에게 사용자들의 작업 현황 및 피크 시간을 질문한 다음 이 표를 작성합니다.

표

입력 시트가 완성되면 Client Mix(클라이언트 조합) 시트로 이동합니다. 이 시트에서는 두 개의 새 영역에서 표준 시간대 데이터를 구성합니다.

두 영역 중 하나는 Model Timezone(모델 표준 시간대)으로, 계획 대상 리소스(예: 네트워크 링크 또는 부하 분산 장치)의 표준 시간대를 나타냅니다. 위의 예제에서 보셨던 것처럼, 모델 표준 시간대는 부하 분산 장치가 있는 뉴욕에 해당하는 GMT-5로 설정합니다.

두 번째 새 열은 TimeZone(표준 시간대)으로, GMT를 기준으로 하는 개별 사이트의 표준 시간대를 나타냅니다. 여기서는 영국의 경우를 예로 들어 GMT를 사용했지만 경우에 따라 UTC 등 다른 표준 시간대를 사용할 수도 있습니다.

표

이 표를 사용하여 생성되는 예측 값이 위에 나와 있는 클라이언트 조합 표 아래의 차트에 표시되어 있습니다. 이 표의 값은 초당 메가비트 단위이며, 각 시간의 예상 네트워크 사용량을 나타냅니다.

추가 정보

계산기에서 제공되는 또 다른 유용한 기능 중 하나는, Mailbox Role Calculator에 복사하여 DAG 네트워크 복제 예측을 수행하는 데 사용할 수 있는 표가 제공된다는 것입니다.

NetWork Calculator에서 예측 차트 오른쪽의 Client Mix(클라이언트 조합) 시트에는 시간별 변경률이 포함된 표가 있습니다. 이 표를 클립보드에 복사합니다.

그래프

그런 다음 Mailbox Server Role Calculator의 입력 시트 아래쪽으로 스크롤하면 Log Replication Configuration(로그 복제 구성) 표가 있습니다. Network Calculator에서 복사한 수치를 이 표에 붙여 넣습니다.

표

그러면 Mailbox Server Role Calculator가 조직의 데이터 및 표준 시간대 구성을 모두 고려하여 DAG 복제를 위한 대역폭 요구 사항을 예측할 수 있습니다.

결론

이 새로운 기능을 통해 많은 사용자들이 네트워크 대역폭 요구 사항을 보다 정확하게 예측할 수 있기를 바랍니다. 모든 배포에서 이 기능이 필요한 것은 아니지만, 이 문제를 겪고 있는 대규모 엔터프라이즈 설계자의 경우 표준 시간대 기능을 사용하면 도움이 될 것입니다.

이 기능을 사용해 보시고 netcalc AT microsoft.com 주소로 언제든지 여러분의 의견을 보내 주십시오. 어떤 의견이라도 환영합니다.

Neil Johnson
MCS UK 선임 컨설턴트

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Exchange Client Bandwidth Prediction – the time zone problem…을 참조하십시오.