メニュー
Amazon Relational Database Service
ユーザーガイド (API バージョン 2014-10-31)

Amazon Aurora の概要

Amazon Aurora (Aurora) は、MySQL および PostgreSQL と互換性がある、完全マネージド型のリレーショナルデータベースエンジンです。ハイエンドの商用データベースの処理速度や信頼性だけでなく、オープンソースデータベースの簡素性やコスト効率をあわせ持っています。既存のほとんどのアプリケーションへの変更を必要とすることなく、MySQL のスループットの 5 倍、PostgreSQL のスループットの 3 倍を実現します。

Aurora では MySQL や PostgreSQL のデプロイを簡単に、コスト効率よく設定、操作、スケーリングできるため、ユーザーは業務やアプリケーションに専念できます。Amazon RDS では、データベースのプロビジョニング、パッチ適用、バックアップ、復旧、障害検出、修復などのルーチンタスクを処理することで Aurora を管理します。Amazon RDS には、既存の Amazon RDS for MySQL および Amazon RDS for PostgreSQL アプリケーションを Aurora に変換するための押しボタン式の移行ツールも用意されています。

Amazon Aurora は、MySQL および PostgreSQL のドロップインリプレースメントです。既存の MySQL および PostgreSQL データベースで現在使用しているコード、ツール、アプリケーションを Amazon Aurora でも使用できます。

Amazon Aurora インスタンスを作成すると、DB クラスターが作成されます。DB クラスターは、1 つ以上の DB インスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されます。Aurora クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリュームです。各アベイラビリティーゾーンには DB クラスターデータのコピーが格納されます。Aurora DB クラスターは 2 種類の DB インスタンスで構成されます。

  • プライマリインスタンス – 読み取りと書き込みの操作をサポートし、クラスターボリュームに対するすべてのデータ変更を実行します。各 Aurora DB クラスターには 1 つのプライマリインスタンスがあります。

  • Aurora レプリカ – 読み取りオペレーションのみをサポートします。各 Aurora DB クラスターは、プライマリインスタンスに加えて 15 Aurora までのレプリカを持つことができます。複数の Aurora レプリカは読み取りワークロードを分散し、別のアベイラビリティーゾーンの Aurora レプリカを検索することでデータベースの可用性を高めることもできます。

次の図は、Aurora DB クラスター内のクラスターボリューム、プライマリインスタンス、および Aurora レプリカの関係を示しています。

 Amazon Aurora アーキテクチャ

現在利用できるリージョン

Amazon Aurora に関する AWS リージョンの可用性は、データベースエンジンの互換性によって異なります。

データベースエンジン 現在利用できるリージョン

Amazon Aurora MySQL

Amazon Aurora MySQL の可用性」を参照してください。

Amazon Aurora PostgreSQL

Amazon Aurora PostgreSQL の可用性」を参照してください。

Aurora エンドポイント

エンドポイントを使用して Amazon AuroraDB クラスターの DB インスタンスに接続できます。エンドポイントは、ホストアドレスとポートを含む URL です。次のエンドポイントは、Aurora DB クラスターから取得できます。

クラスターエンドポイント

クラスターエンドポイントとは、DB クラスターの現在のプライマリインスタンスに接続する Aurora DB クラスターのエンドポイントです。Aurora DB クラスターごとに 1 つのクラスターエンドポイントと 1 つのプライマリインスタンスがあります。

クラスターエンドポイントは、DB クラスターへの読み取り/書き込み接続のフェイルオーバーサポートを提供します。クラスターエンドポイントは、DB クラスターのすべての書き込みオペレーション (挿入、更新、削除、データ定義言語 (DDL) の変更など) で使用します。クラスターエンドポイントは、クエリなどの読み取りオペレーションでも使用できます。

DB クラスターの現在のプライマリインスタンスが失敗した場合、Aurora は新しいプライマリインスタンスに自動的にフェイルオーバーします。フェイルオーバー中、DB クラスターは、新しいプライマリインスタンスからクラスターエンドポイントへの接続リクエストに継続して対応し、サービスの中断は最小限に抑えられます。

次の例では、Aurora MySQL DB クラスターのエンドポイントを示します。

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

読み取りエンドポイント

読み取りエンドポイントとは、DB クラスターで利用できる Aurora レプリカの 1 つに接続する Aurora DB クラスターのエンドポイントです。各 Aurora DB クラスターに読み取りエンドポイントがあります。複数の Aurora レプリカがある場合、読み取りエンドポイントは各接続リクエストを Aurora レプリカのいずれかに振り向けます。

読み取りエンドポイントは、DB クラスターへの読み取り専用接続のロードバランシングサポートを提供します。読み取りエンドポイントは、クエリなどの読み取りオペレーションで使用します。読み取りエンドポイントを書き込みオペレーションで使用することはできません。

DB クラスターは使用可能な Aurora レプリカ間の読み取りエンドポイントに接続リクエストを分散します。DB クラスターにプライマリインスタンスのみが含まれている場合、読み取りエンドポイントはプライマリインスタンスからの接続リクエストに対応します。Aurora レプリカが DB クラスターに対して作成された場合、読み取りエンドポイントは、新しい Aurora レプリカから読み取りエンドポイントへの接続リクエストに引き続き対応し、サービスの中断は最小限に抑えられます。

次の例では、Aurora MySQL DB クラスターの読み取りエンドポイントを示します。

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

インスタンスエンドポイント

インスタンスエンドポイントは、特定の DB インスタンスに接続する Aurora DB クラスターの DB インスタンス用のエンドポイントです。DB クラスターの各 DB インスタンスには、インスタンスタイプにかかわらず、独自のインスタンスエンドポイントがあります。したがって、DB クラスターの現在のプライマリインスタンスに対する 1 つのインスタンスエンドポイントがあり、DB クラスターの Aurora レプリカごとに 1 つのインスタンスエンドポイントがあります。

インスタンスエンドポイントは、クラスターエンドポイントや読み取りエンドポイントの使用が適切でないシナリオ向けに、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 (Solid State Disk) ドライブを利用する単一の仮想ボリュームであるクラスターボリュームに保存されます。クラスターボリュームは、単一リージョンの複数のアベイラビリティーゾーン間のデータのコピーで構成されます。データはアベイラビリティーゾーン間で自動的にレプリケートされるため、データ損失の可能性は低く、耐久性は非常に高くなります。このレプリケーションは、フェイルオーバー中のデータベースの可用性をさらに高めることも保証します。その理由は、データのコピーは既に他のアベイラビリティーゾーンに存在し、DB クラスター内のインスタンスに対するデータ要求を処理し続けるためです。

Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームは、最大 64 テビバイト (TiB) のサイズまで増やすことができます。テーブルサイズの上限はクラスターボリュームのサイズです。つまり、Aurora DB クラスター内のテーブルの最大テーブルサイズは 64 TiB です。Aurora クラスターボリュームは 64 TiB まで拡大できますが、Aurora クラスターボリュームで使用する領域に対してのみ料金が請求されます。料金表については、「Amazon RDS の Aurora 料金表」を参照してください。

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 クラスターの耐障害性」を参照してください。

以下に示しているのは、Aurora MySQL のバイナリログ記録とクラッシュ復旧に関する考慮事項です。

  • Aurora でバイナリログ記録を有効にすると、クラッシュ後の復旧時間に直接影響を与えます。これは、DB インスタンスで強制的にバイナリログ復旧が実行されるためです。

  • 使用するバイナリログ記録のタイプは、ログ記録のサイズと効率に影響を与えます。データベースアクティビティの量が同じでも、バイナリログの形式によって記録される情報の量が異なります。binlog_format パラメータの以下の設定により、ログデータの量が異なることになります。

    • ROW — ログデータの量が最も多い。

    • STATEMENT — ログデータの量が最も少ない。

    • MIXED — ログデータの量が中程度。通常、データ整合性とパフォーマンスのバランスが最も良くなります。

    バイナリログデータの量は復旧時間に影響を与えます。バイナリログに記録されているデータが多いほど、DB インスタンスが復旧中に処理するデータが多くなり、復旧時間が長くなります。

  • Aurora では、DB クラスター内でデータをレプリケートしたり、特定時点への復元 (PITR) を実行したりするために、バイナリログは不要です。

  • 外部レプリケーション (または外部バイナリログストリーム) にバイナリログが不要な場合は、binlog_format パラメータを OFF に設定して、バイナリログ記録を無効にすることをお勧めします。これにより、復旧時間が短くなります。

Aurora バイナリログ記録とレプリケーションの詳細については、「Amazon Aurora とのレプリケーション」を参照してください。さまざまな MySQL レプリケーションタイプの影響の詳細については、MySQL のドキュメントの「ステートメントベースおよび行ベースのレプリケーションの利点と欠点」を参照してください。

Amazon Aurora パフォーマンスの拡張

Amazon Aurora には、ハイエンドな商用データベースのさまざまなニーズをサポートするパフォーマンス拡張機能があります。

Amazon Aurora MySQL パフォーマンスの拡張

Aurora MySQL には、以下のパフォーマンスの拡張が含まれています。

高速挿入

高速挿入は、プライマリキーによってソートされた並列挿入を加速し、特に LOAD DATA および INSERT INTO ... SELECT ... ステートメントに適用されます。

Aurora MySQL のパフォーマンスの拡張の詳細については、「Amazon Aurora MySQL パフォーマンスの拡張」を参照してください。

Amazon Aurora のセキュリティ

Amazon Aurora のセキュリティは次の 3 つのレベルで管理されます。

  • Aurora DB クラスターと DB インスタンスに対する Amazon RDS 管理アクションを実行できるユーザーを管理するには、AWS Identity and Access Management (IAM) を使用します。IAM 認証情報を使用して AWS に接続するとき、IAM アカウントには、Amazon RDS の管理オペレーションを実行するためのアクセス権限を付与する IAM ポリシーが必要です。詳細については、「Amazon RDS に対する認証とアクセスコントロール」を参照してください。

    IAM アカウントを使用して Amazon RDS コンソールにアクセスする場合は、IAM アカウントで AWS マネジメントコンソールにログオンした後、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 (VPCs) と 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 データベース認証」を参照してください。

Aurora DB クラスターでの SSL の使用

Amazon Aurora DB クラスターは、アプリケーションからの Secure Sockets Layer (SSL) 接続を、Amazon RDS DB インスタンスと同じプロセスとパブリックキーを使用してサポートします。詳細については、「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