Zenn
📘

[Ops JAWS#27]EC2の運用と監視 に参加しました②

2024/03/20に公開
AWS
EC2
監視
運用
JAWS
tech

1. はじめに

みなさん、こんにちは。ひよこインフラエンジニアです。普段はAWSを中心に、既存システムの保守運用や新規システムの設計・構築・テストなどのお仕事をしています。
この度2024/3/11(月)に行われたOpsJAWS#27「EC2の運用と監視」にオンライン参加しましたので、その記録を書こうと思います。今回は第二弾として、LTの受講メモ・感想を記載しました。なおOpsJAWSの説明と、EC2 の運用と監視の基本をおさらい 「監視、バックアップ、操作」の受講メモ・感想については、第一弾に記載しています。

2. petなEC2をまとめて監視してみた

1つ目のLT[1]は、まだ監視が全く存在せず、ワークロードが別々で管理されているEC2インスタンスたちに対して、SaaSを使わずAWS内でまとめて監視させたい、というテーマのものでした。大まかな流れは下記の通りです。

  • インスタンスに適切にタグとロールを付ける
  • Resource Groupを利用してインスタンスをまとめる
  • Run CommandでCloudWatch Agentの管理をする
  • State Managerを利用して自動的に設定変更を配布する
  • Chatbotを使ってslackに通知をする

上記の実装について、構成図込みでわかりやすく説明されていました。

https://speakerdeck.com/athagi/petnaec2womatometejian-shi-sitemita

🐣ひよこメモ🐣

本LTは、これから複数のEC2をまとめてSSMで管理したい方にとって非常にわかりやすい内容だったと感じました。かくいう私も実務では使いこなせていないので、通知の手前までは導入してみたいなと感じました。また、下記の内容は初めて知ったことだったので、勉強になりました。

  • AWS BackupではResource Groupは使用できず、タグのみ利用できる
  • CloudWatch Agentの設定ファイルであるconfig.jsonを作り込む場合、Parameter Storeの文字数制限に注意すべき
  • Run Commandではインスタンス・ステップごとに実行結果のログを確認できるが、こちらも行数制限があるため、S3やCloudWatch Logsに出力した方が良い

3. SSMエージェントはIAMロールの夢を見るか

続いてのLT[2]は、某フィリップ・K・ディック氏を彷彿とさせるようなタイトルのこちらです。

https://dev.classmethod.jp/articles/opsjaws27-ssmegent-assumerole/

前回の記事から話題に挙げているSSMですが、EC2を管理する(マネージドノード)にするためには、対象のインスタンスにSSMエージェントというエージェントソフトをインストールする必要があります。こちらのSSMエージェントを通してEC2に対して何らかの動作をする際、裏側ではIAMロールがどのようになっているのか？ というテーマでした。なお、SSMエージェントに必要な権限を持たせる方法は2通りあるそうです。

  • EC2 インスタンスにインスタンスプロファイルをアタッチする
  • リージョンで Systems Manager の Default Host Management Configuration（DHMC）を有効にする

結論としては、SSMエージェントはIAMロールを引き受けない(IAMロールの夢を見ない)とのことでした。正確には、上記の2通りの方法のいずれかで付与したロールがsts:AssumeRoleを引き受け、一時的なクレデンシャルをEC2のコントロールプレーンに格納します。続いて、データプレーンに存在するSSMエージェントがインスタンスメタデータサービス(IMDS)に対してアクセスすることで、その情報を取得するとのことです。

🐣ひよこメモ🐣

SSMを使ってEC2にログインする用途が実務では多かったので、冒頭のSSMエージェントからEC2や他のAWSサービス(S3やCloudWatch等)に向かってのアウトバウンド通信が存在するという説明でハッとさせられました。
また個人的には、IMDSの件についても触れらており勉強になりました。実務では、SSMエージェントをインストールしたけれども、なぜか唐突にマネージドノードの状態が利用不可になったという事態に何度か直面していました。その原因はインスタンスメタデータサービス(IMDS)のエンドポイント「169.254.169.254」にアクセスできなくなったからだ、という事例が多かったです。このIMDSは得体が知れなかったのですが、本LTを聴いて「そりゃー接続できなくなるとマネージドノードから外れてしまうよね」と納得することができました。
IAMロールとsts:AssumeRoleの世界はもっと奥が深そうですね。

4. EC2のバックアップ運用について思いを馳せる

3つ目のLT[3]は、EC2のバックアップ戦略についてです。AWS Backup、Amazon Data Lifecycle Manager(DLM)、opswitch(クラスメソッドさんが提供するAWS自動化サービス)の3者について、様々な観点から比較されていました。

https://speakerdeck.com/inomasosan/thinking-about-ec2-backup-operation

🐣ひよこメモ🐣

冒頭のお客様のバックアップ要件でよくある声は、私もご要望いただいたことがある事項が多く、とっても共感できました。また、EC2インスタンスを停止せずに取得したAMI(EBS)のイメージは「掃除のおばちゃんが稼働中サーバーの電源ケーブルを引っこ抜いた状態」に近い = メモリ上にあるデータが保存されていない という説明があり、非常にわかりやすかったです。後半のサービス比較も参考になりました。個人的には、下記の点が今後のサービス選定で肝になってきそうだと感じました。

項目 AWS Backup DLM
管理方法 保持期間のみ 保持期間、世代数ともに可能
バックアップ対象の指定方法 オプトインしたすべてのリソース
特定のリソースID・タグ指定		 特定のタグ
EC2の再起動 他サービスとの併用が必要 可能
リージョン間コピー 可能 可能
バックアップのタグづけ AMI及びスナップショットにNameタグをコピー可能 AMIのみタグをコピー可能
バックアップ
失敗通知		 SNSのサブスクリプションフィルターを設定することで、失敗時にのみ通知可能 通知機能はなく、DLMのメトリクスをCloudWatchアラームで監視すれば実現可能

これは蛇足ですが、AWS Backupにおいて世代管理したい場合や、バックアップ成功時も通知したい場合は、どのように実装するのかなと関心を持ちました。ひよこの観測範囲では、お客様から要件として出てきそうな予感がします・・・。

5. AIOpsを活用してEC2を監視してみた

次[4]は印象がガラッと変わり、流行のAI関連ネタでした。

https://speakerdeck.com/hiashisan/opsjaws27-aiops-aws

AIOpsは2016年にGartnerによって提唱された考え方で、本LTでは「AIサービス(機械学習、ビッグデータ)を応用してIT基盤運用における問題を分析・改善、自動化する手法」と定義されていました。具体的には、パフォーマンス分析、異常検出、イベントの相関と分析、ITサービスの管理と自動化などの方法が挙げられます。今回は異常検出(Anomaly Detection)にフィーチャーし、AWSの下記サービスについて紹介がありました。

  • CloudWatch Anomaly Detection：最大2週間のCloudWatchメトリクスの数値に基づいた期待値のベースラインを継続的に調整する機能
  • CloudWatch Logs Anomaly Detection：CloudWatch Logs ロググループに取り込まれたログを継続スキャンし、ログデータの異常を検出する機能
  • DevOps Guru：通常から逸脱した動作を機械学習(ML)を利用して検出することが可能なサービス

🐣ひよこメモ🐣

CloudWatch Anomaly Detection及びCloudWatch Logs Anomaly Detectionについては、実機でCloudWatchを触るたびに「何か新しいのあるなー」と思っていましたが、DevOps Guruについては全く存在を知りませんでした。アカウント内の全リソース or CloudFormationスタック単位 で対象リソースを選べるとのこと。全リソースを対象にすると、いったい何円かかるのか・・・・、怖いですね。
プロジェクトの当初は、移行前の監視閾値をそのまま踏襲してAWS上リソースの監視閾値を決めたり、ワークロードが異なるのにもかかわらず他システムの値をそのまま踏襲してしまったり、という事例も存在します。そして、運用しながら適宜見直します、と設計書上明記しているものの、運用時に見直しが入らない、という事態も起こりえます。AWS上のリソース状態に基づいてベースラインを決めてくれるのであれば、こういう事態も少なくなってくるのかなと感じました。
一方で、お客様に閾値の根拠を説明する際に「AWSが機械学習でいい塩梅にやってくれます(※超意訳)」では、なかなか納得していただけないのではとも思いました。お客様にとっては(SEにとってもですが)AWSのAIはブラックボックスなので、実績のある移行前の事例や他システム事例の閾値の方が安心できる、という声も上がってきそうです。

6.「EC2 のセキュリティの運用と監視」について考えてみた件

最後のLT[5]は、EC2のセキュリティ対策を実施することで発生する、セキュリティ運用についてです。想定される脅威、AWSでの予防策・検知策の紹介の後、必要となるセキュリティ運用について解説がありました。

https://speakerdeck.com/hssh2_bin/opsjaws-ec2-nosekiyuriteinoyun-yong-tojian-shi-nituitekao-etemitajian

ポイント

  • セキュリティ対策は実施して終わりではなく、正しく運用しないと効果が薄れリスクが高まる
  • EC2でシステムを組むと管理対象が多くなり、セキュリティ運用負荷が高くなる
  • 多種多様なログと検知するためのロジックが必要になる
  • CSIRTを構築しSREとの間で役割分担をしておくべき

🐣ひよこメモ🐣

脅威と予防策・検知策の結びつきが分かりやすく図解されており、どのAWSサービスを何のために使うのか判断する際の基準になると感じました。また、プロジェクトの初期段階からセキュリティ面の運用を想定して運用設計を行っておくことや、具体的な手順の明確化が必要なこと、CSIRTやSOCとの役割分担が肝心なことを改めて知ることができました。
予算に厳しいお客様の場合、セキュリティやログ系のサービスは最小限の利用にとどまることもありますが、想定される脅威を洗い出してアセスメントし、各脅威への対処(受容・回避・逓減・移転)方針を決めた上で、必要な予防・検知策を講じることが必要だと思いました。

7. 最後に

普段業務でよくEC2を使用するからというシンプルな理由で本勉強会に参加しましたが、EC2の操作方法・バックアップ方針・監視だけではなく、運用を効率化するための仕組みやセキュリティ面の対策まで、幅広く学びがありました。改めまして、この場を借りて主催者の皆様、登壇者の皆様に感謝を申し上げます。
本勉強会で得た知見をもとに、検証環境で乱立しているEC2たちの整理整頓から始めつつ、実務においても運用面・セキュリティ面を意識した設計を行っていきたいと思います。

最後までお読みいただきありがとうございました。
また、何かの記事やどこかの勉強会でお会いしましょう。
ひよこインフラエンジニア

脚注

  1. https://speakerdeck.com/athagi/petnaec2womatometejian-shi-sitemita ↩︎

  2. https://dev.classmethod.jp/articles/opsjaws27-ssmegent-assumerole/ ↩︎

  3. https://speakerdeck.com/inomasosan/thinking-about-ec2-backup-operation ↩︎

  4. https://speakerdeck.com/hiashisan/opsjaws27-aiops-aws ↩︎

  5. https://speakerdeck.com/hssh2_bin/opsjaws-ec2-nosekiyuriteinoyun-yong-tojian-shi-nituitekao-etemitajian ↩︎

Discussion