CLF / ドメイン3 クラウドテクノロジーとサービス

重要な内容

Amazon RDS (Relational Database Service)

は、MySQL や PostgreSQL などのを、AWS がセットアップ・運用・拡張を支援する形で利用できるマネージドデータベースサービスです。 パッチ適用やバックアップなどの管理作業を AWS に任せられるため、利用者はアプリケーションの開発に集中できます。

CLF では、としての利点、配置との違い、 との使い分けを判断できることが重要です。

Point
  • RDS = Relational Database Service(リレーショナルデータベースサービス) の略です。
  • Relational Database(リレーショナルデータベース) は、データを行と列の表形式で管理し、SQL という言語で操作するデータベースです。
  • RDS は「表形式のデータベースをお任せで運用できるサービス」と覚えます。
  • 和訳

概要

は、を自分でサーバーに構築する代わりに、AWS 上で数クリックで用意できるサービスです。 データベースソフトウェアのインストール、 やデータベースへのパッチ適用、バックアップ、障害検知といった定型的な運用作業を AWS が担います。

RDS は「DBインスタンス」という単位で作成します。 DBインスタンスは独立したデータベース環境で、性能を決めるインスタンスクラスと、データを保存するストレージを選んで利用します。

代表的な用途は、Web アプリケーションの顧客情報や注文データの管理、業務システムのデータベース、既存のデータベースのクラウド移行先です。

概要の図 WebアプリケーションEC2 など RDS DBインスタンス 顧客情報 注文データ 商品マスタ

試験では、「運用負荷を減らしたい」「が必要」「読み取り性能を上げたい」といった要件から、RDS のどの機能を選ぶかを判断します。


主要技術

①マネージドサービスの意味と責任共有モデル ⚠️ 頻出

に自分でデータベースソフトウェアをインストールして運用することもできますが、その場合は やデータベースのパッチ適用、バックアップ、の構成をすべて利用者が行います。 を使うと、これらの管理作業の多くが AWS の担当になります。

管理作業EC2 上に自分で構築Amazon RDS判断ポイント
ハードウェア・電源・ネットワーク利用者AWSAWSクラウドを使えば AWS の担当です。
OS のインストール・パッチ適用利用者利用者AWSRDS では OS を直接操作できない代わりに、管理も不要です。
データベースソフトのインストール・パッチ適用利用者利用者AWSRDS の大きな利点です。
バックアップ・高可用性利用者利用者AWSRDS では設定するだけで自動化できます。
アプリケーションの最適化・データ管理利用者利用者利用者どの形態でも利用者の責任です。

RDS を使っても、スキーマ設計、 クエリのチューニング、保存するデータの管理、アクセス権限の設定は利用者の責任です。

⚠️ 頻出: 「データベースのパッチ適用やバックアップの運用負荷を減らしたい」という要件は、EC2 への自前構築ではなく RDS を選びます。逆に「OS に特別な設定をしたい」「AWS が対応していない構成にしたい」場合は EC2 への自前構築を検討します。

Point
  • Managed Service(マネージドサービス) は、構築や運用の作業を AWS が代行してくれるサービスの総称です。
  • Manage は「管理する」という意味で、「管理される(= managed)サービス」つまり「お任せできるサービス」と覚えます。
  • 和訳

②対応データベースエンジンとAmazon Aurora

では、使い慣れたデータベースエンジン(データベースソフトウェアの種類)を選択できます。 既存システムからの移行では、同じエンジンを選ぶことでアプリケーションの変更を最小限にできます。

エンジン特徴判断ポイント
MySQL広く使われるオープンソースのエンジンです。オープンソース系の移行先としてよく選ばれます。
PostgreSQL高機能なオープンソースのエンジンです。オープンソース系の移行先としてよく選ばれます。
MariaDBMySQL から派生したオープンソースのエンジンです。MySQL 系の互換性を持ちます。
Oracle Database商用データベースです。既存の Oracle システムの移行に使います。
Microsoft Server商用データベースです。既存の SQL Server システムの移行に使います。
IBM Db2商用データベースです。既存の Db2 システムの移行に使います。
AWS がクラウド向けに開発した高性能エンジンです。MySQL・PostgreSQL 互換で、より高い性能と可用性が必要な場合に選びます。

Amazon Aurora は、AWS がクラウド向けに設計した独自のエンジンで、RDS の一部として提供されます。 MySQL および PostgreSQL と互換性があるため、既存のアプリケーションやツールをそのまま使いながら、標準の MySQL や PostgreSQL より高いを得られます。 ストレージは利用量に応じて自動的に拡張されます。

Point
  • Aurora(オーロラ) は「夜明け、極光」という意味の英単語です。
  • Aurora = AWS 独自開発・MySQL/PostgreSQL 互換・クラウド最適化で高性能 の3点セットで覚えます。
  • Oracle や SQL Server とは互換性がない点に注意します。
  • 和訳

⚠️ 頻出: 「MySQL 互換でより高い性能・可用性が必要」という要件は Aurora を選びます。


③マルチAZ配置とリードレプリカ ⚠️ 頻出

には、データベースの複製を持つ仕組みが2つあります。 配置は可用性を高めるため、は読み取り性能を高めるための機能で、目的がまったく異なります。

マルチAZ配置では、別の(AZ)にスタンバイ(待機用)の DBインスタンスが自動的に用意され、プライマリの更新が同期的に複製されます。 プライマリに障害が起きると、スタンバイへ自動的に(切り替え)します。

リードレプリカは、読み取り専用の複製です。 プライマリから非同期で複製され、アプリケーションは読み取り処理をリードレプリカへ分散できます。

③マルチAZ配置とリードレプリカ ⚠️ 頻出の図 読み書き 同期レプリケーション 障害時に自動フェイルオーバー 非同期レプリケーション 読み取りのみ アプリケーション プライマリDBインスタンス スタンバイ別AZ・通常時は利用不可 リードレプリカ読み取り専用
項目マルチAZ配置リードレプリカ判断ポイント
目的・障害対策読み取り性能の向上「止めない」ならマルチAZ、「読み取りを速く」ならレプリカです。
複製方式非同期レプリケーション同期は可用性向け、非同期は性能向けです。
通常時のアクセススタンバイには接続できません読み取り専用で接続できますスタンバイは待機専用です。
障害時自動フェイルオーバーします自動では切り替わりません自動復旧の要件はマルチAZです。
Point
  • Multi-AZ = 複数の Availability Zone(アベイラビリティーゾーン) にまたがる配置です。
  • Failover(フェイルオーバー) = fail(障害) が起きたら over(乗り換える)、つまり待機系への自動切り替えです。
  • Read Replica(リードレプリカ) = Read(読み取り) 専用の Replica(複製) です。
  • 和訳

⚠️ 頻出: 「障害時も自動で継続」「高可用性」はマルチAZ配置、「読み取り負荷の分散」「読み取り性能の向上」はリードレプリカです。両者を取り違えさせる問題が非常によく出ます。


④自動バックアップとスナップショット

には、データを保護するためのバックアップ機能が2種類あります。

方式取得方法保持期間判断ポイント
自動バックアップ有効化すると毎日自動で取得されます。設定した保持期間を過ぎると自動削除されます。保持期間内の特定時点への復元(ポイントインタイムリカバリ)ができます。
手動利用者が任意のタイミングで取得します。削除するまで保持されます。長期保管や、大きな変更前の保険に使います。

自動バックアップを有効にすると、保持期間内の任意の時点の状態へデータベースを復元できます。 一方、手動スナップショットは取得した時点の状態を保存するもので、自動では削除されないため、長期のデータ保全に向いています。

⚠️ 頻出: 「特定の時点に戻したい」は自動バックアップ(ポイントインタイムリカバリ)、「削除されない長期保管」は手動スナップショットです。

Point
  • Snapshot(スナップショット) は「スナップ写真」という意味で、その瞬間のデータの状態を丸ごと写し取るイメージです。
  • Point-in-Time Recovery(ポイントインタイムリカバリ) = 「時点(Point in Time)」への「復元(Recovery)」です。
  • 和訳

⑤料金の考え方

はのサービスです。 料金はデータベースの稼働時間だけでなく、複数の要素で決まります。

料金に影響する要素例
インスタンスの稼働時間選択したインスタンスクラスと稼働した時間です。のほか、長期利用ならで割引を受けられます。
ストレージ確保したストレージの容量と種類です。
バックアップストレージ保持期間やの量に応じたバックアップの保存分です。
データ転送AWS 外へのデータ転送などです。
配置スタンバイ用のインスタンスも稼働するため、シングルより料金が増えます。

(マルチAZ)や読み取り性能()を追加するほどインスタンスが増え、コストも増えます。 要件に対して過剰な構成になっていないかという観点で判断します。

⚠️ 頻出: 「1年以上継続して使うデータベースのコスト削減」は、リザーブドインスタンスの購入が有力な選択肢です。


⑥DynamoDBとの使い分け ⚠️ 頻出

CLF では、の と、 データベースの の使い分けが問われます。 DynamoDB はキーバリュー型のフルマネージド NoSQL データベースで、サーバーやインスタンスを意識せずに利用でき、規模が大きくなってもミリ秒単位の応答時間を維持できます。

項目Amazon RDSAmazon DynamoDB判断ポイント
データモデルリレーショナル(表形式・スキーマあり)キーバリュー型 NoSQL(スキーマレス)複雑な結合や集計は RDS、柔軟な構造は DynamoDB です。
クエリ で複雑な結合・集計ができます主にキーによる高速な読み書きです「SQL」「結合(JOIN)」が出たら RDS 系です。
性能の特徴インスタンスの性能に依存します大規模でもミリ秒単位の一貫した低です「ミリ秒」「大規模なスケール」は DynamoDB です。
管理単位DBインスタンスを選んで運用しますサーバー管理が不要ですインスタンス管理すら不要にしたいなら DynamoDB です。
代表的な用途業務システム、ECサイトの注文管理ゲームのユーザーデータ、IoT、セッション管理既存の RDB 移行は RDS が基本です。
Point
  • NoSQL は「Not only SQL」と説明されることが多く、表形式・SQL 以外の方法でデータを扱うデータベースの総称です。
  • スキーマレス(Schemaless) = 事前に列の構造(Schema: スキーマ)を固定しなくてよい、という意味です。
  • 「SQL・結合・トランザクション → RDS」「キーバリュー・スキーマレス・ミリ秒 → DynamoDB」と対で覚えます。
  • 和訳

⚠️ 頻出: 「既存の MySQL アプリを移行」「SQL で集計」は RDS、「スキーマレス」「キーバリュー」「ミリ秒の応答」は DynamoDB です。


試験対策

CLF の問題では、まずデータの種類を確認します。 表形式で を使うなら (または )、キーバリュー型で柔軟な構造なら が基本です。 次に、可用性、読み取り性能、バックアップ、コストのどれが問われているかを確認します。

問題文のキーワード優先して考える機能・サービス理由
データベースの運用負荷(パッチ・バックアップ)を削減Amazon RDS管理作業を AWS が担うです。
・配置別 のスタンバイへ自動で切り替わります。
読み取り負荷の分散・読み取り性能の向上読み取り専用の複製へ処理を分散できます。
MySQL/PostgreSQL 互換で高性能Amazon AuroraAWS がクラウド向けに最適化した互換エンジンです。
特定時点への復元自動バックアップポイントインタイムリカバリができます。
削除されない長期のバックアップ保管手動明示的に削除するまで保持されます。
スキーマレス・キーバリュー・ミリ秒の応答Amazon DynamoDBRDS ではなく の要件です。
長期利用するデータベースのコスト削減稼働時間分の料金を割引できます。
レベルの細かい制御が必要なデータベース への自前構築RDS では OS を直接管理できません。

よくある誤答は、マルチAZ配置とリードレプリカの取り違えです。 マルチAZ配置のスタンバイは通常時に読み取りへ使えず、あくまで障害対策です。 読み取り性能の問題でマルチAZを選ばないように注意します。

また、「データベース」という言葉だけで RDS を選ばず、スキーマレスやミリ秒といった NoSQL のキーワードがあれば DynamoDB を選びます。


参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください