메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon Aurora 개요

Amazon Aurora(Aurora)는 완전 관리형이면서 PostgreSQL 및 MySQL과 호환되는 관계형 데이터베이스 엔진입니다. 이 관계형 데이터베이스 엔진은 고급 상용 데이터베이스의 속도 및 안정성과 오픈 소스 데이터베이스의 경제성 및 단순성을 모두 갖추고 있습니다. 대부분 기존 애플리케이션을 변경하지 않고 그대로 사용하더라도 처리량이 MySQL 처리량에 비해 최대 5배, 그리고 PostgreSQL의 처리량에 비해 최대 3배까지 증가합니다.

Aurora는 MySQL 및 PostgreSQL 배포판에 대한 설정, 조작 및 확장이 간편하고 비용 효율적이기 때문에 비즈니스와 애플리케이션에 더욱 많은 시간을 투자할 수 있습니다. Amazon RDS는 프로비저닝, 패치, 백업, 복구, 결함 감지, 수리 등 일상적인 데이터베이스 작업을 처리할 수 있는 Aurora 관리 기능을 지원합니다. 또한 Amazon RDS는 기존 MySQL 애플리케이션용 Amazon RDS와 PostgreSQL 애플리케이션용 Amazon RDS를 Aurora로 전환할 수 있는 푸시 버튼식 마이그레이션 도구도 제공합니다.

Amazon Aurora는 MySQL 및 PostgreSQL을 즉시 대체할 수 있는 엔진입니다. 오늘날 기존 MySQL 및 PostgreSQL 데이터베이스에 사용되는 코드, 도구 및 애플리케이션 모두 Amazon Aurora에서도 사용할 수 있습니다.

Amazon Aurora 인스턴스를 생성하면 DB 클러스터가 만들어집니다. DB 클러스터는 하나 이상의 DB 인스턴스와 이 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Aurora 클러스터 볼륨은 다중 가용 영역을 모두 아우르는 가상 데이터베이스 스토리지 볼륨으로서, 각 가용 영역에는 DB 클러스터 데이터의 사본이 복사됩니다. Aurora DB 클러스터는 다음과 같이 두 가지 유형의 DB 인스턴스로 구성됩니다.

  • 기본 인스턴스 – 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 변경을 실행합니다. 각 Aurora DB 클러스터마다 기본 인스턴스가 하나씩 있습니다.

  • Aurora 복제본 – 읽기 연산만 지원합니다. 각 Aurora DB 클러스터는 기본 인스턴스에 더하여 최대 15개까지 Aurora 복제본을 구성할 수 있습니다. 다수의 Aurora 복제본이 읽기 워크로드를 분산시키면 Aurora 복제본을 별도의 가용 영역으로 이동시켜 데이터베이스 가용성을 높이는 것도 가능합니다.

다음은 클러스터 볼륨과 Aurora DB 클러스터에 속하는 기본 인스턴스 및 Aurora 복제본 사이의 관계를 나타낸 다이어그램입니다.

 Amazon Aurora 아키텍처

가용성

AWS 리전에서 Amazon Aurora 가용성은 데이터베이스 엔진 호환성에 따라 다릅니다.

데이터베이스 엔진 가용성

Amazon Aurora MySQL

Amazon Aurora MySQL 가용성섹션을 참조하십시오.

Amazon Aurora PostgreSQL

Amazon Aurora PostgreSQL 가용성섹션을 참조하십시오.

Aurora 엔드포인트

Amazon Aurora DB 클러스터의 DB 인스턴스는 엔드포인트를 사용하여 연결할 수 있습니다. 여기에서 엔드포인트란 호스트 주소와 포트가 콜론으로 구분되어 있는 URL을 말합니다. Aurora DB 클러스터에서 제공하는 엔드포인트는 다음과 같습니다.

클러스터 엔드포인트

DB 클러스터의 현재 기본 인스턴스에 연결되는 Aurora DB 클러스터 엔드포인트입니다. Aurora DB 클러스터는 각각 클러스터 엔드포인트가 1개씩 있습니다.

이러한 클러스터 엔드포인트는 DB 클러스터에 대한 읽기/쓰기 연결 시 장애 조치를 지원합니다. DB 클러스터의 현재 기본 인스턴스에 장애가 발생하면 Aurora가 자동으로 새로운 기본 인스턴스로 장애 조치합니다. 장애 조치가 이루어지는 동안에도 DB 클러스터가 클러스터 엔드포인트에 대한 새로운 기본 인스턴스의 연결 요청을 처리하여 서비스 중단 시간을 최소화합니다.

다음은 Aurora MySQL DB 클러스터의 클러스터 엔드포인트를 나타낸 예제입니다.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

리더 엔드포인트

DB 클러스터에서 사용할 수 있는 Aurora 복제본 중 하나에 연결되는 Aurora DB 클러스터 엔드포인트입니다. Aurora DB 클러스터는 각각 리더 엔드포인트가 1개씩 있습니다.

리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결 시 로드 밸런싱을 지원합니다. DB 클러스터는 사용 가능한 Aurora 복제본 사이에서 연결 요청을 리더 엔드포인트에게 분산시킵니다. DB 클러스터에 기본 인스턴스만 포함된 경우에는 리더 엔드포인트가 기본 인스턴스의 연결 요청을 처리합니다. 이때 해당 DB 클러스터에 Aurora 복제본이 생성되더라도 리더 엔드포인트가 리더 엔드포인트에 대한 새로운 Aurora 복제본의 연결 요청을 계속해서 처리하여 서비스 중단 시간을 최소화합니다.

다음은 Aurora MySQL DB 클러스터의 리더 엔드포인트를 나타낸 예제입니다.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

인스턴스 엔드포인트

특정 DB 인스턴스에 연결되는 Aurora DB 클러스터의 DB 인스턴스 엔드포인트입니다. DB 클러스터의 DB 인스턴스에는 인스턴스 유형에 상관없이 각각 고유한 인스턴스 엔드포인트가 있습니다.

클러스터 엔드포인트 또는 리더 엔드포인트의 사용이 부적합한 시나리오에서는 인스턴스 엔드포인트가 DB 클러스터에 대한 연결을 직접 제어합니다. 예를 들어 클라이언트 애플리케이션에 연결이 아닌 읽기 워크로드를 기준으로 로드 밸런싱이 필요한 경우도 있습니다. 이때는 읽기 워크로드를 분산시킬 목적으로 다수의 클라이언트를 구성하여 DB 클러스터의 여러 Aurora 복제본에 연결할 수 있습니다. 장애 조치 후 인스턴스 엔드포인트를 사용하여 연결 속도를 높이는 예제는 Amazon Aurora PostgreSQL을 사용한 빠른 장애 조치 단원을 참조하십시오.

다음은 Aurora MySQL DB 클러스터의 DB 인스턴스 엔드포인트를 나타낸 예제입니다.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

엔드포인트 고려 사항

Aurora 엔드포인트 작업 시 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 인스턴스 엔드포인트를 사용하여 DB 클러스터의 특정 DB 인스턴스에 연결하는 것보다는 클러스터 엔드포인트나 리더 엔드포인트를 DB 클러스터에 사용하는 것이 좋습니다.

    클러스터 엔드포인트와 리더 엔드포인트는 고가용성 시나리오를 지원합니다. DB 클러스터의 기본 인스턴스에 장애가 발생하면 Aurora가 자동으로 새로운 기본 인스턴스로 장애 조치합니다. 이때는 기존 Aurora 복제본을 새로운 기본 인스턴스로 승격시키거나, 혹은 기본 인스턴스를 새롭게 생성하는 방법이 있습니다. 장애 조치가 발생하면 클러스터 엔드포인트를 사용하여 새롭게 승격되거나 생성된 기본 인스턴스에 다시 연결하거나, 혹은 리더 엔드포인트를 사용하여 DB 클러스터에서 나머지 Aurora 복제본 중 하나에 다시 연결할 수 있습니다.

    위와 같은 방법을 사용하지 않더라도 DB 클러스터에서 올바른 DB 인스턴스에 계속해서 연결하여 원하는 작업을 실행할 수 있습니다. 이를 위해서는 수동으로 또는 프로그래밍 방식으로 DB 클러스터에서 사용 가능한 DB 인스턴스의 결과 집합을 가져와서 장애 조치 이후부터 특정 DB 인스턴스의 인스턴스 엔드포인트를 사용하기 전까지 인스턴스 유형을 확인하면 됩니다.

    장애 조치에 대한 자세한 내용은 Aurora DB 클러스터의 내결함성 단월을 참조하십시오.

  • 리더 엔드포인트는 Aurora DB 클러스터에서 사용 가능한 Aurora 복제본 연결에 한해 로드 밸런싱을 적용합니다. 쿼리를 로드 밸런싱하여 DB 클러스터에 대한 읽기 워크로드를 분산시키려는 경우 애플리케이션에서 이 작업을 관리하고, 인스턴스 엔드포인트를 사용하여 해당하는 Aurora 복제본에 직접 연결해야 합니다.

  • 장애 조치 중 리더 엔드포인트는 Aurora 복제본이 기본 인스턴스로 새롭게 승격되는 짧은 시간 동안 DB 클러스터의 새로운 기본 인스턴스에 직접 연결할 수 있습니다.

Amazon Aurora 스토리지

Aurora 데이터는 솔리드 스테이트 디스크(SSD) 드라이브를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장됩니다. 클러스터 볼륨은 동일한 리전에 속한 다중 가용 영역의 데이터 사본으로 구성되어 있습니다. 이러한 가용 영역에서 데이터가 자동으로 복제되기 때문에 데이터 손실 가능성은 줄고 오히려 내구성이 크게 높아집니다. 이러한 복제를 통해 데이터 사본이 이미 나머지 가용 영역에 존재하여 DB 클러스터의 인스턴스에 대한 데이터 요청을 처리할 수 있다는 점에서 장애 조치 중에도 데이터베이스의 가용성이 높아집니다.

데이터베이스의 데이터 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장됩니다. 확장할 수 있는 Aurora 클러스터 볼륨의 최대 크기는 64테라바이트(TB)입니다. 테이블 크기는 클러스터 볼륨 크기로 제한됩니다. 즉 Aurora DB 클러스터의 테이블에 대한 최대 크기는 64TB입니다. Aurora 클러스터 볼륨은 최대 64TB까지 증가할 수 있지만 요금은 Aurora 클러스터 볼륨에서 사용한 공간에 대해서만 청구됩니다. 요금에 대한 자세한 내용은 Aurora용 Amazon RDS 요금을(를) 참조하십시오.

Amazon Aurora 복제

Aurora 복제본은 Aurora DB 클러스터에 있는 독립적인 엔드포인트입니다. DB 클러스터 볼륨 데이터에 대해서는 읽기 전용 액세스가 가능합니다. 여러 복제 인스턴스에서 데이터 관련 읽기 작업의 규모를 조정하여 데이터 읽기 성능과 Aurora DB 클러스터의 데이터 가용성을 모두 향상시킬 수 있습니다. Aurora 복제본은 장애 조치 대상이기도 하며 Aurora DB 클러스터의 기본 인스턴스가 실패하는 경우 신속히 승격됩니다.

Aurora 복제본 및 Aurora DB 클러스터의 데이터 복제와 관련된 기타 옵션에 대한 자세한 내용은 Amazon Aurora를 사용한 복제 단원을 참조하십시오.

Amazon Aurora 안정성

Aurora는 안정성, 내구성 및 내결함성을 고려하여 설계되었습니다. Aurora DB 클러스터는 Aurora 복제본을 추가하여 다른 가용 영역에 배포하는 등의 방법으로 가용성을 높이도록 설계할 수 있습니다. 그 밖에도 Aurora에는 안정적인 데이터베이스 솔루션을 위한 자동 기능이 몇 가지 포함되어 있습니다.

스토리지 자동 복구

Aurora는 3개의 가용 영역에 데이터 사본을 다수 배포하기 때문에 디스크 결함으로 인한 데이터 손실 가능성이 최소화됩니다. Aurora가 클러스터 볼륨을 구성하는 디스크 볼륨에서 결함을 자동 감지합니다. 예를 들어 디스크 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구합니다. Aurora가 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능합니다. 결과적으로 Aurora는 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어듭니다.

유지 가능한 캐시 워밍

Aurora는 전원이 꺼진 데이터베이스를 가동하거나 결함 발생 이후 다시 시작할 때 버퍼 풀 캐시를 "워밍"합니다. 즉, Aurora가 인 메모리 페이지 캐시에 저장된 기존 공통 쿼리 페이지를 이용해 버퍼 풀을 미리 로드합니다. 이 경우 일반적인 데이터베이스 사용과 달리 버퍼 풀의 "웜 업" 필요성을 우회할 수 있기 때문에 성능이 향상되는 이점이 있습니다.

Aurora 페이지 캐시는 데이터베이스가 아닌 별도의 프로세스를 통해 관리되기 때문에 데이터베이스와 상관없이 유지됩니다. 예상과 달리 데이터베이스에 결함이 발생하더라도 페이지 캐시가 메모리에 남아있기 때문에 데이터베이스를 재시작할 때 버퍼 풀이 가장 최신 상태로 워밍됩니다.

충돌 복구

Aurora는 거의 실시간으로 충돌을 복구하여 애플리케이션 데이터를 지속적으로 처리할 수 있도록 설계되었습니다. Aurora가 비동기 방식으로 병렬 스레드에서 충돌 복구를 실행하기 때문에 충돌 직후에도 데이터베이스를 열어두고 사용할 수 있습니다. 자세한 내용은 Aurora DB 클러스터의 내결함성 단원을 참조하십시오.

Amazon Aurora 성능 개선 사항

Amazon Aurora에는 고급 상용 데이터베이스의 다양한 필요를 지원하는 성능 향상이 포함되어 있습니다.

Amazon Aurora MySQL 성능 개선 사항

Aurora MySQL은 다음과 같이 성능이 개선되었습니다.

빠른 입력 기능

빠른 입력 기능은 기본 키에 의해 정렬되는 병렬 입력을 빠르게 처리해 주며, 특히 LOAD DATAINSERT INTO ... SELECT ... 문 사용 시 유용합니다.

Aurora MySQL의 성능 개선 사항에 대한 자세한 내용은 Amazon Aurora MySQL 성능 개선 사항 단원을 참조하십시오.

Amazon Aurora 보안

Amazon Aurora 보안은 다음과 같이 세 가지 수준에서 관리됩니다.

  • Aurora DB 클러스터 및 DB 인스턴스에 대한 Amazon RDS 관리 작업자를 통제하려면 AWS Identity and Access Management(IAM)를 사용합니다. IAM 자격 증명을 사용하여 AWS에 연결할 때는 Amazon RDS 관리 작업에 필요한 권한을 부여할 수 있는 IAM 정책이 IAM 계정에 반드시 필요합니다. 자세한 내용은 Amazon RDS에 대한 인증 및 액세스 제어 단원을 참조하십시오.

    IAM 계정을 사용해 Amazon RDS 콘솔에 액세스하려면 먼저 IAM 계정으로 AWS Management Console에 로그인한 다음 https://console.aws.amazon.com/rds에서 Amazon RDS 콘솔로 이동합니다.

  • Aurora DB 클러스터는 Amazon Virtual Private Cloud(VPC)에서 생성해야 합니다. VPC에서 Aurora DB 클러스터에 대한 DB 인스턴스의 엔드포인트 및 포트에 연결할 수 있는 디바이스와 Amazon EC2 인스턴스를 제어하려면 VPC 보안 그룹을 사용합니다. 이 엔드포인트와 포트는 Secure Sockets Layer(SSL) 방식으로 연결할 수 있습니다. 그 밖에도 기업의 방화벽 규칙을 통해 기업에서 이용하는 디바이스의 DB 인스턴스 연결 여부를 제어하는 것도 가능합니다. VPC에 대한 자세한 내용은 Amazon Virtual Private Cloud(VPC) 및 Amazon RDS 단원을 참조하십시오.

  • Amazon Aurora DB 클러스터에 대한 로그인 및 권한을 인증하기 위해서는 다음 접근 방식 중 하나를 따르거나 두 방식을 조합할 수 있습니다.

    • 독립형 MySQL 또는 PostgreSQL 인스턴스와 동일한 접근법을 사용할 수 있습니다.

      SQL 명령을 사용하거나, 데이터베이스 스키마 테이블을 수정하는 등 독립형 MySQL 또는 PostgreSQL 인스턴스에서 로그인 및 권한을 인증하는 기법이 Aurora에서도 유효합니다. 자세한 내용은 Amazon Aurora MySQL 보안. 또는 Amazon Aurora PostgreSQL 보안 단원을 참조하십시오.

    • 또한 Aurora MySQL에 IAM 데이터베이스 인증을 사용할 수도 있습니다.

      IAM 데이터베이스 인증의 경우, IAM 사용자 또는 IAM 역할 및 인증 토큰을 이용해 Aurora MySQL DB 클러스터에 인증합니다. 인증 토큰은 서명 버전 4 서명 프로세스를 통해 생성하는 고유 값입니다. IAM 데이터베이스 인증을 사용하면 동일한 자격 증명을 사용해 AWS 리소스 및 데이터베이스에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 MySQL 및 Amazon Aurora를 위한 IAM 데이터베이스 인증 섹션을 참조하십시오.

SSL을 이용한 Aurora 데이터 보안

Amazon Aurora DB 클러스터는 Amazon RDS DB 인스턴스와 동일한 프로세스 및 퍼블릭 키를 사용하여 애플리케이션의 Secure Sockets Layer(SSL) 연결을 지원합니다. 자세한 내용은 Amazon Aurora MySQL 보안. 또는 Amazon Aurora PostgreSQL 보안 단원을 참조하십시오.

Amazon Aurora DB 클러스터의 현지 시간대

기본적으로 Amazon Aurora DB 클러스터의 시간대는 협정 세계시(UTC)입니다. 대신 DB 클러스터의 인스턴스 시간대를 애플리케이션의 현지 시간대로 설정할 수 있습니다.

DB 클러스터의 현지 시간대를 설정하려면 DB 클러스터의 클러스터 파라미터 그룹에서 time_zone 파라미터를 이 단원의 뒤에 나오는 지원되는 값 중 하나로 설정합니다. DB 클러스터에 대한 time_zone 파라미터를 설정하면 DB 클러스터의 모든 인스턴스가 새로운 현지 시간대를 사용하도록 변경됩니다. 다른 Aurora DB 클러스터가 동일한 클러스터 파라미터 그룹을 사용하면 해당 DB 클러스터의 모든 인스턴스도 새로운 현지 시간대를 사용하도록 변경됩니다. 클러스터 수준 파라미터에 대한 자세한 내용은 Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터 단원을 참조하십시오.

현지 시간대를 설정하면 데이터베이스에 대한 모든 새 연결에 변경 사항이 반영됩니다. 현지 시간대를 변경할 때 데이터베이스에 대해 열린 연결이 있는 경우 연결을 닫고 새 연결을 열어야 현지 시간대 업데이트가 표시됩니다.

리전 간 복제를 사용 중인 경우 복제 마스터 DB 클러스터와 복제본이 서로 다른 파라미터 그룹을 사용합니다. 파라미터 그룹은 리전에 고유합니다. 각 인스턴스에 대해 동일한 현지 시간대를 사용하려면 복제본 마스터와 복제본 모두의 파라미터 그룹에서 time_zone 파라미터를 설정해야 합니다.

DB 클러스터 스냅샷에서 DB 클러스터를 복원할 경우 현지 시간대가 UTC로 설정됩니다. 복원이 완료된 후 시간대를 현지 시간대로 업데이트할 수 있습니다. DB 클러스터를 특정 시점으로 복원할 경우 복원된 DB 클러스터의 현지 시간대는 복원된 DB 클러스터의 파라미터 그룹에서 설정한 시간대입니다.

현지 시간대를 다음 표에 나열된 값 중 하나로 설정할 수 있습니다. 일부 시간대의 경우 표에 설명된 대로 특정 날짜 범위 시간 값이 잘못 보고될 수 있습니다. 호주 시간대의 경우 표에 설명된 대로 반환된 시간대 약어가 만료된 값입니다.

시간대

참고

Africa/Harare

시간대 설정이 1903년 2월 28일 21:49:40 GMT에서 1903년 2월 28일 21:55:48 GMT까지 잘못된 값을 반환할 수 있습니다.

Africa/Monrovia

Africa/Nairobi

시간대 설정이 1939년 12월 31일 21:30:00 GMT에서 1959년 12월 31일 21:15:15 GMT까지 잘못된 값을 반환할 수 있습니다.

Africa/Windhoek

America/Bogota

시간대 설정이 1914년 11월 23일 04:56:16 GMT에서 1914년 11월 23일 04:56:20 GMT까지 잘못된 값을 반환할 수 있습니다.

America/Caracas

America/Chihuahua

America/Cuiaba

America/Denver

America/Fortaleza

America/Guatemala

America/Halifax

시간대 설정이 1918년 10월 27일 05:00:00 GMT에서 1918년 10월 31일 05:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

America/Manaus

America/Matamoros

America/Monterrey

America/Montevideo

America/Phoenix

America/Tijuana

Asia/Ashgabat

Asia/Baghdad

Asia/Baku

Asia/Bangkok

Asia/Beirut

Asia/Calcutta

Asia/Kabul

Asia/Karachi

Asia/Kathmandu

Asia/Muscat

시간대 설정이 1919년 12월 31일 20:05:36 GMT에서 1919년 12월 31일 20:05:40 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Riyadh

시간대 설정이 1947년 3월 13일 20:53:08 GMT에서 1949년 12월 31일 20:53:08 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Seoul

시간대 설정이 1904년 11월 30일 15:30:00 GMT에서 1945년 9월 7일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Shanghai

시간대 설정이 1927년 12월 31일 15:54:08 GMT에서 1940년 6월 2일 16:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Singapore

Asia/Taipei

시간대 설정이 1937년 9월 30일 16:00:00 GMT에서 1979년 9월 29일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Tehran

Asia/Tokyo

시간대 설정이 1937년 9월 30일 15:00:00 GMT에서 1937년 12월 31일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Ulaanbaatar

Atlantic/Azores

시간대 설정이 1911년 5월 24일 01:54:32 GMT에서 1912년 1월 1일 01:54:32 GMT까지 잘못된 값을 반환할 수 있습니다.

Australia/Adelaide

이 시간대의 약어는 ACDT/ACST가 아닌 CST로 반환됩니다.

Australia/Brisbane

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Australia/Darwin

이 시간대의 약어는 ACDT/ACST가 아닌 CST로 반환됩니다.

Australia/Hobart

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Australia/Perth

이 시간대의 약어는 AWDT/AWST가 아닌 WST로 반환됩니다.

Australia/Sydney

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Brazil/East

Canada/Saskatchewan

시간대 설정이 1918년 10월 27일 08:00:00 GMT에서 1918년 10월 31일 08:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Europe/Amsterdam

Europe/Athens

Europe/Dublin

Europe/Helsinki

시간대 설정이 1921년 4월 30일 22:20:08 GMT에서 1921년 4월 30일 22:20:11 GMT까지 잘못된 값을 반환할 수 있습니다.

Europe/Paris

Europe/Prague

Europe/Sarajevo

Pacific/Auckland

Pacific/Guam

Pacific/Honolulu

시간대 설정이 1933년 5월 21일 11:30:00 GMT에서 1945년 9월 30일 11:30:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Pacific/Samoa

시간대 설정이 1911년 1월 1일 11:22:48 GMT에서 1950년 1월 1일 11:30:00 GMT까지 잘못된 값을 반환할 수 있습니다.

US/Alaska

US/Central

US/Eastern

US/East-Indiana

US/Pacific

UTC