초기 계획 및 성능 기록을 사용하여 Office 365 성능 조정

대략적인 연결 기준을 설정할 수 있도록 Office 365와 귀사 간 연결 성능을 확인하는 몇 가지 간단한 방법이 있습니다. 클라이언트 컴퓨터 연결의 성능 이력을 알고 있으면 새로운 문제를 조기에 감지하고 문제를 식별 및 예측할 수 있습니다.

이 문서는 다음과 같이 서비스 성능 문제 해결에 익숙하지 않은 사용자가 가장 많이 하는 몇 가지 질문을 고려하여 작성되었습니다. 발생한 문제가 Office 365 서비스 인시던트가 아닌 성능 문제라는 것을 어떻게 알 수 있을까요? 장기간 좋은 성능을 유지하기 위해 어떻게 계획을 세울 수 있을까요? 성능을 지속적으로 확인하려면 어떻게 해야 할까요? 팀 또는 클라이언트가 Office 365를 사용하면서 성능이 느려지는 문제를 겪고 있거나 이러한 질문에 대해 고민하고 있다면 이 문서를 읽어 보세요.

중요: 지금 클라이언트와 Office 365 간에 성능 문제가 있나요?Office 365의 성능 문제 해결 계획에 나오는 단계를 따르세요.

Office 365 성능에 대해 알아야 할 사항

Office 365는 자동화뿐만 아니라 실제 관리자에 의해서도 꾸준히 모니터링되는 고용량의 전용 Microsoft 네트워크에 상주합니다. Office 365 클라우드를 유지 관리하는 역할에는 성능을 조정하고 가능할 경우 간소화하는 작업이 포함됩니다. Office 365 클라우드의 클라이언트는 인터넷을 통해 연결해야 하므로 Office 365 서비스 전반의 성능을 정밀 조정하기 위한 작업이 지속적으로 진행되고 있습니다. 클라우드에서 거의 끊임없이 성능 개선이 이루어지고 있으며, 클라우드를 양호하고 신속하게 유지해온 경험이 축적되어 있습니다. 현재 위치에서 Office 365에 연결할 때 성능 문제가 있는 경우, 처음부터 지원을 요청하고 기다리는 것은 좋지 않습니다. 대신 '안에서 밖으로' 문제를 조사해야 합니다. 즉, 사용자의 네트워크 내부에서 시작하여 Office 365 방향으로 조사합니다. Office 365 지원을 요청하기 전에 데이터를 수집하고 조치를 취하여 문제에 대해 알아보면 문제를 해결할 수도 있습니다.

중요: Office 365의 용량 계획 및 제한을 숙지하고 있는 것이 좋습니다. 이 정보를 바탕으로 성능 문제를 더 빠르게 해결할 수 있습니다. 여기에 Office 365 플랫폼 서비스 설명의 링크가 있습니다. 이 문서는 Office 365에서 제공하는 모든 서비스의 링크를 통해 해당 서비스 설명으로 이동할 수 있는 중앙 허브입니다. 예를 들어 SharePoint Online의 기본 제한을 확인해야 하는 경우 SharePoint Online 서비스 설명을 클릭하고 해당 SharePoint Online 제한 섹션을 찾습니다.

문제 해결을 시작할 때 성능은 범위일 뿐이며, 성능의 이상적 값을 달성해서 영구적으로 유지하는 것이 목표가 아니라는 것을 이해해야 합니다. 그렇지 않은 경우, 가끔 많은 수의 사용자를 온보딩하는 고대역폭 작업이나 대규모 데이터 마이그레이션은 스트레스가 될 수 있습니다. 따라서, 이러한 작업을 수행할 때는 성능에 미치는 영향을 고려해야 합니다. 성능에 대해 대략적인 목표를 세울 수 있고 그렇게 해야 하지만, 성능에 영향을 미치는 수많은 변수가 존재하며 그에 따라 성능도 달라집니다. 이것이 성능의 특성입니다.

성능 문제를 해결하는 것은 특정 목표를 달성하고 그러한 수치를 영구적으로 유지하는 것이 아니라 주어진 모든 변수에서 기존 활동을 개선하는 것입니다.

어떤 성능 문제가 있나요?

가장 먼저, 현재 발생한 문제가 서비스 인시던트가 아닌 실제 성능 문제인지 확인해야 합니다. 성능 문제는 Office 365의 서비스 인시던트와 다릅니다. 두 가지를 구분하는 방법은 다음과 같습니다.

Office 365 서비스에 문제가 있다면 서비스 인시던트입니다. Office 365 관리 센터의 현재 상태에 빨간색 또는 노란색 아이콘이 표시되면 Office 365에 연결 중인 클라이언트 컴퓨터의 성능이 느려지는 경우가 있습니다. 예를 들어, 현재 상태에 빨간색 아이콘이 표시되어 있고 Exchange 옆에 조사하는 중이 표시되어 있는 경우, 조직 구성원으로부터 Exchange Online을 사용하는 클라이언트 사서함이 제대로 작동하지 않는다는 불만 전화를 수없이 받을 수 있습니다. 이 경우에는 서비스 내 문제로 인해 Exchange Online 성능이 저하된 것으로 가정할 수 있습니다.

서비스 복원됨이 표시된 Exchange를 제외한 모든 작업에 녹색이 표시된 Office 365 상태 대시보드

이 경우 Office 365 관리자는 현재 상태세부 내용 및 기록 보기를 자주 확인하여 시스템에 대해 수행하는 유지 관리를 최신 상태로 유지해야 합니다. 현재 상태 대시보드는 서비스에 대한 변경 사항과 문제가 갱신되는 위치입니다. 상태 기록에는 관리자가 관리자를 위해 입력한 메모와 설명이 표시되므로 이 정보를 바탕으로 어떤 영향이 있을지 가늠하고 진행 중인 작업을 계속 확인할 수 있습니다.

복원 이유와 함께 Exchange Online 서비스가 복원되었음을 설명하는 Office 365 상태 대시보드 그림

서비스 인시던트로 인해 성능이 느려질 수도 있지만 성능 문제는 서비스 인시던트가 아닙니다. 성능 문제는 다음과 같습니다.

  • 성능 문제는 Office 365 관리 센터의 현재 상태에 표시되는 서비스 상태와 상관없이 발생합니다.

  • 비교적 원활하게 수행되던 작업이 완료되는 데 오래 걸리거나 완료되지 않습니다.

  • 문제를 복제할 수 있거나, 최소한 일련의 올바른 단계를 수행할 경우 문제가 발생한다는 것을 알고 있습니다.

  • 문제가 간헐적으로 발생하며 패턴이 있습니다. 예를 들어, 오전 10시쯤에는 Office 365에 안정적으로 액세스할 수 없다는 전화 문의가 많고 정오쯤에는 해당 전화 문의가 없다는 것을 알고 있습니다.

이러한 상황에 너무나 친숙할 것입니다. 성능 문제라는 것을 확인했으면 다음 문제는 "이후에 수행할 작업"입니다. 이 문서의 나머지 부분을 통해 자세히 알아보세요.

성능 문제를 정의하고 테스트하는 방법

성능 문제는 보통 서서히 나타나므로 실제 문제를 규정하는 것이 어려울 수 있습니다. 문제를 적절히 기술하고 문제 상황을 올바르게 이해한 다음 해결에 적합하고 반복 가능한 테스트 단계를 작성해야 합니다. 그렇지 않으면, 관리자가 잘못한 것이 없는 경우에도 문제를 해결하지 못할 수 있습니다. 그 이유는 무엇일까요? 충분한 정보를 제공하지 않은 문제 기술의 몇 가지 예를 들어보겠습니다.

  • 이전에는 받은 편지함에서 내 일정으로 빠르게 전환할 수 있었는데 지금은 커피 한 잔을 마시고 와도 될 만큼 오래 걸립니다. 이전처럼 빠르게 할 수 없나요?

  • SharePoint Online에 파일을 업로드하려고 하는데 시간이 너무 오래 걸립니다. 어째서 오후에는 느리고 다른 시간에는 빠른가요? 오후에도 빠르게 할 수 없나요?

위와 같은 문제 기술은 몇 가지 큰 문제점이 있습니다. 특히, 다음과 같이 모호한 부분이 너무 많습니다.

  • 노트북에서 받은 편지함과 일정 간에 전환하는 방법이 명확하지 않습니다.

  • 사용자가 "빠르게 할 수 없나요"라고 할 때 "빠르게"는 얼마나 빠른 것을 의미하나요?

  • "너무 오래"란 얼마나 긴 시간을 의미하나요? 몇 초인가요, 몇 분인가요, 아니면 사용자가 점심 식사를 하고 온 다음 10분 후에 완료된다는 것인가요?

이러한 문제 기술 방식으로는 관리자와 문제 해결사가 많은 정보를 확인할 수 없습니다. 예를 들어, 문제가 발생했을 때 사용자가 재택 근무자이고 홈 네트워크에서 전환하는 경우에만 속도가 느려지는 문제가 있는지 여부, 사용자가 로컬 클라이언트에서 RAM 사용량이 많은 다른 응용 프로그램을 여러 개 실행해야 하는지 여부, 사용자가 이전 버전의 운영 체제를 실행하고 있거나 최신 업데이트를 실행하지 않았는지 여부와 같은 정보를 확인해야 합니다.

사용자가 성능 문제를 보고하는 경우 많은 정보를 수집해야 합니다. 이와 같은 정보를 수집하는 것은 문제 확인 또는 문제 조사라고 하는 과정의 일부입니다. 다음은 성능 문제에 대한 정보를 수집하기 위해 사용할 수 있는 기본 확인 목록입니다. 이 목록에 모든 항목이 포함된 것은 아니지만 이러한 질문으로 시작하는 것이 좋습니다.

  • 문제가 발생한 날짜는 언제이고 시간은 대략 언제쯤인가요?

  • 어떤 종류의 클라이언트 컴퓨터를 사용하고 있으며 회사 네트워크에는 어떻게 연결하고 있나요(VPN, 유선, 무선)?

  • 원격으로 근무하고 있었나요, 아니면 사무실에서 근무하고 있었나요?

  • 다른 컴퓨터에서 동일한 작업을 수행했을 때 동일한 문제가 발생했나요?

  • 어떤 동작을 하지 않아야 하는지 기록할 수 있도록 문제가 발생한 단계를 차례대로 실행해 보세요.

  • 성능이 몇 초 또는 몇 분 더 느려졌나요?

  • 현재 있는 지역이 어디인가요?

이러한 질문 중 일부는 다른 질문보다 더욱 명확합니다. 대부분의 사용자는 문제 해결사가 문제를 재현하기 위해 정확한 단계를 알아야 한다는 것을 이해합니다. 이렇게 하지 않는다면 무엇이 잘못되었는지 어떻게 기록할 수 있을까요? 또한 문제가 해결되었는지 여부를 어떻게 테스트할 수 있을까요? "문제가 발생한 날짜와 시간은 언제인가요?" 및 "현재 있는 지역은 어디인가요?" 등의 다소 명확하지 않은 질문의 정보는 함께 사용할 수 있습니다. 사용자가 작업하고 있었던 시간에서 몇 시간이 지났다면 이미 회사의 네트워크에서 유지 관리를 진행 중일 수 있습니다. 예를 들어, 회사가 SharePoint Online 및 온-프레미스 SharePoint Server 2013 인스턴스에서 검색 인덱스를 쿼리할 수 있는 하이브리드 SharePoint 검색과 같은 하이브리드 방식으로 구현된 경우 온-프레미스 팜에서 업데이트가 진행 중일 수 있습니다. 회사 전체가 클라우드에 구현된 경우에는 시스템 유지 관리에 네트워크 하드웨어 추가 또는 제거, 회사 전체 업데이트 설치 또는 DNS나 기타 핵심 인프라에 대한 변경 등이 포함될 수 있습니다.

성능 문제를 해결하는 것은 범죄 현장과 비슷하게 정확한 판단과 관찰로 증거에서 결론을 도출해야 합니다. 그렇게 하려면 증거를 수집하여 정확하게 문제를 기술해야 합니다. 즉, 문제가 시작되었을 때 컴퓨터의 상황 및 사용자의 상황과 성능 문제가 발생하게 된 정확한 단계를 포함해야 합니다. 이러한 문제 기술은 언제나 메모의 맨 윗줄에 기록되어 있어야 합니다. 해결 방법을 실행한 후에 문제 기술의 단계를 통해 수행한 작업으로 문제가 해결되었는지 여부를 테스트하고 입증할 수 있습니다. 이 과정은 문제 해결이 완료되었는지 여부를 확인하는 데 중요합니다.

문제가 발생하기 전의 성능을 알고 계신가요?

사용자가 기억하지 못한다면 아무도 모릅니다. 특히 수치를 아는 사람은 아무도 없습니다. 즉, 대부분의 회사에서 "Office 365에서 받은 편지함을 여는 데 보통 몇 초가 걸렸나요?" 또는 "임원들이 Lync Online 모임에 참여하는 때 보통 얼마나 걸렸습니까?"라는 간단한 질문에 대답할 수 있는 사람은 없을 것입니다.

여기에서 필요한 것이 성능 기준입니다.

기준을 활용하면 성능의 전후 사정을 파악할 수 있습니다. 회사의 요구 사항에 따라, 기준을 설정하는 빈도를 결정해야 합니다. 대규모 회사의 경우 운영 팀에서 온-프레미스 환경에 이미 기준이 설정되어 있을 수 있습니다. 예를 들어, 매달 첫째 주 월요일에 전체 Exchange 서버에 패치를 적용하고 셋째 주 월요일에는 전체 SharePoint 서버에 패치를 적용한다면 운영 팀에서 패치 적용 후에 중요 기능이 작동하는 것을 입증하기 위해 실행하는 작업 및 시나리오 목록이 있을 수 있습니다. 예를 들어, 운영 팀에서 받은 편지함을 열고 '보내기/받기'를 클릭한 다음 폴더가 업데이트되는지 확인하거나 SharePoint에서 사이트 기본 페이지를 탐색하고 엔터프라이즈 검색 페이지로 이동하여 결과가 반환되는 검색을 수행할 수 있습니다.

응용 프로그램이 Office 365에 포함된 경우, 가장 기본적인 기준으로 사용자 네트워크에 있는 클라이언트 컴퓨터에서 송신 지점까지 또는 네트워크에서 Office 365에 도달하기까지의 시간(밀리초 단위)을 측정할 수 있습니다. 다음은 조사 및 기록할 수 있는 유용한 일부 기준입니다.

  • 클라이언트 컴퓨터와 송신 지점(예: 프록시 서버) 간 장치를 확인합니다.

    • 발생한 성능 문제의 상황을 알 수 있도록 장치에 대해 알고 있어야 합니다(IP 주소, 장치 유형 등).

    • 프록시 서버는 일반적인 송신 지점이므로 웹 브라우저에서 어떤 프록시 서버를 사용하도록 설정되어 있는지 확인할 수 있습니다(있는 경우).

    • 네트워크를 검색 및 매핑할 수 있는 타사 도구가 있지만, 장치를 확인하는 가장 안전한 방법은 네트워크 팀 구성원에게 물어보는 것입니다.

  • ISP(인터넷 서비스 공급자)를 확인하여 연락처 정보를 기록해 둔 다음 회로 수와 대역폭 크기에 대해 문의합니다.

  • 회사 내부에서 클라이언트와 송신 지점 간 장치의 리소스를 확인하거나 네트워크 문제에 대해 긴급히 문의할 수 있는 연락처를 확인합니다.

다음은 도구를 이용한 간단한 테스트로 계산할 수 있는 일부 기준입니다.

  • 클라이언트 컴퓨터에서 송신 지점까지 소요되는 시간(밀리초)

  • 송신 지점에서 Office 365까지 소요되는 시간(밀리초)

  • 탐색 시 Office 365의 URL을 확인하는 서버의 위치

  • ISP의 DNS 확인 속도(밀리초), 패킷 도착 비일관성(네트워크 지터), 업로드 및 다운로드 시간(밀리초)

이러한 단계를 수행하는 방법에 대해 잘 모르는 경우 이 문서를 통해 자세히 알아보세요.

기준이란?

성능이 저하될 경우 어떤 영향이 있는지 알고 있어도 기존 성능 데이터를 모른다면 언제 어떻게 성능이 나빠졌는지 알 수 없습니다. 따라서 기준이 없다는 것은 퍼즐을 풀 수 있는 핵심 단서, 즉, 퍼즐 상자의 그림이 없는 것과 마찬가지입니다. 성능 문제를 해결하려면 비교 지점이 필요합니다. 간단한 성능 기준은 어렵지 않게 측정할 수 있으며 운영 팀이 일정에 따라 이러한 작업을 수행하도록 맡길 수 있습니다. 예를 들어, 연결 상태가 다음과 같다고 가정해 보겠습니다.

클라이언트, 프록시, Office 365 클라우드를 보여 주는 기본 네트워크 그래픽

회사에서 프록시 서버를 통해 인터넷에 연결하며, 해당 프록시에서 사용자의 클라이언트 컴퓨터에서 클라우드로 보내는 모든 요청을 처리한다는 것을 네트워크 팀을 통해 확인했습니다. 이 경우, 개입된 모든 장치를 나열하여 간단한 연결 그림을 그려야 합니다. 그런 다음 클라이언트, 송신 지점(인터넷에 연결하기 위해 네트워크에서 나가는 위치), Office 365 클라우드 사이에서 성능을 테스트하는 데 사용할 수 있는 도구를 삽입합니다.

클라이언트, 프록시, 클라우드와 추천 도구(PSPing, TraceTCP, 네트워크 추적)가 표시된 기본 네트워크

옵션은 성능 데이터를 찾는 데 필요한 전문 지식 수준을 기준으로 단순고급으로 나열했습니다. 네트워크 추적은 PsPing 및 TraceTCP 등의 명령줄 도구를 실행하는 경우에 비해 많은 시간이 소요됩니다. 이러한 두 가지 명령줄 도구를 선택한 이유는 Office 365에서 차단하는 ICMP 패킷을 사용하지 않으며 클라이언트 컴퓨터 또는 프록시 서버(액세스 권한이 있는 경우)에서 Office 365에 도달하는 데 몇 밀리초밖에 걸리지 않기 때문입니다. 컴퓨터 간에 각각의 개별 홉이 발생할 때마다 기준으로 사용하기에 적합한 시간 값이 기록됩니다. 이러한 명령줄 도구를 사용하면 명령에 포트 번호를 추가할 수 있습니다. Office 365에서는 SSL(Secure Sockets Layer) 및 TLS(전송 계층 보안)에서 사용하는 포트 443을 통해 통신하므로 이러한 명령줄 도구가 유용합니다. 하지만, 상황에 따라 다른 타사 도구가 더 적합할 수도 있습니다. Microsoft에서 모든 도구를 지원하지는 않으므로 어떤 이유로든 PsPing 및 TraceTCP가 작동하지 않는 경우에는 Netmon과 같은 도구로 네트워크 추적을 실행하세요.

영업 시간 전 기준을 측정하고 사용량이 많은 시간에 다시 측정한 다음 영업 시간이 끝난 이후 다시 측정할 수 있습니다. 이렇게 하면 나중에 폴더 구조가 다음과 유사해질 수 있습니다.

성능 데이터를 폴더에 정리하는 방법을 제안하는 그래픽

파일의 명명 규칙도 선택해야 합니다. 예를 들면 다음과 같습니다.

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

다양한 명명 방법이 있지만 처음에는 <dateTime><what's happening in the test> 형식으로 시작하는 것이 좋습니다. 이러한 형식을 따를 경우 나중에 문제를 해결할 때 많은 도움이 됩니다. 나중에 "2월 8일에 추적을 두 번 측정했는데 하나는 성능이 양호했고 하나는 나빴으므로 두 추적을 비교해볼 수 있겠네요."라고 말할 수 있습니다. 이러한 형식은 문제 해결에 매우 유용합니다.

지난 기준을 유지하려면 체계적인 방식이 필요합니다. 이 예제의 간단한 방법에서는 세 개의 명령줄 출력을 만들고 결과를 스크린샷으로 수집했지만, 대신 네트워크 캡처 파일을 수집할 수도 있습니다. 자신에게 가장 적합한 방법을 사용하세요. 지난 기준을 저장한 다음 온라인 서비스 동작에 변경 사항이 있는 경우 해당 지점을 참조하세요.

파일럿 중 성능 데이터를 수집하는 이유

Office 365 서비스 파일럿 기간만큼 기준을 만들기 좋은 시기가 없습니다. 사무실의 사용자 수가 수백, 수천 명인 경우도 있고 다섯 명에 불과한 경우도 있지만, 사용자 수가 적은 경우에도 테스트를 수행하여 성능의 변동을 측정할 수 있습니다. 대기업의 경우 수천 명의 사용자를 대상으로 구현하기 전에 수백 명의 사용자로 구성된 대표 샘플로 Office 365 파일럿을 실시하면 문제가 발생할 만한 위치를 미리 알 수 있습니다.

소규모 기업의 경우에는 온보딩 시 파일럿 없이 모든 사용자를 동시에 서비스에 연결하므로 성능 저하 문제를 해결해야 하는 사용자에게 데이터를 보여줄 수 있도록 성능 측정 값을 유지합니다. 예를 들어, 이전에 매우 빠르게 업로드할 수 있었던 중간 크기 그래픽을 업로드하는 데 갑자기 건물 안에서 산책을 하고 돌아올 정도의 시간이 소요되는 문제가 발생할 수 있습니다.

기준 수집 방법

모든 문제 해결 계획에서는 최소한 다음 사항을 확인해야 합니다.

  • 사용 중인 클라이언트 컴퓨터(컴퓨터 또는 장치 유형, IP 주소, 문제의 원인이 된 작업)

  • 클라이언트 컴퓨터가 있는 지역(예: 사용자가 VPN으로 네트워크에 연결하여 원격으로 작업 중인지 또는 회사 인트라넷에 연결되어 있는지 여부)

  • 클라이언트 컴퓨터가 네트워크에서 사용하는 송신 지점(트래픽이 ISP 또는 인터넷에 연결하기 위해 회사에서 나가는 지점)

네트워크 레이아웃은 네트워크 관리자를 통해 확인할 수 있습니다. 네트워크 규모가 작은 경우 인터넷에 연결하는 데 사용된 장치를 확인하고 레이아웃에 대해 궁금한 사항이 있으면 ISP에 문의합니다. 참조할 수 있도록 최종 레이아웃 그래픽을 만듭니다.

이 섹션은 간단한 명령줄 도구 및 방법과 기타 고급 도구 옵션으로 구분되어 있습니다. 우선 간단한 방법부터 살펴보겠습니다. 하지만 지금 당장 성능 문제가 있는 경우 고급 방법부터 수행하고 예제 성능 문제 해결 작업 계획을 시도해 보아야 합니다.

간단한 방법

이러한 간단한 방법의 목표는 시간 변화에 따라 간단한 성능 기준을 측정하고, 이해하고, 올바르게 저장하여 Office 365 성능을 파악하는 것입니다. 다음은 위에서 본 다이어그램과 같은 간단한 방법을 위한 간단한 다이어그램입니다.

클라이언트, 프록시, 클라우드와 추천 도구(PSPing, TraceTCP, 네트워크 추적)가 표시된 기본 네트워크

참고 사항: 

  • 이 스크린샷에서는 요청 처리 시간(밀리초)과 요청이 대상에 도달하는 데 필요한 네트워크 수, 다시 말해 컴퓨터 간 연결 수를 표시하는 데 유용한 TraceTCP가 포함되었습니다. 또한 TraceTCP는 홉 중에 사용된 서버 이름도 제공하므로 Microsoft Office 365 지원 담당자가 문제를 해결하는 데 유용할 수 있습니다.

  • TraceTCP 명령은 다음과 같이 매우 간단하게 작성할 수 있습니다.

  • tracetcp.exe outlook.office365.com:443

  • 명령에 반드시 포트 번호를 포함해야 합니다.

  • TraceTCP는 무료로 다운로드할 수 있지만 Wincap이 필요합니다. Wincap은 Netmon에서 사용 및 설치하는 도구입니다. Netmon은 고급 방법 섹션에서도 다룹니다.

여러 사무실이 있는 경우에는 각 사무실 위치의 클라이언트에서 보내는 데이터 집합을 보관해야 합니다. 이 테스트는 지연 시간을 측정하며, 이 경우 지연 시간이란 Office 365로 요청을 보내는 클라이언트와 요청에 응답하는 Office 365 사이에 소요되는 시간에 대해 설명하는 숫자 값입니다. 테스트는 클라이언트 컴퓨터의 도메인 내부에서 시작되며, 네트워크 내부에서 송신 지점을 거쳐 인터넷을 통해 Office 365에 도달한 다음 다시 돌아오는 데 걸리는 왕복 시간을 측정합니다.

송신 지점(이 경우 프록시 서버)을 처리하는 방법은 몇 가지가 있습니다. 1에서 2까지 추적하고 2에서 3까지 추적한 다음, 밀리초 단위의 숫자를 더해 네트워크 가장자리까지의 최종 합계를 구할 수 있습니다. 또는 Office 365 주소에 대한 프록시를 우회하는 연결을 구성할 수 있습니다. 방화벽, 역방향 프록시 또는 둘의 조합이 포함된 대규모 네트워크에서는 프록시 서버에서 많은 URL을 통과시키는 트래픽을 허용하는 예외 사항을 지정해야 할 수 있습니다. Office 365에서 사용하는 끝점 목록은 Office 365 URL 및 IP 주소 범위를 참조하세요. 인증 프록시가 있는 경우 다음에 대한 예외 테스트부터 시작합니다.

  • 포트 80 및 443

  • TCP 및 HTTPS

  • 다음 URL에 아웃바운드된 연결:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

모든 사용자는 프록시 간섭 또는 인증 없이 이러한 주소에 연결할 수 있도록 허용되어야 합니다. 소규모 네트워크에서는 웹 브라우저의 프록시 우회 목록에 이러한 주소를 추가해야 합니다.

Internet Explorer에서 이러한 주소를 프록시 우회 목록에 추가하려면 도구 > 인터넷 옵션 > 연결 > LAN 설정 > 고급으로 이동합니다. 고급 탭에도 프록시 서버 및 프록시 서버 포트가 있습니다. 고급 단추에 액세스하려면 사용자 LAN에 프록시 서버 사용 확인란을 클릭해야 할 수 있습니다. 로컬 주소에 프록시 서버 사용 안 함이 선택되었는지 확인합니다. 고급을 클릭하면 예외 항목을 입력할 수 있는 텍스트 상자가 표시됩니다. 위에 나열된 와일드카드 URL을 세미콜론으로 구분하여 입력합니다. 예를 들면 다음과 같습니다.

*.microsoftonline.com; *.sharepoint.com

프록시를 우회하면 Office 365 URL에 직접 ping 또는 PsPing을 사용할 수 있습니다. 다음으로 outlook.office365.com에 대해 ping을 테스트합니다. 명령에 포트 번호를 입력할 수 있는 PsPing 또는 다른 도구를 사용할 경우에는 portal.microsoftonline.com:443에 대해 PsPing을 실행하여 평균 왕복 시간(밀리초)을 확인할 수 있습니다.

RTT(왕복 시간)는 HTTP 요청을 outlook.office365.com과 같은 서버에 전송하고 서버에서 사용자가 요청을 보냈다는 것을 확인하는 응답을 받기까지 소요된 시간을 측정하는 숫자 값입니다. 간혹 왕복 시간이 약어인 RTT로 표시되는 경우도 있습니다. 이 시간은 비교적 짧습니다.

이 테스트를 수행하려면 Office 365에서 차단한 ICMP 패킷을 사용하지 않는 PSPing 또는 다른 도구를 사용해야 합니다.

PsPing을 사용하여 Office 365 URL에서 직접 전체 왕복 시간(밀리초)을 측정하는 방법

  1. 다음 단계를 완료하여 관리자 권한 명령 프롬프트를 실행합니다.

    1. 시작을 클릭합니다.

    2. 검색 시작상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누릅니다.

    3. 사용자 계정 컨트롤 상자가 나타나면 원하는 동작이 표시되었는지 확인한 다음 계속을 클릭합니다.

  2. 도구(이 경우 PsPing)가 설치된 폴더로 이동하고 다음 Office 365 URL을 테스트합니다.

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      microsoft-my.sharepoint.com 포트 443에 대한 PSPing 명령

포트 번호 443을 반드시 포함해야 합니다. Office 365는 암호화된 채널에서 작동합니다. 포트 번호 없이 PsPing을 실행하면 요청이 실패합니다. 간단한 목록을 ping한 다음 밀리초(ms) 단위의 평균 시간을 찾아봅니다. 이 수치가 기록할 값입니다!

클라이언트에서 프록시까지 왕복 시간이 2.8ms인 PSPing을 보여 주는 그래픽

프록시 우회에 대해 잘 모르고 있으며 단계별 방식을 선호하는 경우, 먼저 프록시 서버의 이름을 찾아야 합니다. Internet Explorer에서 도구 > 인터넷 옵션 > 연결 > LAN 설정 > 고급으로 이동합니다. 고급 탭에 프록시 서버가 나열됩니다. 다음 작업을 완료하여 명령 프롬프트에서 해당 프록시 서버를 ping합니다.

프록시 서버를 ping하고 1~2단계에 대한 왕복 시간 값(밀리초)을 측정하려면

  1. 다음 단계를 완료하여 관리자 권한 명령 프롬프트를 실행합니다.

    1. 시작을 클릭합니다.

    2. 검색 시작상자에 cmd를 입력한 다음 Ctrl+Shift+Enter를 누릅니다.

    3. 사용자 계정 컨트롤 상자가 나타나면 원하는 동작이 표시되었는지 확인한 다음 계속을 클릭합니다.

  2. ping <브라우저에서 사용하는 프록시 서버의 이름 또는 프록시 서버의 IP 주소>를 입력한 다음 Enter 키를 누릅니다. PsPing 또는 다른 도구가 설치된 경우 해당 도구를 대신 사용할 수 있습니다.

    명령은 다음 예제와 같은 형식입니다.

    • ping ourproxy.ourdomain.industry.business.com

    • ping 155.55.121.55

    • ping ourproxy

    • psping ourproxy.ourdomain.industry.business.com:80

    • psping 155.55.121.55:80

    • psping ourproxy:80

  3. 추적이 테스트 패킷 전송을 중지하면 원하는 평균 값(밀리초)이 나열된 간단한 요약이 반환됩니다. 프롬프트의 스크린샷을 만든 다음 명명 규칙에 따라 저장합니다. 이 시점에 다이어그램에 값을 입력하는 것이 도움이 될 수 있습니다.

이른 아침에 추적을 실시했을 때 클라이언트가 프록시(또는 인터넷에 연결하기 위한 송신 서버 출구)에 빠르게 도달하는 경우가 있습니다. 이 경우 숫자는 다음과 같을 수 있습니다.

클라이언트에서 프록시까지 2.8ms의 왕복 시간을 보여 주는 그래픽

클라이언트 컴퓨터가 프록시(또는 송신) 서버에 액세스할 수 있는 몇 안되는 컴퓨터 중 하나인 경우, 해당 컴퓨터에 원격으로 연결하고 여기에서 Office 365 URL에 대한 PsPing에 명령 프롬프트를 실행하여 다음 테스트 단계를 실행할 수 있습니다. 해당 컴퓨터에 액세스할 수 없는 경우 네트워크 리소스에 다음 단계에 대한 지원을 요청하여 정확한 숫자를 얻을 수 있습니다. 이러한 지원이 가능하지 않는 경우 해당 Office 365 URL에 PsPing을 수행하고 프록시 서버에 대한 PsPing 또는 Ping 시간과 비교합니다.

예를 들어, 클라이언트에서 Office 365 URL까지 51.84밀리초가 걸리고 클라이언트에서 프록시(또는 송신 지점)까지 2.8밀리초가 걸리는 경우 송신 지점에서 Office 365까지 49.04밀리초가 걸린 것입니다. 마찬가지로, 하루 중 트래픽이 가장 많은 시간에 클라이언트에서 프록시까지의 PsPing 시간이 12.25밀리초이고 클라이언트에서 Office 365 URL까지 62.01밀리초인 경우 프록시 송신 지점에서 Office 365 URL까지 평균값은 49.76밀리초입니다.

값(밀리초 단위)을 뺄 수 있도록 클라이언트에서 Office 365까지의 Ping 옆에 클라이언트에서 프록시까지의 Ping을 표시한 추가 그래픽

이러한 기준은 문제 해결 측면에서 매우 유용합니다. 예를 들어, 프록시 또는 송신 지점에서 Office 365 URL까지의 지연 시간이 일반적으로 40~59밀리초이고 클라이언트에서 프록시 또는 송신 지점까지의 지연 시간이 3~7밀리초(해당 시간 동안의 네트워크 트래픽에 따라 다름)인 경우를 가정해 보겠습니다. 여기서 클라이언트에서 프록시 또는 송신 지점까지 최근 3개의 기준이 45밀리초라면 어떤 문제가 있다는 것을 확실히 알 수 있습니다.

고급 방법

Office 365에 대한 인터넷 요청 시 어떤 상황이 발생하는지 알고 싶다면 네트워크 추적을 이해해야 합니다. 이러한 추적에는 어떤 도구를 사용해도 상관없으며 HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard를 비롯하여 네트워크 트래픽을 캡처 및 필터링할 수 있는 모든 도구를 사용할 수 있습니다. 이 섹션을 통해 문제를 더 자세히 이해하기 위해 둘 이상의 도구를 사용하는 것이 유리하다는 점을 확인할 수 있습니다. 일부 도구는 테스트 중에 자체적으로 프록시의 역할도 합니다. Office 365 성능 문제 해결 계획 안내 문서에 사용된 도구에는 Netmon 3.4, HTTPWatch 또는 WireShark가 있습니다.

성능 기준 측정은 이 방법에서 간단한 부분에 해당하며, 대부분의 단계가 성능 문제를 해결할 때 수행하는 단계와 동일합니다. 성능에 대한 기준 작성 시 고급 방법을 사용하려면 네트워크 추적을 실행하고 저장해야 합니다. 이 문서에서 소개하는 예제는 대부분 SharePoint Online을 사용하지만, 테스트 및 기록을 수행하기 위해 구독하는 Office 365 서비스 전체에서 일반적 작업 목록을 작성해야 합니다. 기준의 예는 다음과 같습니다.

  • SPO 기준 목록 - 1단계: SPO 웹 사이트의 홈 페이지를 탐색하여 네트워크 추적을 실행합니다. 추적을 저장합니다.

  • SPO 기준 목록 - 2단계: 엔터프라이즈 검색을 통해 용어(예: 회사 이름)을 검색하여 네트워크 추적을 실행합니다. 추적을 저장합니다.

  • SPO 기준 목록 3단계: SharePoint Online 문서 라이브러리에 큰 파일을 업로드하여 네트워크 추적을 실행합니다. 추적을 저장합니다.

  • SPO 기준 목록 - 4단계: OneDrive 웹 사이트의 홈 페이지를 탐색하여 네트워크 추적을 실행합니다. 추적을 저장합니다.

이 목록에는 사용자들이 SharePoint Online에서 실행하는 가장 중요하고 일반적인 작업이 포함되어야 합니다. 비즈니스용 OneDrive에 대해 추적하는 마지막 단계에서는 보통 회사에서 사용자 지정한 SharePoint Online 홈 페이지 로드와 거의 사용자 지정되지 않은 비즈니스용 OneDrive 홈 페이지를 비교합니다. 이 테스트는 SharePoint Online 사이트의 느린 로딩과 관련하여 매우 기본적인 테스트입니다. 테스트에 이 차이의 기록을 포함할 수 있습니다.

성능 문제를 겪고 있는 경우 대부분의 단계는 기준 측정의 경우와 동일합니다. 네트워크 추적의 중요성이 커지므로 다음으로 주요한 추적을 실행하는 방법을 살펴보겠습니다.

지금 성능 문제를 해결하려면 성능 문제가 발생한 당시 추적을 실행해야 합니다. 로그를 수집할 수 있는 적절한 도구와 작업 계획, 즉, 가능한 최선의 정보를 수집하기 위한 문제 해결 작업 목록이 있어야 합니다. 가장 먼저 할 일은 시간이 반영된 폴더에 파일을 저장할 수 있도록 테스트 날짜와 시간을 기록하는 것입니다. 다음으로, 문제가 발생한 단계로 범위를 좁힙니다. 이 단계는 테스트에 사용하는 단계와 정확히 동일합니다. 기본을 기억하세요. 문제가 Outlook에만 있는 경우 문제 동작이 하나의 Office 365 서비스에만 발생하는 것임을 기록해야 합니다. 이 문제의 범위를 좁히면 해결할 수 있는 사항에 집중할 수 있습니다.

참고 항목

Office 365 끝점 관리

Office 기술 확장
교육 살펴보기
새로운 기능 우선 가져오기
Office Insider 참여

이 정보가 유용한가요?

의견 주셔서 감사합니다!

피드백을 주셔서 감사합니다. Office 지원 에이전트와 연락하는 것이 도움이 될 것 같습니다.

×