ことの始まり

ある日、社内の簡易ツールをリリースしたいという相談を受けました。
社内ツールだし、料金は抑えたいけど、MySQLを使いたいという要望だったので、構築のモチベーションの1つにAuroraServerlessが使えないかを検証をすることにしました。

RDSの料金はt3.microだとして、超ざっくり月額2000円程度です。
RDSの料金

AuroraServerlessの料金はACUという単位で、1ACUが$0.06/hなので、まるまる動かすと4800円程度で、RDSよりもAuroraである分高くなります。
AuroraServerlessの料金

なので、営業時間の間だけしか使わないようなツールであれば、8時間だと1600円程度で安くなります。
ということで、AuroraServerlessを検証するべく作業を始めたところ、全然関係ないところで色々余計な作業が発生してしまいました。

問題発生

検証環境で、AuroraでServerlessのインスタンスを作成するべくAWSコンソールでポチポチしていたのですが、ふと疑問が1つ。
VPCでサブネットを選択しようとすると、なぜか選択出来ません。
新規作成となってしまい、仕方なくそのまま先に進めようとしたところ、下記エラーが表示されて作成出来ず。

Aurora Serverless doesn't support DB subnet groups with subnets in the same Availability Zone. Choose a DB subnet group with subnets in different Availability Zones.

1つのAZで複数サブネットを配置した場合のエラーのようでした。
元々検証環境では、1つのAZに1つのサブネットで、マルチAZにしていました。

しかしながら、複数サブネットにしている認識がなかったので確認したところ、たしかに複数サブネットが配置されているようでした。

どうやら、どこかのタイミングで、だれかがポチポチ追加してしまった模様で、RDSは全てのサブネットを追加するボタンがあるので設定変更あたりで間違って追加しちゃったのかなぁという感じでした。

改めて現状を整理すると、
– 全てのサブネットを追加してしまっているのがどうやら過去のどこかのタイミングで発生している。
– 弊社ではDB用のサブネットを1AZに1サブネット作成している。

ここで勘の良い方はすぐに気がつくと思いますが、本来配置すべきではないサブネットにDBインスタンスがいくつか配置されていることがわかりました。
検証環境なので、外部からのアクセスは出来ないようになってはいますが、本番環境とは異なるネットワーク設定に加えて、パブリックサブネットに配置されてしまっているDBもあり適切ではないので即座に対応をすることにしました。

上記のAuroraServerless作成時のエラーを解消するには下記作業が必要であることがわかりました。

1.対象のサブネットグループから不要なサブネットを削除する
2.不要なサブネットに配置されているインスタンスを正しいサブネットに配置しなおす

対処の実施

ということで、まず不要なサブネットを1つづつ削除していき、エラーになったサブネットを洗い出しました。
その後、管理しているDBインスタンスのIPアドレスをdigで調べて、どのサブネットに配置されているかを確認。
スナップショットと、念の為mysqldumpを実施して、一回不要なサブネットに配置されてしまっていたDBインスタンスを全て削除しました。

新たな問題

意図したサブネットに配置されたインスタンス以外を全て削除した後、不要なサブネットを1つずつ削除していき、最後の1つを削除しようとしたところ何故か Some of the subnets to be deleted are currently in use のエラーが。。
なぜか1つだけ削除のできないサブネットグループが見つかりました。
自分の確認間違いで、残したDBインスタンスのうち1つが対象のサブネットに配置されていると思い、改めてdigで確認しましたがやはりそんなことはありませんでした。

原因

対象DBがなければ、どうしたら良いのだろうかと考えたのですが、パッと見では判断がつきません。
そこで、aws cliで一度確認したほうが良いかもということで下記を実行して確認してみました。

aws rds describe-db-instances --region=ap-northeast-1 --profile XXXXX |jq -r '.DBInstances[] |{DBInstanceIdentifier,DBInstanceClass,MultiAZ,AllocatedStorage}|@text "\(.DBInstanceIdentifier)\t\(.DBInstanceClass)\t\(.MultiAZ)\t\(.AllocatedStorage)"'
db-testA-01 db.t3.micro true 200
db-testB-01 db.r4.large false 1
db-testB-02 db.r4.large false 1
db-testC-01 db.t2.medium false 20

すると、どうやら1台だけMultiAZがtrueになっているインスタンスが。。
ここでなんとなくピンときたので、試しにMultiAZをfalse(無効)にしたところ、見事最後の1つのサブネットが除外出来ました。

そうすると、対象のサブネットグループには1AZに1サブネットグループにすることができ、Aurora Serverlessの作成でも対象のVPCとサブネットを選択出来て、エラーになることなくインスタンスを作成することができました。

あとはスナップショットから1つずつDBを作成し直して、無事全ての作業が完了しました。

で、結局AuroraServerlessはどうか

まだ、試して間もないですが、アイドル時間5分でインスタンスを停止するようにしたところ、意図した通りに停止しているように見えます。
最初のアクセスの際にレスポンスが返ってくるまでおおよそ30秒程度かかるので、最初の30秒くらいはタイムアウトしないように処理すれば簡易的なツールであればなんとかなりそうとは思いつつ、外部公開するにはまだ使い所が分からないとは感じています。
ただ、うまく使えば安くAuroraが使えるので積極的に活用していこうとは思ってます。

まとめ

本来やりたかったことをやる前に、なんだか七面倒なヤックシェイビングをしてしまいました。
自称プロの毛刈り職人としては、検証環境とは言えいつもより気の張る作業でしたがネットワークが整理できたし、やりたかった検証も出来たので良かったです。
それと、AWSのRDSは改めて便利だなぁと思いました。

カテゴリー: RDS