JAWS-UG朝会 #45 LT_EC2運用

2023年5月23日 アイレット株式会社 佐藤 竜也 JAWS-UG朝会 #45 EC2運用は EBS復元で幸せになれる （かも）

• https://jawsug-asa.connpass.com/event/274687/

自 己 紹 介 # 名前 佐藤 竜也（ますの） @masno_soy # 所属・担当 ・アイレット株式会社 ・AWS基盤 運用・保守 / PM（仮） # 資格 ・2023 Japan AWS All Certifications Engineers # 触ってみたいAWSサービス ・Fargate ・App Runnner ・Amplify

は じ め に みんな大好きEC2 時代はいつでもEC2運用 （原点回帰） ※本日のLTはインフラ1年生時代のお話※

学びを得た事例 System32フォルダを バルス（del *）してしまったお話 大容量データを 別ＥＣ２に移動したかったお話

Case1 【事の発端】 ・フォルダ内データを全削除する簡易バッチを作成 ・検証環境でテスト実行 ・本番環境で最終チェックのテスト実行 →CドライブからDドライブへのコマンドでこける （テスト環境に複数ドライブ設定が無い痛恨のミス） →管理者権限で実行される ・System32フォルダ内が壊滅する

Case1 その後どうなったのか ・定期リブート前：何事もなく稼働 ・定期リブート後：ステータスチェックに失敗する AMIから復元を試みる →世代管理が１周済み →復元不可（絶望）

Case1 概要図 バックアップ/日 AMI 7世代管理 Instance C システム関連 データを保存 D 運用保守関連 データを保存 Volume

Case1 被害状況 バックアップ/日 AMI 7世代管理 Instance C システム関連 データを保存 D 運用保守関連 データを保存 Volume

Case1 Ｄドライブのデータ 復元出来るのでは？？

Case1 復旧要件 ・Cドライブに救出したいデータは無し ・Dドライブのデータだけ復活すれば良い 復元の手順が見える EC2新規作成 EBSボリュームのデタッチ/アタッチ

Case1 Dドライブのみ復元することに全力で対応する Instance C システム関連 データを保存 D ❶Ｄドライブ ボリュームデタッチ C Instance D ❷ 新ＥＣ２に ボリュームアタッチ Volume 既存EC2インスタンス削除→同じIPでEC2インスタンス作成も可能 ※EC2削除場合はEBS同時削除に注意

Case1 無事に復元！ やってて良かったボリューム設計

学びを得た事例 System32フォルダを バルス（del *）してしまったお話 大容量データを 別ＥＣ２に移動したかったお話

Case2 大容量データを別ＥＣ２に移動したかったお話 概要図 VPC A Server A Instance / Volume 全データを保管（1TB） ・システム ・ログ ・アプリ etc... AMI 1世代 出来れば今日中で VPC B Server B Instance 作業用サーバ / Volume サーバAのデータ サーバBに移動よろしく

Case2 思考を駆け巡らせるも不安材料のみ思いつく ・SCPコマンドがAサーバで利用可能か不明。 ・そもそもSCPコマンドで今日中に出来るのか...。 ・ネットワーク負荷＆サーバ負荷の二次災害の恐怖。 良い方法 あるよ

Case2 AWS機能を使って解決すれば良い。 【作業概要】 ・AサーバのEBSスナップショットを取得 ・スナップショットから新EBSボリュームを作成 ・Bサーバにアタッチ＆マウント設定 ※時間を優先するのであれば AMIのスナップショットを利用することも可能

Case2 実際にやったこと VPC A VPC B Server A Instance / Volume AMI 1世代 全データを保管（1TB） ・システム ・ログ ・アプリ etc... スナップショット作成 Server B / Instance A Volume AMIのスナップショット も利用可能 Snapshot EBSボリューム作成 EBSボリュームアタッチ マウント設定

Case2 大容量データを別ＥＣ２に移動したかったお話 無事に 大容量データ 移動完了

まとめ ・EC2構築前のボリューム設計は大事 ・EBS復元でデータが救えることを考える ・EC2トラブル時にEBS復元方法を思い出す 例） ・EC2のトラブル対応 ・大容量データのEC2間移動 など

ご清聴ありがとうございました