某案件で Amazon RDS for MySQL を利用しています。
追加開発で既存テーブルにカラム追加をしてAPIを新設してほしいという作業依頼がきました。
追加対象のテーブルの現在のレコード数を聞くと、7桁レベルのレコードがあるようです。
そこへ ALTER TABLE 〜 を流すと、どのくらい時間がかかるのだろうか？ リリース時、本番環境で流せるレベルだろうか？
ふと気になったので先輩に相談し、スナップショットからデータベースを復元し、検証用のデータベースを作成して試してみることにしました。
スナップショットは毎晩深夜に自動取得されているものを使います。
Amazon RDS > スナップショット で表示される一覧から、復元したいスナップショットを選択して 「スナップショットから復元」を選択します。
データベース名の入力が必須、インスタンスタイプがデフォルトで本番環境と異なったものが選択されていたので、選択し直しました。
これは本番環境のインスタンスタイプが "旧世代のインスタンスタイプ" という扱いになってしまったからかもしれません。
それと念の為、本番環境とは別のVPCを選択して起動することにしました。
最後に 「DBインスタンスの復元」 ボタンを押して数分待つと復元されたデータベースを使えるようになります。
さて、どうやって接続してSQLを流そうか？
データベースを復元した先と同じVPCにEC2インスタンスを1つ立てました。これをSSHの踏み台サーバーとして使います。
RDSについているセキュリティーグループでEC2インスタンスのIPから MySQL/Auroraのアクセスを許可する設定を追加しました。
さてこれで接続できるはず・・・！
MySQLクライアントとして、TablePlus というアプリを使います
https://tableplus.com/
ここで気がつきました、DB復元時にユーザー名やパスワードの設定が何もしていません。
「RDS 復元 パスワード」 いろいろググった結果、これだという情報にたどり着けませんでした。
もしや元のデータベースと同じ情報ではないか・・・と試してみると無事接続できました！
大事なことなのでもう一度、
スナップショットから復元したデータベースは、元のデータベースと同じユーザ名・パスワード を使ってアクセスできます。
結果
TablePlusから目的の SQL文を流して、おおよその実行時間が判明しました。
結果、数十秒 という単位で終わることがわかり、先輩に報告です。
このくらいであれば、無理な負荷ではない、ただしリリース時はメンテナンス状態にしてアクセスをなくした状態で行うのが良さそう
といった相談をしました。
負荷が気になったときは、実際に同等の環境を作って動かして検証するのが確実ですね。
そんな話を、別な先輩が書いた Amazon Web Services負荷試験入門 っていう本で読んだことを思い出しました。
最後に
検証用に立てたデータベースインスタンスはそれなりのサイズなので、料金もそれなりにかかってきます。
検証が終わったあとは忘れずに削除しましょう。EC2インスタンスも忘れずに。