8월 2008 8월 2008
SQL Server: 효과적인 데이터베이스 유지 관리를 위한 유용한 팁
데이터베이스 관리자로서 제대로 교육 받지 않은 사용자들이 데이터베이스를 책임지게 되는 경우가 종종 발생합니다.이 경우 데이터베이스를 유지 관리할 수 있는 적절한 지식과 정보가 부족하여 문제가 커질 수 있습니다.이 글은 본의 아니게 DBA가 되어서 데이터베이스 유지 관리에 관한 집중 교육이 필요한 이들을 위한 입문서입니다. Paul S. Randal
Windows 관리: 서버 성능 평가
사용자들이 서버 속도가 느리다고 불평하고 있습니다. 문제를 진단하려면 어디를 살펴봐야 하는지 아십니까?PerfMon은 이를 위한 다양한 진단 기능을 제공하는 필수 도구입니다.서버 성능을 저하시킬 수 있는 일반적인 여러 병목 현상을 진단하는 데 사용되는 주요 지표를 살펴보십시오. Steven Choy
System Center: System Center Operations Manager의 Windows PowerShell
Windows PowerShell이 System Center Operations Manager 2007에 통합되어 일반적인 관리 작업을 효과적으로 수행하고 자동화할 수 있게 되었습니다.일상적인 유지 관리, 에이전트 관리 등의 작업에 OpsMgr의 Windows PowerShell을 어떻게 활용할 수 있는지 간략하게 소개합니다. Marco Shaw
인터넷 정보 서비스: ASP.NET 응용 프로그램 확장:교훈
ASP.NET 응용 프로그램을 성공적으로 확장하기 위해서는 응용 프로그램 수명 주기의 초반부터 개발자와 네트워크 관리자 간에 긴밀한 협력이 이루어지는 것이 관건입니다.응용 프로그램을 확장하는 데 어떤 요소가 필요하며 응용 프로그램이 의도한 대로 실행되게 하는 데 그러한 협력이 어떻게 기여하는지 알아보십시오. Richard Campbell
Columns
From the Editor: Tech•Ed 생중계: | Letters: 독자의 목소리: | Toolbox: IT 전문가를 위한 신제품:
SQL Q&A: 분할, 일관성 확인 및 기타: 초대형 데이터베이스에 대해 일관성 확인 및 기타 유지 관리 작업을 수행하는 방법, 실수로 수행된 업그레이드를 처리하는 방법 등 SQL Server에 관한 질문에 Paul Randal이 답변합니다.Paul S. Randal | Utility Spotlight: Windows Installer CleanUp 유틸리티: 응용 프로그램을 업데이트하거나 제거하려고 할 때 남아 있는 Windows Installer 구성 정보로 인해 문제가 발생할 수 있습니다.Windows Installer CleanUp 유틸리티를 사용하여 이 문제를 해결할 수 있습니다. 응용 프로그램의 Windows Installer 정보를 제거한 다음 응용 프로그램을 다시 설치할 때 유용한 유틸리티입니다.Lance Whitney | Inside SharePoint: 메시징 통합 문제 해결: SharePoint를 보안 메시징 환경에 통합하는 것이 간단한 작업은 아니지만, 생산성에 미치는 긍정적인 효과를 고려하면 추진해 볼 만한 프로젝트입니다.이 문서에서는 환경을 설정할 때 발생할 수 있는 문제의 해결 방법에 관한 몇 가지 지침을 제공합니다.Pav Cherny
Windows PowerShell: 버전 2.0의 원격 관리 기능 살펴보기: Windows PowerShell 2.0은 현재 개발 중이며, 최신 CTP는 여러 가지 강력한 새 기능을 제공합니다.여기서는 Windows PowerShell 2.0 CTP2의 대표적인 새 기능 중 하나인 원격 기능에 대해 살펴봅니다.Don Jones | Hey, Scripting Guy!: 전용 차선 이용: Windows Vista에서는 파일 열기 대화 상자를 여는 UserAccounts.CommonDialog ActiveX 컨트롤이 더 이상 제공되지 않습니다.여기서는 Visual Basic Express Edition을 사용하여 이 문제를 해결하는 방법을 소개합니다.Microsoft Scripting Guys | The Desktop Files: Windows 배포 서비스 101: Windows 배포 서비스의 여러 버전에 대해 알아보고, 사용자 지정 OS 이미지를 캡처하는 방법을 살펴보며, 더욱 자동화된 방식으로 설치하는 데 필요한 사항을 확인합니다.Wes Miller
Security Watch: 암호와 신용 카드 - 제2부: 총 3부로 구성된 시리즈의 두 번째 편에서 Jesper Johansson은 소프트웨어 공급업체, 보안 제품 및 마케팅 활동이 진정한 보안 활동을 어떻게 저해하는지 조명하고, 그러한 관행이 어떻게 기술 보안 생태계의 붕괴를 초래할 수 있는가도 경고합니다.Jesper M. Johansson | 지속 가능한 컴퓨팅: 그린워싱 가려내기: 소비 전력을 파악하는 일은 이제 IT 인프라 관리의 필수적인 부분이 되었습니다.환경에 전력 사용량 모니터링을 구현함으로써 전사적 범위에서 장치의 소비 전력을 더 정확하게 파악하기 위해 어떠한 전략을 구사할 수 있는지 알아봅니다.Dave Ohara | Field Notes: 세상을 구하는 IMAP: 여러 운영 체제, 여러 형식의 전자 메일이 여러 군데에 분산되어 있습니까?IMAP4.를 사용하여 한 곳에서 모든 메일에 액세스할 수 있는 방법을 Dara Korra’ti가 소개합니다.Rykandar Korrati
Windows Confidential: 과거의 유산: 한때 위용을 떨치던 Alpha AXP 시스템이 은퇴 생활을 접고 차세대 64비트 시스템 개발에 기여했던 사연을 Raymond가 소개합니다.Raymond Chen


SQL Server
효과적인 데이터베이스 유지 관리를 위한 유용한 팁
Paul S. Randal
한 눈에 보기:
  • 데이터 및 트랜잭션 로그 파일 관리
  • 인덱스 조각화 제거
  • 정확한 최신 통계 유지
  • 손상된 데이터베이스 페이지 검색
  • 효과적인 백업 전략 수립

목차
데이터 및 로그 파일 관리
인덱스 조각화
통계
손상 검색
백업
요약
한 주에 몇 번씩 프로덕션 데이터베이스를 효과적으로 유지 관리하는 방법에 대한 질문을 받곤 합니다. 때로는 새로운 솔루션을 구현하고
새로운 데이터베이스의 특성에 맞게 유지 관리 방식을 세밀하게 조정할 수 있는 방법을 물어보는 DBA도 있습니다. 하지만 전문 DBA는 아니지만 여러 가지 이유로 데이터베이스를 소유하고 책임을 맡게 된 사람들로부터 이러한 질문을 더 자주 받습니다. 이러한 역할을 담당하는 사람들을 "비자발적 DBA"라고 부르겠습니다. 이 글의 목적은 모든 비자발적 DBA를 위한 가장 좋은 데이터베이스 유지 관리 방법에 대한 입문서를 제공하는 것입니다.
IT 분야의 대부분 작업과 절차와 마찬가지로 효과적인 데이터베이스 유지 관리를 위한 하나의 규격화된 솔루션은 없지만, 어떤 솔루션에서나 몇 가지 주요 영역에서 대해서는 공통적으로 다뤄야 합니다. 가장 중요한 영역을 5개 꼽자면 다음과 같습니다. 순서는 중요도와 상관이 없습니다.
  • 데이터 및 로그 파일 관리
  • 인덱스 조각화
  • 통계
  • 손상 검색
  • 백업
제대로 관리되지 않은 데이터베이스는 이러한 영역 중 하나 이상에서 문제가 발생할 수 있으며, 이로 인해 결국 응용 프로그램 성능 저하 또는 작동 중지 및 데이터 손실로 이어질 수 있습니다.
이 글에서는 이러한 문제가 중요한 이유와, 문제를 완화할 수 있는 몇 가지 간단한 방법에 대해 설명합니다. 여기에서는 SQL Server® 2005를 기준으로 설명하지만, SQL Server 2000과 곧 발표될 SQL Server 2008에서 찾을 수 있는 주요 차이점에 대해서도 언급할 것입니다.

데이터 및 로그 파일 관리
데이터베이스에 대한 책임을 맡을 때 항상 가장 먼저 확인해야 하는 영역은 데이터 및 (트랜잭션) 로그 파일 관리와 관련된 설정입니다. 구체적으로 다음과 같은 사항을 확인해야 합니다.
  • 데이터와 로그 파일이 서로 구분되어 있으며 다른 모든 것들과 격리되어 있는가
  • 자동 증가가 올바르게 구성되었는가
  • 인스턴트 파일 초기화가 구성되었는가
  • 자동 축소가 사용되지 않으며, 축소가 유지 관리 계획의 일부가 아닌가
데이터와 로그 파일은 별도의 볼륨에 있는 것이 가장 좋으며, 파일을 생성하고 확장하는 다른 응용 프로그램과 볼륨을 공유할 경우 파일 조각화 문제가 발생할 수 있습니다. 데이터 파일의 경우 과도한 파일 조각화는 쿼리 성능 저하에 어느 정도 영향을 줄 수 있으며, 특히 대량의 데이터를 검색할 때는 더욱 그렇습니다. 로그 파일은 성능에 매우 큰 영향을 줄 수 있으며, 필요할 때 각 파일 크기가 조금씩 증가되도록 자동 증가가 설정되었을 때는 특히 그렇습니다.
로그 파일은 내부적으로 VLF(Virtual Log File)라는 섹션으로 나누어지며, 로그 파일에 조각화가 많을수록 VLF도 많아집니다. 예를 들어, 로그 파일에 200개의 VLF가 있으면 로그 읽기(트랜잭션 복제/롤백 등의 경우), 로그 백업 및 SQL Server 2000의 트리거와 같은 로그 관련 작업에 좋지 않은 영향을 줄 수 있습니다. SQL Server 2005에서는 트랜잭션 로그 대신 행 버전 관리 프레임워크로 트리거 구현이 변경되었습니다.
데이터 및 로그 파일 크기 관리와 관련하여 가장 좋은 방법은 적당한 초기 크기로 파일을 생성하는 것입니다. 데이터 파일의 경우 단기간에 걸쳐 데이터베이스에 추가될 수 있는 추가 데이터를 고려하여 초기 크기를 결정해야 합니다. 예를 들어, 데이터의 초기 크기가 50GB이지만 앞으로 6개월 동안 50GB의 데이터가 더 추가될 것이라면, 크기를 여러 번 증가시켜 해당 크기에 도달하도록 하는 것보다 지금 데이터 파일을 100GB로 생성하는 것이 좋습니다.
하지만 로그 파일의 경우에는, 트랜잭션 크기(오래 실행되는 트랜잭션은 완료될 때까지 로그에서 제거할 수 없음) 및 로그 백업 빈도(로그의 비활성 부분 제거)와 같은 요소를 고려하여 좀 더 복합적으로 결정해야 합니다. 자세한 내용은 SQLskills.com에서 인기 있는 블로그 게시물인 "8 Steps to Better Transaction Log Throughput(높은 트랜잭션 로그 처리량을 위한 8단계)"을 참조하십시오. 이 글은 제 아내인 Kimberly Tripp이 작성했습니다.
초기 크기를 설정했으면 파일 크기를 자주 모니터링하여 적절한 시점에 수동으로 사전에 크기를 증가시켜야 합니다. 자동 증가는 비정상적인 이벤트가 발생할 경우 필요에 따라 파일이 증가할 수 있도록 만약을 위한 보호 조치로 남겨 두어야 합니다. 파일 관리를 전적으로 자동 증가에 맡기는 것을 반대하는 이유는 조금씩 자동 증가가 이루어지면 파일 조각화가 발생하고, 자동 증가는 예기치 않은 시점에 응용 프로그램 작업을 지연시키는 시간 소비 프로세스가 될 수 있기 때문입니다.
자동 증가 크기는 백분율이 아닌 특정 값으로 설정하여 자동 증가가 실행되는 데 필요한 시간과 공간을 제한해야 합니다. 100GB 데이터 파일을 예로 들 경우, 10%가 아닌 5GB의 고정된 자동 증가 크기로 설정하는 것이 좋습니다. 이렇게 설정하면 파일이 커질 때마다 용량이 10GB, 11GB, 12GB 등으로 계속 증가하는 대신 최종 파일 크기가 어떻게 되든지 항상 5GB씩 증가하게 됩니다.
트랜잭션 로그는 수동 또는 자동 증가를 통해 커지면 항상 0으로 초기화됩니다. 데이터 파일은 SQL Server 2000에서 동일한 기본 동작으로 수행되지만, SQL Server 2005부터는 파일을 0으로 초기화하는 작업을 생략하고 증가 및 자동 증가를 즉시 실행하는 인스턴트 파일 초기화를 사용할 수 있습니다. 대부분의 예상과 달리 이 기능은 모든 SQL Server 에디션에서 사용할 수 있습니다. 자세한 내용을 보려면 SQL Server 2005 또는 SQL Server 2008의 온라인 설명서 색인에서 "인스턴트 파일 초기화"를 찾아 보십시오.
마지막으로 축소는 어떠한 경우에도 사용하지 않도록 해야 합니다. 축소는 데이터나 로그 파일의 크기를 줄이는 데 사용할 수 있지만 리소스를 많이 사용하는 동시에 매우 비효과적인 프로세스로서, 데이터 파일의 논리 검색 조각화의 양이 크게 늘어나고(아래 참조) 성능 저하로 이어질 수 있습니다. SQL Server 2005 온라인 설명서의 축소 항목에는 이러한 취지의 경고가 포함되어 있습니다. 하지만 특수한 경우 개별 데이터 및 로그 파일을 수동으로 축소하는 것은 괜찮습니다.
비디오
Paul Randal의 데모를 통해 축소 및 자동 축소가 데이터베이스에 얼마나 심각한 조각화 문제를 일으킬 수 있는지 살펴보십시오.

자동 축소는 백그라운드에서 30분마다 실행되어 데이터베이스 자동 축소 옵션이 설정된 데이터베이스를 축소하려고 시도하는 가장 좋지 않은 기능입니다. 자동 축소는 여유 공간이 25% 이상인 데이터베이스만 축소한다는 점에서 예측이 불가능한 프로세스라고 볼 수 있습니다. 자동 축소는 리소스를 많이 사용하고 성능 저하 조각화를 유발하므로 거의 모든 환경에서 현명한 계획이 아닙니다. 따라서 자동 축소를 사용하지 않도록 설정해야 하며 그와 함께 다음 사항도 고려해야 합니다.
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
정기적인 유지 관리 계획에 수동 데이터베이스 축소 명령을 포함시키는 것도 좋지 않습니다. 유지 관리 계획을 통해 데이터베이스가 축소된 후 데이터베이스가 계속해서 증가한다면 데이터베이스에 그만큼 실행할 공간이 필요하기 때문입니다.
가장 좋은 방법은 데이터베이스가 안정적인 상태의 크기로 증가하도록 두고 축소가 실행되지 않도록 하는 것입니다. 축소를 사용하는 데이터베이스에 대한 추가 정보 및 SQL Server 2005의 새로운 알고리즘에 대한 설명은 이전 MSDN® 블로그 blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx를 참조하십시오.

인덱스 조각화
파일 시스템 수준 및 로그 파일 내에서의 조각화와 별도로 테이블 및 인덱스 데이터를 저장하는 구조의 데이터 파일 내에서도 조각화가 발생할 수 있습니다. 데이터 파일 내에서 발생할 수 있는 조각화에는 다음 두 가지 기본 유형이 있습니다.
  • 개별 데이터 및 인덱스 페이지 내의 조각화(내부 조각화)
  • 페이지를 구성하는 인덱스 또는 테이블 구조 내의 조각화(논리 검색 조각화 및 익스텐트 검색 조각화)
내부 조각화는 페이지에 빈 공간이 많이 있는 경우입니다. 그림 1과 같이 데이터베이스에서 각 페이지의 크기는 8KB이고 96바이트의 페이지 헤더가 있으므로 한 페이지는 약 8096바이트의 테이블 또는 인덱스 데이터를 저장할 수 있습니다. 데이터 및 행 구조에 대한 특정 테이블 및 인덱스 내부는 제가 작성한 Inside The Storage Engine 범주의 블로그 sqlskills.com/blogs/paul을 참조하십시오. 각 테이블 또는 인덱스 레코드가 페이지 크기의 절반을 초과하면 페이지당 단일 레코드만 저장할 수 있으므로 빈 공간이 발생할 수 있습니다. 이 경우 인덱스 키를 GUID와 같이 임의의 삽입 지점을 유발하지 않는 것으로 변경하는 등 테이블 또는 인덱스 스키마 변경이 필요하므로 수정하기가 매우 어렵거나 불가능합니다.
그림 1 데이터베이스 페이지의 구조(크게 보려면 이미지 클릭)
일반적으로 내부 조각화는 삽입, 업데이트 및 삭제와 같이 페이지에 빈 공간을 남길 수 있는 데이터 수정으로 인해 많이 발생합니다. 채우기 비율을 잘못 관리할 경우에도 조각화를 유발할 수 있습니다. 자세한 내용은 온라인 설명서를 참조하십시오. 테이블/인덱스 스키마 및 응용 프로그램의 특성에 따라 이 빈 공간은 일단 만들어지면 재사용하지 못할 수 있으며, 데이터베이스에서 계속 증가하는 사용 불가능한 공간으로 남을 수 있습니다.
평균 레코드 크기가 400바이트인 1억 개의 행 테이블을 예로 들어 보겠습니다. 시간이 지남에 따라 응용 프로그램의 데이터 수정 패턴에 따라 각 페이지에는 평균 2800바이트의 여유 공간이 남게 됩니다. 테이블에서 필요한 총 공간은 약 59GB입니다. 8096-2800 / 400 = 13레코드(8KB 페이지당)이고 1억을 13으로 나누면 페이지 수가 계산됩니다. 공간이 낭비되지 않는다면 페이지당 20개의 레코드가 들어가므로 필요한 총 공간은 38GB로 줄어듭니다. 많이 절약된다는 것을 알 수 있습니다.
이렇게 데이터/인덱스 페이지에서 낭비된 공간으로 인해 동일한 양의 데이터를 보관하기 위한 더 많은 페이지가 필요하게 됩니다. 결과적으로 더 많은 디스크 공간을 사용할 뿐만 아니라, 쿼리에서 동일한 양의 데이터를 읽기 위해 더 많은 I/O가 필요합니다. 그리고 이러한 모든 추가 페이지는 데이터 캐시에서 더 많은 공간을 차지하므로 서버 비용이 늘어납니다.
논리 검색 조각화의 원인은 페이지 분할이라는 작업입니다. 논리 검색 조각화는 인덱스 키 정의에 따라 레코드를 특정 인덱스 페이지에 삽입해야 하는데 해당 페이지에 데이터를 삽입할 충분한 공간이 없을 경우에 발생합니다. 페이지는 반으로 분할되고 레코드의 약 50%가 새로 할당된 페이지로 이동합니다. 이 새 페이지는 대개 이전 페이지와 물리적으로 연속되어 있지 않으므로 조각화되었다고 말합니다. 익스텐트 검색 조각화는 개념적으로 유사합니다. 테이블/인덱스 구조 내의 조각화는 전체 테이블/인덱스 또는 WHERE 절 쿼리(예: SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000)로 제한된 테이블/인덱스에 대해 SQL Server에서 효율적인 검색을 수행할 수 있는 능력에 영향을 줍니다.
그림 2는 새로 생성되어 채우기 비율이 100%이고 조각화가 없는 인덱스 페이지를 보여 줍니다. 이 페이지는 가득 차 있으며 페이지의 물리적 순서가 논리적 순서와 일치합니다. 그림 3은 무작위 삽입/업데이트/삭제 후 발생할 수 있는 조각화를 보여 줍니다.
그림 2 새로 생성되어 조각화가 없는 인덱스 페이지, 채우기 비율이 100%인 페이지(크게 보려면 이미지 클릭)
그림 3 무작위 삽입, 업데이트 및 삭제 후 내부 및 논리 검색 조각화가 발생한 인덱스 페이지(크게 보려면 이미지 클릭)
경우에 따라 테이블/인덱스 스키마를 변경하여 조각화를 막을 수도 있지만, 위에서 언급한 대로 이 작업은 매우 어렵거나 불가능합니다. 이러한 작업이 불가능한 경우 인덱스 재작성이나 재구성 등으로 이미 발생한 조각화를 제거하는 방법을 사용할 수 있습니다.
인덱스 재작성은 제대로 압축되고 최대한 연속된 새 인덱스 복사본을 만든 후 이전의 조각화된 인덱스를 삭제하는 작업입니다. SQL Server에서는 이전 인덱스를 제거하기 전에 새 인덱스 복사본을 만들므로 데이터 파일에 인덱스 크기에 해당하는 여유 공간이 있어야 합니다. SQL Server 2000에서는 인덱스 재작성 작업이 항상 오프라인으로 수행되었습니다. 하지만 SQL Server 2005 Enterprise Edition에서는 몇 가지 제한 사항이 있지만 온라인으로 수행할 수 있습니다. 반면, 재구성 작업은 기본 알고리즘을 사용하여 인덱스를 압축하고 조각 모음을 수행합니다. 실행할 추가 공간은 8KB만 필요하며 항상 온라인으로 실행됩니다. 실제로 SQL Server 2000에서 저는 인덱스 재작성의 공간 효율적인 대안으로 인덱스 재구성 코드를 온라인으로 수행하도록 작성했습니다.
SQL Server 2005에서 검토할 명령은 인덱스 재작성을 위한 ALTER INDEX … REBUILD 명령과 인덱스 재구성을 위한 ALTER INDEX … REORGANIZE 명령입니다. 이 구문은 SQL Server 2000 명령 DBCC DBREINDEX와 DBCC INDEXDEFRAG를 각각 대체합니다.
이러한 방식 간에는 생성되는 트랜잭션 로깅의 양, 데이터베이스에 필요한 여유 공간의 양, 프로세스를 작업 손실 없이 중단 가능한지 여부 등 많은 장단점이 있습니다. 이러한 장단점과 추가 정보에 대한 백서는 microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx에서 찾아 볼 수 있습니다. 이 문서는 SQL Server 2000을 기준으로 하지만 원리와 개념은 이후 버전에도 적용됩니다.
일부 사용자들은 어떤 인덱스가 조각화되며 조각화 제거를 통해 이점을 얻을 수 있는지에 대해 생각하지도 않고, 유지 관리 계획 옵션 등을 사용하여 매일 밤 또는 매주 모든 인덱스를 재작성하거나 재구성하기도 합니다. 최소의 노력으로 정상적인 상태를 유지하려는 비자발적 DBA에게는 이 방법이 좋은 솔루션이 될 수 있지만, 리소스가 중요시되는 대규모 데이터베이스나 시스템의 경우에는 현명한 선택이 아닐 수 있습니다.
좀더 정교한 방법은 DMV sys.dm_db_index_physical_stats(또는 SQL Server 2000의 DBCC SHOWCONTIG)를 사용하여 어떤 인덱스가 조각화되었는지 정기적으로 확인하고 작업 수행 여부 및 방법을 선택하는 것입니다. 백서에서는 이러한 경우 선택할 수 있는 방법에 대해서도 설명합니다. 또한 SQL Server 2005의 DMV sys.dm_db_index_physical_stats에 대한 온라인 설명서 항목의 예제 D(msdn.microsoft.com/library/ms188917) 또는 SQL Server 2000 이상의 DBCC SHOWCONTIG에 대한 온라인 설명서 항목의 예제 E(at msdn.microsoft.com/library/aa258803)에서 이 필터링을 수행할 수 있는 몇 가지 예제 코드를 참조할 수 있습니다.
어떤 방법을 사용하든지 간에 정기적으로 조각화를 검사하고 수정하는 것이 좋습니다.
쿼리 프로세서는 SQL Server에서 사용할 테이블과 인덱스 및 결과를 얻기 위해 수행할 작업 등과 같이 쿼리를 실행하기 위한 방법, 즉 쿼리 계획을 결정하는 부분입니다. 이러한 결정 프로세스에서 고려해야 할 가장 중요한 사항 중 하나는 테이블이나 인덱스 내에서 열에 대한 데이터 값의 분포를 설명하는 통계입니다. 통계는 쿼리 프로세스에 유용하도록 반드시 정확하고 최신이어야 하며, 그렇지 않으면 좋지 않은 쿼리 계획이 선택될 수 있습니다.
통계는 테이블/인덱스 데이터를 읽고 관련 열에 대한 데이터 분포를 확인하여 생성됩니다. 특정 열에 대한 모든 데이터 값을 검색하는 전체 검색으로 통계를 작성할 수도 있고, 사용자가 지정한 데이터의 비율(샘플링 검색)을 기준으로 작성할 수도 있습니다. 열에서 값의 분포가 균일할 경우 샘플링 검색이 적합하며, 이 경우 전체 검색보다 통계 생성 및 업데이트 속도가 더 빠릅니다.
그림 4와 같이 AUTO_CREATE_STATISTICS 및 AUTO_UPDATE_STATISTICS 데이터베이스 옵션을 설정하면 통계를 자동으로 생성하고 유지 관리할 수 있습니다. 이러한 옵션은 기본적으로 설정되어 있지만, 데이터베이스를 상속 받은 경우 확인해 두는 것이 좋습니다. 경우에 따라 통계가 최신이 아닐 수 있는데, 이 경우 특정 통계에 대해 UPDATE STATISTICS 작업을 사용하여 수동으로 업데이트할 수 있습니다. 또는 최신이 아닌 모든 통계를 업데이트하는 sp_updatestats 저장 프로시저를 사용할 수도 있습니다. SQL Server 2000에서 sp_updatestats는 최신 여부와 상관 없이 모든 통계를 업데이트합니다.
그림 4 SQL Server Management Studio를 통해 데이터베이스 설정 변경(크게 보려면 이미지 클릭)
정기적인 유지 관리 계획의 일부로 통계를 업데이트하려는 경우 알아 두어야 할 사항이 있습니다. UPDATE STATISTICS 및 sp_updatestats 명령은 이전에 지정된 샘플링 수준이 있는 경우 기본적으로 이 수준을 사용하며, 전체 검색보다 비용이 적게 듭니다. 인덱스 재작성은 전체 검색을 사용하여 통계를 자동으로 업데이트합니다. 인덱스 재작성 후 수동으로 통계를 업데이트할 경우 통계의 정확성이 낮아질 수 있습니다! 수동 업데이트의 샘플링 검색이 인덱스 재작성으로 생성된 전체 검색을 덮어쓸 경우 이와 같은 현상이 발생합니다. 반면, 인덱스 재구성은 통계를 전혀 업데이트하지 않습니다.
다시 말해서, 전체 인덱스 재작성 전이나 후의 어느 시점에 모든 통계를 업데이트하는 유지 관리 계획을 사용하는 사용자들이 많은데 이 경우 자신도 모르게 통계의 정확성이 낮아질 수 있습니다. 모든 인덱스를 자주 재작성하도록 선택할 경우 통계도 영향을 받습니다. 조각화 제거를 사용하는 좀더 복잡한 경로를 거치도록 선택하는 경우 통계 유지 관리에 대해서도 신경을 써야 합니다. 다음은 제가 제안하는 방법입니다.
  • 인덱스를 분석하여 작업 대상 인덱스와 조각화 제거를 수행할 방법을 결정합니다.
  • 재작성되지 않은 모든 인덱스에 대해 통계를 업데이트합니다.
  • 인덱싱되지 않은 모든 열에 대한 통계를 업데이트합니다.
통계에 대한 자세한 내용은 "Microsoft® SQL Server 2005의 쿼리 최적화 프로그램에서 사용하는 통계" 백서(microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)를 참조하십시오.

손상 검색
지금까지 성능 측면에서 유지 관리에 대해 설명했습니다. 이제 주제를 바꾸어 손상 검색 및 완화에 대해 다뤄 보겠습니다.
여러분이 관리하고 있는 데이터베이스에는 어느 정도 중요한 정보가 들어 있을 것입니다. 이러한 정보를 위해 데이터가 손상되지 않고 재해 발생 시 복구할 수 있도록 해야 합니다. 여기서는 전체 재해 복구 및 고가용성 전략에 대한 구체적인 내용은 다루지 않지만 이를 위해 시작할 수 있는 몇 가지 간단한 사항을 알려 드리겠습니다.
대부분의 손상은 "하드웨어"로 인해 발생합니다. 왜 "하드웨어"라고 강조했을까요? 여기서 하드웨어는 "SQL Server 아래의 I/O 하위 시스템에 있는 것"을 말합니다. I/O 하위 시스템은 운영 체제, 파일 시스템 드라이버, 장치 드라이버, RAID 컨트롤러, 케이블, 네트워크 및 실제 디스크 드라이브와 같은 요소로 구성됩니다. 이러한 위치에서 많은 문제가 발생할 수 있습니다.
가장 많이 발생하는 문제 중 하나는 디스크 드라이브에서 데이터베이스 페이지를 쓰고 있을 때 전원 문제가 발생하는 경우입니다. 전원이 나가기 전에 드라이브에서 쓰기를 완료할 수 없는 경우 또는 쓰기 작업이 캐시에 저장되는데 드라이브의 캐시를 비울 수 있는 충분한 배터리 백업이 없는 경우 디스크에 불완전한 페이지 이미지가 남게 됩니다. 8KB 데이터베이스 페이지는 실제로 16개의 연속된 512바이트 디스크 섹터로 구성되기 때문에 이와 같은 문제가 발생합니다. 불완전한 쓰기의 경우 새 페이지의 일부 섹터가 쓰여졌지만 이전 페이지 이미지의 일부 섹터는 남아 있습니다. 이러한 상황을 조각난 페이지라고 합니다. 이러한 상황을 어떻게 검색할 수 있을까요?
SQL Server에는 이러한 상황을 검색할 수 있는 메커니즘이 있습니다. 즉, 페이지의 모든 섹터에서 2비트를 저장해 두고 특정 패턴을 이 위치에 씁니다. 이 작업은 페이지가 디스크에 쓰여지기 바로 전에 수행됩니다. 페이지를 읽을 때 패턴이 동일하지 않으면 SQL Server에서 페이지가 조각났음을 알고 오류를 발생시킵니다.
SQL Server 2005 이상부터는 페이지 체크섬이라는 좀 더 포괄적인 메커니즘을 사용하여 페이지의 손상을 검색할 수 있습니다. 즉, 페이지를 쓰기 바로 전에 페이지에 전체 페이지 체크섬을 작성한 다음 조각난 페이지 검색과 마찬가지로 페이지를 읽을 때 테스트합니다. 페이지 체크섬을 사용하도록 설정하면 페이지를 버퍼 풀로 읽어와 일정하게 변경한 후 다시 디스크에 쓰고 페이지 체크섬으로 보호해야 합니다.
따라서 SQL Server 2000에서는 조각난 페이지 검색을, SQL Server 2005 이상에서는 페이지 체크섬을 사용하도록 설정하는 것이 좋습니다. 페이지 체크섬을 사용하려면 다음과 같이 하십시오.
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
SQL Server 2000의 경우 조각난 페이지 검색을 사용하려면 다음과 같이 하십시오.
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
이러한 메커니즘을 사용하면 페이지를 읽을 때만 페이지가 손상되었는지 확인할 수 있습니다. 어떻게 하면 할당된 모든 페이지를 손쉽게 읽을 수 있을까요? 이를 위한 가장 좋은 방법 그리고 다른 종류의 손상을 찾을 수 있는 방법은 DBCC CHECKDB 명령을 사용하는 것입니다. 이 명령은 지정된 옵션과 상관없이 항상 데이터베이스의 모든 페이지를 읽으므로 페이지 체크섬 또는 조각난 페이지 검색을 수행합니다. 또한 쿼리를 실행할 때 사용자가 손상 문제를 발견할 경우 알 수 있도록 경고를 설정해야 합니다. 심각도 24 경고를 사용하면 위에서 설명한 모든 문제에 대해 통지를 받을 수 있습니다(그림 5).
그림 5 모든 심각도 24 오류에 대한 경고 설정(크게 보려면 이미지 클릭)
따라서 또 하나의 좋은 방법은 데이터베이스에 대해 정기적으로 DBCC CHECKDB를 실행하여 무결성을 확인하는 것입니다. 이 명령의 다양한 변형이 존재하며 이 명령을 실행하는 간격에 대한 많은 의견이 있습니다. 애석하게도 아직 이 문제에 대한 백서는 없습니다. 하지만 DBCC CHECKDB는 제가 SQL Server 2005에 대해 작성한 코드의 중요한 부분을 차지하므로 이와 관련하여 블로그에 포괄적으로 작성해 놓았습니다. 제 블로그(sqlskills.com/blogs/paul)의 "CHECKDB From Every Angle" 범주에서 일관성 검사와 권잘 절차 및 사용 방법에 대한 심도 높은 다양한 자료를 참조할 수 있습니다. 비자발적 DBA의 경우 가장 좋은 방법은 전체 데이터베이스 백업(아래 참조)을 수행할 때마다 DBCC CHECKDB를 실행하는 것입니다. 다음 명령을 실행할 것을 권장합니다.
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
이 명령을 실행하여 결과가 출력되면 DBCC가 데이터베이스에서 손상을 발견한 것입니다. 그렇다면 문제는 DBCC CHECKDB로 손상이 발견될 경우 어떻게 하느냐는 것입니다. 그래서 백업이 필요한 것입니다.
손상이나 기타 재해가 발생할 경우 복구할 수 있는 가장 효과적인 방법은 백업으로 데이터베이스를 복원하는 것입니다. 여기에서는 백업을 보유하고 있으며 백업 자체는 손상되지 않았다고 가정합니다. 많은 사용자들은 백업이 없을 때 심하게 손상된 데이터베이스를 다시 실행하려면 어떻게 해야 하는지에 대해 묻곤 합니다. 간단히 답하면, 어떤 형태로든 비즈니스 로직과 관계형 데이터 무결성에 큰 위험 요소가 될 수 있는 데이터 손실을 감수하지 않고서는 불가능합니다.
따라서 정기적인 백업을 수행하는 것이 무엇보다 중요합니다. 백업 및 복원을 사용하는 구체적인 방법은 이 문서의 범위에서 벗어나지만, 백업 전략을 수립하는 방법에 대해 간략하게 설명하겠습니다.
첫째, 정기적으로 전체 데이터베이스 백업을 수행해야 합니다. 그러면 나중에 어떤 특정 시점에서 복원할 수 있습니다. 전체 데이터베이스 백업은 BACKUP DATABASE 명령을 사용하여 수행할 수 있습니다. 예제는 온라인 설명서를 참조하십시오. 추가로 보호하기 위해 WITH CHECKSUM 옵션을 사용할 수 있습니다. 이 옵션은 읽는 페이지의 페이지 체크섬이 있는 경우 이 체크섬의 유효성을 검사하고 전체 백업에 대해 체크섬을 계산합니다. 업무상 손실을 감당할 수 있는 데이터 또는 작업의 양을 고려하여 백업 빈도를 선택해야 합니다. 예를 들어, 하루에 한 번 전체 데이터베이스 백업을 수행할 경우 재해 발생 시 최대 하루 분량의 데이터를 잃을 수 있습니다. 전체 데이터베이스 백업만 사용할 경우 트랜잭션 로그 증가 관리와 관련된 복잡성을 피하기 위해 SIMPLE 복구 모델(일반적으로 복구 모드라고 함)을 사용해야 합니다.
둘째, 백업이 손상될 것을 대비하여 며칠 동안의 백업을 보관해 둡니다. 며칠 전의 백업은 백업이 전혀 없는 것보다 낫습니다. 또한 RESTORE WITH VERIFYONLY 명령을 사용하여 백업의 무결성을 확인해야 합니다. 자세한 내용은 온라인 설명서를 참조하십시오. 백업을 만들 때 WITH CHECKSUM 옵션을 사용한 경우 유효성 검사 명령을 실행하면 백업 체크섬이 유효한지 확인하고, 백업 내 페이지의 모든 페이지 체크섬을 다시 확인합니다.
셋째, 매일 전체 데이터베이스를 백업해도 문제 발생 시 데이터/작업 손실이 업무상 감당할 수 있는 범위를 초과한다면 차등 데이터베이스 백업을 사용해 볼 수 있습니다. 차등 데이터베이스 백업은 전체 데이터베이스 백업을 기준으로 하며, 마지막 전체 데이터베이스 백업 이후의 모든 변경 레코드를 포함합니다. 일반적으로 차등 백업과 증분 백업을 동일한 것으로 알고 있는데 그렇지 않습니다. 예를 들어, 4시간마다 차등 데이터베이스 백업과 함께 매일 전체 데이터베이스 백업을 수행할 수 있습니다. 차등 백업은 하나의 특정 시점 복구 옵션을 추가로 제공합니다. 전체 데이터베이스 및 차등 데이터베이스 백업만 사용하는 경우에도 SIMPLE 복구 모델을 사용해야 합니다.
복구에서 가장 마지막 방법은 로그 백업을 사용하는 것입니다. 로그 백업은 FULL(또는 BULK_LOGGED) 복구 모델에서만 사용할 수 있으며 이전 로그 백업 이후 생성된 모든 로그 레코드의 백업을 제공합니다. 전체 데이터베이스 그리고 경우에 따라 차등 데이터베이스의 정기 백업과 함께 로그 백업을 유지 관리하면 최근 몇 분 전으로의 복구를 포함하여 복구 가능한 특정 시점 수에 제한이 없습니다. 단점은 로그 백업을 수행하여 공간을 확보하지 않으면 트랜잭션 로그가 계속 증가한다는 것입니다. 예를 들어, 매일 전체 데이터베이스 백업, 4시간마다 차등 데이터베이스 백업 그리고 12시간마다 로그 백업을 수행할 수 있습니다.
백업 전략 및 설정 방법을 결정하는 일은 복잡할 수 있습니다. 적어도 정기적인 전체 데이터베이스 백업을 통해 복구 가능한 특정 시점을 최소한 하나 이상 보유하고 있어야 합니다.
이와 같이 데이터베이스의 무결성과 가용성을 유지하려면 반드시 해야 할 몇 가지 작업이 있습니다. 다음은 데이터베이스에 대한 책임을 맡은 비자발적 DBA가 수행해야 할 최종 확인 목록입니다.
  • 과도한 트랜잭션 로그 파일 조각화를 제거합니다.
  • 자동 증가를 올바르게 설정합니다.
  • 예약된 축소 작업을 취소합니다.
  • 인스턴트 파일 초기화를 설정합니다.
  • 인덱스 조각화를 검색하고 제거하기 위한 정기적인 프로세스를 수행합니다.
  • AUTO_CREATE_STATISTICS 및 AUTO_UPDATE_STATISTICS를 설정하고, 통계를 업데이트하기 위한 정기적인 프로세스를 수행합니다.
  • 페이지 체크섬(SQL Server 2000의 경우 조각난 페이지 검색)을 설정합니다.
  • DBCC CHECKDB를 실행하기 위한 정기적인 프로세스를 수행합니다.
  • 특정 지점 복구를 위해 전체 데이터베이스 백업, 차등 및 로그 백업에 대한 정기적인 프로세스를 수행합니다.
이 글에서는 T-SQL 명령을 사용했지만 Management Studio에서도 많은 작업을 수행할 수 있습니다. 이 글이 효과적인 데이터베이스 유지 관리를 위한 유용한 정보가 되기를 바랍니다. 의견이나 질문은 paul@sqlskills.com으로 보내 주십시오.

Paul S. Randal은 SQLskills.com의 관리 이사 겸 SQL Server MVP이며, 1999년부터 2007년까지 Microsoft의 SQL Server 저장소 엔진 팀에서 근무했습니다. Paul 이사는 재해 복구, 고가용성 및 데이터베이스 유지 관리 분야의 전문가입니다. 블로그 주소는 SQLskills.com/blogs/paul입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다.


Windows 관리
서버 성능 평가
Steven Choy
한 눈에 보기:
  • 성능 모니터 사용자 지정
  • 측정 항목 및 주기 안내
  • 주요 카운터 및 평가 대상 개요

목차
더욱 신뢰할 수 있는 결과 생성
측정 대상 및 시기
하드 디스크 병목 현상
메모리 병목 현상
﻿프로세서 병목 현상
네트워크 병목 현상
프로세스 병목 현상
요약
월요일 아침에 출근했더니 한 직원이 서버 속도가 너무 느리다고 불평을 합니다. 이를 위해 무엇부터 시작하시겠습니까? 성능
모니터는 Windows®에 기본적으로 포함되어 있는 편리한 도구로서, 문제를 진단하도록 도와 줍니다.
성능 모니터는 명령 프롬프트에서 perfmon을 입력하거나 관리 도구 메뉴에서 성능 또는 안정성 및 성능 모니터(Windows Vista® 및 Windows Server® 2008의 경우)를 선택하여 열 수 있습니다. 모니터링할 성능 카운터 및 개체를 추가하려면 더하기 기호를 클릭하고 선택 가능한 항목 중에서 선택하기만 하면 됩니다.
그렇다면 서버의 성능을 어떻게 측정하겠습니까? 60개 이상의 기본 성능 개체가 있으며, 각 개체에는 여러 카운터가 포함되어 있습니다. 이 문서에서는 서버의 중요한 상태를 나타내는 카운터를 소개하고, Microsoft® Service Support 엔지니어가 성능 관련 문제를 해결하는 데 가장 많이 사용하는 일반적인 샘플링 간격에 대해 설명합니다.
물론 기준은 문제 해결 시 참조할 수 있는 참조 포인트를 제공합니다. 서버 부하는 업무 요구 사항에 따라 달라지고 업무 주기별 시간마다 바뀌므로 일정 기간 동안 표준 작업 부하로 결정된 기준을 설정하는 것이 중요합니다. 이를 통해 변동 사항을 주시하고 추세를 파악할 수 있습니다.

더욱 신뢰할 수 있는 결과 생성
서버의 중요한 상태를 나타내는 카운터를 본격적으로 설명하기 전에 성능 모니터를 사용하여 서버의 주요 상태를 쉽게 측정할 수 있는 두 가지 팁을 소개하겠습니다. 이러한 팁은 Windows Vista 및 Windows Server 2008에서는 필요하지 않지만, 이전 버전의 Windows에서 성능 모니터를 실행하는 경우 매우 유용할 수 있습니다.
첫째, 추세 선의 그래픽 보기를 방해하는 모든 샘플 요소를 제거할 수 있습니다. Windows Vista 및 Windows Server 2008의 경우 성능 모니터는 그래픽 보기에 최대 1000개의 데이터 포인트를 표시할 수 있습니다. 이전 버전의 Windows에서는 최대 100개의 데이터 포인트로 제한됩니다. 100개가 넘는 데이터가 있을 경우 성능 모니터는 데이터 포인트를 버킷화합니다. 하나의 버킷은 버킷에 포함된 샘플 포인트의 최소값, 평균 및 최대값을 나타내는 수직선으로 표시됩니다.
그림 1의 그래프를 보면 알 수 있듯이 너무 많은 데이터가 동시에 표시되면 추세 선을 파악하기가 어렵습니다. 그림 2 그래프는 불필요한 모든 시각적 정보를 없앨 경우 얼마나 간편하고 쉽게 데이터를 파악할 수 있는지를 보여 줍니다. 이러한 수직선이 표시되지 않도록 하는 방법에 대한 자세한 내용은 support.microsoft.com/kb/283110 기술 자료 문서를 참조하십시오.
그림 1 쉼표 없이 산만한 버킷으로 표시된 성능 데이터(크게 보려면 이미지 클릭)
그림 2 쉼표로 구분되어 보기 좋은 데이터(크게 보려면 이미지 클릭)
두 번째 팁은 숫자에 쉼표 구분 기호를 추가하여 카운터에 표시된 값을 더 쉽게 읽을 수 있도록 하는 것입니다. Windows Vista 및 Windows Server 2008에서는 기본적으로 쉼표 구분 기호가 사용됩니다. 하지만 이전 버전의 Windows의 경우 성능 모니터에서 기본적으로 쉼표를 사용하지 않습니다.
별다른 차이가 없을 것처럼 느껴지지만, 쉼표 없이 성능 카운터를 표시하는 그림 1과 쉼표를 사용하여 카운터를 표시하는 그림 2를 비교해 보십시오. 두 번째 그림이 더 읽기 쉽다는 것을 알 수 있습니다. Windows XP에서 성능 카운터에 쉼표 구분 기호를 추가하는 방법은 support.microsoft.com/kb/300884 기술 자료 문서를 참조하십시오.

측정 대상 및 시기
리소스가 한도에 도달할 경우 전체 시스템 성능이 느려질 수 있는 병목 현상이 발생합니다. 병목 현상은 대체로 리소스 부족이나 잘못된 구성, 구성 요소 오작동 및 리소스에 대한 프로그램의 잘못된 요청 등으로 인해 발생합니다.
병목 현상을 유발하고 서버 성능에 영향을 줄 수 있는 주요 리소스 영역은 물리적 디스크, 메모리, 프로세스, CPU, 네트워크 등의 5가지입니다. 이러한 리소스가 과도하게 사용되면 서버 또는 응용 프로그램이 현저하게 느려지거나 충돌이 발생할 수 있습니다. 이 문서에서는 이러한 5가지의 각 영역에서 사용해야 하는 카운터에 대해 소개하고 서버의 상태를 측정하는 데 권장되는 임계값을 제공합니다.
샘플링 간격은 로그 파일의 크기 및 서버 부하에 많은 영향을 주므로, 문제가 다시 발생하기 전에 기준을 설정할 수 있도록 문제가 발생하는 데 걸리는 평균 기간을 기준으로 샘플 간격을 설정해야 합니다. 그러면 문제로 이어지는 경향을 파악할 수 있습니다.
일반적인 작업 중 기준을 설정하기 위한 권장 시간은 15분입니다. 문제가 발생하는 데 걸리는 평균 시간이 약 4시간이라면 샘플 간격을 15초로 설정합니다. 문제가 발생하는 데 걸리는 시간이 8시간 이상이라면 샘플링 간격을 5분 이상으로 설정합니다. 그렇지 않으면 로그 파일이 너무 커져서 데이터를 분석하는 데 어려울 수 있습니다.

하드 디스크 병목 현상
디스크 시스템은 서버에서 프로그램 및 데이터를 저장하고 처리하므로 디스크 사용량 및 속도에 영향을 미치는 병목 현상은 서버의 전체적인 성능에 큰 영향을 줍니다.
디스크 개체가 서버에서 비활성화된 경우 명령줄 도구 Diskperf를 통해 활성화해야 합니다. 또한 % Disk Time은 100%를 초과할 수 있으므로 대신 % Idle Time, Avg. Disk sec/Read 및 Avg. Disk sec/write를 사용하면 하드 디스크가 얼마나 많이 사용되고 있는지 좀더 정확하게 파악할 수 있습니다. % Disk Time에 대한 자세한 내용은 support.microsoft.com/kb/310067 기술 자료 문서를 참조하십시오.
다음은 Microsoft Service Support 엔지니어가 디스크 모니터링을 위해 사용하는 카운터입니다.
LogicalDisk\% Free Space 선택한 논리 디스크 드라이브에서 사용할 수 있는 공간의 백분율을 측정합니다. 이 카운터가 15% 아래로 떨어지면 OS에서 중요 파일을 저장하기 위한 여유 공간이 부족할 수 있습니다. 이 경우 확실한 해결책은 디스크 공간을 늘리는 것입니다.
PhysicalDisk\% Idle Time 샘플 간격 중 디스크가 유휴 상태였던 시간 백분율을 측정합니다. 이 카운터가 20% 아래로 떨어지면 디스크 시스템이 포화 상태인 것입니다. 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것이 좋습니다.
PhysicalDisk\Avg. Disk Sec/Read 디스크에서 데이터를 읽는 데 걸리는 평균 시간(초)을 측정합니다. 값이 25ms(밀리초)보다 크면 디스크에서 읽을 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server® 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 가장 현명한 해결책은 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.
PhysicalDisk\Avg. Disk Sec/Write 디스크에 데이터를 쓰는 데 걸리는 평균 시간을 측정합니다. 이 시간이 25ms보다 크면 디스크에 쓸 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 현명한 해결책은 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.
PhysicalDisk\Avg. Disk Queue Length 얼마나 많은 I/O 작업이 하드 드라이브를 사용할 수 있을 때까지 대기하고 있는지 나타냅니다. 여기에서 값이 스핀들 수 + 2보다 크면 디스크 자체에 병목 현상이 있음을 의미합니다.
Memory\Cache Bytes 파일 시스템 캐시에 사용되고 있는 메모리의 양을 나타냅니다. 이 값이 200MB보다 크면 디스크 병목 현상이 발생할 수 있습니다.

메모리 병목 현상
메모리 부족은 대체로 RAM 부족, 메모리 누수 또는 boot.ini의 메모리 스위치 등으로 인해 발생합니다. 메모리 카운터를 소개하기 전에 먼저 /3GB 스위치에 대해 설명하겠습니다.
메모리가 많을수록 디스크 I/O 작업이 줄고 응용 프로그램 성능이 높아집니다. /3GB 스위치는 사용자 모드 프로그램에 더 많은 메모리를 제공하기 위한 방법으로 Windows NT®에서 도입되었습니다.
Windows에서는 4GB의 가상 주소 공간을 사용하며 이는 시스템의 물리적 RAM과는 무관합니다. 기본적으로 하위 2GB는 사용자 모드 프로그램을 위해 사용되고, 상위 2GB는 커널 모드 프로그램을 위해 사용됩니다. /3GB 스위치를 사용하면 사용자 모드 프로세스에 3GB가 제공됩니다. 그러면 물론 커널 메모리가 가상 주소 공간의 1GB만 남게 되므로 영향을 받습니다. 이 경우 페이징되지 않은 바이트 풀링, 페이징된 바이트 풀링, 사용 가능한 시스템 페이지 테이블 항목 및 데스크톱 힙이 모두 이 1GB 공간 안에 들어가야 하므로 문제가 발생할 수 있습니다. 따라서 /3GB 스위치는 해당 환경에서 충분한 테스트를 거친 후에만 사용해야 합니다.
메모리 관련 병목 현상이 발생하는 경우 이 스위치를 의심해 볼 수 있습니다. /3GB 스위치가 문제의 원인이 아니라면 다음 카운터를 사용하여 잠재적인 메모리 병목 현상을 진단할 수 있습니다.
Memory\% Committed Bytes in Use 커밋된 바이트와 커밋 한도의 비율, 즉 가상 메모리의 사용량을 측정합니다. 이 값이 80%보다 크면 메모리가 부족함을 나타냅니다. 이 경우 확실한 해결책은 메모리를 추가하는 것입니다.
Memory\% Available Mbytes 프로세스 실행을 위해 사용할 수 있는 실제 메모리의 양(메가바이트)을 측정합니다. 이 값이 총 물리적 RAM의 5%보다 작으면 메모리가 부족함을 나타내며 이로 인해 페이징 작업이 늘어날 수 있습니다. 이 문제를 해결하려면 메모리를 추가해야 합니다.
Memory\Free System Page Table Entries 시스템에서 현재 사용되지 않는 페이지 테이블 항목의 수를 나타냅니다. 이 숫자가 5,000보다 작으면 메모리 누수가 있을 수 있습니다.
Memory\Pool Non-Paged Bytes 페이징되지 않은 풀의 크기(바이트)를 측정합니다. 디스크에 쓸 수 없고 대신 실제 메모리에 남아 있어야 하는 할당된 개체에 대한 시스템 메모리 영역입니다. 이 값이 175MB(또는 /3GB 스위치의 경우 100MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2019가 시스템 이벤트 로그에 기록됩니다.
Memory\Pool Paged Bytes 페이징된 풀의 크기(바이트)를 측정합니다. 사용되고 있지 않을 때 디스크에 쓸 수 있는 개체에 대한 시스템 메모리 영역입니다. 이 값이 250MB(또는 /3GB 스위치의 경우 170MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2020이 시스템 이벤트 로그에 기록됩니다.
Memory\Pages per Second 하드 페이지 결함을 해결하기 위해 디스크에서 페이지를 읽거나 쓰는 속도를 측정합니다. 과도한 페이징으로 인해 이 값이 1,000보다 크면 메모리 누수 가능성이 있습니다.

﻿프로세서 병목 현상
프로세서 병목 현상은 프로세서 자체의 성능이 나빠서 발생하거나 비효율적인 응용 프로그램으로 인해 발생할 수 있습니다. 실제 메모리 부족으로 인해 프로세서가 페이징에서 많은 시간을 보내지 않는지 다시 확인해야 합니다. 잠재적인 프로세서 병목 현상을 조사할 때 Microsoft Service Support 엔지니어는 다음 카운터를 사용합니다.
Processor\% Processor Time 프로세서가 비유휴 스레드 실행에 소비하는 경과 시간의 백분율을 측정합니다. 이 백분율이 85%보다 크면 프로세서에 병목 현상이 발생하고 서버에 더 빠른 프로세서가 필요할 수 있습니다.
Processor\% User Time 프로세서가 사용자 모드에서 소비하는 경과 시간의 백분율을 측정합니다. 이 값이 높으면 서버에서 응용 프로그램이 많이 실행되고 있음을 나타냅니다. 한 가지 가능한 해결책은 프로세서 리소스를 많이 사용하는 응용 프로그램을 최적화하는 것입니다.
Processor\% Interrupt Time 지정된 샘플 간격 중 프로세서가 하드웨어 인터럽트 수신 및 서비스 제공에 소비하는 시간을 측정합니다. 이 값이 15%보다 크면 하드웨어 문제일 수 있습니다.
System\Processor Queue Length 프로세서 큐의 스레드 수를 나타냅니다. 이 값이 일정 기간 동안 CPU 수 x 2보다 크면 서버에 프로세서 성능이 부족한 것입니다.

네트워크 병목 현상
네트워크 병목 현상은 네트워크에서 데이터를 송수신하는 서버의 성능에 영향을 미칩니다. 서버의 네트워크 카드에 문제가 있을 수 있거나, 네트워크가 포화 상태여서 분할해야 할 수 있습니다. 다음 카운터를 사용하여 잠재적인 네트워크 병목 현상을 진단할 수 있습니다.
Network Interface\Bytes Total/Sec 프레이밍 문자를 포함하여 각 네트워크 어댑터를 통해 보내고 받는 바이트의 비율을 측정합니다. 인터페이스의 70% 이상이 사용되면 네트워크가 포화 상태입니다. 100Mbps NIC의 경우 사용되는 인터페이스는 8.7MB/초입니다(100Mbps = 100000kbps = 12.5MB/초* 70%). 이와 같이 포화 상태이면 더 빠른 네트워크 카드를 추가하거나 네트워크를 분할해야 할 수 있습니다.
Network Interface\Output Queue Length 출력 패킷 큐의 길이(패킷)를 측정합니다. 이 값이 2보다 크면 네트워크가 포화 상태입니다. 이 문제는 더 빠른 네트워크 카드를 추가하거나 네트워크를 분할하여 해결할 수 있습니다.

프로세스 병목 현상
제대로 작동하지 않는 프로세스나 최적화되지 않은 프로세스가 있으면 서버 성능이 크게 저하될 수 있습니다. 스레드 및 핸들 누수는 결국 서버 다운으로 이어지고, 과도한 프로세서 사용은 서버 속도를 저하시킵니다. 다음 카운터는 프로세스 관련 병목 현상을 진단할 때 유용합니다.
Process\Handle Count 프로세스로 현재 열린 총 핸들 수를 측정합니다. 이 값이 10,000보다 크면 핸들 누수 가능성이 있습니다.
Process\Thread Count 프로세스에서 현재 활성 스레드 수를 측정합니다. 이 값이 최소 및 최대 스레드 수 사이에서 500보다 크면 스레드 누수 가능성이 있습니다.
Process\Private Bytes 다른 프로세스와 공유할 수 없는 이 프로세스에 할당된 메모리의 양입니다. 이 값이 최소 및 최대 스레드 수 사이에서 250보다 크면 메모리 누수 가능성이 있습니다.

요약
지금까지 Microsoft의 Service Support 엔지니어가 다양한 병목 현상을 진단하기 위해 사용하는 카운터를 살펴보았습니다. 물론 결국에는 자신의 특정 요구에 맞는 고유의 카운터를 사용해야 합니다. 또한 서버를 모니터링해야 할 때마다 모든 카운터를 수동으로 추가할 필요가 없게 해야 합니다. 다행히 성능 모니터에는 나중에 사용하기 위해 템플릿에 모든 카운터를 저장할 수 있는 옵션이 있습니다.
성능 모니터를 로컬에서 실행해야 하는지 아니면 원격으로 실행해야 하는지 결정하지 못할 수 있습니다. 또한 성능 모니터를 로컬에서 실행할 때 성능에 정확히 어떤 영향을 주는지도 확실하지 않을 경우가 있습니다. 이 모든 사항은 특정 환경에 따라 다릅니다. 간격을 5분 이상으로 설정한다면 서버에서의 성능 저하는 거의 무시할 만한 수준입니다.
성능 모니터는 서버에 리소스가 부족할 때 원격 시스템에서 데이터를 가져오지 못할 수 있으므로 서버에 성능 문제가 있음을 알고 있다면 성능 모니터를 로컬에서 실행하는 것이 좋습니다. 중앙 컴퓨터에서 원격으로 실행하는 것은 여러 서버를 모니터링하거나 기준으로 사용하고자 할 때 가장 이상적입니다.

Steven Choy는 Microsoft Premier Field Engineering의 상임 수석 현장 엔지니어입니다. 데스크톱 배치 및 마이그레이션, 패치 관리, 그룹 정책 등 관련 프로젝트에서 정부 기관과 일반 고객을 지원하며, 현재 서버 가상화 및 서버 상태 모니터링을 중점적으로 다루고 있습니다.


System Center
System Center Operations Manager의 Windows PowerShell
Marco Shaw
한 눈에 보기:
  • OpsMgr 명령 셸
  • OpsMgr Monitoring 공급자
  • 일반 관리 작업 자동화
  • 몇 가지 실제 Windows PowerShell 예제

목차
Operations Manager 명령 셸
OpsMgr Monitoring 공급자
일반 작업 자동화
실제 사례
요약
System Center Operations Manager 2007(OpsMgr)을 통해 관리자들은 작업 자동화를 위한 강력하고 새로운 스크립팅 언어인 Windows PowerShell에 액세스할 수 있게 되었습니다. 2006년 11월에 일반에 공개된 Windows PowerShell은 지금까지 2백만 회 이상 다운로드되었습니다.
여기서는 Windows PowerShell®을 소개하고 Operations Manager에 어떻게 적용되는지 설명합니다. 또한 Windows PowerShell을 통해 더욱 쉽고 자동화된 방법으로 수행할 수 있는 몇 가지 일반적인 작업을 설명하고, 유용한 스크립트와 설명을 제공하는 웹 사이트를 안내합니다. 현재 Windows PowerShell을 사용하는 많은 전문가들의 유용한 정보 및 블로그 게시물도 소개합니다.
Microsoft는 CTP(Community Technology Preview) 버전의 Windows PowerShell 2.0을 발표하기 시작했지만 이러한 버전은 프로덕션 환경에서 사용할 준비가 되지 않았고 OpsMgr에서 테스트되지 않았으므로 프로덕션 시스템에 설치하면 안 됩니다.

Operations Manager 명령 셸
OpsMgr에서는 콘솔 파일을 로드하고 OpsMgr cmdlet, 함수 및 기본 연결로 환경을 초기화하는 스크립트를 로드한다는 것을 제외하고 기본 Windows PowerShell 환경과 유사한 명령 셸을 통해 Windows PowerShell에 액세스합니다.
명령 셸은 OpsMgr 시작 메뉴의 아이콘으로 시작하거나 OpsMgr UI 콘솔에서 컴퓨터 이름을 마우스 오른쪽 단추로 클릭하여 시작할 수 있습니다(그림 1 참조). 그러면 바로 OpsMgr Monitoring 드라이브 경로(곧 설명 예정)에 있게 됩니다.
그림 1 OpsMgr UI에서 명령 셸 열기(크게 보려면 이미지 클릭)
Windows PowerShell은 OpsMgr SDK를 통해 OpsMgr와 상호 작용합니다. 관리자에게는 다행스럽게도 일반적으로 자동화하거나 명령줄에서 완료하기를 원하는 많은 작업을 위한 cmdlet이 이미 제공되었습니다. 특정 작업에 대한 cmdlet이 없다면 Windows PowerShell을 사용하여 SDK와 상호 작용할 수 있습니다.
Operations Manager 명령 셸에서 제공되는 명령은 Windows PowerShell에서 로드되고 OpsMgr 관리용 cmdlet을 포함하는 DLL인 스냅인에 포함되어 있습니다. 스냅인에는 OperationsManagerMonitoring Windows PowerShell 공급자도 포함됩니다. 간단히 Monitoring 공급자라고 하는 이 도구를 통해 파일 시스템을 탐색하는 것처럼 연결, 그룹 및 모니터링 개체를 탐색할 수 있습니다.
OpsMgr의 모든 cmdlet 목록은 그림 2와 같이 Get-OperationsManagerCommand cmdlet을 사용하여 볼 수 있습니다. 첫 번째 버전에서 이 명령은 탭 완성을 지원하지 않는 함수였으며 SP1에서 cmdlet이 되었습니다. Operations Manager의 최초 릴리스에는 74개의 cmdlet이 포함되어 있었고, OpsMgr SP1에는 87개의 cmdlet이 포함됩니다.
그림 2 OpsMgr cmdlet 목록 보기(크게 보려면 이미지 클릭)

OpsMgr Monitoring 공급자
cmdlet Set-Location 또는 별칭 cd를 사용하여 그룹 및 컴퓨터의 레이아웃을 탐색할 수 있습니다. 기본 Monitoringdrive에 대한 기준 레이아웃은 다음과 유사합니다.
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
여기에서 특정 개체로 이동할 수 있습니다. 이 문서에서는 하나의 관리 서버만 있는 단순한 환경을 대상으로 합니다. 관리 그룹에 설치된 첫 번째 관리 서버를 루트 관리 서버(RMS)라고 합니다.
명령 셸이 시작되면 Monitoring이라는 드라이브가 만들어지고, 드라이브가 OperationsManagerMonitoring 공급자의 루트에 매핑되며, 마지막으로 현재 위치나 경로가 Monitoring 드라이브의 루트로 설정됩니다. 그런 다음 명령 셸은 연결할 기본 RMS의 이름을 레지스트리에서 검색합니다. RMS 연결에 성공하면 그림 3과 같이 현재 위치나 경로가 연결 이름 또는 RMS로 설정됩니다.
그림 3 RMS로 설정된 명령 셸 위치(크게 보려면 이미지 클릭)

일반 작업 자동화
Windows PowerShell에서 몇 가지 가장 일반적인 관리 작업을 어떻게 처리할 수 있는지 살펴보겠습니다.
유지 관리 모드 제어 어떠한 작업을 대상으로 하건 대개 발생해야 하는 날짜와 시간을 지정하게 됩니다. Get-Date cmdlet을 사용하여 이 작업을 얼마나 쉽게 수행할 수 있는지 살펴보겠습니다. 그림 4에 몇 가지 예가 표시되어 있습니다.
그림 4 Get-Date cmdlet 사용(크게 보려면 이미지 클릭)
보시는 바와 같이 현재 시간을 나타내는 개체가 포함된 $date 변수를 만들었습니다. 그런 다음 개체에서 지원하는 몇 가지 문서화된 방법을 사용하여 날짜와 시간을 5분 후, 5시간 후로 쉽게 설정할 수 있습니다. 과거의 값으로 설정하려면 간단히 (5) 대신 (-5)를 사용하면 됩니다.
컴퓨터에서 발생하는 모든 경고를 차단해야 하는 경우 유지 관리 모드를 사용할 수 있습니다. OpsMgr 2007에서는 전체 컴퓨터나 그룹 대신 Windows® 서비스 또는 특정 데이터베이스를 유지 관리 모드로 전환할 수 있습니다. 특별히 유지 관리 모드 작업을 대상으로 하는 cmdlet에는 Get-MaintenanceWindow, New-MaintenanceWindow 및 Set-MaintenanceWindow의 세 가지가 있습니다.
명령 셸 내에서 컴퓨터를 유지 관리 모드로 전환하려면 그림 5와 같이 Monitoring 공급자를 사용하여 원하는 컴퓨터나 모니터링 개체로 이동하고 New-MaintenanceWindow cmdlet을 호출합니다. 보시는 바와 같이 이 작업은 Denver.contoso.com이라는 컴퓨터를 유지 관리 모드로 전환합니다. 또한 유지 관리 기간이 즉시 시작되고, 정확히 1시간 후에 종료되도록 정의했습니다. 이 방법을 사용하여 컴퓨터를 유지 관리 모드로 전환할 경우 이 개체에 대한 HealthService 및 HealthServiceWatcher 인스턴스가 아직 사용되므로 일부 경고는 중지되지 않습니다.
그림 5 New-MaintenanceWindow cmdlet 사용(크게 보려면 이미지 클릭)
Microsoft OpsMgr 팀의 Boris Yanushpolsky 프로그램 관리자는 컴퓨터를 참조하는 모든 개체를 유지 관리 모드로 설정하는 데 사용할 수 있는 매우 간편한 Windows PowerShell 코드를 제공하고, 스크립트를 만든 경우 이 코드를 사용하는 방법도 설명했습니다. 이에 대한 자세한 내용을 보려면 그의 블로그 blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx를 방문하십시오.
때때로 유지 관리 모드가 되면 안 되는 개체인지 확인해야 할 수 있습니다. 하지만 이것을 알아내기 위해 모든 개체를 일일이 조사해야 한다면 큰 고역이 아닐 수 없습니다. 다행히 Boris Yanushpolsky는 OpsMgr SDK를 사용하는 Windows PowerShell 스크립트로 다시 도움을 주었습니다. 그의 블로그 게시물(blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx)에서 바로 코드를 복사하여 명령 셸 창에 붙여 넣으면 유지 관리 모드의 모든 개체 목록을 확인할 수 있습니다.
개체가 유지 관리 모드인 경우 원래 지정한 종료 시간 전에 유지 관리 기간을 끝낼 수 있습니다. Windows PowerShell에 익숙하다면 stop 또는 remove 동사가 있는 cmdlet을 기대하겠지만 실제로는 그림 6과 같이 Set-MaintenanceWindow를 사용해야 합니다.
그림 6 Set-MaintenanceWindow를 사용하여 종료 시간 변경(크게 보려면 이미지 클릭)
에이전트 관리 관리자는 에이전트로 작업하는 경우가 많으며, 다양한 에이전트 관련 작업을 대상으로 하는 6개의 cmdlet과 1개의 함수(현재 릴리스 기준)가 있습니다. 이 목록은 다음 명령을 사용하여 확인할 수 있습니다.
Get-Command *-agent*
SP1 릴리스에서는 Install-AgentByName이 함수 대신 cmdlet으로 패키지화되어 있습니다. Install-AgentByName cmdlet은 지원 및 일관성을 위해 더 좋은 기준을 제공하므로 이것을 사용하는 것이 좋습니다.
명령 셸에 포함되어 있는 도움말에서는 Install-Agent 및 Uninstall-Agent cmdlet을 사용하는 몇 가지 좋은 예를 제공합니다. Microsoft OpsMgr 팀의 Roger Sprague 상임 소프트웨어 설계 엔지니어는 그림 7에 표시되어 있는 것과 같이 그의 블로그에서 대체 방법을 게시했습니다(원본 게시물은 blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx 참조).
이 스크립트는 OpsMgr RTM에서 제대로 작동하지만(Monitoring 공급자의 루트, 이 문서의 경우 monitoring:\oxford.contoso.com에 있어야 함), OpsMgr SP1에서는 제대로 작동하지 않습니다. OpsMgr SP1에서 작동하도록 하려면 그림 7의 첫 번째 명령을 다음과 같이 변경해야 합니다.
$managementServer = Get-RootManagementServer
그림 7 에이전트 설치
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
이제 모니터링되어야 하는 원격 시스템에 에이전트가 설치되었지만, 완전하게 모니터링하려면 먼저 관리 서버가 실제로 새 에이전트를 승인하도록 하는 마지막 단계가 남아 있습니다. 여기서 추가 작업을 수행하지 않을 경우 모니터링 서버가 모니터링을 위해 새 에이전트를 자동으로 승인합니다. 그러나 이 승인 프로세스도 Get-AgentPendingAction cmdlet을 사용하여 빠르게 수행할 수 있습니다. 다음 한 줄을 사용하여 에이전트 승인 프로세스를 빠르게 처리할 수 있습니다.
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
이 작업이 아직 보류 상태인 경우 이것을 Approve-AgentPendingAction 대신 Reject-AgentPendingAction에 연결하면 OpsMgr 서버에서 이 에이전트를 승인하는 것을 차단할 수 있습니다. 보류 상태가 아니면 대신 Uninstall-Agent cmdlet을 사용합니다.
앞에서 언급한 대로 명령줄에서 에이전트가 설치되어야 하는 컴퓨터를 직접 지정하기 위해 Install-AgentByName을 사용할 수도 있습니다.
관리 팩 작업 다양한 관리 팩 작업을 처리할 수 있도록 4개의 cmdlet이 제공됩니다. 이 목록은 다음을 사용하여 확인할 수 있습니다.
Get-Command –noun ManagementPack
다음의 간단한 명령은 현재 설치된 관리 팩과 버전 번호를 제공합니다.
Get-ManagementPack | Format-Table –autosize
이제 명령 셸에서 다음 설치 관리자를 사용하여 두 가지 일반적인 관리 팩을 설치해 보겠습니다.
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
여기서는 명령 셸을 통해 일반적인 작업을 더 쉽게 수행할 수 있음을 보여 주는 것이 목적이므로 가능한 한 가장 적은 수의 명령을 사용하여 시도해 보겠습니다(그림 8 참조). quiet 플래그를 설치 관리자(.msi 파일)에 전달하도록 이 설치 절차를 변경할 수도 있지만, 파일이 수동으로 추출되는 위치를 선택했습니다.
그림 8 관리 팩 설치(크게 보려면 이미지 클릭)
이제 공용 라이브러리를 설치해야 하므로 다음과 같이 수행할 수 있습니다.
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
그런 다음 기타 필수 관리 팩을 설치합니다.
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
그림 9에 표시된 것과 같이 명령 셸 도움말은 Export-ManagementPack cmdlet을 사용하여 봉인되지 않은 관리 팩을 내보내는 좋은 예를 제공합니다. 모든 관리 팩을 내보내려면 다음 줄을 변경합니다.
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
그림 9 관리 팩 내보내기(크게 보려면 이미지 클릭)
사용자 역할 조작 Get-UserRole cmdlet은 사용자 관리를 위한 몇 가지 기능을 제공하지만, 이상하게도 보완하는 Set cmdlet이 제공되지 않고 일반적으로 편집이나 업데이트에 사용하지 않습니다(Windows PowerShell SDK 설명서에 따라). 그림 10에 표시된 것과 같이 먼저 현재 사용자 역할 목록을 확인한 다음 사용자를 Read-Only Operators 그룹에 추가합니다(그림 11 참조).
그림 10 사용자 역할 표시(크게 보려면 이미지 클릭)
그림 11 사용자 추가(크게 보려면 이미지 클릭)
ACS(Audit Collection Services) 사용 ACS는 간단히 말해서 보안 감사 정보를 다루기 위한 중앙 집중식 방법을 제공하는 Operations Manager 2007의 새로운 선택적 기능입니다. ACS는 기본적으로 사용되지 않으며, 대개 OpsMgr 배포의 이후 단계에서 나중에 구성됩니다.
ACS에 대해 많은 수의 에이전트를 사용해야 하는 경우 Windows PowerShell을 통해 설정을 자동화할 수 있습니다. OpsMgr 베타 버전에서 Microsoft는 모든 에이전트에서 ACS를 사용할 수 있는 스크립트를 제공했습니다. SystemCenterForum.org의 기고가이며 블로거인 Neale Browne은 이것을 한 수준 높이고 추가 매개 변수에 대한 지원 기능을 추가했습니다.
SystemCenterForum.org 사이트(Microsoft® System Center 솔루션을 제공하는 커뮤니티 사이트)에서는 ACS의 설정을 자동화하는 데 사용할 수 있는 두 가지 서로 다른 Windows PowerShell 스크립트를 만들었습니다. 특정 그룹의 모든 에이전트를 설정하려면 systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip을 사용합니다. 모니터링되는 모든 에이전트를 설정하려면 systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip을 다운로드합니다.
에이전트 프록시 사용 OpsMgr 환경에는 에이전트 없이 모니터링되는 장치가 포함될 수 있습니다. 이러한 장치는 관리 서버에 지정하거나 원격 모니터링을 제공하는 에이전트 관리 장치에 지정해야 합니다. Windows PowerShell 스크립트를 사용하여 많은 수의 에이전트를 구성하는 것에 대한 자세한 내용은 systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell에서 찾을 수 있습니다. 업데이트된 스크립트 버전은 systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip에서 제공됩니다.
특정 관리 팩에서 에이전트가 프록시로 작동하도록 설정해야 하는 다른 조건도 있습니다. 자세한 내용은 관리 팩 설명서를 참조하십시오.

실제 사례
여기에는 Windows PowerShell을 사용하여 자동화할 수 있는 방법을 보여 주는 몇 가지 실례를 설명합니다.
경고 해결 특정 컴퓨터에 대한 여러 가지 경고를 삭제해야 했던 적이 있었습니까? 응용 프로그램에 무엇인가 잘못되었거나 경고가 제대로 해결되지 않았을 수 있습니다. 다음은 해결 상태가 0인 모든 경고를 해결하는 한 줄 명령입니다.
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
다음 예는 위의 명령과 동일한 기능을 수행하지만, 해결되지 않은 더 많은 경고가 있는 대규모 환경에서 더욱 빠르게 실행됩니다.
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
이렇게 성능 차이가 나는 이유는 기준 매개 변수를 사용할 경우 전달되는 값이 SQL Server® 데이터베이스에 직접 제공되고 관련 데이터만 반환되기 때문입니다. 결과적으로 다시 Windows PowerShell 콘솔로 전달되어야 하는 개체가 줄어듭니다.
이제 한 컴퓨터에 대해 해결되지 않은 모든 경고를 빠르게 제거할 수 있는 방법을 알게 되었습니다. 필요에 따라 이것을 자동으로 실행되도록 설정할 수 있습니다.
마지막으로 다음은 특정 일의 모든 경고를 볼 수 있는 빠른 명령입니다.
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
날짜 값을 매우 쉽게 변경할 수 있고, 출력을 Resolve-Alert cmdlet에 연결할 수 있습니다.
테스트 경고 때때로 Windows 이벤트 뷰어에서 특정 이벤트를 모니터하고 테스트해야 할 수 있습니다. 다음 두 줄을 사용하여 빠른 이벤트 로그 항목을 만들 수 있습니다.
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
하지만 이 경우 기본적으로 Operations Manager 이벤트 로그에 작성되며, 여기는 특정 이벤트가 로깅되도록 하려는 위치가 아닐 것입니다. 다행히 Microsoft의 수석 필드 엔지니어인 Stefan Stranger가 Windows 이벤트 뷰어에서 이벤트를 만들 수 있는 스크립트를 작성했으며, 이 스크립트는 특정 로그에 작성할 수 있는 더 많은 유연성을 제공합니다. 이 스크립트는 go.microsoft.com/fwlink/?LinkId=120308에서 찾을 수 있습니다. 스크립트는 .cab 파일로 패키지화되어 있습니다. 파일을 다운로드한 다음 마우스 오른쪽 단추를 클릭하여 스크립트를 추출해야 합니다.
Stefan의 스크립트에서 알아 두어야 할 한 가지는 이벤트 소스에 입력된 값에 따라 항목이 작성될 로그가 결정된다는 것입니다. 경고가 올바른 로그에 기록되는지 확인하기 위한 가장 쉬운 방법은 Windows 이벤트 뷰어를 열고 최근 항목의 소스를 찾는 것입니다.
소유자 설정 경고의 소유자를 자동으로 설정하는 것이 유용할 때가 있습니다. 다음은 명령 셸에서 수행할 수 있는 간단한 방법입니다.
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
코드의 첫 번째 줄은 특정 경고 개체의 ID를 확인하고 이것을 $alert 변수에 전달합니다. 두 번째 줄에서는 이 변수를 사용하여 소유자를 설정하고, 마지막으로 OpsMgr 데이터베이스에 업데이트가 적용됩니다. 다음 명령으로 경고의 소유자를 확인하면 변경되었음을 알 수 있습니다.
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
전체 경고 집합에 대한 소유자를 설정하려면 코드를 다음과 같이 단순화할 수 있습니다.
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
모니터링 상태 복원 "모니터링되지 않는" 상태의 에이전트를 발견할 때가 있습니다. 이 경우 모든 에이전트를 전체 모니터링되는 상태로 신속하게 복원한 다음 어떻게 되는지 확인해야 합니다. 명령 셸에서 직접 그림 12의 스크립트를 실행하면 해당하는 모든 에이전트에 전체 모니터링이 복원되어야 합니다.
그림 12 Health Service Store 재설정
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
그림 12의 코드를 살펴보겠습니다. 변수를 선언한 후 이 RMS에서 모든 에이전트 목록을 확인하고 문제가 있어 보이는 에이전트를 필터링합니다. 그런 다음 필터링된 목록의 모든 에이전트에 대한 Health Service Store를 재설정하는 작업을 비동기로 호출합니다.
관리 팩과 경고 연결 그림 13은 새로운 모든 경고 및 각 경고와 연결된 관리 팩 목록을 확인하는 방법을 보여 줍니다.
모든 관리 팩 이름이 확인되도록 하려면 코드에 몇 가지 트릭이 필요합니다. 사용되는 cmdlet은 경고가 규칙 또는 모니터에서 발생했는지에 따라 달라집니다. 그림 13에서는 Get-Monitor cmdlet에 대해 작은 해결 방법을 구현해야 했습니다. OpsMgr SP1에서는 현재 cmdlet이 새로운 ID 매개 변수를 지원하여 코드가 약간 단순화되었습니다.
그림 13 관리 팩 찾기
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
손쉬운 보고 환경을 업그레이드할 때 설치된 모든 에이전트의 버전을 감사하는 것이 유용할 수 있습니다. 다음과 같이 간단한 스크립트를 사용하여 적합한 보고서를 출력할 수 있습니다.
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
그림 14는 스크립트의 출력을 보여 줍니다. 이 스크립트는 systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell에 제공된 예제의 확장 버전입니다.
그림 14 일부 에이전트의 버전을 보여 주는 출력(크게 보려면 이미지 클릭)
작업 예약 Windows PowerShell 스크립트를 정기적으로 실행하고자 할 수 있습니다. 클라이언트 컴퓨터를 사용하여 OpsMgr 서버에 연결 및 관리하고 OpsMgr 관리 도구를 로컬에 설치했다고 가정해 보겠습니다. 그리고 에이전트 버전 보고서를 매일 실행하고 현재 날짜를 이름으로 사용하는 파일에 출력이 저장되도록 한다고 가정합니다. Windows 기본 제공 작업 스케줄러를 사용하여 로컬 컴퓨터에서 스크립트를 실행할 수 있습니다.
이를 위해서는 powershell.exe(대개 C:\Windows\System32\WindowsPowerShell\v1.0에 있음)로 설정된 프로그램으로 새 작업을 설정합니다. 작업을 만든 후에는 편집하고 명령이 실행되도록 다음과 같이 설정합니다.
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
그림 15에 표시된 것과 같이 원본 Windows PowerShell 코드에 몇 가지 변경 작업을 수행해야 했습니다. OpsMgr PowerShell 스냅인을 추가하고, OperationsManagerMonitoring 공급자에 매핑된 Monitoring 드라이브를 만들었으며, RMS에 대한 연결을 만들었습니다. 또한 OpsMgr 사용자 지정 Windows PowerShell 스크립트(Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1)를 로드하여 OpsMgr 특정 기능을 로드했습니다.
그림 15 에이전트 버전 일정 예약 스크립트
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
그러나 이것이 전부가 아닙니다. 작업이 실행될 때마다 스크립트가 실행되는 시스템에 누군가 로그온할 경우 검은색 콘솔 창이 화면에 나타나는 것을 알 수 있습니다. 이에 대한 간단한 트릭은 Sapien의 Don Jones 및 Jeffery Hicks의 blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell에서 찾을 수 있습니다.
기본적으로 스크립트는 VBScript 내에서 래핑해야 합니다. 이를 위해서는 예약된 작업에서 다음을 호출하는 대신 그림 16과 유사한 코드를 사용해야 합니다.
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
그림 16 팝업 숨기기
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
이제 작업에서는 wscript.exe 프로그램을 사용하고 호출은 다음과 유사합니다.
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
마지막으로 자동화된 보고서를 만들고 이 프로세스는 로그온한 사용자에게 보이지 않습니다.

요약
이 문서에서는 OpsMgr 2007에서 사용할 수 있는 새로운 자동화 기능에 대해 대략적으로 살펴보았으며, Windows PowerShell을 사용하여 OpsMgr 관리를 수행할 수 있는 방법에 대해서는 아주 약간만 소개했습니다.
이 문서에서 언급한 모든 분들과 많은 도움을 주신 Pete Zerger, MOM MVP 및 SystemCenterForum.org 설립자께 감사의 말씀을 드립니다.

Marco Shaw는 캐나다 통신 회사의 IT 시스템 분석가입니다. IT 분야에서 10년 이상 일해 왔으며, 최근 Windows PowerShell MVP 상을 수상했습니다. 또한 Marco는 새로운 PowerShell 커뮤니티 웹 사이트 powershellcommunity.org의 커뮤니티 부책임자입니다. Marco의 블로그 주소는 marcoshaw.blogspot.com입니다.


인터넷 정보 서비스
ASP.NET 응용 프로그램 확장: 교훈
Richard Campbell
한 눈에 보기:
  • 개발자/IT 협력의 중요성
  • 주 확장 전략 이해
  • 여러 팀 간의 지식 공유
  • 핵심적인 지식에 대한 합의

목차
확장의 기초
정보 및 의견 나누기
네트워킹 팀이 개발 팀에 확인해야 할 정보
개발 팀이 네트워킹 팀에 확인해야 할 정보
확장으로 돌아가기
협력
제가 컨설턴트 자격으로 참여하여 성공을 거둔 모든 ASP.NET 응용 프로그램 확장 프로젝트는 응용 프로그램 개발자와 실제로 응용 프로그램을 실행하는 네트워크 관리자 간에 긴밀한 협력이 이루어진 결과였습니다. 응용 프로그램 수명 주기의 처음부터
이러한 협력의 필요성이 항상 명확하게 드러나는 것은 아닙니다. 따라서 응용 프로그램 수명 주기의 시작 단계부터 참여한 적은 없었습니다. 문제가 발생하는 끝 단계에 와서야 그러한 기회가 주어질 뿐입니다.
어떤 응용 프로그램 확장도 처음부터 효과를 발휘할 수 없다는 것은 당연한 사실입니다. 완벽한 상태로 첫 선을 보이는 것은 불가능하기 때문입니다. 응용 프로그램을 성공적으로 확장하기 위해서는 응용 프로그램이 어떻게 구축되었는지 그리고 그 응용 프로그램이 실행되는 운영 환경이 어떻게 작동하는지 파악해야 합니다. 다시 말해서 개발 담당자와 네트워크 담당자의 의견을 모두 수렴해야 합니다. 이러한 지식 공유가 이루어지지 않는다면 성공할 수 없습니다.

확장의 기초
본론으로 들어가기에 앞서, ASP.NET 응용 프로그램을 확장하기 위한 준비가 필요합니다. 일반적으로 사용되는 두 가지 기본 전략은 전문성(specialization)과 배포(distribution)이며, 대개 ASP.NET 응용 프로그램 확장에서는 두 전략을 모두 적용합니다. 또한 ASP.NET 응용 프로그램 확장에 도움이 되는 모든 방법은 두 전략 중 하나로 분류됩니다.
전문성은 응용 프로그램의 요소를 분리하여 독립적으로 확장할 수 있게 합니다. 예를 들어, ASP.NET 페이지를 렌더링하는 서버를 그대로 사용하지 않고 전용 이미지 서버를 구축할 수도 있습니다. 이미지 서버의 최적의 구성은 ASP.NET 서버와는 크게 다릅니다. 또한 이미지 요청을 응용 프로그램의 나머지 부분과 분리하면 타사 리소스를 이미지 서비스에 사용하는 것이 가능해집니다. 이와 동일한 방식을 다른 리소스 파일에도 적용할 수 있습니다.
한편 배포는 웹 팜(web farm)이라고 하는 여러 서버에 응용 프로그램을 대칭적으로 분산시키는 것입니다. ASP.NET 응용 프로그램은 특히 배포에 적합합니다. 각각의 개별 페이지 요청은 작은 편이고, 대개 사용자마다 상호 작용이 독립적이기 때문입니다. 배포는 하나의 대형 서버가 모든 작업을 수행하는 "수직 확장(scale up)"보다는 중급 성능의 서버 여러 대가 함께 사용자의 요청을 수행하는 "수평 확장(scale out)"이라 할 수 있습니다.
전문성과 배포를 연계하면 효율성이 향상됩니다. 응용 프로그램 중 추가적인 성능이 필요한 요소만 배포할 수 있기 때문입니다. 예를 들어, 전문 이미지 서버를 구축했으나 아직 이미지 서비스가 적합한 수준이 아닌 경우 응용 프로그램 전체에 서버를 추가하지 않고 이미지 서버를 추가할 수 있습니다. ASP.NET 응용 프로그램의 성능과 확장성을 높이고자 할 때 이 전략을 염두에 두어야 합니다.

정보 및 의견 나누기
모든 ASP.NET 응용 프로그램의 수명 주기 중 어느 시점에서 개발자와 네트워크/IT 담당자는 미팅을 갖게 됩니다. 응용 프로그램이 배포되기 전에 이런 자리가 마련되는 다행스러운 경우도 있으나, 응용 프로그램이 테스트 환경에서는 제대로 실행되었으나 사용자에게 공급된 후 속도가 크게 저하되는 경우처럼 문제가 발생한 후에야 미팅을 하게 될 때도 있습니다. 이 시점에서 바로 저와 같은 컨설턴트가 투입되기도 합니다.
개발자와 네트워크 담당자가 만나면 정보를 교환하는 것이 일차적인 목표입니다. 개발자는 응용 프로그램에 대해, 네트워크 담당자는 운영 환경에 대해 핵심적인 지식을 갖고 있습니다. 각 그룹은 상대편 그룹이 보유한 자료를 이해해야 하며, 응용 프로그램의 수명 주기에서 이러한 기회가 일찍 마련될수록 더 효과적입니다.
문제가 발생하고 나서야 처음으로 이러한 미팅이 열려서는 안 됩니다. 두 팀 간에 핵심적인 이해 기반이 조성되지 않은 상태에서는 응용 프로그램이 요구 사항에 미치지 못하는 이유를 밝혀내기가 결코 쉽지 않습니다. 게다가 오로지 상대방에게 문제가 있다는 방어적인 자세로 판단하기가 쉬우며, 그러한 판단은 결코 바람직하지 않습니다. 매우 복잡한 문제를 해결하려면 양측 모두의 노력이 필요합니다.
그러나 순조로운 상황에서도 그러한 미팅은 쉽지 않은 자리가 될 수 있습니다. 지금까지 제가 진행했던 미팅에서는 일반적으로 네트워크 담당자가 테이블의 한쪽에 앉고, 개발 담당자가 반대편에 앉는 상황이 전개되었습니다. 상대편을 응시하면서 시간이 흘러갑니다. 대화가 원활하게 진행되도록 하기 위해 회의의 목표, 즉 정보의 교환을 주지시킵니다. 누가 먼저 말하느냐는 중요하지 않습니다. 여기서는 네트워킹 팀이 개발 팀으로부터 어떤 정보를 얻어야 하는지에 대해 먼저 알아보겠습니다.

네트워킹 팀이 개발 팀에 확인해야 할 정보
ASP.NET 응용 프로그램마다 특이한 점이 있겠지만, 모든 경우에 공통적으로 적용되는 핵심적인 요소도 있습니다. web.config 파일도 그 중 하나입니다(그림 1 참조). Web.config는 개발 영역과 네트워킹 영역이 만나는 교차점입니다. 경우에 따라 개발자가 이를 구성하기도 하고 네트워킹 담당자가 구성하기도 합니다. 어떤 경우에서든 web.config의 내용은 하드웨어 및 네트워크 구성을 제한하며, 응용 프로그램의 작동 방법에 직접적인 영향을 줍니다. web.config 파일의 사소한 점까지 모두 살펴본다면 책 한 권을 채우고도 남을 것입니다. 여기서는 강조하고 싶은 점은 두 그룹 모두 web.config 파일을 연구하여 이 파일이 나타내는 구성의 의미와 다양한 설정이 응용 프로그램과 환경에 미치는 영향에 대해 합의해야 한다는 것입니다.
그림 1 응용 프로그램 설정과 사용자 지정 오류 구성을 보여 주는 기본적인 web.config(크게 보려면 이미지 클릭)
예를 들어, web.config의 <authorization> 섹션은 응용 프로그램에서 사용자를 인증하는 방법을 지정하고 종속성을 정의합니다. 응용 프로그램에서 Windows® 인증을 사용하는 경우 Active Directory®가 필요합니다. 폼 기반의 인증을 사용할 경우에는 사용자 계정의 데이터 저장소가 필요합니다. 이는 분명 의견을 나눌 만한 주제입니다.
<customErrors> 섹션은 오류가 사용자에게 어떻게 나타나는가에 관한 항목이므로 중요하지 않습니다. 복잡한 설정은 아니지만 어떤 오류 페이지가 표시될 것인가에 대한 이해를 돕고자 논의할 만한 가치는 있습니다. 협력 단계의 초기에는 사용자 지정 오류 페이지가 없을 것입니다. 이 점에 관해 의견을 나누는 것도 좋습니다.
web.config의 <appSettings> 섹션은 특히 중요한 의미를 가질 수 있습니다. 이 섹션은 일반적으로 개발자가 전역 변수(예: 데이터베이스 연결 문자열)를 저장하는 곳입니다. 중요한 종속성 소스이며 장애 조치, 마이그레이션 등을 계획할 때 핵심적인 부분을 차지합니다. 그러나 <appSettings>는 완전한 사용자 지정 섹션이므로, 무엇이든 포함할 수 있고 그 내용을 이해하려면 많은 설명이 필요할 수 있습니다. 이 섹션에는 실제로 응용 프로그램의 어느 곳에서도 쓰이지 않는 값이 남아 있는 경우도 많습니다.
개발자가 <appSettings>를 사용하지 않더라도 네트워크/운영 담당자가 원할 수도 있습니다. 모든 데이터베이스 연결 문자열을 여기에 저장하는 것은 간단한 장애 조치 전략을 수립할 수 있는 효과적인 방법 중 하나입니다. 데이터베이스 서버가 중단되면 대체 문자열을 삽입하여 다른 데이터베이스 서버로 연결할 수 있습니다. 개발 주기의 초기에 이러한 기회를 잘 활용한다면 응용 프로그램의 안정성과 유지 관리 편의성을 높일 수 있습니다.
마지막으로, 확장의 관점에서 볼 때 web.config에서 절대적으로 중요한 값 중 하나는 <sessionState> 태그입니다. 이 태그는 응용 프로그램의 세션 데이터가 저장될 위치를 결정합니다. 기본적으로, 세션 데이터는 "InProc", 즉 ASP.NET 응용 프로그램의 프로세스 영역에 저장됩니다. 세션 데이터가 in-process로 구성되는 경우, "Sticky" 부하 분산을 설정해야 합니다. 즉, 특정 사용자의 요청을 세션 데이터가 상주하는 동일한 서버에서 처리해야 한다는 것입니다. 이는 확장 및 장애 조치 방법에 직접적으로 영향을 주기 때문에 개발자와 네트워크 담당자 간에 중요한 대화 주제입니다. 이 사항을 일찍 협의하면 응용 프로그램 디버깅 단계에서 발생할 수 있는 많은 문제를 예방할 수 있습니다.
세션 상태에 관한 대화로 진행되면 응용 프로그램 전반의 부하 분산 요구 사항에 관해 얘기할 수 있습니다. 환경에 따라 특정 기능을 갖춘 부하 분산 전용 하드웨어가 있을 수 있지만, 응용 프로그램에서 이 기능을 제공하지 않더라도 큰 문제는 생기지는 않습니다. 이전에 in-process 세션 데이터가 있는 ASP.NET 응용 프로그램과 함께 하드웨어 부하 분산을 사용한 경우가 있었습니다. 그 결과, 이따금씩 어떠한 설명도 없이 세션 손실이 발생하곤 했습니다. 응용 프로그램의 버그처럼 보였으나 사실은 그렇지 않았습니다. 구성상의 실수였던 것입니다.
네트워크 팀은 해당 응용 프로그램에 어떤 부하 분산 체계가 사용될 것인지에 대해 개발 팀으로부터 정확하게 정보를 받아야 합니다. 사용 가능한 부하 분산 체계와 응용 프로그램의 허용 범위 등에 관해 의견을 나눔으로써 그러한 정보를 확인할 수 있습니다. 응용 프로그램 수명 주기에서 초반에 이러한 대화가 이루어질 경우 가장 큰 이점 중 하나는 out-of-process 방식의 비선호도(non-affinity) 부하 분산 체계로의 진행을 미리 계획할 수 있다는 것입니다.
ASP.NET 응용 프로그램의 배포 준비가 끝나거나 이미 초기 배포 단계에 들어 갔을 경우 개발 팀은 응용 프로그램의 빠른 영역과 느린 영역을 어느 정도 정확히 파악하게 됩니다. 무엇보다도, 시스템의 병목 현상과 잠재적 위험 지점을 알 수 있습니다. 네트워크/운영 팀이 이 병목 현상을 알게 되면 미리 문제에 대비하고 예방할 수도 있을 것입니다.
응용 프로그램 서비스가 중단되는 매일 밤, 대량의 데이터 로드 프로세스를 수행하는 응용 프로그램의 경우를 예로 들어 보겠습니다. 개발자는 데이터 로드 메커니즘을 작성하여 테스트했고 그 작동 방식을 파악했습니다. 이것은 데이터베이스에 상당한 부담이 되기는 하겠지만, 효과적이고 우수한 문제 해결 방법임을 알고 있었던 것입니다.
그러나 그들은 이 프로세스가 실행된다는 사실, 즉 데이터베이스 백업이 실행되는 새벽 1시에 이 프로세스가 실행되도록 예약했다는 사실을 네트워킹 팀에 알리지 않았습니다. 데이터베이스는 온라인 상태였으나 백업 중 실행 속도가 무척 느려졌습니다. 데이터베이스로 보내진 모든 트랜잭션이 트랜잭션 로그에 기록되었기 때문입니다.
데이터 로드와 백업이 동시에 실행되어 데이터베이스 트랜잭션 로그 볼륨이 디스크 공간을 모두 차지하고 나서야 이 충돌 사실이 드러났습니다. 데이터 로드 일정을 새벽 3시에 시작하도록 변경하고 나니 문제가 완전히 해결되었습니다. 그러나 며칠간 위기 상황을 겪은 후였습니다.
이러한 응용 프로그램 작업 부하 항목에 관해 일찍 대화를 나누면 향후 겪게 될 불편을 크게 덜 수 있습니다.

개발 팀이 네트워킹 팀에 확인해야 할 정보
미팅 중 네트워킹 팀이 개발 팀에게 설명하는 시간이 되면 먼저 네트워크 다이어그램으로 시작하는 것이 좋습니다. 개발자는 그림 2와 같이 네트워크를 인식하는 경우가 많습니다. 즉 네트워크 없이 웹 서버, 브라우저 및 인터넷만으로 구성된 모습입니다.
그림 2 네트워크에 대한 개발자의 단순한 시각(크게 보려면 이미지 클릭)
물론 현실은 이보다 훨씬 복잡합니다. 그림 3과 같은 다이어그램이 사실에 더 가깝습니다. 물론 이 역시 매우 단순화시킨 것입니다. 그림 3을 보면 "VPN(Virtual Private Network) 사용자는 응용 프로그램을 어떻게 사용할까?", "내부 사용자와 공용 사용자는 인증이 어떻게 다른가?"와 같은 의문점이 바로 떠오르게 됩니다.
그림 3 개발자가 알아야 할 실제 네트워크의 모습(크게 보려면 이미지 클릭)
물론 네트워크 다이어그램을 제시하는 것만으로는 충분하지 않습니다. 네트워크를 자세히 설명하는 것도 중요합니다. 단지 다이어그램을 보는 것만으로는 정확하게 어떤 요소가 응용 프로그램에 영향을 미칠 것인지 알 수 없기 때문입니다. 공용 사용자, VPN 사용자 및 내부 사용자의 실제 연결 프로세스를 자세히 설명해야 합니다. 그리고 다양한 방화벽 규칙이 있다면 그에 관해서도 설명합니다. 특히 복잡한 DMZ 유형의 네트워크 아키텍처에서는 응용 프로그램 측면에서 잠재적인 문제점이 대두되기 마련입니다.
물론 응용 프로그램이 배포되기 전이나 개발에 착수하기 전에 이러한 사항을 모두 협의하면 좋겠지만, 어느 시점에든 이러한 협의가 반드시 이루어져야 하며 참석한 모든 사람이 네트워크 다이어그램 전체를 제대로 이해하는 것이 중요합니다.
또한 네트워킹은 장애 조치와 중복성 모델이 적용되는 영역입니다. 그러나 소프트웨어적인 지원 또는 최소한 동작에 대한 인식마저 없다면 이 모델은 계획한 대로 작동하지 않을 것입니다. 만일에 발생할 수 있는 다양한 장애 조치 시나리오에 대한 세부적인 협의가 이루어져야 합니다. 데이터베이스에 클러스터링이 구현되는 경우 이는 데이터베이스 액세스 관련 코드에 영향을 미칩니다. 예를 들어, 서버 전환 후 쿼리를 재시도할 수 있는가, 중복 사이트가 있는 경우 그 사이트에 데이터가 어떻게 복제되는가, 다른 사이트로의 전환은 어떻게 이루어지는가 등을 확인해야 합니다.
여기서도 가급적 일찍 이러한 정보를 나누는 것이 유익하지만, 늦더라도 그러한 자리를 마련하는 것이 속수무책인 것보다는 낫습니다. 모든 응용 프로그램 관계자는 이러한 사항을 제대로 이해해야 합니다. 장애 조치 솔루션을 마련했으나 필요한 시점에 제대로 작동하지 않는 것만큼 최악의 경우는 없습니다.
마지막으로, 반드시 공유해야 할 또 하나의 중요한 네트워크 리소스는 프로덕션 로그입니다. 프로덕션 로그를 개발 팀에 제공할 것을 언제나 권장합니다. 이러한 요청에 대한 네트워크 팀의 통상적인 답변은 "개발 팀한테 우리에게 요청하라고 하세요. 그러면 보내주겠소."입니다. 이는 올바른 방법이 아니라고 생각합니다. 개발자가 주로 백업 사이트에서 스스로 로그를 검색할 수 있게 하는 것이 훨씬 더 효과적입니다.
문제가 발생했을 때 프로덕션 로그는 중요한 역할을 합니다. 이 로그는 발생한 상황에 대해 사실적인 이력 자료를 얻을 수 있는 최상의 단독 소스입니다. 그러나 이 로그는 위기 상황이 아닌 일반적인 상황에서도 유익하게 쓰입니다. 개발자가 프로덕션 로그에 일상적으로 액세스할 수 있으면 새로운 기능이 어떻게 작동하는지 직접 확인할 수 있습니다. 이는 해당 기능이 예상대로 작동하지 않음을 확인하고 위기로 확산되기 전에 문제를 바로잡을 수 있는 효과적인 방법입니다. 모든 관계자가 로그에 액세스할 수 있으면 보다 신속하게 문제에 대처하고 해결할 수 있습니다.

확장으로 돌아가기
네트워크 팀과 개발 팀 간의 미팅은 사실 ASP.NET 응용 프로그램 확장과 관련된 전체적인 문제를 이해하는 자리입니다. 응용 프로그램이 운영될 실제 환경은 응용 프로그램에서 실행하는 코드가 어떻게 작동할 것인가에 직접적인 영향을 줍니다. 또한 확장에 관한 모든 전략은 실제 환경에서의 동작에 영향을 줍니다. 응용 프로그램 중 SSL 관련 부분을 분리하는 전문성 전략을 적용할 경우, 네트워크 환경의 변경 그리고 아마도 서버 자체의 변경이 필요할 수 있습니다.
캐싱과 같이 코드 중심의 변경처럼 보이는 것도 환경에 영향을 줄 수 있습니다. ASP.NET 응용 프로그램에 데이터 캐싱을 추가하면 메모리 사용량이 늘어나는 대신 데이터베이스 호출의 수가 줄어들기 때문입니다. 그로 인해 필요한 ASP.NET 서버의 수나 서버의 작업자 스레드 재활용 수가 늘어날 수도 있습니다. 그러면 네트워크 모니터링 쪽에서 이벤트가 발생하게 됩니다.
ASP.NET 응용 프로그램 확장은 개발자와 네트워크 담당자 모두에게 영향을 주는 프로젝트입니다. 따라서 양쪽 모두 의사 결정 과정에 참여시키는 것이 효과적입니다. 이 팀들이 개별적으로 작업할 경우 결코 나오지 못할 독창적인 해결책이 그러한 협력을 통해 등장하는 경우도 많습니다. 예를 들어, 네트워크 담당자가 알고 있는 사내의 기존 하드웨어 솔루션이, 개발자가 성능 및 확장 요구 사항을 해결하는 데 도움이 될 수도 있습니다. 응용 프로그램과 환경의 세부 사항에 관해 의견을 나누다 보면 이러한 기회가 오게 됩니다.

협력
ASP.NET 응용 프로그램 확장을 위한 리소스:

  • 고성능 ASP.NET 응용 프로그램 개발
  • 방법: .NET 응용 프로그램 확장
  • 방법: .NET Framework 기반 응용 프로그램의 성능 조정 및 확장
  • 확장 가능한 아키텍처 구현
  • IIS 성능 극대화
  • ASP.NET 응용 프로그램 확장 전략
확장 프로젝트 중에 문제가 발생하는 것이 항상 나쁜 것은 아닙니다. 해당 응용 프로그램을 사용하길 원하는 수많은 사용자들이 문제를 제기한 만큼 그 응용 프로그램의 가치를 입증하는 것이므로 좋은 기회입니다! 응용 프로그램이 제대로 작동하게 하여 이러한 기회를 살려야 합니다.
다른 행사에 의해 확장 문제가 발생하는 경우도 있습니다. 회사에서 판촉 행사를 진행 중이거나 블로그에서 소개되는 경우 또는 어떤 커뮤니티 사이트를 통해 엄청나게 많은 이들이 한꺼번에 웹 사이트를 방문하는 상황을 예로 들 수 있습니다. 갑자기 응용 프로그램을 원활하게 운영되게 해야 하므로 전쟁을 치르게 된 셈입니다. 물론 이러한 시나리오가 실제로 발생하기 전에 조치를 취하는 것이 최선책입니다. 또한 협력을 통해 이러한 위기 상황을 어떻게 극복할 수 있는지 시연하면 개발자와 네트워크 담당자 간의 미팅을 성공적으로 마무리하는 데 도움이 됩니다.
위기 관리에서 가장 먼저 해야 할 질문은 "사이트가 부하로 인해 성능이 저하되고 있음을 어떻게 감지하는가?"입니다. "CTO의 전화를 받아서"라고 답하는 경우가 많습니다. 웹 사이트에 장애가 있음을 나타내는 첫 번째 징후가 외부인의 전화라면 문제가 있는 것입니다. 전화벨이 울리기 전에 문제를 알리는 적절한 측정 시스템을 갖춰야 합니다. 그렇다고 전화벨이 전혀 울리지 않을 수는 없겠지만, 적어도 답변을 준비할 시간을 벌게 됩니다. CTO에게 "정말입니까?"라고 대답하는 것은 귀하의 경력에 도움이 되지 않는 대처 방법입니다.
다음 질문은 누가 가장 먼저 전화를 받는가 그리고 상황에 누가 대처하는가 하는 것입니다. 대체로 네트워크 담당자가 첫 번째 경고를 접수하는데, 그 사람이 상대적으로 경험이 부족할 수도 있으므로 확실한 상부 보고 절차를 마련해야 합니다. 그 다음에 전화를 받을 사람을 결정해야 합니다. 이제 서둘러 조치를 취해야 합니다. 즉 신속한 진단을 통해 어떤 종류의 문제가 발생하고 있는지 규명합니다. 네트워크 가동 중단과 확장 문제는 전혀 별개의 사항입니다. 확장 문제의 경우 개발 팀원을 일찍 투입하는 것이 바람직합니다.
모든 관계자는 정확한 정보가 필요하므로, 효과적인 액세스 권한을 부여하는 것이 관건입니다. 효과적인 진단이 내려질 수 있도록 최대한 많은 정보를 배포하는 것이 목표이며, 그 진단에 따라 최종 솔루션의 범위가 결정됩니다.
코딩만이 유일한 해답이라면 코딩을 하기 전에 상황이 종료될 때가 많습니다. 물론 향후 개발 작업의 우선 순위를 정할 때 반영되도록 이벤트를 기록해야 하지만, 코딩 후 신중한 테스트도 거치지 않고 프로덕션 환경에 추가하는 것은 올바르거나 현명한 방법이 아닙니다. 어떤 경우에서든 상황을 악화시켜서는 안 된다는 것이 제1 원칙입니다.
확장과 관련된 문제에서는 그냥 기다리는 것이 해결책일 때도 있습니다. 그러나 이 역시 의사 결정 중 하나입니다.
이러한 비상 사태에 대한 계획은 다양한 기법을 신속하게 적용할 수 있음을 의미합니다. 확장 문제 해결에 네트워크와 개발 팀의 리소스를 모두 투입함으로써 매우 빠른 시간 내에 문제가 해결될 때가 많습니다. 판촉 행사를 더욱 성공적으로 마치는 결과를 가져올 수도 있습니다.
결론적으로, 네트워크 팀 입장에서 얻은 교훈은, 우수한 성능과 확장성을 갖춘 ASP.NET 응용 프로그램은 응용 프로그램을 개발한 팀과 이를 배포하고 운영하는 팀 간의 성공적인 협력의 산물이라는 것입니다.
이러한 협력은 반드시 필요하므로 가급적 일찍 두 팀이 만나 정보를 공유하는 것이 가장 좋습니다. 이 미팅의 목적은 응용 프로그램의 모든 요소, 응용 프로그램의 기능과 작동 방식, 종속성, 부하 상태에서의 동작, 시간의 경과에 따라 발생하는 문제에 대처하는 방법 등을 이해하고 합의하는 것입니다.
이러한 협력이 효과를 발휘한다면 문제가 발생했을 때 신속하게 대처하고, 향후 성공을 위해 응용 프로그램에서 필요로 하는 사항에 대한 명확한 목표를 설정해 전달할 수 있는 행동력 있는 기업으로 발전할 수 있습니다.

Richard Campbell은 Microsoft Regional Director이자 ASP.NET의 MVP로 활동 중이며, .NET 개발자를 위한 인터넷 오디오 토크쇼인 .NET Rocks(dotnetrocks.com)를 공동 진행하고 있습니다. 그는 수년간 여러 기업에서 ASP.NET의 성능과 확장에 관한 컨설팅을 수행해 왔으며, Strangeloop Networks의 공동 설립자이기도 합니다.


From the Editor Tech•Ed 생중계
Joshua Hoffman

매월 편집자 논평을 작성할 때마다 약간씩 고민하게 됩니다. 다루어야 할 흥미로운 주제는 항상 많기 때문에 주제를 선택하는 일은 그렇게 어렵지 않습니다. 문제는 거의 대부분의 사람이 읽기 약 6주 전에 편집자 논평을 작성해야 한다는 것입니다. 잡지 인쇄에 걸리는 시간 때문이기도 하지만, 잡지사 편집자가 모든 오류를 수정해야 할 충분한 시간이 필요하기 때문에 그렇습니다. 시간에 맞춰 적절히 대응할 수 있는 블로그와 달리, 이러한 방식으로 "뉴스"를 작성하는 것은 쉬운 일이 아닙니다. 이 글을 읽을 때 쯤이면 더 이상이 뉴스가 아닐 수 있기 때문입니다.
어쨌든 저는 지금 화창한 올랜도의 Tech•Ed 2008에 있으며, 지금 이 시각 매우 중요한 일들이 벌어지고 있습니다. 여러분이 이 글을 읽을 때 쯤에는 물론 지난 이야기일 수도 있지만 말입니다.
Tech•Ed는 여러 가지 이유로 우리에게 흥미로운 이벤트입니다. 무엇보다 저자를 포함한 수많은 독자를 직접 만날 수 있는 1년에 한 번뿐인 기회입니다. 거의 언제나 전자 메일, 인스턴트 메시징 및 전화 통화를 이용하긴 하지만 많은 사람들과 함께 다양하고 흥미로운 대화를 나누는 즐거움과 비교할 수는 없을 것입니다.
또한 Tech•Ed는 다음 해를 내다볼 수 있는 귀중한 시간입니다. 주요 경영진들이 앞으로의 방향을 제시하는 전략을 발표하며, 가상화, 차세대 웹, 시스템 관리의 혁신적인 개념 등에 대한 새로운 정보를 얻을 수 있습니다.
하지만 제가 여기에 온 주 목적은 Microsoft의 기술 전문가 겸 기고가인 Mark Russinovich가 보안 경계의 재정의를 주제로 하는 강연과, Steve Riley의 사라지는 네트워크 경계에 대한 경연을 듣기 위해서 입니다. 정말 흥미롭고 혁신적인 주제가 아닐 수 없습니다! 또 다른 목적은 Mark Minasi, Romi Mahajan, Dharmesh Godha와 함께 IT의 소비론에 대한 토론에 패널로 참가하기 위해서 입니다.
또한 TechNet Magazine에 기사를 쓰고자 하는 사람들을 위해 어떻게 시작해야 하는지를 소개해 보겠습니다. 지난 몇 년간 제가 얼마나 즐겁게 일했는지 그리고 몇몇 새내기 저자에게 어떤 도움을 주었는지 소개하는 프레젠테이션입니다. 이 글을 읽을 때 쯤에는 이 프레젠테이션 슬라이드가 제 블로그(blogs.technet.com/tnmag)에 게시될 예정이므로 자유롭게 방문해서 보실 수 있을 것입니다. 혹시 누가 압니까? 여러분이 내년 Tech•Ed에 저자 중 한 명으로 참석하게 될 수도 있으니까요!
Tech•Ed 파티도 빼놓을 수 없는 즐거움입니다. 사람들은 파티를 사랑하기 마련이죠.
—Joshua Hoffman

도움을 주신 Microsoft 기술 전문가: Sunil Agarwal, Eric Charran, Trina Gorman, Sanjeev Nair, Isaac Roybal, Jez Sadler, Roger Sprague, Stefan Stranger, Kevin Sullivan, Jim Truher, Alan von Weltin, Michael Walsh, Buck Woody.


Letters 독자의 목소리

SharePoint 콘텐츠 형식
Microsoft® SharePoint®에서 콘텐츠 형식을 사용하는 방법을 자세히 알아보기 위해 정보를 찾고 있습니다. 어디서 이 정보를 구할 수 있습니까?
—E.A.

이 정보를 제공하는 유익한 소스 중 하나가 Microsoft SharePoint 제품 및 기술 팀 블로그(blogs.msdn.com/sharepoint)입니다. 또한 사용자 지정 콘텐츠 형식으로 데이터 관리를 표준화하는 것에 관한 Pav Cherny의 글도 있습니다(technet.microsoft.com/magazine/cc194408). 엔터프라이즈 메타데이터 관리에 관한 백서(technet.microsoft.com/library/cc262729)도 도움이 될 수 있으므로 참조하십시오.
Andrew May의 블로그(blogs.msdn.com/andrew_may)도 소개합니다. Microsoft에서 프로그래머 겸 기고가로 활동 중인 Andrew는 Windows® SharePoint Services 3.0 및 Microsoft Office SharePoint Server 2007의 엔터프라이즈 콘텐츠 관리 기능에 관한 개발자용 설명서 집필을 담당하고 있습니다. 콘텐츠 형식에 관한 그의 블로그에서는 콘텐츠 형식을 다루고 SharePoint 환경에서의 엔터프라이즈 콘텐츠 관리의 복잡한 측면을 설명하는 기술 도해 포스터를 게시하고 있습니다.

한층 강화된 보안
"대논쟁: 은둔 보안 방식"(2008년 6월호, technet.microsoft.com/magazine/cc510319) 기사가 무척 좋았습니다. 하지만 Admin 이름의 변경만 중점적으로 다룬 것이 좀 아쉬웠습니다. 저는 Admin 이름 관련 논쟁에서 Roger Grimes와 Aaron Margosis의 의견에 대체로 동의합니다. 속수무책인 것보다는 나으며, 관리 측면에서 그리 심각한 문제를 일으킨다고 여겨지지 않기 때문입니다. 하지만 만만치 않은 과제들도 많습니다. Admin 공유가 언급되기는 했으나 토론자들이 이를 심층적으로 다루지는 않았습니다. 만약 이 공유가 차단된다면 정말 심각한 관리상의 문제가 야기될 것입니다.
또한 토론자들이 "공격 노출 영역을 줄이는 것"에 관해 찬반 토론할 기회가 있으면 좋겠습니다. 공격 노출 영역을 줄이는 것은 은둔 보안 방식을 약간 변형한 종류입니다. 삭제되는 것 대부분이 위치나 ID를 브로드캐스트하는 모든 것을 종료하는 것이니까요. 예를 들어, 은둔 보안 방식이라는 명목으로 IPv6를 삭제하는 고객을 꽤 많이 보았습니다. 눈 감고 환자의 몸 속으로 손을 집어 넣으면서 환자가 죽지 않길 바라던 중세의 의사들처럼 무턱대고 서비스를 제거하는 경우가 비일비재합니다.
—Shelly B.

초점이 Admin 이름 변경에 한정되었다는 귀하의 의견에 전적으로 동의합니다. 초안에는 다른 여러 예가 수록되었으나, 이를 편집하지 않았다면 기사의 분량이 20페이지에 달했을 것입니다! 그런 까닭으로, 중점적으로 다룰 대상 하나를 선정했고 admin 계정 문제가 가장 많이 언급되었던 것 같습니다. 하지만 걱정하지 마십시오. 곧 이 주제에 관한 추가 기사를 내놓도록 필자들을 독려하는 중입니다.

은둔성 부족
"대논쟁: 은둔 보안 방식"은 매우 유익한 기사였습니다. 그 내용에 관해 생각하던 중 두 가지가 떠올랐습니다. 첫 번째는 은둔에 대한 ROI(투자 수익률)가 충분히 높다면 이는 유익하다는 것입니다. 두 번째로, 대부분의 IT 보안은 언제나 은둔 구성 요소를 포함하고 있다는 사실을 깨달았습니다.
암호를 예로 들자면, 지금까지 점점 더 은둔성이 강한 암호가 만들어져 왔습니다. 초기에는 대부분의 PC에서 암호를 설정할 필요가 없었습니다. 그러다가 컴퓨터가 연결되기 시작하던 무렵에는 간단한 암호로도 충분했습니다. 연결이 증가하면서 8자 이상의 암호를 설정하는 것이 중요해졌습니다. 그마저도 충분히 안전하지 않은 시대가 도래하여 혼합 문자, 암호 구문 등이 등장하기 시작했습니다. 기존의 은둔 보호 장치로는 충분한 은둔성이 확보되지 못하는 상황이 계속 이어질 것 같습니다.
—Tom B.

매우 통찰력 있는 의견을 보내주셔서 감사합니다, Tom. 이러한 추세, 특히 다단계 인증(예: 스마트 카드 + 암호)과 같은 보안 개념이 더욱 보편화되는 상황에 관심을 가지고 지켜볼 필요가 있다고 생각합니다.

TechNet Magazine 포스터
몇몇 TechNet Magazine에 실렸던 Microsoft 포스터를 우리 회사의 개발자들을 위해 구하고 싶습니다. 구입할 수 있는 방법을 알려주시겠습니까?
—Helen G.

구입하실 수 있는 세 가지 포스터는 Microsoft Exchange Server 2007 구성 요소 아키텍처, Windows Server® 2008 Active Directory® 기능 구성 요소 및 Windows Server 2008 기능 구성 요소입니다. 미국과 캐나다에서는 800-444-4881 그리고 다른 국가에서는 785-838-7500으로 전화하여 주문하시면 됩니다.


Toolbox IT 전문가를 위한 신제품
Greg Steen

서버 모니터링
PA Server Monitor Pro
poweradmin.com/servermonitor
인프라의 모든 부분을 감시해야 합니다. 최종 사용자가 작업하기 전에 무엇인가 잘못되었음을 아는 것은 피해 제어 및 통신에 매우 중요합니다. (게다가 상사에게 잔소리를 듣는 것은 별로 유쾌한 일이 아닙니다.) 서버 인프라를 감시하는 데 도움이 되는 한 가지 도구는 Power Admin LLC의 PA Server Monitor Professional Edition입니다.
PA Server Monitor 설정 및 실행은 비교적 간단합니다. 특히, LAN에 있는 컴퓨터를 검색하고 자동으로 각각에 대한 모니터를 구성할 수 있는 응용 프로그램의 기본 Smart Configuration Process를 사용할 경우 매우 간단합니다. 검색 프로세스를 거치지 않으려는 경우 모니터 확인을 구성할 컴퓨터 목록을 가져올 수 있습니다. 그리고 컴퓨터를 구성했으면 GUI를 통해 해당 구성을 내보내어 다른 컴퓨터에 대한 템플릿으로 재사용하거나 다시 설치해야 하는 경우 백업으로 사용할 수 있습니다.
PA Server Monitor는 각 서버에 지정할 수 있는 18개의 다양한 모니터를 제공합니다. 이러한 모니터에는 디스크 공간, 이벤트 로그 오류, 원격 스크립트 실행, 파일 및 디렉터리 변경, CPU 및 메모리 사용률, 인터넷 제어 메시지 프로토콜(ping) 응답, Windows® 서비스 상태 모니터링 등과 같은 표준 확인이 포함됩니다.
또한 기본적인 포트 상태를 확인하고 명령 텍스트를 보내 사전 결정된 값에 대해 응답을 확인하는 TCP 포트 모니터링과 같은 여러 가지 편리한 모니터도 있습니다. 로그 파일 모니터링은 로그 파일에서 정규 표현식 또는 단순 텍스트로 정의할 수 있는 텍스트를 확인할 수 있습니다. 디렉터리 할당량 모니터는 최종 사용자가 자신의 한도를 초과하지 않도록 하는 데 도움이 되고 할당량을 초과할 경우 전자 메일로 사용자에게 알려줍니다. 실행하려고 하는 모든 사용자 지정 작업에 대해 스크립트 실행을 모니터링할 수 있습니다. 그리고 마지막으로 파일 사용 기간 모니터링을 사용하여 메일 큐를 감시하고 백업되지 않도록 할 수 있습니다.
서버에 대한 모니터를 정의한 후에는 모니터의 임계값에 도달할 경우 수행할 작업을 정의해야 합니다. PA Server Monitor는 전자 메일, 이벤트 로그, 메시지 상자, 로그 파일, 재시작 서비스, SNPP(Simple Network Paging Protocol), 사용자 지정 작업을 위한 사용자 지정 스크립트 등을 포함한 15가지의 기본 작업을 제공합니다. 작업을 정의할 때 모니터가 지정된 시간보다 오랫동안 오류 상태로 지속될 경우 추가 작업을 수행하는 작업 에스컬레이션 체인을 정의할 수도 있습니다. 예를 들어, 먼저 웹 사이트를 자동으로 다시 시작하는 작업을 설정할 수 있습니다. 그런 다음 다시 5분이 지난 후 계속 확인이 실패하면 사이트의 상태를 알려주는 전자 메일 메시지가 사용자의 핸드헬드 장치로 보내집니다.
시간이 지남에 따라 구성된 모니터에 대한 통계가 필요할 수 있습니다. PA Server Monitor에는 정보를 필요로 하는 사용자에게 정보를 제공할 수 있는 기본 보고 기능이 포함되어 있습니다. 기본 보고서에는 특정 서버의 통계 및 상태를 보여 주는 서버 요약, 모니터링된 각 컴퓨터에 대한 한 줄 설명을 제공하는 일반 요약 및 지리적으로 분산된 설정에 대한 상태 표시기를 보여 주는 그래픽 상태 맵이 포함됩니다. 보고서는 HTML로 생성되므로 웹 브라우저에서 액세스할 수 있으며, 운영 센터에서 알맞게 디자인할 수 있습니다. 또한 간단한 그래프 및 차트로 특별 보고서를 생성하거나 나중에 사용하기 위해 CSV 파일로 내보낼 수도 있습니다. 보고서를 예약하여 응용 프로그램에서 정기적으로 서버의 최신 통계를 전자 메일로 보내도록 할 수도 있습니다.
PA Server Monitor에는 에이전트가 없습니다. 한 가지 좋은 점은 응용 프로그램에 대한 서비스 컨텍스트가 충분한 권한으로 실행되어 네트워크에 있는 컴퓨터에 연결하고 WMI(Windows Management Instrumentation) 및 RPC(원격 프로시저 호출) 등 기타 관리 서비스를 통해 실행되는 한 빠르게 실행할 수 있다는 것입니다. 하지만 단점 중 하나는 원격 컴퓨터에 연결하는 데 필요한 상승된 계정 수준입니다. 물론 상승된 권한이 필요하지 않은 HTTP 및 SMTP와 같은 다른 유형의 서버 프로토콜 모니터도 있습니다.
또 다른 가능성 있는 단점은 복잡하고 분산된 인프라 및 네트워크 토폴로지에 있는 컴퓨터에 연결하는 것이 어려울 수 있고 도메인 및 네트워크 신뢰에 따라 달라진다는 것입니다. 따라서 결국 이 에이전트 없는 방식이 사용자의 환경에서 작동할지 여부는 인프라의 레이아웃과 서버 모니터링 솔루션으로 정확하게 무엇을 할 것인지에 달려 있습니다.
가격: 서버 1대 모니터의 경우 99달러(직판가) 또는 서버 5대 모니터의 경우 349달러(직판가)
PA Server Monitor Professional Edition으로 서버 감시(크게 보려면 이미지 클릭)

중복 파일 정리
dupeGuru
hardcoded.net/dupeguru
최종 사용자와 작업하거나 공유 사용자 디스크 공간을 관리한다면 시간이 지남에 따라 사용자 공간이 매우 어지러워진다는 것을 잘 알 것입니다. 이것은 대개 단일 사용자가 동일한 파일을 여러 위치에 저장하거나 많은 사용자가 동일한 파일을 여러 위치에 저장하기 때문입니다. 이러한 사용자 공간을 통합하고 정리하려면 중복 항목 검색기가 필수적일 수 있습니다. 한 가지 좋은 솔루션은 Hardcoded Software의 dupeGuru입니다.
이 도구는 대상 폴더나 드라이브에서 파일 이름과 내용을 보고 중복 항목을 검색합니다. 그러나 dupeGuru는 기본적인 문자열 비교를 넘어 근접 일치 알고리즘을 사용하여 다른 방법으로 누락될 수 있는 중복 항목을 찾습니다. 중복 항목이 표시되면 휴지통으로 보내거나 영구적으로 삭제하거나 다른 폴더로 이동하거나 최종 확인을 위해 기본 응용 프로그램에서 열 수 있습니다. 나중에 결과를 검토하려면 XHTML로 내보낼 수 있습니다.
기본 설정에서 파일을 검색할 때 파일 이름 및 내용 필터가 얼마나 철저하게 적용되도록 할지 결정할 수 있습니다. 그러면 발견되는 중복 항목의 수가 늘어나지만 중복 항목을 잘못 찾을 가능성도 높아집니다. 또한 dupeGuru에는 파일 이름에 특정 단어가 들어간 모든 중복 항목을 표시할 수 있는 기능도 있습니다. 이 기능은 사용자가 실수로 만든 모든 파일의 "복사본" 및 디렉터리에 만들어진 "새 폴더"라는 이름의 빈 폴더를 찾는 데 매우 유용합니다.
Windows 2000 이상 및 Mac OS X용 버전을 사용할 수 있습니다. 음악이나 사진의 중복 항목을 줄일 수 있는 방법을 찾는다면 전용 버전인 dupeGuru ME 및 dupeGuru PE를 각각 추천합니다.
가격: 19.95달러(직판가)
dupeGuru로 중복 파일 정리(크게 보려면 이미지 클릭)

환경 감시
pt360 Tool Suite PRO
packettrap.com
다양한 네트워크 모니터링 및 관리 도구를 보고 관리할 수 있는 단일 인터페이스가 있다면 매우 유용할 것입니다. 많은 시간(및 데스크톱 점유 공간)을 절약할 수 있을 뿐 아니라 통합된 환경에서 서로 다른 모니터링 도구 사이에 데이터를 공유하면서 한 번에 수많은 모니터를 조사할 수 있으므로 인프라의 상태를 더욱 완벽하게 파악할 수 있습니다.
이 제품을 구입할 의향이 있다면 PacketTrap Networks의 pt360 Tool Suite PRO를 추천합니다. 이 응용 프로그램은 중앙화 및 통합된 보고 기능과 함께 PacketTrap Networks 도구의 통합된 UI를 제공합니다. 가장 많이 사용하는 도구 및 인프라 상태 정보에 즉시 액세스할 수 있도록 도구 보기를 사용자 지정 대시보드로 만들고 구성할 수 있습니다. pt360 대시보드에는 전체 화면 모드로 전환하는 기능도 있습니다. 이 기능은 운영 센터의 팀원 누구나 빨리 화면을 보고 여러 네트워크 및 서버 리소스의 상태를 파악할 수 있으므로 유용합니다. 응용 프로그램은 다중 대시보드를 지원하므로 필요에 따라 환경에서 다양한 보기를 만들 수 있습니다.
대시보드를 설정하려면 드롭다운에서 여러 가젯을 선택하고 각 가젯을 클릭하여 구성하면 됩니다. 가젯은 Application, Networking, Devices, Availability 및 Other의 5가지 범주로 그룹화되고 SNMP(Simple Network Management Protocol) 및 WMI에 의존하여 서버, 응용 프로그램 및 네트워크 장치를 모니터링합니다. Application 가젯은 Active Directory®, Microsoft® Exchange Server 및 SQL Server®에 대한 연결을 제공하고 브라우저 도구도 제공합니다. Networking 가젯은 장치 인터페이스를 파악할 수 있도록 하고 최상위 10개의 평균 패킷 손실, 가장 높은 지연 시간 및 클라이언트당 인터페이스 사용량 보기를 제공합니다. Devices 가젯은 CPU 및 메모리 사용량, 사용 가능한 디스크 공간, 볼륨 목록, 네트워크 인터페이스 사용률 등에 대한 성능 지표를 제공합니다. 이러한 가젯은 구성 가능한 WMI 쿼리를 통해 실시간으로 서버의 성능을 감시하는 데 유용합니다. Availability 모니터는 컴퓨터의 작동 시간을 차트, 게이지, 텍스트 또는 목록 형식으로 보여 줍니다. 마지막으로 Other 가젯으로는 큰 디지털 시계가 있습니다.
pt360 Tool Suite에는 대시보드와 함께 네트워킹 도구가 제공됩니다. 예를 들면 Cisco Configurator가 있습니다. 이 도구를 통해 Cisco 장비의 구성 파일을 보관, 수정, 업로드, 다운로드 및 비교할 수 있습니다. 또한 세 가지 ping 도구가 제공되어 각각 정렬 가능한 테이블 보기를 제공하고, 그래픽 보기를 제공하며, IP 주소 그룹에 대해 빠르게 ping 검사를 수행할 수 있습니다. 기타 사용 가능한 검색 도구에는 MAC 주소 검색기, 포트 검색 도구, SNMP 검색기, WMI 검색 도구 등이 있습니다.
또한 Tool Suite는 syslog 서버로 작동하여 syslog를 지원하는 네트워크의 모든 장치에 대해 syslog 메시지를 전송, 수신, 로그 및 표시할 수 있습니다. 표시에서는 필터링도 지원하므로 문제의 메시지를 빠르게 격리하여 문제 해결 프로세스 속도를 높일 수 있습니다.
Tool Suite는 TFTP(Trivial File Transfer Protocol) 서버로 작동하여 네트워크의 장치 간에 파일을 빠르게 이동할 수 있습니다. 기타 도구에는 추적 라우팅, Whois 및 wake-on-LAN 기능이 있습니다. 물론 이 Tool Suite는 WMI 및 SNMP를 통해 호스트에 연결하는 중앙 관리 솔루션이므로 Tool Suite에서 연결을 위한 자격 증명 저장 방식이 중요합니다. 다행히 Tool Suite에서는 인프라를 모니터링하는 데 필요한 정보를 추가, 업데이트 및 삭제할 수 있는 256비트 AES(Advanced Encryption Standard) 암호화 자격 증명 저장소를 사용합니다.
가격: 단일 라이선스당 999달러(직판가)
그림 36 pt360 Tool Suite PRO로 시스템 모니터링(크게 보려면 이미지 클릭)

디스크 사용량 관리
TreeSize Professional
jam-software.com/treesize/index.shtml
"도대체 서버 디스크 공간을 모두 차지하고 있는 것이 뭐야!" 이 소리를 자주 들으십니까? 모니터링 응용 프로그램은 낮은 디스크 공간 임계값에 도달했음을 알려 주는 전자 메일 메시지만 전송했습니다. 좋습니다. 그러면 컴퓨터를 어떻게 정리하시겠습니까? 그리고 "Shift-Delete" 대상을 어떻게 빠르게 판단할 수 있습니까? (Shift-Delete는 휴지통을 거치지 않고 빠르게 삭제하는 방법입니다.) 호스트 모니터를 정상화하는 데 사용할 수 있는 한 가지 도구는 JAM Software의 TreeSize Professional입니다.
이 응용 프로그램은 Windows 2000 이상의 32비트 및 64비트 버전 Windows에서 실행되고, 어떤 파일이 드라이브의 공간을 차지하고 있는지 자세하게 파악할 수 있는 기능을 제공합니다. 원하는 드라이브를 선택하기만 하면 응용 프로그램에서 폴더 구조를 자동으로 검색합니다. 이 작업이 완료되면 드라이브에 대한 7가지 보기에 액세스할 수 있습니다. 첫 번째 보기는 파이 차트, 막대 차트 및 상대적 크기 상자 그래프의 3가지 분석 가능한 차트를 제공하는 Chart 보기입니다. 이러한 각 차트에서 여러 폴더로 드릴다운하여 공간을 많이 차지하는 대상을 빠르게 파악할 수 있습니다. 차트에 대한 색상 및 스타일을 사용자 지정할 수도 있습니다.
다음은 파일에 대해 정렬 가능한 테이블 보기를 제공하는 Detail 보기로, 이 보기에서 표시할 여러 가지 열을 선택할 수 있습니다. 사용자가 주로 선택하는 열에는 Microsoft Office 파일 작성자, 폴더의 평균 파일 크기, 이 파일이나 폴더가 차지하는 상위 디렉터리의 비율 및 하드 링크가 포함됩니다.
Extensions 보기에는 폴더를 드릴다운할 때 각 디렉터리에서 가장 많은 공간을 차지하는 파일 유형을 나타냅니다. Users 보기에는 문제의 사용자를 격리하는 데 필수적인 사용자 또는 시스템 계정 파일이 차지하고 있는 공간에 대한 복합 보기가 표시됩니다. File Ages 보기에서는 지난 기간(일, 월, 년)을 기준으로 수정, 작성 또는 액세스된 파일의 비율에 대한 그래픽 보기를 제공하여 보관하거나 안전하게 삭제할 수 있는 오래된 파일을 파악할 수 있습니다. 그리고 Top 100 보기에서는 드라이브에서 가장 큰 파일 100개를 표시합니다. 마지막으로 History 보기에서는 시간에 따른 드라이브의 사용량 패턴을 제공합니다.
이러한 7가지 각 보기는 나중에 사용하기 위해 인쇄, 저장 및 클립보드로 복사할 수 있습니다. 또한 TreeSize는 파일 검색 기능을 사용하여 가장 큰 파일, 가장 오래된 파일, 임시 파일, 인터넷 캐시 파일 및 중복 파일을 빠르게 격리할 수 있도록 하여 도구 모음을 통한 일반적인 정리 유지 관리 작업 속도를 높입니다. TreeSize Professional은 UNC 공유를 통해 네트워크를 검색할 수도 있지만, 발생하는 네트워크 오버헤드로 인해 많은 성능 저하가 따릅니다.
응용 프로그램에서는 명령줄 모드도 지원합니다. 명령줄 모드는 예약 및 야간 실행에 유용합니다. 또한 Scheduled Task 검색을 만들어 특정 경로를 검색하도록 구성하고 표준 일정에 따라 일련의 보고서를 생성하도록 할 수도 있습니다. 이 기능은 매일 밤 공유 사용자 공간을 모니터링하고 디스크 공간이 어떻게 사용되는지 감시하는 데 유용합니다.
테라바이트 용량의 전체 사용자 공간이 어떻게 모두 사용되었는지 궁금하다면 TreeSize를 통해 디스크 공간이 어떻게 사용되고 있는지 파악하고 더욱 효과적으로 관리를 시작할 수 있습니다.
가격: 단일 라이선스당 49.95달러(직판가)
TreeSize Professional로 디스크 사용량 관리(크게 보려면 이미지 클릭)

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가들의 운영, QA 및 개발 업무에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


SQL Q&A 분할, 일관성 확인 및 기타
Paul S. Randal

Q. 실수로 프로덕션 데이터베이스를 SQL Server® 2005 서버에 연결했는데, SQL Server 2000을 실행 중인 올바른 서버에 연결하려고 합니다. 단순히 데이터베이스를 분리한 다음 SQL Server 2000 서버에 연결하려고 시도했으며 백업 및 복원을 사용해서도 동일한 작업을 시도했지만 모두 제대로 되지 않았습니다. SQL Server 2000 서버에서 작동하지 않는 이유가 무엇입니까? 이 데이터베이스가 현재 가지고 있는 유일한 사본입니다.
A. 여기서 주의해야 할 첫 번째는 백업의 중요성입니다. DBA는 대개 손상이나 기타 심각한 재해로부터 복구하기 위한 백업의 필요성을 생각합니다. 하지만 이번 경우는 실수로 인한 업그레이드라 하더라도 업그레이드 중 무엇인가 잘못된 흔치 않은 사고입니다. 그래도 데이터베이스에 무슨 일이 발생할 경우를 대비하여 항상 최근의 전체 데이터베이스 백업을 가지고 있어야 합니다.
의도적이든 실수로 인한 업그레이드든 간에 업그레이드는 일방향 작업이며 되돌리기가 매우 어렵습니다. SQL Server 버전 간에 업그레이드할 경우 일련의 업그레이드 단계가 데이터베이스에서 수행됩니다. 각 단계에는 대개 데이터베이스에 대한 몇 가지 물리적 변경이 포함되고, 각 단계는 데이터베이스의 버전 번호를 높입니다.
예를 들어, SQL Server 2000에서 SQL Server 2005로 데이터베이스를 업그레이드할 경우 수행되는 주요 변경 사항 중 하나는 테이블, 인덱스, 열, 할당 및 데이터베이스의 관계 및 물리적 구조 관련 기타 세부 사항에 대한 다양한 메타데이터를 포함하는 데이터베이스의 시스템 카탈로그(시스템 tablesor 데이터베이스 메타데이터라고도 함)의 구조 변경입니다.
이러한 각 업그레이드 단계가 수행되면서 데이터베이스 버전 번호가 높아집니다. 예를 들어, SQL Server 7.0 데이터베이스의 버전 번호는 515, SQL Server 2000 데이터베이스의 버전 번호는 539, 그리고 SQL Server 2005 데이터베이스의 버전 번호는 611(또는 vardecimal 기능이 사용된 경우 612)입니다. 이를 통해 SQL Server에서 데이터베이스에 대해 수행된 마지막 업그레이드 단계를 알 수 있습니다.
SQL Server 릴리스는 더 최근의 SQL Server 릴리스로 업그레이드된 데이터베이스를 읽을 수 없습니다. 예를 들어, SQL Server 2000은 SQL Server 2005로 업그레이드된 데이터베이스를 읽을 수 없습니다. 이전 릴리스에는 업그레이드된 구조 및 데이터베이스 레이아웃을 해석하는 데 필요한 코드가 없기 때문입니다. 그리고 이로 인해 SQL Server 2005로 업그레이드된 데이터베이스를 SQL Server 2000에 다시 연결할 수 없게 되는 문제가 발생합니다.
전체 데이터베이스 백업이 없으므로 업그레이드된 데이터베이스에서 모든 데이터를 내보내고 수동으로 새로운 SQL Server 2000 데이터베이스로 다시 전송할 수밖에 없습니다. SQL Server 2005에서 아직 새로운 기능을 사용하지 않았다면 데이터베이스 구조를 스크립팅하고 SQL Server 2000에서 데이터베이스를 만든 다음 데이터 내보내기/가져오기 작업을 수행할 수 있습니다.
SQL Server 2005에서 데이터베이스를 스크립팅하려면 SQL Server Management Studio에서 개체 탐색기를 사용할 수 있습니다(데이터베이스를 마우스 오른쪽 단추로 클릭하고 작업을 선택한 다음 스크립트 생성 옵션 선택). 마법사는 이해하기 쉬우며 모든 개체, 인덱스, 제약 조건, 트리거 등을 만들기 위한 스크립트를 생성합니다.
Q. 최근 기본 테이블에서 테이블 분할을 사용하도록 스키마를 다시 설계했습니다. 이렇게 하면 성능 향상에 도움이 된다고 들었습니다. 데이터베이스는 단일 120GB 드라이브에 저장되고 테이블은 단일 파일 그룹에 포함되어 있습니다. 수행되는 슬라이딩 윈도우는 없고 단지 새 파티션만 매주 추가되며, 모든 데이터를 온라인에서 사용할 수 있어야 합니다. 대부분의 쿼리는 한 주 내의 데이터를 처리하고 지난 해의 데이터로 작업하는 경우는 가끔씩 있습니다. 단일 파일 그룹에서 작업하는 것이 더 쉬워 보입니다. 이 방법이 올바릅니까? 아니면 더 수행할 작업이 있습니까?
A. 단일 파일 그룹을 사용하는 것이 더 쉬울 수 있지만, 이 경우 분할 사용의 이점을 활용하지 못할 수 있습니다. 분할을 사용하는 주요 이유는 더욱 효율적인 데이터베이스 유지 관리 및 재해 발생 시 데이터 가용성 증가와 성능 향상을 제공하는 스키마를 생성할 수 있다는 것입니다.
분할의 전형적인 예는 각 파티션이 지난 해 한 달의 매출 데이터를 나타내는 12개의 파티션이 있는 매출 테이블입니다. 월말에 가장 오래된 파티션은 교체되어 나가고(및 보관 또는 삭제) 새 파티션이 교체되어 들어옵니다. 이것이 위에서 언급한 슬라이딩 윈도우 시나리오입니다. 현재 월의 파티션은 읽기/쓰기로 설정되고 이전 월은 읽기 전용입니다. 각 파티션은 별도의 파일 그룹에 저장됩니다. 이 스키마를 통해 분할의 모든 이점을 얻을 수 있지만 모든 환경에서 가장 최적은 아닙니다.
제 아내인 Kimberly는 더욱 효율적인 인덱싱이 가능하도록 위에서 설명한 스키마에 대한 변형을 생각해 냈습니다. 매출 테이블을 두 개의 테이블로 나누는 경우를 생각해 보겠습니다. 한 테이블에는 단일 읽기/쓰기 파티션이 있고 다른 테이블에는 11개의 읽기 전용 파티션이 있으며 두 테이블에 대한 분할된 뷰가 있습니다.
이렇게 되면 읽기/쓰기 테이블에는 적은 수의 인덱스가 허용되고, 읽기 전용 테이블에는 보고 쿼리를 지원하기 위한 더 많은 인덱스가 허용됩니다. 결과적으로 클러스터링되지 않은 인덱스를 그렇게 많이 유지 관리할 필요가 없어지므로 읽기/쓰기 데이터에 대한 DML(데이터 조작 언어) 작업 효율성이 크게 높아집니다.
또한 읽기/쓰기 데이터에 대한 쿼리에서 읽기 전용 데이터를 처리할 필요가 없습니다. 쿼리 계획에서 파티션 제거는 SQL Server 2005에서(특히, 복합 조건자가 있는 경우) 완벽하지 않지만, SQL Server 2008에서는 크게 향상되었습니다. 자세한 내용은 sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93에서 Kimberly의 블로그 게시물을 참조하십시오.
이와 관련하여 여러 파일 그룹에 대한 분할을 통해 사용할 수 있게 되는 몇 가지 기능을 설명하겠습니다.
부분적 데이터베이스 가용성 주 파일 그룹이 온라인 상태이면 재해 복구 중에 데이터베이스를 온라인 상태로 만들어 액세스 가능하도록 할 수 있는 기능입니다. 단일 파일 그룹만 있다면 복원 중 전체 데이터베이스를 사용할 수 없습니다. 데이터가 여러 파일 그룹에 분산되어 있다면 손상된 파일 그룹만 복원 중에 오프라인 상태가 되고 응용 프로그램은 계속해서 사용할 수 있습니다.
증분 복원 이 방식은 부분적 데이터베이스 가용성과 유사합니다. 단일 파일 그룹을 사용하는 경우 복원 단위는 단일 페이지 또는 전체 데이터베이스입니다. 여러 파일 그룹을 사용하는 경우 단일 파일 그룹만 복원할 수 있으므로 부분적 데이터베이스 가용성이 허용됩니다.
분할된 데이터베이스 유지 관리 위에서 설명한 두 분할 방식의 경우 모든 파티션이 단일 파일 그룹에 있더라도 파티션별 인덱스 조각 제거를 수행할 수 있습니다. 그러나 단일 파일 그룹을 사용하는 경우 데이터베이스 일관성 확인(DBCC)에서 처리해야 하는 데이터의 양(및 사용되는 CPU 및 I/O 리소스의 양)을 크게 줄일 수 있는 파일 그룹별 일관성 확인을 수행할 수 없습니다.
간단히 말해서 동일 파일 그룹 내에 여러 파티션을 포함할 수 있지만, 파티션과 파일 그룹 간에 1-1 매핑 관계가 있으면 많은 이점이 있습니다.
Q. 최근 하이엔드 데이터베이스 서버 중 하나에서 불량 메모리 보드로 인한 손상이 발생했습니다. 임의 데이터가 응용 프로그램에 나타나기 시작했을 때 이러한 사실을 알았습니다. DBCC CHECKDB를 실행했으며 모든 종류의 손상을 발견했습니다. 불행하게도 이러한 손상은 백업에서도 발견되어 잘못된 데이터를 수동으로 제거해야 했습니다.
간단히 말하면 결국 불량 하드웨어를 교체하고 페이지 체크섬을 설정했습니다. 정기적인 일관성 확인을 실행하고 싶지만, 유지 관리 기간이 충분하지 않고 2.4TB 데이터베이스는 확인하는 데 오랜 시간이 소요됩니다. 어떻게 하면 좋겠습니까?
A. VLDB(초대형 데이터베이스)에 대한 일관성 확인 및 기타 유지 관리 수행 방법의 문제는 점점 더 일반화되고 있습니다. 많은 DBA는 허용되는 유지 관리 기간보다 DBCC CHECKDB를 실행하는 데 오래 걸린다는 것을 발견하고 포기합니다. 어떤 경우에는 데이터베이스가 24x7 동안 사용되어 장기간 동안 DBCC CHECKDB에 필요한 CPU 및 I/O 오버헤드를 할당할 유효한 시간이 없습니다.
일관성 확인을 포기하고 실행하지 않는 방법(매우 권장되지 않음) 이외에 사용 가능한 4가지 방법이 있습니다. 개인적으로 고객이 이 4가지 방법을 모두 사용하도록 도와준 적이 있습니다.
DBCC CHECKDB의 WITH PHYSICAL_ONLY 옵션 사용 정기적인 DBCC CHECKDB에서는 많은 수의 논리 일관성 확인을 실행하고 많은 CPU(및 기본적으로 CPU 바인딩 작업)를 사용하게 됩니다. WITH PHYSICAL_ONLY 옵션을 사용하면 매우 빠른 DBCC CHECKALLOC 할당 비트맵 일관성 확인 실행으로 확인이 제한되고, 데이터베이스에서 할당된 모든 페이지를 읽고 감사하여 페이지에 존재하는 모든 페이지 체크섬을 테스트하게 됩니다. 그러면 DBCC CHECKDB가 매우 짧은 실행 시간의 I/O 바인딩 작업으로 전환됩니다. 사실, 전체 DBCC CHECKDB보다 더 크고 훨씬 빠른 경우가 많아 시간 절약에 많은 도움이 됩니다.
일관성 확인 작업 부하 나누기 이 방법에서는 데이터베이스의 테이블을 동일 크기의 그룹으로 분리(이를 수행하는 가장 쉬운 방법은 페이지 수별 분리)한 다음 DBCC CHECKTABLE 명령을 사용하여 매일 밤 단일 그룹의 모든 테이블에 대한 일관성 확인을 수행합니다. 따라서 예를 들어, 7개의 그룹을 하루에 하나씩 확인하고 DBCC CHECKALLOC 및 DBCC CHECKCATALOG를 1주에 1회씩 수행하면 1주일에 걸쳐 분산되기는 하지만 DBCC CHECKDB와 동일한 효과를 얻을 수 있습니다.
여러 파일 그룹으로 테이블 분할 사용 VLDB에서 가장 큰 테이블을 여러 파일 그룹으로 나눌 수 있습니다. 예를 들어, 읽기/쓰기 파티션을 포함하는 파일 그룹에 대해 매일 DBCC CHECKFILEGROUP을 실행하고, 읽기 전용 파티션을 포함하는 파일 그룹에 대해 매주 DBCC CHECKFILEGROUP를 실행하여 일관성 확인을 수행할 수 있습니다. 이 논리는 읽기 전용 데이터는 전체적으로 백업되고 일상적인 처리에 사용되지 않는다는 것입니다. 결과적으로 이 데이터에 대해서는 손상이 그렇게 치명적이지 않으므로 자주 일관성 확인이 필요하지 않습니다.
다른 서버로 일관성 확인 부하 이전 이 옵션에서는 정기적인 전체 데이터베이스 백업을 다른 서버로 복원하고 해당 서버에서 DBCC CHECKDB를 실행합니다. 그러면 일관성 확인 작업 부하가 프로덕션 서버에서 완전히 없어집니다. 그러나 손상이 발견될 경우 일관성 확인을 프로덕션 서버에서 실행해야 하는 단점이 있지만 이러한 경우는 매우 드뭅니다.
이와 같이, DBA가 VLDB에 대해 일관성 확인을 수행하고 전체 DBCC CHECKDB를 실행할 때 필요한 추가 리소스 부하를 줄이는 데 사용할 수 있는 많은 옵션이 있습니다. 앞에서 언급한 대로 저는 개인적으로 고객이 이 4가지 방법을 모두 사용하도록 도와준 적이 있습니다. 이러한 옵션은 분명 여러분에게도 도움이 될 것으로 생각합니다.
팁: 트리거를 사용하여 서버 쪽 논리 구현
일부 시나리오에서는 트리거로 서버 쪽 논리를 구현해야 합니다. 그러나 알아 두어야 할 유의 사항이 있습니다. 다음은 염두에 두어야 하는 몇 가지 중요한 사항입니다.
  • 트리거는 행별이 아닌 문별로 실행됩니다. 따라서 문의 영향을 받는 여러 행이 있거나 행이 없는 시나리오를 처리하도록 트리거 논리 내에 추가 논리를 두어야 합니다. 영향을 받는 행이 없더라도 트리거는 문별로 실행됩니다. 영향을 받는 데이터는 DML(데이터 조작 언어) 문의 가상 테이블 내에 포함됩니다. 이러한 테이블은 조인할 수 있으므로 데이터 작업이 가능합니다.
  • 트리거는 트랜잭션 내에서 동기적으로 실행됩니다. 응답 시간 또는 적정 시간 내에 반환될지 확실치 않은 외부 응용 프로그램을 호출하거나 외부 리소스에 액세스할 때마다 이 사항을 기억해야 합니다. 예를 들어, 테이블에 대해 Update 문을 실행하고 트리거가 해당 작업 내에서 실행될 경우 트랜잭션(Update 문의 암시적 트랜잭션)은 트리거의 모든 논리가 완료될 때까지 완료되지 않습니다. 외부 응용 프로그램이나 프로세스에서 오류 코드를 반환할 경우 SQL Server는 트랜잭션을 취소하고 롤백할 수 있습니다(구현된 오류 처리 및 오류 코드에 따라). 따라서 트리거 내에서 외부 작업을 수행해야 하고 이 작업이 트랜잭션에 중요하지 않거나 동일 범위 내에서 실행할 필요가 없는 경우 다른 프로세스로 확장하여 비동기 방식으로 데이터를 선택해야 합니다. SQL Server 2005에서는 이러한 작업을 비동기적으로 수행할 수 있는 SQL Server Service Broker를 도입했습니다.
  • 트리거 내의 문으로 인해 발생한 오류는 찾기가 매우 어렵습니다. 트랜잭션 내에 여러 테이블이 포함되어 있는 경우 오류 발생 시 트리거를 검사하고 적절한 오류 처리를 구현해야 합니다. 또한 데이터베이스 내에서 스키마를 변경할 경우에는 트리거 논리도 추적해야 합니다. 그렇지 않으면 작은 트리거라도 전체의 성능과 안정성에 큰 영향을 줄 수 있습니다. 스키마 변경과 관련된 대부분의 영향은 프로젝트 편집 중 자동 스키마 확인을 수행하고 정적 코드 분석으로 데이터 유형 불일치를 확인하는 Visual Studio® for Database Professionals를 사용하여 확인할 수 있습니다.
—Jens K. Suessmeyer, Microsoft 데이터베이스 컨설턴트

Paul S. Randal은 SQLskills.com의 관리 이사 겸 SQL Server MVP이며, 1999년부터 2007년까지 Microsoft의 SQL Server 저장소 엔진 팀에서 근무했습니다. DBCC CHECKDB/repair for SQL Server 2005를 작성했고 SQL Server 2008 개발 과정에서 핵심 저장소 엔진 부분을 담당했습니다. 재해 복구, 고가용성 및 데이터베이스 유지 관리 분야의 전문가인 Paul 이사는 각종 컨퍼런스에서 꾸준히 의견을 발표하고 있으며, 블로그 주소는 SQLskills.com/blogs/paul입니다.


Utility Spotlight Windows Installer CleanUp 유틸리티
Lance Whitney

현재 환경에 있는 PC 중 하나에서 응용 프로그램을 제거하거나 업데이트하려고 하는데 명령이 실행되지 않습니다. 응용 프로그램을 제거하거나 업데이트할 수 없다는 오류 메시지만 나타납니다. 이러한 상황이 자주 발생합니까? 그렇다면 분명 이 오류의 원인이 무엇인지 알고 싶을 것입니다.
Microsoft® Windows® Installer(MSI) 기술을 사용하여 설치된 소프트웨어는 특정 파일 및 레지스트리 설정을 기록합니다. 이러한 파일이나 설정 중 하나라도 없거나 손상되면 프로그램을 제거하거나 업데이트할 수 없으며 다시 설치하지 못할 수 있습니다. 이러한 경우 해결책은 프로그램을 완전하게 다시 설치할 수 있도록 모든 Windows Installer 정보를 제거하는 것입니다. 이를 위해 Microsoft는 Windows Installer CleanUp 유틸리티를 무료로 제공합니다.
Windows Installer CleanUp 유틸리티는 프로그램의 Windows Installer 구성과 연결된 모든 파일 및 레지스트리 설정을 삭제합니다. 이 도구는 프로그램의 실제 설치 파일이나 레지스트리 설정을 제거하지는 않습니다. 또한 이 도구는 프로그램 추가/제거 명령을 대체하거나 대신 사용할 수 없습니다.
대체로 프로그램 추가/제거 또는 기타 방법을 통해 응용 프로그램을 제거하거나 업데이트할 수 없는 경우 이 유틸리티를 사용할 수 있습니다. Windows Installer 정보를 삭제하면 응용 프로그램을 다시 설치할 수 있습니다. 그런 다음 프로그램을 설치된 상태로 두거나 업데이트 또는 제거할 수 있습니다.
PC에 있는 모든 Windows Installer 기반 응용 프로그램 목록을 보여 주는 Windows Installer CleanUp 유틸리티(크게 보려면 이미지 클릭)
프로그램의 Windows Installer 데이터를 제거하는 Microsoft 명령줄 프로그램인 msizap에 대해 잘 아는 사용자도 있을 것입니다. 이 명령도 이러한 상황에서 사용할 수 있습니다. 하지만 Windows Installer CleanUp는 msizap보다 사용이 간편하므로 더 이상 까다로운 명령줄 옵션을 사용할 필요가 없습니다.
유틸리티를 설치하면 Program Files 아래에 Windows Installer Clean Up이라는 하위 디렉터리가 생성됩니다. 이 하위 디렉터리에는 msicuu.exe, msizap.exe, readme.txt의 3개 파일이 있습니다. msicuu.exe 파일은 PC에 있는 모든 Windows Installer 기반 응용 프로그램 목록을 표시하여 원하는 프로그램을 선택, 선택 취소 및 제거할 수 있도록 합니다. 그런 다음 이 프로그램은 선택 항목을 msizap.exe 명령으로 전달하여 선택된 응용 프로그램에 대한 Windows Installer 정보를 제거합니다.
Windows Installer CleanUp을 실행하려면 시작 메뉴 | 모든 프로그램으로 이동하여 해당 폴더를 찾은 다음 Windows Installer Clean Up 바로 가기를 클릭합니다. 그러면 스크린샷에 나온 대로 PC에 있는 모든 Windows Installer 기반 응용 프로그램 목록을 볼 수 있습니다. 문제가 있는 응용 프로그램을 선택하고 제거 단추를 클릭합니다. 그러면 응용 프로그램이 Windows Installer 데이터베이스에서 삭제되어 완전히 다시 설치할 수 있습니다.
CleanUp 도구를 실행하면 응용 프로그램이 더 이상 프로그램 추가/제거에 나타나지 않는다는 것을 알 수 있습니다. 따라서 응용 프로그램을 완전히 제거하고자 하는 경우 우선 다시 설치해야 합니다. Windows Installer CleanUp은 대개 MSI 파일로 패키지된 설치 방식의 Windows Installer 기술을 사용하는 소프트웨어에 대해서만 사용할 수 있습니다.
마지막으로 Windows Installer CleanUp을 실행하려면 관리자로 로그인해야 합니다. 이 도구는 모든 32비트 및 64비트 버전의 Windows와 호환됩니다. 유틸리티에 대한 자세한 내용을 보고 싶거나 소프트웨어를 다운로드하려면 support.microsoft.com/kb/290301을 방문하십시오.

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 분석하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 발을 들여 놓았습니다.


Inside SharePoint 메시징 통합 문제 해결
Pav Cherny

코드 다운로드 위치: SharePoint2008_08.exe (416KB)
목차
일반적인 문제 해결 방식
SharePoint 메시징 아키텍처
진단 정보 얻기
아웃바운드 메시지 전송
인바운드 메시지 전송
디렉터리 관리
결론
잘 설계된 SharePoint 환경에서 정보 근로자는 공동 작업을 위해 통신 습관이나 작업 방식을 변경할 필요가 없습니다. 정기적으로 공동 작업 사이트를 수동으로 확인하는 대신 SharePoint에서 문서 및 경고, 미리 알림 등의 기타 정보를 사서함으로 직접 배달할 수 있습니다.
사용자들은 이러한 메시지에 회신하거나 새 항목을 전자 메일 메시지로 문서 라이브러리 및 목록에 전송하여 워크플로에 참여할 수도 있습니다.
하지만 SharePoint®를 보안 메시징 환경에 통합하는 작업에는 해결 과제가 따르며, 비-SharePoint 구성 요소가 SharePoint 기반 공동 작업에 영향을 줄 수도 있습니다. 해결 과제는 통합 환경에서 문제가 발생할 때마다 문제의 근본 원인을 효율적으로 격리하고 없애는 것입니다.
이 칼럼에서는 빠른 결과를 제공하는 입증된 문제 해결 전략을 기반으로 SharePoint 메시징 통합에 대해 설명합니다. 여기서는 문제 지점을 효율적으로 찾아낸 다음 더욱 자세하고 상황에 맞는 문제 해결 단계로 접근합니다.
대형 조직에서 이 단계별 조사는 초기 분석 후 다른 전문가에게 문제 처리를 넘기는 것을 의미하며, 특히 문제가 비-SharePoint 구성 요소와 관련된 경우 그렇습니다. 반면 중소 규모 조직에서는 한 명의 IT 관리자가 모든 관련 시스템에 대해 직접 문제 해결을 수행하는 것이 일반적이며, 이러한 경우 구조화된 방식이 더욱 필요합니다.
이 칼럼의 연습에서는 Active Directory®, Exchange Server 2007 및 WSS 3.0의 테스트 환경을 사용합니다. 이 테스트 환경을 구성하는 단계별 지침과 이 칼럼 및 관련 자료에서 언급된 문제 해결 도구는 TechNet Magazine 웹 사이트의 코드 다운로드 섹션에서 얻을 수 있습니다.

일반적인 문제 해결 방식
다른 상호 운용성 시나리오에 비해 SharePoint 메시징 통합 문제 해결에는 구조화된 방식이 더 필요합니다. 이 노력을 복잡하게 만드는 몇 가지 요소가 있습니다.
분명 여러분은 복잡한 기술을 다루어야 하고 메시징 전송 문제, 메시지 형식 변환, 보안 측면 및 디렉터리 관리 문제를 처리하면서 일부 SharePoint 오류 메시지가 혼란스럽게 느껴질 수 있습니다. 메시징 통합이 작동하도록 하려면 모든 웹 응용 프로그램을 SharePoint 중앙 관리의 응용 프로그램 풀 ID로 실행해야 한다는 것처럼 인터넷 뉴스 그룹은 잘못된 길로 안내할 수 있는 해결되지 않은 토론 주제와 제안으로 넘쳐납니다.
그러나 긍정적인 측면도 있습니다. SharePoint는 매우 유연합니다. 사실, 여러분이 어디를 찾아봐야 하는지 알고 있다면 자세한 문제 해결 정보를 얻을 수 있습니다. 몇 가지 기본적인 스크립트를 사용하여 문제 해결 효율성을 크게 높일 수 있습니다.
첫 번째 문제 해결 목표는 다루고 있는 특정 문제를 이해하는 것입니다. 문제가 어디에 있고 어떤 구성 요소가 관련되어 있는지 파악해야 합니다. 또한 다른 시스템 구성에서 문제를 재현해 보고 Windows® 이벤트 로그 및 텍스트 기반 로그 파일을 조사해야 합니다. 그러나 일부 문제의 경우 산발적으로만 발생하기 때문에 혼란스러울 수 있습니다. 그래도 문제를 잘 재현할수록 근본 원인을 더욱 빠르게 파악하고 없앨 수 있습니다. 자주 간과되는 또 하나의 중요한 목표는 모든 구성 변경 및 수정 내용을 기록하고 환경의 모든 관련 시스템(예: 웹 팜의 모든 프론트 엔드 서버)에 적용되었는지 확인하는 것입니다.

SharePoint 메시징 아키텍처
메시징 통합과 관련된 문제에 직면할 때마다 문제 해결을 시도하기 전에 우선 커피나 차 한 잔을 든 다음 SharePoint 메시징 통합 아키텍처를 검토하는 것이 좋습니다. 그렇지 않으면 잘못된 문제나 구성 요소를 수정하게 될 수 있습니다. 예를 들어, 나중에 살펴보겠지만 Active Directory에서 연락처 개체를 만들 수 없는 "액세스 거부" 오류가 발생했다고 해서 Active Directory에서 액세스 권한을 수정해야 하는 것은 아닙니다.
어떠한 경우든지 메시징 통합에 관련된 각 구성 요소의 역할과 개별 구성 요소가 서로 어떻게 상호 작용하는지 이해하는 것이 중요합니다. 그림 1을 보면 SharePoint-Exchange 연결 시나리오에서 중요한 구성 요소를 확인할 수 있으며, 다음 섹션에서 이에 대해 자세히 설명합니다.
그림 1 SharePoint 메시징 통합 아키텍처(크게 보려면 이미지 클릭)

진단 정보 얻기
가장 중요한 문제 해결 도구 중 하나는 믿을 수 있는 진단 정보입니다. 기본적인 도구는 Windows 이벤트 로그입니다. 무엇보다 SharePoint 중앙 관리(작업 페이지의 기록 및 보고에서 진단 로깅 클릭)를 사용하여 SharePoint에서 웹 서버의 Windows 이벤트 로그에 작성하는 상세 정보 수준을 제어할 수 있습니다. 별로 중요하지 않은 이벤트는 이벤트 로그 및 추적 로그에 기록되도록 지정할 수 있습니다. 추적 로그(기본적으로 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs에 위치)는 낮은 수준의 정보를 찾는 경우 매우 유용하지만, 매우 빨리 가득 차게 되므로 이 기능은 자주 사용되지 않습니다.
진단 정보를 얻을 수 있는 또 하나의 방법은 관련 자료의 Web Application Config.pdf에 설명된 대로 해당하는 web.config 파일을 구성하여 영향을 받는 웹 응용 프로그램에 대한 디버깅을 사용하는 것입니다. SharePoint는 사용자 인터페이스에 직접 자세한 추적 정보를 표시합니다. 이 방식의 장점은 많은 양의 추적 데이터를 분석하지 않고도 관련 오류 정보를 확인할 수 있다는 것입니다. 단점은 웹 응용 프로그램의 시스템 구성을 변경해야 한다는 것입니다. 원본 web.config 파일을 백업한 다음 문제 해결을 마친 후 원래 구성으로 되돌려야 한다는 것을 잊지 마십시오.
SMTP 서비스를 구성하여 자세한 처리 정보를 SMTP 프로토콜 로그에 작성하도록 할 수도 있습니다(IIS 관리자의 일반 탭에서 로깅 사용 확인란 선택). ODBC 로깅을 사용할 계획이 없더라도 관련 자료의 SharePoint Messaging Integration.pdf에 설명된 대로 SMTP 서비스 기능과 함께 ODBC 로깅 모듈을 설치하십시오. 그렇지 않으면 SMTP 서비스에서 프로토콜 로그를 작성하지 않습니다. 기본적으로 SMTP 프로토콜 로그는 %SystemRoot%\System32\LogFiles\SmtpSvc1에 있습니다. SMTP 통신을 상세하게 분석하고 SharePoint 서버에서 메시지가 전송되었는지 확인할 수 있도록 하는 것은 텍스트 파일입니다.
SMTP 서비스와 통신하는 허브 전송 서버의 송신 커넥터 및 수신 커넥터 구성에서도 프로토콜 로깅을 사용하도록 설정할 수 있습니다(SharePoint Messaging Integration.pdf 참조). 메시지 추적, 큐 뷰어, 파이프라인 추적 등 기타 다양한 도구를 사용하여 메시지가 허브 전송 서버 및 사서함 서버를 거쳐 Exchange Server 2007 환경에서 이동하는 경로를 확인할 수 있습니다. Exchange Server 2007 메일 흐름 문제 해결에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkID=120145의 "전송 및 메일 흐름 문제"를 참조하십시오.
Active Directory 도메인 컨트롤러의 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics에서 해당하는 레지스트리 항목을 설정하여 디렉터리 액세스 및 기타 범주에 대한 진단 로깅을 사용함으로써 자세한 문제 해결 정보를 수집할 수 있습니다. 범주에 대한 0x0 값은 중요한 이벤트만 기록하는 것을 의미하고, 0x5 값은 디버그 정보를 포함한 모든 이벤트를 기록하는 것을 의미합니다. 0x3보다 높은 로깅 수준을 사용하면 서버 성능이 저하되고 Windows 이벤트 로그가 빨리 가득 찰 수 있습니다. 일반적인 작업 중에는 모든 값이 0x0으로 설정되어야 합니다.
문제 해결 시 SharePoint, Exchange 및 Active Directory 서버의 자세한 진단 정보를 수집하면 문제 지점을 빠르고 확실하게 찾는 데 도움이 됩니다. 이러한 시스템 간의 통신은 대부분 컴퓨터 네트워크를 통해 이루어지므로 TCP/IP 도구(ping, tracert, telnet 등) 및 네트워크 모니터와 같은 추가 문제 해결 도구도 유용할 수 있습니다. Microsoft® Network Monitor 3.1은 go.microsoft.com/fwlink/?LinkId=120143에서 다운로드할 수 있습니다.

아웃바운드 메시지 전송
리소스
  • SharePoint 제품 및 기술 웹 사이트
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services 개발자 센터
  • Microsoft SharePoint 제품 및 기술 팀 블로그
이벤트 로그, 추적 로그, 프로토콜 로그, 메시지 추적 로그 및 네트워크 추적이 설정되어 있으면 SharePoint 메시징 통합 관련 문제를 해결할 준비가 된 것입니다. 간단한 부분인 아웃바운드 메시지 전송부터 시작해 보겠습니다. SharePoint는 다양한 구성에서 아웃바운드 메시지 전송을 지원하고 웹 서버의 로컬 SMTP 서비스를 필요로 하지 않습니다. 하지만 완전한 메시징 통합 시나리오에서는 로컬 SMTP 서비스를 사용하는 것이 권장되는 구성입니다. 그림 2는 시나리오의 주요 구성 요소를 보여 줍니다.
그림 2 아웃바운드 메시지 전송(크게 보려면 이미지 클릭)
이 메시징 시나리오에는 네 단계가 포함됩니다. 즉, SharePoint에서 SMTP 서비스에 메시지를 전송해야 하고, SMTP 서비스에서 메시지를 처리해야 하며, 허브 전송 서버에서 메시지를 수신해야 하고, Exchange Server 2007에서 메시지를 최종 대상에게 전송해야 합니다.
SharePoint에서 SMTP 서비스에 메시지를 전송할 수 없는 경우 일반적으로 사용자 인터페이스에서 전자 메일 알림을 전송할 수 없다는 오류를 받게 됩니다. SMTP 서비스가 실행되지 않기 때문일 수 있습니다. 또는 SMTP 프로토콜 로그에 SMTP 서비스가 오류 코드 550(요청된 작업을 수행할 수 없음: 사서함 사용 불가)과 함께 제출 시도를 거부했다고 기록되면 문제가 SMTP 서비스에 있다는 것을 나타냅니다.
SharePoint 문제가 아닌지 확인하려면 기본 스크립트(관련 자료의 SMTP.vbs 참조)를 사용하여 동일한 발신자 및 수신자 정보로 SMTP를 통해 테스트 메시지를 제출할 수 있습니다. SMTP 서비스 문제라면 스크립트가 성공하지 못합니다. 사실, 이 스크립트는 그림 3에 표시된 대로 SharePoint에서 디버깅을 사용해도 알아낼 수 없는 문제의 근본 원인에 대한 귀중한 단서를 제공합니다.
그림 3 메시지를 릴레이할 수 없음(크게 보려면 이미지 클릭)
SMTP 서비스 구성에서 웹 서버 릴레이 권한을 부여하고 SMTP 서비스를 다시 시작하면 SharePoint 메시지 제출 문제를 해결할 수 있습니다. 그러면 메시지는 SMTP 서비스에 도달하는데, 이제 중요한 문제는 SMTP 서비스에서 허브 전송 서버로 메시지를 라우팅할 수 있는지 여부입니다.
메시지가 Queue 폴더에 남아 있다면 SMTP 서비스가 허브 전송 서버에 연결할 수 없는 것입니다. 이 경우 Microsoft Exchange Transport 서비스가 실행되지 않기 때문이거나 네트워크 통신 또는 구성 문제 때문일 수 있습니다. Telnet 클라이언트를 사용하면 내부 통신을 위해 구성된 수신 커넥터의 대상 포트에 연결할 수 있는지 여부를 쉽고 빠르게 확인할 수 있습니다.
반드시 TCP 포트 25가 아닐 수 있습니다. 사실, SMTP 서비스에서 이 포트를 사용할 경우 익명의 메시지 제출을 차단하도록 구성된 허브 전송 서버에 대한 기본 수신 커넥터에 메시지를 전송할 수 있습니다. 이 경우 Drop 폴더에서 메시지를 볼 수 있습니다. 이 경우 Windows SharePoint Services Timer 서비스가 중지되어 있어야 합니다. 그렇지 않으면 몇 초 후 메시지가 사라집니다. 메시지 파일은 메시지가 "진단 코드: smtp;530 5.7.1 클라이언트가 인증되지 않았습니다"로 거부되었음을 나타내는 배달 상태 알림입니다.
이 문제를 해결하려면 SharePoint 서버에 대한 전용 수신 커넥터를 만들어야 합니다. SharePoint 서버는 내부 시스템이므로 외부 보안 인증 옵션을 선택합니다. 그러면 확장 권한을 ANONYMOUS LOGON 계정에 부여하지 않아도 됩니다. 또한 IPsec를 사용하여 SharePoint 서버와 허브 전송 서버 간 통신을 보호하는 방법을 고려해 보십시오.
메시지가 SMTP Queue 폴더에서 나가고 SharePoint 서버 및 허브 전송 서버의 SMTP 프로토콜 로그(%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive 폴더 확인)가 성공적인 메시지 전송을 나타낼 경우 Exchange Server 2007에서 메시지를 대상으로 라우팅할 수 있다면 작업이 완료되었다고 생각할 수 있습니다. 메시지가 원하는 Exchange 수신자에게 배달되지 않을 경우 앞에서 언급한 대로 Exchange Server 2007에 포함된 메일 흐름 문제 해결 도구를 사용하여 문제를 조사하십시오. 이 단계에서는 잘못된 수신자 정보, 스팸 필터 및 메시지 크기 제한으로 인해 최종 대상에 도달하지 못할 수 있습니다.

인바운드 메시지 전송
반대 방향의 메시지 전송은 잠재적인 문제가 있기 때문에 좀더 복잡합니다. 예를 들어, SharePoint 제품 설명서에서는 SharePoint 전자 메일 도메인에 대해 DNS에서 MX 레코드 구성을 권장하고 있는데 이 경우 Exchange 조직에서 메시지가 잘못 라우팅될 수 있습니다.
Exchange Server 2007에서는 연결된 주소 공간과 함께 송신 커넥터를 사용하여 메시지를 전송합니다. 이 경우 SharePoint 서버가 내부용이더라도 SharePoint 메시지를 인터넷을 통해 전송하기 위해 Edge 전송 서버로 라우팅할 수 있습니다. 내부 메시지 전송의 경우 대신 상세 주소 공간과 함께 송신 커넥터를 사용하고 SMTP 서비스를 실행하는 SharePoint 서버를 커넥터 구성에서 스마트 호스트로 지정합니다(관련 자료의 SharePoint Messaging Integration.pdf 참조). 전용 브리지헤드 서버로 잘 정의된 라우팅 토폴로지를 설정하면 Exchange에서 SharePoint로 신뢰할 수 있는 메시지 전송이 가능합니다.
메시지가 SharePoint 서버에 도달하는지 확인하려면 Windows SharePoint Services Timer 서비스를 중지합니다. 그림 4에 표시된 대로 Timer 서비스는 메시지를 처리하고 수신자 전자 메일 주소와 연결된 문서 라이브러리에 첨부 파일을 배치하기 때문에 메시지는 Drop 폴더에 쌓입니다. 메시지가 Drop 폴더에 도착하지 않으면 허브 전송 서버에서 큐 뷰어를 사용하여 Exchange에서 메시지를 제대로 라우팅하는지 확인합니다. 그런 다음 허브 전송 서버가 SharePoint 서버의 SMTP 서비스와 통신하는 것을 막을 수 있는 네트워크 통신 문제를 조사합니다.
그림 4 인바운드 메시지 전송(크게 보려면 이미지 클릭)
Timer 서비스를 다시 시작하면 메시지 항목이 Drop 폴더에서 사라지는 것을 확인할 수 있습니다. 하지만 Windows 이벤트 로그에 SharePoint에서 성공적으로 메시지를 처리했다고 기록되더라도 메시지 첨부 파일이 대상 라이브러리에 문서로 남지 않으면 Exchange에서 Exchange RTF 형식으로 메시지를 전송했음을 의미합니다. 이 문제를 조사하려면 Timer 서비스를 다시 중지하고 Outlook® 클라이언트에서 첨부 파일이 있는 다른 메시지를 전송한 다음 Drop 폴더에 도착하면 메모장에서 메시지를 엽니다. 이제 "winmail.dat" 문자열을 검색합니다. 이 문자열을 찾을 경우 Exchange Server에서 잘못된 형식으로 메시지를 전송하고 있는 것입니다.
SharePoint에서는 메시지 첨부 파일을 MIME 또는 UUENCODE 형식으로 인코딩해야 합니다. 또한 SharePoint에서는 winmail.dat 관련 처리 문제를 Windows 이벤트 로그에 표시하지 않습니다(그림 5 참조). 이 경우 첨부 파일이 문서 라이브러리에 나타나지 않습니다. 메모장을 문제 해결 도구로 사용하고 Exchange 관리 콘솔에서 SharePoint 전자 메일 도메인에 대한 원격 도메인 정의를 구성하여 형식 문제를 해결합니다. "저널 보고서의 첨부 파일로 보낸 원본 메시지의 형식" 탭의 "Exchange 서식 있는 텍스트 형식"에서 "사용 안 함"을 선택합니다.
그림 5 Winmail.dat 메시지 처리(크게 보려면 이미지 클릭)

디렉터리 관리
유용한 Timer 서비스 이벤트 중 하나는 수신 전자 메일 파일 처리 중 알 수 없는 별칭으로 인해 오류가 발생했음을 알려 주는 이벤트 6873입니다. 이 오류는 Exchange 사용자가 메시지를 전송할 때 존재하지 않는 문서 라이브러리와 같이 잘못된 SharePoint 전자 메일 주소를 지정할 경우 발생합니다.
이 문제는 SharePoint 중앙 관리의 수신 전자 메일 설정에서 Active Directory에서 메일 사용 문서 라이브러리에 대한 수신자 개체를 만들도록 디렉터리 관리 서비스를 구성하여 완화할 수 있습니다. 그러면 Exchange 사용자들은 올바른 주소 정보가 있는 수신자 개체를 주소록에서 편리하게 선택할 수 있습니다.
하지만 이렇게 하면 수많은 문제점이 발생하게 됩니다. 이 기능은 웹 서버에서 권한 요구 사항을 상승시키기 때문에 최소 권한의 원칙을 기반으로 하는 보안 시스템 구성에서 디렉터리 관리 서비스를 제대로 실행할 수 없습니다. 더욱이, 제품 설명서(예: technet.microsoft.com/library/cc262947.aspx)에서는 Active Directory에서 SharePoint 수신자 개체에 대해 지정한 OU에서 중앙 관리 응용 프로그램 풀 계정에 "사용자 계정 만들기, 삭제 및 관리" 권한을 부여해야 한다고 권장할 때 어느 정도 상황을 과장합니다.
디렉터리 관리 서비스에서는 연락처 및 그룹 개체를 생성하므로 중앙 관리 응용 프로그램 풀 계정에는 이 OU에서 연락처 및 그룹 개체에 대한 모든 제어 권한이 필요하지만, 사용자 계정에 대한 관리 권한은 필요하지 않습니다. 웹 팜에서 디렉터리 관리 서비스를 설명한 대로 설정하고 문서 라이브러리에서 전자 메일을 사용하도록 시도하면 "액세스 거부됨" 오류가 발생할 가능성이 높습니다.
오류 정보는 Active Directory 권한 문제를 지적하고, SharePoint 관리자는 모든 사람에 대해 SharePoint OU에 대한 전체 제어 권한을 빠르게 지정합니다. 하지만 이 경우 Active Directory 보안이 약해지고 문제도 해결하지 못합니다.
구조화된 문제 해결에서는 먼저 문제의 지점을 찾아낸 다음 적절한 구성 변경 내용을 적용해야 합니다. 이 방식을 따라 도메인 컨트롤러에서 Windows 이벤트 로그를 확인하고 네트워크 모니터를 사용하여 네트워크 통신을 추적할 경우 이 문제가 발생할 때 SharePoint에서 Active Directory에 액세스하지 못한다는 것을 알 수 있습니다. 따라서 Active Directory 구성을 변경해도 문제를 해결하지 못합니다. 문제는 SharePoint 서버에서 발생하고 있습니다.
안타깝게도 이 권한 문제에 대한 유용한 정보를 얻기는 매우 어렵습니다. SharePoint에서는 Windows 이벤트 로그에 추가 정보를 기록하지 않습니다. 하지만 SharePoint 디버깅을 사용할 경우 디렉터리 관리 서비스에서 SharePoint 웹 서비스의 CreateContact 메서드를 사용하도록 권장하는 호출 스택(그림 6 참조)을 볼 수 있습니다. SharePoint SDK에서는 이것을 전자 메일 통합 웹 서비스(<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx)라고 합니다.
그림 6 디버그 출력
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
웹 브라우저에서 SharepointEmailWS.asmx를 열어 지원되는 작업 목록을 확인해 보겠습니다. CreateContact 메서드를 볼 수 있는데 CreateContact 링크를 클릭하면 Active Directory에서 연락처를 만들려는 경우 이 웹 서비스에 전송해야 하는 SOAP 메시지가 나타납니다. 이를 통해 이제 SharePoint 사용자 인터페이스 외부에서 작업할 수 있는 스크립트 기반 문제 해결 도구(관련 자료의 SharepointEmailWS.vbs 참조)를 만들 수 있으므로 테스트 실행 중 다른 사용자 계정을 쉽게 지정할 수 있습니다. 그림 7은 중앙 관리 응용 프로그램 풀 계정(왼쪽) 및 SharePoint 관리자 계정(오른쪽)에서 이 스크립트를 실행할 경우 반환되는 정보를 보여 줍니다.
그림 7 두 가지 서로 다른 "액세스 거부됨" 오류(크게 보려면 이미지 클릭)
오류 메시지가 서로 다릅니다! 두 메시지는 모두 액세스가 거부되었음을 나타내지만, 왼쪽의 오류는 처리 문제이고 오른쪽의 오류는 그렇지 않습니다. 그렇다면 응용 프로그램 풀 계정과 SharePoint 관리자 계정 사이에 어떤 차이가 있는 것일까요?
SharePoint 관리자는 SharePoint 서버의 로컬 관리자이고, 응용 프로그램 풀 계정은 그렇지 않습니다. 웹 응용 프로그램의 응용 프로그램 풀 계정을 로컬 관리자 그룹에 추가하고 웹 서버를 다시 시작하면 문제가 해결되지만 그리 좋은 소식은 아닙니다. 프로덕션 웹 서버에서 관리 권한으로 응용 프로그램 풀 계정을 실행하는 것은 허용되지 않습니다.
응용 프로그램 풀 계정에 이러한 상승된 권한이 필요한 이유는 무엇일까요? 다시 스크립트가 해답을 제시할 수 있습니다. 모든 사용자에게 테스트 목적으로 웹 서버에서 로컬 관리자 권한을 부여할 경우 응용 프로그램 풀 계정에서 전자 메일 통합 웹 서비스를 사용할 수 있지만, SharePoint 관리자를 포함하여 기타 모든 계정에 대한 액세스는 계속 거부된다는 것을 알 수 있습니다. 이것은 전자 메일 통합 웹 서비스에서는 액세스 제어 결정을 위한 기준으로 응용 프로그램 풀 구성을 사용한다는 것을 의미합니다.
응용 프로그램 풀 구성은 IIS 메타베이스(또는 IIS 7.0의 applicationHost.config 파일)의 일부이며, 메타베이스에 대한 액세스는 기본적으로 로컬 관리자로 제한됩니다. 다행히, IIS 6.0 리소스 키트 도구에 포함된 Metabase Explorer를 사용하여 비관리자 계정에 대해 메타베이스에 대한 액세스 권한을 부여할 수 있습니다. IIS 7.0에서는 다음 명령을 실행하여 간단히 applicationHost.config 파일에 전체 제어 권한을 더 쉽게 부여할 수 있습니다.
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
마지막으로 Active Directory에서 연락처 개체를 만들려면 중앙 관리 응용 프로그램 풀에 대상 OU의 연락처 및 그룹 개체에 대한 전체 제어 권한이 필요합니다. 그리고 웹 응용 프로그램의 풀 계정에는 웹 팜의 SharePoint 서버에서 메타베이스에 대한 전체 액세스 권한이 필요합니다. 이제 SharePoint 사용자 인터페이스를 사용하여 연락처 개체를 만들 준비가 되었습니다.
그런데 아직 더 남아 있습니다! Active Directory에서 수신자 개체를 만드는 것은 디렉터리 통합 작업에서 절반을 완료한 것입니다. 나머지 절반은 Exchange 관련 수신자 특성을 생성하고 서버 기반 주조록을 업데이트하는 것입니다. 예를 들어, Exchange 관리 셸 명령 Update-GlobalAddressList "Default Global Address List"를 사용하여 Exchange 서버에서 전체 주소 목록을 업데이트할 경우 Outlook 주소록에서 SharePoint 문서 라이브러리에 대해 새로 만들어진 수신자 개체를 찾을 수 있습니다. 그러나 이러한 수신자에게 메시지를 전송하면 그림 8에 표시된 대로 잘못된 주소 정보로 인해 배달 못 함 보고서가 생성됩니다.
그림 8 문서 라이브러리에 배달할 수 없는 메시지(크게 보려면 이미지 클릭)
IMCEAEX는 Internet Mail Connector Encapsulated Address for Exchange의 머리글자어입니다. 이것은 이전의 Exchange Internet Mail Connector에서 처리할 수 있는 형식으로 캡슐화된 비-Exchange 수신자 주소를 나타냅니다. 그러나 이제는 Exchange Server 2007 및 기본 SMTP 기반 송신 커넥터를 사용하고 있습니다.
요점은 SharePoint 전자 메일 통합 웹 서비스에서 메시지 전송을 위해 Exchange Server 2007에 필요한 주소 특성을 작성하지 않는다는 것입니다. 이름, 성, 표시 이름 및 대상 주소(및 선택적으로 ms-Exch-RequireAuthToSendTo) 특성만 작성합니다. 그러나 메일 별칭 또는 레거시 Exchange DN이나 프록시 주소를 설정하지 않고, 수신자 개체를 Exchange 수신자 정책과 연결하지 않습니다.
이 문제를 해결하려면 Exchange 관리 셸에서 Get-Mailbox cmdlet을 사용하여 SharePoint 전자 메일 도메인을 가리키는 대상 주소를 가진 모든 수신자 개체를 가져옵니다. 그리고 다음과 같이 출력을 Set-MailContact cmdlet에 연결하여 Exchange 수신자 정책을 활성화합니다.
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
또는 Exchange 관리 콘솔을 사용하고 연락처 개체 속성에서 "전자 메일 주소 정책에 따라 전자 메일 주소를 자동으로 업데이트" 확인란을 선택합니다.

WSS 3.0 및 MOSS 2007은 전자 메일 기반 경고와 알림, 워크플로 및 문서 제출을 즉시 사용할 수 있도록 모든 메시징 통합을 지원합니다. 시스템을 올바르게 구성하는 일이 간단한 작업은 아니지만 메시지 통합을 통해 작업자 생산성을 높일 수 있습니다. 특히, 인바운드 및 아웃바운드 메시지 전송이 모두 제대로 작동하도록 해야 합니다. 또한 디렉터리 통합도 작동되도록 해야 합니다.
SharePoint 오류 메시지가 항상 직관적이거나 정보를 제공하지는 않습니다. 하지만 지금까지 SharePoint 서버의 보안을 위협하지 않고 통합 문제의 기본 구조를 파악한 다음 근본 원인을 찾아 안정적으로 문제를 해결할 수 있는 방법을 설명했습니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. IT 운영과 시스템 관리를 주로 다루는 백서, 제품 설명서 및 서적 등을 출간한 Pav는 문서 관리 및 지역화 서비스를 전문으로 하는 Biblioso Corporation의 사장입니다.


Windows PowerShell 버전 2.0의 원격 관리 기능 살펴보기
Don Jones

이 칼럼은 Windows PowerShell의 시험판 버전을 기준으로 작성되었습니다. 여기에 포함된 모든 정보는 변경될 수 있습니다.

목차
두 가지 유형의 원격 기능
동기와 비동기
재사용 가능한 실행 영역
팬 인(Fan-In) 원격 기능
2.0의 핵심 응용 프로그램
Windows PowerShell 2.0의 최신 CTP(Community Technology Preview)를 접해본 적이 있으십니까? 최신 버전인 CTP2에서는 원격 관리 기능이 더욱 강화되었습니다. 바로 지금 이 새로운 기능을 만나 보십시오. 우선 시작하기 전에
go.microsoft.com/fwlink/?LinkID=119707에서 최신 버전을 다운로드해야 합니다.
우선 중요한 두 가지 사항을 밝혀 두겠습니다. CTP는 Microsoft가 다음 버전의 응용 프로그램에서 지향해야 할 방향에 대해 적극적인 사용자들로부터 의견을 듣기 위해 제공하는 사전 베타 코드입니다. 각 CTP 버전 또는 드롭(업계 용어)은 이전 드롭과 완전히 다를 수 있습니다. 개발 팀에서 피드백을 수집하여 철저하게 검토한 후 이러한 사용자 피드백을 기준으로 응용 프로그램을 변경하기 때문입니다. 이러한 방식에서는 CTP 사용과 관련하여 유리한 혜택을 받을 수 있고 주의해야 할 경고도 있습니다.
비디오
Don Jones가 Windows PowerShell 2.0 CTP2에서 새로운 원격 관리 기능을 시연하는 모습을 살펴보십시오.

유리한 혜택이란 CTP를 사용할 때 connect.microsoft.com 웹 사이트를 통해 제품에 대한 피드백을 제공할 수 있다는 것입니다. 그러면 개발 팀에서 개발 중 해당 피드백에 대해 조치를 취할 수 있습니다! 베타 또는 RC(Release Candidate) 단계까지 기다릴 경우 피드백을 적용하기가 더욱 어려워집니다. CTP 중에는 모든 것이 가능하고, 개발 팀에서는 필요한 경우 대대적이고 완전한 변경 작업을 수행할 수 있습니다.
반면 경고도 따릅니다. CTP는 생산 준비가 되지 않은 버전입니다. 물론, Windows PowerShell™ 2.0 CTP2는 지금까지 발표된 사전 릴리스 코드 중 가장 안정적인 버전일 수 있지만, 다음 번 CTP 드롭은 완전히 다른 응용 프로그램이 될 수도 있습니다. 따라서 다음 버전에서 처음부터 다시 시작해야 할 수 있으므로 CTP2에 너무 의존하지는 마십시오.
CTP는 Windows PowerShell 1.0과 함께 설치할 수 없습니다. 최상의 설치를 위해 시스템에 Microsoft® .NET Framework 3.5도 설치되어 있어야 모든 기능을 사용할 수 있습니다. 그렇지 않으면 일부 기능이 제한됩니다.
또한, CTP는 매우 초기의 코드이므로 Microsoft는 지금까지 Windows Vista® 및 Windows Server® 2008을 비롯한 최신 운영 체제에서 작동하는 응용 프로그램에 중점을 두고 있습니다. 현재의 OS 호환성은 최종 발표될 코드의 OS 호환성을 나타내지는 않습니다. 이전 버전과의 호환성은 개발 주기의 후반에 적용됩니다.

두 가지 유형의 원격
원격 관리에는 대개 팬 인(fan-in)과 팬 아웃(fan-out)의 두 가지 유형의 원격 기능이 있습니다. 팬 인(Fan-in) 원격 기능은 단일 서버에 여러 관리자가 보안 셸 연결을 합니다. Windows PowerShell은 보안 분할 방식으로 이 기능을 사용할 수 있도록 설계되었습니다. 따라서, Exchange Server로 회사를 호스팅할 경우 고객에게 서버의 일부에 대한 관리 액세스를 제공할 수 있습니다. 팬 인 원격 기능을 사용하면 원격 서버에 설치된 Windows PowerShell(버전 2.0만 해당)에 원격으로 보안이 유지되는 대화형 액세스가 가능합니다.
팬 아웃(Fan-out) 원격 기능을 사용하면 전체 원격 서버 그룹에 대해 일련의 명령을 한 번에 실행할 수 있습니다. 실행된 명령은 워크스테이션에서 서버 그룹에 동시에 전파됩니다. 명령은 각 서버에서 실행되고, 결과는 Windows PowerShell 개체의 형태로 워크스테이션에 반환되므로 결과를 검토하고 작업을 수행할 수 있습니다. Windows PowerShell은 팬 아웃 원격 기능을 위한 두 가지 핵심 기술인 Windows® Management Instrumentation(WMI)과 Windows Server 2008에서 처음 도입된 후 Windows PowerShell 2.0 CTP에서 업데이트된 Windows Remote Management(WinRM)를 지원합니다.

동기와 비동기
실제로 Windows PowerShell 1.0에도 WMI와 연결된 기본적인 팬 아웃 기능이 있었습니다. 예를 들어, 컴퓨터 이름 배열을 만든 다음 각각에서 WMI 클래스를 쉽게 검색할 수 있었습니다.
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
버전 1.0에서는 WMI 메서드를 한 번에 실행할 수 있는 방법을 제공하지 않았기 때문에 컴퓨터 재부팅과 같은 메서드 실행에는 좀 더 많은 작업이 필요했습니다. 하지만 버전 2.0 CTP에서 Invoke-WmiMethod cmdlet를 도입하면서 바뀌었습니다.
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
이 기술에도 문제는 있습니다. 작업이 동기로 수행되므로 각 컴퓨터가 한 번에 하나씩 연결되고 다른 명령을 실행할 수 있으려면 각 명령이 완료될 때까지 기다려야 합니다. 그러나 CTP에서는 이와 같은 명령을 백그라운드에서 실행할 수 있도록 백그라운드 작업이라는 새로운 개념을 도입했습니다. 간단히 –AsJob 매개 변수만 추가하면 백그라운드에서 WMI 명령을 실행할 수 있습니다.
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
결과 작업의 상태는 Get-PSJob을 실행하여 검토할 수 있으며, 작업의 최종 결과는 Receive-PSJob을 실행하여 볼 수 있습니다. 다음 칼럼에서 작업 관리에 대해 더 자세히 살펴보도록 하겠습니다. 하지만 Invoke-Command cmdlet은 다음과 같이 백그라운드에서 명령을 실행할 수 있는 더 좋은 방법을 제공합니다.
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
이 명령은 지정된 각 컴퓨터에 Get-WmiObject 명령을 보낸 다음 로컬에서 실행합니다. 일반적으로 실행 속도가 더 빠르며 WMI 원격 프로시저 호출(RPC) 연결에 의존할 필요도 없습니다. 대신 Invoke-Command는 기본적으로 포트 80 또는 443을 사용하는 WinRM을 활용합니다. 이러한 포트는 방화벽을 손쉽게 탐색할 수 있게 해주며 전체적으로 구성이 가능합니다. 또한 Invoke-Command는 대체 자격 증명 및 제한을 위한 추가 매개 변수를 지원하여 수백 대의 컴퓨터를 대상으로 하지만 일부만 병렬로 실행할 수 있습니다. 따라서 정체 및 과도한 오버헤드를 피할 수 있습니다.

재사용 가능한 실행 영역
특정 컴퓨터 그룹을 두 번 이상 원격으로 관리할 계획이라면 단순한 컴퓨터 이름 목록이 아닌 실행 영역을 사용해 보도록 합니다. Windows PowerShell에서 실행 영역은 컴퓨터의 셸 콘솔 창에서 로컬로 실행되거나 원격 컴퓨터에서 백그라운드로 실행되거나 상관없이 단순히 셸 엔진의 인스턴스입니다. 원격 실행 영역을 시작하는 방법은 간단합니다.
$names = @("server1","server2","server2")
New-RunSpace –computer $names
실행 영역에서도 WinRM을 사용하므로 기본적으로 포트 80(또는 –UseSSL 매개 변수를 지정할 경우 443)을 사용합니다. 또한 대체 인증서 등도 허용할 수 있습니다. 결과 실행 영역 개체를 검색할 경우 Invoke-Command로 전달할 수 있으며, Windows PowerShell은 이러한 실행 영역이 존재하는 컴퓨터로 명령을 보냅니다.
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
여기서 이점은 셸이 열려 있는 동안에는 실행 영역이 활성 상태로 유지되어 추가 명령에 대해 간단히 재사용할 수 있다는 것입니다.

팬 인(Fan-In) 원격
실행 영역은 팬 인 원격 기능에서도 중요합니다. 예를 들어, 그림 1에서는 원격 컴퓨터에서 실행 영역을 만들고 해당 실행 영역에 대한 참조를 검색한 후 Push-Runspace cmdlet을 사용하여 실행 영역을 활성화했습니다. 여기서 SSH 또는 기타 원격 셸 유틸리티와 유사하게 원격 컴퓨터에서 명령을 실행합니다. Pop-Runspace를 실행하면 원래의 "로컬" 실행 영역으로 돌아오고, 셸 프롬프트를 통해 현재 어느 위치에 있는지 알 수 있습니다.
그림 1 실행 영역을 사용하여 원격 컴퓨터에서 명령 실행(크게 보려면 이미지 클릭)
실행한 정확한 명령 시퀀스는 다음과 같습니다.
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
이 기술은 여러 관리자가 동시에 동일한 서버에서 대화형 원격 실행 영역을 열 수 있고 개별 워크스테이션에서 서버로 들어올 수 있으므로 팬 인이라고 합니다. Windows PowerShell 2.0의 새로운 보안 모델을 통해 제한적인 셸과 cmdlet를 만들어 각 관리자가 전역 수정을 하지 못하게 할 수 있습니다. 각 관리자는 자신의 고유 셸로만 제한됩니다. 이러한 새로운 보안 기술에는 .NET Framework 대상 언어로 몇 가지 사용자 지정 소프트웨어를 개발해야 합니다. 이 내용은 Windows PowerShell 칼럼의 범위를 벗어나지만 이러한 기능이 있다는 사실을 알아두는 것이 좋습니다.

2.0의 핵심 응용 프로그램
Windows PowerShell 2.0 CTP에는 여러 가지 놀라운 새로운 기능이 포함되어 있으나 제 생각으로는 원격 기능이 핵심 응용 프로그램입니다. 거의 모든 환경의 모든 관리자는 원격 기능을 통해 이점을 누릴 수 있습니다.
여러분의 의견을 개발 팀에 제공하려면 먼저 이러한 기능에 익숙해져야 합니다. WinRM 기본 포트를 그룹 정책을 통해 관리하고 싶으십니까? cmdlet이 서로 다르게 작동해야 합니까? 성능 문제가 있습니까? WinRM을 쉽게 구성할 수 있습니까? 여러분의 의견을 connect.microsoft.com으로 보내거나, 저를 포함한 MVP Award 수상자들과 여러분의 피드백을 나눔으로써 응용 프로그램 개발에 참여하실 수 있습니다. 저에게 연락하시려면 여러분의 피드백을 ScriptingAnswers.com의 포럼에 게시해 주십시오. 우리 모두 적극적으로 동참하여 차세대 Windows PowerShell의 핵심 응용 프로그램 개발에 이바지해 봅시다!
이달의 Cmdlet: Select-Object
다음과 같이 해보십시오. Get-Service | ConvertTo-HTML | Out-File Services.htm. 이제 웹 브라우저에서 결과 HTML 파일을 확인하십시오. 정보가 상당히 많지 않습니까? 원하는 정보만 선택하여 줄일 수 있는 방법이 있다면 얼마나 좋을까요? 바로 Select-Object를 통해 이를 해결할 수 있습니다. 예를 들어, 서비스 이름 및 현재 상태 목록만 필요할 경우 Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm과 같이 사용할 수 있습니다.
여기서 염두에 두어야 할 것은 Select-Object는 원본 개체(이 경우 서비스)를 폐기하고 지정한 속성만 포함하는 사용자 지정 개체(PSCustom 개체 유형)를 생성한다는 것입니다. 원본 개체의 기능은 더 이상 액세스할 수 없으므로 원본 개체로 원하는 만큼 작업한 후 파이프라인의 끝에서 Select-Object를 유지하는 것이 좋습니다.

Don Jones는 Windows PowerShell v2.0: TFM의 공동 저자이며 ScriptingAnswers.com "Special Forces" 강좌(scriptinganswers.com/training.asp)의 강사입니다. jeepdon@mac.com을 통해 연락할 수 있습니다.


Hey, Scripting Guy! 전용 차선 이용
Microsoft Scripting Guys

몇 달 전 Scripting Guys 중 한 명은 여기 시애틀에서 새로운 경험을 했습니다. 미국 전역의 여러 도시에서 테스트 중인 시스템인 전자 통행 요금 징수 시스템을 이용한 것입니다. 이 시스템은 워싱턴 주에서는 Good to Go로 알려져 있습니다!
작동 원리는 다음과 같습니다. 우선 전자 장치를 구입하여 자동차 전면 유리에 장착합니다. 그리고 소액을 예치하는 계좌를 하나 개설합니다. 고속도로의 모니터링 장치 중 하나를 지나면 운전자의 계좌에서 요금이 자동으로 징수됩니다. 톨게이트에 정차할 필요 없이 고속도로 통행료를 지불할 수 있는 것입니다.
현재 통행료가 부과되는 많은 지역에서 카풀을 하는 사람들은 요금을 지불하지 않아도 됩니다. 하지만 Good to Go!에서 흥미로운 것은 이 시스템이 카풀 차선에서만 작동한다는 것입니다. 이게 무슨 의미인지 의아해 할 수 있습니다. 카풀을 하면서 요금을 지불해야 한다면 누가 카풀을 하겠습니까? 물론 그렇지 않습니다. 이 시스템은 단독 승차하여 운전하면서 카풀 차선을 이용하고자 하는 사람들에게만 적용됩니다. 카풀 차선으로 가려고 하는 주요 이유는 이 차선에는 대체로 차량 수가 적기 때문입니다. 다들 정차해 있는데 실제로 움직이는 차선은 카풀 차선밖에 없는 경우도 있습니다.
앞에서 언급한 대로 이 시스템은 이미 수 천여 명이 등록했지만 현재 시험 운영 중입니다. 시애틀 지역에는 가려는 곳이 어디든 간에 전용 차선을 이용하기 위해 기꺼이 돈을 지불하려는 사람들이 많습니다.
이번 달 칼럼에서 Scripting Guys는 자체적인 작은 실험을 해보기로 결정했습니다. 이를 위해 Microsoft® Visual Basic® Express Edition이라는 전용 프로그램을 소개합니다. 이 프로그램의 가장 좋은 점 중 하나는 무료라는 것입니다. 이 정보를 어디에서 사용하든지, 얼마나 많은 사람들이 사용하든지 또는 어느 시간에 사용하든지 전혀 요금을 부과하지 않습니다. 훌륭하지 않습니까? 무엇인가 새로운 것을 배워야 한다는 측면에서 어느 정도 부담이 될 수도 있지만, 그만큼 가치가 있음을 알게 될 것입니다.
본격적으로 시작하기 전에 이 칼럼의 내용이 약간 범위를 벗어날 수 있음을 알려 드립니다. 일반적으로 Visual Basic 및 Visual C#®과 같은 Visual Studio® 제품은 TechNet Magazine이 아닌 MSDN® Magazine의 주제입니다. 그러나 MSDN과 TechNet은 하나의 큰 목표를 향해 가고 있으므로 여기에서 다루어도 별 무리가 없을 것으로 생각됩니다. 또한 개발자 도구로서 다루기도 하지만 기본적으로는 Windows® 시스템 관리자를 대상으로 하고 있습니다. 잠시 후면 어떤 의미인지 알게 될 것입니다.
지금부터 저와 함께 진행하려면 우선 Visual Basic을 설치해야 합니다. 여기서 잠깐! "이 제품이 없는데요!"라거나, "이 제품을 살 돈이 없어요!"라고 말하며 덮어 버리지 마십시오. Microsoft는 microsoft.com/express/download에서 무료로 다운로드할 수 있는 Visual Basic Express Edition을 제공합니다.
여기에서는 Visual Basic Express의 사용 방법에 대해 자세히 설명하지는 않습니다. 도움말에 자습서가 있으며, 도움말 자체가 실제로 매우 잘 구성되어 있습니다. 믿어 보십시오. 이제 Visual Basic Express를 사용하여 Windows Vista®의 특정 문제를 푸는 방법을 설명합니다. 이 예제는 이전 버전의 Windows에서도 작동하기는 합니다. 그런 다음에는 계속해서 각자 사용하면 됩니다. 우리가 풀어 볼 문제는 "Windows Vista에서 파일 열기 대화 상자를 어떻게 열 것인가?"하는 것입니다.
몇 년 전 "How Can I Show Users a Dialog Box for Selecting Files(파일 선택 대화 상자를 사용자에게 표시하려면 어떻게 합니까)?" 칼럼의 스크립트에서 파일 열기 대화 상자를 여는 방법을 설명한 적이 있습니다. microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx 참조). 이 글은 Windows Vista가 발표되기 오래 전인 2005년 1월에 게재되었습니다. 답은 UserAccounts.CommonDialog ActiveX® 컨트롤을 사용하여 열려는 파일을 찾아볼 수 있는 파일 열기 대화 상자를 여는 것이었습니다. 하지만 이 컨트롤은 Windows Vista부터 Windows에서 제거되어 새로운 시스템에서는 이 방법을 더 이상 사용할 수 없습니다. 누구도 우리에게 이것이 좋은 생각인지 물어본 적은 없습니다. 다만, 이제는 VBScript를 사용하여 파일 열기 대화 상자를 여는 방법이 없다는 것입니다. 따라서 스크립트를 작성하는 대신 Visual Basic을 사용하여 응용 프로그램 작성하려고 합니다. 이 응용 프로그램이 수행할 작업 중 하나가 파일 열기 대화 상자를 여는 것입니다.
여기에서 보여 드릴 예제는 Visual Basic으로 완전한 응용 프로그램을 만드는 것입니다. 언뜻 들으면 매우 어려운 작업 같지만 Visual Basic Express를 사용하여 응용 프로그램을 만드는 것은 스크립트를 작성하는 것만큼 쉽다는 것을 알게 될 것입니다. 이 응용 프로그램은 파일 열기 대화 상자를 여는 단추를 클릭할 수 있는 창 또는 폼으로 구성됩니다. 그런 다음 이 대화 상자에서 텍스트 파일을 선택하면 응용 프로그램이 이러한 텍스트 파일을 읽고 내용 중 일부를 폼 내부에 표시합니다.
그럼 이제 시작해 보겠습니다. 우선 Visual Basic Express를 엽니다. 가장 먼저 파일 메뉴에서 새 프로젝트를 선택하여 새 프로젝트를 만듭니다. 그러면 새 프로젝트 대화 상자가 나타납니다. Visual Basic Express 2008 이전 버전을 사용하는 경우 여기의 그림과 약간 다를 수 있습니다. Windows Forms 응용 프로그램을 만들 것이므로 Windows Forms 응용 프로그램 템플릿을 선택하고 원하는 프로젝트 이름을 입력합니다. 여기에서는 그림 1에서 보는 바와 같이 ReadFiles라는 이름을 사용했습니다.
그림 1 Visual Basic에서 새 프로젝트 만들기(크게 보려면 이미지 클릭)
프로젝트를 처음 만들면 새 폼이 자동으로 제공됩니다. 우리가 만들려는 응용 프로그램은 그림 2와 같은 폼을 사용자에게 표시합니다. 앞에서 언급한 대로 이 폼에는 클릭하면 파일 열기 대화 상자(C:\Scripts 폴더가 열림)를 여는 단추가 포함됩니다. 사용자는 파일 시스템에 있는 하나 이상의 텍스트 파일을 선택할 수 있습니다. 그러면 응용 프로그램은 선택된 각 텍스트 파일에서 첫 줄을 읽어 그 결과를 폼의 목록 상자에 표시합니다. 이 과정을 어디선가 해본 적이 있다면 2008 Scripting Games의 Beginners Division microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx에 참가하셨을 것입니다.
그림 2 사용자에게 표시될 ReadFiles 폼
폼을 만들려면 도구 상자에서 컨트롤을 끌어 프로젝트 폼에 놓아야 합니다. 기본적으로 도구 상자는 Visual Basic 창의 왼쪽에 열려 있습니다. 도구 상자가 열려 있지 않다면 Visual Basic 작업 영역의 왼쪽에 있는 도구 상자 단추를 클릭하고 모든 Windows Forms를 확장합니다.) 도구 상자에서 단추를 클릭한 다음 폼까지 끌어서 원하는 크기로 단추를 만듭니다. 단추에 레이블을 추가하려면 방금 폼에 추가한 단추를 클릭하고 원하는 레이블을 입력합니다. 또는 기본적으로 Visual Basic 작업 영역의 하단 오른쪽에 있는 속성 대화 상자에서 텍스트 속성을 편집할 수도 있습니다. 여기에서는 단추 레이블로 Browse for Files를 입력했습니다. 이제 ListBox를 클릭한 다음 폼을 다시 클릭하고 마우스를 끌어 목록 상자를 만듭니다. 목록 상자를 사용하여 텍스트 파일에서 읽은 내용을 표시할 것입니다.
이로써 폼이 만들어졌습니다. 이제 단추를 클릭할 때 어떤 이벤트가 발생하도록 해야 합니다. 폼에 있는 단추 컨트롤을 두 번 클릭합니다. 그러면 이미 만들어진 새 서브루틴(Button1_Click 서브루틴)을 포함하는 코드 편집기가 열립니다.
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
이 서브루틴은 폼에 있는 단추를 클릭할 때마다 실행됩니다. 보는 바와 같이 이 서브루틴은 현재 비어 있습니다. 버튼을 클릭했을 때 응용 프로그램에서 무엇을 해야 하는지 알려 주는 코드를 추가해야 합니다. 그렇다면 어떻게 해야 할까요? 우선 이 칼럼의 시작 부분에서 보여 주기로 약속했던 대로 파일 열기 대화 상자를 열도록 하겠습니다. Visual Basic으로 작업하는 거의 대부분의 경우와 마찬가지로 이를 위해 Microsoft .NET Framework를 사용합니다.
서브루틴 위쪽에 두 줄의 Imports 문을 추가합니다.
Imports System
Imports System.IO
이러한 구문은 .NET Framework 네임스페이스를 지정합니다. 원하는 클래스를 간단히 참조할 수 있도록 여기로 가져오기 위해 이러한 네임스페이스에 있는 클래스를 사용할 것입니다. 이러한 구문은 서브루틴 위쪽에 삽입해야 합니다. Imports 문은 전역입니다. 따라서 서브루틴이나 함수의 내부에 들어올 수 없고 외부에 있어야 합니다.
VBScript에서 Option Explicit 문을 스크립트의 상단에 추가하지 않는다면 변수를 명시적으로 선언하지 않아도 됩니다. Visual Basic에서는 자동으로 추가되므로 모든 변수를 선언해야 합니다. 여기에서는 OpenFileDialog 개체(파일 열기 대화 상자를 나타내는 개체)에 대한 참조를 포함하는 변수가 필요합니다.
Dim dlg As Windows.Forms.OpenFileDialog
이제 OpenFileDialog 유형의 변수를 선언(Dim)했으므로 다음과 같이 이 개체의 새 인스턴스를 만들 수 있습니다.
dlg = New OpenFileDialog()
하지만 아직 대화 상자를 표시하지 않았습니다. 우선 몇 가지 속성을 설정해야 합니다.
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Multiselect 속성은 사용자가 파일 열기 대화 상자에서 둘 이상의 파일을 선택할 수 있는지 여부를 지정합니다. 여기에서는 이것을 허용할 것이므로 이 속성을 True로 설정합니다. InitialDirectory 속성은 C:\Scripts로 설정합니다. 이 속성을 설정하지 않으면 대화 상자는 기본 컴퓨터 디렉터리로 열립니다.
마지막으로 Filter 속성을 설정합니다.
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
이 속성을 사용하여 대화 상자에 표시될 파일을 필터링합니다. 우리는 .txt 파일만 표시되도록 할 것입니다. 이러한 속성을 설정하면 그림 3과 같은 모양의 파일 열기 대화 상자가 됩니다.
그림 3 텍스트 파일만 표시하는 열기 대화 상자(크게 보려면 이미지 클릭)
이제 대화 상자를 표시하기만 하면 됩니다. 이 작업에서는 ShowDialog 메서드를 사용합니다.
dlg.ShowDialog()
ShowDialog 메서드는 사용자가 선택한 파일을 열기 위해 열기를 클릭했는지, 아니면 대화 상자를 닫기 위해 취소를 클릭했는지 나타내는 값을 반환합니다. 취소를 클릭하면 아무것도 발생하지 않아야 합니다. 따라서 If 문에 ShowDialog에 대한 호출을 추가하여 계속하기 전에 사용자가 열기를 클릭했는지 확인합니다.
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
지금까지는 Open 속성보다 OK 속성을 선택하는 경우가 많았습니다. 기본적으로 열기(Open) 단추는 확인(OK) 단추와 동일합니다. 여기에서는 사용자에게 "열기"라고 표시하는 것이 더 적절해 보일 뿐입니다.
이제 사용자가 대화 상자에서 어떤 파일을 선택했는지 알아야 합니다. 파일 이름은 OpenFileDialog 개체의 FileNames 속성에 포함되므로 이 속성에 포함된 모든 파일 이름을 읽도록 For Each 루프를 설정합니다.
For Each strName In dlg.FileNames
아차! strName을 선언하는 것을 잊었습니다.
Dim strName As String
이제 이러한 각 파일을 열고 읽어야 합니다. Visual Basic에서는 이를 위해 Using 블록을 사용합니다.
Using sr As StreamReader = File.OpenText(strName)
Using 블록은 실제로 VBScript에 존재하지 않으므로 VBScript 스크립터가 사용되는 것과 다릅니다. Visual Basic은 시스템 리소스 관리에 있어 많은 측면에서 VBScript보다 우수합니다. Using 문을 사용하는 목적은 블록을 빠져 나올 때 시스템 리소스를 확보하기 위해서 입니다. 이 경우 파일 내용 및 큰 메모리 블록을 계속 잡아 두지 않도록 합니다.
약간 복잡하게 생각될 수 있습니다. 하지만 Set 문을 살펴보십시오. 새 개체(이 경우 StreamReader 개체)의 인스턴스를 만들고 File.OpenText 메서드에서 반환된 텍스트 스트림에 간단히 지정하면 됩니다. OpenText를 열려는 파일(현재 루프를 거치는 FileNames 컬렉션의 파일)의 이름에 전달하게 됩니다.
따라서 StreamReader 변수인 sr이 파일의 내용을 포함합니다. 이제 또 하나의 변수가 필요합니다.
Dim strLine As String
이 변수를 사용하여 방금 연 텍스트 파일의 첫 줄을 저장할 것입니다.
strLine = sr.ReadLine()
StreamReader 개체에 대해 ReadLine 메서드를 호출하여 파일에서 첫 줄을 읽습니다. StreamReader 개체는 파일의 내용을 포함합니다. 텍스트의 첫 줄을 strLine 변수에 저장합니다.
이제 ListBox 개체에 대해 Add 메서드를 호출하여 첫 줄을 목록 상자에 추가하면 됩니다.
ListBox1.Items.Add(strLine)
이 예제에서는 텍스트 파일의 전체 텍스트가 아닌 파일의 첫 줄만 필요하므로 StreamReader를 닫고 Using 블록을 닫을 수 있습니다.
sr.Close()
End Using
이제 파일 열기 대화 상자에서 선택된 다음 파일을 계속해서 찾아 선택된 모든 파일을 읽고 모든 첫 줄을 목록 상자에 추가합니다. 완성된 코드는 그림 4와 같습니다.
그림 4 전체 ReadFiles 코드
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
   End Sub
  End Class
말씀드린 대로 응용 프로그램을 만드는 것이 스크립트를 작성하는 것보다 그렇게 어려운 일은 아닙니다.
F5(또는 디버깅 도구 모음의 디버깅 시작 단추)를 눌러 응용 프로그램을 테스트할 수 있습니다. 단추를 클릭한 다음 파일 열기 대화 상자에서 하나 이상의 파일을 선택하면 결과가 그림 5와 같이 나타나야 합니다.
그림 5 목록 상자에 표시된 선택 파일의 첫 줄
응용 프로그램이 의도한 대로 실행되면 빌드 메뉴에서 ReadFiles(또는 다른 프로젝트 이름) 빌드를 선택합니다. 그러면 다른 응용 프로그램과 마찬가지로 실행 가능하고 다른 사용자에게 배포할 수 있는 .exe 파일이 ReadFiles.exe 이름으로 생성됩니다.
파일 열기 대화 상자를 사용하는 것이 "전용 차선"을 이용하는 느낌과 같지 않을 수도 있습니다. 하지만 Windows Vista에서는 스크립트 작성을 통해 이와 같은 결과를 얻을 수 없다는 사실을 생각하면 간단한 응용 프로그램을 만드는 것은 작은 지출에 불과합니다. 실제로 전용 차선을 이용하려면 통행 요금을 지불해야 하는 것과 유사합니다. 약간 부담이 될 수도 있지만 결국에는 빠르게 원하는 곳으로 갈 수 있습니다.
이와 함께 Visual Basic을 사용하는 또 다른 이점은 이제 VBScript보다 강력한 도구를 사용하기 시작했다는 것이고, 편리한 사용자 인터페이스로 응용 프로그램을 쉽게 만들 수 있다는 것입니다. 시스템 관리자도 Visual Basic의 다른 여러 가지 용도를 찾을 수 있을 것입니다.
새로운 시스템의 전용 차선을 이용하기 위해 어떻게 운전해야 하는지 다시 배울 필요는 없습니다. 단지 새로운 차선에서는 정차 없이 앞의 차량들이 진행한다는 사실에만 익숙해지면 됩니다. 마찬가지로 VBScript를 알고 있다면 Visual Basic을 사용하기 위해 처음부터 완전히 새로운 언어를 배울 필요가 없습니다. 이 도구를 사용하여 더 많은 이점을 활용할 수 있다는 상황에만 적응하면 됩니다.
Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀기 실력뿐만 아니라 스크립팅 능력까지 시험해 볼 수 있는 문제입니다.

2008년 8월: 스크립팅 알파벳
이번 달 문제는 빈칸에 A부터 Z까지의 문자를 삽입하여 스크립팅과 관련된 단어를 완성하는 퍼즐입니다. 각 문자(A ~ Z)는 한 번만 사용해야 하며, 각 문자가 사전순으로 나타나지는 않습니다. 삽입한 문자는 단어의 첫 글자나 마지막 글자가 될 수도 있고 중간에 오는 어떤 위치의 글자도 될 수 있습니다. 예를 들어, 첫 줄에서는 문자 C를 삽입하여 SCRIPT라는 단어를 완성했습니다.

정답:
Dr. Scripto의 Scripting Perplexer
´ä: 스크립팅 알파벳, 2008년 8월

Scripting Guy는 Microsoft에서 고용되어 일하고 있는 Microsoft의 직원들입니다. 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


The Desktop Files Windows 배포 서비스 101
Wes Miller

목차
Windows Server 2003의 WDS
Windows Server 2008의 WDS
선택
고려 사항
WDS 시작
캡처 이미지
캡처 101
이미지 마이그레이션
무인 설치
지난 달 칼럼에서는 Microsoft의 PXE(Pre-Boot eXecution Environment) 기반 배포 도구의 역사를 살펴보았습니다. 이번 달에는 Windows 배포 서비스(WDS)에 대해 자세히 살펴봅니다. 특히, Windows Server 2003에 포함된 버전과 Windows Server 2008에 포함된 업데이트된 버전을 중심으로 설명합니다.
그 다음에는 WDS를 구성하고 실행하는 방법에 대해 설명합니다.
WDS는 재작성된 원격 설치 서비스(RIS)라고 생각할 수 있습니다. 둘 다 몇몇 주요 구성 요소를 공유하고 실제로 Windows Server® 2003의 WDS 버전에는 RIS와 기능적으로 동일한 레거시 모드가 있지만, 기본 모드 및 50% 혼합 모드에서 실행되는 WDS의 실제 인프라는 완전히 새로운 것입니다.

Windows Server 2003의 WDS
Windows Vista®가 출시되었을 때 WDS도 동시에 제공되었습니다. Windows Vista 설치는 Windows® Imaging Format(WIM) 아키텍처를 사용하여 완전히 재설계되었기 때문에 RIS를 통해서는 Windows Vista(및 Windows Server 2008)를 배포할 수 없게 되었으므로 이 단계가 필요했습니다. 그 이후 Windows Server 2003 SP1을 실행하는 고객들은 WDS를 선택적으로 다운로드할 수 있게 되었습니다. SP2에서는 RIS가 WDS로 완전히 대체되었습니다.
Windows Server 2003의 WDS는 이전 버전과 완벽하게 호환되므로 Windows Server 2003 SP2 시스템에 WDS를 설치할 때 기본 모드로 전환하지 않아도 됩니다. 계속해서 레거시 모드로 실행(기능적으로 RIS 서버로 실행)하거나 WDS 또는 RIS를 시작할 수 있는 혼합 모드로 실행할 수 있습니다.
Windows Vista 및 Windows Server 2008을 배포할 수 있을 뿐 아니라 기본 모드 또는 50% 혼합 모드로 실행되는 WDS에는 여러 가지 추가 기능이 있습니다. 지난 달에 설명한 Windows 커널 모드 설치 엔진 및 기존의 설치 코어(technet.microsoft.com/magazine/cc645015)를 사용하는 대신, WDS에서는 Windows PE를 부트스트랩 사전 설치 환경으로 사용하고 RISetup 또는 RIPrep 기반 설치를 사용하는 대신 WIM 기반 이미지를 배포합니다. 이를 통해 배포가 더욱 빨라지고 쉬워지며 안정성이 높아집니다.
또한, Windows PE는 Windows 전체 설치와 동일한 문자 집합을 표시할 수 있으므로 ANSI(American National Standards Institute) 기반 문자를 사용해야 한다는 등의 지난 달에 언급했던 많은 제한 사항이 없습니다.
WDS에는 RIS에 없는 관리 지원을 위한 Microsoft® Management Console(MMC) 스냅인 및 RIS에 비해 구성 기능을 확장하는 포괄적인 명령줄 구성 도구 등 몇 가지 도구가 포함되어 있습니다.
레거시와 혼합 모드에서 모두 RISetup 및 RIPrep 기반 Windows 이미지 배포가 가능하므로 한 가지 사항을 염두에 둘 필요가 있습니다. RIS에서는 디스크의 이미지 저장을 최적화하기 위해 SIS(단일 인스턴스 저장소)라는 구성 요소를 사용했습니다. 나중에 Windows Storage Server 2003의 일부로 제공된 SIS는 RIS(및 WDS) 서버에서 백그라운드로 실행되어 동일한 파일을 찾는 Groveler라는 서비스를 사용했습니다. 파일의 크기와 해시가 일치하면 SIS는 복사본을 SIS Common Store 폴더에 저장한 다음 찾은 각 원본 버전에 대한 하드 링크를 만듭니다.
SIS는 프로세서 사용률에 대한 영향을 최소화하면서 저장 공간 절약이 가능하도록 설계되었습니다. 이러한 개념은 RIS에서 처음으로 사용된 다음 Windows Server 플랫폼에서 널리 사용되었습니다. 그러나 SIS는 WDS에서 더 이상 사용되지 않습니다.
기본 모드로 실행되는 Windows Server 2003의 WDS(및 Windows Server 2008의 경우 항상)는 설치를 위해 WIM 이미지를 사용하므로 고유의 압축 및 더욱 중요한 고유의 단일 인스턴스 파일 저장 모델이 있으며 SIS는 전혀 사용하지 않습니다. 이미지 저장소는 WDS를 위한 새로운 WIM 기반 설계로 RIS에서 사용되는 저장 모델을 대체합니다. SIS에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=120302를 참조하십시오.

Windows Server 2008의 WDS
Windows Server 2008에서 WDS는 Windows Server 2003 기능의 상위 집합이며 또한 하위 집합입니다. 이제 EFI(Extensible Firmware Interface) 기반 x64 시스템을 지원하고, 향상된 설치 메트릭 보고 기능을 갖춘 뛰어난 성능의 신형 TFTP(Trivial File Transfer Protocol) 서버인 전송 서버를 사용하여 독립 실행형 모드에서 멀티캐스트를 통해 이미지를 배포할 수 있습니다. 이러한 기능에 대해서는 다음 달 칼럼에서 설명하겠습니다.
Windows Server 2008의 WDS에는 Windows Server 2003에 있었던 레거시 설치 지원 기능이 없습니다. RISetup/RIPrep 이미지 배포 기능 또는 레거시 RIS OS 선택기를 사용하여 설치를 시작하는 기능은 더 이상 사용할 수 없습니다.

선택
Windows Server 2008이 출시된 이후 가장 자주 듣는 질문 중 하나는 "어떤 버전의 WDS를 사용해야 할까요?"입니다. 대답은 Windows Vista 이전의 Windows 버전을 배포하는지 여부와 그러한 경우 RISetup 및/또는 RIPrep 기반 이미지에서 전환하여 WIM 기반 설치를 사용할 준비가 되어 있는지 여부에 따라 달라집니다.
WDS는 Windows Server 2008에서도 WIM 이미지라면 Windows 2000 버전까지 모든 이전 버전의 Windows를 배포할 수 있으며, 멀티캐스트를 사용하여 작업을 수행할 수 있습니다. 따라서 지금 RIS에서 WDS로 전환하고, 인프라에 Windows Server 2008을 생각하고 있으며, RIS 기반에서 WDS 기반 이미지로 마이그레이션할 의향이 있다면 Windows Server 2008의 WDS로 마이그레이션이 적절할 수 있습니다.
Windows Server 2003 시스템 자체에서도 RIS에서 WDS로 마이그레이션하고(SP2를 설치할 경우 기본), WDS 기반 이미지로 전환할 수 있습니다. 그런 다음 Windows Server 2008 WDS로 업그레이드할 수 있습니다.
하지만 이것은 제가 권장하는 모델이 아닙니다. 2008 이전에 많은 버전의 Windows Server가 있으므로 Microsoft에서는 한 버전의 Windows Server에서 다른 버전으로 마이그레이션(업그레이드와 대비)하는 것을 권장합니다.
그리고 이전에 언급한 대로 인프라에서 Windows Server 2008 x64 버전을 고려하는 것이 Windows Server 2003 x64 버전을 고려하는 것보다 훨씬 낫습니다. 이러한 전환을 할 경우 Windows Server 2003에서 Windows Server 2008로 WDS의 서버 간 마이그레이션 작업이 업그레이드 작업에 비해 비교적 쉽고 훨씬 안정적입니다.

고려 사항
WDS 배포 작업에서 고려해야 할 몇 가지 사항이 있습니다. 실제로 WDS에 대한 새로운 요구 사항은 아닙니다. RIS의 경우에도 이와 동일한 여러 고려 사항이 있었습니다. 하지만 단일 WDS 서버를 구축하든지, 전체 인프라를 구축하든지 다음 사항을 염두에 둘 필요가 있습니다.
권한 WDS 서버를 관리할 때 기억해야 할 두 가지 기본 사항이 있습니다. Active Directory®에서 RIS와 마찬가지로 WDS 서버에 권한을 부여해야 합니다. 이렇게 하려면 포리스트의 루트 도메인에서 도메인 관리자 또는 엔터프라이즈 관리자이거나 적절한 권한이 위임되어야 합니다. 또한 WDS 서버를 관리하려면 도메인 관리자여야 하고, 물론 WDS 서버 자체의 관리자이기도 해야 합니다.
가상화 Microsoft Virtual PC 또는 Virtual Server상의 가상화된 Windows Server 2003 또는 Windows Server 2008 인스턴스에서 실행하고 Virtual PC 또는 Virtual Server가 설치되어 있는 동일한 클라이언트 PC와 통신할 경우, PXE 부팅 시 경합 상태가 발생하여 클라이언트가 매우 느려지거나 멈출 수 있습니다. 클라이언트 또는 서버를 가상화할 수 있지만 둘 다 가상화하는 것은 권장되지 않습니다. 특히, 동일한 호스트 시스템에서는 더욱 그렇습니다. 개인적으로 프로덕션 환경에서 WDS 서버를 가상화하는 것은 권장하지 않는데, 주로 다음과 같은 고려 사항 때문입니다.
기타 서비스 WDS는 RIS와 마찬가지로 다른 프로덕션 서비스와 항상 잘 작동하는 것은 아닙니다. 특히, Microsoft Exchange Server, Systems Management Server(SMS) 및 System Center Configuration Manager(SCCM)가 실행 중인 프로덕션 시스템에서 실행할 경우 RIS/WDS에 문제가 발생하는 것을 목격했습니다.
일반적으로 5대가 넘는 클라이언트에 대한 프로덕션 환경에서 WDS를 사용하는 경우 서버에서 WDS가 유일한 역할이 되도록 하는 것이 좋습니다. WDS뿐만 아니라 Windows 서버 제품의 역할을 함께 사용할지 여부를 신중히 고려하고 배포 전에 테스트해야 합니다.
느리거나 대기 시간이 긴 링크 RIS와 마찬가지로 WDS는 위성 링크와 같은 낮은 대역폭 연결이나 대기 시간이 긴 연결을 통해 사용하도록 설계되지 않았습니다. PXE 핸드셰이크에서 문제가 발생할 수 있으며, 작동된다고 해도 이미지 다운로드에 상당히 많은 시간이 소요될 수 있습니다.

WDS 시작
WDS에 대한 추가 정보

  • Windows Server 2003의 WDS에 대한 단계별 안내서
  • Windows 배포 서비스 단계별 안내서(Windows Server 2008)
  • Windows Server 2003에서 WDS 업데이트 배포 및 관리
  • Windows Server 2008에서 Windows 배포 서비스 설명서
  • 기술 참조: Windows 배포 서비스(Windows Server 2008)
먼저 Windows Server 2003에서 WDS를 사용할지 Windows Server 2008에서 사용할지를 결정해야 합니다. Windows Server 2003을 사용하는 경우 SP1 및 이전의 Windows 자동 설치 키트(WAIK)에 포함된 WDS의 선택적 다운로드 대신, 선택적 구성 요소로 WDS(RIS 대체)가 기본적으로 포함되어 있는 SP2로 시작하는 것이 좋습니다.
선택한 Windows Server 버전에 대해 고유의 서버 시스템을 구축해야 합니다. 100Mbps 이상을 지원하는 고품질 NIC(네트워크 인터페이스 카드)이 필요하며, WDS의 PXE 인프라에서 문제가 발생할 수 있으므로 NIC 팀은 사용하지 마십시오. Windows Server 2008을 사용하는 경우 서버 코어 또는 Windows Server 2008의 전체 설치에 WDS를 설치할 수 있습니다.
WDS는 Windows Server 2003에서 이전의 RIS와 마찬가지로 선택적 구성 요소로 설치됩니다. OS 설치 중에 설치하거나 나중에 프로그램 추가/제거 | Windows 구성 요소 추가/제거(또는 명령줄에서 sysocmgr.exe 실행)를 실행하여 설치할 수 있습니다. WDS는 Windows Server 2008에 역할로 설치되며, 초기 구성 마법사(역할 추가 | 다음 | Windows 배포 서비스 선택을 클릭) 또는 서버 관리자(초기 구성 마법사와 동일한 단계)를 통해 설치하거나 명령줄에서 ServerManagerCmd –install WDS를 실행하여 설치할 수 있습니다.
WDS를 설치했으면 구성해야 합니다. Windows 시작 메뉴에서 관리 도구로 이동하고 Windows 배포 서비스를 선택합니다. MMC가 실행되면 서버를 마우스 오른쪽 단추로 클릭하고 메뉴에서 "서버 구성"을 선택하여 구성 마법사를 실행합니다.
Windows Server 2003에 설치하고 기존 RIS 서버를 업그레이드하는 경우 레거시 설치를 혼합 모드로 업그레이드할 수 있도록 기존 RemoteInstall 디렉터리를 지정할 수 있습니다. 이 경우 RemoteInstall 디렉터리가 성능에 영향을 줄 수 있는 System 파티션에 있지 않은지 확인해야 합니다.
그림 1은 구성 마법사가 완료되기 전 Windows Server 2008의 WDS 콘솔을 보여 줍니다. 그림 2는 Windows Server 2008의 WDS 구성 마법사 시작 페이지를 보여 줍니다. 그림 3은 WDS 구성 마법사의 PXE 구성 단계를 보여 줍니다. 이 단계에서 서버가 임의의 클라이언트에 응답해야 하는지(초기 구축의 경우 유용), 알려진 클라이언트 컴퓨터에만 응답해야 하는지(Active Directory에 미리 구성된 클라이언트) 또는 모든 클라이언트에 응답해야 하는지(그리고 관리자가 일련의 작업을 선택할 수 있도록 알려지지 않은 모든 클라이언트를 선택적으로 보류해야 하는지 여부)를 지정할 수 있습니다.
그림 1 설치되었지만 아직 구성되지 않은 WDS
그림 2 WDS 구성 마법사
그림 3 PXE 서버에 대한 응답 정책 선택
그림 4는 Windows Server 2008에 완전히 구성된 WDS 서버(아직 설치된 이미지는 없음)의 속성 페이지를 보여 줍니다. 이미 DHCP(Dynamic Host Configuration Protocol) 서버인 서버를 사용하는 경우 DHCP 옵션 60을 PXEClient로 설정하고, WDS를 포트 67에서 수신 대기 안 함으로 설정해야 합니다. 이렇게 하면 WDS 서버에서 PXE 검색 과정 중 단계를 건너뛸 수 있습니다(지난 달 칼럼 참조).
그림 4 Windows Server 2008에 완전히 구성된 WDS 서버
마법사가 완료되었으면 새 이미지를 추가할 수 있습니다. 혼합 또는 기본 모드로 실행되는 WDS 서버에 두 가지 유형의 이미지를 추가할 수 있습니다.
  • 부팅 이미지: 일반적으로 Windows Server 2008 또는 Windows Vista SP1 설치 DVD에서 복사된 Windows PE 2.x를 포함하는 이미지입니다. 멀티캐스트를 사용하는 경우 부팅 이미지로 Windows Server 2008의 \Sources\Boot.wim 파일을 사용할 수 있습니다(Windows Vista 또는 레거시 운영 체제를 배포하는 경우에도 해당). 부팅 이미지는 대개 Windows PE, Windows Setup.exe 및 기타 종속 구성 요소로 구성됩니다.
  • 설치 이미지: 일반적으로 Windows Vista 또는 Windows Server 2008의 \Sources\Install.wim 파일인 Windows OS 이미지로 구성됩니다.
기본 부팅 이미지 또는 기본 설치 이미지를 추가하는 단계는 거의 동일합니다. 이미지 유형을 마우스 오른쪽 단추로 클릭하고 해당 유형의 이미지를 추가하도록 선택하여 각 프로세스를 시작합니다.
설치 이미지의 경우 이미지 그룹 이름을 지정해야 합니다(Windows DVD의 기본 WIM에는 둘 이상의 OS 유형이 포함되어 있음). 그런 다음 추가하려는 해당 boot.wim 또는 install.wim으로 이동하고 열기를 클릭합니다. 설치 이미지의 경우 WDS 서버에 추가하지 않으려는 볼륨 이미지(OS 이미지)의 선택을 취소할 수 있습니다. 마지막으로 이러한 기본 이미지를 사용하여 클라이언트에 대해 PXE-install을 수행할 수 있습니다.

캡처 이미지
사용자 지정 OS 이미지를 만들려면 캡처 이미지(Windows 시스템을 WIM 이미지로 캡처할 수 있도록 설계된 Windows PE 이미지)를 만들어야 합니다. 가장 쉬운 방법은 이전에 설치한 boot.wim 이미지를 사용하는 것입니다.
원하는 이미지를 마우스 오른쪽 단추로 클릭하고 캡처 부팅 이미지 만들기를 클릭합니다. 이미지에 대해 사용할 이름과 설명을 지정하고, 캡처 이미지를 배포할 때 네트워크 연결 문제 발생을 대비하여 .wim 파일의 로컬 복사본을 저장할 위치를 지정합니다. 그런 다음 마법사의 지시에 따라 완료하고 마침을 클릭합니다.
이제 WDS MMC에서 Boot Image 폴더를 마우스 오른쪽 단추로 클릭하고 부팅 이미지 추가를 클릭합니다. 이전과 같이 마법사의 지시를 따릅니다. 작업을 마쳤으면 Windows 설치 이미지를 캡처할 준비가 완료된 것입니다.

캡처 101
운영 체제 이미지를 캡처하기 전에 물론 Windows를 설치하고 원하는 모든 응용 프로그램, 사용자 지정 및 업데이트가 포함되도록 해야 합니다. 다음으로 해야 할 일은 시스템에서 Sysprep를 실행하는 것입니다. Sysprep로 준비된 시스템에서만 Windows 설치 이미지를 캡처할 수 있기 때문입니다. 손상 가능성을 방지하기 위해 새 이미지 및 *.wim 확장명을 저장할 유효한 로컬 위치를 지정해야 합니다.
시스템을 구성하고 올바른 버전의 sysprep.exe를 시스템에 복사했으면 다음 단계를 따라야 합니다.
  1. 참조 컴퓨터에 있는 명령 프롬프트에서 sysprep.exe가 있는 디렉터리로 변경합니다.
  2. Sysprep를 시작합니다(sysprep.exe를 두 번 클릭하고 수동으로 옵션을 지정하여 시작할 수도 있음). Windows Vista 또는 Windows Server 2008을 실행하는 컴퓨터의 경우 sysprep /oobe /generalize /reboot 명령을 실행합니다. 이전 버전의 Windows를 실행하는 컴퓨터의 경우 sysprep -mini –reseal –reboot를 실행합니다.
  3. 컴퓨터가 다시 시작되면 PXE 부팅합니다(이 프로세스는 클라이언트 시스템에 따라 다를 수 있음).
  4. 부팅 메뉴에서 WDS 캡처 이미지를 선택하고 다음을 클릭합니다.
  5. 이미지에 대한 드라이브 및 이름과 설명을 선택합니다.
  6. 설명한 대로 Sysprep로 준비된 시스템만 보입니다. 이것은 계획적으로 설정된 것으로 우회할 수 있는 방법은 없습니다.
  7. 찾아보기를 클릭한 다음 캡처된 설치 이미지를 저장할 로컬 폴더로 이동합니다. 매핑된 네트워크 드라이브를 선택할 수도 있습니다.
  8. WDS 서버에 이미지 업로드를 선택합니다.
  9. WDS 서버의 이름을 입력한 다음 연결을 클릭합니다.
  10. 이미지 그룹 목록에서 이미지를 저장할 이미지 그룹을 선택한 다음 마침을 클릭합니다.
이 이미지는 이제 WDS 서버에서 배포할 준비가 되었습니다. 그런데 이쯤에서 RIS 전문가의 지적이 있을 수 있습니다. 여기에서는 이 Windows 이미지를 라이브로 캡처하지 않았기 때문입니다. WDS의 경우 캡처되는 시스템이 오프라인 상태여야 합니다.
RIS의 경우 RIPrep는 온라인 시스템을 캡처할 수 있었습니다(사실, 그렇게 해야만 했습니다). 이 프로세스는 매우 불안정했습니다. WDS의 캡처 프로세스가 비교적 쉽고 더 강력하다는 사실을 알 수 있습니다.

이미지 마이그레이션
RIS를 사용한 적이 있다면 사용했던 이미지가 있을 것입니다. RISetup 기반 이미지(스크립트 설치)의 수명은 끝났습니다. 하지만 RIPrep 이미지를 WDS WIM 기반 이미지로 마이그레이션할 수 있습니다. 사실, WDS에서는 WDSUtil을 통한 이미지 마이그레이션도 가능합니다(다음 달에 자세히 설명할 예정).
일반적으로 이 작업은 이미지에 많은 시간과 노력을 투자했고 이를 잃고 싶지 않은 경우에만 수행하는 것이 좋습니다. 프로세스는 비교적 잘 수행되지만, 변환 중 오류가 약간 발생할 수도 있습니다. 그러면 이미지를 처음부터 다시 만들어야 합니다.

무인 설치
앞에서 설명한 대로 이미지를 만들면 수동으로 설치할 수 있는 이미지가 만들어집니다. 더 자동화되거나 완전히 자동화된 설치를 위해서는 두 가지 무인 설치 파일을 사용해야 합니다. WDS 자체에는 WDS 설치 프로세스를 자동화하는 응답 파일(WDS 서버의 \RemoteInstall\WDSClientUnattend 디렉터리에 있는 unattend.xml)이 필요합니다. 두 번째 파일은 실제 이미지 unattend 파일입니다. Windows Vista 및 이후 버전의 경우 unattend.xml 파일에 해당됩니다. 이전 버전 Windows 이미지의 경우 $OEM$ 디렉터리 구조 또는 각 이미지 디렉터리의 \Unattend에 있는 sysprep.inf 파일입니다. 이 파일은 WDS가 완료된 후 Windows의 실제 설치를 자동화하는 데 사용됩니다.
WDS Unattend 파일을 만들려면 WAIK를 사용하여 WDS에 대한 unattend.xml을 만듭니다. 이 파일을 RemoteInstall 디렉터리나 하위 디렉터리에 복사합니다. unattend 파일을 사용하려는 설치 이미지를 마우스 오른쪽 단추로 클릭하고 속성을 클릭합니다. 클라이언트 탭에서 무인 설치 사용을 선택하고 앞에서 지정한 unattend.xml 파일을 지정합니다.
Windows Vista 이전 버전의 이미지에 대해 이미지 unattend 파일을 만들려면 sysprep.inf 파일을 이미지의 $OEM$ 디렉터리에 복사합니다(예: D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf). Windows Vista 이미지의 경우 연결할 이미지를 지정하고 속성을 클릭한 다음 일반 탭에서 무인 모드에서 이미지 설치 허용을 클릭합니다. 그런 다음 설치에 사용할 unattend.xml 파일을 지정합니다.
이제 절반 정도 진행되었습니다. 이 칼럼을 통해 WDS를 구성하고 실행할 수 있게 되었습니다. 다음 달에는 WDSUtil, 이미지 저장소 특성 및 멀티캐스트에 대해 자세히 다룰 예정입니다. 그런 다음 WDS을 기반으로 사용자 지정 배포 솔루션 구현을 고려해야 하는 이유와 그 방법에 대해 자세히 설명하면서 이번 시리즈를 마무리할 예정입니다. 그 때까지 이 칼럼과 함께 제공되는 "WDS에 대한 추가 정보" 추가 기사를 살펴보십시오.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(www.CoreTrace.com)에서 기술 제품 수석 관리자로 맡고 있으며, 이전에는 Winternals Software에서 그리고 Microsoft에서 프로그램 관리자로 일했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


Security Watch 암호와 신용 카드 - 제2부
Jesper M. Johansson

목차
의사 다단계 로그온 프로세스
브라우저 추가 기능의 문제점
인증자 변경 불가
보안 수준이 낮은 암호로 다운그레이드
의사 다단계 로그온 우회
암호 노출의 문제점
몇 가지 이점
사용자의 오해를 부르는 잘못된 보안 표시
열 것인가, 열지 않을 것인가
보안 통신 제공
개인 정보 보호
IT 산업의 보안 문제에 있어서 사용자에게 도움이 아니라 오히려 혼란을 주는 사안을 다룬 3부 시리즈 중 2부를 시작합니다. TechNet Magazine 2008년 7월호에서는 적용이 불가능하거나 잘못된 보안 권고와 혼동스러운 로그온 워크플로에 대해 다루었습니다. (제1부를 아직 읽지 않은 경우
technet.microsoft.com/magazine/cc626076에서 찾아볼 수 있습니다.) 지난 호에서는 취약한 보안 권고와 잘못된 로그온 워크플로로 인해 사용자들이 얼마나 많은 혼란을 겪고 있으며, 개인 정보를 보호하려는 사용자들의 노력을 무용지물로 만드는 일이 공공연하게 발생하고 있다는 얘기를 했었습니다.
이번에는 실제 사용자 보안 환경의 좀더 구체적인 예를 들어 관련 내용을 설명해 보겠습니다. 보안 전문가들의 의견을 소개할 이 시리즈의 마지막 편은 TechNet Magazine 다음 호에 게재될 예정입니다.

의사 다단계 로그온 프로세스
2005년 10월, FFIEC(미국 연방 금융감독원)에서는 "인터넷 뱅킹 환경의 인증" 기준을 발표했습니다(www.ffiec.gov/press/pr101205.htm 참조). 시행 준비 기간은 14개월밖에 되지 않았으며, 미국 연방 기관들은 이러한 새로운 기준을 충족하기 위한 방안을 강구하기 시작했습니다.
대부분의 기관들은 이 기간에 맞추지 못했습니다. 기준을 충족한 많은 기관들도 기준을 통과하기 위한 조치만 마련했습니다. 즉, 기관들은 사용자를 더욱 안전하게 보호하기 위한 조치를 마련하지 못했으며 "보안 전시 행정"에 불과했습니다. 전혀 도움이 되지 않는 재미있는 솔루션 중의 하나는 실제로 다단계가 아닌 다단계 인증을 만들려고 하는 것입니다.
사용자가 암호를 입력할 때 입력 흐름을 측정하는 기술을 예로 들어 보겠습니다. 웹 사이트에서 사용되는 이 솔루션은 기존의 로그온 대화 상자와 동일한 모양의 로그온 대화 상자를 표시합니다. 하지만 이 대화 상자는 Adobe Flash 개체입니다.
Flash 개체는 키를 얼마나 오래 누르고 있는지 그리고 키 입력 간의 시간 간격이 얼마인지와 같은 특성을 포함하는 사용자의 입력 흐름을 기록합니다. 이 데이터는 암호와 함께 웹 사이트로 제출되어 저장된 값과 비교됩니다. 입력 흐름 데이터가 저장된 데이터의 편차 범위 내에 있고 암호가 일치하면 로그온이 허용됩니다. 일반적인 생각은 이 솔루션을 통해 클라이언트에 타사 하드웨어를 설치하지 않고도 사이트에서 의사 생체 인증 방식을 사용할 수 있다는 것입니다.
이것을 의사 다단계 인증이라고 하겠습니다. 이 방식은 다음과 같은 정식 요소 중 두 항목 이상을 측정하는 진정한 다단계 인증이 아닙니다.
  • 사용자가 가지고 있는 것(스마트 카드 등)
  • 사용자가 알고 있는 것(암호 등)
  • 사용자를 증명할 수 있는 것(지문 등)
의사 다단계 인증은 인증 프로세스에서 실제로 다중 요소를 포함하는 대신 여러 매개 변수 중 하나인 암호만 읽습니다. 그런 다음 추가 매개 변수를 사용하여 사용자를 증명할 수 있는 것에 대한 추론을 합니다.
의사 다단계 인증에 사용된 기술에는 많은 결함이 있습니다. 이러한 결함으로 인해 이 기술은 보안 문제를 해결하는 데 있어 대체로 비효과적입니다.

브라우저 추가 기능의 문제점
의사 다단계 인증 시스템은 브라우저 추가 기능을 통해 필요한 클라이언트측 처리 기능을 제공합니다. 물론 모든 소프트웨어에는 버그가 있으며, 이러한 버그 중 일부로 인해 취약점이 발생합니다. 이러한 취약점은 소프트웨어를 업데이트하기 어렵고 업데이트가 설치되었는지 확실치 않을 때 실제로 문제가 됩니다.
브라우저 추가 기능은 이러한 두 가지 사항에 모두 적용됩니다. 추가 기능은 업데이트하기가 어렵고 설치된 버전이 최신 버전인지 아닌지를 사용자가 확실히 알기가 어렵습니다. 따라서 사용자는 필요하지 않을 수도 있는 소프트웨어의 일부분을 인터넷에 노출해야 합니다.
추가 기능을 최신 버전으로 유지하기 위해 해당 웹 사이트에 정기적으로 방문하여 업데이트를 확인해야 하는 경우도 있습니다. 하지만 대부분의 사용자는 이렇게 하고 있지 않습니다. 단순한 보안 기능을 제공하기 위해 최종 사용자가 관련성 없는 추가 소프트웨어를 인터넷에 노출해야 하는 모든 시스템은 심각하게 검토를 해야 합니다.

인증자 변경 불가
"사용자를 증명할 수 있는" 요소에는 다른 두 가지 요소에 영향을 주지 않는, 단점일 수도 있는 특성이 있습니다. 암호(사용자가 알고 있는 것)를 변경할 수 있고 새 보안 토큰(사용자가 가지고 있는 것)을 만들 수 있지만 사용 가능한 생체 인증자의 수는 대체로 제한적입니다. 예를 들어, 지문의 경우 평생 10개만 사용할 수 있으며, 만약 사고로 이 중 하나를 잃게 된다면 대개는 대체가 불가능합니다.
이제 이것이 의사 다단계 로그온 사례에 어떻게 적용되는지 살펴보겠습니다. 다른 요소의 일부로 수집된 측정 정보는 쉽게 교체하거나 수정할 수 없습니다. 암호가 변경되면 사용자가 입력하는 방식도 변경되겠지만, 사용자가 키보드에서 키를 누르는 일반적인 방식은 바뀌지 않습니다. 이것이 바로 이 기술의 핵심 요소입니다. 이러한 측정 정보가 노출되면 합성이 가능해지며, 공격자가 이러한 측정 정보를 알아내고 재생할 수 있습니다.

보안 수준이 낮은 암호로 다운그레이드
긴 암호를 사용하고 자주 암호를 변경하는 것이 좋습니다. 또한 일부 권고 사항에 반할 수도 있지만 제1부에서 언급한 대로 안전한 곳에 암호를 기록해 두는 것이 좋습니다. 하지만 이렇게 하면 손으로 암호를 입력할 때 편하지는 않습니다. 긴 암호는 입력하기가 어려우므로 암호를 기록해 두면 복사하여 붙여 넣을 수 있습니다. 수백 개 이상의 암호를 관리할 수 있는 가장 좋은 방법 중 하나는 Password Safe(sourceforge.net/projects/passwordsafe)와 같은 소프트웨어 유틸리티를 사용하는 것입니다. 이와 같은 도구를 사용하면 완전한 무작위 암호를 생성하여, 암호화된 형태로 저장한 후, 로그온 대화 상자에 바로 붙여 넣을 수 있습니다. 사실, 이러한 도구를 사용하면 암호가 무엇인지 알 필요도 없습니다.
하지만 여기에는 한 가지 문제가 있습니다. 사용자가 암호를 입력하지 않으면 입력 흐름을 측정할 수 없습니다. 그리고 입력 흐름을 측정하는 개체에 암호를 입력해야 하는 경우 이 암호 관리 기술은 효용성이 떨어집니다. 15자의 완전한 무작위 암호를 정확하게 입력하는 작업은 간단한 일이 아닙니다. 따라서 사용자들은 대개 이와 같은 유형의 시스템에서 간단한 암호를 사용합니다. 그래도 15자의 완전한 무작위 암호는 그 자체만으로도 의사 다단계 인증 시스템의 간단한 암호보다 안전합니다.
배타적으로 구현된 의사 다단계 인증은 사용자들이 안전하지 않은 암호를 사용하도록 유도합니다. 곧 알게 되겠지만 실제로는 적절한 암호 관리 기술을 사용하는 것이 의사 다단계 인증 시스템으로 얻을 수 있는 어떠한 이점보다도 우수합니다.

의사 다단계 로그온 우회
사이트에서 의사 다단계 인증을 구현하더라도 의사 다단계 시스템을 우회할 수 있는 방법을 지원해야 합니다. 첫째, 일부 사이트에서는 사이트에 액세스하려는 모든 사용자에게 "제4자" 기술을 설치하도록 요구할 수 있습니다. TechNet Magazine 저자와 같은 일부 사용자는 이러한 종류의 소프트웨어를 설치하는 것을 항상 거부합니다.
둘째, 입력 흐름은 여러 가지 이유로 바뀔 수 있으므로 사이트에서 이러한 사실을 고려해야 합니다. 예를 들어, 손목이 골절된 사용자의 경우 입력 흐름이 일시적으로 바뀔 수 있습니다. 사이트에서 입력 흐름을 분석한 후 다른 사람이 해당 사용자의 자격 증명으로 로그인하려고 시도하고 있다고 간주된다면 어떻게 해야 하겠습니까? 손목 부상이 영구적이라면 사용자는 저장된 흐름 값을 재설정할 수 있습니다. 하지만 일시적인 부상이라면 사용자는 입력 흐름이 곧 원래대로 돌아올 것이라 생각하고 저장된 값을 재설정하려고 하지 않을 것입니다.
마지막으로, 모든 사용자가 의사 다단계 인증 시스템을 사용할 수 있는 것은 아닙니다. 예를 들어, 음성 인식을 통해 컴퓨터를 작동하는 장애인의 경우 프로그래밍 방식 입력 허용 여부에 상관없이 대화 상자에 암호를 입력하지 못할 수 있습니다. 이 경우 법적으로 장애인을 위한 대체 시스템이 마련되어 있어야 합니다.
이러한 모든 시나리오에 대비한 가장 간단하고도 직관적인 방식은 표준 암호 기반 인증을 지원하는 것입니다.

암호 노출의 문제점
의사 다단계 인증 시스템은 암호 기반 인증과 관련된 다양한 문제를 해결하기 위해 고안되었습니다. 하지만 이러한 시스템은 암호가 무력화될 수 있는 모든 주요 문제를 완전히 해결하지는 못합니다. 암호 기반 인증을 사용하는 시스템의 암호를 노출시킬 수 있는 5가지의 기본적인 방법이 있습니다. 여기서 "노출"이란 공격자가 다른 사용자의 암호를 알아내서 사용할 수 있음을 말합니다.
  • 암호 추측
  • 키 입력 로거
  • 피싱 공격
  • 사용자에게 묻기
  • 암호나 암호 해시를 저장하는 시스템에 침투
암호 추측은 이제 공격자가 일반적으로 사용하는 공격 방식이 아니며, 키 입력 로거 및 피싱보다 드뭅니다. 암호 추측은 의사 다단계 인증으로 인해 불가능해졌다고도 볼 수 있습니다. 공격자는 암호뿐 아니라 입력 흐름도 추측해야 하기 때문에 일반적인 암호 추측 방법은 의사 다단계 인증 시스템에서는 효과가 없습니다. 입력 측정 정보를 합성하는 것이 이론적으로 가능하기는 하지만 실제 데이터는 대개 피싱 공격이나 키 입력 로거로 알아낼 수 있으므로 거의 그럴 필요가 없습니다. 또한 시스템에서 암호만 사용하는 표준 로그온 인터페이스를 제공한다면 공격자는 암호 추측을 위해 해당 시스템만 사용할 수 있습니다.
게다가 암호 추측 공격은 강력한 암호를 사용함으로써 막을 수 있습니다. 사용자들에게 관련 도구를 사용하도록 하는 등 보다 강력한 암호를 사용하도록 할 수 있다면 굳이 의사 다단계 인증은 필요하지 않습니다. (반면, 일반적으로 의사 다단계 인증 시스템과 함께 사용되는 간단한 암호는 실제로 암호 추측 공격을 받을 가능성이 높습니다.) 따라서 구현에서 암호만 사용하는 로그온을 지원하지 않는 경우 암호 추측을 막기 위해 제공할 수 있는 값은 실제로 값을 추가하는 것뿐입니다. 그리고 아까도 말했듯이 이 방법은 가능하더라도 실제로는 거의 사용되지 않습니다. 즉, 사용자가 의사 다단계 인증 시스템에서 간단한 암호를 사용할 경우 암호 추측 공격이 다시 가능해질 것이므로 의사 다단계 인증은 보안을 강화하는 대신 약화시키게 됩니다. 이 문제에 대해서는 추가 연구가 필요합니다.
또한 의사 다단계 인증은 키 입력 로거의 문제도 해결하지 못합니다. 현재 일반적으로 사용되는 키 입력 로거 중에서 입력 흐름을 감지하는 것이 있는지 모르겠지만 키 입력 로거에 이 기능을 구현할 이유는 전혀 없습니다. 키 입력 로거는 키보드와 컴퓨터 사이에서 기능하는 하드웨어이거나 키 입력을 캡처하는 소프트웨어입니다. 두 경우 모두 로거는 의사 다단계 인증 솔루션에서 사용되는 모든 데이터에 액세스할 수 있습니다.
사실, 인증 솔루션은 사용자 모드에서 실행되고 키 입력 로거는 그것보다 훨씬 아래쪽에 있기 때문에 키 입력 로거에서 더 많은 데이터에 액세스할 수 있습니다. 암호를 캡처하는 데 사용되는 웹 기반 개체와 키보드 간에 신뢰할 수 있는 경로가 없으면 이러한 유형의 암호 노출 공격을 막을 수 없습니다. 의사 다단계 인증 솔루션이 보편화된다면 누군가 반드시 그러한 키 입력 로거를 만들어낼 것입니다.
마찬가지로 피싱 공격도 의사 다단계 인증으로 막을 수 없습니다. 가짜 로그온 화면을 사용하는 대신 공격자는 Flash 개체를 사용하여 암호와 입력 흐름을 알아낼 수 있습니다.
의사 다단계 인증은 공격자의 기술이 사용자의 암호만 제공하는 일부 시나리오에 유용합니다. 예를 들어, 사용자로부터 암호를 알아내는 가장 쉬운 방법은 사용자에게 묻는 것입니다. 결과적으로 이 방법은 사용자에게 직접 만나서, 전화를 통해 또는 피싱 메시지를 통해 물어보든지 간에 효과적인 방법으로 입증되었습니다.
물론 사용자에게 입력 흐름을 물어보는 것은 효과가 떨어집니다. 마찬가지로 회사의 암호 데이터베이스가 노출될 경우 공격자는 암호만 액세스할 수 있습니다. 하지만 이 경우에도 시스템에서 암호만 사용하는 표준 인증을 제공하지 않을 때만 공격을 막을 수 있습니다.
실제로 암호 데이터베이스 자체만 노출되었더라도 공격자는 한 개 또는 여러 개의 정식 사용자 계정 암호를 알고 있을 때보다 더 심층적으로 시스템 정보를 노출시킬 수 있을 것입니다. 따라서 암호 데이터베이스를 소유한 공격자를 막으려는 시도는 실제로 의미가 없을 수 있습니다.

몇 가지 이점
공정하게 평가해 볼 때 시스템에서 암호만 사용하는 표준 로그온 옵션을 제공하지 않는다면 의사 다단계 인증으로 두 가지 문제점을 해결할 수 있습니다. 예를 들어, 암호 공유를 막을 수 있습니다. 하지만 공동 은행 계좌와 같이 여러 사용자가 계정을 공유하는 시스템에서는 단점이 될 수도 있습니다.
또한 웹 사이트 로그인이 아니고 제대로 구성된 대화형 로그온 대화 상자는 입력 흐름이 일치하지 않을 경우 추가 인증 단계를 거치도록 할 수 있습니다. 이를 통해 기밀을 요하는 환경에서 보안 취약한 계정에 대해 추가 보안을 제공할 수 있습니다.

사용자의 오해를 부르는 잘못된 보안 표시
사용자를 혼란스럽게 하는 가장 주된 요소 중 하나는 잘못된 보안 표시입니다. 가장 흔히 볼 수 있는 표시는 그림 1과 같이 웹 페이지에 표시되는 자물쇠 이미지입니다. 이 페이지의 경우 자물쇠 옆에 "Secure(보안)"라는 단어도 표시되어 있습니다.
그림 1 자물쇠 아이콘의 잘못된 사용(크게 보려면 이미지 클릭)
다들 알고 있겠지만 페이지에 자물쇠 이미지와 "보안"이라는 단어를 표시한다고 해서 안전한 것은 아닙니다. 그러나 이러한 표시는 가장 유명하고 가장 많은 공격 대상이 되는 웹 사이트에서 보편화되어 있습니다. 이로 인해 많은 사용자들은 이러한 표시가 주소 표시줄에서 실제로 어떤 의미를 갖는지 확인하는 대신 웹 페이지 본문에서 이러한 안전 표시만을 찾고 있습니다. W3C Web Security Context Wiki는 w3.org/2006/WSC/wiki/PadlockIconMisuse에서 이 문제를 지적했습니다.
이렇게 잘못 사용되는 사례를 쉽게 볼 수 있다는 것은 안타까운 일입니다. 연구에 따르면 사용자들은 인증서가 매우 분명한 경우에도 악의적인 웹 사이트를 식별하지 못하는 것으로 나타났습니다(www.usablesecurity.org/papers/jackson.pdf 참조). 비교할 실제 인증서가 없으니 가짜와 진짜를 쉽게 구분하지 못하는 것입니다. 여기에는 기술이 필요하지만, 웹 페이지에 표시되는 잘못된 보안 표시로 인해 그러한 기술의 개발이 저지되고 사용자들은 잘못된 정보에 익숙해지게 됩니다.
그림 2는 이와 관련된 특히 심각한 문제를 보여 줍니다. 이 경우 정보를 표시하는 페이지는 실제로 안전하지 않습니다. 주소 표시줄을 보면 프로토콜을 나타내는 "http"가 있습니다. 이 사이트에서는 가장 일반적인 최적화 기술을 사용하고 있는데, 로그온 폼이 포함된 페이지를 암호화하는 대신 폼 제출만 암호화합니다. "안전"을 "암호화"와 동일하게 생각한다면 로그인은 페이지에 표시되어 있는 대로 안전합니다. 하지만 여기서 가장 중요한 문제는 사용자가 자격 증명을 보내기 전에 자격 증명이 어디로 전송되는지 확인할 수 있는 방법이 없다는 것입니다. 사이트에서는 폼을 제출하기 전에 사이트를 인증하는 인증서를 사용자에게 보여 주지 않습니다. 이것은 일종의 도박으로, 뒤쳐지면 뒤따라 오던 사람에게 붙잡히게 되듯이 폼이 제출될 쯤에는 이미 피해를 입을 수도 있습니다.
그림 2 안전하지 않은 페이지의 보안 표시(크게 보려면 이미지 클릭)
HTTPS로 보안을 제공하는 프로토콜인 SSL(Secure Sockets Layer)에는 두 가지 중요한 목적이 있습니다. 첫째, 사용자에게 서버를 인증합니다. 둘째, 클라이언트와 서버 간에 사용할 수 있는 세션 암호화 키의 협상을 위한 간편한 메커니즘을 제공합니다.
실제 폼 제출만 암호화될 경우에는 우선적으로 가장 중요한 목적이 달성되지 않습니다. 이 최적화를 구현하는 사이트는 키를 협상하기 위한 방법으로 SSL을 사용합니다. 모순되지만, 사이트에서는 단순히 표준 키 협상 프로토콜을 사용함으로써 이러한 목적을 달성하고 결과적으로 SSL의 비용과 오버헤드를 피할 수 있습니다.
그림 2의 사이트는 흔히 볼 수 있습니다. 많은 사이트에서는 폼 제출에 대해서만 SSL 보호 기능을 제공하고 폼 자체에 대해서는 제공하지 않습니다. 하지만 이 사이트는 그보다 더 놀라운 특징을 보여 줍니다. 브라우저의 주소 표시줄에 https://www.<site>.com(보안이 유지되는 https에 주목)을 입력하면 SSL을 지원하지 않는 사이트 버전으로 리디렉션된다는 것입니다. 자격 증명을 사이트에 보내기 전에 인증서를 검사하려고 해도 사이트에서 인증서를 보여 주지 않습니다.
모든 사이트가 이런 것은 아니지만 많은 사이트가 그러합니다. 그리고 미국의 대표적인 신용 카드 회사 중 두 곳도 그렇습니다. 사실 현재 이용하고 있는 세 곳의 신용 카드 회사 중 American Express에서만 로그온 폼에 인증서를 제공하는 실정입니다. American Express에서는 HTTP 요청도 HTTPS로 리디렉션합니다. 훌륭하지요!
의미 없는 보안 표시와 로그온 폼의 인증서 부재와 관련하여 한 가지 의문이 생깁니다. 사이트에서는 왜 이렇게 할까요? 그 이유는 경제적인 부분 때문입니다. 인증서를 표시하면 페이지를 암호화해야 하고, 페이지를 암호화하면 처리 오버헤드가 발생합니다. 처리 오버헤드는 동일한 부하를 서비스하는 데 더 많은 컴퓨터를 필요로 하며, 컴퓨터가 늘어날수록 비용이 증가합니다. 안타깝게도 고객 개인 정보 보호와 수익 증대 사이에서 많은 기업들은 수익을 먼저 생각하고 있습니다.

열 것인가, 열지 않을 것인가
최근에 건강 보험 회사로부터 놀라운 전자 메일 메시지를 받았습니다. 10년 동안 컴퓨터를 사용해 온 사람이라면 누구나 요청하지 않은 전자 메일 첨부 파일을 열어서는 안 된다는 것을 알고 있습니다. 그러니 그림 3과 같은 메시지를 받았을 때 얼마나 놀랐겠습니까?
그림 3 “보안 첨부 파일”이 포함된 전자 메일 메시지(크게 보려면 이미지 클릭)
사실 건강 보험 회사의 웹 사이트에 문의를 한 적이 있으며, 의심되는 메시지가 도착했을 때는 이 사실에 대해 잊어버렸습니다. 회사에서는 이렇게 답신을 보냈습니다. 처음에는 이것이 똑똑한 피싱 방식이라고 생각했습니다. 하지만 이것이 정당한 메시지였다는 것을 알았을 때 놀라움을 금할 수 없었습니다.
가장 첫 번째 지침은 첨부 파일을 두 번 클릭하여 메시지의 암호화를 풀라는 것이었습니다. 보안 커뮤니티와 IT 관리자들은 지난 10년 동안 사용자들에게 첨부 파일을 두 번 클릭하지 말도록 가르치는 데 수많은 시간을 쏟아 왔습니다. 그런데 보험 회사에서는 보안을 위해 첨부 파일을 클릭하라고 했습니다. 사실 이 건강 보험 회사만이 이 방식을 사용하는 것이 아닙니다. 이런 상황에서 사용자는 어떻게 해야 합니까? 누구의 말을 따르고, 누구의 말을 따르지 말아야 합니까?
그래서 저는 Microsoft® Office Outlook® 2007의 미리 보기 기능을 사용하여 메시지를 확인했습니다. 그림 4에 나와 있는 것처럼 Outlook에서는 해당 메시지가 위험할 수 있으므로 열지 말도록 경고했습니다!
그림 4 Outlook 2007에서 보안 문서를 악의적인 것으로 판단(크게 보려면 이미지 클릭)
건강 보험 회사가 전 세계적으로 가장 많이 보급된 전자 메일 클라이언트에서 사용되는 매우 기본적인 보안 확인을 위반하고 있다는 사실은 정말 안타깝고도 어리둥절한 일입니다. 이 회사가 Outlook으로 새 보안 솔루션을 테스트하지도 않았다고 생각하니 이 회사가 도대체 개인 정보 보호를 위해 무엇을 하고 있을지 의문스러웠습니다. 또한 단지 고객의 개인 정보를 충분히 보호하지 않는다는 고소를 피하기 위해 이 회사가 다른 어떤 솔루션을 구현하고 있을지도 모르겠다는 생각이 들었습니다. 이것은 재무 기관에서 수행하고 있는 보안 전시 행정과 유사합니다. 이 회사의 경우 실제로 고객을 보호하기 위해서가 아니라 고소를 면하기 위한 것이 솔루션의 기본 목적이라고 생각합니다.
저는 첨부 파일이 실제로 무엇인지 확인해 보기로 했습니다. ActiveX® 컨트롤 개체였습니다. 첨부 파일을 확인하려면 Internet Explorer®에서 열고 개체를 설치해야 했습니다. 그림 5와 같이 확인하는 화면이 다시 표시되었습니다. 보시다시피 설계자들은 메시지가 실제 우편 봉투와 같이 보이도록 하기 위해 많은 노력을 했으며, 봉투에는 신뢰할 수 있다는 것을 나타내기 위한 스탬프도 있습니다.
그림 5 봉투에 “Trusted(신뢰할 수 있음)”가 찍힌 보안 문서(크게 보려면 이미지 클릭)
이와 같은 기술은 여러 가지 이유로 위험합니다. 첫째, 사용자에게 원치 않는 첨부 파일을 열도록 하는, 권장되지 않는 행동을 요구합니다. 둘째, 실제 메시지에서 확인 없이 항상 첨부 파일을 열도록 시스템을 구성하라는, 바람직하지 않은 지침을 제공하고 있습니다. 셋째, 전자 메일에서는 신뢰할 수 있다고 말하고, Outlook에서는 신뢰할 수 없다고 말하게 되면 메시지가 매우 의심스러워 보입니다. 마지막으로, 실제 첨부 파일에는 사용자에게 신뢰할 수 있다고 확신시키는 의미 없는 보안 표시가 포함되어 있습니다. 사용자가 이러한 종류의 메시지를 신뢰하기 시작하면 유사한 형태의 악의적인 메시지를 신뢰하는 것은 시간 문제입니다.

보안 통신 제공
이 기술이 해결하려고 시도하는 문제가 매우 중요하다는 것은 인정합니다. 고객과 신뢰할 수 있는 방식으로 통신하는 것은 쉬운 일이 아닙니다. 하지만 이 특정 솔루션은 과도하게 구현되었습니다. 이로 인해 고객은 혼란을 느끼고 해결하려는 의도와 반대의 결과로 이어질 수 있습니다. 즉, 고객의 시스템이 노출될 수 있습니다.
제대로 구현된 웹 사이트에서는 "메시지 센터"를 사용합니다. 이러한 설계에서는, 회사에서 고객과 통신해야 할 때 "귀하에게 메시지 센터에 도착한 메시지가 있습니다. 메시지를 보려면 웹 사이트에 방문하여 로그온하고 메시지 센터 링크를 클릭하십시오."라는 내용의 전자 메일 메시지를 보냅니다. 회사에서 S/MIME(Secure Multipurpose Internet Mail Extensions)을 사용하여, 고객이 보는 모든 전자 메일 메시지에 서명을 하면 사용자가 소스를 인증할 수 있으므로 추가 이점이 있습니다. 메시지에 "이 링크를 클릭하십시오"라는 항목을 포함시키지 않으면 또 하나의 추가 이점이 있습니다. 사용자가 직접 회사의 URL을 입력해야 원하는 사이트로 이동할 수 있다는 것입니다.
메시지 센터와 서명된 메시지를 사용하여 회사에서는 고객과 신뢰할 수 있는 경로로 통신할 수 있게 됩니다. 메시지 워크플로 중 고객이 보는 모든 것은 인증되며, 회사에서는 낮은 수준의 보안 방식을 요구하지 않습니다.

개인 정보 보호
지금까지 이번 시리즈의 두 편의 글을 통해 보안 전문가들이 사용자에게 실제로 얼마나 피해를 주고 있는지 설명했습니다. 보안을 유지하는 것은 우리의 임무입니다. 그러나 많은 결정 및 구현 솔루션을 통해 사용자들에게 혼란을 주고, 잘못된 결정을 내리게 하며, 잘못된 보안 인식을 심어 주고 있습니다. 우리는 이렇게 혼란스럽게 사용자에게 부담을 주어서는 안 됩니다.
앞에서도 말했듯이 일반 사용자에게 보안은 단순히 암호 및 신용 카드 번호를 보호하는 것입니다. 사용자들은 기술이 제대로 작동하고 신뢰할 수 있기를 원합니다. 안타깝게도 결정은 사용자들이 내려야 하고, 이러한 결정을 내리도록 정보를 제공하는 것은 우리의 임무입니다.
이번 시리즈의 마지막 편에서는 고객이 사용할 수 있는 가장 중요한 기술 중 일부가 얼마나 기대에 못 미치는지에 대해 설명하겠습니다. 또한 다른 전문가들의 의견도 수록할 예정입니다. 2008년 9월의 Security Watch 칼럼으로 다시 찾아 뵙겠습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년의 보안 관련 경력을 보유한 Enterprise Security 영역의 Microsoft MVP(Most Valuable Professional)입니다. 그의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.


지속 가능한 컴퓨팅 그린워싱 가려내기
Dave Ohara

목차
수치의 필요성
에너지 사용량 측정
역률
프로덕션 환경에서의 측정
Microsoft Enterprise Engineering Center
요약
절전, 우수 효율성 등을 내세우며 판매되는 소위 그린(Green) 제품과 솔루션이 크게 늘고 있습니다. 시장에서 이러한 마케팅 활동은 무엇이 진정 환경 친화적인가에 대한 혼란만 가중시키는 형국입니다. 갖가지 제품의 사양에 대한 평가가 이루어졌더라도, 환경 문제가 이렇게 중요한 상황에서
어떤 장비를 사용할 것인지 IT 전문가가 판단하기가 (불가능하지는 않더라도) 쉬운 일이 아닙니다. 어떤 데모에서든 상당한 에너지 절약 효과가 항상 강조되므로, 이러한 ROI(투자 수익률) 덕분에 업그레이드의 타당성을 입증하기가 쉽겠다고 생각하기 마련입니다. 결국 에너지 절약 제품이라면 TCO(총 소유 비용)가 줄어들어야 합니다.
유형을 막론하고 여러 기업들이 거의 모든 제품에 환경 레이블을 부착하고 그린 솔루션에 대한 최근의 관심을 이용하는 행보는 "그린워싱(greenwashing)"이라는 개념까지 탄생시켰습니다. 이는 환경 보호 효과를 과장하여 내세우는 것을 가리킵니다. 그렇다면 에너지 절약의 진실은 무엇입니까? 가정에서 에너지 효율성이 높은 전구를 설치하는 것처럼 명확하지는 않습니다.
지속 가능한 IT에 관한 관심이 높아지고 환경 친화적 IT 장비 시장이 확대되면서 많은 사람들과 기업들은 에너지 효율적인 랩톱, 데스크톱과 서버를 배포하고 가상화를 통해 전력 소비량을 줄인다는 최종적인 성과에 매달리고 있습니다. 그러나 지금까지 구입했던 제품과 솔루션의 진정한 가치를 평가하는 에너지 감사를 실시하는 곳은 드문 편입니다.
프로덕션 환경을 적극적으로 측정하는 것이 이상적인 시나리오이지만, 이 역시 많은 비용이 들 수 있습니다. 프로덕션 환경에서 측정할 준비가 되지 않았다 하더라도 가급적 서둘러, 성능 및 평가 테스트 환경에서 에너지 감사를 실시함으로써 진일보할 수 있습니다. 대부분의 기업들은 구매에 앞서 장비를 테스트하고 평가하는 일을 담당하는 실험실이나 그룹이 있습니다. 여기서 에너지 성능을 테스트 기준 중 하나로 추가한 다음, 구매 결정을 내릴 때 제조업체가 제시하는 수치에 의존하기 보다는 그 테스트 결과를 반영하면 됩니다. 따라서 테스트 과정에서 장치 전력 소비 데이터베이스를 직접 작성합니다. 그렇게 하면 그린워싱을 배제하고, 실제로 효과가 있는 제품과 솔루션을 찾아낼 수 있습니다.
물론 실제 부하 상태에서의 정확한 운영 수치를 얻고 싶다면 프로덕션 환경에서 모니터링을 실시해야 합니다. 더 빨리 프로덕션 환경 모니터링을 시작할수록 기업 및 기업의 수익성에 이익이 될 것입니다. 이 프로세스는 기업의 장기적인 성공에 중요한 역할을 할 것입니다.

수치의 필요성
이상적인 경우라면 실제 사용자 부하에서 하드웨어 장치의 전력(와트) 대비 성능을 평가하는 독립적인 테스트가 실시될 것입니다. 그러나 아직 업계는 그와 같은 테스트를 개발하고 보급한지 얼마 되지 않았습니다. 그리고 SPEC Power 벤치마크와 같이 현재 제공되는 테스트는 아직 초기 단계에 있습니다. 이러한 에너지 테스트가 얼마나 효과적일 것인가도 미지수입니다. 그러나 여느 테스트와 마찬가지로 제조업체들은 최적의 테스트 결과를 얻기 위해 장비를 수정하는 방법을 습득할 것입니다.
경험이 풍부한 IT 전문가들은 테스트 환경에서 실시한 검사에 의문을 제기하기 시작했습니다. 자동차 회사들이 도로 주행 성능 테스트에 가장 좋은 차를 보내는 것처럼, IT 공급업체들도 효율성이 가장 우수한 장비 구성으로 에너지 테스트를 치를 것입니다.
가상화의 이점을 입증할 서버 통합이 전혀 구현되지 않은 상태에서 과도하게 프로비저닝된 일군의 서버들을 비교하는 데 가상화 테스트가 이용되는 것과 마찬가지입니다. 공급업체들은 가상화를 비롯한 에너지 절약 프로젝트에서 발생할 수 있는 반동 효과와 같은 문제를 제대로 언급하지 않습니다. 근본적으로, 에너지 효율성으로 비용이 감소하면 그에 대한 반응으로 수요가 증가하고 결국 에너지 사용을 부추겨 사용량이 증가하게 됩니다. 가상화와 같이 절대적인 에너지 절약 효과를 내세우는 솔루션을 평가할 때 비판적인 시각으로 꼼꼼하게 살펴야 합니다. 모든 구성 요소가 제대로 연동하며 기능을 수행하는지 그리고 시간이 경과하면서 어떠한 연쇄 작용이 발생할 것인지 확인해야 합니다.
그렇다면 귀사의 환경에 적합한 경로를 어떻게 찾습니까? 유료로 평가를 시행해 줄 컨설턴트는 많습니다. 그러나 이 방법의 단점도 몇 가지 있습니다. 효율성과 관련된 전문 지식을 외부인에게 넘기는 것을 정말 원하십니까? 장기적인 계약을 체결하여 자신의 서비스에 대한 의존도를 높이려는 컨설턴트에게 모든 것을 맡기고 싶으십니까?
이를 대규모의 프로젝트로 발전시켜 수십 명의 인원을 참여시킴으로써 귀사 환경의 지속 가능성 전략을 결정할 수도 있습니다. 환경 중 어느 한 영역만 선택하여 측정하는 것은 피해야 합니다. 그 영역이 맞을 것 같다고 해도 임의적인 조치에 불과하므로 이 방법은 의미가 없습니다. 어디서 에너지 소비가 발생하며 어디서 효과를 낼 수 있는지 정확하게 분석해야 합니다.

에너지 사용량 측정
새로운 관점에서 현재의 상황을 살펴봐야 합니다. IT 전문가들은 어떤 하드웨어가 제대로 작동하지 않을 때, 예를 들어, 서비스가 중단될 경우 이를 알아냅니다. 그러나 전력 소비 측면에서 어떤 하드웨어가 제대로 작동하지 않는 경우는 어떻습니까? 대부분의 조직에서는 에너지 효율성의 기준선을 설정할 데이터가 없으므로, 그러한 상황은 감지되지 않을 것입니다.
그렇다면 이러한 수치를 어떻게 얻을 수 있습니까? 에너지 책임자(energy czar)의 필요성을 제기하는 이들도 있습니다. 그러나 이 방법을 위해서는 전력 문제에 관한 기술 전문가가 회사 곳곳을 돌아다니며 조사할 수 있어야 합니다. 더 간단하면서도 실현 가능한 방법 중 하나는 성능 테스트 환경의 기존 기능에 에너지 측정 도구를 추가하는 것입니다.
다양한 에너지 측정 장치가 보급되고 있습니다. 안타깝게도, 현재로서는 IT 성능 테스트 환경에 완벽하게 들어맞는 장치가 없습니다. 가장 기본적인 장치로는 Watts Up Pro가 있습니다. 이 USB 장치는 120V의 인라인 전력을 측정합니다. 또 다른 장치인 Smart-Watt는 네트워크 연결이 가능한 전력 소비 장치로서 100-240V와 15-30암페어 범위를 지원합니다. Smart-Watt 장치를 온도 및 습도 센서와 함께 사용하면서 환경 요인을 측정할 수도 있습니다. 그리고 Extech Appliance Tester 380801 및 Fluke 345 Power Clamp와 같은 산업용 전력 분석 장치도 있습니다. 테스트 환경의 필요 사항을 해결할 때 이와 같은 장치는 어려움 없이 구할 수 있습니다.

역률
전력 측정 초보자라면 역률(power factor)의 개념을 이해하는 것이 중요합니다. AC 전기 시스템의 역률은 유효 전력(real power) 대비 피상 전력(apparent power)의 비율로 정의되며, 0 ~ 1 범위의 수치로 표시합니다. 유효 전력(와트)은 회로가 기능을 수행하기 위한 용량입니다. 피상 전력(VA)은 회로상의 전류와 전압의 곱입니다.
왜 역률이 중요한지 의문이 생길 수 있습니다. 그림 1을 살펴보시기 바랍니다. 이 사진은 랩톱, 전구와 콘덴서의 에너지 효율성을 비교하는 데 사용되는 Smart Works의 에너지 모니터링 장치입니다. 전구는 50와트 부하와 50VA이므로 역률이 1.0입니다. 순수 용량성 부하의 콘덴서는 2와트의 부하와 193VA를 발생시키므로, 역률이 0.01입니다. 랩톱은 22와트의 전력을 소비하지만 48VA로 측정되므로 역률은 .47이 됩니다. 랩톱의 역률이 낮은 것은 아마도 목표 제조 원가를 맞추기 위해 비효율적인 전원 공급 장치 설계를 적용했기 때문입니다.
그림 1 랩톱, 전구와 콘덴서의 전력 소비(크게 보려면 이미지 클릭)
에너지 효율성에 대한 관심이 고조되는 가운데 공급업체들은 예상 조건에서 전원 공급 장치의 성능을 높일 방안을 모색하는 중입니다. 기존 장비의 역률을 새 장비의 역률과 비교할 경우, 더 효율적인 전원 공급 장치를 사용하고 역률이 높은 솔루션을 선택하면 어느 정도의 전기 용량을 추가로 확보할 수 있습니다.

프로덕션 환경에서의 측정
성능 테스트 환경에서 결과를 측정하는 것은 프로덕션 환경에서의 성능을 예측하는 데 목적이 있습니다. 프로덕션 환경에서 에너지 소비를 측정할 경우 모든 장치를 측정하는 데 드는 비용이 문제가 됩니다. 그러나 프로덕션 환경의 전력 측정 비용을 줄이는 전략 중 하나는 전력 분배기(PDU)에서 측정하여 여러 장비의 측정값을 합산하는 것입니다. 그림 2는 PDU의 에너지 측정값을 보여 줍니다. 하나의 PDU에 동일한 여러 장비가 연결된 경우입니다. 서버당 평균 소비 전력을 계산할 수 있으므로, 이 측정 방법으로 프로덕션 환경의 소비 전력 수치를 구하는 것이 가능해집니다.
그림 2 PDU에서의 측정(크게 보려면 이미지 클릭)
각 장비가 측정되므로 이 전력 정보를 구성 관리 데이터베이스로 통합해야 합니다. 이 작업이 너무 어렵다면 직접 데이터베이스를 작성하거나 적어도 Excel® 스프레드시트에서 장치와 그 소비 전력을 목록으로 작성할 수 있습니다. 장치를 추가해 가면서 다른 장치의 추정치를 입력하고 전체 전력-용량 계산식을 작성할 수 있습니다. 에너지 효율적인 신형 서버는 피크 상태가 아닌 유휴 상태에서 전력 부하의 절반 미만을 소비한다는 사실을 명심하십시오. 그리고 쓸모 없는 솔루션을 실행하고 있는 구식 서버가 있다면, 이 구식 서버는 유휴 상태이더라도 상당량의 전력을 소비할 것입니다. 이는 소비 전력을 줄이는 데 가장 손쉬운 대상 중 하나입니다.
개선 노력을 계속 이어가려면 데이터 센터에서 사용하는 랙 단위 소비 전력을 계산하는 것이 다음 단계입니다. 또한 환경을 변경할 때 전력 및 냉방 용량을 반드시 확인해야 합니다. 시간이 흐르면서 장비가 차지하는 공간뿐 아니라 필요 전력의 기준에서 장비를 평가하기 시작할 것입니다. 공간은 정적이고 가시적이므로 쉬운 개념입니다. IT 전문가들은 1U, 2U 및 4U 서버에 대해 어려움 없이 얘기할 수 있지만, 200와트 서버와 450와트 서버를 비교하기 시작하면 동일한 IT 전문가라도 대화하기가 쉽지 않을 것입니다. 이는 IT 장비에 대한 새로운 언어가 되었으며, 이 점은 오늘날 데이터 센터에서 분명하게 드러납니다. 최대 전력 용량에 도달했음에도 불구하고 추가 장비용 공간이 넉넉한 곳이 많습니다.

Microsoft Enterprise Engineering Center
최근 Microsoft Enterprise Engineering Center(EEC)는 시설에 대한 전력 측정 기능을 도입했습니다. 미국 워싱턴주 레드먼드의 Microsoft 본사에 위치한 EEC(microsoft.com/windowsserver/evaluation/eec/default.mspx)는 가장 복잡한 컴퓨팅 환경도 검증할 수 있는 최첨단 시설입니다.
4천만 달러 이상의 하드웨어와 네트워킹 장비를 갖춘(그림 3 참조) EEC에서는 아무리 복잡한 실제 프로덕션 환경도 재현할 수 있습니다. 이 그룹은 대표적인 네트워킹, 스토리지 및 클라이언트/서버 솔루션 공급자와 손 잡고 다양한 최첨단 기술과 레거시 플랫폼을 제공합니다. 각 테스트가 고객의 현재 환경을 정확하게 반영하는 것을 목적으로 합니다. 이 곳에서 가장 최근에 개발 중인 서비스는 솔루션의 소비 전력을 보고하여 전력 대비 성능 벤치마크를 제공하는 것입니다.
그림 3 EEC 실험실에 늘어선 장비의 열 중 하나(크게 보려면 이미지 클릭)
지난 몇 년간 EEC는 많은 데이터 센터 운영자가 장비에 전력과 냉방을 제대로 공급하지 못하는 상황을 목격했습니다. 최첨단 장비는 전력 밀도가 높아 시설에 더 큰 부담으로 작용하곤 합니다. EEC 팀은 전력 및 냉방 인프라를 업그레이드하는 데 드는 비용과 시간을 직접 경험했습니다. 더 효율적이고 경제적인 운영을 위해 EEC는 장치당 전력을 측정하는 기능을 추가했습니다.
EEC에서 사용 중인 일부 도구와 장비는 이 기사가 작성되던 시점에는 출시되지 않았습니다. 새로운 솔루션이기 때문에 EEC는 앞으로도 고객, 공급업체 및 Microsoft 개발 팀과 협력하면서 더 우수한 기술을 개발할 것입니다. EEC는 지금까지의 개발에 적용했던 방식을 고객과 직접 공유하면서 조기에 피드백을 받고 또한 고객이 직접 벤치마크를 마련할 수 있도록 지원합니다.
그리고 명확한 결과를 전제로 하지 않습니다. EEC는 EEC 성능 테스트 환경에서 에너지 모니터링 기능을 활용하면서 얻은 흥미로운 결과 중 일부를 공유했습니다.
  1. 장치를 끄더라도 소비 전력이 예상만큼 감소하지는 않습니다(그림 4 참조). 전원을 껐지만 플러그를 계속 꽂아 놓은 서버 하드웨어 장치가 100와트의 전력을 소비한 사례도 있었습니다. 이는 많은 이에게 놀라운 결과였으며, EEC는 이 설정으로 여러 차례 테스트를 반복했습니다. 결국 적외선 온도계를 사용하여 입력/출력 콘센트 온도를 측정했는데, 이 장치가 꺼진 상태에서 100와트를 소비한다는 사실을 확인했습니다.
  2. 소프트웨어가 전력 소비에 큰 영향을 미칠 수 있습니다. 동일한 네트워킹 스위치(하드웨어 및 BIOS 구성 동일)에서 서로 다른 네트워킹 소프트웨어를 실행한 결과, 21%의 소비 전력 차이가 나타났습니다. 보안 및 모니터링 도구처럼 더 많은 프로세서와 기능이 활성화되는 고급 솔루션이 더 단순한 일반 솔루션보다 소비 전력이 더 높은 경우가 많았습니다.
  3. 가상화 시나리오에서 EEC는 특정 하드웨어에서 전력 대비 성능이 극대화되는 시점을 파악하기 위해 I/O 사용률 및 CPU 사용률 대비 소비 전력을 측정했습니다. CPU 사용률에 한정하여 초점을 맞추면 물리적 시스템에 지나치게 많은 가상 시스템이 로드되어 사실상 전력 대비 성능이 저하된다는 사실을 EEC는 밝혀냈습니다.
  4. 예상대로 밀도가 높은 장치는 더 많은 전력 및 냉방 문제를 야기합니다. 고밀도 시스템을 배포할 경우, 가급적 일찍 전력 및 냉방 시설 담당자와 상의해야 합니다. 해당 환경에 전력 공급이 제한적이라는 사실을 알고 있다면, 프로덕션 환경에서 그러한 장치에 자체 전력 모니터링 장치를 설치하는 것을 고려할 만합니다.
  5. 이중 전원 공급 장치는 단일 전원 공급 장치보다 훨씬 많은 전력을 소비할 수 있습니다.
  6. 구성이 동일하고 외관상 똑같아 보이는 하드웨어가 소비 전력이 크게 다를 수 있습니다. EEC 담당자가 실제로 하드웨어가 동일하게 구성되었는지 재확인할 만큼 큰 차이가 관찰되었습니다.
  7. 제품에 표시된 전력 등급은 실제 소비 전력 수치가 아니라 전원 공급 장치의 정격 용량입니다.
  8. 지식을 수집하고 자료를 비교하기 위해 장치 및 하위 구성 요소별로 소비 전력 테스트와 그 결과에 대한 데이터베이스를 구축하고 유지 관리하는 것이 중요합니다.
  9. 같은 양의 RAM도 다르게 구성하면 에너지 소비량이 달라집니다. 일반적으로 DIMM 수가 적을수록 소비 전력이 줄어듭니다(예: 4 x 2GB DIMM과 8 x 1GB DIMM). 그러나 더 적은 수의 DIMM이 더 많은 전력을 소비한 경우도 있었습니다.
그림 4 전원을 켜고 껐을 때의 소비 전력 비교(크게 보려면 이미지 클릭)

요약
성능 테스트 환경에 소비 전력을 측정하는 기능을 추가함으로써, 장치별 소비 전력 정보를 정확한 실제 부하 수치와 함께 관리하는 데이터베이스를 직접 만들 수 있습니다. 이러한 솔루션을 배포할 때 폐회로 피드백(closed-loop feedback) 방식으로 결과 감사를 실시하여 성능 테스트의 정확성을 검증해야 합니다. EEC에서 자체 측정 테스트를 실시하여 확인한 것처럼, 그린워싱을 걸러내고 진실을 발견하는 데 도움이 될 몇 가지 흥미로운 사실이 있습니다.
성능 테스트 환경에서의 이러한 측정 방법은 시장 전체에 영향을 미쳐 실제로 가장 에너지 효율성이 높은 제품을 찾아내는 노력으로 이어질 것입니다. 그리고 시간이 흐르면서 제조업체들은 자신의 에너지 절약 주장을 뒷받침할 더 정확한 데이터를 제시할 필요성을 깨닫게 될 것입니다. 물론 IT 전문가들이 장치당 전력(와트)을 일반적인 구매 기준으로 삼는 때도 올 것입니다. 이는 특히 서버를 대량 구입하는 기업에서 보편적인 관행으로 정착되어야 합니다. 한편 귀사도 지금부터 전력을 귀중한 IT 리소스 중 하나로 인식함으로써 이러한 흐름에 앞장설 수 있습니다.
데이터 센터의 냉방 관리
데이터 센터 냉방에는 에너지 소비를 줄일 기회가 무궁무진합니다. 데이터 센터에서 얼마나 많은 열이 발생하며 하드웨어의 온도를 낮추기 위해 얼마나 많은 에너지가 사용되고 있는지 알게 되면 놀랄 수 밖에 없습니다. 그러나 효과적으로 냉방을 관리하고 문제를 바로잡으며 더 효율적인 냉방 솔루션을 개발하고 싶다면, 온도 모니터링 솔루션이 필요합니다. Microsoft 데이터 센터에서 사용하는 솔루션을 고려해 보십시오.
Microsoft Research에서는 온도 조절 성능을 높이고 다양한 냉방 개선 조치를 평가할 수 있는, 데이터 센터용 온도 센서 네트워크를 구축했습니다. 예를 들어, 한 Microsoft 데이터 센터에서는 더운 공기와 찬 공기의 분리 효과를 높이기 위해 통로 끝에 에어 커튼을 설치하고 평가를 실시했습니다. 커튼을 설치하자 일부 서버에서 과열 경보를 보내기 시작했습니다. 물론 운영 엔지니어는 찬 공기를 더 많이 공급하기 위해 냉방 시스템의 공기 흐름을 늘렸습니다. 하지만 놀랍게도 더 많은 서버가 과열 경보를 보내기 시작했습니다. 그리고 이 서버들은 모두 랙의 맨 아래에 있었습니다. 아시다시피 이중 바닥형(raised-floor) 냉방 시스템에서는 아래쪽의 온도가 가장 낮습니다.
엔지니어들은 랙의 상단으로 갈수록 온도가 내려가고 랙의 맨 아래가 가장 뜨겁다는 사실을 센서 네트워크를 통해 확인했습니다. 그리고 이들은 랙의 맨 아래와 바닥 사이의 뜨거운 통로에서 더운 공기가 나오고 있음을 깨달았습니다. 베르누이의 법칙이 작용한 것입니다. 랙의 아래쪽을 밀봉하고 공기 흐름의 속도를 낮춤으로써 이 과열 문제를 쉽게 해결했습니다.
이는 Microsoft Enterprise Engineering Center가 성능 테스트를 실시하면서 수집하고 분석한 데이터의 한 예입니다. 따라서 최근 EEC는 배포 테스트 준비가 완료되었음을 Microsoft Research에 알렸습니다. 하루도 채 되지 않아 10개의 랙에 시스템이 배포되었고, 불과 1시간 만에 설치가 완료되었습니다. 이제 EEC는 냉방 문제 그리고 하드웨어 성능과의 관계를 연구하고 더 정확하게 이해할 수 있게 되었습니다.
물론 모니터링만으로는 문제가 해결되지 않습니다. 해결 가능한 문제 영역을 찾아내고, 변경하며, 다양한 솔루션을 평가하여 기대한 결과를 내놓는지 확인할 수 있어야 진정한 가치가 실현됩니다. 결론적으로, 귀사는 새로 도입한 냉방 솔루션 때문에 예기치 않게 랙이 과열될 때 속수무책인 처지에 놓이는 것을 원치 않을 것입니다.

Dave Ohara는 26년간 기술 전문가로 활동해 왔습니다. 현재 그는 그린 프로젝트를 시행하는 여러 기업을 위해 일하고 있습니다.


Field Notes 세상을 구하는 IMAP
R'ykandar Korra'ti

때때로 새롭고 사소한 문제의 해결책으로 기존의 중대한 문제까지 해결하는 경우도 있습니다. 그러한 사례 중 하나를 소개합니다.
지난 겨울, 우리 회사의 웹 관리자가 MacBook을 구입했습니다. 그녀는 지금까지 Windows®만 사용했었으나, 이제는 OS X 그리고 가상 시스템에서 Windows Mobile® 장치와 그 밖의 몇몇 간단한 작업을 동기화하기 위해 Windows XP를 사용하게 되었습니다.
이 관리자는 두 운영 체제 모두에서 자신의 메일 아카이브에 액세스해야 합니다. 하지만 Mac에서 Entourage를 사용하는 건 원치 않습니다. 그랬더라면 매우 쉽게 해결되었을 문제입니다. 여하튼 그녀는 OS X와 함께 제공된 전자 메일 클라이언트인 Mail.app를 사용하길 원했습니다. 어쩌다보니 그녀는 모든 메일을 미러링하지 않은 채로 랩톱의 로컬 저장소에 보관하고 있었습니다. 이 상황을 해결하는 것이 제가 할 일이었습니다.
어디서든 아카이브를 읽을 수 있게 하는 것은 앞서 말한 대로 사소한 문제입니다. 이 사례가 전하는 첫 번째 교훈이기도 한데, Exchange Server, Microsoft® Office Outlook® 및 메일을 비롯한 모든 것이 IMAP4를 지원하기 때문입니다. IMAP4는 씬 클라이언트에서 서버상의 메시지 저장소를 처리하기 위한 메시징 프로토콜입니다. Exchange만큼 기능이 많지는 않지만, 유용하게 사용됩니다(How IT Works: IMAP4 - TechNet Magazine 2006년 3월-4월호 technet.microsoft.com/magazine/cc161016 참조).
그렇다면 몇 가지 설정을 변경하여 SSL을 통해 IMAP4를 온라인으로 설정하고, 이 관리자의 로컬 폴더를 모두 서버로 복사한 다음 ping합니다! 그녀는 모든 클라이언트에 있는 메일에 액세스하고 Windows Mobile 장치를 계속 업데이트할 수 있습니다. 문제가 해결되었습니다.
그러나 어떤 번거로운 문제에 대해 간단한 해결책을 얻는 것은 소형 회전톱을 새로 장만한 것과도 같습니다. 갑작기 합판을 더 구하게 되고 언제라도 "로미오와 줄리엣"을 상연할 수 있는 무대 세트를 어느새 완성하게 되는 것입니다.
소규모 ISP인 우리 회사는 Windows, OS X, Mac OS 및 Linux를 사용하며, 게다가 구석진 곳에서 친구를 갈망하는, 늙고 외로운 AmigaOS 시스템까지 있습니다. 그 옛날 우리 회사는 이 Amiga 시스템에서 Usenet 뉴스와 UUCP 메일을 호스팅했습니다. 즉 RFC-733/AmigaUUCP 형식의 아카이브를 만들어 보관했던 것입니다. 게다가 Microsoft Mail 아카이브(.mmf 형식)와 몇몇의 구형 UNIX 메일 아카이브(.mbox 형식)도 있습니다. 이 갖가지 아카이브들이 우리를 비웃듯이 자리를 차지하고 있습니다. 이따끔씩 우리는 이 문제를 해결하겠다고 나섰으나 곧 절규하며 포기하곤 했습니다.
이번 시나리오에서 우리는 두 번째 교훈을 떠올리지 않을 수 없습니다. 바로 Danger Hacker의 모토입니다. 대체할 수 없다면 절대 지우지 말라는 것입니다.
우리는 먼저 Microsoft Mail 아카이브를 처리했습니다. 한때 Outlook은 .mmf 파일을 가져오지 못했습니다. 그러나 지난 몇 년간 클라이언트를 업그레이드했으며, 앞으로의 일이 어떻게 될지 모르므로 옛날 제품별로 하나 이상의 라이선스를 유지했습니다. 그 덕분에 우리 회사의 라이선스 보관함은 마치 Microsoft Corporation의 연대기 같습니다. MS-DOS®가 필요하신가요? OS/2 1.31은? Microsoft Mail은? Office 95는? 물론 있습니다! 영어판 아니면 프랑스어판?
Outlook 2000은 .mmf를 가져왔지만, 이 제품의 IMAP 지원은 좀 특이해서 가끔씩 헤더 데이터를 빠뜨리곤 했습니다. 게다가 IMAP4 및 Exchange 서버와 동시에 통신할 수가 없었습니다. 좀 성가신 문제였지만, 심각한 것은 아니었습니다. Outlook 2000을 통해 .mmf 파일을 가져오고 보유하고 있는 Outlook 2003 라이선스로 업그레이드한 후 몇 시간 동안 끌어서 놓기 작업을 한 결과, 15년 된 아카이브가 온라인화되어 어디서든 볼 수 있게 되었습니다. .mbox도 마찬가지로 처리했는데, mbox 호환 IMAP 서버를 Linux 시스템으로 옮기고 .mbox 형식의 아카이브를 작업 디렉터리에 저장했습니다. 그런 다음 Outlook IMAP 지원을 이용하여 해당 프로덕션 서버에 연결하여 폴더를 복사합니다.
한편 Amiga 아카이브에서는 RFC-733 헤더를 RFC-822 형식으로 변환하고 기존의 SysV-style 메시지 구분선을 정리하며 특이한 From: 라인 데이터를 기존의 저장소로부터 검색하기 위해 약간의 C 코드 작성이 필요했습니다. 그동안 문제를 오랫동안 방치했기 때문에 이런 수고가 생기는 것입니다. 여하튼 모든 일을 마치자 AmigaUUCP 형식은 .mbox 형식이 되었습니다. 그리고 동일한 작업 디렉터리로 저장하자 Outlook IMAP4는 이 메일을 마치 새 메일처럼 즉시 가져왔습니다. 첨부 파일도 매우 깔끔하게 패키지화되었습니다.
이제 1990년까지의 아카이브도 단일 형식으로 온라인화했으며, 이와 같이 처리할 아카이브가 또 있는지 확인하는 중입니다. 못 해낼 이유가 없으니까요. 근사하지 않습니까?

R'ykandar Korra'ti는 소규모 공동 ISP의 전자 메일 관리자로, 파트너 Anna와 함께 시애틀 근교에 거주하고 있습니다. Microsoft에 메일 제품을 공급하기도 했던 그녀는 거의 알려지지 않은 만돌린 곡을 작사하지 않을 때는 기술 관련 기사를 쓰고 있습니다. 관심 있는 출판 대행사는 darako@murkworks.net으로 연락하시면 됩니다.


Windows Confidential 과거의 유산
Raymond Chen

동료 한 사람이 먼지투성이의 벽장에서 Alpha AXP 시스템 한 대를 찾아냈습니다. 시스템을 부팅하자 2000년 초에 출시되었던 64비트 버전의 Windows®가 실행되었습니다. 어떻게 이런 일이 일어날 수 있을까요?"
어쩌다 보니 당시 그 시스템 중 한 대가 제 사무실에 있었습니다. 한때 무시 못할 위력을 떨치던 시스템입니다. 소형 냉장고만한 크기에 진공 청소기만큼의 소음을 냈습니다. 자그마치 4개의 Alpha AXP 프로세서를 장착했고, 이 프로세서 각각은 놀랍게도 400MHz의 속도를 자랑했습니다. 1GB의 RAM 그리고 12개의 고속 SCSI 드라이브를 스트라이프한 13GB의 하드 드라이브 공간을 갖추었습니다. 요즘 같으면 보잘것없어 보이겠지만, 1990년대에 이 Alpha AXP 시스템은 선망의 대상이었으며 점심 테이블에서 단연 인기 스타로 떠오르게 해주는 자산이었습니다.
1999년에 Compaq이 더 이상 Alpha AXP에서 Windows를 지원하지 않겠다고 발표하자 갑자기 수많은 Alpha AXP 시스템은 정식 임무도 없이 Microsoft 옆에 둘러앉는 처지가 되었습니다. 그러나 그 시스템 중 일부에게는 다채로운 비공식적인 임무가 주어졌습니다. 저는 Windows 소스 코드 전체의 인덱스를 작성하는 데 Alpha AXP 시스템을 활용했습니다. 프로그래머 입장에서는 어떤 함수의 모든 호출자를 불과 몇 초 만에 파악하거나 디버그 추적 창에 나타난 함수나 대화 상자의 소스 코드를 찾아내는 것이 얼마나 편리하던지요.
그러나 곧 Alpha AXP는 Windows 소스 코드의 인덱스를 작성하는 간단한 임무에서도 x86급 시스템에게 밀리기 시작했습니다. 훨씬 저렴했고 빨랐으며 더 많은 하드 디스크 공간과 메모리를 제공했기 때문입니다. 이런 까닭으로 제 시스템 역시 잊혀진 동족들과 운명을 같이 했던 것입니다. Alpha AXP에 대한 지원 종료는 이 시스템의 종말을 고하는 듯했습니다. 그러나 이들이 영광스러운 빛을 발하며 차세대 서비스 영역에서 마지막으로 진가를 발휘할 기회가 주어졌습니다.
64비트 Windows 프로젝트가 이미 진행 중이었고 64비트 프로세서 프로젝트는 검토 단계였던 시절, 사실상 물리적으로 존재하는 시스템은 Alpha AXP뿐이었습니다. Intel Itanium은 아직 개발 단계에 있어 시뮬레이터에서만 실행되던 중이었고, AMD64 아키텍처는 아직 구상되지도 않던 때였습니다. 따라서 처음에 64비트 Windows는 Alpha AXP에서 개발되었습니다.
Compaq이 Alpha AXP에서 더 이상 Windows를 지원하지 않겠다고 밝히자, 32비트 Windows 2000 개발 및 테스트용으로 사용되던 Alpha AXP 시스템 모두는 용도 변경되어 64비트 운영 체제를 위한 테스트 시스템 자격으로 비밀스러운 임무를 수행하기 시작했습니다. 물론 Alpha AXP용 64비트 운영 체제는 결코 출시되지 않았습니다. Alpha AXP는 단지 개념 증명(proof-of-concept) 플랫폼이었을 뿐입니다.
Alpha AXP 시스템은 그 역할을 훌륭하게 해냈습니다. 64비트 Windows 팀은 Itanium 시뮬레이터가 아니라 실제 하드웨어에서 이 운영 체제를 실행할 수 있었습니다. 물론 속도는 정말 느렸을 것입니다. Alpha AXP가 최종적인 대상 하드웨어는 아니었으나 큰 도움이 되었습니다. 그리고 Itanium CPU가 위용을 드러내자 Alpha AXP에게 주어졌던 역할은 사라졌고 다시 한번 먼지 쌓인 벽장 속으로 퇴장했던 것입니다.
Microsoft 기록 보관소에서 일하는 친구들이 제 충실한 옛 친구인 Alpha AXP를 먼지투성이 벽장에서 불러내어 이 시스템 덕분에 등장할 수 있었던 제품 중 하나와 함께 이 기념 사진을 찍었습니다. 바로 64비트 Microsoft Windows Server® 2003과 함께. 물론 쌓여 있는 이 먼지는 진짜입니다.

Raymond Chen의 웹 사이트, The Old New Thing과 같은 이름의 저서(Addison-Wesley, 2007)에서는 Windows의 역사와 Win32 프로그래밍을 다루고 있습니다. 물론 그는 먼지 쌓인 벽장 속에 갇히는 걸 원치 않을 사람입니다.