내보내기(0) 인쇄
모두 확장
이 항목은 아직 평가되지 않았습니다.- 이 항목 평가

Windows Azure SQL 데이터베이스 사용 시 성능 고려 사항

업데이트 날짜: 2014년 1월

이 문서에서는 Windows Azure SQL 데이터베이스로 마이그레이션된 데이터베이스를 사용하는 응용 프로그램의 성능을 향상시키는 최선의 구현 방법에 대해 설명합니다. 데이터베이스 서버에서 응용 프로그램 서버와 동일한 랙을 공유하는 경우 이 최선의 구현 방법이 큰 효과가 없을 수도 있습니다. 그러나 데이터베이스 서버를 원격 데이터 센터로 이동하는 경우에는 이 최선의 구현 방법이 좋은 성능을 유지하는 데 효과적입니다. 또한 Windows Azure는 모든 리소스가 다른 응용 프로그램, 역할 및 데이터베이스와 공유되는 공유 환경입니다. Windows Azure에서는 네트워크 부하 분산 및 게이트웨이 구성 요소를 통해 규모의 경제를 유지하고 전체 환경에 컴퓨팅 및 네트워크 리소스를 가장 효율적으로 제공합니다. Windows Azure용 응용 프로그램을 디자인 및 배포할 때 이러한 요소를 고려하십시오.

이 문서에서는 Windows Azure SQL 데이터베이스 환경에 대한 성능 최적화를 위한 최상의 디자인 및 구현 방법에 대해 설명합니다. 특히, 내부 데이터베이스를 Windows Azure SQL 데이터베이스로 마이그레이션할 때 인식된 성능 문제를 발생할 수 있는 두 가지 영역을 해결하는 최선의 구현 방법에 대해 검토합니다.

아래에 설명된 대로 Windows Azure 데이터베이스의 성능과 관련된 기타 몇 가지 문서가 있습니다.

Windows Azure SQL 데이터베이스는 현재 미리 보기 프로그램을 통해 사용할 수 있는 Premium Edition을 통해 데이터베이스의 리소스를 예약하는 기능을 제공합니다. SQL 데이터베이스용 Premium 미리 보기 지침 문서에서는 미리 보기 프로그램을 통해 제공되는 Premium 데이터베이스가 사용자의 응용 프로그램에 적합한지 여부를 확인하는 데 도움이 되는 지침을 제공하고 이 기능을 최대한 활용할 수 있도록 응용 프로그램을 튜닝하는 방법에 대한 권장 사항을 제공합니다.

Windows Azure SQL 데이터베이스 및 SQL Server -- 성능과 확장성 비교 및 대조 문서에서는 SQL 데이터베이스의 일부 성능 패턴과 성능을 제대로 평가하기 위한 몇 가지 기법에 대해 설명하고, SQL 데이터베이스 인스턴스를 평가하고 관련 문제를 해결하는 데 도움이 될 수 있는 몇몇 SQL 스크립트를 제공합니다.

  • 연결 관리

  • 응용 프로그램 계층과 데이터베이스 계층 사이의 네트워크 대기 시간

저자: Silvano Coriani, Steve Howard
검토자: Mark Simms, Valery Mizonov, Kun Cheng, Paolo Salvatori, Jaime Alva Bravo

Windows Azure SQL 데이터베이스의 연결 관리

데이터베이스를 Windows Azure SQL 데이터베이스에서 호스팅하는 경우 데이터베이스 연결이 내부 환경에서보다 더 자주 끊길 수 있습니다. 응용 프로그램에서 연결 중단을 빠르게 감지하지 못하여 일시적인 오류가 발생하더라도 다시 연결하지 않을 경우 사용자가 이러한 끊김을 성능 문제로 인식할 수 있습니다. 공유 리소스에 대한 대규모 다중 테넌트 데이터베이스 서비스 공급자인 Windows Azure SQL 데이터베이스에서는 세 개의 노드를 통해 각 데이터베이스를 클러스터링하고 클러스터 노드 간의 균형을 조정하여 모든 테넌트에 유용한 환경을 제공합니다. 일시적인 오류의 예로는 여러 데이터베이스를 호스팅하는 서버에 대한 많은 사용량을 Windows Azure SQL 데이터베이스에서 감지하는 경우가 있습니다. 이 경우 Windows Azure SQL 데이터베이스에서는 처리 부하가 낮은 보조 클러스터 노드로 데이터베이스 중 하나를 장애 조치할 수 있습니다. 장애 조치(failover)는 열려 있는 모든 데이터베이스 연결을 끊고 처리 중인 트랜잭션을 롤백합니다. 응용 프로그램에서는 오류를 빠르게 감지하여 데이터베이스에 다시 연결한 다음 마지막 트랜잭션을 다시 시도해야 합니다.

다음 목록에서는 Windows Azure SQL 데이터베이스에서 연결을 끊기는 몇 가지 이유를 요약하여 설명합니다.

  • 전체 Windows Azure SQL 데이터베이스 네트워크 토폴로지는 방화벽, 부하 분산 장치 및 TDS(Tabular Data Stream) 게이트웨이를 포함합니다. 데이터 액세스 코드와 데이터베이스 노드 사이에 토폴로지 구성 요소별로 하나의 계층이 추가됩니다. 이러한 추가 계층에서 오류가 발생하면 연결이 끊길 수 있습니다.

  • Windows Azure SQL 데이터베이스에서는 데이터베이스 사용 통계를 지속적으로 수집하여 분석합니다. 수집된 통계를 기반으로 서비스를 정상 상태로 유지하는 데 필요할 경우 Windows Azure SQL 데이터베이스에서 연결을 끊을 수 있습니다.

  • 서비스 거부 공격은 Windows Azure SQL 데이터베이스에서 특정 IP 주소를 통한 연결을 일정 기간 동안 차단합니다.

  • 일부 장애 조치(failover) 이벤트로 인해 Windows Azure SQL 데이터베이스에서 세션을 갑자기 종료할 수 있습니다. 장애 조치(failover) 이벤트 이전에 노드에서 열린 연결은 장애 조치(failover) 이후에 새 노드에서 사용할 수 없습니다.

위의 목록은 연결이 끊기는 이유 중 일부에 불과합니다. 연결 오류에 대한 자세한 내용과 Windows Azure SQL 데이터베이스에서 연결을 관리하는 방법은 다음 문서를 참조하십시오.

코드에서 연결 관리를 처리하기 위한 옵션

Windows Azure SQL 데이터베이스 연결 문제를 관리할 수 있도록 Microsoft에서는 다음과 같은 기능을 제공하기 위해 노력하고 있습니다.

  • 기본 정보(서버 이름, 보안 자격 증명 등)를 지정하는 일관된 방법 또는 도구(대량 복사 프로그램(bpc.exe) 등)의 충실한 사용을 위해 노력합니다. 예를 들어 SQL Server Native Client 11, JDBC 버전 4.0 및 .NET Framework 버전 4.0의 .NET Framework Data Provider for SQL Server(System.Data.SqlClient) 이상에서는 Windows Azure SQL 데이터베이스에 액세스할 때 username@server를 지정할 필요가 없습니다.

  • 모든 연결 기술을 통해 유휴 기간에도 연결이 유지되도록 보장하기 위해 노력합니다. 예를 들어 Windows와 달리 Java 플랫폼에서는 기본적으로 데이터베이스 연결에 대한 '연결 유지' 간격을 관리하지 않습니다. 따라서 Windows Azure SQL 데이터베이스에 연결하는 JDBC 구성 요소에서는 유휴 연결이 끊어지지 않도록 하려면 일부 레지스트리 설정을 변경해야 합니다.
    자세한 내용은 MSDN 라이브러리에서 Windows Azure SQL 데이터베이스의 데이터베이스에 연결 항목을 참조하십시오.

또한 Microsoft는 가장 일반적인 데이터 액세스 라이브러리 및 Windows Azure SQL 데이터베이스 서비스 릴리스의 많은 업데이트를 지속적으로 배포합니다. 가장 중요한 업데이트는 강력한 일시적인 오류 처리 논리를 제공하는 응용 프로그램 라이브러리인 일시적인 오류 처리 응용 프로그램 블록입니다. 일시적인 오류는 네트워크 연결 문제, 서비스 사용 불가 등의 일시적인 조건으로 인해 발생하는 오류입니다. 다음 섹션에서는 일시적인 오류 처리 응용 프로그램 블록을 응용 프로그램에 적용하는 방법을 자세히 살펴봅니다.

일시적인 오류 처리 응용 프로그램 블록 사용 방법 개요

일시적인 오류 처리 응용 프로그램 블록에서는 응용 프로그램에서 다음 Windows Azure 서비스를 사용할 때 발생할 수 있는 일시적인 오류에 대한 정보를 캡슐화합니다.

  • Windows Azure SQL 데이터베이스

  • Windows Azure Service Bus

  • Windows Azure 저장소

  • Windows Azure Caching 서비스

이러한 각각의 서비스에서 서로 다른 일시적인 오류가 발생할 수 있습니다. 따라서 일시적인 오류 처리 응용 프로그램 블록에서는 서비스마다 다른 오류 검색 정책을 사용합니다. 마찬가지로 응용 프로그램마다 다른 오류 처리 전략이 필요합니다. 이러한 차이를 수용하기 위해 일시적인 오류 처리 응용 프로그램 블록에서는 다양한 일시적인 오류 시나리오를 처리하는 다양한 다시 시도 논리 접근 방식을 제공합니다. 체계적으로 정의된 인터페이스를 사용하는 사용자 지정 클래스를 만들어 이러한 기본 정책을 확장할 수 있습니다.

기존 응용 프로그램 내에서 일시적인 오류 처리 응용 프로그램 블록을 사용하는 것은 효과가 매우 작습니다. 디자인을 기반으로 일시적인 오류 처리 응용 프로그램 블록에서는 일반 ADO.NET 데이터 액세스 계층의 동작을 모방하는 여러 클래스 및 확장 메서드를 제공합니다.

이 응용 프로그램 라이브러리의 간편성을 설명하기 위해 다음 몇 개의 단락에서는 일부 기존 코드에 일시적인 오류 처리 응용 프로그램 블록을 적용하는 방법을 보여 줍니다. 다음 예에서는 데이터베이스를 쿼리하고 결과 집합을 사용하는 간단한 방법을 보여 줍니다.

        public static void ReadFromDB()
        {

            using (SqlConnection conn = new SqlConnection(connString))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = 
new SqlCommand(@"SELECT SOH.SalesOrderID
                         FROM SalesLT.SalesOrderHeader SOH 
                         JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                         JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                         JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                         JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                         JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                         WHERE A.City=@City", conn);

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = selectCommand.ExecuteReader();

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}",e.Message);
                }
            }

이 코드를 보다 강력하게 만들려면 먼저 적절한 다시 시도 전략을 정의합니다. 증분적 다시 시도 전략이 가장 적합합니다. 이 전략을 구현하려면 먼저 Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.SqlAzureTransientErrorDetectionStrategy 클래스를 사용합니다. 이 클래스는 일시적인 오류 조건과 관련된 오류 코드를 가로챈 후 다음 코드 예제와 같이 System.Data.SqlClient SqlConnection 클래스를 Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection 클래스로 대체합니다.

        public static void ReadFromDBWithReliableConnection()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            using (ReliableSqlConnection conn = new ReliableSqlConnection(connString,retryPolicy))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                        FROM SalesLT.SalesOrderHeader SOH 
                                        JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                        JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                        JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                        JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                        JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                        WHERE A.City=@City");

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = conn.ExecuteCommand<IDataReader>(selectCommand);

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}", e.Message);
                }
            }
        
        }

이전 코드 예제에서는 적절한 다시 시도 논리를 추가하는 동안 기존 SQLConnection 코드를 ReliableSQLConnection 코드로 대체했습니다. 다시 작성하는 코드의 양을 최소화하기 위한 대체 방법으로 일시적인 오류 처리 응용 프로그램 블록과 함께 제공되는 확장 메서드를 사용할 수 있습니다. 이 방법은 다시 작성해야 하는 양을 최소화할 뿐만 아니라 ADO.Net 응용 프로그램에 다시 시도 기능을 추가하는 일반적인 방법을 제공합니다. 확장 메서드를 사용하려면 Open() 및 다양한 Execute 메서드(예: ExecuteScalar(), ExecuteReader(), ExecuteNonQuery())를 다시 시도 가능한 해당 메서드(예: OpenWithRetry(), ExecuteScalarWithRetry())로 대체합니다. 다음 코드 예를 참조하십시오.

        public static void ReadFromDBWithExecute()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            try
            {
                retryPolicy.ExecuteAction(
                  () =>
                  {
                      using (SqlConnection conn = new SqlConnection(connString))
                      {
                          conn.OpenWithRetry();

                          SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                                FROM SalesLT.SalesOrderHeader SOH 
                                                JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                                JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                                JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                                JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                                JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                                WHERE A.City=@City",conn);

                          selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                          selectCommand.CommandType = CommandType.Text;

                          // Execute the above query using a retry-aware ExecuteCommand method which will
                          // automatically retry if the query has failed (or connection was dropped)
                          IDataReader dataReader = selectCommand.ExecuteReaderWithRetry(retryPolicy);
                          
                            while (dataReader.Read())
                            {
                                Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                            }                          
                      }
                  });
            }
            catch (Exception e)
            {
                Console.WriteLine("Exception: {0}", e.Message );
            }

        }

일시적인 오류 처리 응용 프로그램 블록에서는 구성 가능한 다시 시도 정책 선언을 지원합니다. 다시 시도 정책 선언에 대한 자세한 내용은 구성에서 다시 시도 전략 지정을 참조하십시오.

여기에 표시된 코드 예에서는 일시적인 오류 처리 응용 프로그램 블록을 사용하는 방법을 간략하게 보여 줍니다. 이 응용 프로그램 라이브러리를 사용하는 방법에 대한 자세한 내용은 다음 TechNet Wiki 자습서를 참조하십시오. Windows Azure SQL 데이터베이스의 일시적 오류에 대한 다시 시도 논리

Windows Azure SQL 데이터베이스의 네트워크 대기 시간

연결 오류 이외에 현재 Windows Azure SQL 데이터베이스 사용자 사이에서 가장 많이 발생하는 성능 문제로 네트워크 대기 시간이 있습니다.

인터넷 대기 시간의 영향을 잘 알려져 있지만 응용 프로그램과 Windows Azure SQL 데이터베이스 사이에서 발생하는 대기 시간의 영향에 대해서는 과소 평가하는 경향이 있습니다. 응용 프로그램과 데이터베이스를 동일한 데이터 센터에서 호스팅하는 경우에도 대기 시간이 기존 내부 환경의 대기 시간보다 더 높은 것이 일반적입니다. 이 높은 대기 시간은 Azure의 다중 테넌트 특성에서 기인합니다. 또한 이 높은 대기 시간은 "규격화되지 않은" 응용 프로그램 동작의 영향을 증폭시켜서 데이터베이스를 호출할 때마다 대기 시간이 증가하므로 전체적인 성능 저하가 가중될 수 있습니다. 따라서 "규격화되지 않은" 응용 프로그램에서 내부에 호스팅된 SQL Server 데이터베이스가 아닌 Windows Azure SQL 데이터베이스에 호스팅된 데이터베이스에 액세스할 경우 훨씬 더 오래 걸립니다.

응용 프로그램과 Windows Azure SQL 데이터베이스 사이의 대기 시간뿐만 아니라 솔루션의 다양한 분산된 구성 요소 간 통신에서도 대기 시간이 늘어납니다. 이러한 유형의 대기 시간은 내부 응용 프로그램과 클라우드 응용 프로그램 사이의 가장 큰 차이점 중 하나입니다. 또한 이런 유형의 대기 시간은 사용자와 응용 프로그램 간 통신과 응용 프로그램과 Windows Azure SQL 데이터베이스 간의 통신에서 모두 발생합니다.

최종 사용자의 관점에서 네트워크 대기 시간에 대한 이러한 모든 원인은 사용자가 인식하는 다음과 같은 응답 시간과 일치합니다.

Response Time = 2 x (Latency_1 + Latency_2) + Application_Processing_Time + Query_Exec_Time

여기서

  • Latency_1 은 최종 사용자와 응용 프로그램을 호스팅 중인 데이터 센터 사이의 대기 시간입니다. 이러한 유형의 대기 시간은 내부 환경에서도 발생할 수 있습니다.

  • Latency_2 는 응용 프로그램과 Windows Azure SQL 데이터베이스의 데이터베이스 사이의 대기 시간입니다.

성능을 최적화하려면 먼저 다음과 같은 기본 작업을 수행하는 것이 좋습니다.

  • 대부분의 사용자로부터 가장 가까운 데이터 센터를 선택하여 Latency_1을 최소화합니다.

  • 데이터를 Windows Azure 응용 프로그램과 함께 배치하여 네트워크 왕복을 최소화함으로써 Latency_2를 최소화합니다.

  • 데이터 계층 액세스, 성능 처리, 최적화를 위한 코딩 등에서 내부 데이터베이스를 사용할 때 일반적인 최선의 구현 방법에 따라 Application_Processing_TimeQuery_Exec_Time을 최소화합니다.

데이터와 응용 프로그램 사이의 거리 최소화

데이터베이스를 응용 프로그램이 실행되는 위치에서 최대한 가깝게 호스팅하는 것이 중요합니다. 응용 프로그램이 North Central US 데이터 센터에서 실행 중인 경우 데이터베이스를 North Central US 데이터 센터에서 호스팅하면 왕복 거리가 최소화되고, 그에 따라 거리 관련 대기 시간이 최소화됩니다.

내부에 호스팅된 응용 프로그램에서 Windows Azure에 호스팅된 데이터베이스에 액세스할 수 있지만 그럴 경우 데이터 액세스를 위한 대기 시간이 길어지고 데이터 센터에서 데이터를 송신하는 비용이 발생합니다.

여러 지리적 로캘에서 데이터에 액세스해야 하는 경우 콘텐츠 배달 네트워크를 사용하여 여러 사이트에 정적 데이터를 배포합니다. 또는 여러 데이터 센터에서 데이터베이스 복사본을 여러 개 만든 후 SQL 데이터 동기화(미리 보기)를 사용하여 데이터 센터 간의 데이터를 통기화합니다. 이러한 방법은 데이터를 응용 프로그램의 여러 인스턴스에서 가깝게 배치하여 전체 대기 시간을 줄여주므로 응용 프로그램을 여러 지리적 위치에서 실행하는 경우에 유용합니다.

note참고
SQL 데이터 동기화(미리 보기)는 현재 미리 보기로만 사용할 수 있으며 이후 릴리스를 위한 제품 사용자 의견용으로만 사용되므로 프로덕션 환경에서는 사용할 수 없습니다.

네트워크 왕복 최소화

네트워크 왕복 최소화는 내부 응용 프로그램에도 중요하지만 Windows Azure에 특히 중요합니다. Windows Azure SQL 데이터베이스에서 처리되는 쿼리는 네트워크 부하 분산 계층과 TDS 프로토콜 게이트웨이를 통과한 이후에 Windows Azure SQL 데이터베이스에 수신됩니다. Windows Azure SQL 데이터베이스에서는 이 추상화를 통해 최종 사용자에게 확장성과 가용성을 제공하지만 이 추상화를 사용하려면 특정한 양의 처리 과정이 필요하므로 왕복할 때마다 약간의 대기 시간이 발생합니다. 많은 횟수의 순차적 왕복을 통해 Windows Azure SQL 데이터베이스에 데이터를 보내는 응용 프로그램에서는 성능 크게 저하될 수 있습니다.

왕복의 영향을 최소화하려면 내부 응용 프로그램의 경우와 동일한 최선의 구현 방법을 따르십시오.

  • 특히, 저장 프로시저 사용하여 복잡한 데이터 액세스 논리 및 트랜잭션 동작 캡슐화 - 순차적 호출을 사용할 때 두 번째 호출이 첫 번째 호출에서 반환되는 데이터에 따라 달라지는 경우, 저장 프로시저를 사용하여 논리를 수행하면 두 번째 호출에서 한 번 이상의 왕복을 제거하여 성능을 가속화할 수 있습니다. 이 방법을 사용하면 왕복과 서버 쪽의 리소스 잠금 및 사용량이 자연적으로 감소합니다.

  • 커서 사용 또는 행 단위 액세스 최소화 - 가능하면 집합 기반 작업을 사용합니다. 커서를 사용해야 하는 경우 클라이언트 쪽 커서를 사용합니다.

  • 각 왕복에서 테이블 반환 매개 변수를 사용하여 Windows Azure SQL 데이터베이스에 여러 행 보내기 - Windows Azure SQL 데이터베이스에서는 SQL Server 데이터베이스 엔진의 내부 버전에서와 마찬가지로 테이블 반환 매개 변수를 사용합니다. 테이블 반환 매개 변수를 사용하면 레코드/값 집합을 처리하기 위해 동일한 저장 프로시저를 호출하는 횟수를 여러 번 줄일 수 있습니다. 또한 테이블 형식 매개 변수를 단일의 매개 변수가 있는 쿼리(예: SELECT, INSERT, UPDATE 또는 DELETE 명령)로 전달할 수 있습니다.
    자세한 내용은 온라인 설명서의 테이블 반환 매개 변수 사용 항목을 참조하십시오.

  • 가능한 경우 로컬 캐싱 사용 - 로컬 캐싱을 사용하면 Windows Azure SQL 데이터베이스로 여러 번 왕복하지 않고 동일한 결과를 다시 사용할 수 있습니다. 또한 동일한 상황에서 동일한 값을 반환하는 저장 프로시저에 호출을 캐시할 수 있습니다.

  • 가능한 경우 Windows Azure 캐싱 사용 - 읽기 전용 조회 데이터에 대한 Windows Azure 캐싱을 사용하여 Windows Azure SQL 데이터베이스에 대한 네트워크 트래픽을 최소화합니다. 자세한 내용은 Windows Azure Caching을 사용하여 네트워크 왕복 감소를 참조하십시오.

  • 가능한 경우 메타데이터 및 데이터 캐시

  • 되도록 런타임에 메타데이터 검색 안 함

  • SqlCommandBuilder 같은 클래스 방지 - 이러한 클래스는 런타임에 메타데이터를 쿼리하여 왕복 횟수가 증가됩니다.

  • 가능하면 SQL 문을 일괄 처리 - 단일의 일괄 처리 명령에서 여러 Transact-SQL 문을 연결하여 여러 결과 집합을 검색하거나 단일의 네트워크 왕복에서 여러 DML 작업을 실행할 수 있습니다. 이 방법은 연속 INSERT 작업을 많이 처리할 때 특히 유용합니다.

  • 응용 프로그램 기반 트랜잭션 관리 방지 - 트랜잭션 관리 작업(BEGIN TRAN, COMMIT/ROLLBACK)을 저장 프로시저에 캡슐화하여 네트워크 왕복 및 잠금을 줄일 수 있습니다.

내부 데이터베이스에 대한 일반적인 최선의 구현 방법 따르기

데이터와 사용자 사이의 거리를 최소화하여 네트워크 왕복을 최소화한 후 다음 단계에서는 응용 프로그램이 내부 데이터베이스에 대한 일반적인 최선의 구현 방법을 따르는지를 확인합니다. 잘 알려진 최선의 구현 방법 및 권장 사항을 성능 및 최적화를 위한 최선의 구현 방법과 함께 응용 프로그램의 데이터 액세스 계층에 적용하여 클라우드와 같은 대기 시간이 긴 환경에서 효과를 '배가'해야 합니다.

내부 데이터베이스와의 데이터베이스 상호 작용에 대한 일반적인 최선의 구현 방법에는 다음과 같은 권장 사항이 포함되어 있습니다.

  • 연결을 가능한 늦게 열고 빨리 닫기 - 리소스 사용률과 제한 가능성을 최소화하려면 코드에 해당 연결이 필요한 지점에서만 응용 프로그램에서 연결을 엽니다. 또한 코드에서 연결 작업을 마친 후 연결 개체를 즉시 삭제하여 연결을 풀에 반환합니다. 더 급한 작업이 있는 경우에는 이 반환 정책의 예외입니다. 이 경우 가장 시급한 작업이 모두 완료된 경우에만 연결을 반환합니다.

  • 연결 풀링 활용 - 프로세스 수준에서 연결 풀에는 동일한 데이터베이스를 대상으로 하고 동일한 보안 컨텍스트를 사용하는 연결이 포함되어 있습니다. 가능한 경우 동일한 특성을 가진 모든 연결에 대해 동일한 연결 문자열을 사용하십시오.

  • 필요한 데이터만 검색 - SELECT 목록과 WHERE 절을 신중하게 정의합니다. 이 방법을 사용하면 네트워크 대역폭 사용을 최소화하고 성능을 위해 데이터베이스를 효과적으로 인덱싱할 수 있습니다.

  • 트랜잭션을 최대한 짧게 유지하고 불필요한 리소스 제외 - 데이터 모델 디자인이 최적화되지 않아 응용 프로그램 코드와 데이터베이스 사이의 왕복이 과도하게 많아지는 것은 일반적인 문제이지만, 내부 배포에서는 대기 시간이 낮은 연결 환경으로 인해 중요한 문제가 되지 않을 수도 있습니다. 이러한 응용 프로그램은 다음과 같은 이유로 인해 수정하기 어려울 수도 있습니다.

    • 기존 아키텍처 제약 조건

    • 데이터 액세스와 비즈니스 논리가 밀접하게 연결되고 상호 종속되는 모놀리식 디자인

    • 응용 프로그램 논리 자체에 필요하지만 많은 부분을 다시 작성하지 않고는 수정하기 어려운 일부 측면(예: 행 단위 데이터 처리)

이러한 일반적인 최선의 구현 방법 외에도 응용 프로그램에서 사용하는 기술과 관련된 추가적인 최선의 구현 방법이 있습니다. 예를 들어 .NET Framework를 사용하는 응용 프로그램에서는 ADO.NET, Entity Framework, WCF Data Services 등의 기술을 사용할 수 있습니다. 이러한 기술을 사용하면 개발 시간을 단축하고 응용 프로그램 스타일에 대한 데이터 액세스 계층을 매우 유연하게 구현할 수 있습니다. 이러한 기술은 계층을 분리하고, 스키마 유연성을 제공하고, 개방형 데이터 아키텍처(예: OData)를 사용하고, 기본적으로 '연결이 끊어진' 디자인을 제공하여 서비스 방향에도 부합됩니다. 하지만 이러한 이점에도 불구하고 적절한 데이터 디자인 및 작업 최적화(불필요한 왕복을 줄이기 위한 최적의 데이터 표현, 캐시 사용 및 데이터 관련 작업 포함)를 고려하지 않을 경우 이러한 기술은 레거시 응용 프로그램에 대해 설명한 것과 동일한 문제(예: 규격화되지 않음)를 발생할 수 있습니다.

다음 섹션에서는 Azure 응용 프로그램에 비동기 프로그래밍을 적용하는 방법과 이러한 기술에 대한 몇 가지 최선의 구현 방법에 대해 설명합니다.

ODBC 및 JDBC에 대한 최선의 구현 방법

인텔리전스 작업(정렬, 필터링 등)에 대한 클라이언트 쪽 지원이 제한되는 ODBC, JDBC 등의 데이터 액세스 라이브러리의 경우에도 커서 기반 작업 및 행 단위 처리 감소와 같은 기존 최적화 기술을 적용할 수 있습니다. 커서를 사용해야 하는 경우 읽기 전용의 정방향 전용 커서를 사용하여 값을 검색하고 커서의 위치 지정 업데이트를 사용하지 않고 SQL 명령을 사용하여 데이터를 수정합니다.

ADO.NET에 대한 최선의 구현 방법

ADO.NET에는 데이터 액세스 코드의 효율성을 극대화하기 위해 적용할 수 있는 몇 가지 최적화가 있습니다.

  • SqlCommand를 사용하여 적절한 실행 모드 선택 - 예를 들어 스칼라 값을 검색 해야 하는 경우 ExecuteScalar() 메서드 또는 ExecuteNonQuery() 메서드(결과 집합을 검색할 필요가 없는 경우)를 사용합니다.

  • SqlDataAdapter 클래스를 사용하여 여러 작업을 실행할 때 UpdateBatchSize 속성 사용 - 네트워크를 통해 전송되는 여러 명령을 일괄 처리하여 네트워크 왕복을 최소화합니다.

  • SqlDataAdapter를 사용하여 SELECT, INSERT, UPDATE 및 DELETE 작업에 대한 저장 프로시저를 통해 데이터베이스 상호 작용 직접 구현

  • 데이터베이스를 클라이언트 쪽 캐시로 사용할 경우 SerializationFormat 속성을 Binary로 설정 - 유선을 통해 전송되는 데이터의 양이 감소됩니다.

Entity Framework에 대한 최선의 구현 방법

데이터 액세스 개발과 관련하여 다음과 같은 이유로 Entity Framework에 많은 관심이 있습니다.

  • 개발 시간을 극적으로 단축할 수 있는 풍부한 개체-관계형 매핑 환경을 제공합니다.

  • 응용 프로그램 데이터의 개념적 표현에서 물리적 데이터베이스 스키마 정의를 분리하여 유연성을 강화합니다.

  • 일관된 처리가 가능하도록 전체 서비스 집합을 제공합니다.

  • Windows Azure SQL 데이터베이스에서 응용 프로그램 메모리의 개체 집합으로 결과 집합을 로드할 수 있도록 하여 네트워크 왕복을 줄여주고 모든 작업에 대해 백 엔드와 상호 작용할 필요 없이 연결이 끊어진 상태로 결과 집합을 다시 사용합니다.

하지만 다른 프로그래밍 도구와 마찬가지로 데이터베이스 상호 작용을 처리할 때 특별히 주의하지 않을 경우 Entity Framework도 몇 가지 성능 문제를 발생할 수 있습니다. 또한 Windows Azure 환경에서 이러한 성능 문제가 증폭됩니다.

Windows Azure SQL 데이터베이스에서 Entity Framework 사용을 최적화하려면 다음과 같은 최선의 구현 방법 지침을 따르십시오.

  • 엔터티와 관계 모두에 대해 ObjectStateManager 수준에서 개체의 상태 추적을 사용하지 않도록 명시적으로 설정 - 일반적인 읽기 전용 사용으로 인해 응용 프로그램에서 개체 상태를 추적할 필요가 없는 경우에 이 지침을 적용하십시오.

  • 코드와 데이터베이스 간 상호 작용을 효율적으로 제어하기 위해 지연 로드 사용 안 함 - 왕복을 줄이기 위해 단일 상호 작용에 필요한 모든 항목을 다시 로드합니다. 특정 메서드로 개체 컨텍스트를 확장하여 데이터를 로드할 때와 데이터 저장소에 데이터를 저장할 때 모두에 적용할 수 있는 여러 명령을 일괄 처리할 수 있습니다.

  • 가능한 경우 데이터 저장소 상호 작용에 대해 저장 프로시저 사용 - 저장 프로시저를 사용할 수 없는 경우 성능 향상을 위해 매개 변수가 있는 쿼리 및 인덱싱된 보기를 사용하십시오.

  • 테이블 반환 매개 변수를 통합하고 개체 집합을 저장 프로시저 테이블 형식 매개 변수에 매핑하여 단일 왕복에서 여러 데이터베이스 작업 실행 - 이 방법은 디자인 도구에서 직접 지원하지 않는 경우에도 사용할 수 있습니다.

  • 가능한 경우 단일 작업에서 개체에 여러 결과 집합 매핑

  • 대규모 데이터 삽입 활동을 위한 System.Data.SqlClient.SqlBulkCopy.WriteToServer() 메서드에 개체 집합 매핑 - SQLBulkCopy 메서드를 사용하면 SQL Server 데이터베이스 엔진 및 Windows Azure SQL 데이터베이스에서 대규모 작업 로깅 최적화를 활용하여 대부분의 경우 대규모 삽입을 더욱 빠르게 수행할 수 있습니다.

자세한 내용은 Windows Azure SQL 데이터베이스의 네트워크 대기 시간을 줄이기 위해 Entity Framework 사용을 참조하십시오.

비동기 프로그래밍에 대한 최선의 구현 방법

명령 실행과 같은 일부 데이터베이스 작업을 완료하는 데 많은 시간이 걸릴 수 있습니다. 그런 경우 단일 스레드 응용 프로그램에서는 다른 작업을 차단하고 명령이 완료될 때까지 대기한 다음 다른 작업을 계속해야 합니다. 반면에 장기 실행 작업을 백그라운드 스레드에 할당하면 작업을 마칠 때까지 포그라운드 스레드를 활성 상태로 유지할 수 있습니다.

ADO.NET에서는 SqlCommand 클래스에서 이러한 동일한 디자인 패턴을 지원합니다. 특히, BeginExecuteNonQuery(), BeginExecuteReader() 및 BeginExecuteXmlReader() 메서드를 EndExecuteNonQuery(), EndExecuteReader() 및 EndExecuteXmlReader() 메서드와 각각 연결하면 비동기 지원이 제공됩니다.

이러한 비동기 메서드는 이전 섹션에서 설명한 모든 최적화 및 최선의 구현 방법을 적용하여 절약할 수 없습니다. 하지만 Windows Azure SQL 데이터베이스에서 다른 작업을 쿼리와 함께 실행할 수 있으므로 데이터 액세스 계층에서 장기 실행 데이터베이스 작업의 영향을 줄일 수 있습니다.

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.

커뮤니티 추가 항목

추가
표시:
© 2014 Microsoft. All rights reserved.