LoginSignup
12
8
@kharashimain2024-ANGEL-Dojo

【諸説あり！？】RDSを素早く停止する方法を考えてみた！

Posted at

はじめに

この度、ANGEL Calendarの企画に参加しております！
記事一覧は下記のOrganizationアカウントの一覧をチェックしてみてください！
2024-ANGEL-Dojo Organization

RDSを素早く停止したい

こんにちは！ANGEL Calendar企画&運営のはらしまです！
栄えある2日目&平日初投稿をさせていただきます！
※以前こちらの記事をOrganizationアカウントに紐づけて投稿させていただきました。

突然ですが、AWS RDSって停止するまで時間かかるなあと思ったことありませんか？
データベースの再起動を行う際、停止は早ければ早いほど助かりますよね！
今回の記事では、RDSを素早く停止する方法について仮説を立て、それが正しいかどうか実際に検証してみました！
そんな検証してみたんだ:rolling_eyes:という感じで読んでいただければと思います！

仮説

本記事では、停止前にスナップショットを取得しておくことで停止が早くなるのではないかという仮説のもと検証を行いました。

仮説に至った経緯

知り合いのエンジニアとの雑談中、RDSの話になり、「停止する際にあまりにも時間がかかるよね...※¹」ということが話題に上がりました。
下記の画像の通り、RDSを停止する際には、オプションにてスナップショットを取得するかどうかを指定できます。

スナップショット _ RDS _ ap-northeast-1 - Google Chrome 2024_08_16 20_13_15.png

停止までの時間が長くなる原因の一つとして、上記オプションを指定していない場合でも、管理側（AWSの基盤側）でスナップショットが必ず取得されているのではないかという話になりました。
RDSインスタンスの後続のスナップショットは増分ですので、上記の仮説が正しければ、スナップショットを事前取得してから一時停止することで、停止までの時間を短くできるはず※²です！仮説に対して、下記の方法で検証してみました！

※¹あくまでも個人の感想です。
※²事前にバックアップを取っておけば、停止の際のスナップショット作成の時間が短縮され、停止までの時間が短くなるのではないかという予想になります。

検証手順

  1. 下準備として、シングルAZ構成のRDS(MySQL)を2台と、mysql clientをインストールした接続用EC2を作成し、RDSに対してダミーデータを書き込む※³。スナップショットの有無で停止にかかる時間を計測するため、それぞれのRDS名は下記とした。
    • yes-snapshot：停止前に必ずスナップショットを取得する。
    • no-snapshot：スナップショットを取得せずに停止を行う。
  2. 下記の手順を参考にyes-snapshotのスナップショットを取得する。
  3. 両方のRDSをスナップショット取得のオプションを付けずに一時的に停止し、時間を計測する※⁴。

1回の計測では試行回数が足りないと考えたため、上記の検証を実施後、下記の作業を4回実施しました。また、条件をフラットにさせるため、毎回ダミーデータとスナップショットを取り直すようにしております。

  1. 両方のRDSにダミーデータを書き込む。
  2. yes-snapshotのみスナップショットを取得する。
  3. 両方のRDSをスナップショット取得のオプションを付けずに一時的に停止し、時間を計測する。

※³ダミーデータの作成方法はこちらをチェック！
※⁴時間の計測については下記の式にて計算しております。

{AWS CLIにて取得したRDSの「DB instance stopped」ログが出た時刻※⁵} - {RDSの一時停止ボタンを押した時刻}

※⁵RDSのログ時刻についてはこちらで確認しております。

検証前準備

RDSにダミーデータを書き込むことで、本番に近い形で検証を行います。

  1. RDSに接続後、データベース"dummy_database"を作成する。 
    CREATE DATABASE dummy_database;
  2. データベース"dummy_database"に移動する。 
    USE dummy_database;
  3. テーブル"dummy"を作成する。 
    CREATE TABLE dummy (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(50),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
  4. ダミーデータ生成用のストアドプロシージャを作成する。 
    DELIMITER //
CREATE PROCEDURE generate_dummy_data(IN num_rows INT)
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE i <= num_rows DO
        INSERT INTO dummy (name, email)
        VALUES (CONCAT('User', i), CONCAT('user', i, '@example.com'));
        SET i = i + 1;
    END WHILE;
END//
DELIMITER ;
  5. ダミーデータを1000件生成する。 
    CALL generate_dummy_data(1000);
  6. テーブル"dummy"に保存されているデータの総件数が表示する。(確認作業) 
    SELECT COUNT(*) FROM dummy;
  7. テーブル"dummy"に保存されているデータの先頭10件が表示する。(確認作業) 
    SELECT * FROM dummy LIMIT 10;

検証結果

実際に検証を行った結果を下記の表に記載いたします！

スナップショット有りの場合 停止までにかかった時間
1回目 8分19秒
2回目 8分47秒
3回目 8分32秒
4回目 8分20秒
5回目 8分27秒
平均 8分29秒
スナップショット無しの場合 停止までにかかった時間
1回目 8分47秒
2回目 8分26秒
3回目 8分20秒
4回目 8分41秒
5回目 8分43秒
平均 8分35.4秒

今回の検証では、スナップショットを取得した方が少しだけ停止までの時間を短縮させられることが確認できました:fist:
なお、RDSの停止までにかかる時間につきましては、AWSの基盤側のリソース状況等などの様々な要素で変動いたします。
そのため、今回の検証を同じ結果が常に得られるとは限りませんので、結果につきましてはご参考程度に認識いただけますと幸いです。

最後に

ただの雑談から始まった今回の検証ですが、一から自分の頭で考えて、無事結論を出すところまでやり切ることができました。「わからないことや未知の分野に対しても、とりあえずトライして自分の目で確かめてみよう」という姿勢は、AngelDojoを通して徐々に身についてきた気がします。
本記事を読んでいただいたうえで、そうなんだ～と思われた方はへぇ～ボタンと「いいね！」を押していただけますと幸いです:relaxed:
Angel Calendarにつきましては明日からもまだまだ投稿が続きますので、ご期待くださいませ:stars::koala:

参考文献

12
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
8