スクリーンショット_2020-01-30_00

AWS習得編 ゼロからわかるAWS超入門 CHAPTER5


こちらの書籍について学んだことです。

CHAPTER5 データベースを活用しよう

データベースには重要なデータが保存されるため、バックアップなどの適切な運用が大切。
マネージドサービスであるRDSを活用すれば、そういった煩わしい運用をAWSに任せることができる。

5-1 マネージドのデータベースサービスRDS

1台のEC2インスタンスにApache、PHP、MariaDBをインストールして、WordPressが動くようにした。
AWSでこのようなシステムを構築する場合、もっといい方法がある。
データベースをEC2に同意せず、マネージドサービスのRDSとして運用する方法。

RDSは、Amazon Relational Database Service
MySQLやPostgreSQL、Oracleデータベース、MicrosoftSQLServerデータベースなどもサポートされている優れ物。

5-1-1 RDSとは

マネージドサービスとして提供されるリレーショナルデータベースサービスの総称
マネージドサービスのため、運用管理はAWSが担う。

自分でセットアップせず、出来合のデータベースサーバーを借りるのがRDS
いくつかの項目を選ぶだけでデータベースサーバーが起動し、すぐに利用できるようになる。

5-1-2 RDSが対応するデータベース製品

RDSは、リレーショナルデータベースを提供するサービスの総称であり、特定のデータベース製品を指している訳ではない。

RDSは、本書の執筆時点において、フリーのものから商用のものまで、全6種類のデータベースに対応している。
どれを利用するのかは、AWSマネジメントコンソールからDRインスタンスを作成するときに決める。

RDSは、AWSが運用してくれるデータベースというだけで、使い方はRC2インスタンスにインストールしたものとほぼ同じ

MySQL オープンソースのデータベース
MariaDB MySQLからスピンアウトしたオープンソースのデータベース
PostgreSQL オープンソースのデータベース
AmazonAurora MySQLやPostgreSQLと互換性がある、高パフォーマンスなデータベース。MySQLやPostgreSQLを前提としたシステムをエンタープライズシステムで運用したいときに向く
Oracle オラクル社が提供する商用データベース
Microsoft SQL Server マイクロソフト社が提供する商用データベース

5-1-3 RDSの料金

RDSの料金は、次の合計金額
RDSの料金=①ストレージ費用+②DBインスタンスの費用+③バックアップストレージの費用+④通信費用

①ストレージ費用
確保しているストレージ(ディスク)に対する費用。実際に使っている量ではなく、確保した量に対する課金なので注意。
1年間のAWS無料枠では月に20バイト分利用。

②DBインスタンスの費用
EC2インスタンスと同様に、時間当たりの稼働費用。
DRインスタンスもEC2インスタンスと同様にそこそこの性能のものから高性能なものまであり、性能によって費用が異なる。
DBインスタンスを作るときは冗長性をとらないシングルAZ構成と冗長性をとるマルチAZ構成があり、費用が異なる。
また、インスタンスの費用は利用するデータベース製品によっても異なる。
たとえば、Microsoft SQL ServerやOracleなど、商用の有料データベースを使う場合は、そのライセンス費用が加算されるため、オープンソースのでーたべースを利用するときと比べて高価になる。
1年間のAWS無料枠ではdb.t2.microインスタンスが毎月750時間分利用できる。

③バックアップストレージの費用
DBインスタンスでは、スナップショット(バックアップ)をとれる。スナップショットはバックアップストレージと呼ばれる場所に作られ、その容量に応じて費用がかかる。1年間のAWS無料枠では月に20Gバイト分利用できる。

④通信費用
DBインスタンスがインターネットと通信する場合、転送量に応じた費用がかかる。本章のように、VPC内のEC2インスタンスとだけ通信するなど、同一AZ内でしか通信しない場合、費用はかからない


5-1-4 RDSを利用するメリットとデメリット

責任分界点が異なる
EC2は全部自分で面倒を見る
RDSはAWS任せ

いいことずくめっぽいRDSだが、デメリットは下記

①コスト面
EC2で運用するのに比べて、ランニングコストがかかる。

②構成の自由度がない
EC2の場合データベースサーバーのオプション変更でパフォーマンス・チューニングを実施できる。
RDSではカスタム設定で動かすことはできない。

RDSでも、いくつかのオプションは変更できるものの、基本的にはAWSによって構成されている標準的なデータベースを利用することになり、高度なカスタムチューニングは困難

こうしたデメリットと先述のメリットを比べた場合、安定運用のメリットのほうが重要視される。
AWSでデータベースを利用するときはRDSを利用するのが一般的。

RDSは無停止での運用は困難


5-2 この章での操作の流れ

Linuxに乗ってたデータベースをRDSにする

5-2-1 DBインスタンスの作成

①管理者のユーザー名とパスワード
DBインスタンスを作成する際は、データベース管理者(admin)のユーザー名とパスワードを決める。
このアカウントで、アプリケーションから接続する。

②配置先
DBインスタンスは、EC2インスタンス同様、どこかのVPC・サブネットに配置する。
本章では第4章のEC2インスタンスと同じ場所に配置する。

③パブリックIPは割り当てない

DBはインターネットに接続できる必要なし

④エンドポイント
DBインスタンスを作成するとそのインスタンスの「エンドポイント」が決まる。
エンドポイントとは、ホスト名。アプリケーション(WordPress)から接続するときの、接続先データベースサーバー名に相当する。

⑤セキュリティグループ
DBインスタンスには、EC2インスタンスからの接続が必要。
DBインスタンスのセキュリティグループを接続できるように構成する。

5-2-2 EC2インスタンス上のMariaDBからの移行

DBインスタンスの構成後、EC2インスタンス上でWordPressのデータの保存先をDBインスタンスに変更する。

①現在のデータをDBインスタンスにコピー

EC2インスタンス上でのMariaDBのデータを、作成したDBインスタンスにコピーする。MariaDBのデータをバックアップして、それをDBインスタンスにリストアする。

②WordPressの設定を変更してDBインスタンスに接続
WordPressの設定を変更して、DBインスタンスに接続するように修正。
動作テストして問題ないことを確認。

③EC2インスタンス上のMariaDBを停止
EC2インスタンス上のMariaDBは必要ないので停止。
全く利用しないのであればアンインストールも可。

ただし、アンインストールする際はデータベース本体のみのアンインストールとし、mysqlなどのコマンドやPHPから操作するためのライブラリなどはアンインストールしないようにする。そうしないと、EC2インスタンスからDBインスタンスのデータ操作ができなくなる。

WordPressを新規に構築する場合

本文中の手順では、前章でEC2インスタンスに構成したMariaDBを移行することを前提としているが、最初からDBインスタンスを使うようにもできる。
最初からDBインスタンスを使うようにするには、あらかじめDBインスタンスを作っておき、WordPressをインストールするときにDBインスタンスを指定して初期設定をする。
mysqlコマンドで-hオプションを指定すると、接続先にホスト名を指定できる。
次のようにすると、DBインスタンスに対して操作できる。
ここで指定するユーザー名とパスワードは、DBインスタンスの管理者のユーザー名とパスワード。

mysql -h DBインスタンスのエンドポイント-u ユーザー名 -p

前やった4-9-5データベースとユーザーを作成するでの操作をDBに対して行う
そのあと、http://パブリックIP/wp-admin/install.phpにアクセスしてインストールページを開き、データベースとしてDBインスタンスのエンドポイントを選ぶ。これでRDSのDBインスタンスを利用するように構成できる。


5-3 RDSのDBインスタンスを作成する

DBインスタンスを作成していく。
DBインスタンスをEC2インスタンスと同じサブネットに作成する。

5-3-1 DBインスタンスを作るのに当たって決めること

操作を始める前に、あらかじめ決めておくものを決めておく

データベースエンジン MariaDB
インスタンスのクラス db.t2.micro
マルチAZ配置 しない
ストレージタイプと割り当て 汎用SSD/20GiB
DBインスタンスの識別子 wordpressdb
マスターユーザーの名前 root
マスターユーザーのパスワード myrdspassword
VPC デフォルトVPC
サブネットグループ default
パブリックアクセシビリティ いいえ
AZ EC2インスタンスと同じ

5-3-2 EC2インスタンスのアベイラビリティーゾーン

同じAZじゃなくても動くけどコストがかかるのとパフォーマンスが落ちるのとで結局は同じAZにしたほうがいい。

AZを調べるには

EC2をポチ
インスタンスをポチ
アベイラビリティーゾーンを確認
ap-northeast-1a
であることが判明!

5-3-3 RDSダッシュボード

DBインスタンスを作成していく。

AWSコンソールからRDSをポチ

5-3-4 DBインスタンスを作成する

データベースの作成をポチ
アザラシポチ(MariaDB)
バージョンは10.3.8にしといた
テンプレートは開発テスト
ライセンスモデルは見当たらず
書籍とぜんぜん違う。。。
DBインスタンス識別子はwordpressdb
認証情報の設定はroot
マスターパスワードはmyrdspassword
パスワードの確認を入力
DBインスタンスサイズはバースト可能クラスでdb,t2.micro
ストレージタイプは汎用SSD(プロビジョンドIOPS SSDってなんだろう意味わからん)
ストレージ割り当ては20
ストレージの自動スケーリングはしないようにする
マルチAZ配置はスタンバイインスタンスを作成しない

接続はデフォルトのVPC
追加の接続設定
サブネットグループはデフォルト
パブリックアクセスはなし
VPCセキュリティグループは新規作成
セキュリティグループ名はchapter5にしておく
AZはさっき調べたやつにする
暗号化はできない

追加設定を開く
最初のデータベース名は空欄
DBパラメータグループはdefault.mariadb10.3
オプショングループはdefault:mariadb-10-3
バックアップは自動バックアップ有効で保存期間は7日にしておく
最大35日まで行けるっぽい
バックアップウィンドウは設定なし
スナップショットにタグをコピーは一応チェック
モニタリングは特に有効化はしない
ログのエクスポートもつけない
メンテナンス
マイナーバージョン自動アップグレードの有効化はチェック
いつやるかはメンテナンスウィンドウの選択肢による
削除保護は、データベースが誤って削除されるのを防いでくれるが、今回はなし

ここまでやったら、データベースの作成をポチ

できあがるまで時間がかかる模様。しばらく待ってみる。
できた!


5-3-5 セキュリティグループのルールを変更する

VPCセキュリティグループの
chapter5 (sg-0919947e5da48f8b6)をポチ

インバウンドをポチ

デフォルトIP削除をポチ

ルールの追加をポチ

タイプはすべてのトラフィック
ソースはカスタムでmy-で出てくるやつを選択 これは4章で作ったやつ
保存をポチ

完了!


5-4 WordPressのデータベースをDBインスタンスに変更する

データベース移行

5-4-1 エンドポイントを確認する

エンドポイントを確認
wordpressdb.cmcsnnsmq6ku.ap-northeast-1.rds.amazonaws.com

5-4-2 MariaDBからDBインスタンスに移行する

EC2インスタンス上のMariaDBから、このDBインスタンスに移行していく。
EC2インスタンス上のMariaDBのバックアップをとり、それをDBインスタンスにリストアする

EC2インスタンスにssh接続
ssh -i myserverkey.pem ec2-user@54.65.30.164

管理者権限に変更
sudo -i

バックアップの作成
mysqldump --databases wordpressdb -u root -p > /tmp/wordpressdb.sql

ここで聞かれるパスワードはEC2のもの
foobar

バックアップしたデータを流し込む
mysql -h wordpressdb.cmcsnnsmq6ku.ap-northeast-1.rds.amazonaws.com -u root -p < /tmp/wordpressdb.sql

ここで聞かれるパスワードはRDSのもの
myrdspassword

これでおk

5-4-3 WordPressの設定を変更する

DB_NAMEは変更しない
DB_USERとDB_PASSWORDとDB_HOSTを変更

viで開く
sudo nano /var/www/html/wp-config.php

色々書き換え
カーソルキーで移動
command+vで貼り付け
control+xで終了 保存でy 終了でenter

設定を反映したらApache再起動
sudo systemctl restart httpd

http://ec2-54-65-30-164.ap-northeast-1.compute.amazonaws.com

データベースエラー・・・

これはパスワードがミスってた!変更!

もっかいApache再起動
sudo systemctl restart httpd

行けた!!

5-4-4 MariaDBの停止とアンインストール

mariaDBを止める

sudo systemctl stop mariadb

行けたっぽい

mariaDBを削除
sudo -i yum remove mariadb-server

これでおk!

5-5 DBインスタンスの管理

RDSを使うまでは以上
あとは簡単にDBインスタンス管理方法について

5-5-1 DBインスタンスの操作

rdsのアクションで停止・再起動・削除とかできる
変更で色々変更できる

5-5-2 バックアップとリストア


rdsで簡単にスナップショット取れる
ちょいと時間かかる
これを復元する場合はアクションからスナップショットの復元をポチ

無駄な課金を防ぐためにDBインスタンスは停止しとく
7日後は復活するので注意。

本当に使わなくなったらDBインスタンスは削除。

スナップショットは課金されるので注意。

まとめ
RDSはマネージドのデータベースサービス
ユーザーは運用管理する必要なく、RDSマネジメントコンソールから操作するだけで、簡単にデータベースサーバーを起動できる
RDSで作成するDBがDBインスタンス。EC2同様VPCサブネット配置され、そしてエンドポイント決定する。
EC2インスタンスとだけの通信ならパブリックIP使わず、セキュリティ高める
EC2とRDSで通信するならセキュリティグループの設定が必要
EC2インスタンス上のデータベースなど、既存のデータベースからDBインスタンスに移行するには、既存のデータベースでバックアップを作り、それをDBインスタンスにリストアする。
スナップショットという機能を使うとDBインスタンスをバックアップすることができる。


この記事が気に入ったらサポートをしてみませんか?