AWSの仕組みがキーワードベースで理解できるようまとめてみました。
AWSの仕組みがキーワードベースで理解できるようまとめてみた８
1. RDSーインスタンスタイプ
Amazon RDSでは、データベースの用途に合わせたインスタンスタイプを選ぶことが出来ます。
インスタンスタイプとは、CPU、メモリ、ストレージ、ネットワークキャパシティーの組み合わせからなる、インスタンスの種類のことです。
リレーショナルデータベースのさまざまなユースケースに合わせ、最適なインスタンスタイプを選択できます。
Amazon RDSのインスタンスタイプを簡単にまとめました。
インスタンスタイプ 特徴
Tシリーズ ミニマムな構成。
Mシリーズ スタンダードなインスタンス。コア数、メモリともに一般的な構成。
Rシリーズ メモリに特化したインスタンス。Mシリーズより大きいメモリを搭載。
Xシリーズ 大規模アプリケーション、エンタープライズクラスのアプリケーションなどに最適化された高性能なインスタンス。
Zシリーズ RDSのインスタンスの中でもっとも高速。コア単位のライセンス費用が高いデータベースの利用に最適。
インスタンスタイプとは、CPU、メモリ、ストレージ、ネットワークキャパシティーの組み合わせからなる、インスタンスの種類のことです。
リレーショナルデータベースのさまざまなユースケースに合わせ、最適なインスタンスタイプを選択できます。
Amazon RDSのインスタンスタイプを簡単にまとめました。
インスタンスタイプ 特徴
Tシリーズ ミニマムな構成。
Mシリーズ スタンダードなインスタンス。コア数、メモリともに一般的な構成。
Rシリーズ メモリに特化したインスタンス。Mシリーズより大きいメモリを搭載。
Xシリーズ 大規模アプリケーション、エンタープライズクラスのアプリケーションなどに最適化された高性能なインスタンス。
Zシリーズ RDSのインスタンスの中でもっとも高速。コア単位のライセンス費用が高いデータベースの利用に最適。
10. AWS Shield
AWS Shieldとは、AWSにおけるアプリケーションサービスからDDoSに対する保護を提供するサービスです。
AWS Shieldにはスタンダードとアドバンストの2つのタイプがあり、スタンダードは無料・アドバンストは有料です。
スタンダードではWebアプリケーションを標的とした、ネットワーク層(レイヤ3)およびトランスポート層(レイヤ4)のDDoS攻撃から保護してくれます。
アドバンストはAWS WAFと統合されており、大規模で高度なDDoS攻撃に対する追加の検出と、ほぼリアルタイムでの可視性が提供されています。
なお、スタンダードに関してはAWSを利用している時点で自動的に適用されています。
DDoS（Distributed Denial of Service）とは、DoS攻撃と呼ばれるサービスダウンを目的とした攻撃のひとつで、分散型DoS攻撃とも呼ばれます。
1台のコンピュータで攻撃してサービスをダウンさせる手法はDoS攻撃と呼ばれますが、なかでもウイルス感染などでボット化した大量のコンピュータを利用した攻撃で、サービスダウンに追い込むのがDDoSです。
いずれも不正なパケットを送り込みサービスを停止させるという点では共通していますが、非常に多い台数のコンピュータが攻撃元となっている場合はDDoSとなります。
一般的にはDDoS攻撃が発生した場合、ゲートウェイ側で攻撃元のIPアドレスを制限しようとしても数が多すぎるため設定が追い付かず、対策が難しいのが現状です。
また、WAF（Webアプリケーションファイアウォール）であればパケットの中身まで解析して制御の対象にできるので有効な策となります。
（※WAFでのDDoS対策は緩和程度となります。）
しかし、AWSはクラウド環境のため、ゲートウェイ対策が自由にできるわけではありません（AWS WAFであれば対策が可能です）。
その場合に有効な策となるのが、AWS Shieldというわけです。
AWS Shieldにはスタンダードとアドバンストの2つのタイプがあり、スタンダードは無料・アドバンストは有料です。
スタンダードではWebアプリケーションを標的とした、ネットワーク層(レイヤ3)およびトランスポート層(レイヤ4)のDDoS攻撃から保護してくれます。
アドバンストはAWS WAFと統合されており、大規模で高度なDDoS攻撃に対する追加の検出と、ほぼリアルタイムでの可視性が提供されています。
なお、スタンダードに関してはAWSを利用している時点で自動的に適用されています。
AWS Shieldで保護するDDoSとは？
DDoS（Distributed Denial of Service）とは、DoS攻撃と呼ばれるサービスダウンを目的とした攻撃のひとつで、分散型DoS攻撃とも呼ばれます。
1台のコンピュータで攻撃してサービスをダウンさせる手法はDoS攻撃と呼ばれますが、なかでもウイルス感染などでボット化した大量のコンピュータを利用した攻撃で、サービスダウンに追い込むのがDDoSです。
いずれも不正なパケットを送り込みサービスを停止させるという点では共通していますが、非常に多い台数のコンピュータが攻撃元となっている場合はDDoSとなります。
一般的にはDDoS攻撃が発生した場合、ゲートウェイ側で攻撃元のIPアドレスを制限しようとしても数が多すぎるため設定が追い付かず、対策が難しいのが現状です。
また、WAF（Webアプリケーションファイアウォール）であればパケットの中身まで解析して制御の対象にできるので有効な策となります。
（※WAFでのDDoS対策は緩和程度となります。）
しかし、AWSはクラウド環境のため、ゲートウェイ対策が自由にできるわけではありません（AWS WAFであれば対策が可能です）。
その場合に有効な策となるのが、AWS Shieldというわけです。
2. RDSーインスタンスクラス
インスタンスクラスによって、インスタンスの計算とメモリの容量を決定します。
必要なインスタンスクラスは、処理能力とメモリの要件によって異なります。
インスタンスクラスは、インスタンスタイプとサイズの両方で構成されます。
db.r5.4xlarge←これがインスタンスクラスの名称です。
必要なインスタンスクラスは、処理能力とメモリの要件によって異なります。
インスタンスクラスは、インスタンスタイプとサイズの両方で構成されます。
db.r5.4xlarge←これがインスタンスクラスの名称です。
3. RDSーストレージ
ストレージとは、パソコンのデータを長期間保管しておくための補助記憶装置のことです。
主なストレージにハードディスクやDVD、CDなどがあげられます。
スマートフォンなどでは、内部保存領域（内部ストレージ）と外部保存領域（SDカード）があり、ユーザーが用途に応じてストレージの拡張を行うこともできるようになっています。
主なストレージにハードディスクやDVD、CDなどがあげられます。
スマートフォンなどでは、内部保存領域（内部ストレージ）と外部保存領域（SDカード）があり、ユーザーが用途に応じてストレージの拡張を行うこともできるようになっています。
4. RDSーRDSのオートスケーリング
まず、RDSインスタンスを作成する場合について考えてみる。
RDSインスタンスを作成する際には、DBの容量を指定する必要がある。
以前までは、DBの容量が不足した際に、手動で容量を追加する必要があったが、自動的に容量を追加すること(オートスケーリング)が可能となった。
具体的には、以下の条件全てに合致する場合に自動的にDB容量が追加される。
・使用可能な空き領域が、割り当てられたストレージの10%未満になった場合
・低ストレージ状態が5分以上の場合
・最後のストレージ変更から 6時間以上経過している場合
追加されるDBのサイズは、次のうちいずれか大きい方の増分となる。
・5 GiB
・現在割り当てられているストレージの10% ※60 GiB割り当てられているなら、6 GiB。
・直近 1 時間の FreeStorageSpace(使用可能なストレージ領域の容量) メトリクスの変動に基づいて予測される 7 時間のストレージの増分。
※RDS DB インスタンスのストレージサイズが 100 GiB で 10.1 GiB の空き容量があり、ストレージの消費量が通常 1 時間あたり 100 MB の場合、100 MB × 7 時間 = 700 MB
Auroraの場合は、オートスケーリングで「Auroraレプリカ」を追加することが可能。
Auroraの構成として、SQL処理を行う「データベースインスタンス」とデータを格納する「クラスターボリューム」に分かれている。
「データベースインスタンス」は、さらに、「プライマリDBインスタンス」と「Auroraレプリカ」に分かれている。
SQL処理の中で、データの読み取り、更新を行うDBが「プライマリDBインスタンス」となり、データの読み取りのみを行うDBが「Auroraレプリカ」となる。
EC2のオートスケーリング、Auroraのオートスケーリングはどちらもインスタンスそのものを自動的に増やしているが、RDSのオートスケーリングは、データを格納する容量を自動的に増やしている点に注意する。
日常生活で例えると、家を掃除する際に、掃除する人を増やすという観点がEC2やAuroraのオートスケーリングに該当し、掃除する時の収納を増やすという観点がRDSのオートスケーリングに該当すると考える。
ちなみに、データロード(DBの読み取り)の増加が予想される場合は (RDS DB インスタンスの現在のストレージサイズの 20% を超えるロードなど)、データロードの前に RDS DB ストレージのサイズを手動で増加させることがベストプラクティスであると公式ページに記載されている。
そのため、推奨設定ではないと考えている。
RDSインスタンスを作成する際には、DBの容量を指定する必要がある。
以前までは、DBの容量が不足した際に、手動で容量を追加する必要があったが、自動的に容量を追加すること(オートスケーリング)が可能となった。
具体的には、以下の条件全てに合致する場合に自動的にDB容量が追加される。
・使用可能な空き領域が、割り当てられたストレージの10%未満になった場合
・低ストレージ状態が5分以上の場合
・最後のストレージ変更から 6時間以上経過している場合
追加されるDBのサイズは、次のうちいずれか大きい方の増分となる。
・5 GiB
・現在割り当てられているストレージの10% ※60 GiB割り当てられているなら、6 GiB。
・直近 1 時間の FreeStorageSpace(使用可能なストレージ領域の容量) メトリクスの変動に基づいて予測される 7 時間のストレージの増分。
※RDS DB インスタンスのストレージサイズが 100 GiB で 10.1 GiB の空き容量があり、ストレージの消費量が通常 1 時間あたり 100 MB の場合、100 MB × 7 時間 = 700 MB
[補足] Auroraのオートスケーリングについて
Auroraの場合は、オートスケーリングで「Auroraレプリカ」を追加することが可能。
Auroraの構成として、SQL処理を行う「データベースインスタンス」とデータを格納する「クラスターボリューム」に分かれている。
「データベースインスタンス」は、さらに、「プライマリDBインスタンス」と「Auroraレプリカ」に分かれている。
SQL処理の中で、データの読み取り、更新を行うDBが「プライマリDBインスタンス」となり、データの読み取りのみを行うDBが「Auroraレプリカ」となる。
注意点
EC2のオートスケーリング、Auroraのオートスケーリングはどちらもインスタンスそのものを自動的に増やしているが、RDSのオートスケーリングは、データを格納する容量を自動的に増やしている点に注意する。
日常生活で例えると、家を掃除する際に、掃除する人を増やすという観点がEC2やAuroraのオートスケーリングに該当し、掃除する時の収納を増やすという観点がRDSのオートスケーリングに該当すると考える。
RDSのオートスケーリングは推奨されるのか？
ちなみに、データロード(DBの読み取り)の増加が予想される場合は (RDS DB インスタンスの現在のストレージサイズの 20% を超えるロードなど)、データロードの前に RDS DB ストレージのサイズを手動で増加させることがベストプラクティスであると公式ページに記載されている。
そのため、推奨設定ではないと考えている。
5. RDSーマルチAZ構成
RDSが強靭な高可用性や耐障害性を実現するための構造であるマルチAZ構成とは、複数のデータセンターであるAZに対してRDSが配置される構造のことを言います。
起動時に用意されているマルチAZオプションをオンにすると、自動的に２つのRDSを２つのAZに渡って構築してくれる仕組みになっています。
RDSはマスター(プライマリ)とスレーブ(セカンダリ)という関係性があり、マスターへの変更が自動的にスレーブに反映されます。
またこの仕組みをレプリケーションと呼び、その中でもマスターへの変更後にスレーブの変更が完了してから応答するため同期レプリケーションと言います。
同期レプリケーションは、スレーブへのデータの反映を待つ時間だけ遅延が生じますが、データベース障害の影響を最小限に抑えることができます。
6. RDSーフェイルオーバー
フェイルオーバーとは、予備も一緒に動かしている(ホットスタンバイ)システムにおいて、メインサーバーに障害が発生した時に自動的に予備サーバーに切り替えてくれる機能を指します。
フェイルオーバーの目的は「サービスの継続稼働のための最小ダウンタイムの実現」です。
アプリケーションやサービスが停止すると非常に困るという場面において、障害発生時に稼働可能なサーバーに切り替えることで、サービスを停止することなく最小限のダウンタイムで安定稼働させられる仕組みになっています。
フェイルオーバーの目的は「サービスの継続稼働のための最小ダウンタイムの実現」です。
アプリケーションやサービスが停止すると非常に困るという場面において、障害発生時に稼働可能なサーバーに切り替えることで、サービスを停止することなく最小限のダウンタイムで安定稼働させられる仕組みになっています。
7. RDSーリードレプリカ
リードレプリカとは、マスターからレプリケーションされた読み込み専用のデータベースです。
リードレプリカを複数設置させることで、読み込みが多いサービスではデータベース１つにかかる負荷を削減させ、データベースの負荷分散をすることができます。
読み込み専用のため、データ読み込み時はリードレプリカが処理を実行し、その他の削除 / 更新 / 追加に対してはマスターが処理を実行します。
また、より可用性を向上させるためには複数のリードレプリカへのルーティングをロードバランサーによって負荷分散させる方法もあります。
※データベースに対する設定によって、どのデータベースに処理させるかはAWSでの設定ではなくプログラムに書く必要があります。
8. RDSースペック不足時にはスケールアップ
RDSは、EC2と同様にインスタンスタイプをスケールアップすることができます。
CPUのスペック不足を感じた場合、コンソールからボタン１つでインスタンスタイプの変更が可能です。
インスタンスタイプの変更には、必ずインスタンスの停止が必要になるので、必然的にフェイルオーバーが実行されます。
それによりサービス自体を一時的に停止させなければならないため、サービスをリリースする前にできるだけスケールアップの必要がないよう、余裕のある設計が大切になります。
CPUのスペック不足を感じた場合、コンソールからボタン１つでインスタンスタイプの変更が可能です。
インスタンスタイプの変更には、必ずインスタンスの停止が必要になるので、必然的にフェイルオーバーが実行されます。
それによりサービス自体を一時的に停止させなければならないため、サービスをリリースする前にできるだけスケールアップの必要がないよう、余裕のある設計が大切になります。
9. AWS WAF
AWSの提供するWAF(ウェブアプリケーションファイアウォール)で、Webサイトを含めたWebアプリケーションをサイバー攻撃から守るツールです。
ファイアウォールやIPSなどほかのセキュリティツールでは防御できない、Webアプリケーション層への攻撃を検知・遮断できるのがWAFの特徴です。
近年、WAFへの注目が高まっています。
SQLインジェクションやクロスサイトスクリプティング（XSS）など、Webアプリケーションの脆弱性を突くサイバー攻撃が増えてきたというのが原因の1つです。
また、検知ルールのカスタマイズもできます。
AWSが提供している基本的なルールセットや、Linux OSやWordPressなどのルールセットやAWS Marketplaceセラーが販売しているルールセットを導入することによって、より自社のシステムに合う検知ルールを選ぶことができます。