この記事は、「AWS Community Builders Advent Calendar 2023」13日目の記事です。

Community Buildersとしては、[Serverless]のカテゴリで現在活動しています。しかしそれはそれとして、個人のAWSアカウントでは、長年WordPressを動かすためのEC2が１台稼働しています。記事を移行させる手間や、新しいエディタや管理画面を覚えることを考えると、なんだかんだ多少手間がかかってもWordPressを使い続けるのが性に合っているなぁ・・・ということで、たまにはサーバーフルな話もしたいと思います。

WordPressを気軽に壊せるようにしておきたい

もともとインフラレイヤの人間ではないため、サーバーの設定どころかPHPやMySQLなどのデバッグもなかなか苦手意識を持っていたりします。そんな人間がEC2上にホストするアプリを一人で管理するためには、「壊れてもどうにかなる」と思える環境づくりが重要です。

ということでこのWordPressを動かしているサーバーでは、「壊してもすぐ復旧できるように、バックアップを自動で作成する仕組み」を用意しています。これはEBSのストレージ丸ごとバックアップを作成し、壊れたらそれごと復旧させることですぐにリカバリーできることをめざしています。また、同時にバックアップが貯まることでコストが増えることも避けたいため、数日でバックアップを消すようにもしています。

・・・このような仕組みを組むのはなかなか大変そうに聞こえませんか？実はとあるサービスを利用することで、ノーコードでバックアップの管理が可能です。

Amazon Data Lifecycle Manager

ノーコードでEC2（厳密にはEBS）のバックアップを管理するには、[Amazon Data Lifecycle Manager] を使います。

EC2の管理画面で、Data Lifecycle Managerまたはライフサイクルなどのメニューを探して開きましょう。

ライフサイクルポリシーを作ることで、バックアップ管理を設定できます。ポシリータイプはインスタンス・ボリュームごとにカスタマイズしたサイクルを指定できる「カスタムポリシー」と、リージョン内の全てのボリューム・インスタンスのバックアップが作れる「デフォルトポシリー」の２つがあります。

カスタムポリシーの場合、対象にするボリュームやインスタンスをタグやインスタンスIDなどの値で指定できます。

除外するボリュームの設定なども行えます。また、ポリシーのステータスを[有効化されていません]にすることもできますので、作成だけしてみることなどもできそうです。

バックアップする対象を決めた後は、どのようなスケジュールでバックアップを処理するかを決めます。「毎日X時から、2つまで保持する」みたいな細かい設定までできる様子です。

他にもクロスリージョン・クロスアカウントの共有や、バックアップ作成前後に動かすスクリプトなども指定できます。

クロスアカウントなどは、EC2を利用してサービスを提供している場合などにも使えるのではないかと思います。

現在利用しているライフサイクル設定は、「毎日実行・3件保持」

このサイトのバックアップ設定は、こんな感じです。

Headlessに利用しているため、2・3日前までロールバックできればなんとかなるだろうとの判断で、保持数を絞った運用にしています。

チームで運用している場合などでは、もう少し長めに持った方がいいケースもあるかもしれません。

バックアップ作成状況のモニタリングもできる

Data Lifecycle Managerにはモニタリング機能もついています。「どれくらいのリソースが対象」で、「スナップショット作成に成功しているか」がみることができます。

Amazon EventBridgeで通知もノーコード

Data Lifecycle ManagerはAmazon EventBridgeとも連携できます。

aws.dlmから始まるイベントパターンを指定することで、スナップショット作成などに関するイベントを受け取れます。

Amazon SNSに連携させて、AWS Chatbot経由でSlackに投げると、バックアップ作成状況をSlackでみれます。

おわりに

サーバーレスの対極にあるEC2ですが、ノーコードな仕組みを組み合わせることで、運用保守をサーバーレス的に行うことは可能です。

Systems Managerなども組み合わせて、より管理レスなサーバー運用を目指したいと思っていますので、また新しい試みをした際にはご紹介します。