RDS
MySQLとMariaDB
MySQLを最初に作った開発者はOracleを離れてmariaDBというMySQLから派生したDBを開発している。
CentOS 6やAmazon LinuxではMySQLが採用されていたが、CentOS 7やAmazon Linux 2ではMariaDBに切り替わっている。
しかもyumでmySQLをインストールすると何も言わずにMariaDBがインストールされるので注意!!
RDSとは
AWSでMySQLを使いたいとき、EC2インスタンスにyumでインストールする方法とAmazon RDSというサービスを使う方法がある。
RDS:Relational Database Service
RDSはサーバにSSH接続することはできない。DB接続のみ。
RDSのメリット
- バックアップをお任せ(直近7日分のスナップショットから復元可能)
- 脆弱性パッチの適用などをお任せ
パラメータグループの作成
my.cnfを編集する代わりにパラメータを編集する。
RDS⇒パラメータグループ⇒パラメータグループの作成
文字コードuft8mb4にする場合は、以下の値をuft8mb4にする。
- character_set_client
- character_set_connection
- character_set_database
- character_set_results
- character_set_server
文字コードuft8mb4にする場合は、、以下の2つの値をutf8mb4_general_ciにする。
- collation_connection
- collation_server
文字コードuft8mb4にする場合は、init_connectの値をSET NAMES utf8mb4;
にする。
オプショングループの作成
追加機能を使用したい場合だけ設定する。
RDS⇒オプショングループの作成⇒グループの作成
RDSインスタンスの作成
RDS⇒データベース⇒データベースの作成⇒設定とデータベースの設定を入力(インスタンスの仕様やネットワーク & セキュリティは変更しなくてOK)⇒データベースの作成
インスタンスの情報の「接続」にある「エンドポイント」が接続用アドレスとなる。
作成直後はセキュリティグループがrds-launch-wizardとなっている。
インバウンドタブの編集⇒ソースに書かれたIPアドレスを消して任意のアドレスまたは既存のセキュリティグループを指定
S3
サイトからアップロードされるデータはS3に保存する
EC2インスタンス(=EBS)にアップロードデータを保存してしまうと以下のデメリットがある。
- WEBサーバを複数台にスケールアウトできない
- WEBサーバのインスタンスをAMIから復元したときに消えてしまう
よって、アップロードデータはS3に保存するようにする。
S3にファイルを保存するためのIAMユーザーを作るとよい。
グループ作成時、ポリシーは「AmazonS3FullAccess」を選択する。
ユーザー作成時、アクセスの種類は「プログラムによるアクセス」とする。
アクセスキー IDとシークレットアクセスキーが発行されるので必ずメモする。
ELB
ELBのメリット
- 負荷分散できる
- Auto Scalingが使える(自動でインスタンスを作成してくれる)
- ELBを使うと無料でSSL証明書を取得できる
インターネットとELB間をHTTPS通信とすれば、ELBとEC2インスタンス間はAWS独自セキュリティで守られているのでHTTP通信で問題ない。
https://www.leon-tec.co.jp/yoshida/7570/
ロードバランサーの作成
- EC2⇒ロードバランサー⇒Application Load Balancer
- 名前を入力、アベイラビリティーゾーンはすべてチェック
- 新しいセキュリティグループを作成する
セキュリティグループ名を入力しルールを編集(タイプ=HTTP、ソース=0.0.0.0/0) - ターゲットグループ名を入力
- インスタンスを選択し「登録済みに追加」
- ターゲットグループ:分散先のグループ
EC2⇒ロードバランサー⇒「説明」タブのDNS名でアクセス可能。
EC2⇒ターゲットグループ⇒「ターゲット」タブでステータスがhealthy になっていればヘルスチェックOK。
プロトコルをHTTPSではなくHTTPにすると「ロードバランサーのセキュリティを向上させましょう。ロードバランサーは、いずれのセキュアリスナーも使用していません。」と表示される。
ELB経由のアクセスだけ許可する
EC2インスタンスのセキュリティを「ELB経由のリクエストだけ通す」設定にすればよい。
EC2⇒セキュリティグループ⇒「インバウンド」タブの編集⇒ソースにELBで指定したセキュリティグループを指定する
セキュリティグループのソースにはセキュリティグループが指定でき、その場合は指定したセキュリティグループに所属するEC2やELBからのアクセスが許可される。
.htaccessでIPアドレス制限する場合
ELBを経由したアクセスは、EC2インスタンスから見たアクセス元はすべてELBとなる。
.htaccessでRequire ip xxx.xxx.xxx.xxxとしてもうまくいかない。
RemoteIPHelper X-Forwarded-Forを記述するとELBではなく本当のクライアントIPがアクセス元として利用されるようになる。
※本当は、EC2インスタンス上ではなく、ELBのセキュリティグループで遮断した方が無駄なリクエストがなくなるのでお勧め
RemoteIPHelper X-Forwarded-For
Require all denied
Require ip 許可するIP
Require ip ELBのIP"
Auto Scaling
起動設定の作成
- EC2⇒AUTO SCALING⇒起動設定⇒起動設定の作成⇒マイAMI
- インスタンスタイプ選択
- 「名前」は現在のインスタンスを同じにする
- 「既存のセキュリティグループを選択する」で現在のものと同じにする
- 既存のキーペアを選択
Auto Scalingはアクセスが増えたらインスタンスを増加し、減ったら削除してくれる。
しかし、本著ではインスタンスの維持のために利用していて、何か問題が起きてインスタンスが停止してしまっても、Auto Scalingによってインスタンスが自動で作成され復旧されるようにしている。
Auto Scalingグループの作成
- EC2⇒AUTO SCALING⇒Auto Scalingグループ⇒Auto Scalingグループの作成
- グループ名を入力
- EC2と同じサブネットIDを選択
- ロードバランシングをチェック
- ターゲットグループを選択
- ヘルスチェックタイプはELBを選択
- このグループを初期のサイズに維持する⇒通知の追加⇒メアド入力
インスタンスが停止や削除されると、自動的にインスタンスが生成され通知メールが届く。
※インスタンスを削除すると状態がterminatedとなり、しばらくの間削除されずに表示されたままとなる
Auto Scalingグループ=EC2インスタンスのグループのこと。
常に維持したいインスタンス数、最小数や最大数などを設定する
自動生成されたインスタンスはElastic IPが設定されていないので、設定する必要がある。