AWSにapi作ったんだけど（非公開）、相当数の同時接続時に速さが足りないと言われたんで、
とりま原因究明のためにRDS（MariaDB）からスロークエリログを吐き出してCloudWatchで眺めてみた。
その軌跡です。

深奥まで知る必要はないけどとりあえず今夜勝ちたい人向けです。

環境

本記事はAWS RDS（MariaDB10.2）で試しています。
以降はこの前提で進めますがバージョン違いやMysqlでも基本同じな模様。
Auroraは若干微妙に違うので他の記事をご参照下さい。

作業工程

やることは大きく2つ。

• パラメータグループの設定（DBエンジンのパラメータ設定）
• ログエクスポートの設定（CloudWatchへの出力設定）

tips

RDSでは新しくデータベースを作成する際に、エンジン毎にデフォルトで用意されているパラメータ＆オプショングループを選択できます。

できますが下記理由からオリジナルを作ることをお勧めします。（特にパラメータ）

• デフォルトグループは設定値が変更不可
• グループの付け替えは再起動が必要

パラメータグループの設定

「RDS > パラメータグループ > パラメータグループの作成」より

1. パラメータグループを作成
2. 作成したパラメータグループを選択
3. パラメータの編集で以下の値を設定
   • slow_query_log = 1　（スロークエリ出力の有無）
   • long_query_time = 1 （スロークエリと判定する秒数。お好みで）
   • log_output = FILE　 (ログの出力方法)

グループ作成時のパラメータグループファミリーには使用するDBエンジンを指定。
他は適当でおｋ。（嘘、あとでわかりやすい名前を設定して）

デフォルトではslow_query_log=0（false）なのでスロークエリは出力されません。
また、log_output = TABLEの場合、DB接続して下記でログは参照可能です。

select * from mysql.slow_log

ちなみにここで設定した値は適用タイプがdynamicなので即時適用されます。
ここがstaticのパラメータはDBの再起動が必要です。

ログエクスポートの設定

新規DB作成：「RDS > データベース > データベースの作成」より
既存DB変更：「RDS > データベース > {当該DB} > 変更」より

どちらの場合も下記を設定します。

• DBパラメータグループ = 作成したパラメータグループ
• ログのエクスポート > スロークエリログ = ON

新規作成の場合、追加設定というところに折り畳まれてるんで見逃してそのまま作成しないように気をつけてください。
俺はやった。

結果

これで「CloudWatch > ログ」に/aws/rds/instance/{DB名}/slowquery
というログが出力されるようになるはずです。

あとはスロークエリから遅延の原因を探すだけです！やったね！
僕はクエリが原因ではなさそうと判定されたので来週も戦い続けます。

某案件で 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インスタンスも忘れずに。