AWSクラウドプラクティショナー資格取得のための学習用備忘録(管理サービス)

CloudWatch

Amazon CloudWatchは、たとえばこれまでに出てきたEC2インスタンス、RDSインスタンス、DynamoDBテーブルなどの
各インスタンスの現在の状態、情報をモニタリングするサービス。
CloudWatchは、標準メトリクスという、AWSが管理している範囲の情報を、顧客側で追加の設定なしで収集している。

CloudWatchで何も設定しなくても、EC2インスタンスを起動しただけで、
5分おきにCPU使用率のようなメトリクスデータが収集される。
メトリクスデータはダッシュボードで可視化できる。また、アラームを設定することもできる。

★AWSのサービスを使い始めると、サービスにより起動されたリソースのメトリクスがCloudWatchに自動的に収集され始める

CloudWatchの特徴

CloudWatchには主に次の機能がある

・標準(組み込み)メトリクスの収集、可視化

・カスタムメトリクスの収集、可視化

・ログの収集

・アラーム

標準(組み込み)メトリクスの収集、可視化

CloudWatchは、AWSがコントロールできる範囲(たとえばEC2ではハイパーバイザーまで)の、
AWSが提供している範囲で知り得る情報を標準メトリクスとして収集している。
顧客のコントロール範囲のOS以上の情報については、AWSが勝手にモニタリングすることはない。
EC2では、CPU使用率や、ハードウェアやネットワークのステータス情報が標準メトリクスとして収集される。

標準メトリクスとして収集された値は、マネジメントコンソールのメトリクス画面やダッシュボードで可視化できる。
EC2の標準メトリクスでは、CPUがどれくらい使われているか、過不足はないかなどを確認できる。

EBSの標準メトリクスでは、ディスクI/Oなどの情報がある。
EBSのボリュームタイプを変更するべきか、などの判断に使用できる。

マネージドサービスのRDSでは、EC2では標準メトリクスに含まれなかった、
メモリの情報やディスク使用量の情報が含まれている。
これはRDSではOSもAWSが提供している範囲の情報のため収集されている。

★標準メトリクスは、使用するサービスによって取得される情報が異なる

カスタムメトリクスの収集、可視化

たとえばEC2では、メモリやアプリケーションのステータスなどOS以上の範囲、
および顧客がコントロールしている範囲については標準メトリクスとしては収集されない。
これらの情報は、CloudWatchのPutMetricData APIを使用してCloudWatchへカスタムメトリクスとして書き込むことができる。

CloudWatchへメトリクスを書き込むプログラムはCloudWatchエージェントとして提供されているので、
EC2へインストールするだけで使用できる。

CloudWatchエージェントで対応していない任意の数値データもプログラムを実装すれば、
CloudWatchメトリクスへ書き込むことができる。
このように、標準メトリクス以外の、顧客が選択して収集できるメトリクスをカスタムメトリクスという。

カスタムメトリクスとして収集された値も標準メトリクスと同様に、
マネジメントコンソールのメトリクス画面やダッシュボードで可視化できる。

★EC2のカスタムメトリクスはCloudWatchエージェントで取得できる

ログの収集

CloudWatchにはメトリクスだけではなく、ログを収集する機能もある。(CloudWatch Logs)

CloudWatch Logsでは、EC2のアプリケーションログや、Lambdaのログ、VPC Flow Logsなどを収集することができる。
EC2では、カスタムメトリクス同様に、CloudWatchエージェントをインストールして少しの設定をすることで
CloudWatch Logsへ書き出せる。
ログの情報をEC2の外部に保管することで、EC2をよりステートレス(情報や状態を持たない構成)にできる。

例えば障害が発生してログ調査が必要になったとする。
EC2のローカルにだけログがある場合、そのログファイルを退避するまでEC2を終了することができない。
Auto Scalingの場合、異常とみなされたEC2インスタンスは自動で終了できるが、
このような場合は自動で終了させるわけにはいかない。
CloudWatch Logsへ書き出しておけば、異常なインスタンスや不要になったインスタンスを
その時点でAuto Scalingによって終了させることができ、後でログを分析して調査できる。

ダッシュボードからCloudWatch Logsを見てみると、
設定したOSやアプリケーションのログが収集されていることがわかる。
他にはLambdaの実行ログや、VPC Flow Logsなどを書き出すことができる。
CloudWatch Logsは出現文字でフィルタリングしてメトリクスとして扱うこともできる。

Webサーバーがデータベースに接続できないエラーの発生などをフィルタリングすることも可能。

データベースの接続エラーのため、RDSのメトリクスともあわせて見てみる。
接続数や書き込みとの関係性も特に強くはなさそうだということがわかる。
(例でのエラーは結果的にはWebサーバー側に問題があり、アプリケーションの修正で解決)

★EC2のCloudWatch LogsはCloudWatchエージェントで取得できる

★CloudWatch LogsによりEC2をよりステートレスにできる

★CloudWatch Logsは文字列のフィルタリング結果をメトリクスとして扱える

アラーム

CloudWatchでは、各サービスから収集したメトリクス値に対してアラームを設定することができる。

たとえば、次のようなサービス状態(=メトリクス値)に対してアラームを設定できる。

・EC2のCPU使用率が10分間、80%を上回っているとき

・ログに「Out of Memory」という文字列が5分間で2回出現したとき

・RDSのディスク空き容量が残り10GB未満になって5分間そのままのとき

アラームに対しては、次の3つのアクションを実行できる。

・EC2の回復：EC2のホストに障害が発生した時に自動で回復する

・Auto Scalingの実行：Auto Scalingポリシーでは、CloudWatchアラームに基づいて、
スケールイン/スケールアウトのアクションを実行する。

・SNSへの通知：AWSのサービスの1つにSNSがある。
「Amazon SImple Notification Service」の略。SNSへ通知することにより、
そのメッセージをEメールで送信したり、Lambdaへ渡すなどができる。
Eメールで送信することで、監視の仕組みを簡単に構築できる。
また、Lambdaにメッセージを渡して実行することで、アラームの次の処理を自動化することができる。
(SNSから連携できるアクションは他にもいくつかある)

★アラームを設定することにより、モニタリング結果に基づく運用を自動化できる

保存期間について

メトリクス：メトリクスの保存期間は、次のようになっている。
この期間を超えたメトリクスは消去される。
これ以上の期間にわたってデータ分析などに使用する場合は、S3などに保存する。

・60秒未満のデータポイント(高分解能カスタムメトリクス)は3時間

・1分(詳細モニタリング)のデータポイントは15日間

・5分(標準)のデータポイントは63日間

・1時間のデータポイントは455日間

CloudWatch Logs：CloudWatch Logsには任意の保存期間を設定できる。消去しないことも可能。

Trusted Advisor

Trusted Advisorは、顧客のAWSアカウント環境の状態を自動的にチェックして回り、
ベストプラクティスに対してどうであったかを示すアドバイスをレポートする。

チェックする視点は以下の5つ。

・コスト最適化

・パフォーマンス

・セキュリティ

・フォールトトレランス(耐障害性)

・サービス制限

★Trusted AdvisorはAWS環境を自動でチェックして、ベストプラクティスにそったアドバイスをサポートする

コスト最適化

ここを見直せばコストを最適化できる、という視点でチェックしたアドバイスがレポートされる。
コスト最適化では、具体的にどれくらい月額コストが下がるかという金額も計算されて提示される。

使用率の低いEC2インスタンス

使用率が低いということは、たとえば次のような状態が考えられる。

・使っていないのに起動中のインスタンスがある

・検証やテストで使って終了を忘れているインスタンスがある

・過剰に高いスペックのインスタンスがある

これらはすべて無駄なコストの発生源。使っていないものは終了する、
過剰なインスタンスは適切なサイズに変更するなどの対策で、コストを最適化できる。
使用率の低いものとしては、他にEBSやRedshiftもチェックされる。
アイドル状態(使われていない)か否かは、ELB、RDS、Elastic IPアドレスに対してもチェックされる。

リザーブドインスタンスの最適化

EC2の利用状況をチェックして、リザーブドインスタンスを購入した方がコスト最適化に繋がるかどうかをレポートする。
このレポートに上がってきた内容で1年または3年の継続が見込めるときは、
リザーブドインスタンスを購入することでコストが最適化される。
購入済みのリザーブドインスタンスについても、有効期限が切れる30日前からアラート対象になる。
リザーブドインスタンスは延長できないため、継続する場合の新規購入忘れも防げる。

★コスト最適化では、無駄なコストが発生していないかがチェックされる

パフォーマンス

システムのパフォーマンスを低下させる原因はいくつかあり、
その原因となる設定や選択がされていないかがチェックされる。

・使用率の高いEC2インスタンス：コスト最適化とは逆で、使用率の高いインスタンスをチェックする。
EC2に実装している処理に対してリソースが不足している可能性がある。
システムのパフォーマンスが良い状態とは言えない。
このような状態に陥っている環境ではエンドユーザーに「システムが遅くて使えない」という印象を持たれるかもしれない。
対象の処理が最も早く完了するインスタンスタイプに変更することが推奨される。

・セキュリティグループルールの増大：セキュリティグループのルールが多いと
それだけネットワークトラフィックが制御されることになる。
50以上のルールがあるとパフォーマンスの低下に繋がる可能性がある。
このアラートが発生した場合は、ルールをまとめることができないか、
対象のインスタンスを分けることができないか、を検討する。

・コンテンツ配信の最適化：CloudFrontにキャッシュを持つことで、S3から直接配信するよりもパフォーマンスが向上する。
また、キャッシュがどれだけ使われているかを示すヒット率についてもチェックされる。

★パフォーマンスでは、最適なサービス、サイズが選択されているかがチェックされる

セキュリティ

セキュリティリスクのある環境になっていないかをチェックする。

・S3バケットのアクセス許可：誰でもアクセスできるS3バケットがないかチェックする。
もちろん意図してそのように設定しているケースはある。
1つの方法としては、バケットは公開設定をせずに、オブジェクト単位で公開設定をすることもできる。
そうすることでそのバケットに誤って機密情報をアップロードしてしまっても、
バケット自体は公開設定になっていないので公開されることはない。

・セキュリティグループの開かれたポート：リスクの高い特定のポートが、
送信元無制限でアクセス許可されているセキュリティグループをピックアップする。
悪意のあるアクセスによって攻撃され、データが漏洩する可能性がある。

・パブリックなスナップショット：EBSやRDSのスナップショットは他の特定のアカウントに共有することもでき、
アカウントを特定せずに公開共有することもできる。
意図せず誤って公開設定してしまうことは、他のAWSアカウントすべてからも使用できる状態になってしまうということ。
必要なアカウント間のみで共有するようにする。

・ルートアカウントのMFA、IAMの使用：IAMユーザーがいないアカウントということは、
ルートアカウントを使用しているということ。
ルートアカウントという、権限を制御できないアカウントを運用で使うことは非常に危険。
そのルートアカウントにMFA(多要素認証)を設定していない、ということも非常に危険。
運用するための最低権限を設定したIAMユーザーを作成して、ルートアカウントにもIAMユーザーにもMFAを設定する。

Trusted Advisorでは他に、IAMパスワードポリシーが有効化されているかどうかなどもチェックされる。

★セキュリティでは、環境にリスクのある設定がないかがチェックされる

フォールトトレランス(耐障害性)

耐障害性が低い状態がないかをチェックして、耐障害性を高めるためのアドバイスを提供する。

・EBSのスナップショット：EBSのスナップショットが作成されていない、
または最後に作成されてから時間が経過したことがチェックされる。
EBSボリュームはAZ内で複製されているが、AZに障害が起こる可能性はある。
EBSのスナップショットを作成するとスナップショットはS3に保持されるので、
複数のAZ上で高い耐久性でデータが保持されることになる。

・EC2、ELBの最適化：複数のAZでバランス良く配置されているかがチェックされる。
ELBではクロスゾーン負荷分散やConnection Draining(セッション完了を待ってから切り離す機能)が無効になっている
ロードバランサーがないかもチェックされる。

・RDSのマルチAZ：マルチAZになっていないデータベースインスタンスがチェックされる。

★フォールトトレランスでは、耐障害性が低い状態がないかがチェックされる

サービス制限

AWSアカウントを作った最初の時点では、いくつかのサービス制限がある。
これはソフトリミットと呼ばれるもので、この制限がある理由は主に次の2つ。
緩和申請によって制限を超えることができるサービスもある。

・誤った操作による意図しない請求を回避する

・不正アクセスによる意図しない請求を回避する

サービス制限を上回りそうな予定がある場合は、事前にAWSへ申請を行っておく。

★意図しない操作や不正アクセスによって顧客に不利益が生じないよう、サービス制限がある

★サービス制限では、制限に基づいたサービスがアラート報告される

その他の管理ツール

その他の管理ツールとしては次の3つがある。

・CloudTrail

・CloudFomation

・Elastic Beanstalk

CloudTrail

AWS CloudTrailは、AWSアカウント内のすべてのAPI呼び出しを記録する。
API呼び出しを記録するということは、AWSアカウント内におけるすべての操作を記録するということ。

例えばEC2インスタンスを作成するとする。
マネジメントコンソールからは、EC2インスタンスの作成メニューで作成する。

AWS CLIでコマンドを使ってEC2インスタンスを作成することもできる。

AWS SDK for Python(boto3)でもEC2インスタンスを作成できる。

どの方法でも、EC2インスタンスを作成するAPIが呼び出される。

CloudTrailはこのAPI呼び出しを記録するため、すべての操作が記録される。監査や調査に使用できる。

CloudTrailに似たサービスに、AWS Configがある。AWS ConfigはAWSリソースの変更を自動記録し、
運用効率と整合性を高める。誰がいつ何を変更したかが自動で記録される。

CloudFomation

AWS CloudFomationは、AWSの各リソースを含めた環境を自動作成/更新/管理する。

JSON形式またはYAML形式で記述されたテンプレートから、Stackというリソースの集合体を作成する。
CloudFomationを使用することで、同一のAWS環境を何度でも自動で構築することができる。

このようにCloudFomationでは、自動的なプロビジョニング(構築して準備)をコードを用いて行える。
コードはAWS CodeCommitなどのリポジトリでバージョン管理できる。
このような機能のことをIaC(Infrastructure as Code)と呼ぶ。

Elastic Beanstalk

Amazon Elastic Beanstalkは、Webアプリケーションの環境を簡単にAWSに構築する。
CloudFomationと似ているが、テンプレートを作成する必要はない。
設定パラメータを提供することで、ApacheやNginx、IIS、各言語の実行環境もあわせて簡単に構築できる。
ただし、AWSの全てのサービスを網羅しているわけではなく、
Webアプリケーションやタスク実行環境を構築することに向いている。
アプリケーションの継続デプロイのための高性能な機能を有している。

まとめ

CloudWatch

・AWSのサービスを使い始めると、サービスにより起動されたリソースのメトリクスがCloudWatchに自動的に収集され始める

・標準メトリクスは、使用するサービスによって取得する情報が異なる

・EC2のカスタムメトリクスはCloudWatchエージェントで取得できる

・EC2のCloudWatch LogsはCloudWatchエージェントで取得できる

・CloudWatch LogsによりEC2をよりステートレスにできる

・CloudWatch Logsは文字列のフィルタリング結果をメトリクスとして扱える

・アラームを設定することにより、モニタリング結果に基づく運用を自動化できる

Trusted Advisor

・Trusted AdvisorはAWS環境を自動でチェックして、ベストプラクティスに沿ったアドバイスをサポートする

・コスト最適化では、無駄なコストが発生していないかチェックされる

・パフォーマンスでは、最適なサービス、サイズが選択されているかがチェックされる

・セキュリティでは、環境にリスクのある設定がないかがチェックされる

・フォールトトレランスでは、耐障害性が低い状態がないかがチェックされる

・意図しない操作や不正アクセスによって顧客に不利益が生じないよう、サービス制限がある

・サービス制限では、制限に近づいたサービスがアラート報告される