[Ops JAWS#27]EC2の運用と監視 に参加しました①
1. はじめに
みなさん、こんにちは。ひよこインフラエンジニアです。普段はAWSを中心に、既存システムの保守運用や新規システムの設計・構築・テストなどのお仕事をしています。
この度2024/3/11(月)に行われたOpsJAWS#27「EC2の運用と監視」にオンライン参加しましたので、その記録を書こうと思います。今回は第一弾として、OpsJAWSの説明と、EC2 の運用と監視の基本をおさらい 「監視、バックアップ、操作」の受講メモ・感想を記載しました。
OpsJAWSとは
OpsJAWSは、AWSのユーザーグループであるJAWS-UG(AWS User Group – Japan)の中でも、特にAWSの運用系トピックスについて語り合う会[1]です。
参加の経緯
今回は、私が普段業務で多用するEC2がテーマだったこと、ちょうどお客様が監視で悩まれていたことから、参加させていただきました。監視は、やりすぎると通知が飛びすぎてお客様も運用者も疲弊してしまいますし、オオカミ少年になる可能性が高くなってしまうのが悩ましいところです。また、そもそもその閾値を採用した根拠を説明するのが難しかったりするなというのが私の個人的な印象です。(仮決めして運用中に見直そうとはするものの、気が付いたらそのままだったり・・・なんてこともあるかなと思います。)
2. EC2 の運用と監視の基本をおさらい 「監視、バックアップ、操作」堀 貴裕 様
最初は、AWS JapanのSAさんによるおさらいタイムです。
1-1. EC2の操作
EC2の操作方法について、操作のレイヤー(EC2のOS上での操作 or EC2のAPI操作)、定型・非定型(定型操作 or インタラクティブな操作)、操作のタイミング(任意・定期実行)の3観点から分類し、各場面でどのようにEC2を操作する方法があるかについてご説明がありました。
定型操作
- 任意のタイミングの操作(GUI)：マネジメントコンソール
- 任意のタイミングの操作(CUI)：AWS CLI
- 定期実行(任意のスケジューリング)：Amazon EventBridge
- 定期実行(サーバーの状態維持)：SSM StateManager
サーバーの状態維持のため、定期的に状況を確認したり、設定処理を実行したいときに使用。ノードの状態はコンプライアンス画面で確認できる。Inventoryの収集や、SSM Agentの更新などシステム動作に影響のない固有の処理を定期実行するためによく使う。
- 定期実行(メンテナンスウィンドウ)：SSM MaintenanceWindow
業務的にサービス停止が可能な時間帯を定め、その時間帯にSSMのドキュメントを実行したい場合に利用。システム稼働に影響のある動作を行うときに使う。複数のRun Commandの順序実行や、並列実行ができるのが特徴。 - 定期実行(既存のジョブ管理ツール)
■補足
Run Command：サーバーにログインすることなく、ノードへの一括コマンドを発行できる。ただし、SSMエージェントの設定が必要で、対象のインスタンスはSSMのマネージドノードになっている必要がある。シェルスクリプトやAnsibleを流すことも可能。
インタラクティブな操作
- インスタンスにSSHでアクセス：EC2 Instance Connect
エージェント不要だが、インバウンドルールが必要。EC2のみ対象。 - インスタンスにアクセス：SSM Session Manager
エージェントが必要だが、インバウンドルールが不要。(エージェントがSSMエンドポイントに向かってアウトバウンドで通信をするような動きをしているため。)EC2でもオンプレでも対象にできる。
EC2のインタラクティブな操作の比較 (発表資料24スライド目より)
🐣ひよこメモ🐣
業務ではSSM StateManagerやSSM MaintenanceWindow、EC2 Instance Connectを利用したことがなかったので、自分がやりたいことに合わせてどのような操作方法があるのか紹介してくださったのは非常に助かりました。個人的には、各EC2にログインしてOSやミドルウェアのバージョンを調べる手間が省けるので、StateManagerを利用してみたいなと感じました。
1-2. EC2のバックアップ
続いて、EC2のバックアップ方法3種について解説がありました。
- EC2からAMIを作成する
- EBSスナップショットを作成する
- AWS Backupで管理する
特別な要件がない限りはAMI作成やEBSスナップショットがおすすめとのこと。一方、他のAWSサービスと合わせてバックアップを一括管理したい場合は、AWS Backupが推奨ということでした。
🐣ひよこメモ🐣
ひよこの観測範囲では、EC2・EBS・RDS・FSxをまとめてバックアップしたり、DR用途のためクロスリージョンで保管したいという要件が多いので、AWS Backupにお世話になることが多いです。
1-3. EC2の監視
最後に、個人的に最も気になっていた監視方法のベストプラクティスについてです。EC2に対してどのようなメトリクス・ログを収集するか、CloudWatchを使用してどのように実装するかといった点が解説されました。
EC2の監視で必要になるもの (発表資料24スライド目より)
Amazon CloudWatch (発表資料35スライド目より)
EC2のメトリクス、ログ収集の基本的な考え方 (発表資料37スライド目より)
■補足
・EC2のコンポーネント別の推奨メトリクス[2] なるものが公式から発表されている。
・ログについては、低頻度アクセスログクラス[3]が新しく登場し、コスト効率よく収集が可能になった。
🐣ひよこメモ🐣
OSレイヤーや監視の知識がないまま入社以来AWSの案件に携わってきたので、社内研修でレビューを受けるまでメトリクス(数値情報)とログ(文字情報)の違いが分かっていなかったなーということを思い出しながら聞いていました。
また、印象に残ったのは推奨メトリクスが公式から発表されていることです。実務においても、この分野はお客様が強い関心を持たれており、提案する中で「監視するのはいいけれども、通報がたくさんなると見る方も大変」「たくさんメトリクスがあるけれど、結局どれが一番業務影響があって、どれを通報するとリカバリが早くできるのか」といった声をいただくことが多いです。そのため、公式の推奨メトリクスを参照し、そこから業務チームやお客様と一緒にシステムの安定稼働に必要な項目をさらに絞り込んでいく・・・といった順序をとることがあります。
CPUやディスクなどの使用率は必ずといっていいほど取得していますが、「インスタンスが蓄積したCPUクレジット」(CPUCreditBalance:t系のバースト可能インスタンスが蓄積したクレジット)であったり、「アタッチ済みEBSのステータス」(StatusCheckFailed_AttachedEBS)は取得した経験がありませんでした。業務チームやお客様が関心を持たれるメトリクスだけではなく、AWSの基盤観点からも取得しておいた方が良いメトリクスを判断し、こちらから提案するのがAWS担当者として求めらていることの1つかなと思ったりしました。
3. 感想
業務で毎日のように使用しているEC2ですが、操作方法やバックアップ、監視を体系的に整理する機会が今までなかったため、非常に勉強になる内容でした。また、Run Commandも、StateManagerもMaintenanceWindowもまだ実務で使ったことないため、SSMと仲良くなって運用負荷を下げる工夫をしてみたいなと感じました。ログやメトリクスはAWSに閉じず、お客様の関心も高く、奥が深い分野だと思うので、そろそろ『入門監視』に入門する時期が来ている予感がします。
最後に、本記事をお読みくださったあなた、ありがとうございました。
LTの感想についてはまた別記事で掲載させていただきますので、よろしければ。
Discussion