AWSをいじり倒す(5-2.RDS-Aurora)
Auroraを選んでみる。
簡単作成を選びたい気持ちを抑えて、勉強のために標準作成
Auroraを選ぶ
互換性はMySQLを選ぶ
互換性とはなんぞや？
MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します
なるほど。ということはテスト接続はMySQLと同じコマンドで試そう。
機能を４つから選ぶ
サーバーレス気になる
Aurora Serverless の仕組み - Amazon Aurora
ワークロードの集中が数分または数時間しか続かない場合やアクティビティが低下したり完全になくなったりする期間が長く続く場合
が用途として適しているらしい。今回アクティビティなんて無いに等しいので
サーバレスのほうがいいのかも。
しかし、サーバレスって言うけど必要に応じたリソース分のサーバは結局あるわけだし、この単語どうにかならんかな。
文句言いながらサーバレスを選んでみることにした
設定
パスワード自動生成はしないぞ。
キャパシティー設定
この辺がサーバレス特有の設定
キャパシティユニットは2の累乗刻みで1〜256まで選べる。
今回は1〜2の最小構成でいく。
強制的にスケーリング・・・のところはタイムアウトって何だ
[アップデート] Aurora Serverless の最小キャパシティが 1 から指定可能になりました！＆キャパシティ変更の強制オプションが追加されました | Developers.IO
ただし、以下のような場合には、スケーリングポイントが特定できず、タイムアウトになることがあります。
- 進行中の長期のクエリやトランザクションがある場合
- 一時テーブルやテーブルロックを使用している場合
なるほど。
アイドルの一時停止も便利そうだけど、今回はどちらのオプションもなしで。
接続
この辺は前回と一緒。
APIの項目が増えている
Aurora Serverless の Data API の使用 - Amazon Aurora
この API を使用すると、ウェブサービスベースのアプリケーション（AWS Lambda、AWS AppSync、AWS Cloud9 など）を通じて Aurora Serverless にアクセスできます
無料なら有効にしない手はない。普通にEC2を介せばコマンド発行できるんだろうけど、徹底的にコスト削りたい時には良いかも
追加設定
前回と一緒
ちなみにAuroraは暗号化がデフォルトで有効である（画像は割愛）
以上で設定おわり。データベースの作成ボタンを押す。
２回目なので標準作成でもサクサク選べた感はある。
作成中の様子
せっかくなので認証情報のところを押してみる
ここに自動生成のパスワードも出るわけね。
できたので接続してみよう
まずは前回と同じく建てたEC2サーバに接続.
mysqlデータベースに接続するコマンド、これも前回と同じもので
アクセス先を今回のAuroraにしたものを投入すると
普通につながった。
Aurora要素は微塵も感じられない
うーん操作感はMySQLと同じ。
あとはレプリカを作ってみようと思ったが、作成するメニューがない。
Aurora Serverlessが一般利用可能になったので試してみた | Developers.IO
Aurora Serverlessでは以下の機能をサポートしていません。
- S３バケットからのデータロード
- Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し
- 高度な監査の使用
- Auroraレプリカ
使えなかった・・・！
レプリカ作って負荷分散する思想と、負荷に応じて性能を拡張する思想は相容れないのかもしれないが、読む専用のリードレプリカの存在があった方が安心する（精神論）
というか、下記のダウンタイムが許容できない場合はサーバレスは使えんということになる。
AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | Developers.IO
シングルインスタンス構成で、そのインスタンスがクラッシュした際のことを考えます。この場合、Auroraはインスタンスの自動復旧を行ないます。この復旧は通常10分未満で完了します。この10分のダウンタイムを許容できるのであれば、Mulit-AZにせずとも良いのではないでしょうか
しょうがないのでこのDBは消して新たに作成する。
今度はこちらを選ぶ。
すると新たなメニューが登場
これを選べばレプリカも最初から作成されるのかな？
早速作ってみると
２つ作成された・・・と思いきや、ロールが読み込みと書き込みで別。
エンドポイントは２つなので、これはいわゆるリードレプリカは１つで
書き込み権限のあるエンドポイントがマスターということか。
リーダーの追加でレプリカを増やしてみる
DB クラスターに Aurora レプリカを追加する - Amazon Aurora
設定画面
上では2cを選んでいるけど、
2cにサブネット作ってなくて怒られたので、のちに2bに変更
暗号化は触るところなし（画像は割愛）
設定
ソースには別のレプリカも選べる。
フェイルオーバー
本体が死んだとき、だれがプライマリになるかの優先度決め
プライオリティ"範囲"って、なんで範囲？
普通にプライオリティ値でいいのでは・・・。
この辺は特にいじる必要なし
パフォーマンスインサイト
Performance Insights を使用した Amazon RDS データベースの負荷分析 | Amazon Web Services ブログ
データベースの負荷（どのSQL文が負荷を発生させており、それはなぜなのか）を可視化するダッシュボードを使用して、エキスパートな方とエキスパートではない方の両方が、Performance Insights でパフォーマンス問題を容易に検出できます。
これは調子悪い時に有効にすれば原因がわかるかも。
メンテナンスも特に変更なし
Add readerして、ロール：読み込みのレプリカが増えた。
結論としては、AuroraもMySQLも、使用感は同じ。コマンドレベルで同じ。
なので構成や挙動、お値段の違いを勉強して
最適な環境を選べるようにしましょう、という感じ。
何度か引用したこの記事によると
AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | Developers.IO
ちょっと屁理屈に聞こえるかもしれませんが…たしかにAuroraの方がAWS利用費は高くなるかもしれませんが、その分人的コストを抑えれますよ？という話です。
結局こう書いてあるので、ちょい使いならMySQL、がっつりだとAuroraかなぁ（個人の感想です）
進捗
次はストレージ付近触ってみようかな
