DB 서버가 해외에 있을 때 발생 가능한 실수

2018년 11월 기준, 국내 외산 데이터센터 현황은 다음과 같다.

2016년 1월 (설립) – AWS
2017년 2월 (설립) – MS
2019년 5월 (예정) – Oracle
2019년 중   (추진) – Google

외산 클라우드 솔루션을 사용 시 데이터센터가 해외에 위치할 경우,
쿼리 과정에서 식별한 (사소하지만 critical한) 문제가 있어 공유한다.

타겟팅 추출하는 과정에서 현 시간 날짜 속성을 자주 사용한다.
가령 ‘최근 2주’라는 조건이 있다고 가정해보자.

참고사항으로
1. 데이터센터의 소재지는 한국과 16시간 차이나는 미국이며
2. 클라우드 솔루션의 VM이 데이터센터와 같은 곳에 위치해있다.
3. 달력을 보니 오늘 날짜가 2018년 5월 1일이다.

이 경우 쿼리는 다음과 같이 구성할 수 있다.

WHERE …. 날짜컬럼 BETWEEN SYSTIMESTAMP-14+16/24 AND SYSTIMESTAMP+16/24

(참고사항 2번으로 인해 CURRENT_TIMESTAMP와 SYSTIMESTAMP는 같으므로
SYSTIMESTAMP 대신 CURRENT_TIMESTAMP를 사용해도 결과는 같다)

문제가 없어 보인다. 문제를 찾으려고 하지 않을 만큼 매우 쉬운 쿼리다.

자, 이제 몇 달이 흘러 11월 28일이다. 쿼리 결과를 다시 확인해보았다.

그런데?

1시간이 오차가 있는 것이다. 왜일까?

Summer Time을 고려하지 않아서이다. 다음은 2018년 기준 미국 LA의 Summer Time 적용 시간 변화다.

LA_SUMMER_TIME

맨 처음 쿼리가 작성된 시점이 PDT (UTC-7h)이고, 마지막으로 쿼리 결과를 확인한 시점이 PST (UTC-9h)이다.  이 Summer Time 적용을 고려했을 때, 쿼리는 다음과 같이 수정되어야 한다.

수정 전
WHERE …. 날짜컬럼 BETWEEN SYSTIMESTAMP-14+16/24 AND SYSTIMESTAMP+16/24

수정 후
WHERE …. 날짜컬럼 BETWEEN SYS_EXTRACT_UTC(SYSTIMESTAMP)-14+9/24 AND SYS_EXTRACT_UTC(SYSTIMESTAMP)+9/24

 

결론
국가 간 시간 차를 반영할 때 표준시간을 기준으로 생각하고
SYS_EXTRACT_UTC() function을 사용하자!

 

참고
https://www.timeanddate.com/time/zone/usa/los-angeles

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중