소개

성능은 일종의 기능입니다. 성능은 장래 환경에 맞게 설계해야 하며, 그렇지 않으면 나중에 응용 프로그램을 다시 작성해야 하는 일이 생길 수 있습니다. 즉, 'Active Server Pages(ASP) 응용 프로그램의 성능을 최적화하려면 어떤 전략이 좋지?'와 같은 의문이 발생하게 됩니다.

이 기사에서는 ASP 응용 프로그램과 Visual Basic® Scripting Edition(VBScript)을 최적화하는데 도움이 되는 팁을 제공하며 수많은 위험과 곤란한 문제에 대해서도 논의합니다. 이 기사에 나열된 제안 사항들은 http://www.microsoft.com 및 그외 다른 사이트에서 테스트를 거쳤으며 올바르게 작동합니다. 이 기사에서는 VBScript 및/또는 JScript, ASP 응용 프로그램, ASP 세션, 기타 ASP 고유 개체(요청, 응답 및 서버) 등을 포함하여 ASP 개발에 대한 기본 사항들을 이해하고 있다고 가정합니다.

ASP 코드 자체 이외의 다른 요소들에 의해 ASP 성능이 달라지는 경우가 간혹 있습니다. 이 기사에서 미처 다루지 못한 사항들에 대해서는 뒷부분의 성능 관련 리소스를 참조하십시오. 뒷부분에 나열된 링크에서는 ActiveX® Data Objects(ADO), Component Object Model(COM), 데이터베이스 및 Internet Information Server(IIS) 구성 등을 포함하여 ASP와 비 ASP 항목에 대해 설명합니다. 이러한 링크들은 Microsoft가 즐겨 찾는 링크들이므로 반드시 참조하시기 바랍니다.

팁 1: 자주 사용되는 데이터는 웹 서버에 캐시하십시오

일반적인 ASP 페이지는 백엔드 데이터 저장소에 있는 데이터를 검색한 후 그 결과를 HTML(Hypertext Markup Language) 형식으로 표시합니다. 데이터베이스 속도에 상관없이, 메모리에 있는 데이터를 검색하는 속도는 백엔드 데이터 저장소에 있는 데이터를 검색하는 속도보다 훨씬 빠릅니다. 또한 로컬 하드 디스크에 있는 데이터를 읽는 속도도 데이터베이스에 있는 데이터를 검색하는 속도보다 빠른 것이 보통입니다. 따라서 데이터를 웹 서버의 메모리나 디스크에 캐시하면 일반적으로 성능이 향상됩니다.

캐싱은 전형적으로 속도 향상을 위해 공간을 희생시키는 작업입니다. 캐시 기능을 올바르게 사용하면 성능이 놀랄 만큼 향상되는 것을 볼 수 있습니다. 효과적인 캐시를 위해서는 자주 사용되는 데이터이면서 다시 연산하기에는 부담이 큰 데이터만 캐시에 보관해야 합니다. 사용 빈도가 낮은 데이터로 캐시를 가득 채우면 메모리가 낭비되는 결과를 낳게 됩니다.

자주 변경되지 않는 데이터는 시간이 지나더라도 데이터베이스에 동기화할 필요가 없으므로 캐시하는 것이 좋습니다. 콤보 상자 목록, 참조 테이블, DHTML 스크랩, XML(Extensible Markup Language) 문자열, 메뉴 항목과 데이터 원본 이름(DSN), 인터넷 프로토콜(IP) 주소 및 웹 경로를 포함하는 사이트 구성 변수 등은 캐시하는 것이 좋습니다. 데이터 자체를 캐시하는 대신에 데이터에 대한 표현을 캐시할 수도 있다는 점에 주목하십시오. 전체 제품 카탈로그와 같이 ASP 페이지가 자주 변경되고 캐시하기에 부담이 큰 경우에는 요청이 발생할 때마다 해당 ASP 페이지를 다시 표시하는 것이 아니라 미리 HTML을 생성하는 방법을 고려해 보십시오.

데이터는 어디에 캐시되어야 하며 캐싱 전략에는 어떠한 것들이 있습니까? 데이터는 간혹 웹 서버의 메모리 또는 디스크에 캐시됩니다. 다음 두 가지 팁에서는 이러한 옵션들에 대해 설명합니다.

팁 2: 자주 사용되는 데이터는 응용 프로그램이나 세션 개체에 캐시하십시오

ASP 응용 프로그램 및 세션 개체는 데이터를 메모리에 캐시하는 편리한 컨테이너를 제공합니다. 데이터는 응용 프로그램과 세션 개체에 모두 지정될 수 있으며 이렇게 지정된 데이터는 새로운 HTTP 호출이 발생할 때까지 메모리에 그대로 남아 있습니다. 세션 데이터는 각 사용자별로 저장되지만 응용 프로그램 데이터는 모든 사용자들 사이에서 공유됩니다.

데이터는 응용 프로그램이나 세션에 언제 로드됩니까? 데이터는 간혹 응용 프로그램이나 세션이 시작될 때 로드됩니다. 응용 프로그램이나 세션을 시작하면서 데이터를 로드하려면 적당한 코드를 Application_OnStart() 또는 Session_OnStart()에 각각 추가하십시오. 이러한 함수들은 Global.asa에 들어 있으며, 그렇지 않다면 이러한 함수들을 직접 추가할 수 있습니다. 또한 처음 데이터를 필요로 할 때 해당 데이터를 로드할 수도 있습니다. 이렇게 하려면 데이터가 있는지 검사하여 데이터가 없으면 데이터를 로드하는 일부 코드를 ASP 페이지에 추가하거나 재사용 가능한 스크립트 함수를 만드십시오. 다음은 지연 평가(Lazy Evaluation)라는 고전적인 성능 기술에 대한 예로, 필요할 때만 이를 사용하십시오.

<%
Function GetEmploymentStatusList
Dim d
d = Application(?EmploymentStatusList?)
If d = ??Then
' FetchEmploymentStatusList function (not shown)
' fetches data from DB, returns an Array
d = FetchEmploymentStatusList()
Application(?EmploymentStatusList?)= d
End If
GetEmploymentStatusList = d
End Function
%>


각각의 필요한 데이터에 대해 이와 유사한 함수를 작성할 수 있습니다.

데이터는 어떤 형식으로 저장됩니까? 모든 스크립트 변수는 변형이기 때문에, 모든 변형 유형이 저장 가능합니다. 예를 들어, 문자열, 정수 또는 배열을 저장할 수 있습니다. 간혹 ADO 레코드 집합의 내용을 이러한 변형 유형들 중 하나로 저장할 수 있습니다. ADO 레코드 집합의 데이터를 꺼내기 위해 데이터를 VBScript 변수에 한 번에 하나의 필드씩 수동으로 복사할 수 있습니다. ADO 레코드 집합 지속성 함수인 GeTRows(), GetSTRing() 또는 Save()(ADO 2.5) 중 하나를 사용하면 복사가 더 빠르고 편리해집니다. 이 기사에서는 자세한 세부 정보는 제공하지 않습니다. 다음은 GeTRows()를 사용하여 레코드 집합 데이터 배열을 반환하는 함수의 예입니다.

' Get Recordset, return as an Array
Function FetchEmploymentStatusList
Dim rs
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GeTRows() ?Return data as an Array
rs.Close
Set rs = Nothing
End Function


배열이 아닌, 목록에 대한 HTML을 캐시하도록 위 예제를 변경할 수도 있습니다. 다음은 그에 대한 간단한 예입니다.

' Get Recordset, return as HTML Option list
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
s = ?<select name=??EmploymentStatus??>?& vbCrLf
Set fldName = rs.Fields(?StatusName?)' ADO Field Binding
Do Until rs.EOF
' Next line violates Don't Do STRing Concats,
' but it's OK because we are building a cache
s = s & ? <option>?& fldName & ?</option>?& vbCrLf
rs.MoveNext
Loop
s = s & ?</select>?& vbCrLf
rs.Close
Set rs = Nothing ' See Release Early
FetchEmploymentStatusList = s ' Return data as a STRing
End Function


올바른 조건 하에서는 ADO 레코드 집합 자체를 응용 프로그램이나 세션 범위에 캐시할 수 있습니다. 이 때 다음 두 가지를 고려해야 합니다.

• ADO는 빈 스레드로 표시되어야 합니다.
• 연결이 끊긴 레코드 집합을 사용해야 합니다.

이 두 가지 요구 사항이 충족된다고 보증할 수 없으면 ADO 레코드 집합을 캐시하지 마십시오. 아래의 팁 4(비 Agile 구성 요소는 응용 프로그램이나 세션 개체에 캐시하지 마십시오)와 팁 5(데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마십시오)에서는 COM 개체를 응용 프로그램이나 세션 범위에 저장할 때 발생할 수 있는 위험에 대해 설명합니다.

데이터를 응용 프로그램이나 세션 범위에 저장하면, 프로그램을 통해 변경되거나 세션이 만료되거나 웹 응용 프로그램이 다시 시작될 때까지 데이터가 그대로 남아 있습니다. 데이터를 업데이트해야 할 경우에는 어떻게 할까요? 응용 프로그램 데이터의 업데이트를 강제로 수행하도록 지정하려면 데이터를 업데이트하는 관리자 액세스 전용 ASP 페이지로 호출할 수 있습니다. 또한 함수를 사용하여 정기적으로 데이터를 자동으로 새로 고치는 방법도 사용할 수 있습니다. 다음 예에서는 캐시된 데이터와 함께 시간 스탬프를 저장하고 일정 기간이 경과한 후 데이터를 새로 고칩니다.

<%
' error handing not shown...
Const UPDATE_INTERVAL = 300 ' Refresh interval, in seconds

' Function to return the employment status list
Function GetEmploymentStatusList
UpdateEmploymentStatus
GetEmploymentStatusList = Application(?EmploymentStatusList?)
End Function

' Periodically update the cached data
Sub UpdateEmploymentStatusList
Dim d, sTRLastUpdate
sTRLastUpdate = Application(?LastUpdate?)
If (sTRLastUpdate = ??)Or _
(UPDATE_INTERVAL < DateDiff(?s?, sTRLastUpdate, Now)) Then

' Note: two or more calls might get in here.This is okay and will simply
' result in a few unnecessary fetches (there is a workaround for this)

' FetchEmploymentStatusList function (not shown)
' fetches data from DB, returns an Array
d = FetchEmploymentStatusList()

' Update the Application object.Use Application.Lock()
' to ensure consistent data
Application.Lock
Application(?EmploymentStatusList?) = Events
Application(?LastUpdate?) = CSTR(Now)
Application.Unlock
End If
End Sub


다른 예를 보려면 World's Fastest ListBox with Application Data를 참조하십시오.

세션 또는 응용 프로그램 개체에 큰 배열을 캐싱하는 것은 좋지 않습니다. 스크립트 언어의 기능(Semantics)을 사용하려면 배열 요소에 액세스하기 전에 전체 배열을 임시로 복사해야 합니다. 예를 들어, 100,000개의 요소를 가지고 있으며 미국 우편 번호를 지방 기상청으로 매핑하는 문자열 배열을 응용 프로그램 개체에 캐시하는 경우, ASP는 그 중 하나의 문자열을 추출하기 전에 먼저 100,000개의 모든 기상청을 임시 배열에 복사합니다. 이 경우, 사용자 정의 메서드를 통해 사용자 정의 구성 요소를 작성하여 기상청을 저장하는 것이 보다 나은 방법입니다. 그렇지 않으면 딕셔너리 구성 요소들 중 하나를 사용하십시오.

주의를 상기시키는 의미에서 한 가지 더 언급하자면, 배열은 메모리 내에서 서로 인접해 있는 키 데이터 쌍에 대한 빠른 조회 및 저장 성능을 제공한다는 점을 고려해야 합니다. 딕셔너리 인덱싱 속도는 배열 인덱싱 속도보다 느립니다. 자신의 환경에 맞게 최적의 성능을 제공하는 데이터 구조를 선택해야 합니다.

팁 3: 데이터 및 HTML은 웹 서버 디스크에 캐시하십시오

간혹 데이터가 너무 많아서 메모리에 캐시할 수 없는 경우가 생길 수도 있습니다. "데이터가 너무 많다"는 의미는 상황에 따라, 즉 사용할 메모리의 양과 캐시할 항목의 수 및 그 검색 빈도에 따라 다를 수 있습니다. 메모리에 캐시할 데이터가 너무 많은 경우에는 데이터를 텍스트 또는 XML 파일 형식으로 웹 서버의 하드 디스크에 캐시하는 방법을 고려해 보십시오. 디스크 캐시 및 메모리 캐시를 결합하여 사이트에 맞는 최적의 데이터 캐싱 전략을 세울 수 있습니다.

단일 ASP 페이지의 성능을 평가할 때, 디스크에 있는 데이터를 검색하는 속도가 항상 데이터베이스에 있는 데이터를 검색하는 속도보다 빠른 것은 아니라는 점에 주의하십시오. 하지만 캐싱을 수행하면 데이터베이스와 네트워크에 걸리는 로드가 줄어듭니다. 로드가 큰 경우, 캐싱을 수행하면 전체 처리량을 크게 개선할 수 있습니다. 다중 테이블 조인 또는 복잡한 저장 프로시저 등과 같이 부담이 큰 쿼리의 결과를 캐시하거나 대규모 결과 집합을 캐시하는 경우에는 캐싱이 매우 효과적입니다. 여느 때와 마찬가지로 여러 가지 가능성을 테스트해 보십시오.

ASP 및 COM은 디스크 기반 캐싱 구성표를 작성하는 다양한 도구를 제공합니다. ADO 레코드 집합인 Save() 및 Open() 함수는 레코드 집합을 디스크에 저장하고 디스크에 있는 레코드 집합을 로드합니다. 이러한 메서드를 사용하면 앞부분의 응용 프로그램 데이터 캐싱 팁에 있는 코드 예제를 다시 작성함으로써 Save()를 응용 프로그램 개체로 기록하는 코드용 파일로 대체할 수 있습니다.

다음은 파일에 사용되는 몇 가지 다른 구성 요소들입니다.

• Scripting.FileSystemObject를 사용하면 파일을 작성하거나 읽거나 기록할 수 있습니다.
• Internet Explorer와 함께 제공되는 Microsoft® XML 파서인 MSXML은 XML 문서의 저장 및 로딩을 지원합니다.
• MSN에서 사용되는 샘플인 LookupTable 개체는 디스크로부터 간단한 목록을 로드하는데 유용합니다.

끝으로, 데이터 자체가 아니라 디스크 상의 데이터에 대한 표현을 캐시하는 것도 고려해 보십시오. 미리 렌더링된 HTML은 .htm 또는 .asp 파일 형식으로 디스크에 저장될 수 있으며 하이퍼링크를 통해 해당 파일들을 직접 가리킬 수 있습니다. Xbuilder 또는 Microsoft® SQL Server™ 인터넷 게시 기능 등과 같은 상용 도구를 사용하여 HTML 생성 프로세스를 자동화할 수 있으며, 그 대신 HTML 내용 일부를 .asp 파일에 포함시킬 수도 있습니다. 또한 FileSystemObject를 사용하여 디스크에 있는 HTML 파일을 읽거나 초기 렌더링 과정에서 XML을 사용하는 것 역시 가능합니다.

팁 4: 비 Agile 구성 요소는 응용 프로그램이나 세션 개체에 캐시하지 마십시오

데이터를 응용 프로그램 또는 세션 개체에 캐시하는 것은 좋은 방법이지만, COM 개체를 응용 프로그램 또는 세션 개체에 캐시하면 곤란한 문제들이 유발될 수 있습니다. 간혹 자주 사용되는 COM 개체를 응용 프로그램 또는 세션 개체에 캐시해야 하는 경우가 발생합니다. 불행하게도, Visual Basic 6.0 이하에서 작성된 개체를 포함한 많은 수의 COM 개체들의 경우 응용 프로그램 또는 세션 개체에 저장하려고 하면 심각한 병목 현상이 생길 수 있습니다.

특히, 비 agile 구성 요소인 경우에는 세션 또는 응용 프로그램 개체에 캐시할 때 성능 병목 현상이 발생하게 됩니다. agile 구성 요소는 FTM(Free-Threaded Marshaler)을 집계하는 ThreadingModel=Both로 표시된 구성 요소이거나 ThreadingModel=NeuTRal로 표시된 구성 요소입니다. NeuTRal 모델은 Windows® 2000 및 COM+의 새로운 모델입니다. 다음은 비 agile 구성 요소입니다.

• FTM을 집계하지 않는 빈 스레드 구성 요소
• 공동(Apartment) 스레드 구성 요소
• 단일 스레드 구성 요소

중립 스레드가 아닌 한, Microsoft TRansaction Server(MTS)/COM+ 라이브러리 및 서버 패키지/응용 프로그램 등과 같은 구성된 구성 요소들은 비 agile입니다. 공동(Apartment) 스레드 구성 요소와 기타 비 agile 구성 요소들은 페이지 범위에서 가장 잘 작동합니다. 즉, 단일 ASP 페이지에서 만들어지고 제거됩니다.

IIS 4.0의 경우 ThreadingModel=Both로 표시된 구성 요소는 agile로 간주되지만, IIS 5.0에서는 그렇지 않습니다. 이러한 구성 요소들은 Both로 표시되어야 하며 FTM도 집계해야 합니다. agility 기사에서는 Active Template Library로 작성된 C++ 구성 요소들이 FTM을 집계하는 방법에 대해 설명합니다. 구성 요소가 인터페이스 포인터를 캐시하는 경우에는 이러한 포인터는 그 자체가 agile이어야 하거나 COM GIT(Global Interface Table)에 저장되어야 합니다. FTM을 집계하도록 Both 스레드 구성 요소를 다시 컴파일할 수 없는 경우에는 그 구성 요소를 ThreadingModel=NeuTRal로 표시할 수 있습니다. 또한 IIS가 agility 검사를 수행하지 않기를 원해서 비 agile 구성 요소를 응용 프로그램이나 세션 범위에 저장하려고 할 경우에는 메타베이스에서 AspTRackThreadingModel을 TRue로 설정할 수 있습니다. AspTRackThreadingModel을 변경하면 안됩니다.

IIS 5.0에서는 Server.CreateObject를 사용해서 만든 비 agile 구성 요소를 응용 프로그램 개체에 저장하려고 하면 오류 메시지가 나타납니다. Global.asa에서 <object runat=server scope=application ...>을 사용하면 이러한 문제를 해결할 수 있지만, 이 방법은 아래에 설명된 바와 같이 마샬링 및 순차화를 유발하므로 사용하지 않는 것이 좋습니다.

비 agile 구성 요소를 캐시하면 어떻게 될까요? 세션 개체에 캐시된 비 agile 구성 요소는 ASP 작업자 스레드에 대한 세션을 "잠급니다". ASP는 요청을 처리하는 작업자 스레드의 풀을 유지 관리합니다. 일반적으로 새 요청은 최초 사용 가능한 작업자 스레드에 의해 처리됩니다. 스레드에 대한 세션이 잠기는 경우, 해당 요청은 자신이 연결된 스레드를 사용할 수 있을 때까지 기다려야 합니다. 다음은 이를 이해하는데 도움이 될만한 유사한 사례입니다. 즉, 슈퍼마켓에 가서 몇 가지 식료품을 고른 후 3번 계산대에서 그 대금을 지불합니다. 그런 다음부터는 그 슈퍼마켓에서 산 식료품의 대금은 항상 3번 계산대에서 지불해야 합니다. 다른 계산대에서 기다리는 손님이 적거나 심지어 없는 경우에도 마찬가지입니다.

비 agile 구성 요소들을 응용 프로그램 범위에 저장하면 성능에 최악의 영향을 미치게 됩니다. ASP는 별도의 스레드를 만들어서 비 agile 응용 프로그램 범위 구성 요소들을 실행해야 합니다. 결과적으로, 모든 호출이 이 스레드에 대해 마셜링되어야 하거나 모든 호출이 순차화되어야 합니다. 마셜링은 매개 변수들이 메모리 공유 영역에 저장되어야 함을 의미합니다. 즉, 부담이 큰 컨텍스트 스위치가 별도의 스레드에 대해 만들어지고 구성 요소의 메서드가 실행되며, 그 결과가 공유 영역으로 마셜링되고 다른 부담이 큰 컨텍스트 스위치는 제어 권한을 원래의 스레드로 되돌려야 합니다. 순차화는 모드 메서드가 한 번에 하나씩 실행되어야 함을 의미합니다. 따라서 서로 다른 두 개의 ASP 작업자 스레드가 공유 구성 요소에서 메서드를 동시에 실행할 수 없으므로 동시성이 사라지게 되는데, 특히 다중 프로세서 컴퓨터에서 이러한 현상이 더 두드러집니다. 더군다나, 모든 비 agile 응용 프로그램으로 범위가 한정된 구성 요소들이 한 개의 스레드("Host STA")를 공유하므로 순차화의 영향이 더욱 커지게 됩니다.

이해가 잘 안되면 아래의 몇 가지 일반 규칙들을 살펴보십시오. Visual Basic 6.0 이전 버전을 사용해서 개체를 작성하고 있는 경우에는 그 개체를 응용 프로그램 또는 세션 개체에 캐시하면 안됩니다. 개체의 스레드 모델을 모른다면 그 개체를 캐시하면 안됩니다. 비 agile 개체는 캐시하지 말고 각각의 페이지에서 만든 후 릴리스하십시오. 개체는 마셜링 또는 순차화가 발생하지 않도록 ASP 작업자 스레드에서 직접 실행해야 합니다. IIS 상자에서 COM 개체를 실행하고 있는 경우와 그 COM 개체를 시작하거나 종료하는데 많은 시간이 걸리지 않는 경우에는 적절한 성능을 얻을 수 있습니다. 단, 단일 스레드 개체는 이와 동일한 방식으로 사용되지 않아야 한다는 점에 주의하십시오. VB는 단일 스레드 개체를 만들 수 있으므로 조심하십시오! Microsoft Excel 스프레드시트 등과 같은 단일 스레드 개체를 이와 동일한 방식으로 사용해야 하는 경우에는 많은 처리량을 기대할 수 없습니다.

ADO 레코드 집합은 ADO가 빈 스레드로 표시되어 있을 때 안전하게 캐시할 수 있습니다. ADO를 빈 스레드로 표시하려면 보통 \\Program Files\Common\System\ADO에 있는 Makfre15.bat 파일을 사용하면 됩니다.

경고 Microsoft Access를 데이터베이스로 사용하고 있는 경우에는 ADO를 빈 스레드로 표시하지 마십시오. 또한 ADO 레코드 집합에 대한 연결이 끊어져 있어야 합니다. 일반적으로, 자기 자신만의 고유한 구성을 관리하는 고객들에게 웹 응용 프로그램을 판매하는 독립 소프트웨어 공급업체[ISV]처럼 사이트에서 ADO 구성을 제어할 수 없는 경우에는 레코드 집합을 캐시하지 않는 것이 좋습니다.

또한 딕셔너리 구성 요소는 agile 개체입니다. LookupTable은 데이터 파일로부터 데이터를 로드하며 구성 정보 뿐만 아니라 콤보 상자 데이터에서도 유용하게 사용됩니다. Duwamish Books에 있는 PageCache 개체는 Caprock Dictionary와 마찬가지로 딕셔너리 기능(semantics)을 제공합니다. 이러한 개체들과 그 파생물들은 효과적인 캐싱 전략의 토대로 사용될 수 있습니다. Scripting.Dictionary 개체는 비 agile이므로 응용 프로그램이나 세션 범위에 저장될 수 없다는 점에 주의하십시오.

팁 5: 데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마십시오

보통 ADO 연결은 캐시하지 않는 것이 좋습니다. 하나의 연결 개체를 응용 프로그램 개체에 저장하여 모든 페이지에서 이를 사용하는 경우에는 모든 페이지가 이 연결을 사용하기 위해 경쟁하게 됩니다. 연결 개체가 ASP 세션 개체에 저장되어 있으면 모든 사용자들에 대해 데이터베이스 연결이 설정됩니다. 따라서 연결 풀링을 통해 얻을 수 있는 장점들이 줄어들며 웹 서버와 데이터베이스 모두에서 불필요하게 많은 로드가 발생하게 됩니다.

데이터베이스 연결을 캐시하지 말고 ADO를 사용하는 모든 ASP 페이지에서 ADO 개체를 만들거나 제거하십시오. 이렇게 하면 IIS가 자체적으로 데이터베이스 연결 풀링을 보유하게 되므로 효과적입니다. 더 정확히 말해서, IIS가 OLEDB 및 ODBC 연결 풀링을 자동으로 사용하게 되므로 각 페이지에서 연결을 효과적으로 만들거나 제거할 수 있게 됩니다.

연결된 레코드 집합은 데이터베이스 연결에 대한 참조를 저장하므로, 연결된 레코드 집합을 응용 프로그램 또는 세션 개체에 저장하면 안됩니다. 단, 연결이 끊긴 레코드 집합은 데이터 연결에 대한 참조를 저장하지 않으므로 안전하게 캐시할 수 있습니다. 레코드 집합의 연결을 끊으려면 다음과 같은 두 단계를 수행하십시오.

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' step 1

' Populate the recordset with data
rs.Open sTRQuery, sTRProv

' Now disconnect the recordset from the data provider and data source
rs.ActiveConnection = Nothing ' step 2


연결 풀링에 대한 자세한 내용은 ADO 및 SQL Server 설명서에 나와 있습니다.

팁 6: 세션 개체를 올바르게 사용하십시오

지금까지 데이터를 응용 프로그램 및 세션 개체에 캐시함으로써 얻을 수 있는 장점들에 대해 얘기했으며, 이제는 세션 개체를 사용하지 말라는 제안을 하려고 합니다. 세션 개체는 아래에 설명된 바와 같이 사용량이 많은 사이트에서 사용할 때 발생하는 수많은 곤란한 문제들을 가지고 있습니다. 여기서 사용량이 많은 사이트는 일반적으로 1초 당 사용되는 페이지 수가 수 백개에 달하거나 동시에 접속하는 사용자 수가 수 천명에 달하는 사이트를 의미합니다. 수평으로 확장해야 하는 사이트, 즉 여러 대의 서버를 사용하여 로드를 분산시키거나 내결함성을 구현하는 사이트에서는 이 팁이 더욱 중요합니다. 인트라넷 사이트와 같이 소규모 사이트인 경우에는 세션 사용으로 인한 편리함이 크기 때문에 오버헤드가 생기는 단점을 보상할 수 있습니다.

재생을 위해 ASP는 웹 서버에 접속하는 모든 사용자에 대해 세션을 자동으로 만듭니다. 각각의 세션은 10KB 정도의 메모리 오버헤드를 가지며 모든 요청을 약간씩 느려지게 만드는데, 이 때 오버헤드는 종류에 상관없이 데이터가 세션에 저장될 때마다 항상 맨 위에 놓여집니다. 세션은 구성 가능한 초과 시간이 경과할 때까지 계속 사용되며 그 초과 시간은 보통 20분입니다.

세션에 관련된 가장 큰 문제는 성능이 아닌 확장성에 관련된 문제입니다. 세션은 웹 서버를 스팬하지 않습니다. 즉, 일단 세션이 한 대의 서버에서 만들어진 이후에는 그 데이터가 그대로 보존됩니다. 따라서 웹 그룹에서 세션을 사용하고 있다면, 사용자의 세션이 있는 서버로 향하도록 각 사용자의 요청을 처리하기 위한 전략을 세워야 합니다. 이러한 전략을 세우는 작업은 웹 서버에 대한 사용자 "Sticking"이라고 합니다. "Sticky Session"이라는 용어는 바로 여기에서 유래된 것입니다. 세션은 디스크에 영구적으로 저장되지 않기 때문에, "sticky 상태의" 사용자는 웹 서버의 작동이 중단되면 자신의 세션 상태를 잃게 됩니다.

Sticky Session을 구현하기 위한 전략에는 하드웨어 및 소프트웨어 솔루션이 포함됩니다. Windows 2000 Advanced Server의 네트워크 로드 균형 조정 및 Cisco사의 Local Director 등과 같은 솔루션을 사용하면 약간의 확장만으로도 Sticky Session을 구현할 수 있습니다. 이러한 솔루션들은 완벽하지가 않습니다. 이 시점에서는 자기만의 소프트웨어 솔루션은 사용하지 않는 것이 좋습니다. Microsoft에서는 ISAPI 필터와 URL 맹글링(mangling) 등을 사용했습니다.

응용 프로그램 개체는 서버를 스팬하지 않기 때문에, 웹 그룹에 걸쳐 응용 프로그램 데이터를 공유하고 업데이트해야 할 경우에는 백엔드 데이터베이스를 사용해야 합니다. 단, 읽기 전용 응용 프로그램 데이터는 웹 그룹에서 그대로 사용할 수 있습니다.

업무상 중요한 대부분의 사이트에서는 가동 시간을 늘리려는 이유가 아닌 다른 이유, 즉 장애 조치 및 서버 유지 관리를 처리하기 위해 두 대 이상의 웹 서버를 구축하려고 할 것입니다. 따라서 업무상 중요한 응용 프로그램을 설계할 때, "Sticky Session"을 구현하거나 그렇지 못하면 세션 사용을 피해야 합니다. 또한 사용자 상태를 개별 웹 서버에 저장하는 다른 상태 관리 기술들도 사용해야 합니다.

세션을 사용하고 있지 않으면 세션 기능을 반드시 해제해야 합니다. 인터넷 서비스 관리자를 통해 응용 프로그램의 세션 기능을 해제할 수 있습니다. 자세한 내용은 ISM 설명서를 참조하십시오. 세션을 사용하는 경우에는 다양한 방법으로 세션이 성능에 미치는 영향을 최소화할 수 있습니다.

도움말 화면, 방문자 영역 등과 같이 세션에 필요하지 않은 내용은 세션 기능이 해제되어 있는 별도의 ASP 응용 프로그램으로 옮길 수 있습니다. 각 페이지 단위로 해당 페이지에서 세션 개체를 필요로 하지 않는 ASP에게 힌트를 제공할 수 있습니다. 다음과 같은 지시어를 ASP 페이지의 맨 위에 넣으십시오.

<% @EnableSessionState=False %>


위와 같은 지시어를 사용해야 하는 중요한 이유는 세션으로 인해 프레임셋 관련 문제가 생길 수 있기 때문입니다. ASP를 사용하면 세션으로부터 발생하는 요청이 한 번에 하나씩만 실행되도록 만들 수 있습니다. 따라서 브라우저가 한 명의 사용자에 대해 여러 개의 페이지를 요청하더라도 한 번에 한 개의 ASP 요청만 세션을 사용하게 되므로, 세션 개체에 액세스할 때 다중 스레드 문제가 유발되지 않습니다. 결과적으로 볼 때, 프레임셋에 있는 모든 페이지는 동시에 표시되는 것이 아니라 순차적으로 한 번에 하나씩 표시됩니다. 모든 프레임이 표시될 때까지 사용자가 장시간 기다려야 할 경우도 있습니다. 참고: 특정 프레임셋 페이지가 세션에 대한 신뢰를 가지고 있지 않은 경우에는 @EnableSessionState=False 지시어를 사용하여 반드시 ASP에게 알려야 합니다.

세션 개체를 사용하는 대신, 세션 상태 관리용으로 제공되는 많은 수의 옵션들을 사용할 수도 있습니다. 상태의 크기가 4KB 미만으로 작은 경우에는 일반적으로 쿠키, QuerySTRing 변수 및 숨겨진 서식 변수를 사용하는 것이 좋습니다. 쇼핑 카트와 같이 데이터 크기가 큰 경우에는 백엔드 데이터베이스를 사용하는 것이 가장 좋습니다. 웹 서버 그룹에는 상태 관리 기술에 대한 많은 정보들이 들어 있습니다. 자세한 내용은 세션 상태 설명서를 참조하십시오.

팁 7: 코드를 COM 개체에 캡슐화하십시오

VBScript 또는 JScript가 매우 많은 경우, 간혹 그 코드를 컴파일된 COM 개체로 옮기면 성능을 개선할 수 있습니다. 컴파일된 코드의 실행 속도는 보통, 해석된 코드의 실행 속도보다 빠릅니다. 컴파일된 COM 개체는 스크립트에 사용된 "후기 바인딩"이 아니라, 보다 효과적으로 COM 개체 메서드를 불러오는 "초기 바인딩"을 통해 다른 COM 개체에 액세스할 수 있습니다.

성능 측면 뿐만 아니라, 코드를 COM 개체에 캡슐화하면 다음과 같은 장점도 얻을 수 있습니다.

• COM 개체는 비즈니스 로직으로부터 표현 로직을 분리하는 성능이 매우 우수합니다.
• COM 개체는 코드 재사용을 가능케 합니다.
• 대부분의 개발자들은 VB, C++ 또는 Visual J++로 작성된 코드가 ASP로 작성된 코드보다 디버깅하기 쉽다는 점을 알고 있습니다.

COM 개체는 초기 개발 기간이 길고 다양한 프로그래밍 기술을 필요로 한다는 단점들을 가지고 있습니다. 작은 양의 ASP를 캡슐화하면 성능상 얻을 수 있는 장점보다는 단점이 많을 수 있다는 점에 주의하십시오. 일반적으로 이러한 상황은 작은 양의 ASP 코드가 COM 개체에 포함될 때 발생합니다. 이러한 경우에는 컴파일된 코드를 통해 얻을 수 있는 장점보다 COM 개체를 만들어 불러오는데 걸리는 오버헤드로 인한 단점이 더 많습니다. 어떤 방식으로 ASP 스크립트와 COM 개체 코드를 결합할 때 최적의 성능을 얻을 수 있는지를 판별하려면 여러 번의 시행 착오를 거쳐야 합니다. Microsoft는 Windows NT® 4.0/IIS 4.0에 비해 Windows 2000/IIS 5.0의 스크립트와 ADO 성능을 다양하게 개선했습니다. 따라서 ASP 코드에 비해 컴파일된 코드를 통해 얻을 수 있는 성능상의 장점들은 IIS 5.0의 도입과 함께 줄어들었습니다.

COM 개체를 ASP에 사용함으로써 발생하는 장단점에 대한 자세한 내용은 ASP Component Guidelines and Programming DisTRibuted Applications with COM and Microsoft Visual Basic 6.0을 참조하십시오. COM 구성 요소를 구축하는 경우에는 반드시 스트레스 테스트를 수행해야 합니다. 실제로 모든 ASP 응용 프로그램들은 당연히 스트레스 테스트를 거쳐야 합니다.

팁 8: 최신의 리소스를 얻어 신속하게 릴리스하십시오

일반적으로 최신의 리소스를 얻어 신속하게 릴리스하는 것이 좋습니다. 이러한 팁은 파일 핸들 및 기타 리소스 뿐만 아니라 COM 개체에도 적용됩니다.

ADO 연결 및 레코드 집합이 이러한 최적화에 가장 적합합니다. 레코드 집합을 사용하는 경우, 그 데이터를 사용하여 테이블을 채운 후 페이지 끝에 도달할 때까지 기다리지 말고 즉시 릴리스하십시오. VBScript 변수는 Nothing으로 설정하는 것이 가장 좋습니다. 레코드 집합이 범위를 벗어나지 않게 하십시오. 또한 관련된 모든 명령 또는 연결 개체를 릴리스하십시오. = Nothing으로 설정하기 전에 레코드 집합 또는 연결에 대해 Close()를 호출하는 것을 잊지 마십시오. 그러면 데이터베이스에서 리소스를 저글링하는 기간이 단축되며 데이터베이스 연결이 최대한 빠르게 연결 풀에 릴리스됩니다.

팁 9: 독립 프로세스 실행을 통해 성능과 안정성을 적절히 안배하십시오

ASP와 MTS/COM+에는 모두 성능과 안정성이 적절히 안배되도록 조정할 수 있는 구성 옵션들이 있습니다. 응용 프로그램을 만들고 구축할 때 그 장단점을 이해하고 있어야 합니다.

ASP 옵션

세 가지 방법들 중 하나로 실행되도록 ASP 응용 프로그램을 구성할 수 있습니다. IIS 5.0에서는 이러한 옵션들에 대해 설명할 목적으로 "격리 수준(isolation level)"이라는 용어를 도입했습니다. 격리 수준 값에는 낮음, 보통 및 높음의 세 가지가 있습니다.

• 낮음 격리. 모든 IIS 버전에서 지원되며 속도가 가장 빠릅니다. 낮음 격리는 Inetinfo.exe로 ASP를 실행하는데, 이는 기본 IIS 프로세스입니다. ASP 응용 프로그램의 작동이 중단되면 IIS의 작동도 중단됩니다. IIS 4.0의 경우, IIS를 다시 시작하려면 웹 마스터가 InetMon 등과 같은 도구들을 사용하여 사이트를 모니터하고 서버 오류가 발생한 경우 배치 파일을 실행하여 서버를 다시 시작해야 합니다. IIS 5.0에서는 오류가 발생한 서버를 자동으로 다시 시작하는 안정적인 재시작 기능을 도입했습니다.
• 보통 격리. IIS 5.0에서 새로 도입된 이러한 보통 격리 수준은 ASP가 IIS 프로세스와는 별도로 실행되므로 독립 프로세스라고도 불립니다. 보통 격리에서 보통으로 실행되도록 구성된 모든 ASP 응용 프로그램은 하나의 프로세스 공간을 공유합니다. 따라서 한 개의 상자에서 여러 개의 독립 프로세스 ASP 응용 프로그램을 실행하는데 필요한 프로세스의 수가 줄어듭니다. 보통은 IIS 5.0의 기본 격리 수준입니다.
• 높음 격리. IIS 4.0 및 IIS 5.0에서 지원되는 높음 격리도 역시 독립 프로세스입니다. ASP 작동이 중단되더라도 웹 서버 작동은 중단되지 않습니다. 다음 번 ASP 요청이 발생하면 ASP 응용 프로그램이 자동으로 다시 시작됩니다. 높음 격리를 사용하면, 높음으로 실행되도록 구성된 각각의 ASP 응용 프로그램은 자체 프로세스 공간에서 실행됩니다. 따라서 ASP 응용 프로그램들이 상호 보호됩니다. 하지만 각각의 ASP 응용 프로그램마다 별도의 프로세스를 필요로 한다는 단점이 있습니다. 이러한 단점 때문에, 하나의 컴퓨터에 많은 수의 응용 프로그램들을 호스트해야 할 경우에는 엄청난 오버헤드가 생길 수 있습니다.

최상의 옵션은 무엇입니까? IIS 4.0에는 독립 프로세스를 실행하기에 좋지 않은 성능상의 단점들이 있습니다. IIS 5.0에서는 ASP 응용 프로그램을 독립 프로세스로 실행하는데 드는 비용을 최소화하기 위한 많은 작업들이 수행되었습니다. 실제로 대부분의 테스트를 거친 결과, IIS 5.0의 ASP 독립 프로세스 응용 프로그램이 IIS 4.0의 종속 프로세스 응용 프로그램보다 빠르게 실행되었습니다. 그럼에도 불구하고 종속 프로세스(낮음 격리 수준)는 두 플랫폼 모두에서 여전히 최상의 성능을 제공합니다. 그러나 상대적으로 방문 횟수가 적거나 최대 처리량이 낮은 경우에는 낮음 격리 수준을 통해 얻을 수 있는 장점들이 그다지 많지 않습니다. 따라서 각각의 웹 서버에서 1초에 수 백개 또는 수 천개의 페이지를 필요로 할 때까지는 낮음 격리 수준으로 설정할 필요성을 느끼지 못할 것입니다. 또한 다양한 구성들을 사용하여 테스트를 수행하고 그 장단점을 판별해야 합니다.

참고 ASP 응용 프로그램을 독립 프로세스(보통 또는 높음 격리)로 실행하면 ASP 응용 프로그램은 Windows NT4의 경우 MTS에서 실행되고 Windows의 경우 COM+에서 실행됩니다. 즉, Windows NT4의 경우 Mtx.exe로 실행되고 Windows 2000의 경우 DllHost.exe로 실행됩니다. 작업 관리자를 살펴보면 이러한 프로세스의 실행 여부를 알 수 있습니다. 또한 IIS가 MTS 패키지 또는 COM+ 응용 프로그램을 ASP 독립 프로세스 응용 프로그램용으로 구성하는 방법도 알 수 있습니다.

COM 옵션

ASP 옵션과 완전히 유사하지는 않지만, COM 구성 요소도 세 가지 구성 옵션들을 가지고 있습니다. COM 구성 요소는 "구성되지 않은" 구성 요소이거나 라이브러리 응용 프로그램으로서 구성된 구성 요소이거나 서버 응용 프로그램으로서 구성된 구성 요소입니다. 구성되지 않은 구성 요소는 COM+에 등록되지 않은 구성 요소를 의미합니다. 이러한 구성 요소는 호출자의 프로세스 공간에서 실행되므로 "종속 프로세스"입니다. 라이브러리 응용 프로그램도 종속 프로세스이지만 보안, 트랜잭션 및 컨텍스트 지원 등을 포함하여 COM+ 서비스의 장점을 활용합니다. 서버 응용 프로그램은 자체 프로세스 공간에서 실행되도록 구성됩니다.

라이브러리 응용 프로그램에 비해 구성되지 않은 구성 요소를 사용하여 얻을 수 있는 장점이 약간 더 많다는 사실을 알 수 있습니다. 또한 서버 응용 프로그램에 비해 라이브러리 응용 프로그램을 사용하여 얻을 수 있는 성능상의 장점이 훨씬 많다는 사실도 알 수 있습니다. 그 이유는 라이브러리 응용 프로그램이 ASP와 동일한 프로세스에서 실행되는 반면에 서버 응용 프로그램은 자체 프로세스에서 실행되기 때문입니다. 프로세스간 호출은 종속 프로세스 호출보다 더 부담이 큽니다. 또한 레코드 집합 등과 같은 데이터가 프로세스 사이에서 전달될 때에는 모든 데이터가 두 프로세스 사이에서 복사되어야 합니다.

주의! COM 서버 응용 프로그램을 사용할 때, ASP와 COM 사이에서 개체를 전달하는 경우에는 개체가 "값에 따른 마셜링" 또는 MBV를 구현해야 합니다. MBV를 구현하는 개체들은 하나의 프로세스에서 다른 프로세스로 자동 복사됩니다. 이러한 방식은 개체가 작성자의 프로세스에 그대로 남아 있으며 다른 프로세스가 개체를 사용하기 위해 작성 프로세스에 반복적으로 호출되는 방식보다 낫습니다. 연결이 끊긴 ADO 레코드 집합은 값에 따라 마셜링되지만, 연결된 레코드 집합은 그렇지 않습니다. Scripting.Dictionary는 MBV를 구현하지 않으며 프로세스 사이에서 전달되지 않습니다. 끝으로, VB 프로그래머는 MBV가 ByVal 매개 변수의 전달을 통해 구현되는 것이 아니라, 원래의 구성 요소 작성자에 의해 구현된다는 점에 주의해야 합니다.

수행할 사항

성능과 안정성이 적절히 조정된 구성을 설정하려면 다음과 같은 권장 사항들을 수행해야 합니다.

• IIS 4.0에서는 ASP의 낮음 격리 수준을 사용하고 MTS 서버 패키지를 사용하십시오.
• IIS 5.0에서는 ASP의 보통 격리 수준을 사용하고 COM+ 라이브러리 응용 프로그램을 사용하십시오.

이 권장 사항들은 매우 일반적인 지침들입니다. 기업 호스팅에서는 일반적으로 ASP가 보통 또는 높음 격리 수준에서 실행되는 반면에 단일 용도의 웹 서버는 낮음 격리 수준에서 실행될 수 있습니다. 그 장단점을 평가하여 어떤 구성이 자신의 환경에 맞는지를 스스로 판별하십시오.

팁 10: Option Explicit를 사용하십시오

.asp 파일에 있는 Option Explicit를 사용하십시오. .asp 파일의 맨 위에 있는 이 지시어는 사용할 변수를 모두 선언하도록 개발자에게 강요합니다. 응용 프로그램을 디버깅할 때 이 지시어를 사용하면 MyXMLSTRing= 대신에 MyXLMSTRing=가 발생하는 경우처럼 변수 이름의 입력 오타가 생기거나 원치 않는 변수가 만들어질 가능성을 봉쇄하기 때문에, 대부분의 프로그래머들은 이 지시어가 매우 유용하다는 것을 알고 있습니다.

보다 중요한 점은 선언된 변수가 선언되지 않은 변수보다 빠르게 실행된다는 것입니다. 스크립팅 실행 시간은 선언되지 않은 변수가 사용될 때마다 자동으로 변수 이름별로 그 선언되지 않은 변수를 참조합니다. 반면, 선언된 변수는 컴파일 시간 또는 실행 시간에서 서수를 할당받습니다. 결과적으로 볼 때, 선언된 변수는 이 서수에서 참조합니다. Option Explicit를 사용하면 변수를 선언하도록 강제 지정하므로, 모든 변수가 선언되어 빠른 액세스를 가능하게 합니다.

팁 11: 로컬 변수를 하위 루틴 및 함수에 사용하십시오

로컬 변수는 하위 루틴 및 함수 내에서 선언된 변수입니다. 함수 또는 하위 루틴 내에서 선언된 로컬 변수는 글로벌 변수보다 빠르게 액세스됩니다. 또한 로컬 변수를 사용하면 코드가 보다 명확해지므로, 가능하면 항상 로컬 변수를 사용하십시오.

팁 12: 자주 사용되는 데이터를 스크립트 변수에 복사하십시오

ASP에 있는 COM 개체에 액세스할 때는 자주 사용되는 데이터를 스크립트 변수에 복사해야 합니다. 이렇게 복사하면 스크립트 변수에 액세스하는 것에 비해 상대적으로 부담이 큰 COM 메서드 호출의 수가 줄어듭니다. 컬렉션 및 딕셔너리 개체에 액세스할 때에도 이 기술을 사용하면 부담이 큰 조회의 수를 줄일 수 있습니다.

일반적으로 두 번 이상 개체 데이터에 액세스할 경우에는 해당 데이터를 스크립트 변수에 복사하십시오. 이러한 최적화의 주요 대상은 Request 변수(Form 및 QuerySTRing 변수)입니다. 예를 들어, QuerySTRing 변수로 호출되는 UserID가 반복적으로 분배되는 사이트에서 이 UserID가 특정 페이지에 12회 참조된다고 가정해 보십시오. Request(?UserID?)를 12회 호출하지 말고 ASP 페이지의 맨 위에 있는 변수에 UserID를 할당하십시오. 그러면 페이지 전체에 걸쳐 그 변수가 사용됩니다. 따라서 11회의 COM 메서드 호출이 줄어듭니다.

실제로 COM 속성 또는 메서드에 대한 액세스는 매우 부담이 큰 작업입니다. 다음은 자주 사용되는 구문 코드를 보여주는 예입니다.

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...


이 코드는 다음과 같이 실행됩니다.

1. Foo 변수가 글로벌 개체로 확인됩니다.
2. bar 변수가 Foo의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 발생합니다.
3. blah 변수가 Foo.bar의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 다시 발생합니다.
4. qaz 변수가 foo.bar.blah의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 다시 발생합니다.
5. Foo.bar.blah.quaz(1)를 불러옵니다. COM 메서드 호출이 다시 발생합니다. 여기까지 이해가 되었습니까?
6. 1-3 단계를 다시 수행하여 baz를 확인합니다. 시스템은 qaz 호출이 개체 모델을 변경했는지 여부를 알지 못하므로, 1-3 단계를 다시 수행하여 baz를 확인해야 합니다.
7. baz를 Foo.bar.blah의 구성원으로 확인합니다. 속성을 설정합니다.
8. 1-3 단계를 다시 수행하여 zaq를 확인합니다.
9. 1-3 단계를 다시 수행하여 abc를 확인합니다.

이처럼, 이 코드는 매우 비효율적이며 작성에 많은 시간이 걸립니다. VBScript에서 이 코드를 가장 빠르게 작성하는 방법은 다음과 같습니다.

Set myobj = Foo.bar.blah ' do the resolution of blah ONCE
Myobj.baz = myobj.qaz(1)
If Myobj.zaq = Myobj.abc Then '...


VBScript 5.0 이상을 사용하고 있는 경우에는 With 명령문을 사용하여 이 코드를 작성할 수 있습니다.

With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With


이 팁은 VB 프로그래밍에도 적용된다는 점을 기억하십시오.

팁 13: 배열 크기 재정의를 피하십시오

배열의 크기 재정의(Redim)는 가능한 한 피하십시오. 실제 메모리 크기에 의해 성능이 제한되는 컴퓨터의 경우에는 최악의 경우에 대비하여 초기 배열 크기를 설정하거나, 그 크기를 최적으로 설정하고 필요할 때마다 배열 크기를 재정의하십시오. 단, 필요하지 않은 경우에도 수 MB나 되는 메모리를 할당해야 한다는 것은 아닙니다.

다음 코드는 Dim 및 Redim 사용 예입니다.

<%
Dim MyArray()
Redim MyArray(2)
MyArray(0) = ?hello?
MyArray(1) = ?good-bye?
MyArray(2) = ?farewell?
...
' some other code where you end up needing more space happens, then ...
Redim Preserve MyArray(5)
MyArray(3) = ?more stuff?
MyArray(4) = ?even more stuff?
MyArray(5) = ?yet more stuff?
%>


배열의 크기 재정의(Redim)를 수행하여 그 크기를 늘리는 것보다는 초기에 올바른 크기까지 배열의 크기 정의(Dim)를 수행(위 코드의 경우 5)하는 것이 좋습니다. 모든 요소들을 끝까지 사용하지 않으면 약간의 메모리 낭비가 있게 되지만 속도가 빨라지는 이점이 있습니다.

팁 14: 응답 버퍼링을 사용하십시오

"응답 버퍼링" 기능을 설정함으로써 전체 출력 페이지 만큼을 버퍼링할 수 있습니다. 이렇게 하면 브라우저에 기록되는 양이 최소화되어 전체 성능이 향상됩니다. 기록할 때마다 IIS 및 회선을 통해 보내지는 데이터 크기로 인한 오버헤드가 아주 크기 때문에, 기록 횟수가 줄어들수록 성능이 향상됩니다. TCP/IP는 느리게 시작되며 Nagling 알고리즘을 통해 네트워크 혼잡을 최소화하므로, 작은 블록을 여러 개 보낼 때보다 큰 데이터 블록을 한 개 보낼 때 더욱 효율적으로 작동합니다.

응답 버퍼링 기능을 설정하는 방법은 두 가지가 있습니다. 첫번째 방법은 인터넷 서비스 관리자를 사용하여 전체 응용 프로그램의 응답 버퍼링 기능을 설정하는 것입니다. 이는 권장되는 방법이며 기본적으로 IIS 4.0 및 IIS 5.0에서 새로 사용되는 ASP 응용 프로그램의 응답 버퍼링 기능을 설정합니다. 두번째 방법은 다음과 같은 코드 행을 ASP 페이지의 맨 위쪽에 넣음으로써 응답 버퍼링 기능을 페이지 단위로 설정하는 것입니다.

<% Response.Buffer = TRue %>


이 코드 행은 응답 데이터가 브라우저에 기록되기 이전에 미리 실행되어야 합니다. 즉, HTML이 ASP 스크립트에 나타나기 이전과 Response.Cookies 컬렉션을 사용하여 쿠키가 설정되기 이전에 미리 실행되어야 합니다. 일반적으로 전체 응용 프로그램에 대해 응답 버퍼링 기능을 설정하는 것이 좋습니다. 이렇게 하면 각 페이지마다 이 코드 행을 사용하지 않아도 됩니다.

Response.Flush

응답 버퍼링에 관한 일반적인 불만 사항들 중 하나는 전체 페이지가 생성된 후에야 비로소 그 내용을 볼 수 있기 때문에 전체 응답 시간이 향상되었음에도 불구하고 사용자들이 ASP 페이지의 응답이 다소 느리다고 느낀다는 점입니다. 페이지를 장시간 실행하는 경우에는 Response.Buffer = False를 설정함으로써 응답 버퍼링 기능을 해제할 수 있습니다. 그러나 Response.Flush 메서드를 활용하는 것이 더 낫습니다. 이 메서드를 사용하면 ASP가 브라우저에 표시한 모든 HTML이 플러시됩니다. 예를 들어, 1,000개의 행으로 구성된 테이블에서 100개의 행을 표시한 후 ASP는 Response.Flush를 호출하여 표시된 결과를 브라우저에 강제 지정할 수 있습니다. 이렇게 하면 나머지 행이 표시되기 전에 사용자는 처음 표시된 100개의 행을 볼 수 있습니다. 이 기술을 사용하면 데이터를 브라우저에 점차적으로 표시함과 동시에 응답 버퍼링 기능도 사용할 수 있는 최상의 환경을 만들 수 있습니다.

1,000개의 행으로 구성된 테이블을 사용하는 위의 예에서 종료 </table> 태그가 나타날 때까지는 대부분의 브라우저에서 테이블 표시를 시작할 수 없다는 점에 주의하십시오. 대상 브라우저가 지원되는지 확인하십시오. 이 문제를 해결하려면 행 수가 적은 여러 개의 테이블로 나누고 각각의 작은 테이블 다음에서 Response.Flush를 호출하십시오. 최신 버전의 Internet Explorer에서는 전체 내용을 다운로드하기 전에 테이블을 표시하며, 테이블 열 너비가 지정되어 있으면 Internet Explorer가 모든 셀 내용의 너비를 측정함으로써 열 너비를 계산하지 않기 때문에 훨씬 빠르게 표시됩니다.

응답 버퍼링에 관한 또 다른 일반적인 불만 사항은 큰 페이지를 생성할 때 매우 많은 서버 메모리가 사용될 수 있다는 점입니다. 큰 페이지 생성을 조정하는 것이 아니라, Response.Flush를 적절히 사용하면 이 문제 역시 해결할 수 있습니다.

팁 15: 인라인 스크립트 및 Response.Write 명령문을 일괄 처리하십시오

VBScript 구문 <% = 표현식 %>을 사용하면 "표현식" 값이 ASP 출력 스트림에 기록됩니다. 응답 버퍼링 기능이 해제되어 있는 경우, 이러한 각각의 명령문을 사용하면 데이터가 네트워크를 통해 여러 개의 작은 패킷 형태로 브라우저에 기록됩니다. 이 기록은 아주 느리게 진행됩니다. 또한 작은 양의 스크립트와 HTML을 보내면 스크립트 엔진과 HTML간 전환이 발생하여 결과적으로 성능이 저하됩니다. 이 경우에는 여러 개의 인접한 인라인 표현식들을 한 번의 Response.Write 호출로 바꾸십시오. 예를 들어, 아래의 예에서는 응답 스트림 쓰기 동작이 각각의 행에 있는 각 필드에 대해 한 번 발생하며 VBScript와 HTML간 전환이 각각의 행에 대해 여러 번 발생합니다.

<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<TR>
<% For Each fld in rs.Fields %>
<TD><% = fld.Value %></TD>
<% Next
</TR>
<% rs.MoveNext
Wend %>
</table>


보다 효율적인 아래의 코드에서는 응답 스트림 쓰기 동작이 각각의 행에 대해 한 번 발생합니다. 모든 코드는 한 개의 VBScript 블록 안에 포함됩니다.

<table>
<%
For each fld in rs.Fields
Response.Write (?<th>?& fld.Name & ?</th>?& vbCrLf)
Next
While Not rs.EOF
Response.Write (?<TR>?)
For Each fld in rs.Fields %>
Response.Write(?<TD>?& fld.Value & ?</TD>?& vbCrLf)
Next
Response.Write ?</TR>?
Wend
%>
</table>


이 팁은 응답 버퍼링 기능이 해제되어 있을 때 더욱 효율적입니다. 응답 버퍼링 기능을 설정한 후 Response.Write를 일괄 처리하여 성능이 향상되는지를 확인해 보는 것이 가장 좋습니다.

위의 예에서 테이블 본문을 구성하는 중첩된 루프(While Not rs.EOF...)는 제대로 구성된 GetSTRing 호출로 바꿀 수 있습니다.

팁 16: 실행 시간이 긴 페이지를 만들 때 Response.IsClientConnected를 사용하십시오

참을성이 없는 사용자라면 자신의 요청을 실행하기도 전에 미리 ASP 페이지를 포기해 버릴 수도 있습니다. 이러한 사용자들이 새로 고침을 누르거나 서버의 다른 페이지로 이동하면 새 요청이 ASP 요청 대기열의 맨 끝부분에 넣어지고 연결이 끊긴 요청이 대기열의 중간 부분에 넣어집니다. 이러한 상황은 서버에 과도한 로드가 걸려 있을 때 간혹 발생하는데, 이 경우 요청 대기열이 길어져서 더 많은 응답 시간이 소요되므로 문제가 더욱 악화됩니다. 사용자의 연결이 끊어지면 ASP 페이지를 실행할 지점이 없어집니다. 특히, 속도가 느리고 그 내용이 많은 ASP 페이지인 경우에는 더욱 그렇습니다. Response.IsClientConnected 속성을 사용하면 이러한 상황이 발생했는지를 검사할 수 있습니다. False가 반환되면 Response.End를 호출하여 나머지 페이지를 포기해야 합니다. 실제로 IIS 5.0에서는 이러한 절차를 코드화했습니다. 즉, 새 요청을 실행하려고 할 때마다 ASP는 해당 요청이 대기열에 있었던 기간을 검사합니다. 그 기간이 3초를 초과하는 경우, ASP는 클라이언트가 아직도 연결되어 있는지를 검사하여 클라이언트 연결이 끊어져 있으면 그 즉시 해당 요청을 종료합니다. 메타베이스에 있는 AspQueueConnectionTestTime 설정을 사용하면 이러한 시간 초과 값(3초)을 변경할 수 있습니다.

매우 긴 실행 시간을 필요로 하는 페이지가 있는 경우에는 간혹 Response.IsClientConnected를 검사해야 합니다. 응답 버퍼링 기능이 설정되어 있는 경우에는 가끔 Response.Flush를 실행하여 무슨 일이 진행되고 있는지를 사용자에게 알리는 것이 좋습니다.

참고 IIS 4.0에서는 Response.Write를 먼저 실행하지 않으면 Response.IsClientConnected가 제대로 작동하지 않습니다. 또한 버퍼링 기능이 설정되어 있으면 Response.Flush도 실행해야 합니다. IIS 5.0에서는 이들을 실행하지 않더라도 Response.IsClientConnected가 제대로 작동합니다. Response.IsClientConnected를 실행하는데 어느 정도의 대가가 따를 수도 있으므로, Response.IsClientConnected는 500밀리초 이상이 소요되는 작업을 수행하기 전에만 사용해야 합니다. 1초에 수 십개의 페이지를 계속 처리해야 한다는 점에서 보면 500밀리초는 매우 긴 시간입니다. 일반적으로 20개 또는 50개의 테이블 행에 도달할 때마다 테이블 행을 표시하는 경우처럼, 간격이 짧은 루프가 반복될 때 이 속성을 호출하면 안됩니다.

팁 17: <OBJECT> 태그를 사용하여 개체를 초기화하십시오

모든 코드 경로, 특히 서버 또는 응용 프로그램 범위 개체에 사용되지 않는 개체를 참조해야 할 경우에는 Server.CreateObject 메서드를 사용하지 말고 Global.asa에서 <object runat=server id=objname> 태그를 사용하여 선언하십시오. Server.CreateObject는 즉시 개체를 만들기 때문에, 나중에 그 개체를 사용하지 않을 경우에는 리소스를 낭비하는 결과를 초래합니다. <object id=objname> 태그는 개체 이름(objname)을 선언하지만, 그 개체 이름은 해당 메서드나 속성들 중 하나가 처음으로 사용된 후 비로소 만들어집니다.

이것은 지연 평가(Lazy Evaluation)의 다른 예입니다.

팁 18: TypeLib 선언을 ADO 및 그 밖의 다른 구성 요소에 사용하십시오

ADO를 사용할 때, 개발자가 ADO의 다양한 상수들에 액세스할 목적으로 adovbs.txt를 포함시키는 경우가 간혹 있습니다. 이 파일은 상수가 사용될 모든 페이지에 포함되어야 합니다. 이 상수 파일의 크기는 매우 크기 때문에, 모든 ASP 페이지의 컴파일 시간 및 스크립트 크기에 엄청난 오버헤드가 추가됩니다.

IIS 5.0에는 구성 요소의 유형 라이브러리에 대한 바인드 기능이 새로 추가되었습니다. 이 기능을 사용하면 일단 유형 라이브러리를 참조한 이후에 모든 ASP 페이지에서 이를 다시 사용할 수 있습니다. 페이지마다 상수 파일을 컴파일할 필요는 없으므로, 구성 요소 개발자는 ASP에서 사용할 VBScript #include 파일을 만들 필요가 없습니다.

ADO TypeLib에 액세스하려면 다음 명령문들 중 하나를 Global.asa에 넣으십시오.

<!-- METADATA NAME=?Microsoft ActiveX Data Objects 2.5 Library?
TYPE=?TypeLib?UUID=?{00000205-0000-0010-8000-00AA006D2EA4}? -->


또는

<!-- METADATA TYPE=?TypeLib?
FILE=?C:\Program Files\Common Files\system\ado\msado15.dll? -->


팁 19: 브라우저의 유효성 검사 기능을 활용하십시오

최근에 개발되는 브라우저에서는 XML, DHTML, Java 애플릿 및 원격 데이터 서비스 등과 같은 기능들에 대한 고급 지원 기능을 제공합니다. 가능하면 항상 이러한 기능들을 사용하십시오. 이러한 모든 기술들은 데이터 캐싱 뿐만 아니라 클라이언트측 유효성 검사를 수행하므로 웹 서버에 대한 왕복 이동 시간을 줄여줍니다. 스마트 브라우저를 실행하고 있는 경우, 그 브라우저에서는 약간의 유효성 검사를 수행할 수 있습니다. 예를 들어, POST를 실행하기 전에 신용 카드에 유효한 검사값이 들어 있는지를 검사합니다. 다시 말해서, 가능하면 항상 이러한 기능들을 사용하십시오. 클라이언트 대 서버간 왕복 이동 시간이 줄어들면 서버가 액세스하는 백엔드 리소스 뿐만 아니라 웹 서버에 걸리는 스트레스와 네트워크 트래픽도 줄어듭니다. 단, 브라우저에서 수신하는 초기 페이지의 크기는 더 커집니다. 또한 사용자가 새 페이지를 그다지 자주 페치할 필요가 없으므로 성능이 훨씬 나아집니다. 그렇지만 서버측 유효성 검사를 수행하지 않아도 되는 것은 아닙니다. 서버측 유효성 검사는 항상 수행해야 합니다. 서버측 유효성 검사를 수행하면 브라우저가 클라이언트측 유효성 검사 루틴을 실행하지 않더라도 클라이언트로부터 해킹과 같은 나쁜 데이터가 들어오는 것이 방지됩니다.

"모든 브라우저에서 실행되는" HTML을 작성할 때 보통 이러한 기능이 사용됩니다. 이는 간혹 성능상의 장점을 제공하는 자주 사용되는 브라우저 기능을 이용하려는 개발자의 의욕을 꺾는 결과를 초래합니다. 따라서 "사용 가능한" 브라우저 종류를 고려해야 하는 고성능 사이트에서 유용한 전략은 가장 자주 사용되는 브라우저에 맞게 페이지를 최적화하는 것입니다. 브라우저 기능 구성 요소를 사용하는 ASP에서는 브라우저 기능들을 간편하게 검색할 수 있습니다. Microsoft FrontPage와 같은 도구를 사용하면 원하는 HTML 버전과 브라우저에서 작동하는 코드를 설계하는데 도움이 됩니다. 자세한 내용은 When is Better Worse? Weighing the Technology TRade-Offs를 참조하십시오.

팁 20: 루프 형식의 문자열 연결을 피하십시오

대부분의 개발자들은 다음과 같은 루프 형식의 문자열을 사용합니다.

s = ?<table>?& vbCrLf
For Each fld in rs.Fields
s = s & ? <th>?& fld.Name & ?</th> ?
Next

While Not rs.EOF
s = s & vbCrLf & ? <TR>?
For Each fld in rs.Fields
s = s & ? <TD>?& fld.Value & ?</TD> ?
Next
s = s & ? </TR>?
rs.MoveNext
Wend

s = s & vbCrLf & ?</table>?& vbCrLf
Response.Write s


이러한 접근 방법에는 몇 가지 문제가 있습니다. 첫번째 문제는 반복적인 문자열 연결로 인해 제곱 배의 시간이 소요된다는 점입니다. 공식적인 수치는 아니지만, 이러한 루프를 실행하는데 소요되는 시간은 레코드 수와 필드 수를 곱한 값의 제곱에 비례합니다. 이는 아래의 간단한 예를 살펴보면 더욱 분명해집니다.

s = ??
For i = Asc(?A?) to Asc(?Z?)
s = s & Chr(i)
Next


첫번째 반복에서 한 개의 문자로 구성된 문자열(?A?)이 얻어집니다. 두번째 반복에서 VBScript는 문자열을 다시 할당하고 두 개의 문자(?AB?)를 s에 복사해야 합니다. 세번째 반복에서 VBScript는 다시 s를 할당하고 세 개의 문자를 s에 복사해야 합니다. N번째(26번째) 반복에서 VBScript는 s를 다시 할당하고 N개의 문자를 s에 복사해야 합니다. 따라서 그 복사 합계는 1+2+3+...+N, 즉 N*(N+1)/2입니다.

위의 레코드 집합 예에서 레코드 수가 100개이고 필드 수가 5개인 경우에는 100*5 = 500회의 내부 루프가 실행되어야 하며, 모든 복사 및 재할당에 소요되는 시간은 500*500 = 250,000입니다. 이러한 수치는 보통 크기의 레코드 집합인 경우에는 아주 큰 값입니다.

이 예에서 문자열 연결을 Response.Write()로 바꾸거나 인라인 스크립트(<% = fld.Value %>)로 바꾸면 코드 성능이 향상될 수 있습니다. 응답 버퍼링 기능이 설정되어 있으면 Response.Write가 데이터를 응답 버퍼의 끝에 추가하므로 그 속도가 더욱 빨라집니다. 또한 재할당 동작이 발생하지 않으므로 아주 효율적입니다.

ADO 레코드 집합을 HTML 테이블로 변환해야 하는 특별한 경우에는 GeTRows 또는 GetSTRing을 사용해 보십시오.

문자열을 JScript에 연결하는 경우에는 반드시 += operator; that is, use s += ?some sTRing?, not s = s + ?some sTRing?을 사용하십시오.

팁 21: 브라우저 및 프록시 캐싱을 사용하십시오

기본적으로 ASP는 브라우저 및 프록시 캐싱 기능을 사용하지 않습니다. 그 이유는 ASP 페이지의 경우 잠재적으로 시간이 중요시되는 정보를 갖는 동적 페이지의 속성을 가지고 있기 때문입니다. 그러나 볼 때마다 새로 고칠 필요가 없는 페이지에서는 브라우저 및 프록시 캐싱 기능을 사용해야 합니다. 이렇게 하면 브라우저 및 프록시에서 일정 기간 동안 "캐시된" 페이지 복사본을 사용할 수 있으며, 그 기간은 사용자가 조절할 수 있습니다. 또한 서버에 걸리는 로드가 크게 줄어들며 성능이 훨씬 나아집니다.

어떤 종류의 동적 페이지를 캐시할 수 있습니까? 다음은 캐시 가능한 페이지의 예입니다.

• 날씨가 5분마다 업데이트되는 날씨 페이지
• 신문 기사나 보도 자료를 나열하고 하루에 두 번 업데이트되는 홈 페이지
• 뮤추얼 펀드 실적을 나열하고 기초 통계 자료가 서너 시간마다 업데이트되는 페이지

브라우저 또는 프록시 캐싱 기능을 사용하면 웹 서버에 기록되는 방문 횟수가 줄어든다는 점에 주의하십시오. 모든 페이지 화면이나 게시 알림 횟수를 정확하게 측정하기 위해 브라우저 및 프록시 캐싱 기능을 해제해야 할 수도 있습니다.

브라우저 캐싱 기능은 웹 서버로부터 브라우저로 보내지는 HTTP의 "Expires" 헤더에서 제어됩니다. ASP에서는 두 가지 간단한 메커니즘을 통해 이 헤더를 전송합니다. 첫번째 메커니즘은 향후 일정 시간(분 단위)이 경과한 후 페이지를 만료하도록 Response.Expires 속성을 설정하는 것입니다. 다음은 10분이 경과한 후 내용을 만료하도록 브라우저에게 지시하는 예입니다.

<% Response.Expires = 10 %>


Response.Expires를 음수나 0으로 설정하면 캐싱 기능이 사용되지 않습니다. 서버 시계와 브라우저 사이의 불일치 문제를 해결하려면 -1000 등과 같이 하루보다 약간 적은 시간을 의미하는 음수를 사용해야 합니다. 두번째 메커니즘은 Response.ExpiresAbsolute를 사용하여 해당 내용을 만료할 시간을 설정하는 것입니다.

<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>


Response 개체를 사용하여 만료 날짜를 설정하는 대신에 <META> 태그를 HTML에 사용할 수도 있습니다. 이 태그는 일반적으로 HTML 파일의 <HEAD> 섹션에 놓입니다. 아래의 지시어는 일부 브라우저에서는 인식되지만 프록시에서는 인식되지 않습니다.

<META HTTP-EQUIV=?Expires?VALUE=?May 31,2001 13:30:15?>


끝으로, Response.CacheConTRol 속성을 사용하여 HTTP 프록시에서 해당 내용을 캐시할 수 있는지 여부를 나타낼 수 있습니다. 이 속성을 "Public"으로 설정하면 프록시는 해당 내용을 캐시합니다.

<% Response.CacheConTRol = ?Public? %>


기본적으로 이 속성은 "Private"로 설정됩니다. 사용자 고유의 데이터를 보여주는 페이지인 경우에는 프록시가 다른 사용자의 페이지를 제공할 수도 있으므로 프록시 캐싱 기능을 사용하면 안됩니다.

팁 22: 가능하면 Response.Redirect가 아닌 Server.TRansfer를 사용하십시오

Response.Redirect는 다른 페이지를 요청하도록 브라우저에게 지시합니다. 이 함수는 사용자를 로그온이나 오류 페이지로 리디렉션하는데 간혹 사용됩니다. 리디렉션은 새 페이지 요청을 강제로 수행하기 때문에, 결과적으로 볼 때 브라우저가 웹 서버에 두 번 왕복 이동해야 하며 웹 서버가 추가 요청을 처리해야 합니다. IIS 5.0에서는 동일한 서버에 있는 다른 ASP 페이지에게 실행을 전송하는 Server.TRansfer 함수를 새로 도입했습니다. 이 함수를 사용하면 브라우저 대 웹 서버 왕복 이동이 추가로 발생하지 않기 때문에, 결과적으로 볼 때 사용자의 응답 시간이 빨라지며 전체 시스템 성능도 향상됩니다. 자세한 내용은 Server.TRansfer 및 Server.Execute에 대해 설명하는 New Directions in Redirection을 참조하십시오.

또한 IIS 5.0 및 ASP 3.0의 새 기능에 대한 자세한 목록은 Leveraging ASP in IIS 5.0을 참조하십시오.

팁 23: 디렉터리 URL에 후행 슬래시를 사용하십시오

여기에 관련된 팁은 디렉터리를 나타내는 후행 슬래시(/)를 URL에 사용해야 한다는 것입니다. 후행 슬래시가 생략된 경우, 브라우저는 서버에게 디렉터리를 요청합니다. 그런 다음 브라우저가 슬래시를 URL에 추가하여 두번째 요청을 보내면 서버가 해당 디렉터리의 기본 문서로 응답하거나, 기본 문서가 없어서 디렉터리 찾아보기가 사용된 경우 디렉터리 목록으로 응답합니다. 슬래시를 추가하면 불필요한 첫번째 왕복 이동 동작이 발생하지 않습니다. 사용자가 쉽게 읽을 수 있도록, 표시되는 이름에서 후행 슬래시를 생략할 수도 있습니다.

예를 들면, 다음과 같습니다.

<a href=?http://msdn.microsoft.com/workshop/? title=?MSDN Web
Workshop?>http://msdn.microsoft.com/workshop</a>


이 팁은 웹 사이트의 홈 페이지를 가리키는 URL에도 적용됩니다.<a href=?http://msdn.microsoft.com?>이 아닌 <a href=?http://msdn.microsoft.com/?>을 사용해 보십시오.

팁 24: 서버 변수 사용을 피하십시오

서버 변수에 액세스하면 웹 사이트가 서버에게 특수한 요청을 보내어 요청한 변수 뿐만 아니라 모든 서버 변수들을 모으게 됩니다. 이는 불필요한 파일들을 넣어둔 창고에 있는 폴더에서 특정 항목을 찾는 경우와 비슷한데, 여기서 한 개의 필요한 항목을 찾으려면 원하는 항목에 액세스하기 전에 먼저 창고에 들어가서 해당 폴더를 찾아야 합니다. 이러한 상황은 서버 변수를 요청할 때 발생하는 상황과 동일합니다. 방문 횟수(performance hit)는 맨 처음 서버 변수를 요청할 때 추가됩니다. 나중에 다른 서버 변수를 얻기 위해 보내지는 요청은 방문 횟수(performance hit)에 추가되지 않습니다.

Request("Data")와 같이 정식 Request 개체가 아닌 개체에 액세스하면 안됩니다. Request.Cookies, Request.Form, Request.QuerySTRing 또는 Request.ClientCertificate에 들어 있지 않은 항목에 대해서는 Request.ServerVariables에 대한 암시적 호출이 발생합니다. Request.ServerVariables 컬렉션 속도는 다른 컬렉션 속도보다 매우 느립니다.

팁 25: 최신 구성 요소로 업그레이드하십시오

시스템 구성 요소들은 자주 변경되므로 최신 구성 요소로 업그레이드해야 합니다. 가장 좋은 방법은 Windows 2000으로 업그레이드하고 IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 및 JScript 5.1로 업그레이드하는 것입니다. IIS 5.0 및 ADO 2.5는 다중 프로세스 컴퓨터에서 놀랄만한 성능을 제공합니다. Windows 2000에서는 ASP가 네 개 이상의 프로세서로 완벽하게 확장되지만, IIS 4.0에서는 ASP가 두 개 이상의 프로세서로 제대로 확장되지 않았습니다. 응용 프로그램에 사용된 스크립트 코드와 ADO가 많을수록 Windows 2000으로 업그레이드한 후 얻게 될 성능상의 장점이 많아집니다.

Windows 2000으로 업그레이드할 수 없는 경우에는 SQL Server, ADO, VBScript 및 JScript, MSXML, Internet Explorer, Windows NT 4 서비스 팩의 최신 릴리스로 업그레이드할 수 있습니다. 이렇게 하면 안정성이 향상되는 동시에 성능도 좋아집니다.

팁 26: 웹 서버를 조정하십시오

사이트 성능을 개선할 수 있는 다양한 IIS 조정 매개 변수들이 제공됩니다. 예를 들어, IIS 4.0에서 ASP ProcessorThreadMax 매개 변수(IIS 설명서 참조)의 값을 늘리면 성능이 크게 향상된다는 점이 밝혀졌습니다. 특히, 데이터베이스와 같은 백엔드 리소스나 스크린 스크래퍼와 같은 기타 미들웨어 제품에서 대기하는 경향이 있는 사이트에서는 더욱 그렇습니다. IIS 5.0에서 현재 알려진 것처럼 최적의 AspProcessorThreadMax 설정을 찾는 것보다는 ASP Thread Gating을 조정하는 것이 보다 효율적입니다.

이 기사의 뒷부분에 있는 IIS 조정 부분에 참고 자료가 나와 있습니다.

최적의 구성 설정은 다른 요소들보다는 응용 프로그램 코드, 응용 프로그램 코드를 통해 실행되는 하드웨어 및 클라이언트 작업 부하에 의해 결정됩니다. 최상의 설정을 찾는 유일한 방법은 성능 테스트를 수행하는 것입니다.

팁 27: 성능 테스트를 수행하십시오

앞에서 언급한 바와 같이, 성능은 일종의 기능입니다. 사이트 성능을 개선하려면 일단 성능 목표를 설정한 후 그 목표에 도달할 때까지 점차적으로 개선 작업을 수행하십시오. 성능 테스트를 프로젝트 마지막 단계로 미루지 마십시오. 프로젝트 마지막 단계에서 아키텍처 변경을 하기란 너무 늦기 때문에 고객을 실망시키는 경우가 종종 발생합니다. 성능 테스트는 일상적인 테스트의 일부로서 수행하십시오. 성능 테스트는 ASP 페이지나 COM 개체 등과 같은 개별 구성 요소에서 별도로 수행하거나 전체 사이트에 걸쳐 한꺼번에 수행할 수 있습니다.

대부분의 관리자들은 한 개의 브라우저에서 페이지를 요청함으로써 웹 사이트의 성능을 테스트합니다. 이렇게 테스트하면 사이트의 응답 성능은 제대로 파악할 수 있지만, 일정한 로드 하에서 사이트가 제대로 작동하는지는 파악할 수 없습니다.

일반적으로 성능을 정확하게 측정하려면 테스트 전용 환경이 필요합니다. 이러한 테스트 전용 환경에는 프로세서 속도, 프로세서 수, 메모리, 디스크, 네트워크 구성 등의 측면에서 프로덕션 하드웨어와 거의 유사한 기능을 갖는 하드웨어를 설치해야 합니다. 그런 다음에는 동시 사용자 수, 사용자의 요청 빈도, 사용자가 방문하는 페이지의 유형 등과 같은 클라이언트 작업 부하를 정의해야 합니다. 사이트로부터 실제 사용량 데이터를 얻을 수 없으면 적당한 값을 추측해야 합니다. 끝으로, 예상되는 클라이언트 작업 부하를 시뮬레이트할 수 있는 도구가 필요합니다. 이러한 도구들을 사용하면 "N 명의 동시 사용자가 있는 경우에는 몇 대의 서버가 필요한가요?"와 같은 질문에 답할 수 있으며 병목 현상을 찾아내서 최적화를 위해 이를 해결할 수 있습니다.

훌륭한 웹 스트레스 테스트 도구들 중 몇 가지가 이 기사의 뒷부분에 나와 있지만, Microsoft WAS(Web Application STRess) 도구 키트를 사용할 것을 권장합니다. WAS에서는 테스트 스크립트를 작성하여 웹 서버를 방문하는 사용자들을 수 백명 또는 수 천명까지 시뮬레이트할 수 있습니다. WAS는 초당 요청수, 응답 시간 배포, 오류 카운트 등을 포함하여 매우 많은 수의 통계를 보고합니다. WAS에는 다양한 클라이언트 인터페이스와 웹 기반 인터페이스가 포함되어 있으며, 웹 인터페이스를 사용하면 테스트를 원격으로 수행할 수 있습니다.

반드시 IIS 5.0 조정 가이드를 읽어보십시오.

The Domain Name Service (DNS) protocol searches for resources using a database distributed among different name servers.

The DNS message header structure is shown in the following illustration:

16	21						28	32 bits
ID	Q	Query	A	T	R	V	B	Rcode
Question count	Answer count
Authority count	Additional count
DNS message header structure

IDentification : 16-bit field used to correlate queries and responses.

: DNS 메세지의 순서 번호로서 Resolver에 의해 설정되고, DNS 서버는 동일한 번호를 사용하여 응답한다.

 

QR
1-bit field that identifies the message as a query or response.

 

Query
4-bit field that describes the type of message:

0	Standard query (name to address).
1	Inverse query (address to name).
2	Server status request.

A
Authoritative Answer. 1-bit field. When set to 1, identifies the response as one made by an authoritative name server.

 

T
Truncation. 1-bit field. When set to 1, indicates the message has been truncated.

R

1-bit field. Set to 1 by the resolve to request recursive service by the name server.

 

V
1-bit field. Signals the availability of recursive service by the name server.

B
3-bit field. Reserved for future use. Must be set to 0.

RCode
Response Code. 4-bit field that is set by the name server to identify the status of the query:

0	No error condition.
1	Unable to interpret query due to format error.
2	Unable to process due to server failure.
3	Name in query does not exist.
4	Type of query not supported.
5	Query refused.

Question count
16-bit field that defines the number of entries in the question section.

 

Answer count
16-bit field that defines the number of resource records in the answer section.

 

Authority count
16-bit field that defines the number of name server resource records in the authority section.

DNS Header Section (RFC 1035)

Der DNS Header ist die erste Section innerhalb einer DNS Message. Als einziger Teil innerhalb einer DNS Message hat der DNS Header eine fixe L?ge, die 12 Bytes betr?t.

Der DNS Header ist folgendermassen aufgebaut:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                the corresponding reply and can be used by the requester
                to match up replies to outstanding queries.

QR              A one bit field that specifies whether this message is a
                query (0), or a response (1).

OPCODE          A four bit field that specifies kind of query in this
                message.  This value is set by the originator of a query
                and copied into the response.  The values are:

                0               a standard query (QUERY)

                1               an inverse query (IQUERY)

                2               a server status request (STATUS)

                3-15            reserved for future use

AA              Authoritative Answer - this bit is valid in responses,
                and specifies that the responding name server is an
                authority for the domain name in question section.

                Note that the contents of the answer section may have
                multiple owner names because of aliases.  The AA bit
                corresponds to the name which matches the query name, or
                the first owner name in the answer section.

TC              TrunCation - specifies that this message was truncated
                due to length greater than that permitted on the
                transmission channel.

RD              Recursion Desired - this bit may be set in a query and
                is copied into the response.  If RD is set, it directs
                the name server to pursue the query recursively.
                Recursive query support is optional.

RA              Recursion Available - this be is set or cleared in a
                response, and denotes whether recursive query support is
                available in the name server.

Z               Reserved for future use.  Must be zero in all queries
                and responses.

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation:

                0               No error condition

                1               Format error - The name server was
                                unable to interpret the query.

                2               Server failure - The name server was
                                unable to process this query due to a
                                problem with the name server.

                3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.

                4               Not Implemented - The name server does
                                not support the requested kind of query.

                5               Refused - The name server refuses to
                                perform the specified operation for
                                policy reasons.  For example, a name
                                server may not wish to provide the
                                information to the particular requester,
                                or a name server may not wish to perform
                                a particular operation (e.g., zone
                                transfer) for particular data.

                6-15            Reserved for future use.

QDCOUNT         an unsigned 16 bit integer specifying the number of
                entries in the question section.

ANCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the answer section.

NSCOUNT         an unsigned 16 bit integer specifying the number of name
                server resource records in the authority records
                section.

ARCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the additional records section.

화이트페이퍼-The Web & Storage Area Networks
by Brocade Communications Systems, Incorporated(http://www.brocade.com)
	웹 기반의 서비스를 제공하는 업체에게는, 지금이 최고의 기회이자 최악의 상황이다. 최고의 기회인 이유는 고객들이 다른 어느 때보다도 서비스에 많은 투자를 하고 있기 때문이고 최악의 상황은 전통적인 아키텍처로는 고객의 요구를 충족시킬 수 없기 때문이다. 웹 인프라스트럭처 디자이너가 직면하고 있는 가장 중요한 문제는 급속도로 늘어나고 있는 사용자와 스토리지 용량의 증가에 어떻게 자사의 시스템을 대처해 가는가이다. 광 채널 스위치 패브릭에 기반을 둔 SAN은 효율적이고 비용 효과적인 서버 구축과 관리를 위한 강력한 프레임웍을 제공한다. 본고에서는 시스템 확장성과 연관되어 해결해야 할 여러 가지 문제점들을 분석하고 시스템 관리자가 이러한 문제들을 SAN 기술을 이용하여 뛰어난 관리, 효율성, 성능을 가진 웹 인프라스트럭처를 구축하는 방법에 관하여 다룰 것이다.
	Web Service Scaling Factors
	웹 서비스를 위한 용량 계획에는 다음과 같은 고려 사항들이 있다. 분당 히트 수 (사용자의 수 고려)분 당 히트 수는 사용자의 수를 알 수 있게 해 주기 때문에 한 사이트의 전반적인 용량의 척도가 된다. 이것은 서버의 수와 외부 대역폭(outbound bandwidth), 또한 제공되는 컨텐츠의 양과는 무관하다. URL을 제공하는데 필요한 평균 시간이 바로 중요한 척도이다. 사이트 운영자는 대개 이런 수치들을 조사하며 URL을 제공하는 시간이 길어질 경우 필요한 행동을 취해야 한다. 외부 대역폭 외부 대역폭 용량은 서버 군과 인터넷사이에서 발생하는 최초의 네트웍 홉(Hop)의 초당 비트 수이다. 일반적으로 네트웍 디자이너는 인터넷 기반의 서비스에서 사용자의 네트웍 연결의 수준을 제어할 수는 없다. 그러나, 최초의 홉은 모든 요구와 응답이 이 파이프를 통해서 발생하기 때문에 주어진 초당 히트 수를 제공하는데 가장 최초로 고려되는 사항이다. 파이프가 충분할수록, 주어진 시간에 이 파이프를 통하여 발생되는 요구와 응답도 많아지게 된다. 이 변수의 중요성은 인터넷 영역의 웹 호스팅 분야에서 더욱 두드러진다. Exodus, Level 3, Abovenet 등의 웹 호스팅 제공 업체가 인터넷의 매우 빠른 연결을 제공하고 있기 때문이다. 서버를 구입하여 직접 회사에 위치시키는 것은 인터넷 연결을 위한 고용량의 인터넷 전용선의 추가 구매를 필요로 한다. 일반적으로 말하자면, 서버를 IDC같은 웹 호스팅 업체에 두는 것이 주어진 인터넷 액세스율에 대해서는 보다 높은 비용 대비 효과를 지닌다. (이 서비스를 co-location이라고 부르기도 한다.) 이하에서 다시 다룰 것이지만, 위에서 언급한 것은 서버쪽에서 해결할 문제가 아니라 네트웍에서 해결되어야 하는 문제이기 때문에 외부 대역폭이나 사용자 네트웍은 웹 인프라스트럭처 디자이너가 직면하고 있는 문제가 아니라고 가정한다. 스토리지 용량 (최종 사용자에게 제공될 웹 데이터의 수와 사이즈) 스토리지 용량은 가장 직접적인 문제이다. 그러나 현재의 서버군 형태에서는 스토리지 양의 증설은 서버 증설과 스토리지 증설이 함께 고려되어야 하는 문제이다.
	웹서버 운용 실태
	웹 사이트는 사용자 요구에 서비스를 제공하기 위한 확장 가능한 용량을 제공해야만 한다. 대부분의 대규모 설치 사이트에서는 CPU 용량 확장을 위하여 로드 밸런싱(Load balancing)을 이용하고 있다. 로드 밸런싱은 여러 가지 방법으로 운영이 가능하지만, 가장 효과적인 방법은 Layer 4 네트웍 스위치 같은 로드 밸런싱 하드 웨어 장비를 사용하는 것이다. 로드 밸런싱 스위치는 인터넷(delivery network)과 서버 사이에 놓이게 된다. 한 URL의 요구가 발생하게 되면, 연결 요구를 중간에서 가로채 여러 서버들 중에서 특정 서버를 선택하여 그 요구를 처리하도록 한다.	그림1. 서버 로드 밸런싱
	그림 1은 서로 다른 클라이언트가 동시에 같은 URL을 요청하고 있는 모습을 보여준다. 이 경우 서로 다른 서버가 각 클라이언트에 서비스를 제공하게 된다. 서비스를 요청한 서로 다른 클라이언트를 위하여 네트웍 상에 서로 다른 경로가 존재하는 것이다. 이런 구조는 사이트의 CPU 용량을 확장하는데 매우 적당하다. 더 많은 CPU 사이클이 필요하게 되면, 운영자는 늘어나는 요구를 충족시키기 위하여 새로운 서버 하드웨어를 도입하기만 하면 된다. 그러나 여기에서 중요한 점은 각 클라이언트에 같은 데이터(같은 URL)가 제공되어야 한다는 것이다. 이것은 각 서버가 모든 웹 데이터의 복제본을 자체적으로 보유, 제공해야 한다는 것을 의미한다. 이것이 바로 스토리지 확장 문제에 있어 가장 중요한 부분이다.
	웹서버 환경에서의 스토리지
	모든 서버는 직접 연결된 스토리지(DAS;Direct Attatched Storage)에 반드시 그 데이터의 복제본을 보유하고 있어야 한다. 이것은 다음과 같은 세 가지의 문제를 야기시킨다. ● 서버를 위하여 모든 웹 데이터 복제본을 어떻게 동기화시킬 것인가 웹 데이터가 갱신, 추가 혹은 삭제되면, 모든 서버의 로컬 디스크(local Disk) 데이터도 변경되어야 한다. ● 모든 사이트의 스토리지 용량을 어떻게 확장할 것인가
	만일 더 많은 스토리지 용량이 필요하면, 모든 서버는 디스크를 추가해야 한다. 서버의 스토리지 용량이 한계에 도달하게 되면, 더 이상 데이터를 추가할 수 없다. 각 서버는 반드시 운영을 중지하고 디스크 스토리지를 추가해야 한다. ● 더 많은 CPU 용량이 필요하게 되면 어떻게 서버를 증설할 것인가 로드 밸런싱 하드웨어는 더 많은 CPU를 추가할 수 있도록 한다. 그러나 스토리지 확장 문제는 해결할 수 없다. 서버가 추가되면, 각 서버에 부가적인 디스크 스토리지를 도입해야 한다.
	SAN이란?
	광채널 스위치 기반의 네트웍, 즉 패브릭은 서버와 서버 혹은 서버와 스토리지 간의 고성능의 any-to-any 연결을 제공한다. 광채널은 대 규모의 어드레스 공간과 확장성 같은 네트웍의 특징과 고속의 I/O 채널의 특징을 단일 인프라스트럭처내에 모두 포함하고 있으며, 단일 인프라스트럭처를 통하여 네트워킹(IP), 스토리지(SCSI), 메시징(VIA)을 위한 다수의 프로토콜을 지원한다. 이 인프라스트럭처는 SAN을 구축하는데 사용될 수 있으며, SAN상의 디스크 스토리지와 테이프 라이브러리 같은 주변 장치는 광채널 네트웍에 연결되며, 연결된 노드 간에 공유된다(그림 2 참조). 서버와 스토리지를 이런 방식으로 편성하여 얻을 수 있는 특징은 다음과 같다.	그림2. 스토리지 영역 네트워크(SAN)
	스토리지 관리 SAN환경의 스토리지는 스토리지에 필요한 투자를 일관된 형태로 관리될 수 있도록 한다. 예를 들어, 다른 작업의 수행 중에도 스토리지가 호스트에 할당, 복제, 백업 그리고 모니터링 등의 작업을 병행할 수 있다. 이것은 각 호스트의 스토리지가 별개로 관리되어야 하는 직접 연결되어 있는 스토리지와 잘 비교가 된다. 비용 효과적인 오픈 시스템 모델 SAN은 사이트 운영자가 최고의 가격대 성능을 보유한 서버와 스토리지 장비를 선택할 수 있는 서버와 스토리지 인프라스트럭처를 위한 오픈 시스템 모델을 제공한다. 또한 하드웨어와 성능이 향상됨에 따라서, 시스템 운영자는 지속적으로 기존의 장비를 사용하면서도 새로운 시스템으로 발전시킬 수 있다. 고성능 광채널 패브릭은 100MB/sec의 전송 속도를 제공한다. 또한 블록 단위의 I/O는 네트웍 트래픽에 비교하여 훨씬 효율적으로 처리될 수 있다. 하나의 SCSI Command는 CPU 인터럽트를 포함하여 극히 적은 프로토콜 오버헤드로 수많은 메가바이트급 데이터의 전송을 가능하게 한다. 결과적으로, 상대적으로 저렴한 비용의 호스트와 스토리지 장비는 네트웍을 통하여 뛰어난 처리가 가능하다. 확장성 광채널 패브릭은 24비트 어드레싱을 사용하기 때문에 최대 1천 6백만개의 장비가 연결될 수 있다. 광채널 스위치는 스위치가 추가됨에 따라 스위치의 성능이 증가하기 때문에 성능의 손실 없이 노드의 추가가 가능하다. 전통적인 채널 연결 방식에 따른 연결될 수 있는 장비의 수에 대한 제한성을 극복하게 된다. 거리 전통적인 스토리지 연결 방식은 호스트와 스토리지를 연결시키는 케이블의 길이에 제한이 있었다. 광채널은 최대 10킬로미터까지 연결이 가능하다. 스토리지 통합 SAN은 많은 서버들이 SAN에 연결되어 있는 스토리지 장비를 액세스하도록 한다. 이것은 대규모의 스토리지를 구입함으로써 비용 절감을 가능하게 한다. 또한, 이 특징은 모든 서버군에 대해서 일관된 성능과 지원을 보장한다. 서버와 스토리지의 분리 스토리지를 서버로부터 분리시키는 것은 운영상의 많은 이점을 주게 된다. 서버들은 스토리지와는 별개로 업그레이드가 가능하고, 스토리지는 필요시에 추가되며 시스템 운영의 정지 없이 서버에 자동적으로 할당된다. 향상된 기능을 위한 Pay-As-You-Go 모델 SAN은 확장이 가능하기 때문에 무장애(fault-tolerance)와 온라인 백업(hot backup)같은 기능들을 점진적으로 이용할 수 있다. 이런 기능들의 사용 필요성이 증명되기 전에는 비용을 지불할 필요가 없다. 스토리지 효율성 SAN 에서는 이론상 모든 서버들이 어떤 스토리지 장비도 액세스할 수 있기 때문에, 스토리지 장비를 공유하기 위한 서버 소프트웨어의 향상이 잠재적으로 필요하다. 이것은 현재 전통적인 네트웍 기술을 통하여 데이터를 복제하고 공유하고 있는 애플리케이션의 변화도 내포하고 있다.
	그림3. Adding Storage DAS Web Servers	그림4. SAN 백 엔드 서버 아키텍처
	웹 서버를 위한 SAN : 유연한 확장성
	그림 4는 SAN에 연결되어 있는 스토리지가 있는 SAN 환경에 공유 파일 시스템이 추가된 것을 보여주고 있다. 이런 구성은 이미 설명한 모든 장점을 모두 이용할 수 있으며 스토리지 확장에 대한 제한을 극복할 수 있다. 스토리지 관리 스토리지는 서버 인프라스트럭처 투자에서 많은 부분을 차지하고 있다. 특히 웹 공간에서 스토리지의 요구는 최소 매년 100%씩 증가하고 있다. 투자가 증가함에 따라서, 자원의 관리는 점점 더 중요해지고 있다. SAN은 스토리지가 서버에 종속되는 것이 아니라 가장 중요하게 관리되어야 하는 자산으로 여겨져야 하는 관리 프레임웍을 제공한다. 소프트웨어 도구들은 다음과 같은 기능을 제공한다. ● 스토리지 파티셔닝 ● 호스트에 스토리지 할당 ● 데이터 복제 ● 스토리지 시스템의 상황 모니터링 ● 백업 이런 기능들은 스토리지 증설을 가능하게 하고 관리 비용을 조절하면서 시스템의 무중단 운영을 가능하게 하는 가장 중요한 요소들이다. 온라인 상의 시스템 설치 인 터넷 인프라스트럭처의 계획에 중요한 요소 중에 하나는 사이트가 점점 유명해질때 그에 맞는 빠른 확장을 가능하게 하는 능력이다. 만일 새로운 사이트가 많은 사용자를 유치하는데 성공했다면, 60일 내 혹은 그 이전에 매일 히트 수가 놀랍게 증가되는 것을 발견하는 것은 그리 놀랄 일은 아니다. 스위치 환경의 광 채널 SAN은 사이트 운영자가 스토리지와 클라이언트의 수에 제한이 있는 값비싼 서버의 투자를 보호하며 인프라스트럭처에 알맞은 투자가 가능하도록 한다. 새로운 스토리지는 서버의 운영 중단 없이 온라인으로 설치, 구성될 수 있다. 서버와 스토리지의 독립적인 확장가능 전 통적인 서버 디자인은 각 CPU에 스토리지를 바인딩하는 것이다. 대규모의 스토리지 용량을 가지고 있는 서버들은 부가적인 컨트롤러, 섀시(Chassis), 그리고 전원 공급기를 필요로 하기 때문에 더욱 많은 비용이 필요하게 된다. SAN 은 필요에 따라 스토리지와 서버를 증설할 수 있기 때문에 초기 구현시 상대적으로 작은 규모의 서버 구성이 가능하다. 만일 사용자의 요구를 충족시키기 위해서 더 많은 서버 CPU 사이클이 필요하다면, 서버는 수월하게 필요한 스토리지와 함께 혹은 별개로 증설될 수 있다. 만일 더 많은 컨텐츠를 공급하기 위해서 더 많은 스토리지가 필요하다면 SAN에 연결하고 기존의 서버에 그 스토리지를 적용함으로써 수월하게 증설할 수 있다. SAN의 확장성 스위치 광 채널 SAN은 사용자의 수가 증가되더라도 증설을 위한 운영상의 정지 없이 서버와 스토리지를 확장시킬 수 있다. -스위치의 수가 증가될수록 스위칭 용량은 늘어난다 스 위치 SAN이 지속해서 확장이 가능한 이유는 다른 스위치 네트웍처럼 네트웍에 스위치가 추가될수록 스위칭 용량이 증가하기 때문이다. 반대로, FC-AL(Fibre Channel-Arbitrated Log)와 공유 이더넷(Ethernet) 같은 네트웍에서는 연결된 노드의 수가 늘어나게 되면 가용한 대역폭을 공유하기 때문에 성능은 점점 떨어지게 된다. -향상된 라우팅은 SAN의 증설을 수월하게 한다 네트웍 노드의 수가 늘어남에 따라서, 운영자는 단순히 네트웍에 스위치를 추가하면 된다. 일반적으로 패브릭이 스위치와 노드가 추가될 때 네트웍의 토폴로지를 자동으로 감지하기 때문에 사용자 구성의 변경이 필요하지 않다. 광 채널 스위치는 스토리지 네트웍 운영자가 연결되어 있는 노드간에 다중 경로를 보유할 수 있는 그물 형태의 대규모 스위치 네트웍을 구축할 수 있도록 한다. 광 채널 스위치 소프트웨어는 자동으로 손상된 연결을 감지하여 다른 경로를 제공함으로써 SAN상에서 단일 오류 요소는 제거된다. 수월한 마이그레이션 현재 사용하고 있는 인프라스트럭처에서 SAN으로의 이전은 어려운 작업이 아니다. SAN을 구성하기 위해서는 다음과 같은 구성 요소들이 필요하다. ·Host Bus Adapter(HBA) ― 서버를 SAN에 연결할 때 ·Fibre Channel Storage ― SAN에 직접 연결할 때 ·SCSI-FC Bridge ― SCSI(디스크와 테이프) 장비를 SAN에 연결할 때 ·SAN Network Components―파이버 채널 스위치 현 재의 Windows NT와 UNIX를 위한 광 채널 HBA는 SAN에 연결된 스토리지를 마치 지역적으로 연결되어 있는 SCSI자원으로 보기 때문에 SAN을 시작하기 위해 필요한 운영 시스템이나 애플리케이션 소프트웨어의 업그레이드가 필요하지 않다. 초기 SAN환경의 구축은 하나 혹은 두개의 호스트와 하나의 SAN에 연결된 스토리지 장비, 혹은 JBOD(Just a Bunch Of Disks, Fibre Channel Arbitrated Loop Disk drives) 또는 Fibre Channel RAID로 시작하는 것이 일반적이다. SAN에 연결된 테이프 장비는 네트웍 기반의 백업에 비하여 훨씬 더 빠르게 작업을 수행한다. 테이프 백업 소프트웨어를 제공하는 많은 벤더들은 SAN 구성을 지원하는 프로그램들을 가지고 있다.
	공유 스토리지 원칙적으로, SAN의 모든 서버들은 클러스터 파일 시스템 혹은 공유 파일 시스템으로 알려져 있는 소프트웨어를 사용하여 스토리지 풀(pool)을 공유할 수 있다. 기존의 접근 방식에서는 한 서버에 직접 연결되어 있는 디스크에서 다른 서버의 디스크로 데이터가 복제된다. 그림 5는 같은 URL을 요청하고 있는 2개의 다른 클라이언트를 보여주고 있다. 로드 밸런싱 하드웨어는 각 클라이언트를 위한 서버를 선택한다. 이 경로는 각 서버가 같은 디스크 스토리지의 URL을 액세스하고 있는 것을 보여준다.	그림 5. 공유파일 시스템의 데이터에 대한 액세스
	향상된 기능을 위한 Pay-As-You-Go 모델 SAN은 확장이 가능하기 때문에 무장애(fault-tolerance)기능과 온라인 백업(hot backup)같은 기능들을 점진적으로 이용할 수 있다. 이런 기능들의 사용 필요성이 증명되기 전에는 비용을 지불할 필요가 없다. 예 를 들어, 이와 같은 아키텍처를 이용하여, 서버와 스토리지를 물리적으로 다른 곳에 분산시킴으로써 온라인 백업(hot backup) 사이트를 구축할 수 있게 된다. 가능하다면, dark fibre를 이용하여 최대 10km까지 사이트 분산이 가능하다(link extender를 사용할 경우 최대 120km까지 지원). Dark fibre를 사용할 수 없는 경우, 향후 몇 분기 내에 ATM연결을 사용하여 두개 혹은 그 이상의 사이트에 광 채널 패브릭을 확장시킬 수 있게 될 것이다. 또 다른 예에서는, 무장애(fault-tolerance) 디스크 시스템을 생성할 수 있다. 이것 역시 최초의 아키텍처에서 확장된 형태라고 할 수 있다. 사이트 운영자는 각 서버에 어댑터를 추가하여 다른 스위치에 연결할 수 있다. 디스크는 이미 이중 포트로 되어 있기 때문에, 디스크에 연결을 추가하기 위하여 필요한 것은 단지 다른 스위치 포트이다.
	이렇게 구성할 경우, 호스트 어댑터, 스위치, 혹은 스토리지의 포트에 손상이 발생할 경우에도 지속적인 운영이 가능하다. 소프트웨어 혹은 하드웨어 미러링은 어떤 단일 스토리지 장비의 손상에 의해서 발생하는 시스템 정지를 예방할 수 있다.

SAN (Storage Area Network) 이란?

특수 목적용 네트워크로서 서로다른 저장장치가 연결되어 모든 사용자가 공유할수 있을뿐만 아니라 백업, 복원, 영구보관, 검색 등이 가능하고 한 저장장치에서 다른 저장장치로 데이터를 이동시킬수가 있는 것입니다.

보통 SAN이라하면 파이버 채널을 이용한 FC SAN을 말합니다.

하지만 요즘에는 iSCSI가 뜨면서

 - 파이버 채널로 구성한 SAN은 FC SAN

 - iSCSI을 이용해 구성한 SAN은 IP SAN

으로 나누어 부르는 추세입니다.

먼저 기존의 FC SAN (Fibre channel Storage Area Network)

- 기존의 이더넷 환경 이외에 파이버 채널을 이용한 새로운 망을 설치해야합니다. (물론 각 컴퓨터에 넣을 어댑터도)

- 또한 여러서버에서 하나의 스토리지를 공유하기 위해서는 SAN 메니지먼트 소프트웨어도 필요합니다.

- 그에따라 막대한 비용이 소모 됩니다.

- 하지만 성능은 현존 최강입니다. 비교가 되고있는 IP SAN에 비해 전송속도, 에러감지 및 복구, 플로우 제어, 보안 등 모든 면에서 뛰어나다고 합니다.

- 대기업의 데이터센터 서버를 위한 스토리지 솔루션으로 주로 사용됩니다.

IP SAN(iSCSI SAN) (iSCSI 에 대해서는 따로 설명하도록 하겠습니다.)

- 기존 이더넷 환경을 그대로 사용할수 있습니다.

- 기존 이더넷 환경을 사용하기 때문에 FC SAN에 비하면 무척 저렴합니다.

- 이더넷 환경 어디서든 쓸수 있기때문에 거리의 제약이 없습니다.

- 중소기업의 스토리지 솔루션으로 사용되지만 대기업에서도 사용될 가능성이 높습니다.

In computing, a storage area network (SAN) is an architecture to attach remote computer storage devices such as disk array controllers, tape libraries and CD arrays to servers in such a way that to the operating system the devices appear as locally attached devices. Although cost and complexity is dropping, as of 2007, SANs are still uncommon outside larger enterprises.

By contrast to a SAN, network-attached storage (NAS) uses file-based protocols such as NFS or SMB/CIFS where it is clear that the storage is remote, and computers request a portion of an abstract file rather than a disk block.
Contents


    * 1 Network types
    * 2 Benefits
    * 3 Disk controllers
    * 4 SAN types
          o 4.1 Types of SAN
    * 5 SAN vs Traditional Server Based Storage
    * 6 Compatibility
    * 7 SANs at work
    * 8 SANs in a Small Office / Home Office (SOHO)
    * 9 SANs in the Media and Entertainment
    * 10 Volume-level vs. File-level sharing
    * 11 Storage virtualization and SANs
    * 12 See also
    * 13 References
    * 14 External links
          o 14.1 SAN Best Practices and Lessons Learned
          o 14.2 SAN Software Articles and White Papers

Network types

Most storage networks use the SCSI protocol for communication between servers and disk drive devices, though they do not use its low-level physical interface, instead using a mapping layer such as the FCP mapping standard.

    * Fibre Channel, currently the most common. Comes in 1 Gbit/sec, 2 Gbit/sec, 4 Gbit/sec, and 8 Gbit/sec variants (10 Gbit/sec is under development)
    * iSCSI, mapping SCSI over TCP/IP
    * HyperSCSI, mapping SCSI over Ethernet
    * ATA over Ethernet, mapping ATA over Ethernet
    * InfiniBand (IB), supports mapping SCSI over IB and/or mapping TCP/IP over IB

Benefits

Sharing storage usually simplifies storage administration and adds flexibility since cables and storage devices do not have to be physically moved to move storage from one server to another. Note, though, that with the exception of SAN file systems and clustered computing, SAN storage is still a one-to-one relationship. That is, each device, or Logical Unit Number (LUN) on the SAN is “owned” by a single computer (or initiator). In contrast, Network Attached Storage (NAS) allows many computers to access the same set of files over a network. The contrast between the SAN and NAS has been blurred with the creation of a NAS head.

SANs tend to increase storage capacity utilization, since multiple servers can share the same growth reserve.

Other benefits include the ability to allow servers to boot from the SAN itself. This allows for a quick and easy replacement of faulty servers since the SAN can be reconfigured so that a replacement server can use the LUN of the faulty server. This process can take as little as half an hour and is a relatively new idea being pioneered in newer data centers. There are a number of emerging products designed to facilitate and speed up this process still further. For example, Brocade Communication Systems offers an Application Resource Manager product which automatically provisions servers to boot off a SAN, with typical-case load times measured in minutes. While this area of technology is still new, many view it as being the future of the enterprise datacenter.

SANs also tend to enable more effective disaster recovery processes. A SAN attached storage array can replicate data belonging to many servers to a secondary storage array. This secondary array can be local or, more typically, remote. The goal of disaster recovery is to place copies of data outside the radius of effect of an anticipated threat, and so the long-distance transport capabilities of SAN protocols such as Fibre Channel and FCIP are required to support these solutions. (The physical layer options for the traditional direct-attached SCSI model could only support a few meters of distance: not nearly enough to ensure business continuance in a disaster.) Demand for this SAN application has increased dramatically after the September 11th attacks in the United States, and increased regulatory requirements associated with Sarbanes-Oxley and similar legislation.

Newer SANs allow duplication functionality such as “cloning,” “Business Continuance Volumes” (BCV) and “snapshotting,” which allows for real-time duplication of LUN, for the purposes of backup, disaster recovery, or system duplication. With higher-end database systems, this can occur without downtime, and is geographically independent, primarily being limited by available bandwidth and storage. Cloning and BCVs create a complete replica of the LUN in the background (consuming I/O resources in the process), while snapshotting stores only the original states of any blocks that get changed after the “snapshot” (also known as the delta blocks) from the original LUN, and does not significantly slow the system. In time, however, snapshots can grow to be as large as the original system, and are normally only recommended for temporary storage. The two types of duplication are otherwise identical, and a cloned or snapshotted LUN can be mounted on another system for execution, or backup to tape or other device, or for replication to a distant point.

Disk controllers

The driving force for the SAN market in the enterprise space is rapid growth of highly transactional data that require high speed block level access to the hard drives (such as data from email servers, databases, and high usage file servers). Historically, enterprises would have “islands” of high performance SCSI storage RAIDs that were locally attached to each application server. These “islands” would be backed up over the network, and when the application data exceeded the maximum amount of data storable by the individual server, the end user would often have to upgrade his server to keep up.

The disk controllers used in enterprise SAN environments are designed to provide applications with block level access to high speed, reliable “virtual hard drives” (or LUNs). In addition, modern SANs allow enterprises to intermix FC SATA drives with their FC SCSI drives. This allows enterprises to have multiple tiers of data that will migrate over time to different types of media. For example: many enterprises relegate files that are rarely accessed to FC SATA while keeping their frequently used data in FC SCSI.

Another feature of most enterprise disk controllers is an I/O cache. This feature allows higher overall performance for writing to the controller, and in some cases (like for contiguous file access where read ahead is enabled) reading from the controller.

SAN types

SANs require an infrastructure specially designed to handle storage communications called a fabric. Thus, they tend to provide faster and more reliable access than higher level protocols such as NAS. A fabric is similar in concept to a Network Segment in a local area network.

The most common SAN technology is Fibre Channel networking with the SCSI command set. A typical Fibre Channel SAN fabric is made up of a number of Fibre Channel switches. Today, all major SAN equipment vendors also offer some form of Fibre Channel routing solution, and these bring substantial scalability benefits to the SAN architecture by allowing data to cross between different fabrics without merging them. These offerings use proprietary protocol elements, and the top-level architectures being promoted are radically different. When extending Fibre Channel over long distances for disaster recovery solutions, it can be mapped over other protocols. For example, products exist to map Fibre Channel over IP (FCIP) and over SONET/SDH. It can also be extended natively using signal repeaters, high-power laser media, or multiplexers such as DWDMs.

Types of SAN

A centralized storage area network can contain many heterogeneous servers connected to one single storage space. The single storage space can have heterogeneous storage entities or disk drives. Centralized storage area networks are useful for simplifying the storage architecture in large organizations. The storage space can be treated as a black box so that administration of storage is easy. Centralized storage area networks are compatible with many different server environments including HP-UX, Solaris, Linux and Windows-based servers.

A distributed storage area network contains many geographically dispersed disk drive networks. All the networks are treated as one unit and are connected by the iSCSI storage area network protocol. Distributed storage area networks is a sub-network of shared storage devices that allows for all information stored to be shared among all of the servers on the network. Distributed storage area networks are most popular in large organizations with geographically dispersed storage pools, that can be connected and communicated through iSCSI.

SAN vs Traditional Server Based Storage

In a typical large LAN-installation, each of a number of servers (and perhaps mainframes) may have its own dedicated storage devices. If a client needs access to a particular storage device, it must go through the server that controls the device. In a SAN, no server sits between the storage devices and the network; instead, the storage devices and servers are linked directly to the network. The SAN arrangement improves client-to-storage access efficiency, as well as direct storage-to-storage communications for backup and replication functions.[1]

Compatibility

One of the early problems with Fibre Channel SANs was that the switches and other hardware from different manufacturers were not entirely compatible. Although the basic storage protocols (such as FCP) were always quite standard, some of the higher-level functions did not interoperate well. Similarly, many host operating systems would react badly to other Operating Systems sharing the same fabric. Many systems were pushed to the market before standards were finalized and vendors innovated around the standards.

The combined efforts of the members of the Storage Networking Industry Association (SNIA) improved the situation during 2002 and 2003. Today most vendor devices, from HBAs to switches and arrays, interoperate nicely, though there are still many high-level functions that do not work between different manufacturers’ hardware.

SANs at work

SANs are primarily used in large scale, high performance enterprise storage operations. It would be unusual to find a Fibre Channel disk drive connected directly to a SAN. Instead, SANs are normally networks of large disk arrays. SAN equipment is relatively expensive, therefore, Fibre Channel host bus adapters are rare in desktop computers. The iSCSI SAN technology is expected to eventually produce cheap SANs, but it is unlikely that this technology will be used outside the enterprise data center environment. Desktop clients are expected to continue using NAS protocols such as CIFS and NFS. The exception to this may be remote replication sites. Remote replication enables the data center environment to exist in multiple locations for disaster recovery and business continuity purposes.

SANs in a Small Office / Home Office (SOHO)

With the increasing rise of digital media in all phases of life and its effect on storage needs, it’s natural that SANs have begun to enter into the SOHO market. Historically, this market was dominated by NAS systems, but SOHO is poised to become a major market for SAN infrastructure as SOHO performance requirements rise.

Systems such as film scanners and video editing applications require performance that cannot be provided by traditional file servers. For example, motion picture film at 2048x1536 requires more than 300MBytes/s for each real-time stream, and several of these streams can be required simultaneously. As a result, several Gigabits per second can be required, which creates a problem for standard NAS technologies. In addition, these systems need to work with the same files collaboratively, so they cannot be distributed through different file servers or DAS connections.

Instead of having many computers connected to the network, with each one requiring a low bandwidth and only the server being stressed under heavy traffic, the SOHO “real-time” area only needs to integrate a few systems, but all of them require high bandwidth to access the same files. These problems are addressed very well by 4Gbit Fibre Channel SAN infrastructures, where the aggregated bandwidth for sequential I/O operations is extremely high.

SANs in the Media and Entertainment

Video editing workgroups require very high data rates. Outside of the enterprise market, this is one area that greatly benefits from SANs.

Per-node bandwidth usage control, sometimes referred to as quality-of-service (QoS), is especially important in video workgroups as it lets you ensure a fair and prioritized bandwidth usage across your network. Avid Unity and Tiger Technology MetaSAN are specifically designed for video networks and offer this functionality.

Volume-level vs. File-level sharing

The simplest form of SAN management consists in allowing one computer to write to a given volume while other computers can only read from it. To achieve this, a SAN management software only needs to mark the given volumes (so they appear as “read only” to the OS) on all but one computer, and let the OS manage the volume as it normally does.

By allowing all computers in the SAN to participate in both read and write operations on a common volume, file-level sharing offers significant savings and workflow benefits over the volume-level approach. Superior collaboration results when everyone has full access to files, folders, and projects. In addition, no storage provisioning is required as the entire volume’s space is available to all projects. However, resolving arbitration at the file-level is far more complex. A reliable mechanism must ensure that multiple computers writing to a shared volume do not corrupt the shared file system.


Storage virtualization and SANs

    * Storage virtualization refers to the process of completely abstracting logical storage from physical storage. The physical storage resources are aggregated into storage pools, from which the logical storage is created. With storage virtualization, multiple independent storage devices, that may be scattered over a network, appear to be a single monolithic storage device, which can be managed centrally. Storage Virtualization is commonly used in SANs. Virtualization of storage helps achieve location independence by abstracting the physical location of the data. The Virtualization system presents to the user a logical space for data storage and itself handles the process of mapping it to the actual physical location.

White papers:

    * whitepapers.techrepublic.com

Virtualization software: product descriptions and specifications

    * Overview Article and Product Specifications on Storage Virtualization Software from a number of vendors [1]

See also

    * ATA over Ethernet - a light-weight open source SAN protocol
    * Fibre Channel - the most common SAN protocol.
    * File Area Network
    * File hosting service
    * InfiniBand - a high-speed interconnect that can be used as a SAN
    * iSCSI - a newer SAN protocol
    * List of SAN Network Management Systems
    * Network-attached storage - the most common enterprise storage alternative
    * Redundant array of independent disks (RAID) - a common method of disk storage
    * SMI-S - Storage Management Initiative Specification
    * Storage Resource Management (SRM)

References

   1. ^ Stallings, William “Local Area Network Technology”, Business Data Communications, 4th Edition, 2001 Prentice Hall, p. 370-371.

External links

    * Introduction to Storage Area Networks - Exhaustive Introduction into SAN, IBM Redbook

SAN Best Practices and Lessons Learned

    * InfoWorld Virtualization Report on Top 10 SAN Lessons

SAN Software Articles and White Papers

    * Whitepapers.Techrepublic.com Vendor white papers

    * Networkworld Storage Research Center

    * SearchStorage Storage Software Links

    * Storage Networking World Knowledge Center Are SAN virtualization solutions right for you?

    * Virtual-Strategy Magazine Storage Virtualization White papers

DAS(direct attached storage)
 서버와 전용 케이블로 연결한 외장형 저장 장치. 서버/클라이언트 환경에서의 부족한 저장 공간을 가장 쉽게 확보하는 방법으로 서버 자체에 물리적으로 외부 저장 장치를 연결하는 것입니다.
 네트워크에 연결된 각 서버에 외부 저장 장치를 추가함으로서 필요한 데이터를 물리적으로 가까운 곳에서 접근할 수 있고 확장이 용이합니다.
 하지만 데이터의 증가에 따른 외부 저장 장치의 계속적인 추가는 서버의 효율성을 저하시키는 문제가 있습니다. 또 다른 문제는 네트워크상의 서버가 다운되는 경우에는 중지된 서버에 장착된 저장 장치도 사용할 수 없게 되어 중앙 집중식 시스템과 같은 취약점이 있습니다.
---------------------------------------------------------------------------
SAS(Serial Attached SCSI)
 SAS는 전통적인 SCSI(Small Computer System Inteface)보다 훨씬 더 빠른 속도로 데이터를 전송하기 위해 설계된 직접 연결 스토리지용 통신 프로토콜입니다.
 SAS는 병렬 방식(즉 SCSI 같은 것) 대신 직렬 통신 방식을 사용합니다. 즉 USB나 파이어와이어와 유사합니다. SCSI의 뒤를 잇는 기술로서 SAS는 기기와 대화하는 데 이용하는 SCSI 명령을 그대로 사용합니다.
 SAS 드라이브는 고성능/고가용성을 위해 만들어졌으며, 가격과 성능 면에서 엔터프라이즈급 스토리지에서 사용되는 FC(Fibre Channel) 드라이브에 견줄만합니다.
 1세대 SAS 인터페이스는 초당 3Gbps의 쓰루풋(throughput)을 내며, 2010년까지는 12Gbps가 나오게 될 것입니다.
---------------------------------------------------------------------------
NAS(Network Attached Storage)
1) 개요
* NAS는 Server와 Client가 Storage의 Network 에 의하여 원활한 접근을 할 수 있게 해 주는 Network 방식입니다.
2) 특징 및 장점
* Network에 연결된 NAS Server에 의해 데이터 서비스를 수행합니다.
* LAN, WAN등의 Data Network을 이용하여 접근합니다.
* 고성능, 고가용성을 위한 전용 OS가 탑제되어 있습니다.
* 이 기종간의 파일 공유가 가능합니다.
* 경제적으로 용이하며 설치가 용이합니다
* 저장장치의 유지 및 관리가 편리하다.
* 시스템을 정지시키지 않고 데어터 백업, 복구를 할 수 있습니다
* 시스템 변경 및 확장이 용이합니다
3) NAS의 필요성
* 데이터 관리를 온라인 상에서 필요로 할때
* 웹 호스팅업체 (자료실, 게시판)
* 금융기관(문서 공유, Report공유)
---------------------------------------------------------------------------
SAN(Storage Area Network)
1)개요
* 현재 직면해 있는 대용량의 Data와 고속의 Data 전송을 필요로 하는 Server와 Storage간의 원활한 접속을 Fibre Cahnnel의 기술과 접목시킨 SAN에 의하여 신속한 업무 처리와 흐름을원활히 해줍니다.
2) SAN이란
* Storage Area network의 약어이며, Server나 Host들에게 사용되는 대용량의 Data를 집중시켜 보관하고, 이를 구성하는 장비들을 이용, 공유하여 사용할 수 있도록 하는기술을 의미합니다.
* Host와 Storage가 분리되어 구성되어지며, Fibre Channel을 이용하여 고속전송,장거리 (cpooer : 30m, FC-AL:10km) 데이터 전송이 가능합니다.
* 서로 다른 운영체제를 가진 Server들이 같은 Network상의 Storage Data를 공유할 수 있습니다
* SAN을 이기종간의 여러 Server에서 하나의 Storage를 구축하기 위해서는 SAN Managemeent Software가 별도로 필요하며 SAN Network을 별도로 구축해야 합니다.
3) SAN의 기능
* 용량의 확장성이 있고, Data 전송 속도가 빠르고 Data 전송거리를 늘릴 수 있으며, 장비와 Storage 공유로 인해 비용을 절감할 수 있습니다.
* 특정 Server에 제한 하지 않고 Data Backup 등 통합 관리가 용이합니다.
* SAN 환경에서 데이터 저장장치는 Host Server와의 기종에 관계없이 멀티 Server와 공유되며 Host Server와 관계없이 저장장치 운용
* Disk Array 나 Backup 장치의 공유, Backup 기능, Clustering 기능 지원

RAID의 유래

    * RAID (Redundant Array of Inexpensive Disks)란 용어는 원래 고성능, 고가격의 High-End Disk System에 관한 수 많은 논문을 통하여 소개되어 왔다. 1987년 미국 Berkeley 대학의 Randy kate와 Garth Gibson이 "A Case of Redundant Array of Inexpensive Disks"라는 논문을 통하여 여러 종류의 Disk Array구조를 발표하였다.
    * Hard Disk가 고용량,고가격으로 가면서 저용량,저가의 Disk를 최대한 활용할 의도였다. 저가의 Disk들을 하나의 Virtual Disk로 구성하므로 대용량 저장장치를 구축하거나, 여러개의 Disk에 Data를 분할하여 병렬로 전송하므로써 전송 속도를 향상시키고, System이나 물리적인 Disk의 손상시 새로운 Disk를 교체하여 원래의 Data로 복구시키는 기능을 의미한다
    * Raid의 각 구조에 따라 Level을 나누어 표시하였다. 이 RAID Level을 이해하는데 주목해야 할 것은 Level이 높아지더라도 하위 Level의 기능을 포함하지 않을 수 있다는 것이다. 단지 구조에 따라 Level을 부여했을 뿐, Level간의 연관성은 부여하지 않고 있다.

RAID의 정의

    * 장애 발생요인을 최대로 제거한 무정지 대용량 저장장치임.
    * 여러개의 HDD를 하나의 Virtual Disk Drive로 구성하여 하나의 Drive처럼 사용할 수 있게 하며, 장애 발생시에도 최대한 Data를 보호하고 각각에 대해 독립적으로 동작
    * Virtual로 구성한 Disk Drive에 Data를 Byte 단위, Block단위, 또는 Segment 단위로 나누어 병렬로 동시에 저장 가능
    * Disk의 일부 공간에 Parity를 기록함으로써 Disk 손상시 Parity를 참조하여 Data 복구 가능

　
RAID의 구조

    * RAID는 두개 이상의 Disk Drive와 Array Controller로 구성되어 있다. Array Controller는 각 Disk들을 효율적으로 관리하여 안정성과 성능 및 용량을 한층 증가 시킨다.
    * RAID는 2,5,7,9,15 ... 등 User가 원하는 만큼의 Disk Drive를 장착하여 구성할 수 있다. 또한 필요에 따라 적당한 용량으로 Partition을 나눌 수 있다.

RAID 기능

    * Availability
      Availability란 저장 장치에 고장이 발생했음에도 불구하고 자료의 복구 유지가 가능하게 하는 능력이다.
            이 Availability는 RAID System이 제공하는 가장 큰 장점이다. RAID에서는 데이터 중복성 (Data Redundant)을 사용함으로써 수준 높은 Availability를 보장한다.
      Availability는 Mirroring과 Parity 방식이 있다.
      　
    * Mirroring에 의한 Data Redundant
      Mirroring 기술은 Data Redundant를 구현하는데 가장 간단한 방법이다. 이 방식을 RAID-1 이라 부른다.
            보통은 한쌍의 Disk Drive가 필요하다. Data가 하나의 Drive에 쓰여지면 자동으로 다른 Drive에도 동일한 내용이 기록된다. 양쪽 Drive에 동일한 Data가 저장되기 때문에 한쪽의 Drive에 장애가 발생했을 경우에 다른쪽 Drive에 의해 Data를 즉시 복구 할 수 있다. 이 방식을 "Mirroring" 또는 "Duplexing"이라 한다.
            그러나 "Mirroring"의 경우에는 하나의 Disk Controller에 의 해 Data가 기록되고 난 후 다른 Drive에 Data가 저장되기 때문에 입출력 속도가 절반으로 떨어진다.
            반면 "Duplexing"의 경우에는 두개의 Disk Controller가 있어 동시에 양쪽 Drive에 Data를 기록하므로 성능 저하가 없다.
      Mirroring은 매우 우수한 Data Availability를 갖고 있지만 비용이 두배가 드는 문제가 있다.
      　
    * Parity에 의한 Data Redundant
      Data Redundant를 위한 Parity 방식은 Parity Data를 만들기 위하여 매우 복잡하고 세련된 수학적 Data 교정 방식을 도입한 것이다. 여기서 여러 종류의 RAID Level이 이 방식에 의해 파생되었다.
            하나의 Disk에 문제가 발생헸을 경우 다른 Disk에 기록된 Parity를 이용하여 원래의 Data를 즉시 복구시킨다.
      　
    * Data Reconstruction
      Data Reconstruction이란 고장난 Drive를 새로운 Drive로 교체 하였을때, 고장난 Drive에 있는 원래의 Data와 똑같은 Data를 새로운 Drive에 생성시키는 과정을 의미한다. Data를 재구축 하는 동안에는 보통 RAID Array는
      Host에서 요구하는 Disk 입출력 요구에 100% 성능을 발휘하지 못한다. RAID Level에서는 Drive간 Copy 작업이 진행되거나 Parity를 이용 Data를 생성시키는 과정을 거치게 되기 때문이다. 따라서 Data Reconstruction시에는 통상적으로 System Manager에 의해 속도를 조절하게 된다.
      　
    * Hot Swap
      Hot Swap 개념은 현재 가동중인 System의 작업 중지 없이 운영중에 장애 부분을 교체할 수 있음을 나타낸다.
            만일 장애가 발생한 드라이브를 교체하기 위해 RAID System을 Down 시켜야 한다면 그 순간 Availability는 사라진다. 100% Data Availability를 구현하기 위해서는 Hot Swap이 되어야 한다.
            최근에는 Disk뿐 아니라, Power, AC Input Cord , FAN등 다른 장치까지 운영중 교체가 가능하다.

RAID 장점

    * 운영체계에서 다수의 물리적 Drive가 하나의 논리적 Drive로 보임으로써 논리적 드라이브 수의 제한을 피할 수 있다.
    * 다수의 소용량 Drive로 대용량의 Drive를 대체할 수 있다.
    * 하나의 Disk 입출력 요구에 대하여 여러개의 Disk에 Data를 분산시키고 병렬적으로 입출력을 처리함으로써 속도 향상과 효율성이 증가된다.
    * 다수의 Disk로 RAID를 구성함으로써 하나의 Disk에 물리적 장애가 발생하더라도 다른 Disk의 정보를 이용하여 원래 상태로 Data를 복구, 안정적으로 Data를 보관 할 수 있다.
    * System운영중 장애가 발생할 경우 손실 비용이 크게 증가된다. 또한 복구시의 노동력과 시간의 손실은 대단히 크다.
      RAID는 장애 발생시에도 System의 Down을 막고 Data를 보호할 수 있어 커다란 유익을 준다.
      RAID의 Real-Time Recovery와 무정지 운영은 오늘날 전산 환경의 필수 요소이다.


RAID LEVEL

* Raid-0 (Striping)
    * 최소 2개의 Disk Drive 필요
    * 각 Data는 Block 단위로 각각의 Disk에 저장됨.
    * I/O 성능은 Channel과 Disk수를 늘림으로써 높아짐.
    * Controller 하나에 Disk 하나를 연결하여 여러개의 Controller를 통해 I/O를 분산함으로써 최대의 성능을 낼 수 있다.
    * Parity 계산을 하지 않음. Data Redundant 안됨.

* 장단점

    * 구현이 쉽다.
    * Fault Tolerant가 아니므로 진정한 RAID라 할 수 없다.
    * Disk중 하나가 장애 발생시 모든 Data를 잃어 버린다.
    * 따라서 중요한 환경에는 사용하지 않는게 좋다.
    * Video, Image 편집, 높은 Bandwidth를 요구하는 Application에 적합함.

* Raid-1 (Mirroring)
    * 최대 성능을 위해 Controller는 각 Mirrore된 쌍으로된  Disk를 동시에 읽거나 ,각 Mirror된  두개의 Disk에 중복해서 쓰는 작업을 수행할 수 있어야 한다
    * 최소 2개의 Disk가 필요함.
    * 각 Mirror당 하나의 쓰는 작업과 두개의 읽는 작업이 가능함.
    * 하나의 Disk에 대해 두번의 읽기 전송 비율과 두번의 쓰기 전송 비율
    * 복구 Disk에 Data를 실시간 Copy함.

* 장단점

    * Block당 전송 속조는 Disk 하나일 때와 거의 동일함
      ( Read :빠름, Write-약간 느림,  Raid5 보다는 빠름)
    * RAID 1은 다중 Disk가 장애 발생랗 때에도 운영이 가능함.
    * 다중 사영자 시스템이서 최고 성능및 최고의 고장 대비 능력.
    * RAID 구현이 쉽다.
    * 비용이 많이 든다. ( 저장 용량당 단가 높음: 총 용량의 50%사용)

* Raid-2(Hamming Code ECC)
    * 디스크들 간에 스트립 사용
    * 에러검출 능력이 없는 드라이브를 위해 hamming 오류정정 코드를 사용
    * Data Word의 각 bot는 Data Disk Drive에 기록됨.
    * 각 Data Word는 ECC Disk들에 기록된 Hamming Code Word를 가지고 있음

* 장단점

    * 매우 높은 속도의 Data 전송이 가능함.
    * 높은 Data 전송 속도 요구시 Data Disk의 ECC에 대한 비율이 좋아야 함.
    * SCSI Disk는 자체 Erro 검출 능력이 있으므로 사용 안함.

* Raid-3( Data Striping with a Dedicated Parity Disks)
    * Parity 정보를 저장하기 위해 별도의 드라이브 한 개를 사용함.
    * Data Block은 세분화 되어서 Data Disk에 기록됨.
    * Data를 Bit 단위로 분할 기록 , Parity Disk에는 Parity만 기록함.
    * Stripe Parity는 Data 저장중에 생성되어 Parity Disk에 기록되고, Data 읽기시에 Check됨.
    * 최소 Disk 3개 필요.
    * 읽기 성능 매우 높음, 쓰기 성능 매우 높음.
    * Disk에 장애가 발생하더라도 Data  처리량에 영향력을 거의 미치지 않음.

* 장단점

    * 전송 속도는 Disk 하나일때와 거의 비슷한 성능을 나타냄.
    * Controller 디자인은 약간 복잡함.
    * Image 및 Video Data 편집등에 유리함.

* Raid-4( Independent Data Disks with Shared Parity Disk)
    * 각각의 전체 Block은 Data Disk내에 저장됨.
    * 같은 순번 Block들을 위한 Parity는 Data 저장 중에 만들어지며, Parity Disk에 기록됨.
    * 최소 3개의 Disk가 필요.

* 장단점

    * 대형 스트립을 사용, 중첩 입출력의 장점을 취할 수 있다.
    * Read시 level 0 정도의 속도, write시 추가적 시간 필요
    * 읽기 Data 전송 속도가 매우 높음.
    * Data가 크고 순차적 기록시에 유리
    * Disk 사용 효율이 좋다.
    * Controller 디자인이 복잡함.
    * 저장 전송 속도 좋지 않음.
    * Disk 장애시 Data Rebuild하는데 어렵고 비 능률적임.

* Raid-5 ( Independent Data Disks with Distributed Parity Blocks)
    * 각각의 Data Block은 Data Disk에 저장, 동시에 각 열의 Block을 위한 Parity는 Data 저장중에 생성
    * 회전식 Parity Array를 포함한다.
    * 모든 Disk에 Parity가 분산되어 기록되고 Data 읽기시에 Check됨.
    * 최소 3개의 Disk 필요.

* 장단점

    * 읽기 성능이 가장 좋음.
    * 작은 Data의 빈번한 입출력시 빠름.
    * 쓰기 성능은 보통임.
    * Disk 사용 효율이 매우 좋음.
    * Controller 디자인이 매우 복잡함.
    * Raid-1과 비교시 Data Rebuild가 어렵다.
    * File 및 Application Server
    * Data Base Server
    * WWW, E-mail, Intranet Server

* Raid-6 (Independent Data Disks with Two Independent Distributed Parity Schemes)
    * 본질적으로 두번째의 독립된 분산 Parity를 사용함으로써 추가적인 Fault Tolerance를 수행하는 Raid-5의 확장형
    * 다른 드라이브들 간에 분포되어 있는 2차의 Parity 구성을 포함함.
    * Data는 Raid-5처럼 Drive들 간의 하나의 set을 통한 Level에 하나의 Block이 Stripe된다. 그리고 모든 Drive를 통해 두번째 Parity set에 계산되고 쓰여진다.
    * 2개 이상의 Disk로 구성

* 장단점

    * 매우 높은 Data Fault Tolerance를 제공
    * 쓰기 성능은 Reed-Solomon Parity를 계산하는 ASIC을 사용하므로 Raid-5에 가까운 성능 발휘
    * 매우 복잡한 Controller 디자인
    * Parity 주소를 계산하는 Controller의 부하가 매우 높다.
    * 2차원 적인 Parity 계획 때문에 N+2개의 Disk를 필요로 한다 ( 투자대비 효율성 낮다)
    * 매우 중요한 Application에 최적임.

* Raid-7 (Optimized Asynchrony for High I/O Rates as well High Data Transfer Rates)
    * 콘트롤러에 내장되어 있는 실시간 운영체계를 사용, 빠른 속도의 버스를 통한 케시.
    * 독자적 컴퓨터의 특성을 포함
    * 모든 I/O 전송은 비동기이고 독립적으로 Control되며, Host Interface 전송을 포함하여 저장됨
    * 모든 Read 와 Write는 고속의 x-bus를 경유하여 저장됨
    * 할당된 Parity Drive는 어떠한 channel에 있을수 있음.
    * 수행 완료된 process를, 내장된 Array Control Microprocessor상에 상주하는 O/S에 실시간으로 보냄
    * 실시간 운영체계는 Chennel을 제어함.
    * 개방형 System은 표준 SCSI Drive들, 표준 PC Bus들, Motherboard 및 Memory를 사용한다.
    * 고속의 내부 Cache Data
    * Parity Generation은 Cache안에서 구성됨
    * 다중 접속된 Drive는 Hot Standby로 설정될 수 있다.
    * 원격 Monitor 및 관리를 SNMP를 통해 쉽게 할 수 있다.

* 장단점

    * 전체적인 Write 성능이 Single Spindle 성능보다 25% ~ 90%이상 좋고, 다른 Array Level보다  1.5배 ~ 6배 정도 좋다
    * Host Interface는 Connectivity 나 Host 전송 대역폭이 증대되었다
    * 동일한 Multi User환경에서의 Read는 0 에 가까운 Access 시간에 결과치를 내는,  매우 높은 Cache를 가지고 있다
    * Array내의 Drive 개수를 늘림으로써 Write 성능을 높일 수 있다.
    * Access Time은 Array내의 Actuator들의 수가 늘어날수록 감소한다
    * 임시 Data전송시에는 Parity 구성을 안한다.
    * Solution이 특정 Vandor에 있다.
    * MB당 매우 높은 비용이 든다.
    * Warranty가 매우 짧다.
    * Power Supply는 Cache Data의 손실을 막기위해 반드시 UPS를 써야한다.

* Raid-10 (Very High Reliability Combined with High Performance)
    * 각 스트립은 Raid-1 드라이브 어레이인 스트립 어레이를 제공  Raid-1 보다 성능은 높은 반면 비용 또한 높다.
    * 최소 4개의 Disk를 요구함.

* 장단점

    * Raid-1과 동일하게 작동된다.
    * Raid 1과 같이 동일한 Fault Tolerance를 지원한다.
    * Raid 10은 동시에 일어난 Disk 장애에서도 운영이 가능하다.
    * Raid-1 보다 성능은 높은 반면 비용 또한 높다.
    * 구성하는데 매우 값이 비싸다 ( 높은 overhead )
    * 높은 비용에 비해 확장성의 제한이 있다.

* Raid 0+1 (High Data Transfer Performance)
    * Raid-0 와 Raid-1의 구조를 동시에 구축
    * 최소 4개의 Disk Drive를 필요로 함.
        - Data 전송 성능이 높은 반면 비용 또한 높다

* 장단점

    * Raid-0와 동일하게 Mirror로써 동작한다.
    * Raid-1처럼 동일하게 Fault Tolerance를 가진다.
    * 단독으로 Mirror한 것과 같은 Fault Tolerance시의 부하를 가진다.
    * 다중 Stripe을 통해 높은 I/O 성능을 발휘한다.
    * 높은 성능을 요구하는 곳에서 훌륭한 Solution이다.
    * Raid-10과 구별이 쉽지 않다.
    * 하나의 Disk에 문제가 발생시 전체 Array에 영향을 미친다.
    * 매우 비싸다/ 높은 Overhead가 발생한다.
    * 모든 Drive는 한정된 성능내에서 병렬로 움직여야 한다.
    * 비용이 높은 반면 확장성에 한계가 있다.