Zenn
🦛

前にやった[AWS EC2の運用]まとめてなかったので。

2024/08/18に公開
初心者
tech

題名の通りでっす。

ライフサイクル

ライフサイクルとは、
EC2インスタンスを起動してから、終了するまでの状態遷移のこと。

インスタンスの状態変化を確認

  • インスタンスの状態から確認できる。
    起動とか、再起動とか、停止、終了とかのやつ。

  • インスタンスの停止/起動時の挙動
    インスタンスを停止すると、インスタンスは、物理サーバー上から削除される。
    再びインスタンスを起動すると、停止前とは別の物理サーバー上で起動する。
    表面上は変化していませんが、背後ではこの動作が行われていることを認識しておくこと。

  • インスタンス再起動時の挙動
    マネジメントコンソールによる再起動は、OSからの再起動と同等の効果となるため、同じ物理サーバーが保持される。
    ほとんどの場合、インスタンスのパブリックIP、インスタンスストアのデータも引き続き利用できる。

  • インスタンス停止時のEBSやEIPの挙動
    インスタンスを終了する際の設定によって、
    EBSやEIPリソースの残る・残らないが決まる。

インスタンスを終了するときに、EBSも合わせて削除する

  • インスタンス作成時のストレージ(ボリューム)で設定できる。
    終了時に削除の項目ではい(Yes)を選択すると、EC2終了時に、共に削除される。
    いいえ(No)を選択すると削除されない。

EIPを解放する(解放＝削除)

  1. インスタンスを選択する
  2. 下の詳細タブにあるElastic IPアドレスをクリック
  3. 表示された画面で、[アクション]からElastic IPアドレスの関連付けの解除を行う
  4. [アクション]から、Elastic IPアドレスの解放を行う

スケジュールイベント

EC2インスタンスは、AWSによって[再起動][停止/開始][リタイア]などのイベントが予定されることがある。
イベントが発生するのは、
[EC2インスタンスのメンテナンスが行われるとき]や、
[回復不可能な障害が検出された時]など。

イベントが予定されると、AWSアカウントに関連付けられたEメールアドレス宛に、お知らせメールが送信される。
このEメールには、イベント開始/終了日などの詳細情報が記載されている。

スケジュールイベントの種類

Instance stop

  • インスタンスが停止する
  • 再起動すると、別のサーバーへ以降される

Instance retirement

  • Instance Store-Backed AMIの場合：Instance Storeによってバックアップされた後、削除される。
  • EBS-Backed AMIの場合：Amazon EBSによってバックアップされた後、停止する。

Instance reboot

  • インスタンスが再起動される

スケジュールイベントを確認するには

予定されたイベントを確認するには、
マネジメントコンソールで行うか、AWS CLIで行う。

[ 方法 ]
マネジメントコンソールから、EC2ダッシュボードの下にある、イベントクリック

スケジュールイベント発生時、取るべきアクション

イベント内容によって、取るべきアクションは変わってくる。
基本的には、通知メールに記載されたアクションどおりに対応すれば良い

さらに、最新のAWSドキュメントページの情報を確認することで、
アクションの詳細情報を得られる場合もあるので、
AWSドキュメントページを一読することと良い。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html#schedevents_actions_retire

Auto Recovery(ステータスチェック)

AWSでは、実行中のEC2インスタンスに対して、
定期的なステータスチェック(監視)を行っている。
(インスタンスのステータスチェック"2/2のチェックに合格しました"ってところ。)

このステータスチェックによって、AWSの関与が必要な問題
(物理的なハードウェア障害や、なんらかのAWS側の問題が起因するケース)が検出されることがある。

ステータスチェック失敗の種類と原因

システムステータスチェック(StatusCheckFailed_System)

EC2インスタンスをホストしているハードウェア側の障害

  • 原因
  1. ネットワーク接続の喪失
  2. システム電源の喪失
  3. 物理ホストのソフトウェアの問題
  4. ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

インスタンスステータスチェック(StatusCheckFailed_Instance)

EC2インスタンス内部で発生している障害。
ユーザーが関与して修復する必要がある

  • 原因
  1. 誤ったネットワーク設定や起動設定
  2. メモリの枯渇(こかつ)
  3. ファイルシステムの破損

ステータスチェックの失敗を自動的に検出する

Amazon CloudWatch

Amazon CloudWatchのアラームで検知できる。

設定

  1. [CloudWatch]で、検索する。

  2. [CloudWatch]コンソールのナビゲーションペイン(横のメニュー)から、
    [アラームの作成]をクリック

  3. [メトリクスと条件の指定]で、[メトリクスの選択]をクリック

  4. メトリクスの選択で、[参照]→[EC2]→[インスタンス別メトリクス]を選択する

  5. [StatusCheckFailed_Instance]となってるものを選択(条件のもの)、[メトリクスの選択]をクリック

  6. 条件を指定する。

    メトリクス

    [統計]を「最大」、期間を「1分」とする。
    →　この設定で、1分間に一度ステータスチェックを行うことができます

    条件

    StatusCheckFailed_Instanceは、
    "0"で正常、"1"で問題ありと判断することができる
    つまり、EC2インスタンスに問題がある時に条件を限定することができるということ。

  7. その他の設定
    「アラームを実行するデータポイント」を2/2にする。
    こうすることで、1分間に2度、ステータスチェックを行うことができる。

例）
しきい値の種類　：　静的
StatusCheckFailed_Instance : 以上
...よりも　: 1
その他の設定
アラームを実行するデータポイント : 2/2

  1. "次へ"をクリック

  2. 通知の設定をする
    [アラーム状態]を選択し、[新しいトピックの作成]をチェックすることで、
    [トピック名]と[通知を受け取るEメールエンドポイント]を入力できるようになる。
    トピック名:任意の名前を入力
    通知を受け取るEメールエンドポイント:通知を受信するメールアドレスを入力する

  3. ここまで出来たら、[トピックの作成]をクリックする

  4. メールの確認
    [トピックの作成]をクリックすると、さっき設定したメールアドレス宛にAWSから確認メールが届くので、
    Confirm subscriptionに設定してあるリンクを開く。
    リンクを開くと手続きが完了して、アラートのメールを受信する設定ができる。

  5. EC2アクションの設定

    アラーム状態トリガー : アラーム状態
    以下のアクションを行なってください　: このインスタンスを再起動

    この設定で、アラートを検知した時にインスタンスを再起動することができる。
    　13. "次へ"をクリック

  6. [名前と説明を追加]を記述。

  7. 入力したら"次へ"

  8. [プレビューと作成]画面に遷移。
    入力内容の確認画面になるなるので、入力内容に間違いがなければ、
    [アラームの作成]をクリック

以上が、方法。

課題で、一回やったから、なんとなく流れは復習になった。
インスタンスを選択して、アラームのタブからちゃんと設定できたか、見ることができる

Discussion