SAA学習-信頼性設計-RDSによるマスタースレーブ構成
今回のテーマ：RDSによるマスタースレーブ構成のハンズオン実施
構成
事前準備(今回は概略と関連リンクを記載しておきます。)
- NATGWの作成およびElasticIPの払い出し
- ルートテーブルの関連づけ
before
after
- ELBの作成
- イメージの作成
- 起動設定およびAuto-ScalingGroupの作成(希望、最小を0台にしておくとよいかと思います。)
実施する項目が分かれば、ここまで20分程度で実装は可能だと思います。
実際の手順(RDB作成まで)
- マネージメントコンソール-RDSと検索しクリック
- サブネットグループよりDBサブネットグループを作成をクリック
- サブネットは構成図に合わせてプライベートサブネットを指定し、作成をクリック
- データベースよりデータベースの作成をクリック
- MySQLを選択とエンジンバージョンを指定します。
- マルチAZ構成にしたいため、学習用ですが開発/テストを選択します。
- DB識別子を指定し、マスターユーザーのアカウント情報を登録します。
- インスタンスサイズを指定します。(デフォルトたとm系のファミリアーとなるため要注意)
- ストレージサイズタイプやサイズなどを指定します。(ストレージタイプを汎用にしておけば安価にすみます)
また、自動スケーリングは有効としておき最初はスモールスタートにしてスケーリングをさせる方が実務ではよく使用されます。
- マルチAZ配置でスタンバイインスタンスを作成するを指定します。
- 認証方式を指定します。
- 追加設定でRDB名を任意で記載し、パラメータグループを指定します。(実務だと先にパラメータグループを使用する方が望ましいです)
- バックアップの取得方式などを確認します。(サイクルなど指定があれば変更します)
- モニタリング(監視の指定)およびログの出力に関して確認します。(すべて有効化しておくことが望ましいですが割愛します)
- 定期メンテナンスの指定を行います。(パッケージソフトとかのバージョンアップ対応を考慮するとマイナーバージョンの自動アップグレードの有効化は外す方がよいです)
- 利用コストを確認し、データベースの作成をクリック
cf)RDBへ日本時間に合わせるなどのオプションを指定する場合、オプショングループを新規に作成し作成したRDBへ適用します。(今回は割愛)
cf)実運用上ですと定期的にAmazon RDS SSL/TSL証明書を更新する作業があります。
- 作成したRDBが利用可能な状態になっていることを確認します。
- 新規でSGを作成すると「/32」の固定IPのみの指定となるため、VPC内のサブネットを許可する設定に変更するため、
適用しているセキュリティグループを選択し、インバンドルールの編集をクリック
実際の手順(RDBの接続確認・設定・リストア試験)
- mysqlコマンドを使用できるようにするため以下コマンドを実行
コマンド
yum install mysql -y
実行結果
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Resolving Dependencies --> Running transaction check ---> Package mariadb.x86_64 1:5.5.68-1.amzn2 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: mariadb x86_64 1:5.5.68-1.amzn2 amzn2-core 8.8 M Transaction Summary ================================================================================ Install 1 Package Total download size: 8.8 M Installed size: 49 M Downloading packages: mariadb-5.5.68-1.amzn2.x86_64.rpm | 8.8 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : 1:mariadb-5.5.68-1.amzn2.x86_64 1/1 Verifying : 1:mariadb-5.5.68-1.amzn2.x86_64 1/1 Installed: mariadb.x86_64 1:5.5.68-1.amzn2 Complete!
- 作成したRDBへ接続します
コマンドひな形
mysql -h RDBのエンドポイント名 -u ユーザー名 -p
コマンド例
mysql -h mysql.cupngjp8wkyf.ap-northeast-1.rds.amazonaws.com -u admin -p
- パスワードが聞かれれるため応答し、RDBへ接続します。
- DBを作成します。
コマンド
create database testdb;
- DBへ接続します。
コマンド
use testdb;
- 試験用のテーブルを作成します。
コマンド
create table testdb.account(id int,name varchar(20));
- 作成したテーブルを確認します。
コマンド
show tables;
- 作成したテーブルに対しデータを入れます。
コマンド
insert into account values(1001,"testuser1"); insert into account values(1002,"testuser2");
- テーブルへインポートしたデータを確認します。
コマンド
select * from account;
結果のまとめ
実際の手順(RDBの復元確認)
- スナップショット名は任意で記入し、スナップショットの取得をクリック
- 利用可能であることを確認します。
- ターミナルに戻り追加のデータをインポートします。
insert into account values(1003,"testuser3");
結果
- RDBをいったん削除するため、DBからの接続を切ります。
コマンド
quit
業務の場合、RDBのインスタンス識別子を合わせるリストア対応が必要となります。
対応する方法は稼働しているインスタンスを削除し、スナップショットから復元します。
- マネージメントコンソールへ戻り、稼働しているRDBを選択しアクションから削除を選択します。
- 削除確認画面で、最終スナップショットの取得とフレーズ入力を記入後、削除をクリック
- 削除されたことを確認します。
- マネージメントコンソールへ戻り、取得したスナップショットを選択し、アクション-スナップショットを復元をクリック
- インスタンス識別子を基のものと同じ値にします、
- SGとサブネットは先程と同じものを指定します。
- インスタンスサイズおよびストレージも同様に指定します。
- 後の設定も同様に指定します。
- 追加設定の値も同様に設定指定したら、DBインスタンスの復元をクリック
- リストアされていることを確認します。(この状態までいけば接続確認はできたはずです)
- ターミナルに戻りRDBへ接続します
コマンド例
mysql -h mysql.cupngjp8wkyf.ap-northeast-1.rds.amazonaws.com -u admin -p
- DBへ接続し、先程のテーブルを確認します。
確認までの経緯ログ
MySQL [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test_rdb | | testdb | +--------------------+ 5 rows in set (0.00 sec) MySQL [(none)]> use testdb Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MySQL [testdb]> show tables; +------------------+ | Tables_in_testdb | +------------------+ | account | +------------------+ 1 row in set (0.00 sec) MySQL [testdb]>
- testuser3が存在していないことを確認し問題ないことを確認します。
MySQL [testdb]> select * from account; +------+-----------+ | id | name | +------+-----------+ | 1001 | testuser1 | | 1002 | testuser2 | +------+-----------+ 2 rows in set (0.00 sec) MySQL [testdb]>
cf) スナップショットから復元したい場合、特定地点からの復元は稼働指定できなかったため、
リストア手法を要注意となります。(少し確認をしておきます。)
実際の手順(RDBの自動F/Oとリードレプリカの作成)
リードレプリカを作成するため、自動バックアップが有効である必要があります。
動作確認をするため1回再作成を実施しておきます。
リードレプリカの作成
- マネージメントコンソールよりデータベース-対象のRDBを指定し、アクションからリードレプリカの作成をクリック
- インスタンスタイプとマルチAZ配置の指定をします。(今回はそのまま)
- リージョン、サブネット、AZ、SGを指定します。(AZのみ指定しておきます。)
- DB識別子を指定します。(レプリカなどわかる名称の方がよいかも)
- その他の設定は変更せず、リードレプリカの作成をクリック
- リードレプリカが作成されたことを確認します。(画面ではレプリカ側が作成中ですがここまでいけば大丈夫です)
自動F/Oの動作確認
- マネージメントコンソールよりデータベース-対象のRDBを指定し、アクション-再起動をクリック
- フェイルオーバーで再起動にチェックを入れて、確認をクリック
- リージョンとAZがF/O先に変更されていることを確認します。
今回のテーマは以上です。
cf)検証用で使用したリソースをすべて削除しておかないと結構いい金額が発生するので、
失念しないようにしてください。
SAA学習-Route53-Route53の概要
今回のテーマ：Route53の概要
主要サービスの公式資料
Route53： docs.aws.amazon.com
概要
Amazon Route 53は、可用性と拡張性に優れたドメインネームシステム (DNS) ウェブサービスです。
DNSの概要について以下のものが挙げられます。
DNS
- DNSはインターネット上で名前解決をする仕組み
- 名前解決とはインターネットにおける人向けのUIRLをシステム向けの住所となるIPアドレスに変換するための仕組み
- 企業サーバーに一時的なDNS情報を保持するキャッシュDNSサーバーと実際に名前解決機能がある権威DNSサーバーの2種が存在
Route53とは
- Route53はAWSが提供する権威DNSサーバー
- Route53はDNSレコードというIPアドレスうとURLを紐づけた表を確認しルーティングを行う
- ポート53番で動作しルーティング定義するためサービス名の由来となる
Route53の特徴
- 主要機能はドメイン登録/DNSルーティング/ヘルスチェックの3つ
- ポリシーによルーティング設定
設定概要は以下のものが挙げられ様々ルーティングを設定可能
- AWS側で100%可用性を可能とするSLA
- マネージドサービスとして提供しており、ユーザー側で冗長性を考慮は不要
Route53の利用方法
Route53の利用を開始後、ドメインを登録するとホストゾーンを自動生成し、そこにルーティングを設定します。
利用ステップとしては以下の4ステップになります。
①Route53にドメインを設定
②ドメイン名と同じホストゾーンを自動生成
③ホストゾーンにルーティング方法となるDNSレコードを作成
④トラフィックルーティングを設定
ホストゾーン
ドメインとそのサブドメインのトラフィックのルーティングをする方法について情報を保持するコンテナとなります。
cf)ドメインの例：example.com
cf)サブドメインの例：sub.example.com
パブリックホストーゾーン
プライベートホストゾーン
- VPCに閉じたプライベートネットワーク内のDNSドメインのレコード管理をするコンテナ
- VPC内のDNSドメインに対し、どのようにトラフィックをルーティングするかを定義
- 1つのプラベートホストゾーンで複数VPCに対応
- VPCが相互アクセス可能であれば複数リージョンのVPCでも同じホストゾーンを利用可能
DNSレコード
ルーティング方法を設定するため。DNMSレコードを作成し各種レコードを設定する。
主なレコードタイプは以下となります。
| レコードタイプ | 概要 |
|---|---|
| SOA | ドメインのDNSサーバー/ドメイン管理のメールアドレス/知り合う番号等を保持し、ゾーン転送時に情報が更新されているかの判断に利用する |
| A | ホスト名とIPアドレスの関連付けを定義するレコード |
| MX | メール配送先(メールサーバー)のホスト名を定義するレコード |
| CNAME | 正規ホスト名に対する別名を定義するレコード。特定のホスト名を別のドメイン名に転送するときなどに利用する |
その他DNSレコードの参考文献： docs.aws.amazon.com
ALIASレコード
Route53固有の仮想リソースレコードになります。
ALIASレコードの概要
DNSクエリにAWSサービスのエンドポイントIPアドレスを返答する機能となります。
設定が可能な項目は以下となります。
- 静的WEBサイトをして設定されたS3バケット
- CloudFront
- ELB
- ホストゾーン内のリソースレコードセット
ALIASレコードのメリット
- DNSクエリに対するレスポンスが高速
- CNAMEにマッピングできないZoneApex(ドメイン名そのもの)を設定可能
- ALIASレコードに対するクエリが無料でありRoute53と連携したDNSLookupを高速化する
- CloudFrontでのクエリ回数を削減
トラフィックルーティングのタイプ
ルーティング方式として以下の内容があります。
シンプルルーティング(Simple)
加重ルーティング(Weighted)
- 複数のエンドポイント毎の重み設定によりDNSクエリに応答
- 重みづけの高いエンドポイントに多くルーティング
フェイルオーバールーティング(Failover)
- ヘルスチェックの結果に基づいて、利用可能なリソースをDNSクエリに応答
- 利用可能なリソースにのみルーティング
複数値回答ルーティング(Multivalue)
- ランダムに選ばれた最大8つの別々のレコードを使用しIPアドレスを設定し、複数の値を返答
- IPアドレス単位でヘルスチェックを実施し、ルーティングすることで、正常なリソース返す
- ELBに代わるものではないが、正常なことが確認できる複数のIPアドレスを返す機能により、DNSを利用しアベイラビリティとロードバランシングを向上させることが可能
レイテンシールーティング(Latency)
- リージョンの遅延によりDNSクエリに応答
- 基本的にはユーザーの際よりのリージョンに返答
- リージョン間の遅延が少ない方へルーティング
位置情報ルーティング(Geolocation)
- ユーザーのIPアドレスにより位置情報を特定し、地域ごとに異なるレコードを返す
- ネットワーク構成に依拠しない制度の高いレコードの区分けが可能
地理的近接性ルーティング
- ユーザーとリソースの場所に基づいて地理的近接性ルールを作成し、トラフィックをルーティング
- 必要に応じてバイアスを設定し、特定のリソースにルーティングするトラフィック量を変更可
- トラフィックフローを利用する必要
トラフィックフロー
従来はALIASレコードを使用し、複雑なルーティングポリシーを作成する対応が必要でした。
レコードに対しフロー図をエディタで作成するような設定方法となります。
今回のテーマは以上です。
SAA学習-信頼性設計-Auto-Scalingの設定
今回のテーマ：Auto-Scalingの設定
実装構成
実施する手順
ここは今回省略します。
- サブネット作成/自動パブリックIPの有効化
- ElasticIPの払い出し/NATGWの作成
- ルートテーブルの更新(サブネットの関連付けおよびNATGWの更新)
- ELBの作成
- EC2の起動テンプレート作成(ヘルスチェックするためのOSSなどをきちんと導入しておかないとドはまります)
今回の実施する概要
- 起動設定の作成
- Auto-Scalingグループの作成
実際の手順(起動設定の作成)
- マネージメントコンソール-EC2-Auto Scaling-起動設定の順に選択し、起動設定の作成クリック
- 起動設定名は任意で記載し、AMIの指定が作成しているAMIを指定し、インスタンスタイプは無料枠のものを指定します。
- 追加設定は特にしてせず、ストレージサイズも変更しなくてよいです。
- SG(セキュリティグループ)とキーペアを指定し、起動設定の作成をクリック(キーペアの承諾チェックは入れてください)
大枠はEC2インスタンスを起動する際の設定を1つの画面でできるという点になります。
実際の手順(Auto-Scalingグループの作成)
*マネージメントコンソール-EC2-Auto Scaling-Auto Scalingグループの順に選択し、Auto Scalingグループの作成をクリック
- 名称は任意で記載し、先程作成した起動設定を指定後、次へをクリック
- インスタンスの購入タイプは起動テンプレートに準拠を選択し、ネットワークはAZ間で分散するようにサブネットを2つ設定し、次へをクリック
- グループキャパシティで、希望する台数と最小、最大台数を指定します。また、スケールイン(台数増加のポリシー)を指定し、次へをクリック
※グループキャパシティは希望する台数は最小と最大の間の台数で設定
※スケールインは増加、スケールアウトは減少となります。
- AutoScalingで作成/削除されたインスタンスがあったらメール通知を行うか設定しますが、割愛するため、次へをクリック(実務では必要になる場合がほとんどです)
- タグは任意で記載し、次へをクリック
- 設定確認になったら内容を確認し、Auto Scalingグループを作成をクリック
- Auto-Scalingグループを作成後インスタンスが希望台数稼働します。
- ELB経由でアクセスできることを確認します。
実際の手順(Auto-Scalingグループのスケールイン/アウト動作確認)
試験用にインスタンスを立ち上げた状態より確認します。
- アタッチするAuto Scalingグループを指定し、アタッチをクリック
- しばらく時間を経過するのを待ってから作成したAutoScalingポリシーより、希望する台数まで減少することを確認します。(この場合は起動した後の方が残るため、登録した方が削除されます)
負荷テストによるAuto 負荷試験による動作確認
- 負荷ツールをダウンロードします
コマンド
wget https://rpmfind.net/linux/dag/redhat/el7/en/x86_64/dag/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm
結果
wget https://rpmfind.net/linux/dag/redhat/el7/en/x86_64/dag/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm --2021-06-06 13:21:15-- https://rpmfind.net/linux/dag/redhat/el7/en/x86_64/dag/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm Resolving rpmfind.net (rpmfind.net)... 195.220.108.108 Connecting to rpmfind.net (rpmfind.net)|195.220.108.108|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 36804 (36K) [application/x-rpm] Saving to: ‘stress-1.0.2-1.el7.rf.x86_64.rpm’ 100%[======================================>] 36,804 147KB/s in 0.2s 2021-06-06 13:21:16 (147 KB/s) - ‘stress-1.0.2-1.el7.rf.x86_64.rpm’ saved [36804/36804]
- 負荷ツールをインストールします
コマンド
rpm -ivh stress-1.0.2-1.el7.rf.x86_64.rpm
結果
warning: stress-1.0.2-1.el7.rf.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY Preparing... ################################# [100%] Updating / installing... 1:stress-1.0.2-1.el7.rf ################################# [100%]
- 負荷ツールがインストールされたか確認します
コマンド
rpm -qa|grep stress
結果
stress-1.0.2-1.el7.rf.x86_64
- 負荷ツールのバージョンを確認します
コマンド
stress --version
結果
stress 1.0.2
- マネイジメントコンソールで負荷をかける前の状態を確認します。(希望台数1台、最大3台)
- サーバーで負荷ツールを実行します
コマンド
stress -c 1 -q &
結果
[1] 29723
- 負荷ツールを実行した後の状態を確認します
コマンド
top
結果
※ctrl+cでtopの実行状態を終了できます
- AutoScalingポリシーで新規インスタンスが起動するか確認します(モニタリングの間隔があるためそれに合わせて起動する動作となります)
- インスタンスでも同様に確認できます
- 確認が取れたら負荷をかけているサーバーで負荷ツールのプロセスを確認します
コマンド
ps -ef | grep stress | grep -v grep
結果
root 29723 29646 0 13:28 pts/0 00:00:00 stress -c 1 -q root 29724 29723 99 13:28 pts/0 00:11:37 stress -c 1 -q
- 負荷ツールのプロセスを強制終了します(エラーなくコマンドが終わります)
コマンド
kill -9 29723
- 負荷ツールのいプロセスが稼働してないことを確認します(何もプロセスが動作してない状態になります)
コマンド
ps -ef | grep stress | grep -v grep
- 再度スケールアウトされているか確認します
今回のテーマは以上です。
補足：動作確認など終わったらAuto Scalingポリシーで自動起動させないようにするため、グループキャパシティの値をすべて0台しておくとよいです
- マネージメントコンソール-AUTO SCALING-Auto Scaling Group-作成したAutoScalingグループ-詳細タブの順に選択し、グループの詳細から編集をクリック
- 希望する容量と最小キャパシティおよび最大キャパシティを0にして、更新をクリック
今回のテーマは以上です。
SAA学習-信頼性設計-RDSの概要
今回のテーマ：RDSの概要
RDS
RDSは様々なデータベースソフトウェアに対応したフルマネージドなリレーショナルデータベースとなります。
ソフトウェアの種類は以下のものなどがあります。
AWSのデータベース構築
AWSにおけるデータベース構築はEC2に自らインストールするか専用DBサービスを利用するかの2通り
| ケース | メリット | デメリット |
|---|---|---|
| EC2の場合 | 自由にDB構成や機能を利用 | 構築・運用が手間 |
| RDSの場合 | 構築・運用が楽(大部分がAWS側) | AWS提供の範囲内での利用制限 |
RDSの制約事項
RDSはマネージド型で便利な反面、AWSから提供される機能範囲内で制限を受けます。
主な制限事項としては以下となります。
RDSの特徴
- RDS自体がマネージド型の更改用なのに加え、マルチAZによるMaster/Slave構成を容易に構築することが可能
- 参照専用のレプリカを最大5台(Auroraは15台)設置可能で、DBの読み取り処理をスケールアウトが可能
- 自動/手動でスナップショットを取得し、保存管理することで耐障害性を確保することが可能
スケーリング
マネージメントコンソールやAPIからスケールアップ可能
- インスタンスタイプを変更しスケールアップ/ダウンを実施
- コマンドライン(AWS CLI)やAPIからストレージを数クリックで容易にスケールアップ/ダウンが可能
- 一時的にインスタンスタイプを大きくしてその後戻すことも可能
- ストレージサイズは拡張はできるが縮小ができない
データベースのシャーディング(水平分割)機能を利用し、RDSの書き込みをスケーリングすることが可能
DBインスタンスの暗号化
保管時のインスタンスとスナップショットの暗号化が可能となります。 暗号化対象と暗号化方式は以下のものになります。
暗号化対象
- DBインスタンス
- 自動バックアップ
- リードレプリカ
- スナップショット
暗号化方式
RDSのスケーリング
データベースのパフォーマンス低下に対しスケーリング対応を実施することが可能
パフォーマンスの低下させる要因：アクセス多数、クエリ処理の増加など
スケーリングのタイプ
スケーリングのタイプは垂直スケーリングと水平スケーリングの2つのタイプがあります。
垂直スケーリング
- 拡張方法(スケールアップ)：メモリやCPUの追加・増強
- 低減方法(スケールダウン)：メモリやCPUの削減・低性能化
水平スケーリング
- 拡張方法(スケールアップ)：処理を行う機器/サーバー台数の増加
- 低減方法(スケールダウン)：処理を行う機器/サーバー台数の低減
スケールアップ
インスタンスタイプやサイズを変更することでスケールアップによるパフォーマンス向上を実施することが可能
| 実施方法 | 概要 |
|---|---|
| インスタンスサイズの変更 | 現在のDBインスタンスタイプに対しサイズを高性能なものに変更することで、パフォーマンスを向上させる |
| インスタンスタイプの変更 | 現在のDB利用方式に適したDBインスタンスタイプがある場合、そのタイプに変更する |
| ストレージタイプの変更 | ストレージタイプを高性能なタイプ(I/O処理が多い場合IOPS)に変更する |
インスタンスタイプ
最初のDBがDBインスタンスを表し、その後のアルファベットと数字がインスタンスタイプになります。
インスタンスタイプの後に大きさ(micro/largeなど)の表示がインスタンスサイズとなります。
RDSインスタンスタイプの詳細：Amazon RDS インスタンスタイプ | AWS
インスタンスタイプとサイズ
2つのインスタンスタイプ
- 汎用：バランスの取れたコンピューティング、メモリ、ネットワークリソースを提供し、多様なワークロードに使用できるインスタンスタイプ
- メモリ最適化：メモリ内の大きいデータセットを処理するワークロードに対し高速なパフォーマンスを実現するように設計されたインスタンスタイプ(高速データベースにはメモリ最適化を利用する)
インスタンスタイプ：汎用
バランスが取れた対応が可能なMファミリーとバーストパフォーマンスが提供されるTファミリーが利用可能
| タイプ | 概要 |
|---|---|
| T2インスタンス | 汎用バーストパフォーマンスインスタンス。 ベースラインレベルのCPUパフォーマンスを提供し、ベースラインを越えてバーストする機能を有する。 マイクロサービス、テストおよびステージングなど様々なデータベースワークロードに適している |
| T3インスタンス | T2インスタンスと同じく汎用バーストパフォーマンスインスタンス。 T3インスタンスはバランスの取れたコンピューティング、メモリ、およびネットワークリソースを提供し、使用中に一時的なスパイクが生じる中程度のCPU使用率を持つデータベースワークロードに適している |
| M4インスタンス | バランスの取れたコンピューティング、メモリ、およびネットワークリソースを提供し、オープンソースまたはエンタープライズアプリケーション用の小規模および中規模データベースを含む様々なデータベースワークロードに適している |
| M5インスタンス | 最新世代の汎用インスタンスでM4より優れたパフォーマンスを提供する。 バランスの取れたコンピューティング、メモリ、およびネットワークリソースを提供し様々なデータベースワークロードに適している |
インスタンスタイプ：メモリ最適化
メモリ負荷の高い処理や高速データベース処理に利用する
| タイプ | 概要 |
|---|---|
| R4インスタンス | メモリ負荷の高いデータベースワークロード向けに最適化されており、RAM GiBあたりのメモリ華夏がR3よりも安価 |
| R5インスタンス | R4よりもvCPU当たり5%大きいメモリを適用する最新世代のメモリ最適化インスタンス。 最大で768 GiBのメモリを提供する。 R4と比較しGiBごとの価格が10%低く、CPUパフォーマンスも最大20%高い |
| X1インスタンス | 大規模アプリケーション、エンタープライズクラスのアプリケーション、およびインメモリアプリケーション用に最適化されたインスタンス。 Amazon RDSのインスタンスタイプの中でもRAM 1GiB当たりの価格が最も低いインスタンスの1つ |
| X1eインスタンス | 高性能データベースように最適化されたインスタンス。 X1eインスタンスはAmazon RDSのインスタンスの中でもRAM 1GiBあたりの価格が最も低いインスタンスの1つ |
| Z1dインスタンス | クラウドインスタンスの中で最も高速で、すべてのコア周波数が4.0GHzで持続可能。 高いコンピューティング性能と大容量メモリの組み合わせにより、Z1dインスタンスはコア単位のライセンス費用が高いリレーショナルデータベースに最適 |
ストレージタイプの変更
ストレージタイプは汎用とプロビジョンドIOPSタイプから選択します
マグネティックは古いタイプのためあまり利用しません
| ストーレジタイプ | 概要 |
|---|---|
| 汎用 | ・SSDタイプ ・GB当たりの容量課金 ・通常のパフォーマンスに加えてバーストを実施し100～10,000IOPSを実現可能 |
| プロビジョンドIOPS | ・SSDタイプ ・GBあたりの容量課金を実施+プロビジョン済みIOPS単位の課金 ・通常のパフォーマンスに加えてバーストを実施し、1,000～30,000IOPSを実現可能 |
| マグネティック | ・ハードディスクタイプ ・GBあたりの容量課金を実施＋IOリクエスト課金 ・平均100～最大数百のIOPS |
ストレージサイズの容量変更
ストレージ容量は設定変更で増加することは可能ですが、減少させることはできない
ストレージサイズのAutoScaling
ストレージ容量に対しAutoScalingを実行することが可能
RDSのスケールアウト
リードレプリカの増設、キャッシュによる高速化が可能
また、全く別のDBへ変更するAuroraへの移行も可能
- リードレプリカの増設： 読込処理のアクセス集中を分散化するため、読込専用インスタンスとなるリードレプリカを増設し、負荷分散を行う
- キャッシュの利用：ElastiCacheを連携または、MySQL Memcached機能を利用し、キャッシュを増設し、読込処理の高速化を実施する
- Auroraへの移行：RDS MySQLを高速なAurora MySQLへと移行することが可能で、性能アップさせることが可能です(厳密にはスケールアウトではありません)
リードレプリカの増設
フェイルオーバー設定を有効にするだけで、容易にフェイルオーバーが利用可能となります
概要は以下となります。
- 最大5台(Auroraの場合は15台) までリードレプリカを増設可能
- マルチAZやクロスリージョンとも併用可能
- インスタンスやストレージを異なるタイプに設定可能
- 障害対応などでリードレプリカから、スタンドアロンDBインスタンスに手動で変更可能(Aurora以外)
- Auroraの場合、プライマリーインスタンスに昇格可能
RDSの構成比較
マルチAZとマルチリージョンと比較しリードレプリカはスケーリングに特化した構成方式となります。
| マルチAZ配置 | マルチリージョン配置 | リードレプリカ | |
|---|---|---|---|
| 目的 | 高可用性 | 災害復旧とローカルパフォーマンス | スケーラビリティ |
| 同期方式 | Aurora 以外: 同期レプリケーション Aurora: 非同期レプリケーション |
非同期レプリケーション | 非同期レプリケーション |
| アクセス | Aurora 以外: プライマリインスタンスのみがアクティブ Aurora: 全インスタンスがアクティブ |
すべてのリージョンにアクセスでき、読み取りに使用できる。 | すべてのリードレプリカにアクセス可能で、読み込みのスケーリングに使用可能 |
| バックアップ | Aurora 以外: 自動バックアップはスタンバイから取得される。 Aurora: 自動バックアップは共有スト レージレイヤーから取得される。 |
各リージョンで自動バックアップを取得可能 |
デフォルトではバックアップは構成されない |
| 配置 | 1 つのリージョン内に常に 2 つ以上のアベイラビリティーゾーンを展開 | 各リージョンに対してマルチ AZ 配置が可能 |
アベイラビリティーゾーン内、AZ 間、またはリージョン間に配置可能 |
| 切替 | 問題が検出された場合のスタンバイ (Aurora 以外) またはリードレプリカ (Aurora) への自動フェイルオーバー |
Aurora は、セカンダリリージョンのプロモーションをマスターに昇格可能 | 手動でスタンドアロンのデータベースインスタンスに昇格可能 (Aurora 以外) Auroraはプライマリインスタンス に昇格可能 |
キャッシュの利用
読込処理の一部をキャッシュとして保持して、高速クエリ処理を実現する構成が可能
- ElastiCacheの利用
AWSが提供するインメモリDBサービスであるElastiCacheを利用してクエリ処理をインメモリDBに保持して高速処理を可能にする
- MYSQLのオプション機能の利用
MYSQLのオプション機能にあるMemcachedを利用してインメモリキャッシュを利用する
Auroraへの移行
RDSのMySQLとPostgreはAuroraと互換性があるバージョンは容易に移行が可能で、パフォーマンスを向上させることができる
今回のテーマは以上です。
SAA学習-信頼性設計-Auto-Scalingの概要
今回のテーマ：Auto-Scalingの概要
主要サービスの公式資料
Amazon EC2 Auto Scaling： docs.aws.amazon.com
スケーラビリティの確保
需要増にトラフィック量が処理できなくなる前に処理サーバーを拡張することで対処を可能とする。(ELBでトラフィックを確認し需要増)
スケーリングのタイプ
スケーリングタイプは垂直スケーリングと水平スケーリングの2つのタイプがあり、Auto-Scalingは水平スケーリングタイプとなります。
垂直スケーリング
- 拡張方法(スケールアップ)：メモリやCPUの追加・増強
- 低減方法(スケールダウン)：メモリやCPUの削減・低性能化
水平スケーリング
- 拡張方法(スケールアップ)：処理を行う機器/サーバー台数の増加
- 低減方法(スケールダウン)：処理を行う機器/サーバー台数の低減
Auto-Scalingの要素
- Auto-Scalingグループ
- Auto-Scaling configuration：起動設定
- Auto-Scaling Pan
Auto-Scalingグループ
スケールするインスタンスの最大数など基本情報を設定する。
- 起動インスタンスの際小数と最大数を設定
- 今時点で必要なインスタンス数(Desired Capacity)の数量になるようにインスタンスを起動/終了を調整
- 起動台数をAZ間でバランシング
- AZ障害児は障害のない別のAZにその分インスタンスを起動
Auto-Scaling configuration：起動設定
スケールアウトの際、起動するインスタンス内容を設定します。
設定項目はいかのものが挙げられます。
- AMI
- インスタンスタイプ
- セキュリティグループ
- キーペア
- IAMロール
Auto-Scaling Pan
どのようにスケールするかの方法で以下のものを定義します。
- Auto-Scaling Groupサイズの維持：現在のAuto-Scaling Groupのインスタンス最小台数を維持する設定を行う
- 手動スケーリング：設定外で予期せぬスケーリングが必要となった場合、手動でスケーリングを実施
- スケジュールベース：予想された需要増時期に合わせたスケーリングスケジュールを設定
- 動的スケーリング：予測不能なケースにスケーリングポリシーにスケール方針を設定し、動的にスケールアウトを実施
また、上記のプランについて複数組み合わせて利用することが可能 例：スケジュールベースで設定を実施後、スケジュールベース設定を超過したら動的スケーリングを有効にするなど
ヘルスチェック
Auto-Scaling配下のEC2のヘルスチェックはEC2のステータス情報またはELBのヘルスチェックのどちらかを利用します。
- EC2ステータス：インスタンスのステータスがrunning以外の状態を異常と判断する
- ELB：ELBのヘルスチェック機能を活用する
ターミネイションポリシー
需要減に基づくスケールインの際、どのインスタンスから終了するか設定します。
- OldestIntance/NewInstance：最も古いインスタンスや新しい起動自国のインスタンスなど順番で終了
- OldestLaunchConfiguration：最も古い起動設定により、起動しているインスタンスから終了
- ClosestToNextInstanceHour：次の課金が始まるタイミングで最も近いインスタンスから終了
- デフォルト設定：「OldestLaunchConfiguration」から「ClosestToNextInstanceHour」の順に適用する。その後複数インスタンスが残った場合、ランダムに終了する。
Auto-Scalingの連携
ELBのヘルスチェックやCloudWatchのアラーム機能をトリガーにしスケールイン/アウトの条件として利用できます。
Auto-Scalingの基本構成
ELB構成冗長化したEC2に対しAuto-Scalingを設定し自動拡張できるような構成となります。
概略図：
Auto-Scalingの設定プロセス
Auto-Scalingの設定する順番は以下のように実施します。
①ALBの作成
②ターゲットグループの作成
③起動するインスタンス設定
④Auto-Scalingグループ作成
⑤Auto-Scalingポリシーの作成orスケジュール設定
Auto-Scalingの設定ポイント
- インスタンスの最大値/最小値の設定は慎重に設定
- ステートフルなアプリケーションへの設定は、Auto-Scaling Groupでの自動設定が必要
- ライフサイクルフック(起動時または削除時にインスタンスを一時停止しカスタムアクションを実行)を使用
- Auto-Scalingスラッシング(急なスケールインによる影響)を避ける
今回のテーマは以上です。
SAA学習-信頼性設計-ELBによる冗長構成
今回のテーマ：ELBによる冗長構成
今回の構成
- VPCの作成
- ELBの作成
- バランシング設定
実際の手順(VPCの作成)
- パブリックとプライベートを持つVPCで、VPC名は任意で記載し、CIDRブロックはAZを含め値を確認し、Elastic IPを作成済みの状態で、VPCの作成をクリック(作成完了するまで数分かかります。またNATGWを作成済みでElastic IPを指定すると作成に失敗します。)
- VPCの作成が完了したら、OKをクリック
- マネージドコンソール-VPC-VIRTUAL PRAVATE CLOUD-サブネットの順に選択し、サブネットを作成をクリック(AZ1-c用のパブリックとプライベートサブネットを作成するため)
- VPCIDは作成したVPCを指定し、サブネット名はパブリック/プライベート-1cと記入とCIDRは指定の値を記入し、サブネットを作成をクリック(パブリック-1c用のサブネット作成分となります。)
パブリックサブネット-1c
プライベートサブネット-1c
- マネージドコンソール-VPC-VIRTUAL PRAVATE CLOUD-ルートテーブルの順に選択し、ルーティングの設定を確認
パブリック用のルートテーブル
- ルートにインターネットGWへのターゲットが指定を確認
- サブネットの関連付けでパブリック用のサブネットが2つ指定を確認
プライベート用のルートテーブル
- ルートにNATGWへのターゲットが指定を確認
- サブネットの関連付けでプライベート用のサブネットが2つ指定を確認
パブリックサブネット側のみインスタンス作成時に、自動IPの割りあえてを有効化します。
- マネージドコンソール-VPC-VIRTUAL PRAVATE CLOUD-サブネット-有効にするサブネットを指定後、アクション-自動割りあえてIP設定の変更をクリック
- パブリックIPv4アドレスの自動割りあえてを有効にするにチェックを入れ、保存をクリック
実際の手順(EC2の作成)
実際の手順は過去作成した記事リンクをご参照頂ければ幸いです。(講義ではS3バケットを作成後にindexファイルを取得なりますが、ユーザーデータのみで実装した場合になります。)
過去記事：
作成するポイントは以下2点となります。
- EC2を1台パブリックサブネット-1aに作成
- 作成したEC2のスナップショットを活用し、イメージ化しパブリックサブネット-1cで構築
- 動作確認のため、index.htmlファイルに対し各AZ単位で更新します。
実際の手順(ELB)
- ロードバランサーの種類はApplication Load Balancerを選択するため、作成をクリック(黄色のマーカーの箇所になります。)
- ロードバランサー名は任意のものを記載し、スキームはパブリック向けの場合はインターネット向けと選択(プライベート向けの場合は内部を選択)
- AZは作成したVPCを指定し、AZはパブリック-1aとパブリック-1cの2つを選択
- 残りの設定はデフォルトのままで、次の手順：セキュリティ設定の構成をクリック
- HTTPSをリスナーに指定していない場合、次の手順：セキュリティグループの設定をクリック
- SGはインスタンスに割りあえてをしているSGを選択し、次の設定：ルーティングの設定をクリック
- ターゲットグループ名は任意で記入し、種別はインスタンスを指定
- ロードバランサーの作成前の状態を確認し、問題がなければ作成をクリック
実際の手順(ELBの動作確認)
- 作成したELBを選択し、DNS名をコピーします。
- コピーしたDNS名をブラウザで実行
パブリック1a向き
パブリック1c向き
- ロードバランサーの正常性確認は、ターゲットグループのtargetより確認
- 1c側のインスタンスを停止後、ステータスの変化を確認
- WEBサイトの正常性確認
- 1c側のインスタンスを起動後、ステータスの変化を確認
今回のテーマは以上です。
cf)導入時での試験項目にELBの切り替えを行いサービスが継続できるかなどの試験項目に挙げて確認をします。
SAA学習-信頼性設計-ELBの概要
今回のテーマ：ELBの概要
ELB(Elastic Load Balancing)
マネージド型のロードバランシングサービスで、EC2インスタンスの処理を分散する際に標準的に利用します。
特徴は以下になります。
- インスタンス完夫不可を分散
- 異常なインスタンスを認識し対応
- パブリック/プライベートどちらでも使用可能
- ELB自身も不可に応じてキャパシティを自動増減するスケーリングを実施
- 従量課金で利用可能
- マネージドサービスなので管理が不要
- Auto Scaling,Route53,Cloud Formationなどと連携
ELBの主要機能
ヘルスチェック
負荷分散
- 配下のEC2の負荷に応じて、複数のAZにまたがるEC2インスタンスの負荷分散を行う
SSLサポート
- ELBでSSL Terminationできる
スティッキーセッション
Connection Draining
S3へのログ保管
- ELBのアクセスログを指定したS3へ自動保管
スケーラビリティの確保
- 複数のEC2インスタンス/ECS Serviceへの負荷分散を実現します。
高可用性
- 複数のAZにある複数のインスタンス/ECS Serviceの中から正常なターゲットにのみ振り分け
ELBのタイプ
利用できるロードバランサーは3タイプで用途に応じて使い分けます。
- ALB
- NLB
- CLB
CLB(Classic Load Balancer)
AWSが開始された初期に提供されたELBとなり、標準的なL4/L7におけるロードバランシングが可能ですが、複雑な設定はできません。
特徴は以下となります。
- HTTP/HTTPSとTCL/SSLプロトコルのL4とL7に対応
- Proxyプロトコルによる発信元IPアドレス識別
- ELBとバックエンドのEC2インスタンス間でHTTPS/SSL使用時にサーバ証明書認証を実施
- CLBは配下のインスタンスは、すべて同一の機能を持ったインスタンスが必要
- 異なる機能に対しパスベースルーティングができない
cf)パスベースルーティング：異なるコンテンツ(URL)をホストする複数のバックエンドサーバーに要求を分散すること
簡単なディレク構成ですが、以下のようなWEBサイトで掲載してるコンテンツに対し、
アクセス経路に関するルーティングを行うことをパスベースルーティングとなります。
/root LcontentsA LcontentsB
ALB(Application Load Balancer)
レイヤー7の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能です。
特徴は以下となります。
- URLのパスに基づいてルーティングが可能なパスベースルーティングが可能
- WebSocketとHTTP/2のリクエストを受付
- 1インスタンスに複数ポートを登録可能
- EC2インスタンスをターゲットグループに割りあえてる際、複数ポートを個別ターゲットとして登録することが可能なため、ポートを利用するコンテナバランシング可能
- ターゲットグループでのヘルスチェックが可能
- アクセスログの情報追加
- EC2と同様に削除保護が可能
- ALB自体が自動的にキャパシティを増減
CLBとALBの違い
ALBはパスベースルーティングにより、CLBより容易にバランシング構成が可能となります。
- CLBの場合の構成事例
- ALBの場合の構成事例
NLB(Network Load Balancer)
NLBは超低速で高スループットを維持しながら秒間何百万リスエストを捌くように設計されたロードバランサーとなります。
特徴は以下となります。
- 開放型システム間相互接続(OSI)モデルの固定IPアドレスを持つL4ロードバランサー
- 揮発性(きはつせい)ワークロードを処理し、毎秒数百万のリクエストに対応できる能力
- VPC外のターゲットを含めたIPアドレスや静的IPアドレスでの登録可能
- 複数のポートで各インスタンスまたはIPアドレスを同ターゲットグループに登録可能
- 大規模アクセスが予測される際、CLBやALBで必要だったPre-waring申請が不要
- ALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断したが、NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、パケットからアクセス元判断可能
- NLBはフォルトトレランス機能を内蔵したコネクション処理を持ち数カ月から数年のオープンな処理が可能
- コンテナ化されたアプリケーションのサポートが可能
- 各サービスの個別のヘルスチェックステータスのモニタリングのサポートが可能
今回のテーマは以上です。
