최초 문서 게시일: 2012년 9월 11일 화요일

이 게시물은 Office Web Apps 선임 프로그램 관리자인 Nick Simons가 작성했습니다.

2010년 Microsoft는 Word, PowerPoint, Excel 및 OneNote의 브라우저 기반 버전인 Office Web Apps를 소개했습니다. 이러한 제품은 SharePoint 응용 프로그램 집합으로 제공됩니다. 자신의 네트워크에 Office Web Apps를 배포하려는 고객은 SharePoint 서버에 Office Web Apps를 배포했습니다.

한동안은 긴밀한 SharePoint 통합이 최적의 방법인 것처럼 여겨졌습니다. 명확히 SharePoint는 Office Web Apps의 핵심이었으며 지금도 그렇습니다. 그리고 SharePoint는 Office Web Apps와 같은 응용 프로그램의 통합에 대해 잘 정의된 모델을 갖고 있습니다. 하지만 다음 버전의 Office Web Apps 계획을 시작하면서 SharePoint와 긴밀하게 연결된 상태로는 아키텍처의 핵심 목표를 모두 달성하기 어렵다는 것이 분명하게 드러났습니다.

저희는 설치 및 용량 계획을 간소화하고 여러 팜 간의 페더레이션을 지원할 수 있기를 원했습니다. 그리고 Lync와 같은 새로운 파트너와의 통합 요청도 수용할 수 있기를 바랬습니다. 마지막으로 Office 365와 온-프레미스의 많은 고객들로부터 SkyDrive 사용자와 동일한 수준의 향상된 기능을 원한다는 요청이 있었습니다.

이러한 목표를 달성하기 위해 저희는 다시 처음으로 돌아가서 Office Web Apps가 다른 제품들과 현재 그리고 미래에 어떻게 통합되어야 하는지 다시 생각해보았습니다. 그리고 Office Web Apps를 다른 특정 파트너 기술과 구분하는 새로운 모델을 만들었습니다. 결과적으로 새로운 모델에서는 SharePoint와 같은 파일 호스트에 대한 코딩 부담을 줄이면서도 완전히 별도의 서버에서 Office Web Apps를 실행할 수 있게 되었습니다.

이렇게 새로운 독립형 서버 제품으로 만들어진 것이 바로 Office Web Apps Server입니다.

물론 단순히 또 다른 유형의 서버를 추가한다는 것이 상황을 더 복잡하게 만들고 관리자의 부담 역시 증가할 수 있다고 생각할 수 있습니다. 하지만 독립형 구조를 갖춤으로써 얻을 수 있는 이점도 있습니다.

1.  보다 간단한 설치

2.  SharePoint와 완전히 구분된 업그레이드 및 유지 관리

3.  여러 SharePoint 팜을 단일 Office Web Apps Server 팜과 통합

4.  Exchange, Lync 및 타사의 여러 제품들을 Office Web Apps와 통합

5.  본질적으로 같은 시간 내에 웹 기반 및 온-프레미스 고객들에게 새로운 기능과 향상된 기능 제공

SharePoint 2010의 이전 Office Web Apps 배포를 Office Web Apps Server를 사용한 새로운 배포와 비교하면 이점을 제대로 이해할 수 있습니다.

이전 버전의 Office에서는 일반적으로 Office Web Apps 배포가 다음과 같은 특징을 가졌습니다.

 

이전 버전의 Office Web Apps 배포

이전 버전의 Office Web Apps는 각각의 팜에, 그리고 각 팜에 포함된 각각의 컴퓨터에 설치해야 했습니다. 또한 Office Web Apps의 확장도 전체 SharePoint 확장으로 제한되었습니다. Office Web Apps를 업데이트하려면 모든 SharePoint 팜에 있는 모든 컴퓨터에서 코드를 업데이트해야 했습니다.

Office Web Apps Server에서는 다음과 같은 배포 성능을 기대할 수 있습니다.

 

Office Web Apps Server를 사용한 Office Web Apps 배포

하나의 Office Web Apps Server 팜이 여러 개의 SharePoint 2013 팜과 Lync 2013 및 Exchange 2013(Outlook Web Access)을 지원할 수 있습니다. 또한 Office Web Apps 팜을 사용하여 URL 또는 UNC 기반의 Word, Excel 및 PowerPoint 파일을 볼 수 있습니다.

새로운 통합 모델에 대한 간단 개요

다음 단락에서는 Office Web Apps가 SharePoint와 같은 파일 호스트와 어떻게 통합되는지 간단하게 설명하겠습니다. 이 문서의 정보는 이후 설명하는 네트워크 및 보안 요구 사항을 이해하는 데 도움이 될 수 있습니다.

먼저, 몇 가지 정의할 것이 있습니다.

  • Office Web Apps Server - Office Web Apps 기능을 호스트에 제공합니다. 이 문서 전체에서 설명하는 내용이기도 합니다.
  • 호스트 - Office Web Apps Server에서 제공되는 서비스를 이용해서 웹 브라우저에 파일을 표시합니다. 예를 들어 SharePoint Server 2013, Lync Server 2013 및 Exchange Server 2013과 같은 것들이 모두 호스트입니다. 
  • 클라이언트 - 브라우저 또는 기타 비슷한 소프트웨어입니다.

새로운 통합 모델의 핵심은 Office Web Apps가 호스트와 통신하기 위해 사용하는 새로운 공용 API입니다. 이 API를 WOPI(Web application Open Platform Interface)라고 부릅니다. Office Web Apps Server는 WOPI API를 사용해서 파일을 가져오고 조작합니다. Office Web Apps Server를 WOPI 응용 프로그램이라고도 부릅니다. 호스트는 WOPI 응용 프로그램의 WOPI 요청을 이해할 수 있어야 합니다.

WOPI는 HTTP/HTTPS를 사용하는 RESTful API입니다. 즉, 호스트와 Office Web Apps Server 간의 모든 트래픽이 표준 HTTP/HTTPS 포트를 통해 전송됩니다. 또한 가능한 한 Office Web Apps Server는 상태를 유지하지 않습니다(stateless). 즉, 네트워크 중단에서 완전한 하드웨어 장애까지 다양한 오류들에 대해 보다 탄력적인 운영이 가능합니다.

WOPI의 작동 방식을 이해하기 위해 간단한 시나리오를 예로 들어 보겠습니다. 이 예에서는 Sally라는 사용자가 SharePoint에 호스팅된 test.docx라는 파일을 봅니다. 어떻게 작동되는지 설명하겠습니다.

1.  Sally가 test.docx가 저장된 문서 라이브러리로 이동합니다.

2.  Sally가 문서 라이브러리에서 파일 이름을 클릭합니다.

3.  SharePoint는 브라우저를 특별한 SharePoint 페이지로 연결합니다. 이 페이지에는 Office Web Apps Server(및 기타 WOPI 응용 프로그램)에 대한 요청을 시작하는 방법이 지정되어 있습니다. 이 SharePoint 페이지를 WOPIFrame.aspx라고 합시다.

4.  WOPIFrame.aspx에는 Office Web Apps Server의 페이지로 이동시키는 iframe(http://dev.w3.org/html5/spec/the-iframe-element.html(영문일 수 있음))이 포함되어 있습니다. 이 페이지는 WordViewer.aspx입니다. WordViewer.aspx에 대한 HTTP 요청에는 몇 가지 중요한 정보가 포함되어 있습니다.

    • Office Web Apps Server가 test.docx를 가져오기 위해 사용하는 URL. 이를 WOPI 끝점이라고 합니다.
    • 파일의 이름. 실제로는 WOPI 끝점과 파일 이름을 조합하여 WOPI 원본을 호출하는 단일 매개 변수로 만듭니다.
    • Office Web Apps가 Sally의 자격 증명을 나타내는 WOPI 끝점에 전달할 수 있는 문자열. 이를 액세스 토큰이라고 부릅니다.
      보안을 위해 액세스 토큰은 Sally에게 특정 파일 하나에 대한 액세스 권한만 부여합니다. 악의적인 사용자가 액세스 토큰을 어떻게 훔쳐내더라도 해당 파일 하나에 대해서만 Sally를 가장해서 권한을 얻을 수 있습니다. 물론 그렇더라도 위험이 존재하므로 SSL을 통해 액세스 토큰을 보호하는 것이 매우 중요합니다.

5.  Office Web Apps Server가 WOPI 원본과 액세스 토큰을 사용해서 SharePoint로부터 test.docx를 가져옵니다.

6.  WordViewer.aspx는 WOPIFrame.aspx의 iframe에 test.docx를 표시합니다.

다음 그림은 브라우저, SharePoint 및 Office Web Apps Server 간의 데이터 흐름을 보여줍니다.

브라우저, SharePoint 및 Office Web Apps Server 간의 데이터 흐름

Office Web Apps Server 팜 설정

서버 팜은 공유 서버에서 실행되는 하나의 가상 컴퓨터일 수도 있고 수십 개의 데이터 센터급 서버로 구성된 팜일 수도 있습니다. 하지만 어떤 경우에든 기본 설정과 유지 관리는 모두 동일합니다. 물론 팜을 만들기 위한 정확한 사전 요구 사항과 단계는 해당 제품에 포함되어 있으므로 여기에서는 이에 대해 다시 설명하지 않습니다. 여기에서는 적정 수준에서 이와 관련된 내용에 대해 다루겠습니다.

하드웨어

먼저, 컴퓨터가 필요합니다. 예를 들어 여러 SharePoint 팜으로 80,000명의 사용자를 지원해야 하는 팜을 설정한다고 가정해보면 다음과 같은 구성의 서버가 4개 필요할 것입니다.

  • Windows Server 2008 R2 또는 Windows Server 2012 및 모든 필수 구성 요소
  • 8개 코어
  • 8GB RAM
  • 적정 크기의 하드 드라이브(60GB 이상)

부하 분산 장치도 필요합니다. Microsoft에서는 10개의 컴퓨터 팜에서 다른 여러 서버 제품들과 함께 F5 BIG-IP 하드웨어 부하 분산 장치를 공유하고 있습니다. 이러한 구성은 성능이 매우 뛰어나지만 그렇지 않더라도 적정 수준의 부하 분산 솔루션도 무방합니다. 여기에서 유일한 권장 사항은 해당 하드웨어 부하 분산 솔루션의 선호도(affinity) 지원 여부입니다. 성능 측면에서 선호도는 동일 서버로 특정 세션의 모든 요청을 처리하는 경우에 매우 중요합니다.

네트워크

여기에서는 사용자가 내부 네트워크 및 인터넷을 모두 사용해서 Office Web Apps에 액세스할 수 있어야 한다고 가정합니다. 그렇다면 팜에 대해 내부 및 외부 DNS를 모두 설정해야 합니다. 또는 외부 DNS만 설정하고 내부 DNS는 규칙을 사용해서 내부 요청을 전용 네트워크로 제한할 수도 있습니다. 여기에서는 후자의 방법을 선택합니다.
네트워크는 자신의 환경에 맞게 적절하게 설정하면 됩니다. 여기에서 필요한 사항은 다음과 같습니다.

  • 클라이언트(일반적으로 웹 브라우저)가 팜에 요청을 수행할 수 있어야 합니다. 이러한 요청은 일반적인 HTTP/HTTPS 요청이며 사용되는 포트는 각각 80 또는 443입니다.
  • Office Web Apps 팜의 컴퓨터는 파일 호스트(예: SharePoint)의 서비스에 대한 요청을 시작합니다. 이러한 요청도 포트 80 또는 443의 HTTP/HTTPS 요청입니다. 이 방식으로 Office Web Apps 컴퓨터는 자신이 렌더링하거나 편집하는 파일에서 작업을 수행합니다.
  • 일부 경우에는 파일 호스트가 부하 분산 장치를 통해 Office Web Apps Server 팜에서 직접 정보를 요청해야 합니다. 이러한 요청도 포트 80 또는 443의 HTTP/HTTPS 요청입니다.
  • Office Web Apps Server 팜의 모든 컴퓨터는 포트 809를 통해 서로 통신할 수 있어야 합니다. 이상적으로는 이러한 컴퓨터를 하나의 전용 서브넷에 두어 다른 컴퓨터가 팜에 참가하거나 트래픽을 수신할 수 없도록 하는 것이 좋습니다. 그렇지 않은 경우에는 Office Web Apps Server에 내장된 일부 기능을 통해 보다 개방된 네트워크에서 팜을 보호할 수 있습니다. 이러한 기능에 대해서는 여기에서 설명하지 않습니다. 자세한 내용은 Office Web Apps Server Preview 보안 계획을 참조하십시오.

이러한 네트워크 경로가 올바르게 설정되었는지 확인하는 것이 중요합니다. Office Web Apps는 비교적 간단하지만 통신 채널이 열려 있을 때만 작동합니다.

보안

앞에서 설명한 것처럼 파일 렌더링 또는 편집을 위한 초기 요청에는 액세스 토큰 형태의 사용자 자격 증명이 포함됩니다. 그리고 이 액세스 토큰은 Office Web Apps에서 호스트로의 모든 요청에 포함됩니다. 사용자가 개인 네트워크에 있고 이 네트워크에 액세스하는 사용자를 모두 신뢰할 수 있지 않은 한 이러한 모든 트래픽을 SSL로 보호해야 합니다. 그리고 신뢰할 수 있더라도 여전히 SSL 사용은 매우 중요합니다.
SSL 설정을 위해서는 인증서를 만들고 이를 각각의 Office Web Apps Server 컴퓨터 또는 부하 분산 장치에 두어야 합니다. 부하 분산 장치에서 SSL을 사용하지 않을 경우 Office Web Apps Server의 설정을 사용할 수 있습니다. 이에 대해서는 이후에 간단히 설명하겠습니다.

Office Web Apps Server 구성

모든 하드웨어 및 네트워크 인프라가 배치되었으므로 이제는 실제로 Office Web Apps Server 팜을 만들어보겠습니다. 먼저 Office Web Apps Server 및 해당 언어 팩을 모든 컴퓨터에 설치합니다. 컴퓨터에 다른 소프트웨어는 설치하지 마십시오. SharePoint나 Exchange 또는 어떤 것도 설치하지 마십시오. 하드웨어를 공유해야 할 경우에는 가상 컴퓨터를 사용합니다.

완료되었으면 팜의 첫 번째 컴퓨터(여기에서는 Server1이라고 가정)에서 다음과 같은 Windows PowerShell을 실행합니다. 이 Windows PowerShell에는 다음과 같이 가정합니다.

  • 외부 DNS를 URL https://officewebapps.contoso.com에서만 설정합니다. 이 URL은 원하는 대로 선택해서 설정할 수 있습니다.
  • 읽기와 보기를 모두 지원하도록 Office Web Apps Server 팜을 설정합니다.
    이 작업은 조직에 편집을 위한 적합한 라이선스가 있는 경우에만 수행합니다. 라이선스 관련 내용은 여기에서 설명하지 않지만, Office Web Apps의 경우 보기는 무료이지만 편집 기능을 사용하려면 라이선스가 필요합니다. 자세한 내용은 SharePoint 2013 Preview 제품과 함께 사용되는 Office Web Apps Preview 계획을 참조하십시오.
  • 부하 분산 장치에서 SSL을 종료합니다.

Windows PowerShell 명령은 다음과 같습니다.

New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded

이제 단일 컴퓨터로 구성된 Office Web Apps Server 팜이 설정되었습니다.

그 다음에는 Server2로 이동해서 이 서버에서 다음을 실행합니다.

New-OfficeWebAppsMachine -MachineToJoin "Server1"

이제 두 컴퓨터로 구성된 팜이 설정되었습니다. Server3 및 Server4에 대해서도 위 단계를 반복합니다.

SharePoint에 연결

이제 Office Web Apps 팜을 시작할 준비가 되었습니다. 하지만 아직은 연결된 호스트가 없습니다. SharePoint 팜을 이 Office Web Apps Server 팜에 연결하려면 SharePoint 팜의 아무 서버에서나 Windows PowerShell 명령 프롬프트를 열고 다음을 실행합니다.

New-SPWopiBinding -ServerName "officewebapps.contoso.com"

또한 다음 명령을 실행하여 Office Web Apps Server 팜의 외부 URL을 사용하고 여기에 HTTPS를 사용하도록 SharePoint 팜에 지정해야 합니다.

Set-SPWopiZone -Zone "external-https"

이제 모든 작업이 끝났습니다. SharePoint 팜의 문서 라이브러리로 이동해서 원하는 대로 Office 파일을 만들고, 보고, 편집할 수 있습니다. 추가 구성은 필요하지 않습니다.

마지막으로 SharePoint에서 Office Web Apps Server 팜 연결을 해제하려면 다음을 실행합니다.

Remove-SPWopiBinding -All

이제 SharePoint 팜의 문서 라이브러리로 이동하면 Office Web Apps에 대한 추적이 없습니다.

원하는 만큼 여러 SharePoint 팜을 단일 Office Web Apps 팜에 연결할 수 있습니다. 그리고 Exchange 및 Lync도 Office Web Apps 팜에 연결할 수 있습니다. 자세한 내용은 Exchange Server 2013: Office Web Apps Server 통합(영문일 수 있음)Office Web Apps Server 및 Lync Server 2013 배포(영문일 수 있음)를 참조하십시오.

Office Web Apps Server 업데이트

처음부터 Office Web Apps는 자주 업데이트되었습니다. 하지만 이러한 업데이트는 서비스 팩을 통해 온-프레미스 고객들에게만 제공되었습니다. Office Web Apps Server 2013을 출시한 후에는 이보다 자주 업데이트를 제공할 예정입니다. 하지만 Office Web Apps Server가 매우 간소화되었기 때문에 이렇게 업데이트가 자주 되어도 관리 측면에서 충분히 감당할 수 있을 것입니다.

Office Web Apps Server 팜에서 컴퓨터를 업데이트하려면 부하 분산 장치 및 팜에서 컴퓨터를 제거해야 합니다. 하지만 이러한 프로세스는 사용자에 대한 영향이 거의 없으므로 충분히 관리할 수 있습니다.
기본적으로 팜이 4개의 컴퓨터로 구성되어 있으므로 이 중에서 2개를 선택해서 업그레이드할 수 있습니다. 그런 다음에는 이 2개의 컴퓨터로 새 팜을 만든 후 부하 분산 장치를 원래 팜의 컴퓨터 2개 대신 업그레이드된 2개의 컴퓨터로 지정할 수 있습니다. 그런 후 남은 두 컴퓨터를 업그레이드하고 이를 새 팜에 조인시킨 후 이러한 컴퓨터에 대해서도 부하 분산 장치를 지정하면 됩니다.

컴퓨터를 팜에서 분리하면 일부 사용자에게 약간의 장애가 발생할 수 있지만 Office Web Apps가 이를 다시 복구할 수 있습니다. 단일 컴퓨터로 된 경우가 아니라면 문제 없이 복구할 수 있습니다.

Office Web Apps Server에 대한 추가 정보

Office Web Apps Server에 대한 추가 리소스는 다음 위치에서 찾을 수 있습니다.
• TechNet의 Office Web Apps Preview 라이브러리
• Exchange Server 2013: Office Web Apps Server 통합(영문일 수 있음)
• Office Web Apps Server 및 Lync Server 2013 배포(영문일 수 있음)
• Office Web Apps 설치 및 배포 포럼(영문일 수 있음)

Nick Simons
Office Web Apps 선임 프로그램 관리자

 

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Introducing Office Web Apps Server를 참조하십시오.