先日、業務にて「既存のRDSのストレージを暗号化したい」という、シンプルかつ重たい要件が降ってきました。

これの何が困るかというと、皆様ご存知の通りRDSの仕様です。 RDSは作成後の暗号化ステータスの変更ができません。つまり、既存のRDSを暗号化するためには、「暗号化有効」設定で作り直す（再作成する）必要があります。

参考: Amazon RDS DB インスタンスおよびクラスターの暗号化 – AWS Prescriptive Guidance

さらに今回はインフラを AWS CDK で管理しています。
単純にCDKのコードを書き換えてデプロイすると、CloudFormationの仕様により「リソースの置換」が発生し、予期せぬダウンタイムやデータ損失のリスクがあります。
また、よくある「スナップショットから復元して差し替え」という手法も、CDKのState管理との兼ね合いで今回は採用できませんでした。

様々な制約がある中、「既存データを維持しつつ」「CDK管理のまま」暗号化リソースへ移行できたので、その手法を共有します。

今回の要件と制約

今回のミッションにおける前提条件は以下の通りです。

• 既存RDSの暗号化（最重要）
• 既存データをそのまま移行できること
• アプリ側の変更を避けるため、エンドポイント（またはDNS）の変更がないこと
• ダウンタイムは許容（ALBでメンテナンス画面を挟む前提）
• バッチ処理が稼働していない夜間帯での作業
• CDKコードの変更は最小限に留め、今後もCDKで管理し続けること

結論：CDKデプロイを3回行う

結論から言うと、「削除ポリシーを変更して既存RDSをCDK管理から切り離し、新規で暗号化RDSを作成する」という力技で解決しました。

具体的には以下の3ステップでデプロイを行います。

1. RemovalPolicy.RETAIN を設定（既存保護）
2. instanceIdentifier を変更（既存切り離し）
3. storageEncrypted: true を指定（新規作成）

なぜこの手順が必要なのか？（ハマりポイント）

通常、CDKで管理されているリソースに対し、instanceIdentifier（物理ID）を固定したまま storageEncrypted: true に変更してデプロイしようとすると、以下のエラーが発生して失敗します。

CloudFormation cannot update a stack when a custom-named resource requires replacing

これは、「カスタム名（明示的な名前）がついているリソースを置換（削除＆作成）することはできない」というCloudFormationの安全装置です。これを回避するために、あえて識別子を変更して別リソースとして認識させる必要があります。

手順詳細

1. 削除ポリシーの変更

まず、既存のRDSがCDKのスタック操作によって削除されないようにします。 これをやらないと、次の手順で「既存RDSの削除」が走ってしまい、データが消えます（超重要）。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 現在の識別子
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN, // ここを追加！
});

この状態で一度 cdk deploy します。 これで、このRDSはスタックから削除される際も、AWS上にはリソースが残るようになります。

2. instanceIdentifier の変更

次に、既存のRDSをCDKの管理下から外す（Orphanにする）作業です。 CDK上の識別子を、既存のものとは別の名前に書き換えます。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db-temp', // 3と被らない一時的な名前に変更
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN,
});

この状態で cdk deploy します。

何が起きるか：
CloudFormationは「my-prod-db を管理から外し、新しく my-prod-db-temp を作る」という挙動をします。 ステップ1で RETAIN を設定しているため、旧RDS（データ入り）は削除されずにそのまま残ります。
※この時点でアプリはまだ旧RDSを見ています。

3. いよいよ暗号化RDSの構築

最後に、本命の「暗号化されたRDS」を作成します。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 元の名前に戻す（ここが変わるとエンドポイント変わるので注意）
  storageEncrypted: true,           // 暗号化をON
  removalPolicy: cdk.RemovalPolicy.RETAIN,
  // ...
});

この状態で cdk deploy します。

注意点：
もし instanceIdentifier を手順1と同じ名前（my-prod-db）に戻したい場合、手順2の時点でAWS上に古い my-prod-db が残っているため、名前重複でエラーになる可能性があります。
その場合は、AWSマネジメントコンソールまたはCLIから、古いRDS（手順2で切り離されたもの）の識別子を手動で my-prod-db-old などにリネーム してからデプロイしてください。

これで、暗号化された空っぽのRDSが立ち上がりました。

データ移行

新旧2つのRDSが存在している状態になりました。

• 旧RDS
  • データあり
  • 非暗号化
  • CDK管理外
• 新RDS
  • データなし
  • 暗号化済み
  • CDK管理下

データ量がそれほど多くない（数GB〜数十GB程度）ため、今回はシンプルに mysqldump で移行を行いました。TB級の場合は AWS DMS (Database Migration Service) の利用を検討してください。

# SSM Session Manager 等で踏み台サーバーに接続

# 1. 旧RDSからデータをエクスポート（パイプで圧縮して転送時間を短縮）
mysqldump -h [旧RDSエンドポイント] -u [ユーザー名] -p \
  --single-transaction --routines --triggers \
  --databases [対象のスキーマ] \
  | gzip > dump.sql.gz

# 2. 新RDSへインポート
zcat dump.sql.gz | mysqldump -h [新RDSエンドポイント] -u [ユーザー名] -p

データの移行が完了したら、アプリケーションの接続先が新RDSに向いていることを確認し、メンテナンスを解除します。

後片付け

無事稼働確認が取れたら、不要なリソースを削除してお財布を守りましょう。

1. 手順2で立ち上がった一時的なRDS（CDKの管理からは外れているはずですが、念の為確認して削除）
2. 手順1以前から存在していた旧RDS（リネームした my-prod-db-old など）

スナップショットが取れていることを確認した上で、マネジメントコンソールから削除しました。

(おまけ) 試したけどうまくいかなかったこと

cdk import での既存リソース取り込み

既存のリソースをリネームして、新しいスタックに取り込もうと cdk import を試みましたが、以下のようなメッセージが出てスキップされました。

TmpStack: no new resources compared to the currently deployed stack, skipping import.

また、定義と実リソースのプロパティ（暗号化の有無）が食い違っているため、インポート自体が整合性エラーになる可能性が高いです。

DatabaseInstanceFromSnapshot の利用

スナップショットから復元するCDKのクラスですが、これをメインの定義にしてしまうと、常に「スナップショットから作られた状態」が正となり、パラメータグループやバージョン更新などの運用時にドリフト（設定乖離）の管理が面倒になると判断し、今回は見送りました。

まとめ

CDKで管理しているステートフルなリソース（RDSなど）の「再作成必須な変更」は非常に神経を使います。 「Retainで保護」→「Identifier変更で管理から切り離し」→「新規作成」 というフローは、RDSに限らず他のリソースでも応用が効くテクニックなので、覚えておいて損はないはずです。

なにはともあれですが、RDSは最初から暗号化しましょう。これだけは覚えて頂けると。。。

同じ悩みを抱えるPHPer（およびAWS使い）の助けになれば幸いです！

本記事では、AWS CDK（Cloud Development Kit）を用いて、ECSとRDSの監視アラーム、ECSのオートスケーリング、そしてそのイベントをSlackに集約する通知基盤をIaCとして一括で構築する方法を解説します。

監視・通知アーキテクチャの全体像

採用するアーキテクチャは以下の通りです。

事前準備: AWS ChatbotとSlackの連携

CDKデプロイの前に、AWSアカウントとSlackを連携させるためのAWS Chatbotクライアントを作成しておく必要があります。

1. AWS Chatbotコンソールで、Slackワークスペースとチャンネルを連携させます。
2. この設定により、通知先のSlackチャンネルIDとワークスペースIDが取得できます。これらはCDKコード内で使用します。

監視とオートスケール基盤の構築

今回は、ECSサービスとRDSインスタンスが既に存在することを前提に、その監視・スケール設定を定義するCDKスタックを作成します。

CDKスタックのセットアップ

必要なCDKライブラリをインポートし、スタックを定義します。

// lib/monitoring-stack.ts

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';
import * as actions from 'aws-cdk-lib/aws-cloudwatch-actions';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as autoscaling from 'aws-cdk-lib/aws-applicationautoscaling';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as chatbot from 'aws-cdk-lib/aws-chatbot';

// 環境依存の定数を定義 (適宜置き換えてください)
const CLUSTER_NAME = 'your-ecs-cluster-name';
const SERVICE_NAME = 'your-ecs-service-name';
const RDS_IDENTIFIER = 'your-rds-instance-identifier';
const SLACK_CHANNEL_ID = 'C01234567'; // 取得したチャンネルID
const SLACK_WORKSPACE_ID = 'T01234567'; // 取得したワークスペースID

export class MonitoringStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 既存のECSサービスを参照
    const ecsService = ecs.FargateService.fromFargateServiceAttributes(this, 'ExistingEcsService', {
      serviceArn: cdk.Stack.of(this).formatArn({
        service: 'ecs',
        resource: 'service',
        resourceName: `${CLUSTER_NAME}/${SERVICE_NAME}`,
        sep: '/',
      }),
      cluster: ecs.Cluster.fromClusterAttributes(this, 'ExistingCluster', {
        clusterName: CLUSTER_NAME,
        vpc: ({} as any), // 参照のため空オブジェクト
        securityGroups: [],
      }),
    });
  }
}

通知用SNSトピックとChatbotの設定

アラームやイベントが通知を送るSNSトピックを作成し、それをAWS Chatbotに連携させます。

// 1. 通知用SNSトピックの作成
    const alarmTopic = new sns.Topic(this, 'AlarmTopic', {
      displayName: 'System-Monitoring-Notifications',
    });

    // 2. AWS ChatbotとSNSトピックの連携 (Slackへのルーティング)
    new chatbot.SlackChannelConfiguration(this, 'ChatbotConfig', {
      slackChannelConfigurationName: 'EcsRdsMonitoring',
      slackWorkspaceId: SLACK_WORKSPACE_ID,
      slackChannelId: SLACK_CHANNEL_ID,
      notificationTopics: [alarmTopic], // このトピックへの通知がSlackに送られる
    });

ECSとRDSの監視アラーム設定

主要なメトリクスに対してCloudWatchアラームを作成し、アクションとして上記SNSトピックを設定します。

// --- ECS Fargate アラーム ---
    // ECS CPU利用率が80%を超えた場合にアラーム
    const ecsCpuAlarm = new cloudwatch.Alarm(this, 'EcsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/ECS', 'CPUUtilization').with({
        dimensionsMap: { ClusterName: CLUSTER_NAME, ServiceName: SERVICE_NAME },
      }),
      threshold: 80, 
      evaluationPeriods: 2,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'ECS Service CPU utilization is too high.',
    });
    ecsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));
    // ecsCpuAlarm.addOkAction(new actions.SnsAction(alarmTopic)); // 復旧時も通知したい場合は追加

    // --- RDS アラーム ---
    // RDS CPU利用率が70%を超えた場合にアラーム
    const rdsCpuAlarm = new cloudwatch.Alarm(this, 'RdsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/RDS', 'CPUUtilization').with({
        dimensionsMap: { DBInstanceIdentifier: RDS_IDENTIFIER },
      }),
      threshold: 70, 
      evaluationPeriods: 3,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'RDS CPU utilization is too high.',
    });
    rdsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));

ECSサービスのオートスケーリング設定

ECSサービスをCPU利用率$60%$を目標に自動スケーリングするように設定します。

// 3. ECSサービスのオートスケーリング設定
    // サービスのDesired Countをスケーリング対象にする
    const scalableTarget = autoscaling.ScalableTarget.forEcsService(this, 'EcsScalableTarget', {
      service: ecsService,
      minCapacity: 1, // 最小タスク数
      maxCapacity: 5, // 最大タスク数
    });

    // 目標CPU利用率 60% を維持するように調整するターゲット追跡スケーリングポリシー
    scalableTarget.scaleToTrackMetric('CpuScalingPolicy', {
      metric: ecsService.metricCpuUtilization(), 
      targetValue: 60,
      scaleOutCooldown: cdk.Duration.seconds(60),
      scaleInCooldown: cdk.Duration.seconds(300),
    });

// 4. オートスケールイベントを捕捉しSNSトピックへルーティング
    new events.Rule(this, 'AutoScalingNotificationRule', {
      description: 'Notify Slack on successful ECS Auto Scaling events.',
      eventPattern: {
        source: ['aws.application-autoscaling'],
        detailType: ['Application Auto Scaling Policy Execution'],
        detail: {
          // 成功したスケーリング操作のみを通知
          statusCode: ['Successful'], 
        },
      },
      // ターゲットは既存のSNSトピック
      targets: [new targets.SnsTopic(alarmTopic)],
    });

RDS

RDSの自動起動対策

RDSは7日間の停止後に自動で起動してしまう仕様が存在する。

稼働していないシステムで使用しているRDSは止めておきたいという要望が上がってきた。

7日間ごとに停止を手動で行うのは面倒くさすぎるし、ヒューマンエラーが発生する可能性がある。

そんな時に EventManeger にてRDSの自動停止を達成する事ができた。

やったこととしては、以下の通り。

• RDSの自動停止/起動 のスクリプトをLambda で定義
• Lambdaスクリプトを EventManeger にて7日周期で実行するように定義
  • 起動 → 停止 の順番で実行するようにしないと、RDS本体の再起動とLambdaスクリプトの停止処理が同時刻に実行されてしまい、自動停止が出来ないよ

Aurora

クラスターとインスタンスという概念がある。

Blue/Greenデプロイ

ダウンタイムを限りなく減らすデプロイ手法のこと。（2系統の環境を作成し、ユーザーが使用しているシステムに影響を少なくする）

当手法では、エンドポイントの切り替えを行う必要がないため、プログラマー目線だとかなり作業が楽。（インフラ担当の作業範囲で収まるため）

実際に経験したユースケースは以下の通り。

• RDS for MySQL の5系から8系へのアップグレード
• インスタンスサイズの変更

上記対応を行った際のダウンタイムは2 ~ 3分程度で切り替えが行われた。これはかなり凄いことだと思う。
以前までの対応だと、以下の対応があると思われるが、当手法ではコンパネから手軽に実施することができる。

• 本番環境とは別にMySQLサーバーを構築し、各種テストを実施後に現環境と旧環境の切り替え
  切り替え後はエンドポイントの切り替えを行う必要がある。
• システムメンテナンス期間を設け、現環境の変更を行う。

Blue/Greenデプロイは素晴らしい。。。

インスタンスタイプのサポート期日は守ろう

とあるタスクにて、RDSの インスタンスタイプのアップグレード & MySQLのバージョンアップ の作業があった。

その際の作業方法として、ダウンタイムを可能な限り削減するべくBlue/Greenデプロイを想定していたが、T2系インスタンスのサポートが終了していたため、Blue/Greenの作成が出来なかった。

本来であれば Blue/Green を作成後にGreen環境でインスタンスタイプのアップグレードとMySQLのバージョンアップを考えていたが、こうも上手くいかないとは思わなかった。

代替手段として、RDSのスナップショットからサポートされているインスタンスタイプで新規インスタンスを起動し、アプリケーションのエンドポイントを切り替える方法を考えたが、エンジニアが関与していないシステム（Redash等が上がっていたが、複数のサービスが連携していると報告が上がってきた）があるため、この手法は取れなかった。

そのため、エンドユーザーにダウンタイムを許容してもらう形で現行環境のRDSをインプレースで対応することになった。

エンジニアのプライドとして許せなかったが、前任の構築者が既にいなかったことやI/Oの遅さからユーザーからのクレームがあり早急に対応する必要があったので仕方がない結果となった。
（このタスクは他チームのインフラを面倒みることになっていたので余計に情報が絡み合ってめんどくさかった）

最終的には深夜作業で対応することになり、なんとか目的を達成することが出来た。

今後の教訓としては、インスタンスタイプのサポート期限は守ろう。

パラメータグループはデフォルトを使うな

時間がないからと言って、AWSが用意しているパラメータグループを使うな。

以下の問題が起きる

• Slow Query の出力がない
• クエリの実行時間の制限がない

問題の発生に気付けないのは大きな問題だ。

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

EC2

Amazon Linux2023 は remiリポジトリが使えないぞ

Amazonlinux2023 はAWSさんが独自で管理しているOSらしいので、remi リポジトリがサポートされていない。

epel も使えない。

Q: AL2023 は AL2 のような Amazon-Linux-Extras を搭載していますか?

A: いいえ。AL2023 には extras はありません。言語ランタイムなどの高レベルのソフトウェアパッケージの場合、四半期ごとのリリースを使用して、リポジトリで提供されるデフォルトパッケージに加えて、個別の名前空間化されたパッケージとしてメジャー/マイナー更新をパッケージに追加します。 例えば、Amazon Linux 2023 のデフォルトの Python バージョンは 3.8 である可能性がありますが、Python 3.9 (python39) が利用可能になると、別の名前空間化されたパッケージとして追加されます。これらの追加パッケージは、アップストリームリリース頻度とサポートモデルに厳密に従います。また、それらのサポートポリシーは、コンプライアンスとセキュリティのユースケースのために、パッケージマネージャーによってアクセスされることがあります。デフォルトパッケージは、AL2023 の存続期間を通じてサポート対象であり続けます。

サポート切れの PHP7.4 を使いたいという要件を達成するため、PHPの公式サイトからソースをビルドする事を考えたが、 php-fpm の導入及び関連する拡張機能の有効化の方法が分からなかったため、当手法は断念。

代わりに Rocky Linux を選択し、remi リポジトリからPHP7.4のインストールを行った。

（そもそもサポートの切れている言語Version 使うなよというお話でした

OSのメンテナンスは定期的に

10年近く稼働している一度もOSの再起動を行ったことのない EC2 のメンテナンス作業を行うタスクがあった。
（何で誰も手つけて来なかったの？馬鹿じゃないの？

構築した人は既におらず、インスタンスの中身がどうなっているかわからない状況だったため、作業前に以下の対応を行った。

• EBS バックアップ取得
• AMI バックアップ取得
• インスタンスの中で使用しているプログラムについての調査
  • 各種言語のバージョン(拡張機能
  • cron
  • シェル
• VPCの構成

とりあえず結果からいうとデータの損失等が発生せず作業を終了することができた。

（やったこととしては、インスタンスサイズのアップグレード と ストレージのアップグレード。

若者に伝えたいのが定期的にメンテナンスを行うことと運用がしやすいように設計書なり構成図なりを残すこと。
（まじで何でも良いので、データとして残すことをオススメします。分かる人が見たら多少ズレのある設計書でもなんとなく予想がつくため。

ALB

リスナールールのデフォルトルールは503返したほうが無難

ALB は2つ以上のパブリックサブネットを設定する必要があります。

Route53 の Aレコード にALBのエイリアスを設定している場合は、ALBのパブリックIPが返ってくるようになる。

nslookup xxxx.com

返却されるIPにアクセスするとALBで設定されているリスナールールに従った、ルーティングが行われる。

そのため、リスナールールのデフォルトルールが APPサーバーへのルーティングを行うターゲットグループを指定すると ALB のパブリックIP でアクセスすることができるようになってしまう。

これの怖いところが、EC2のセキュリティグループでは弾くことが不可能なため、意図しないルーティングが行われてしまう可能性があることです。

直近、 us-west-2 から大量のアクセスが来てしまい、アプリケーションサーバーが落ちるといった事業が発生してしまった。
リスナールールの設定は適切に。。。

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

先日 RDS を構築した際に EC2 と接続ができなくて泣きたくなった。

原因はシンプルで EC2 に MySQL クライアントが存在しませんよという内容です。

クラウド先（RDS）には MySQL が存在しているのに、わざわざ EC2 に MySQL 本体をインストールするのもなぁと思っていたのですが、ちょっと工夫するだけで EC2 から接続できるようにすることができることを知ったので共有ですぅぅぅ〜

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

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

いざ実践

• とりあえずアプデ

  sudo apt update
  

• mysql-client のパッケージを検索
  なんかいい感じのやつ出てくるよ

  apt search mysql-clien

• 最小を入れたい
  (お使いのバージョンに合わせたものを指定してね
  (client を入れれば MySQL コマンドが使えるよ

  apt install mysql-client-core-8.x

• MySQL に接続

  mysql -h rds.amazonaws.com -P 3306 -u rds -p

失敗時のエラー

権限不足

Permission denied

• Ubuntu で入ったから何となく行けてんのかと思いきや…
• sudo しなさいよ

接続失敗

ERROR 2003 (HY000): Can't connect to MySQL server on

• RDS の設定漏れ
• EC2 からの接続許可

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

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

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

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

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

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

事前準備

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 |
+----+---------------------+

わかったこと

• データは途切れるが、DB の復旧とともにデータ登録が可能となる
  • 被害が大きくなりにくい
  • エンドポイントが変更されないので、プログラム側で特別な処理は不要（超嬉しい）
• 難しい設定は不要
  • 天下の Oracle 様が解説している高可用性構成の作り方
    https://www.oracle.com/jp/a/tech/docs/technical-resources/120127-mysql-ha.pdf
    https://downloads.mysql.com/presentations/01_201311_MySQL_JP_Tech-Tour.pdf

わかっていないこと

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

まとめ

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

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

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

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

バックアップが楽ちん

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 はメトリクスの収集、アラームの設定、ログの収集と監視などを対応してくれるサービスです）

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

イメージ	設定手順
	アプリケーションサーバー構築 アプリケーションサーバーを監視するサーバー（監視サーバー A）を構築 Zabbix をインストール アプリケーションサーバーに 監視サーバーA のエージェントをインストール 監視サーバーA にて監視設定 監視サーバーAを監視する監視サーバーBを構築 Zabbix をインストール 監視サーバーAに監視サーバーBのエージェントをインストール 監視サーバー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 使うと幸せになれることを胸張って伝えていきたいです。笑