お蔵入りにしてた記事 『AWS Database Specialtyに合格したのでAuroraについてまとめた + RDSの思わぬ欠点について』
もったいないので放出します。2023年の9/29合格なので、約一年前ですね。そのまま出します。当時のライブ感が残っていて懐かしい。思えばこれがSAP,DOP,MLSなどの合格の発端となりました。
当時の合格時のヴァイブスは以下です。
対象読者は、
・DBSの範囲の問題を多少解いてSAAなど他試験の解像度をあげたい方
・Auroraについて気になる方
・RDSなどAWSのDB系のサービスについて学びたい方
などです
それでは、
以下が当時の記事です。
受かりました
わーい。
初のSpecialty合格なので嬉しいです。
DBS試験はオススメです。
受かったことで、AWSのDBについての解像度が上がりました!
たとえば、以下のような感じです。
XXX「オンプレdbからRDS+Auroraへの移行を考えてるんですよ~」
受かる前「DMSを使うっぽいな」
受かった後「DMSで移行するとして、ソースとターゲットはどこにある?LOBの有無は?また、CDCとフルロードはどのように使い分ける？」
解像度が上がってるのがわかりますね。
Auroraの解像度も上がった。
試験ではAurora,RDS,Dynamodb,Elasticash,DMSが出まくります。
Auroraの特徴って他の試験(SAA,DVA,SOA,SAPなど)では、あまり出題されなく、知らないものが多くありましたが今回キャッチアップできました。
AWS公式から抜粋すると、以下のような特徴があります。
・Aurora Replica
・Aurora Serverless
・Auroraグローバルデータベース
・クロスリージョンレプリケーション
・Aurora マルチマスタークラスター(書き込みができるクラスターの複製)
・Aurora Auto Scaling
・バックトラック機能
・障害挿入クエリ
・データベースアクティビティストリーム
・Aurora MySQLからLambda関数の呼び出し
・高度な監査(Advanced Auditing)
・クラスターキャッシュ機能(フェイルオーバー時にキャッシュを引き継ぐ)
など
これらの内、黒字にした4つを抜粋して、DBSの問題を通して解説します。
RDSと違う、というのがこの4つに共通するポイントです。
また、実践面で役立つ知識が得られたのも良かったです。
以下で、DBSの問題を中心に、
解像度、実践面、
という観点から、説明していきます。
１. Aurora Replica (詳しめなのでスキップ可）
XXX「RDSのリードレプリカみたいな感じで、Auroraのリードレプリカも使えるよね。」
受かる前「できます！(たぶん。知らんけど）」
XXX「複製しとけばOK？」
受かる前「OKです！！！」
受かった後「Auroraは、AuroraReplicaがありますが、これはRDSのリードレプリカとは似ているようんで違います。細かい仕様は省略しますが。また、複製ということですが、クローン機能はありますが、それはAurora Repolicaとは全く別で、その辺理解されてますか?また、フェイルオーバーどうやってさせるかとか見えてますか？」
//長いので、ここだけ別記事にすることも検討中なので、読み飛ばしていただいても大丈夫です。
レプリカってリードレプリカ？RDSにもあるじゃん、
と思いますが、Auroraのレプリカは、2つの役割があります。
リードレプリカに加えて、スタンドバイインスタンスの役割も果たすことができるのです。
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.77 より
公式の引用をすると、
Aurora レプリカには主な目的が 2 つあります。これらにクエリを発行することで、アプリケーションの読み取り操作をスケールできます。これは、通常はクラスターのリーダーエンドポイントに接続することで行われます。これにより、Aurora は、読み取り専用の接続負荷を、クラスター内にある Aurora レプリカと同じ数だけ分散できます。Aurora レプリカは、可用性の向上にも役立ちます。クラスター内のライターインスタンスが使用できなくなると、Aurora はリーダーインスタンスのうちの 1 つを自動的に昇格させ、新しいライターとして機能させます。
とあります。
リードレプリカだけでなく、
可用性の向上にも使えるのですね。
レプリカはフェイルオーバーや、読み込み負荷分散のために便利ですよね。
（ただし、レプリカさせた分はそれだけ料金が加算されてしまいます)
ところでレプリカとは何でしょうか？
レプリケーションとは？で検索すると、レプリケーションとは複製のことです。
というようなトートロジーな説明が出てきます。
微妙な語感ですが、似たような言葉にクローンがあります。
クローンではなく、レプリケーションなのです。
一旦ですが、簡単に、説明します。
・クローンの例
Aのクローンをつくる。A'が生まれる。
Aが変化するがその変化がA'に反映されるわけではない。
・レプリケーションの例
AのレプリケーションA’をつくる。
Aが変化すると、それに合わせて、A'も変化する。
理解を深めるために、次の例題を見ましょう。
例題1.
問題32 Amazon Aurora DB クラスターを本番稼働させています。新しい要件として予測できない読み取り負荷が発生するグループウェアアプリケーションがクライアントとして追加されます。 グループウェアアプリケーションがアクセス可能なデータにはDBインスタンスへの書き込みから100ミリ秒未満のレイテンシーが要求されます。 これらの要件を最小限のダウンタイムで満たすことができるソリューションはどれでしょう。
A. Amazon Aurora Auto Scaling設定を有効にして、CPU利用率をターゲットメトリクスにしてAmazon Auroraレプリカ数を調節する。
B. Amazon Aurora Serverless設定を有効にして、ワークロードに合わせたオンデマンドオートスケーリングを実行する。
C. Amazon Aurora DBクラスターのクローンをワークロードに合わせて作成して負荷分散する。
D. Amazon Aurora グローバルデータベースを使用して、マルチリージョンでレイテンシーを低減して、読み取りを高速化する。
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.321より
ポイントはCの選択肢を外せるか、です。Cは何故ダメなのでしょうか。
負荷分散させるという点では、Cは実現できている選択肢に見えます。
一方、
アクセス可能なデータにはDBインスタンスへの書き込みから100ミリ秒未満のレイテンシーが要求
これがクローンさせただけでは、実現できません。
クローンさせる、だけでは、クローン元の変化がクローン先には反映されないためです。
最新の更新が反映されないクローンを永遠と見に行くという悲しいことになりますね。
ここで、レプリカが必要となるのです。
Auroraのクローン作製機能のユースケースは、本番環境からテスト環境用のDBを作成する場合などです（この場合だと、本番環境DBの修正がテスト環境には反映されませんが問題ないですよね。）
このようなことから、正解はAとなります。
Bの選択肢は、次の章で説明しますので、ここでは割愛しますが、ここでの回答にはなりません。
Dのグローバルデータベースも要件を満たすことが可能ですが、グローバル展開の要件がないので、
オーバースペックとなり、コスト面で不適です。
また前述したように、Auroraでは、これがリードレプリカとしてだけではなく、
フェイルオーバー用のレプリカとしても使用できます。
DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。
※9
RDSでもこれは可能なのですが、RDSの場合だと、手動で対応する必要があります。
また、RDSでは、リードレプリカを昇格させるのではなく、スタンドバイインスタンスの利用が推奨されます。
Auroraは自動でのフェイルオーバーが可能になります。
このあたりは、レプリケーションの種類について理解することがカギになります。
自分も理解しきれていないのですが、次のQiita記事がレプリケーションの種類について、かなり掘り下げていて、参考になりました。
Qiita記事:RDSレプリケーションの同期、非同期についてまとめました
Aurora replicaは同期レプリケーションに近いものなので、リードレプリカとしてだけではなくスタンドバイインスタンスとしての活用もできるようですね。
ここは自分も深堀しきれていない部分なのですが、参考までに以下の公式の予想問題とその答え、解説をここに転載することで、一旦は完結させます。
自分は、以下の過去問は、RDSリードレプリカは、災害対策には使いにくく非推奨なんだな、くらいの理解で、正答を丸暗記しました。実戦的にはこれで良いかもしれません。
公式問題なので、当日出題される可能性があります。
例題2.
(9) ある企業の顧客関係管理アプリケーションで、マルチ AZ 配置の Amazon RDS for PostgreSQL データベースを使用しています。データベースサイズは約 100 GB です。データベース専門家が、費用対 効果の高いディザスタリカバリ計画を策定するよう求められています。このディザスタリカバリ計画の内容 は、データベースを 2 時間以内に別のリージョン内に復元するというものです。また、復元後のデータベー スにおいて、トランザクションデータが失われてもよい時間を 8 時間以内に抑える必要があります。 最も費用対効果の高い方法でこれらの可用性要件を満たすには、どうすればよいですか。
A) RDS のリードレプリカを第 2 リージョン内に作成する。ディザスタリカバリ時、このリードレプ
リカをスタンドアロンインスタンスに昇格させる。
B) RDS のリードレプリカを第 2 リージョン内に作成する。その際、インスタンスサイズを元のデー
タベースよりも小さくする。ディザスタリカバリ時、このリードレプリカをスケーリングし、また、
スタンドアロンインスタンスに昇格させる。
C) データベースインスタンスのスナップショットを 1 時間ごとに作成する AWS Lambda 関数を作成
し、スケジューリングする。そのスナップショットを第 2 リージョンにコピーする Lambda 関数
を別途作成し、スケジューリングする。ディザスタリカバリ時、最新のスナップショットからマルチ
AZ 配置の新しい RDS データベースインスタンスを作成する。
D) マルチ AZ 配置の新しい RDS データベースインスタンスを第 2 リージョンに作成する。継続的に
レプリケートするよう、AWS DMS タスクを構成する。
解説
(9) C — バックアップ/復元は、RTO 要件 (2 時間) と RPO 要件 (8 時間) を満たすための、最も費用対
効果の高い方法です。データベースの新規作成時に使用できるようにするため、1 時間ごとに手動で作成し
たスナップショットを、第 2 リージョンにコピーする必要があります。1 時間ごとにスナップショットを
作成すれば、増分スナップショットサイズを小さくし、リージョン間でスナップショットをコピーする際の
時間を短縮して、RPO 要件を満たすことができます。スナップショットを頻繁に作成しても、コストへの影
響はありません。スナップショットを作成して第 2 リージョンにコピーするよう、2 つの AWS Lambda
関数をスケジューリングできます。
※AWS 認定データベース — 専門知識
AWS Certified Database – Specialty
(DBS-C01) 認定試験の質問例 より
A、Bダメなんだ。。。と、驚きますよね。RDSではなく、Aurora replicaならA,Bが可能です。
２. Aurora Serverless
XXX「Aurora Serverlessって機能使いたい」
受かる前「サーバレス？オーロラってサーバレスじゃん。使うっしょ」
受かった後「Aurora Serverlessは、動的にスケーリングさせられるサービス。けどユースケースが限られてるけど大丈夫？動的なスケーリングが必要なだけでは、採用するには至らなかったりする。その辺確認できてますか？」
この機能によって、Auroraのパフォーマンスを自動で調整できます。
Auroraを、オンデマンドでスケーリングする機能です。
このような機能を持ったサイズ指定不要のAuroraインスタンスを作成できます。
Aurora Serverlessの仕組み
動的な自動スケーリングをどのように実現しているか。
これは、小さなAuroraのキャパシティ単位である、Auroraキャパシティユニット(ACU)と
呼ばれる単位を増減することにより、自動スケーリングが実現されています。
※ 『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.87 より
ユースケースとしては、
・開発環境
・アクセスがかなり少ないサイト（アクセス数が少ないブログなど）
・可変負荷なアプリケーション 予測が不可な活動のピーク（ニュースサイトなど）
※AWS BlackBelt Aurora MySQL slide 34 より
以下の例題を見ていきましょう。
例題3.
問題40. 複数のチームが１つのAmazon Aurora MySQL DBクラスターを共有して開発環境用データベースとして使用しています。 各チームごとに用意されたDBクラスターは日中のみ使用され、読み込みと書き込みに必要とされるパフォーマンスは各チームの日々の作業によって異なります。 この利用状況の条件を満たしながら、コストを削減できる最も費用対効果の高いソリューションはどれでしょうか。
A.AWS CloudFormation を使用して、各チームが必要とするパフォーマンスを満たすリソースをテンプレートのパラメータに入力させてDBクラスターをデプロイする。
B.チーム共通のAmazon Aurora DB クラスターを作成した後、Amazon AuroraデータベースクローンでDBクラスターを複製して各チームに割り当てる。
C.チーム共通のAmazon Aurora DB クラスターを作成した後、Auto Scaling設定を有効にしたAmazon Aurora レプリカを各チームに割り当てる。
D.既存のAmazon Aurora DB クラスターのスナップショットから一時停止機能を有効化したAmazon Aurora Serverless DB クラスターを作成する。
※ 『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.325
各チームの日々の作業によって異なります。
この一文がポイントです。これを見た瞬間、Aurora Serverlessが浮かび、他の選択肢を読むことなく直接Dを選べると思います。また開発環境であることからも、Aurora Servelessがアリな選択肢として見えてきます。
（全般に言えることですが、ユースケースを暗記することでも問題を解くヒントになります。）
念のためよくよく読むと、A、Bでは本問の、可変で予測不可能なワークロードには対応できない、ということが読み取れます。
答え、Dです。
また、注意点として、Aurora Serverlessは、機能としてオンオフするものではなく、
Aurora Serverlessを作成する、という形になります。
先ほどの例題1で、
B. Amazon Aurora Serverless設定を有効にして、ワークロードに合わせたオンデマンドオートスケーリングを実行する。
が間違いだったのは、これが理由で、設定を有効にしたところで切り替わるのではないのが理由です。
その他には次のような機能もあります。
AUrora Serverlessには開発者に便利な次の機能もあります。
・AWSマネジメントコンソールから直接SQLを実行(Query Editor)
・HTTPSのAPI形式でデータを取得、結果はJSON形式（DataAPI）
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.88 より
３. バックトラック機能
XXX「Auroraで障害が起きて復旧させたい。いったん、残ってるスナップショットを探して、復旧させよう。」
受かる前「お願いします！」
受かった後「Aurora Replicaからだと復旧させれるが、そもそも、どのような状況かによって、復旧させる内容は違う。バックトラック機能で瞬時に戻せるけど、それだとその間のデータが消えてしまうかもしれない。」
見ていきましょう。
Aurora MySQL限定の機能で、
ただ巻き戻せるだけでなく、通常の復旧（復元ポイントなどを利用したもの）よりも爆速で巻き戻せる、
というメリットがあります
以下は、AWS公式からの引用です。
バックトラックを有効にした場合、指定されたバックトラック期間中、Aurora のデータレコードが保持されます。たとえば、最大 72 時間までデータベースを巻き戻せるようにバックトラックをセットアップできます。データレコードのコピーが不要なため、大規模データベースであってもバックトラックの実行は数秒で完了します。
大規模データベースであってもバックトラックの実行は数秒で完了します
まさに、爆速ですね。
以上を踏まえて、バックトラック機能の例題を見ていきましょう。
例題4.
問題9 Amazon RDS for MySQL を使用したアプリケーションの継続的な改善を開発環境で実施しています。 複数のエンジニアが同じデータベースで作業しており、データベース操作の失敗で正常な時点への復元が必要になる場合が度々あります。 この問題が今後発生した場合に最小限のダウンタイムで不具合のあったクエリを実行前の時点に戻す方法はどれでしょうか。
A. AWS Lambda 関数で定期的にスナップショットを作成してスナップショットから復元する。
B. Amazon RDS for MySQLのバックトラック機能を有効にする。
C. Amazon Aurora MySQLに移行し、復元ポイントを使用する。
D. Amazon Aurora MySQLに移行し、バックトラック機能を有効にする。
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.311より
RDSにはバックトラック機能はありません。なのでBはすぐ消せますね。
A、Cも検討できるのですが、遅いです。最小限のダウンタイムでの要件に答えることができません。
そこで爆速のバックトラック機能を使用したＤが正解となります。
補足ですが、バックトラックよりもPTR(ポイントインタイムリカバリ）を採用する場合もあります。
バックトラックだと、戻せるのですが、正しいデータも巻き戻ってしまいます。
特定の時点でデータが不整合が起き、その後もユーザーがデータ追加していったというような場合です。
簡単にいうと、データベースが無茶苦茶になっている場合ですね。
その場合は、PTRで別にデータベースを作成し、その中のテーブルから、今の正しくないテーブルへとテーブル単位で移行させ、復旧させる、という手段をとることになります。
そのような、巻き戻ってはいけないときにテーブルだけ戻す、というような場合もDBS試験で出ました。
４. 障害挿入クエリ(Fault Injection Queries)
XXX「AuroraでBPO訓練しよう。AWSマネジメントコンソールからDBインスタンスをフェイルオーバーするオプションを実行しよう」
受かる前「お願いします！！」
受かった後「障害挿入クエリが使えます。それで再起動なしにディスククラッシュがシュミレーションできるのでそれでいきましょう。再起動させてわざわざやる理由って何かありますか？？？」
Auroraでのみ、ディスククラッシュのテストがこのクエリによってできます。
pointはAuroraのみの機能ということです。Auroraすごい。
この機能はRDSにはありません。
ポイントはシュミレーションできるということです。
RDSなどはこのテストのために再起動（フェイルオーバー）させる必要がありますが、
Auroraの場合は、このクエリによって再起動なしにシュミレーションできるのです。
DBSの例題を見ていきましょう。
例題4.
問題30 マルチAZ構成のAmazon RDS for OracleのDBインスタンスを使用したアプリ ケーションでアベイラビリティゾーン障害を想定したフェイルオーバーテストを実施した いと考えています。この要件を最小限の作業量と時間で実現する方法はどれでしょうか。
A.AWSマネジメントコンソールからDBインスタンスをフェイルオーバーして再起動する
オプションを選択して再起動する。
B.Amazon RDSの障害挿入クエリを使用して障害イベントをシュミレーションする。
C.アプリケーション側でマルチAZ構成のプライマリノードのIPアドレスを拒否するように設定する。
D.AWS CLIでaws cli failover-db-clusterコマンドを実行してフェイルオーバーをテストする。
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.320より
ここで障害挿入クエリの知識が無いと、Bを選んでしまいますが、RDSにこの機能はありません。
答えは、A です。
Dのコマンドも、オーロラのフェイルオーバーテストのコマンドで、RDSは無関係です。
例題5.
問題45. Amazon Aurora DBクラスターでDBインスタンスのディスク障害のテストを実施しています。 Amazon Aurora DBクラスターの障害耐性を最小限の時間とコストで確認する方法はどれでしょうか。
A.EC2インスタンスを無制限にオートスケーリングし、DBクラスターに負荷の高いクエリを発行する。
B.AWSマネジメントコンソールからDBインスタンスをフェイルオーバーするオプションを実行する。
C.Amazon Aurora 障害挿入クエリ を使用してディスク障害のシュミレーションを実施する。
D. DBクラスターのエンドポイントを削除してディスク障害のシュミレーションを実施する。
※『AWS認定 データベース・専門知識』 NRIネットコム株式会社 p.327より。
これは瞬殺できますね。ディスク障害をAuroraではこのFIQでテストできます。
答えは、Cです。
番外編 RDSの思わぬ欠点
XXX「RDSが使われたテスト環境作った。年末年始の10連休使わないから停止させとくね」
受かる前「お願いします！！！」
受かった後「ダメです。RDSは、7日後に自動で起動してしまうので、Lambda関数などで停止のスケジューリングが必要。でも停止させても浮かせられるのは、インスタンスの起動時間分で、ストレージ時間には課金されるから、10日くらいなら停止させるだけでいいかも。金額ではなくその間アクセスされないことが目的なら、7日後に停止のスケジューリングすべき」
知らなかったのですが、
RDSは、停止させても7日後に勝手に起動してくる仕様
のようです。
もちろんRDSは起動時間に対する従量課金制ですので、ここはかなり注意すべき点です。
例えば、3週間使用しない予定があるとして、停止させるという選択肢をとるとしても、一週間後にRDSにアクセスできるようになってしまいます。
これは、AWS側がパッチ適用などをしての更新を行うことが理由のようです。
Lambdaを使用して、停止をスケジューリングする、など、継続停止させるには別途対応が必要になります。
以下の公式記事などが参考になります。
AWS公式 Lambda 関数を使用して Amazon RDS インスタンスを 7 日以上停止する方法を教えてください。
最後に
DBS試験は、
実運用に役立つ観点を得られたのが良かったです。
本記事で取り上げた知識も、すべて、実運用に役立つものです。
最後に、本記事で学ぶことができた、実運用に役立つ知識についてまとめる形で、
記事を終えさせていただきます。
・Aurora Replicaをどう使うか
・Aurora Serverlessはどのようなときに使うか
・バックトラック機能は便利だが、PTRを優先し、別の手法をとる場合もある。
・障害挿入クエリが便利
・RDSの実運用で必須の知識
参考文献
・『AWS認定 データベース・専門知識』 NRIネットコム株式会社
・AWS公式サイト Amazon Aurora の特徴
https://aws.amazon.com/jp/rds/aurora/features/
・arc serve japan blog
レプリケーションとは、仕組み～3つのお勧めケースまで総解説
1-4-2. 非同期レプリケーションの仕組みとお勧めケース
https://insights-jp.arcserve.com/replication#:~:text=1%2D4%2D2.%20%E9%9D%9E%E5%90%8C%E6%9C%9F%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF%E3%81%A8%E3%81%8A%E5%8B%A7%E3%82%81%E3%82%B1%E3%83%BC%E3%82%B9,-%E2%97%86&text=%E4%B8%80%E8%88%AC%E7%9A%84%E3%81%AB%E3%80%81%E9%9D%9E%E5%90%8C%E6%9C%9F%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3,%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E5%A0%B4%E5%90%88%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82
・Aurora リードレプリカを使用した、MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html
・Aurora レプリカ
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html
・Qiita記事:RDSレプリケーションの同期、非同期についてまとめましたhttps://qiita.com/bonjiko/items/e61a2f4e44da1535829c