【Amazon RDS】タイムゾーンのベストプラクティスってなんだ？

2024.12.05

この記事をシェアする

はじめに

はじめまして！
クラウドビルダーズのKawabataと申します。

「RDSのタイムゾーンのベストプラクティスって何ですか？」

先日、あるお客様からこんな質問を受けました。日本のシステムなんだから日本時間にするのが自然…そう思いますよね？
でも、ちょっと待ってください！実は、この何気ない設定が後々大きな問題を引き起こす可能性があるんです。

今回は、私が実際に調査して分かった「RDSのタイムゾーン設定のベストプラクティス」について、できるだけ分かりやすく解説していきます。

結論

Amazon RDSにおけるタイムゾーン設定のベストプラクティスは以下の通りです：

データベースレイヤーでは、デフォルトのUTC（協定世界時）を使用する
必要に応じて、アプリケーションレイヤーでタイムゾーンの変換を行う

理由

UTCをデータベースレイヤーで使用することを推奨する理由は以下の通りです：

夏時間（DST）の問題回避 🕒

UTCは夏時間の影響を受けないため、時刻の自動調整による問題が発生しない
データの一貫性が保たれる

2. グローバル展開の容易さ 🌏

世界中どの地域でもUTCを基準に時刻を管理できる
異なるタイムゾーン間での時刻の計算が容易

3. システムの保守性向上 🛠

単一のタイムゾーンで管理することで、システムの複雑性が低減
デバッグや障害対応が容易になる

「えっ！そんなところにも影響が？」

日本に住んでいると夏時間に触れる機会がないため、そんなところに弊害があるとは考えたこともなかったですね。

実は私も最初は「国内向けのサービスだからJSTでいいじゃん」と思っていました。が、調べてみると「UTCの方が良さそうだな…」と感じました。

上記理由だけを鑑みると国内展開しか考えていないアプリに関してはJSTでも問題なさそうですが、今後のデータ利用の拡張性も考えるとUTCで設定していくのが無難そうですね。

RDSでのタイムゾーンの設定方法

各データベースエンジンでのタイムゾーン設定方法を紹介します

Amazon Aurora

クラスターパラメータグループでタイムゾーンパラメータを設定
Aurora MySQL: time_zoneパラメータを使用
Aurora PostgreSQL: timezoneパラメータを使用
設定変更後、クラスター内のすべてのインスタンスに適用

注意点:

新しい接続から変更が反映
既存の接続は一度切断して再接続する必要あり
クロスリージョンレプリケーション使用時は、レプリカ側のパラメータグループでも設定が必要

Aurora MySQL

Aurora PostgreSQL

MySQL/MariaDB

カスタムパラメータグループで設定が可能
パラメータグループ名を押した後に、右上の編集を押す
time_zoneを検索してパラメータ値を入力した後、右上の変更を保存を押す
設定変更後、すべてのDBインスタンスとリードレプリカに適用

MySQL

MariaDB

PostgreSQL

カスタムパラメータグループで設定可能
パラメータグループ名を押した後に、右上の編集を押す
timezoneを検索してパラメータ値を入力した後、右上の変更を保存を押す
設定変更後、すべてのDBインスタンスとリードレプリカに適用

PostgreSQL

Oracle

オプショングループで設定可能
オプショングループ名を押した後、オプションの追加を押す
以下を設定してオプションの追加を押す:
– オプション名: TIMEZONE
– タイムゾーン: 任意のタイムゾーン
– すぐに適用: 任意のものを選択

Microsoft SQL Server

インスタンス作成時のみ設定可能
追加設定のタイムゾーンで設定できる

おわりに

データベースのタイムゾーン設定は、一度設定すると変更が困難な場合があり、システム設計の初期段階で十分な検討が必要です

ベストプラクティスとして、以下の方針を推奨します：

データベースはUTCで統一的に管理
タイムゾーンの変換はアプリケーションレイヤーで実施

これらの方針に従うことで、より保守性が高く、グローバルで展開しやすいシステムを構築することができそうですね

参考資料

Amazon RDS DBインスタンスのタイムゾーン変更