顧客フロントSEのIT勉強ブログ

2022 Japan AWS Top Engineer / 2022-23 Japan AWS Certifications Engineer。AWS認定12冠、情報処理試験全冠。顧客フロントSEがなるべく手を動かしながらIT技術を学んでいくブログです。

【資格】AWS認定 データベース - 専門知識に合格した勉強法

AWS認定資格の内、AWS認定 データベース - 専門知識」に無事合格しました!
実は取得したのは数か月前になるのですが、ブログにまとめるタイミングを逸してしまっていました。勉強していた当時を振り返りながら、私の勉強法と学んだことを書き出していきます。
システムを構築・運用するなら必ず使用するデータベースに関する資格です。実務に活かせる知識も多いと思うので是非ご参照ください。

準備期間と結果

準備期間は2021年10月3日~10月30日の約1ヵ月でした。
RDSやAuroraは普段の業務で馴染みのあるサービスだったため、「あー、あの機能だな」とある程度感触がある中での学習となりました。

結果は840点で、無事全分野「コンピテンシーを満たしている」と判定されました!

合格までの勉強法

1.試験ガイド

AWSが公式に提供している試験内容を説明した資料です。
いつも最初にざっくり内容を確認し、出題範囲となるAWSサービスと出題分野を確認しています。データベースの試験ガイドはこちら

(出典)AWS Certificated Database - Specialty 試験ガイド

2.サンプル問題

こちらも毎回最初に確認するAWS公式のサンプル問題10問です。リンクはこちら
出てくるキーワード自体は理解できたのでセキュリティやネットワークの時よりは「ヤバイ・・・」と感じることはなかったですが、それでも最初の正答率は3割でした。

1問目だけ抜粋して掲載しますが、次の問題の答えは分かりますか??

(出典)AWS Certified Database - Specialty 認定試験の質問例

答えは「D」です!
DBMSPostgreSQLで共通しているなら、RDSをソースにして、Auroraリードレプリカを作成できるんですね。もちろんPostgreSQLのバージョンなど細かい制約はありますが、この方法なら手間が非常に少なく、ダウンタイムも「リードレプリカを昇格させる時間」だけに限定できます。

3.AWSレーニングライブラリ

AWS Skill Builderの中に日本語向けのコンテンツがあります。
「Exam Readiness: AWS Certified Database - Specialty (Japanese)」です。リンクはこちら

自分が受験した時とはコンテンツ内容が変わっている気もしますが、各データベースサービスの特徴を動画で押さえていきました。

4.AWS WEB問題集で学習しよう

過去のAWS認定資格全てでお世話になっているこちらのサイトで問題を解きました。
ですが、2020年4月に正式版になった比較的新しい認定区分のため掲載されている問題数が少な目です。これだけでは勉強量が足りないと感じたので、今回は次の項目も追加しました。

5.認定資格本

AWSサービスは変動が激しいこともあり、特に専門知識ではあまり書籍を見かけないのですが、ありがたいことにNRIネットコムから認定資格本が出ています!

データベースサービス毎の機能が体系立ててまとめられており、内容が理解しやすいので非常におすすめです!末尾に練習問題65問が掲載されています。
合格後に振り返って少し残念だったのは、この練習問題と同じ or 類似する問題を本番試験では見かけなかったことです。練習問題の質(本番試験と類似するという意味)は、前述の「WEB問題集」のほうが良いと思います。

6.模擬試験

Skill Builderで公式の模擬試験が提供されています。
AWS Certification Official Practice Question Sets (Japanese)」です。
自分が受けたときは受験できるのが1度だけで正答も分からなかったのですが、2021年末からそれが解消されましたね。受験者にとって非常に嬉しい改善です。

7.Black Beltサービス別資料

https://cdn-ak.f.st-hatena.com/images/fotolife/s/se_o_chan/20210911/20210911214907.png

試験対象のサービスは一通り説明動画・スライドが用意されています。リンクはこちら
QLDBが「Blockchain」配下にあるように、いくつかのサービスが「Database」以外のところにあるのでご注意を。

今回学んだこと

重要なのは複数あるデータベースサービスの特徴(可用性、パフォーマンスなどを実現する機能)を把握することです。サービスごとの違いを正しく把握することで実務でも最適なデータベースサービスを選択できるようになりますし、それこそが今回の資格取得者に求められることでもあります。

DBサービス比較

計9つのサービスを横並びで比較します。可用性やパフォーマンスなどの非機能要件に対して、それらを実現する機能をキーワードで記載しています。横並びにするとサービス毎の違いや類似点が分かり易いのではないかと思います(AuroraとNeptuneは比較的似た機能を持っているなど)。
ただ下記画像では文字が小さくて読めないと思うので、こちらからPDFファイルをダウンロードして参照ください。

主サービスであるRDS、Aurora、DynamoDBは個別に機能内容を説明します。

RDS

■概要

OracleMySQLPostgreSQLなどのリレーショナルデータベースを提供するサービスです。OSやDBMSへのパッチはAWS側で管理され、可用性・拡張性・バックアップなどの要件を実現する機能も提供されているのでデータベース運用の負荷が軽減されます。

下記はRDS作成時のDBMS選択画面です。AuroraもRDSの一種であるのですが、アーキテクチャが大きく異なるので認定試験では別物だと考えた方が良いと思います。

■可用性

RDSの可用性を高める機能は「スタンバイレプリカによるMulti-AZ構成」です。プライマリインスタンスとは別に、リアルタイムにデータ同期しているRDSインスタンス(=スタンバイレプリカ)を別AZに構築します。
本番システムではMuti-AZ構成で運用される前提となっており、サービスレベルアグリーメント(SLA)もMuti-AZ構成でないと適用されません(Mutli-AZ構成なら月間99.95%以上)。

エンドポイントという[データベース名].[ランダム文字列].[リージョン名].rds.amazonaws.comで表現されるDNS形式の接続情報を使ってRDSに接続するのですが、プライマリインスタンスに障害が発生した場合、AWSが自動的にエンドポイントの向き先をスタンバイレプリカに変更してくれます(おおよそ60~120秒が目安)。これによりアプリケーションが意識することなく障害からの自動復旧が実現できます。

■パフォーマンス

RDSのパフォーマンスを高めるためには、インスタンスタイプを変更し高スペックなインスタンスに切り替える(=スケールアップ)のが最もシンプルな方法です。
一方でスケールアップにも限界があるため、読み取り性能を上げたいのであれば「リードレプリカによるスケールアウト」も検討するとよいです。1~5個作成できます。

リードレプリカは、プライマリインスタンスから非同期でデータコピーされています。スタンバイレプリカと似ていますが、RDSではスタンバイレプリカとリードレプリカは別物です。可用性を高めつつ、読み取り性能も上げたいならスタンバイレプリカとリードレプリカの両方を実装する必要があります。
リードレプリカはプライマリインスタンスのスナップショットから構築されるため、自動バックアップを有効にしておく必要があります。

もう一つパフォーマンス向上を目的とした機能として「RDS Proxy」があります。これはコネクションプーリングを代行してくれる機能です。RDSへの接続元がEC2であればアプリやミドルウェアにコネクションプーリング機能が搭載されていると思いますが、接続元がLambdaの場合、API実行する都度Lambdaコンテナが起動するというアーキテクチャであるが故にコネクションプーリングが実現できません。そこでRDS Proxyを使ってRDSへの接続を代行してプーリングし、RDS接続の負荷を低減させます。

■メンテナンス

RDSではOSレイヤはAWS管理下であるため、OSにログインしてDBMSの設定値を変更することが出来ません。その代わり「パラメータグループ」で設定値をRDSに反映します。
パラメータグループは文字コードタイムゾーンなどの設定値の集合体で、DBMS種類ごとに用意されています。パラメータの変更が即時反映される動的パラメータと、RDS再起動が必要な静的パラメータがあります(下記の「適用タイプ」を参照)。

例えばOracleならOEMOracle Enterprise Manager)やStatspackのような追加機能を使いたい場合は「オプショングループ」を設定します。こちらも即時反映されるものとRDS再起動が必要なものがあります。

■バックアップ

RDSのバックアップは「スナップショット」機能で実現します。スナップショットにより保持データ全体がバックアップされます(特定テーブルのみのバックアップ、という機能はありません)。

自動バックアップを有効にすると、指定した時間帯(=バックアップウィンドウ)に1日1回のスナップショットを取得します。スナップショットの保持期間は0~35日です。
初回はフルバックアップですが、2回目以降は差分バックアップで動きます。

手動バックアップとして、任意の時間にスナップショットを取得することもできます。自動バックアップとは違い、保持期間の設定が無いので自動削除されることなく保持し続けることができます。手動バックアップは毎回フルバックアップで動きます。

RDSではさらにトランザクションログを5分単位に自動退避しているため、スナップショット+トランザクションログの組み合わせで任意の時間帯に復元できます。これを「ポイントインタイムリカバリ」と呼びます。ただし運用中のRDSとは別のインスタンスとして復元される(つまりアプリケーション側で接続先の変更が必要となる)ことに注意が必要です。

(参考)オフィシャルではないですが下記サイトによると、エンドポイントに含まれるランダム文字列はAWSアカウント+リージョンが同じであれば同値になるようです。従って、スナップショットから同じリージョンに復元した後でデータベース名を元の値に戻せば、エンドポイントも同じ文字列に戻るため、アプリケーション側で接続先変更が不要になります。

Aurora

■概要

AWSが独自に構築したリレーショナルデータベースです。MySQL互換とPostgreSQL互換の2種のAuroraがあります。
クラウドに特化したアーキテクチャで構成されており、SQLを受けつけて計算するインスタンス部と、データを管理するストレージ部が分離されています。データは3つのAZに自動コピーされるため高い可用性を実現します。後述のAuroraレプリカはインスタンス部のみを複製し、ストレージ部はプライマリインスタンスと共有します。

■可用性

RDS同様、可用性を高めるにはレプリカを使用するのですが、Auroraレプリカはスタンバイレプリカとリードレプリカの両方の役割を持ちます。従って、可用性を高めつつ読み取り性能向上も実現できます。

リードレプリカの役割もあるため1~15台のAuroraレプリカを構築できるのですが、プライマリインスタンス障害時にどのレプリカにフェールオーバーするかは、事前に設定しておいた優先度に基づいた次のロジックで決定されます。

  1. 優先度が高い(優先度の値が小さい)Auroraレプリカ
  2. 優先度が同じならインスタンスタイプが大きいAuroraレプリカ
  3. 優先度もインスタンスタイプも同じなら任意のAuroraレプリカ

さらにAuroraではリージョン障害に備えて、複数リージョンにまたがってデータ同期される「Auroraグローバルデータベース」機能があります。1つのプライマリリージョンと、最大5つのセカンダリリージョンを設定できます。リージョンを跨いでもおおよそ1分以内にデータ同期されますが、データ書き込みができるのはプライマリリージョンのみです。

またAuroraレプリカへのフェールオーバーには1~2分の書き込み処理の停止が伴いますが、「Auroraマルチマスタークラスター」能を使えば書き込み処理も無停止で継続可能になります。ただしMySQL互換のAuroraだけが対象、インスタンス数は最大2つ、バックトラック機能(後述のバックアップ機能)が使えないなど制約も多いです。

■パフォーマンス

Auroraレプリカで読み取り性能をスケールアウトできるのは前述の通りですが、Auroraの場合は「Aurora Auto Scaling」レプリカの自動追加・削除を実現できます。

また「Aurora Serverless」という機能を使うと、インスタンスタイプという概念が無くなりCPUやメモリ等のリソースを自動でスケールアップ/ダウンしてくれます。予測できないワークロードのスパイクがあるような環境では有効な選択肢となります。
従来はMulti-AZ構成にできなかったり、バックトラック機能(後述)が使えない等の理由で本番環境の利用は非推奨だったのですが、2022年4月21日にAurora Serverless v2がGA(一般公開)され、その懸念が解消されました。

■メンテナンス

ここはほぼRDSと同機能です。

■バックアップ

自動バックアップ or 手動バックアップでスナップショットを取得できるのはRDSと同様ですが、Auroraではスナップショットは別に「クローン」機能があります。クローンはデータを保持するストレージ部ではなく、インスタンス部のみコピーします。これだけだとAuroraレプリカと類似しますが、クローン機能ではクローン側が更新したデータは別ストレージに書き込まれ、コピー元のAuroraクラスターには反映されないのが特徴です。
AWSアカウントやVPCを跨いでクローンを作成できるので、本番データを使った開発・テストなどに利用できます。

スナップショットから復元は運用中のデータベースとは別のインスタンスとなってしまいますが、Auroraは「バックトラック」機能を使うことで運用中のインスタンスに対して最大24時間前の状態までデータを戻すことが出来ます。ただしMySQL互換でのみ利用可能であり、バックトラック実施中はインスタンスが一時断するなどの制約もあります。

DynamoDB

■概要

DynamoDBはフルマネージドのNoSQLデータベースです。Key-Value型データおよびドキュメントデータモデルを保持できます。

テラバイト級のデータを管理しつつ、数ミリ秒レベルのパフォーマンスを実現できることから性能要件が厳しいシステムのデータベースとしてRDSやAuroraよりも適しています。反面、その性能を実現するためにDynamoDB特有のデータ構造を理解し、最適なデータ設計を行う必要があります。その構造のポイントがパーティションです。

リレーショナルデータベースでも使われることがあるパーティションは、値によって予め保存するデータの物理配置を決めておくことで参照する際の探索範囲を限定でき、性能向上を実現する技術です。リレーショナルデータベースではオプションの位置づけですが、DynamoDBではパーティション前提でテーブルを実装します。

パーティション先を決めるための項目をパーティションキー」と言います。データを一意に特定する「プライマリキー」が1つの項目で定義される場合は「パーティションキー=プライマリキー」です。
一方で複数項目の組み合わせでデータが一意になる「複合プライマリキー」構成のテーブルの場合、パーティションキーではない項目を「ソートキー」と呼びます。つまり「パーティションキー+ソートキー=プライマリキー」です。DynamoDBの場合、複合プライマリキーとして3つ以上の項目を指定することはできません。

■可用性

Aurora同様、AWSがデータを3つのAZに自動複製することで高可用性を実現しています。しかし、その複製のせいでデータ書き込み直後にそのデータを読み込むと、書き込み結果がまだ反映されていない(=結果整合性)ことがあります。

それだと困る、という場合は「強力な整合性のある読み込み」を有効にすることが出来ます。これを有効にするとデータ書き込み直後でも、読み込み前の処理が全て反映された結果を得られます。

一方でレイテンシーの悪化、コストが増加(詳細は後述)するなどのデメリットや、グローバルセカンダリインデックス(GSI、これも後述)では「強力な整合性のある読み込み」はサポートされないなどの制約があります。

■パフォーマンス(ユニット)

DynamoDBでは読み込みと書き込みの性能をそれぞれ「ユニット」と呼ばれる単位をテーブルに設定し、そのユニット数に応じてコストが発生します。各ユニットの性能は下記です。

  • 書き込みキャパシティユニット(WCU):1秒に最大1KBのデータを1回書き込み
  • 読み込みキャパシティユニット(RCU):1秒に最大4KBのデータを2回読み込み

1秒に3KBのデータを書き込む性能が欲しいなら3WCUが必要ですし、1秒に10KBを読み込む性能が必要なら2RCUが必要になります。また、強い整合性のある読み込みを使用すると、RCUは「1秒に最大4KBのデータを1回読み込み」に半減します。

ユニット数の設定方式として「プロビジョニング済みキャパシティモード」「オンデマンドキャパシティモード」があります。前者は予めユニット数を決めておく方式です。設定値を超えるリクエストが発生するとリクエストスロットリングというエラーになります。後者は事前にユニット数は決めず発生したリクエスト数に応じた費用を支払う方式です。

■パフォーマンス(インデックス)

DynamoDBはそのデータ構成上、パーティションキーに指定した項目で検索すると非常に高速に結果が返ってきますが、その他の項目で検索するとすべてのパーティションを探索する必要があるのでレスポンスが悪化します。
このようにDynamoDBではデータ検索パターンを考慮してテーブル設計(=キー設計)を行うのですが、どうしても1つのテーブルに対して「この項目で検索することも、あの項目で検索することもありえる!」というケースがあります。そこで使用するのが「インデックス」です。

ローカルセカンダリインデックス(LSIは同一パーティション内で代替ソートキーを定義する機能です。下記の場合、「社員ID=A0001の社員の認定ネットワークの得点を知りたい」という検索には、社員IDからパーティション1を特定した後、試験名によってダイレクトに欲しい情報にアクセスできます。しかし「社員ID=A0001の社員の800点以上の試験を知りたい」という検索の場合、パーティションは特定できますが、その中の全データを探索して初めて所望の情報を得られます。
そこで得点をソートキーに指定したローカルセカンダリインデックスを構築します。すると予め得点順にデータが並んでいるので全データを探索しなくても「800点以上」の試験名を取得することが出来ます。

インデックスと言いつつDynamoDB内部としては別テーブルを保有するようなもので、データの更新があった場合は元テーブルに加えてLSIにもデータの更新が走ります。これによりLSIへの書き込みにもWCUが消費されます
また代替ソートキーを定義するという機能であるため、そもそもソートキーがない「パーティションキー=プライマリキー」のテーブルにはLSIを構築できません。

グローバルセカンダリインデックス(GSI)はテーブルに対して代替のパーティションキーを定義する機能です。先ほどと同じ例において「認定データベースの得点が800点以上の社員を知りたい」という検索の場合、既存のキー設計だと全パーティションに対して探索しないと所望のデータが得られません。そこで試験名をパーティションキー、特典をソートキーに指定したGSIを定義すると検索を最適化できます。
LSIと同様、GSIへのデータ書き込み、読み込みにもユニットを消費します。

■メンテナンス

フルマネージドでサーバレスなサービスなため、原則メンテナンスは不要です。
DynamoDBは基本的に上限データサイズを気にすることなくデータを保持できますが、その分ストレージコストもかかりますし、インデックス定義がイマイチでフルスキャンが発生した場合のRCU消費量も増大します。不要データを随時削除していくことでそれらが軽減されますが、DynamoDBではデータに対して有効期限(Time to Live=TTLを設定できます。TTLを超えたデータはWCUを消費することなく自動削除されます。

■バックアップ

DynamoDBも、RDSやAuroraと同様、手動バックアップ(=オンデマンドバックアップ)と自動バックアップがあります。また自動バックアップを有効化すればポイントインタイムリカバリにより任意の時間に復元可能です。

ここでバックアップからのリストア時に復元される設定と復元されない設定があることに注意が必要です。下記設定はリストアするとバックアップ時の値に復元されます。

  • グローバルセカンダリインデックス(GSI)
  • ローカルセカンダリインデックス(LSI
  • キャパシティモード
  • プロビジョニングされた読み込みキャパシティ(RCU)および書き込みキャパシティ(WCU)
  • 暗号化設定

一方で次の設定はリストア後に手動設定が必要です。

  • Auto Scalingポリシー
  • IAMポリシー
  • CloudWatchメトリクス、アラーム
  • タグ
  • ストリーム設定
  • TTL設定

まとめ

今回取り上げたデータベースサービス以外だと「DMS/SCTを使った移行」は学習が必要です。その他「CloudFormationの基礎知識」、「CloudTrail・CloudWatchによるモニタリング」などもスコープに入っていますが、ソリューションアーキテクト プロフェッショナル(SAP)やDevOpsエンジニア プロフェッショナル(DOP)を取得していれば新たに学習する必要はないと思います。

他の認定資格と比べると比較的新しいこともあり、過去問題・練習問題が少ないことが学習を難しくしているのですが、データベース自体は皆さん馴染みやすく取っつきやすいサービスです。

セキュリティやネットワークは拒否感がある方も、データベースは是非取得を目指してみてください!!

他の認定区分については次の記事も参照してみてください!

PVアクセスランキング にほんブログ村ブログランキング・にほんブログ村へにほんブログ村