RDSとはAWSが提供しているマネージド型リレーショナルデータベースです。RDSを使用することによりユーザは
・プロビジョニング
・パッチの適用
・バックアップ
・リカバリ
・障害検知
・リペア
などのデータベースに関する多くの処理から解放され、アプリケーション開発に注力することが可能となります。設定自体は画面上のマネージメントコンソールをぽちぽちやっていくだけでできちゃうのでとても簡単なのですが、初めてデータベースを立てるよ！ って方は少し困惑しちゃう場面もあると思うので今回は順を追って言葉の概念や意味を理解しながらデータベースを立ててみましょう。
自社のサービスではPostgreSQLを採用しているので、今回はそれにあわせたデータベース設定を行っていこうと思います。
新規データベース作成は右上にあるような、オレンジ色の「データベース作成」というボタンを押すことで始めることができ、下のような各種設定の画面に遷移します。
標準作成か簡単作成かの選択を行います。それぞれのサービスごとに適した細かい設定を行うために標準作成にします。
エンジンのタイプには
・Amazon Aurora
・MySQL
・mariaDB
・PostgreSQL
・Oracle
・Microsoft SQL Server
の６つが用意されています。今回、使用したものはAmazon Auroraです。
AuroraはMySQLとPostgreSQLに互換性があるクラウド向けに構築されたリレーショナルデータベースであり、Amazonが独自に構築したものです。
公式によると、Amazon Aurora は標準的な MySQL データベースと比べて最大で5倍、標準的な PostgreSQL データベースと比べて最大で3倍高速とのことなので、MySQLやPostgreSQLを使う人はぜひ積極的にAuroraを使っていきましょう！
エンジンのタイプでAuroraのMySQLに互換性があるタイプかPostgreSQLに互換性があるタイプかを選択します。今回PostgreSQLのデータベースを立ち上げたいということだったので下のPostgreSQLとの互換性を持つ Amazon Auroraを選択します。
キャパシティをユーザが明示的にプロビジョニングおよび管理を行うのか、Aurora Serverlessを使い、サービス側に自動的なスケーリングを任せるのかを選択します。
Aurora Serverlessを選択するとサービス側でアプリケーションニーズに応じて自動的に
・起動
・シャットダウン
・キャパシティを拡大または縮小
などをしてくれます。
つまりアプリケーションへのアクセスに波がある場合、使用されていない時間は自動的にキャパシティを縮小したりシャットダウンされるのでコスト面でメリットがあります。また、新規のアプリケーションのようなどの時間帯やシチュエーションで負荷が集中するのかが明確にわからない場合にも自動的にそのときに適したスケーリングを行ってくれるので便利です。
Aurora Serverlessを選択すると以下のような設定画面が表示され、ACUの最小と最大を設定する必要があります。
Aurora ServerlessはACUという単位でスケーリングを行い、それに応じて料金も設定されます。
ACUとはAurora Capacity Unitの略です。各 ACU では、約2GB のメモリ、対応する CPU、およびネットワーキングの組み合わせとなっています。
なお、Aurora ServerlessではACUでリソースを管理するので、以降でインスタンスクラスの選択はありません。
今回は自社の環境に合わせて、プロビジョニング済みを選択しています。
エンジンのバージョンを設定します。
グローバルデータベース機能をサポートするバージョンを表示というtoggleボタンがありますが、これをオンにするとグローバルデータベースに対応したバージョンのみが下のプルダウンメニューに表示されるようになります。
グローバルデータベースとは何か？ ですが、単一の Amazon Aurora データベースを複数の AWS リージョンにまたがって運用できるというもので、リージョン規模の停止からの災害復旧を行うことができます。
グローバルデータベースには以下のような特徴があり、可用性を大いに高めることが期待できます。
・セカンダリリージョンに通常1秒未満のレイテンシ(要求を出してからレスポンスが返ってくるまでの遅延時間)でストレージベースのレプリケーションが可能
・万が一プライマリリージョンに障害が起こった場合でも読み取り/書き込みを実行するようセカンダリリージョンの1つを1分以内に昇格させることが可能
本番稼働用と開発/テストがありますが、今回は本番環境を対象としたものなので本番稼働用を選択します。
違いとしては以降で設定するパラメータのデフォルト値が異なってくる点です。(各環境で推奨のものがすでに選択された状態になっている)本番稼働用を選択した場合
・マルチAZ
・プロビションドIOSP(ストレージオプション)
・削除保護の有効化
がすでに選択された状態になります。
・DBクラスター識別子
DBクラスターの名前を入力します。
・マスターユーザ名
ログインする際に使用するユーザ名を入力します。
・マスターパスワード
ログインする際に使用するパスワードを入力します。
キャパシティータイプでプロビジョニング済みを選択した場合、要件に適したDBインスタンスクラスを選択する必要があります。
上のプルダウンメニューでdb.r5.largeなどの表記でインスタンスクラスが記載されていますが、db.以下はそれぞれの特性に応じた記載となっています。
db.r5.largeの場合ならr5の部分がインスタンスタイプを表し、largeの部分がインスタンスサイズを表しています。インスタンスタイプはr系のほかにもm系、t系など様々な用途にあった種類がありますが、今回はメモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されているメモリ最適化インスタンスに属するr系を使います。後方の数字は世代を表しており数字が大きくなるほど最新のバージョンです。
さらにdb.r6g.largeのような世代の数字の後ろにgのような文字がついているタイプもありますがこれは追加機能を表しています。例えばgならばAWS Gravitonプロセッサ(最良のコストパフォーマンスを提供)搭載を示しています。
またインスタンスサイズですが、わかりやすくいうとスペックを表しており画像で言うと
large < xlarge < 2xlarge < 4xlarge < ・・・
の順にCPUコアの数やメモリのサイズなどのリソース量が増えていきます。
以上のことを踏まえて自分のアプリケーションに適したインスタンスクラスを選択しましょう。
ラジオボタンの選択肢にバースト可能クラス(tクラスを含む)とありますが、バースト可能クラスを使用することである特定の負荷のかかる場面のみCPUの機能をフルに活用させて、その他のときにはCPUの機能を抑え低いコストで運用するということが可能となります。
バースト可能クラスの各インスタンスにはベースラインが設定されており、そのベースラインを下回るリソースの使用率の場合、CPUクレジットというものが蓄積されます。ベースラインを上回る場合にはCPUクレジットを消費する代わりにベースライン以上の機能を使用可能になるという仕組みです。
もちろんCPUクレジットが枯渇するとCPUの使用率に制限がかかったり、追加料金がかかったりするので適したシュチュエーションで使用すればコスト面を低く抑えることができますが使用には注意しましょう。
Auroraレプリカをプライマリとは別のAZ(アベイラビリティーゾーン)に作成するかを選択します。
レプリカとは読み込み専用のDBのことを指し、プライマリインスタンスの内容を同期的にレプリカにも反映させることによって同じ内容のデータベースを複数存在させることができます。読み込みはレプリカに任せることで個々のサーバの負荷を減らしたり、万が一、プライマリに障害が起こった時にレプリカがあればすぐさま復旧させることが可能となります。
AZは各リージョン内の複数の独立した場所であり、レプリカを別の場所に分散させることで高可用性を実現します。
・Virtual Private Cloud
環境に合わせた適切なVPCを選択します。
・サブネットグループ
適切なサブネットグループを選択します。
・パブリックアクセス可能
セキュリティーの観点から基本的にはなしを選択することになると思います。
・VPCセキュリティグループ
適切なセキュリティーグループを選択します。
・データベースポート
データベースポートを指定します。
デフォルトは PostgreSQL の標準的な ポート番号5432が設定されています。
・IAM database authentication
これにチェックすることでIAM認証でRDSに接続できるようになります。
・Kerberos認証
これにチェックすることでKerberos認証でRDSに接続できるようになります。「Kerberos」はサーバーとクライアント間の身元確認のために使用するプロトコルです。
さらに追加設定の項目に入っていきましょう！
・最初のデータベース名
データベースの名前を設定します。
・DBクラスターのパラメータグループ
適切なDBクラスターのパラメータグループを設定します。
パラメータグループとはDBに適応されるパラメータの集合のことです。
例えば、タイムゾーンの設定や文字コードの設定はパラメータグループを編集することで設定することができます。
DBクラスターのパラメータグループでは設定されたパラメータグループがDBクラスター全てにおいて適応されます。優先度としては下のDBパラメータグループの方が高く、DBクラスターのパラメータグループより優先されますが、DBパラメータグループにおいてデフォルトのパラメータはDBクラスターのパラメータグループが適応されます。
・DBパラメータグループ
DBインスタンスのパラメータグループを設定します。
・フェイルオーバー優先順位
フェイルオーバーとはプライマリインスタンスに障害などがおこり機能しなくなったときにレプリカを代わりにプライマリへと昇格させることです。ここで優先順位を設定しておくことで任意のレプリカを優先的に昇格させることができます。
0に近い数字ほど優先順位が高くなります。
・バックアップ保持期間
バックアップの保持期間を選択します。
1日~35日まで選択可能です。
・スナップショットにタグをコピー
ここにチェックすることでスナップショットにタグを含めたコピーを行ってくれます。
・暗号を有効化
DBインスタンスを暗号化し、データ保護を強化します。
・マスターキー
暗号を施すためのマスターキーを選択します。
Amazon RDS Performance Insights はデータベースパフォーマンスのチューニングとモニタリングを行う機能です。グラフでデータベースの状態を可視化することによって負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。
・保持期間
データを保持する期間は7日(デフォルト)と2年から選択できます。
・マスターキー
データを暗号化するマスターキーを選択します。
拡張モニタリングの有効化にチェックをいれるとDB インスタンスが実行されているOS のリアルタイムのメトリクス(システムのパフォーマンスに関するデータ)をコンソールを通して見ることが可能となります。拡張モニタリングメトリクスはCloudWatch Logs に無制限、または1 日間～10 年間の間で任意の期間保存できます。詳細度ではメトリクスが収集される間隔 (秒単位) を設定できます。モニタリングロールはメトリクスをCloudWatch Logsに送る際に使用するロールです、とくに何もしないとデフォルトで作成されます。
複雑なサービスではなく、気軽にRDSにデータベースを立ち上げてみたいという場合にはとくにチェックをつける必要はないと思います。
・マイナーバージョン自動アップグレードの有効化
これにチェックを入れておくとデータベースエンジンの新しいマイナーバージョンが利用可能になったときにデータベースを自動的にアップグレードしてくれます。マイナーバージョンとはちょっと追加機能ついたりバグ直して進化しましたよ的なバージョンアップですね。今までの仕様と互換性がある変更のみです。
チェックを付けない場合、手動でバージョンアップする必要があります。
・メンテナンスウィンドウ
選択ウィンドウをチェックすることでメンテナンスなどの開始時間を明示的に設定することができます。サービスの特徴に合わせて適切な時刻に更新が行われるようにしておきましょう。
・削除保護の有効化
誤ってデータベースを消してしまわないようにこの欄にチェックを入れておきましょう。データベースを削除したい時はこのチェックを外さないと削除することはできません。
今回はRDSでのデータベース立ち上げ設定を簡単にではありますが順を追って説明していきました。
一つひとつのワードの意味を追っていくと結構な情報量となりますがどれも大切な概念なので少しでも理解が進む助けになればと思います！
※2021年3月19日時点
