Aurora and RDSでのAurora PostgreSQL を用いたDB作成手順

こんにちは、合田と申します。 

突然ですが、Aurora and RDSを用いてDBを作成しようとしたことはありますか？ 

いざ作成しようとしてみると、たくさんの設定項目があり尻込みしてしまいます。 

そこで今回は、Aurora PostgresSQLを用いたDB標準作成時の設定項目を上から順に網羅的に説明していきます。(セキュリティ部分の詳細は説明しています。) 

最初に標準作成を選択し、エンジンはAurora(PostgreSQL Compatible)を使用します。 

次にエンジンバージョンの指定をします。 

【エンジンのバージョン指定】 

エンジンのバージョンを指定します。基本的に新しいバージョンでは、パフォーマンス改善や新しいSQL機能やデータ型、ストレージの効率化などが追加され、セキュリティ修正も施されています。なので、こだわりや既存アプリとの互換性を考える必要がないのであれば、最新のメジャーバージョンのデフォルトを使うことをお勧めします。 

メジャーバージョンのデフォルトとはAurora PostgreSQL のバージョン選択時に表示される「メジャーバージョンのデフォルト」という表記は、そのメジャーバージョン（15系、16系など）における、セキュリティパッチやバグ修正が含まれた、AWSが推奨する最新の安定サブバージョンを意味しています。逆にデフォルトではないものは古いマイナーバージョンであり、バグが残っている可能性があります。 

ここで見慣れないRDS延長サポートの有効化というものが出てきます。 

新しめのバージョンを使っている場合あまり意識せずオフのままで大丈夫です。 

【RDS延長サポートの有効化】 

RDSは、PostgreSQLやMySQLなどのオープンソースDBエンジンに基づいており、これらのデータベースにはそれぞれサポート期間があります。サポート期間を過ぎたバージョンはAWSのRDSでも利用できなくなります。しかし、互換性の関係で古いバージョンを使い続けなければいけない場合があり、それを可能にするサービスが延長サポートです。 

延長サポートは、サポートが終了したRDSエンジンの古いバージョンを、延長期間中も引き続き利用できるようにする有料オプションです。AWSが正式サポートを終えた後も、セキュリティパッチなどの重要なアップデートを受け取れるようにする仕組みです。 

本番稼働用か開発/テスト用か選択して下さい。以下に詳細をまとめています。 

DBクラスターの名前を決めてください。同じ名前のクラスターを２つ以上作ることはできないのでお気を付けください。 

【DBクラスター識別子】 

DBクラスター識別子は、Auroraクラスター内のDBインスタンス群を識別するために使用される一意の名前です。これを用いて、複数のAuroraクラスターやインスタンスを区別し、特定のクラスターのパラメータやセキュリティ設定を変更したり、スケールアウトやスケールインを実行したりします。 

次に管理者ユーザーの名前を設定しましょう。 

【マスターユーザー名】 

最初に作成される管理者ユーザーの名前のことです。このユーザーは、データベースへの接続や初期設定を行うための管理者権限を持ったユーザーです。後から変更できません。 

その下で、承認情報の管理方法を選択してください。こだわりが無ければデフォルトで大丈夫です。 

I/Oとは、Input/Outputの略で、ストレージとの間でデータを読み書きする操作を意味します。以下にAurora I/O-最適化とAurora スタンダードの違いをまとめます。 

【クラスターストレージ設定】 

I/Oが多いかどうかで選択をすればよいと思います。 

例えば読み取り中心のwebサイトなどではAurora スタンダードを選択し、 頻繁にI/Oを行うECサイトなどではAurora I/O-最適化を選択します。 

以下に、具体的な例をもとにAurora スタンダードとAurora I/O-最適化の損益分岐点(Aurora スタンダードとAurora I/O-最適化の金額が等しくなるI/Oの回数)をを示します。選択の参考にしてください。(記事を書いた時点での料金を参考にしています。) 

(設定) 

インスタンス：db.r6g.large 

稼働時間：720時間(1か月) 

ストレージ：100GiB 

リージョン：東京 

この状況下で1か月I/Oを行わずに運用したときの両者の差額は$23.38となります。 

日本円にすると約3,500円ほどAurora スタンダードの方が安くなります。 

ここで、I/Oを考えクエリの回数による損益分岐点を計算すると月に約1億1700万回、 1日あたりだと約 389万回となります。 

4つのクラスの中から自身に最適なものを選んでください。 

以下に特徴をまとめます。 

【インスタンス設定】 

たくさん書きましたが、簡単にまとめると 

最も柔軟性が高い → Serverless v2 

本番で安定稼働させたい → メモリ最適化クラス 

コストを抑えたい  → バースト可能クラス 

読み込みを分散したい  → 読み取り最適化クラス 

となります。 

次にマルチAZに対する設定を行います。 

【マルチAZ配置】 

可用性を高めるために別のAZにAuroraのレプリカを配置するかどうかを選択してください。 

開発・試用運転でないならばAurora のレプリカを作成しておきましょう。 

【コンピューティングリソース】 

RDBとEC2インスタンスを接続するかを選択してください。 

EC2上に作成したアプリケーションなどからAuroraに接続する必要があるユースケースを考えています。 

もし、長時間処理を要するバックエンドや特定のOSやライブラリが必要な処理を必要としないのであれば、EC2を使わず、AWS LambdaをRDS Proxyを用いてAuroraに接続、仮想サーバー（EC2）を使わずにコンテナベースのFargateでアプリを実行してAuroraと連携することでアイドルコストを無くすことが可能です。 

【ネットワークタイプ】 

IPv4のみを運用するかIPv4とIPv6を同時に運用するかを選択してください。 

デュアルスタックモードは、IPv4のアドレス枯渇問題を解決するために設計されており、IPv6に移行している現在に適しているモードです。 

どちらを選んでも金額が変わらないため、既存インフラがIPv4に依存していないならばデュアルスタックモードを利用しましょう！ 

【Virtual Private Cloud】 

RDBを設置するVPCと、そのサブネットグループを選択してください。 

因みにDBは必ずVPCに設置する必要があります。 

S3やAmazon Lambdaのようにそれ単体で稼働することはできません。 

セキュリティに対する設定を行う項です。Aurora　and RDSのシステムに直接関係がある項ではないので、詳細な説明は省きます。こだわりが無ければデフォルトの設定で大丈夫です。 

【パブリックアクセス】 

DBインスタンスをインターネット上からアクセス可能にするかどうかを選択して下さい。検証・開発で一時的に外部接続が必要などの特殊なケースでないかぎり、セキュリティリスクがとても高くなるのでパブリックアクセスは無しにしておきましょう。 

【セキュリティ】 

セキュリティグループやサーバー証明書の設定を行ってください。 

リードレプリカは、DBクラスターにおける読み取り専用のコピーインスタンスです。通常、書き込みはライターインスタンスにのみ可能で、リードレプリカは読み取り専用として扱われます。読み込み負荷を分散させる目的で使われます。 

書き込み転送とはリードレプリカに届いた書き込みクエリ（INSERT、UPDATE、DELETEなど）を自動的に Writer インスタンスに転送する機能です。 

【リードレプリカの書き込み転送】 

リードレプリカの書き込み転送を有効にするかを選択して下さい。接続先を一本化して運用し、負荷分散しながら書き込みもできる状態にしたいなら有効に、書き込みと読み取りを明確に分離しセキュリティを重視したいのであれば無効にしておきましょう。 

次はタグの設定です。タグとは、リソースに付けられる名前付きラベルのことです。主にリソースの分類・整理・管理などを目的として使われます。 

【タグ】 

タグは「キー（Key）」と「値（Value）」のセットで構成されます。 

例 

Key: Environment     → Value: Production 

Key: Owner           → Value: Sato 

Key: Project         → Value: WebApp 

タグに紐づけてIAMポリシーを付与したり、タグごとのソート、タグの有無によってLambdaの起動のトリガーにすることが可能です。 

次はbabelfishの説明です。特殊なユースケースでのみ使われるサービスですが、Aurora RDSではこのようなこともできるのだという新しい知見が得られると思いますので、ぜひ説明に目を通してみてください! 

【Babelfish】 

Babelfish は「SQL Server語 ⇔ PostgreSQL語 の通訳」 のような道具であり、SQL Server 向けに作られたアプリケーションをAurora PostgreSQL 上で動かすことができる互換レイヤーです。SQL Server（マイクロソフトの有料DB）は定額性で割高です。もし社内でSQL Serverを用いたシステムを運用している場合にBabelfishを用いると、少ない仕様変更でPostgreSQLに変更でき、従量課金制になることでコストダウンをはかれます。 

データベース認証はデータベースへのセキュリティやアクセス制御を強化するために用います。 

【データベース認証】 

データベース認証は、DBにアクセスできるユーザーやアプリケーションを識別し、どの操作を許可するかを選択してください。パスワードによる認証はデフォルトでオンになっていますが、別の認証方法が必要な場合は追加してください。 

DBに特化したモニタリングサービスです。上手く活用して運用効率化に役立ててください。 

【モニタリング】 

Amazon RDS Performance Insights は、DBのパフォーマンスをリアルタイムで監視し、クエリの実行状況やリソースの使用状況を詳細に分析できるツールです。CPU使用率やディスクI/O、待機イベントなど、さまざまなメトリクスを可視化でき、クエリの最適化やリソースの調整に役立ち運用の効率を高めるために効果的です。過去のパフォーマンスデータを表示でき、過去のパフォーマンスの問題を追跡できます。 

本記事ではモニタリングの項と追加設定の項の詳細を省きます。様々な詳細な設定ができるため必要に応じて設定をしてください！ 

最後に全体の設定の見直しと概算の月間コストを確認し、問題が無ければデータベースの作成を押してください。これで無事データベースを作成することができました！