[AWS]EC2運用

システムやサービスは、開発をしてデプロイをすれば終わりではありません。
「AWSサービス」を運用することによりサービスが安定して稼働し続け、また、継続した開発（改修）がすばやく行えるようにしていくことが大切👻

目次

• ライフサイクル
• スケジュールイベント
  AWSによって予定されるイベント（AWS内部の対応による停止、再起動）
• Auto Recovery
  EC2インスタンスにおける障害時の自動的な復旧方法
• 監視（モニタリング）
  EC2インスタンスの状態監視、通知方法
• 自動化ツールと機能
  EC2インスタンスの運用や構築時の自動化

ライフサイクル

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

インスタンスの状態

インスタンスの状態には開始や停止など色々あるけど1個わからなかったことが、『停止』と『終了』の違い！！

インスタンス『停止』と『終了』と『休止』の違い

1. 停止（Stop）

• 操作: インスタンスをシャットダウンし、電源を切る操作です。
• 状態: インスタンスは「停止（stopped）」状態になります。再起動すると、インスタンスは再び起動します。
• データ: Amazon EBS（Elastic Block Store）ボリュームのデータは保持されます。インスタンスストアのデータは失われます。
• 課金: 停止中のインスタンスには使用料金が発生しませんが、EBSボリュームやElastic IPの料金が発生します。
• 再起動: インスタンスIDは保持され、再起動後も同じインスタンスIDで利用可能です。IPアドレスが変わることがあります。

終了（Terminate）

• 操作: インスタンスを完全に削除する操作です。インスタンスが削除されるため、再利用できません。
• 状態: インスタンスは「終了（terminated）」状態になり、もはや存在しません。
• データ: インスタンスストアのデータは失われます。EBSボリュームがインスタンス終了時に削除設定（デフォルトで「削除」）されている場合、そのEBSボリュームのデータも失われます。EBSボリュームの設定により、データの保持が可能。

※EBSも合わせて削除するインスタンス作成時の「ストレージ (ボリューム)」で設定できます。「終了時に削除」の項目で[はい(Yes)]を選択すると、EC2終了時に共に削除される。

• 課金: 終了後、関連するリソースの課金が停止します。
• 再起動: 終了したインスタンスは再起動できません。新たにインスタンスを作成する必要があります。

休止（Hibernate）

• 操作: インスタンスの状態をメモリ（RAM）に保存し、電源を切る操作です。再起動時には、保存された状態から復帰します。
• 状態: インスタンスは「休止（hibernated）」状態になります。再起動すると、以前の作業状態が復元されます。
• データ: インスタンスのRAMの状態がAmazon EBSスナップショットに保存され、次回起動時にその状態が復元されます。Amazon EBSボリュームのデータは保持されます。
• 課金: 休止中でもEBSボリュームの料金は発生します。RAMの状態を保存するための追加ストレージ料金がかかることがあります。
• 再起動: 休止状態から復帰することで、以前の作業状態がそのまま利用可能です。インスタンスIDは保持され、IPアドレスも復帰することが多いです。

警告メッセージをここに

• 停止（Stop）: データは保持されず、基本的にコストが発生しない。
• 休止（Hibernate）: メモリの状態が保存され、再開時に元の状態から復帰するが、コストが高くなる可能性がある。

インスタンスを停止すると、インスタンスは物理サーバー上から削除されて再びインスタンスを起動すると、停止前とは別の物理サーバー上で起動する！

だーから毎回IPv4アドレスが変わるんかぁ〜〜〜🫶ほぇ〜〜〜〜

[注意]　EBSとEIPは、インスタンスが起動していなくても課金される。

Elastic IP（EIP） とは

AWSが提供する「動的に割り当て可能な固定IPアドレス」のことです。インスタンスが停止したり再起動したりしても、同じIPアドレスを使い続けることができるので、外部からのアクセスに対して安定した接続を維持するために使われます。

終了しても課金されることがあるからちゃんと確認する、解放・削除すること！！！！！

スケジュールイベント

EC2インスタンスは、AWSによって「再起動」「停止／開始」「リタイア」などのイベントが予定されることがある。
イベントが発生するのは、EC2インスタンスのメンテナンスが行われるときや、回復不可能な障害が検出されたときなど！
イベントが予定されると、AWSアカウントに関連付けられたEメールアドレス宛に、お知らせメールが送信されます

Auto Recovery

AWSでは、実行中のEC2インスタンスに対して、定期的にステータスチェック（監視）が入る！
「Auto Recovery」は、システムステータスが失敗（Status Checked Failed）となった場合に、自動的にEC2インスタンスを復旧させる機能です。

ステータスチェック失敗の種類／主な原因

• システムステータスチェック（StatusCheckFailed_System）：EC2インスタンスをホストしているハードウェア側の障害
• インスタンスステータスチェック（StatusCheckFailed_Instance）：EC2インスタンス内部で発生している障害。ユーザーが関与して修復する必要がある

システムステータスの確認方法

1. インスタンスを選択して［ステータスチェック］タブ押して確認

ステータスチェックの失敗を自動的に検出し通知させる

https://blog.serverworks.co.jp/30min-handson-cloudwatch-alarm

一応手順

1. マネジメントコンソールのサービス検索で「CloudWatch」を検索
2. コンソールのナビゲーションペインから「アラーム」を選択し、「アラームの作成」をクリック
3. メトリクスと条件の指定で「メトリクスの選択」をクリック
4. メトリクスの選択で [参照] ＞ [EC2] ＞ [インスタンス別メトリクス] を選択
5. メトリクス名が「StatusCheckFailed_Instance」となっているものを選択し、「メトリクスの選択」をクリック
6. 条件を指定する
   [メトリクス]
   統計を「最大」、期間を「1分」とします。この設定で1分間に1度ステータスチェックを行うことが出来ます。
   [条件]
   StatusCheckFailed_Instanceは「0」で正常、「1」で問題ありと判断することができます。
   つまり、EC2インスタンスに問題がある時に条件を限定することが出来るということです。
   [その他の設定]
   「アラームを実行するデータポイント」を2/2にします。
   このようにすることで、1分間に2度、ステータスチェックを行うことが出来ます。 次へを押す
7. 通知の設定をする
8. 「トピックの作成」をクリック
9. メールの確認
   トピックの作成」をクリックすると、先程設定したメールアドレス宛にAWSをから確認メールが届くので
   「Confirm subscription」に設定してあるリンクを開きましょう。リンクを開くと手続きが完了し、アラートのメールを受信する設定が出来ました。
10. EC2アクションの設定
    
11. 名前と説明を追加 作成したアラームに、名前と説明を追加していきます。 今回は、アラーム名を"status-failed-alert"とします。
12. 次へを押して「プレビューと作成」画面にて入力内容に間違いがなければ「アラームの作成」をクリック
13. END

監視（モニタリング）

システムやサービスを安定して運用し続けるには サービスを監視する必要があります。
使うのはさっきの「CloudWatch」など。

3つの機能

• モニタリング：死活監視／性能監視／キャパシティ監視
• 結果を可視化：取得メトリクス（監視項目）の値をグラフで表示する
• アラート通知：各メトリクスをベースとしたアラームを設定する

監視できるサービス

• Amazon EC2
• Amazon EBS
• Amazon RDS
• Elastic Load Balancingなど

「メトリクス」とは

「メトリクス」とは、監視項目のこと。

標準メトリクス：CPU使用率、Disk利用量、ネットワーク利用量などを監視する
カスタムメトリクス：標準メトリクスでは収集できない項目を独自に定義できる
メトリクスデータの保管は、2週間までです。2週間以上保存する場合は、別の場所に保管しておく必要があります。

CloudWatchでは、以下のような項目が「監視対象」として取得され、グラフ化され、通知対象になります。

「監視対象」

• CPUUtilization：CPUの利用比率
• DiskReadOps：ディスクから読み取られた（Readされた）回数
• DiskWriteOps：ディスクに書き込まれた（Writeされた）回数
• DiscReadBytes：ディスクから読み取られたバイト数
• DiscWriteBytes：ディスクに書き込まれたバイト数
• NetworkIn：ネットワークから受信されたバイト数
• NetworkOut：ネットワークから送信されたバイト数

CloudWatchの料金

• 初期費用なし、従量課金制
• 標準の監視：無料
• EC2インスタンスの標準監視：5分間隔
• サービスによって標準監視間隔は異なる（例：EBS、ELB、RDSは1分間隔が無料）
• より厳密な監視：有料化が必要（たとえば監視項目を増やしたり監視間隔を短くするなど）

「踏み台サーバー」と「バッチサーバー」

パブリックEC2＝（踏み台サーバー）

• 配置: パブリックサブネット
• 目的: インターネットからの管理アクセスを提供する
• 説明: このサーバーは、外部から内部ネットワークへのアクセスを安全に提供するためのものです。ユーザーはこのサーバーを介してプライベートサブネット内の他のサーバーにアクセスします。通常、SSHやRDPなどの管理ツールを使ってアクセスします。

プライベートEC2＝（バッチサーバー）

• 配置: プライベートサブネット
• 目的: 内部処理やデータ処理を実行する
• 説明: このサーバーは、データの処理やバックグラウンドジョブの実行などを担当します。外部から直接アクセスする必要はなく、プライベートサブネット内で安全に運用されます。踏み台サーバーを通じて、管理者が必要に応じてこのサーバーにアクセスします。

---

awsの上限設定（申請や緩和）

AWSアカウントを開設した当初は、それぞれのサービスに対し、起動可能なサービス数や容量などの上限値がデフォルトで設定されています。
この制限（クォータ）が設定されているのは、誤って大量のリソースを起動してしまったり、不適切なアーキテクチャ設計によって不要なリソースを大量に利用してしまうなどのトラブルを防ぐためです。
たとえばEC2の場合、「起動は、リージョンごとに20インスタンスまで」といった制限が設けられています。

コスト最適化

AWSサービスは、多くが従量課金のため、必要なときに必要な分だけ利用できます。
このため、コストを抑えた運用が可能。

EC2インスタンスやEBSボリュームは、1秒単位で課金されます。

AWSにおけるコスト圧縮の工夫

AWSでは、以下のような割引方法や、AWS自身におけるコスト圧縮を工夫しています。

• 利用が増えると、単価が安くなる（ボリューム割引）
• データ転送量
• S3ストレージ料金　など
• 利用オプションによる割引：リザーブドインスタンス（後述）
• EC2
• RDS
• ElastiCache
• Redshift
• DynamoDB　など
• 価格改定：AWSは頻繁に価格改定を実行

EC2の購入オプション

オンデマンドインスタンス（デフォルト値）

• 初期費用：なし
• 従量課金：使った分だけ課金される
• 想定利用シーン
• Web／APPサーバー（利用者が時間帯によって増減する）
• 一時的に利用するサーバー
• キャンペーンサイトをホストする
• 開発サーバーとして利用する　など

リザーブドインスタンス（オプション）

• 長期利用（1年～3年）を予約すると、最大75％の割引が適用される
• スケジュールされたリザーブドインスタンス
• 指定した時間帯のみのキャパシティ予約（1年間、月次、週次、日次）によって、5％～10％の割引が適用される
• 想定利用シーン
• 常時稼働しているサーバー
• 24時間365日稼働するサーバー
• DB、キャッシュサーバー　など

スポットインスタンス（オプション）

• AWS保有の未使用インスタンス（空いているリソース）を、時価で利用できる（入札制）。最大90％の割引が適用される
• 想定利用シーン
• 処理時間やタイミングがクリティカルではないビックデータ解析
• 大量の並列実行が可能なバッチサーバー（リソースを利用できるタイミングで、大量のリソースを確保して実行する など）
• テスト自動化サーバー
  上記が主な購入オプションです。詳細は、公式サイトの以下のページで確認できます。
  https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-purchasing-options.html

「AWS Budgets」とは

予算のしきい値を超えたとき（または、超えると予測されたとき）に、アラートを発信できる機能。

「Trusted Advisor」とは

コスト最適化やパフォーマンスなど、5種類の観点でAWSの利用状況をチェックし、推奨事項を知らせてくれるサービス。