フェイルオーバー – エンジニア見習い https://otonan-syusyoku.work 三流プログラマー Sat, 22 Feb 2025 05:59:22 +0000 ja hourly 1 https://wordpress.org/?v=6.9.4 https://otonan-syusyoku.work/wp-content/uploads/2023/10/cropped-名称未設定のデザイン-16-32x32.png フェイルオーバー – エンジニア見習い https://otonan-syusyoku.work 32 32 RDSでフェイルオーバー試してみたよ https://otonan-syusyoku.work/archives/1448 https://otonan-syusyoku.work/archives/1448#respond Wed, 18 Oct 2023 13:52:33 +0000 https://otonan-syusyoku.work/?p=1448 DBのあるべき姿の冗長構成

みなさんはDBの冗長構成を取っていますか？

冗長構成とは簡単に言うと、
システムやサービスの障害が発生した場合に、自動的に別のバックアップシステムやリソースに切り替え、中断を最小限に抑える仕組み
になります。

 

冗長構成を取っていると DB に障害が発生した際でも被害を最小限に抑えてシステム運用することが可能となっています。

データに破損が起きると案件次第では損害賠償に発展したり、ユーザーへの悪影響が生じたりするなどビジネスチャンスを失ってしまいます。

可能な限り冗長構成を取るようにしましょう〜

RDS for MySQL でフェイルオーバー試してみた

注意

RDS はちゃんとお金かかります！
自分で払える範囲のスペックで構築してください！
後、検証が終わったら RDS は閉じてください！！！
※RDS は停止してもお金がかかります。。。。(インスタンス料金, データベースストレージ料金, バックアップストレージ料金)

事前準備

EC2 と RDS の構築は済まして置いてください。

その上で1秒毎にDBへデータを登録する処理を PHP で書いていきます。

<?php
ini_set('mysqlnd.net_read_timeout', 3);
$i = 0;
$end_time = time() + 600;
while (time() < $end_time) {
  $result = hoge();
  sleep(1);
  echo $i . ":" . $result . "\n";
  $i++;
}

function hoge () {
  $result = 'connectionWaiting';
  try {
    $dbh = new PDO(
      'mysql:host=database-1.cizcjskkh2r7.ap-northeast-1.rds.amazonaws.com;dbname=testDB;charset=UTF8mb4',
      'admin',
      'password',
    );
    $dbh->setAttribute(PDO::ATTR_TIMEOUT, 3);
    $sql = "INSERT INTO testTable (created) VALUES ('" . date('Y-m-d h:i:s') . "')";
    if ($dbh->query($sql)) {
      $result = 'Succees';
    } else {
      $result = 'Faile';
    }
  } catch (PDOException $e) {
    $request = 'Die';
  }
  return $result;
}
?>

いざ実行

PHPの実行

php index.php

RDS の再起動

RDS はフェイルオーバー での再起動ができるので、フェイルオーバーのオプションを付けて再起動を行います。

まずはデータ登録処理のPHPを実行します。
フェイルオーバー実行前のデータ↓

mysql> select * from testTable;
+----+---------------------+
| id | created             |
+----+---------------------+
| 1 | 2023-10-18 10:39:07 |
| 2 | 2023-10-18 10:39:08 |
| 3 | 2023-10-18 10:39:09 |
| 4 | 2023-10-18 10:39:10 |
| 5 | 2023-10-18 10:39:11 |
| 6 | 2023-10-18 10:39:12 |
+----+---------------------+

 

フェイルオーバー実行後のデータ↓

mysql> select * from testTable;
+----+---------------------+
| id | created |
+----+---------------------+
| 50 | 2023-10-18 10:39:57 |
| 51 | 2023-10-18 10:39:58 |
| 52 | 2023-10-18 10:39:59 |
| 53 | 2023-10-18 10:40:00 |
| 54 | 2023-10-18 10:40:01 |
| 55 | 2023-10-18 10:40:02 |
| 56 | 2023-10-18 10:40:03 |
| 57 | 2023-10-18 10:40:04 |        ← 再起動で止まったところと思われる箇所
| 58 | 2023-10-18 10:41:10 |        ← 再起動完了したところと思われる箇所
| 59 | 2023-10-18 10:41:11 |
| 60 | 2023-10-18 10:41:12 |
| 61 | 2023-10-18 10:41:14 |
| 62 | 2023-10-18 10:41:15 |
| 63 | 2023-10-18 10:41:16 |
| 64 | 2023-10-18 10:41:17 |
| 65 | 2023-10-18 10:41:18 |
| 66 | 2023-10-18 10:41:19 |
| 67 | 2023-10-18 10:41:20 |
| 68 | 2023-10-18 10:41:21 |
| 69 | 2023-10-18 10:41:22 |
+----+---------------------+

わかったこと

わかっていないこと

  • 大量のデータになった場合の復旧時間
    • 今回の検証でもすぐに終わるときもあれば、３分以上かかる場合もあった
  • PHP 側に `ini_set(‘mysqlnd.net_read_timeout’, 3)` を入れないと再起動が完了しても処理が継続しない
    • RDS 側でデッドロックが走っている？
    • 接続先を探している？
    • RDS 側に設定が必要？
    • とりあえずプログラムでちょっとした工夫は必要そう

まとめ

今回の検証で RDS を使用して冗長性を確保することができたのではないかなぁという所感です〜

実際に検証を通して冗長性のある構成とはこんな感じなんだなぁと言うのがしれたのはかなり大きいです。笑

 

実際、 DB を使わないシステムは限りなく少ないので DB が死んでも大丈夫と言える構成を取ることでビジネスチャンスを失わないというのはかなり大切だと考えています。

引き続き検証を続けていく必要がありそうです〜

 

]]> https://otonan-syusyoku.work/archives/1448/feed 0 僕が考えるRDSを激推する理由 https://otonan-syusyoku.work/archives/1426 https://otonan-syusyoku.work/archives/1426#respond Thu, 21 Sep 2023 14:42:53 +0000 https://otonan-syusyoku.work/?p=1426 僕が考えるRDS を激推する理由

バックアップが楽ちん

RDS を推したい理由の上位にくるのがバックアップの手軽さです。

AWS の公式にも記載がある通り、バックアップを自動で取ってくれます。

過去に クラウドサーバー 上にインストールした MySQL のバックアップ手法として、cron にて AWS SDK for PHP を用いて S3にダンプファイルを保管する手法を取っていた自分からすると RDS のバックアップはかなり楽ちんです。
だって、以下の設定が不要になりますからね。笑

  1. AWS SDK for PHP のインストール
  2. cron にて日次の実行処理を記述
  3. S3 に送信処理を記述

デフォルトで有効になっている Amazon RDS の自動バックアップ機能により、データベースとトランザクションログがバックアップされます。Amazon RDS では DB インスタンスのストレージボリュームのスナップショットを自動的に作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。

このバックアップは、バックアップウィンドウと呼ばれるユーザーが設定可能な 30 分間隔の時間に 1 日 1 回行われます。自動バックアップは、お客様が設定した日数の間、保持されます (バックアップ保持期間と呼ばれます)。自動バックアップの保持期間は、最大 35 日間まで設定できます。

Amazon RDS のバックアップと復元

 

また、 RDS には自動バックアップに加えてポイントインタイムリカバリという機能があり、特定の時点に戻すことができます。（5分毎にデータベースの変更ログのアーカイブが自動で実行されます）

これは、データの損失を最小限に抑えることのできる機能となっており、ポカしやすい人には必需品と言えるほどの機能となっています。

先程申し上げた日次のバックアップだけでは不足しているバックアップ分を補填しているので、個人的にはすごく好きです。

DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。

DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。

死活監視が楽ちん

RDS はデフォルトでメトリクスデータを1分間隔で CloudWatch に送信してくれます。
（CloudWatch はメトリクスの収集、アラームの設定、ログの収集と監視などを対応してくれるサービスです）

 

これも自分ごとではありますが、死活監視をするために以下のようなインフラを構築しました。

イメージ 設定手順
監視構成
  1. アプリケーションサーバー構築
  2. アプリケーションサーバーを監視するサーバー（監視サーバー A）を構築
    1. Zabbix をインストール
    2. アプリケーションサーバーに 監視サーバーA のエージェントをインストール
  3. 監視サーバーA にて監視設定
  4. 監視サーバーAを監視する監視サーバーBを構築
    1. Zabbix をインストール
    2. 監視サーバーAに監視サーバーBのエージェントをインストール
  5. 監視サーバーBにて監視設定

[getpost id=”1243″ cat_name=”1″ date=”0″][getpost id=”1220″ cat_name=”1″ date=”0″]

 

手順書いてみたんですけど、すっげー面倒くさいですね。。。

その反面、 RDS では上記のような面倒くさい事をしなくても死活監視が簡単にできてしまうんです。

下記のあたりを見てれば DBが生きているかどうかを判別することができるので、すごく楽です。

  • データベースの稼働状況
  • CPU使用率
  • メモリ使用率
  • ディスクストレージ
  • データベースのクエリおよびスロークエリ

これらに対して閾値を設定して異常状態を感知できるようにすれば、僕が構築したよく分からない事はしなくても済むなんて素敵すぎる！！！！

フェイルオーバーが楽ちん

フェイルオーバー の構成を取っていると何らかの障害が起きた際に被害を最小限に止めることができます。

実際に手動で組み込んだことはないのですが、天下の Oracle 様の解説記事を読んでみるとごちゃごちゃと設定が必要そうで、適切な冗長構成を取るのが難しそうな印象を受けました。

 

対して RDS は以下の条件を満たせば、冗長構成を取ることが可能となっています。

  • マルチアベイラビリティーゾーン
  • ホットスタンバイオプションの有効化

実際の手法を確認したい方はこちらの記事をご確認ください。

[getpost id=”1448″ cat_name=”1″ date=”0″]

まとめ

単純なDBを構築したい場合、RDS を使うことで楽に安全に構築することができます。

過去の自分に戒めを込めて、 RDS 使うと幸せになれることを胸張って伝えていきたいです。笑

 

]]> https://otonan-syusyoku.work/archives/1426/feed 0