Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
마침 프로모션 실습도 할 겸,
APM 솔루션, 제니퍼 PHP, .NET 무료 사용 프로모션 _2020
; https://jennifersoft.com/ko/blog/2020-06-17/
제 웹 사이트도 ^^
제니퍼 닷넷을 이용해 모니터링을 해보았습니다. 아래의 화면은 들어오는 요청들을 보여주는
X-View인데,
좀 이상한 부분이 있습니다. 거의 모든 요청에 대한 응답시간이 400ms 가깝게 걸려 바닥에서 약간 뜨고 있는데요, 사실 제 웹 사이트는 단순히 게시판을 읽어내는 용도이기 때문에 딱히 저렇게 걸릴만한 요소가 없습니다. 그런데, 이에 대한 프로파일 결과를 보면,
TXID : 6249473527617534112 DOMAIN (ID) : udb (12266)
START_TIME : 2020-07-17 09:49:42 525 INSTANCE (ID) : 1 (1)
COLLECTION_TIME : 2020-07-17 09:49:42 951 BUSINESS :
END_TIME : 2020-07-17 09:49:42 947 ERROR :
RESPONSE_TIME : 422 CLIENT_IP : 46.229.168.133
SQL_TIME : 329 CLIENT_ID : 0
EXTERNALCALL_TIME : 0 USER_ID :
FETCH_TIME : 0 GUID :
CPU_TIME : 0 USER_AGENT : ...[생략]...
FRONT_APP_ID : FRONT_PAGE_LOAD_ID :
APPLICATION : /Default.aspx (867325662)
---------------------------------------------------------------------------------------------------------------------
[ No.][ START_TIME ][ GAP][CPU_T]
---------------------------------------------------------------------------------------------------------------------
[ ][09:49:42 525][ 0][ 0] START
[0000][09:49:42 525][ 0][ 0] System.Void ASP.default_aspx.ProcessRequest(System.Web.HttpContext) [422 ms]
[0001][09:49:42 525][ 0][ 0] [GET] ...[생략]...
[0002][09:49:42 525][ 0][ 0] DB_OPEN_CONNECTION (0x133d21d, Server=tcp:testdb.database.windows.net,1433;Database=udb;User ID=udbadmin@testdb;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;) [0 ms]
[0003][09:49:42 525][ 0][ 0] SQL-EXECUTE-QUERY [31 ms]
SELECT TOP # * FROM memoList ORDER BY mdate DESC
param1:[10]
[0004][09:49:42 556][ 31][ 0] FETCH [10/10]
[0005][09:49:42 556][ 0][ 0] DB_CLOSE_CONNECTION (0x133d21d) [0 ms]
[0006][09:49:42 556][ 0][ 0] DB_OPEN_CONNECTION (0xbbea7b, Server=tcp:testdb.database.windows.net,1433;Database=udb;User ID=udbadmin@testdb;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;) [0 ms]
[0007][09:49:42 556][ 0][ 0] SQL-EXECUTE-QUERY [47 ms]
SELECT * FROM external WHERE aid=@aid
param2:[@aid=511]
[0008][09:49:42 603][ 47][ 0] FETCH [1/11]
[0009][09:49:42 603][ 0][ 0] DB_CLOSE_CONNECTION (0xbbea7b) [0 ms]
[0010][09:49:42 603][ 0][ 0] DB_OPEN_CONNECTION (0xdd6438, Server=tcp:testdb.database.windows.net,1433;Database=udb;User ID=udbadmin@testdb;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;) [0 ms]
[0011][09:49:42 603][ 0][ 0] SQL-EXECUTE-QUERY [31 ms]
SELECT * FROM fileattach WHERE aid=@aid AND bid=@bid
param2:[@bid=testbd,@aid=511]
[0012][09:49:42 634][ 31][ 0] FETCH [0/11]
[0013][09:49:42 634][ 0][ 0] DB_CLOSE_CONNECTION (0xdd6438) [0 ms]
[0014][09:49:42 634][ 0][ 0] DB_OPEN_CONNECTION (0x28934bc, Server=tcp:testdb.database.windows.net,1433;Database=udb;User ID=udbadmin@testdb;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;) [0 ms]
[0015][09:49:42 634][ 0][ 0] SQL-EXECUTE-QUERY [47 ms]
...[생략]...
[0016][09:49:42 681][ 47][ 0] DB_CLOSE_CONNECTION (0x28934bc) [0 ms]
[0017][09:49:42 681][ 0][ 0] DB_OPEN_CONNECTION (0x2f81fee, Server=tcp:testdb.database.windows.net,1433;Database=udb;User ID=udbadmin@testdb;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;) [0 ms]
[0018][09:49:42 681][ 0][ 0] SQL-EXECUTE-QUERY [31 ms]
...[생략]...
[0034][09:49:42 947][ 47][ 0] FETCH [1/40]
[0035][09:49:42 947][ 0][ 0] DB_CLOSE_CONNECTION (0xe02126) [0 ms]
[ ][09:49:42 947][ 0][ 0] END
---------------------------------------------------------------------------------------------------------------------
TOTAL[ 422][ 0]
SQL 쿼리 수행 시마다 매번 고정적으로 30~50ms 정도의 시간이 걸리는 것이 원인임을 알 수 있습니다.
원인을 명확하게 하기 위해, 다른 간섭이 없도록 코드를 다음과 같이 콘솔 형식으로 줄여 테스트를 해봤습니다.
using System;
using System.Configuration;
using System.Data.SqlClient;
using System.Diagnostics;
namespace ConsoleApp1
{
class Program
{
static string _sqlQuery = "SELECT TOP 10 * FROM memoList ORDER BY mdate DESC";
static void Main(string[] args)
{
Action<int, SqlConnection, Action<int, SqlConnection>> action = (loopCount, connection, work) =>
{
Stopwatch st = new Stopwatch();
st.Start();
work(loopCount, connection);
st.Stop();
Console.WriteLine(st.ElapsedMilliseconds);
};
using (SqlConnection connection = new SqlConnection())
{
connection.ConnectionString =
ConfigurationManager.ConnectionStrings["cloud"].ConnectionString;
connection.Open();
action(1, connection, RunCommand);
action(1, connection, RunCommand);
action(1, connection, RunCommand);
connection.Close();
}
}
private static void RunCommand(int loopCount, SqlConnection connection)
{
SqlCommand command = new SqlCommand();
command.Connection = connection;
command.CommandText = _sqlQuery;
int count = command.ExecuteNonQuery();
if (count == 0)
{
command.ExecuteNonQuery();
}
}
}
}
그러니까, SqlConnection은 열어두고 SqlCommand만 수행하는 시간만을 측정한 것인데, 다음과 같이 고정적으로 SQL 쿼리 수행에만 지연 시간이 발생하고 있습니다.
C:\temp\perf> ConsoleApp1.exe
38
37
37
제목에서도 밝히고 있었지만, 이 문제는 웹 응용 프로그램의 코드가 "Korea Central"에, 데이터베이스가 "East Asia"에 위치하고 있어서 발생한 문제였습니다. Connection 연결 시간이 아닌, SQL 쿼리 한 번 실행할 때마다 발생한다고 보면 생각보다 지연 시간이 꽤 긴데요, 그래서 Azure SQL Database를 웹 서버와 같은 위치인 "Korea Central"에 새롭게 생성/이전해 다시 테스트를 해보니,
C:\temp\perf> ConsoleApp1.exe
1
1
0
빠릅니다. ^^ 당연히 X-View에 보이는 응답시간도 바닥으로 쫙 깔리는 걸로 바뀌었고.
제 웹 사이트가 이런 식으로 Location이 다르게 구성된 이유는, 제가 Azure를 처음 접할 당시에는 "Korea Central"이 없던 시절이어서 "East Asia"로 웹/DB 서버가 구성이 되어 있었는데, 이후 실습을 위해
PaaS로 되어 있던 웹 서버를
IaaS 형식의 VM으로 바꾸면서 새롭게 "Korea Central" 지역으로 변경했기 때문입니다.
위의 결과를 조사하면서 Azure SQL Database에 대한 연결 방식이,
Azure SQL Database and Azure Synapse Analytics connectivity architecture
; https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-architecture
"Redirect"와 "Proxy" 방식이 있다는 것을 알게 되었습니다. 자신의 Azure SQL Database가 어떤 방식인지는 Azure Portal에서 해당 SQL 서버의 "Firewalls and virtual network" 설정을 통해 확인/변경할 수 있고,
또는
Azure CLI 명령어를 통해 "
az sql server conn-policy" 관련 명령어로 처리할 수도 있습니다. 대개의 경우 기본값인 "Default"일 텐데,
C:\Users\testusr> az sql server conn-policy show --resource-group udb_res --server testdb
{
"connectionType": "Default",
"id": "/subscriptions/B186197D-39D9-4776-B9A4-914535CA470E/resourceGroups/udb_res/providers/Microsoft.Sql/servers/testdb/connectionPolicies/default",
"kind": null,
"location": "East Asia",
"name": "default",
"resourceGroup": "udb_res",
"type": "Microsoft.Sql/servers/connectionPolicies"
}
명시적으로 설정하는 것도 가능합니다.
C:\Users\testusr> az sql server conn-policy update --connection-type Redirect --resource-group udb_res --server testdb
{
"connectionType": "Redirect",
"id": "/subscriptions/B186197D-39D9-4776-B9A4-914535CA470E/resourceGroups/udb_res/providers/Microsoft.Sql/servers/testdb/connectionPolicies/default",
"kind": null,
"location": null,
"name": "default",
"resourceGroup": "udb_res",
"type": "Microsoft.Sql/servers/connectionPolicies"
}
그런데, 저게 딱히 어떤 효과가 있는지는 모르겠습니다. 가령, "Redirect"로 설정해 두면,
Redirect (recommended): Clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput.
(상식적으로 생각했을 때) "proxy" 방식을 지원하지 않아 외부에서의 연결이 안 되어야 할 텐데 (테스트 해보면) 여전히 잘 됩니다. 즉, "Default"와 "Redirect"의 설정 차이가 없다는 것입니다. (혹시 아시는 분은 덧글 부탁드립니다. ^^)
참고로
문서를 보면, Azure에서 제공하는 Gateway IP 주소 목록을 모두 공개하고 있습니다. 그래서 Azure SQL Database의 연결 문자열에 명시한 서버 DNS 이름을 ping으로 확인해 보면,
C:\Users\testusr> ping testdb.database.windows.net
Pinging koreacentral1-a.control.database.windows.net [52.231.32.42] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 52.231.32.42:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
출력되는 IP(52.231.32.42)를 통해 "Korea Central"임을 알 수 있습니다.
개인적으로 Azure에서 좀 불편한 점이 있다면 서비스에 대한 "Location"을 자유롭게 바꿀 수 없다는 점입니다. 물론 서비스가 대용량화되면 Location 이전이 쉽지 않은 것은 당연하겠지만, 그래도 Azure Portal 내에서의 기능으로 제공해도 (어차피 대용량이면 과금을 추가하는 식으로 구현해도 되므로) 좋을 듯한데, 그게 없어서 대부분 수작업으로 직접 해야 합니다.
Azure DB도 마찬가지인데요, 예전에 했던 방식과,
Azure 데이터베이스를 로컬 DB로 이전하는 방법
; https://www.sysnet.pe.kr/2/0/1667
크게 달라진 점은 없습니다. 제 경우에는 그냥 bacpac 파일로 "East Asia"의 DB 파일을 export하고, 다시 그 bacpac 파일을 "Korea Central"의 DB로 import하는 방식으로 처리했습니다. 또한, DB 사용자를 추가하는 등의 작업은 SSMS를 통해도 여전히 SQL 쿼리를 다뤄야 하는 식입니다. 예를 들어, 로그인 사용자를 추가하는 것도,
Adding Users to Azure SQL Databases
; https://www.mssqltips.com/sqlservertip/5242/adding-users-to-azure-sql-databases/
우선 DB 서버 수준에서 추가한 후,
CREATE LOGIN [udbadmin]
WITH PASSWORD = [...암호...]
그 사용자를 데이터베이스마다 권한을 부여하는 식으로 처리해야 합니다.
CREATE USER [udbadmin]
FOR LOGIN [udbadmin]
WITH DEFAULT_SCHEMA = dbo;
-- add user to role(s) in db
ALTER ROLE db_datareader ADD MEMBER [udbadmin];
ALTER ROLE db_datawriter ADD MEMBER [udbadmin];
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]