残り少しなんで頑張ろうと思う。このあと模試を受ける予定…
CloudWatch
監視サービス。
メトリクスの収集、ログ収集、モニタリング、アラームの設定ができる。
CloudWatch、CloudWatch Logs、CloudWatch Eventsの3サービスで構成されている。
CloudWatchはシステム監視のサービス。
CloudWatch Logsはログ管理サービス。
CloudWatch Eventsはリソースの変更をトリガーとしてアクションを行うサービス。
メトリクスを収集する。メトリクスとは監視対象のパフォーマンスのこと。CPUとか。
実際のデータをデータポイントという。40%とか。
AWSサービスが収集するメトリクスを標準メトリクスといい、AWSサービスを利用すると自動的に収集される。
ユーザーが独自に収集するメトリクスをカスタムメトリクスといい、ユーザーがAWS APIやAWS CLIを使用して任意の値を収集する。
標準サービスか、自分で監視したい項目追加するかみたいな違い
EC2インスタンスの監視
標準で監視可能なメトリクスと、エージェントを入れることによって監視可能になるメトリクスがある。
カスタムメトリクスならエージェント入れないと使えない。
ちなみにポーリング感覚は5分がデフォ。１分間隔の詳細モニタリングは有償。設定せねばアカン。
しかしEBSのプロビジョンドIOPSは1分間隔。なぜ。
CPUなどの、基盤側のデータはエージェント不要だが、メモリなどのOS内部の情報はエージェント必要。
メトリクスの解像度と保存期間
メトリクスを収集する間隔のことを解像度という。標準メトリクスなら最小１分間隔、カスタムメトリクスなら最小1秒間隔でいける。
保存期間は、5分なら約二ヶ月、1分なら約半月保存しててくれる。
料金
5分間隔なら無料。1分間隔は10個まで無料。
カスタムメトリクスや5分未満の間隔のメトリクスは有償。
CloudWatchアラーム
通知機能。閾値以下であるok、閾値を超えたAlarm、データ不足とか判断できないInsufficient_dataがあり、これらをメール送信やEC2インスタンスの自動停止や再起動やAuto scalingができる。
SNSと連携できるので、SNSが出来ることはできる。Lambda起動とか。
請求アラーム
利用料金が予め設定した上限を超えると通知してくれる。
ダッシュボード
グラフなどを見ることができる。
CloudWatch Logs
ログを収集、保存してくれる。保存期間は一日から10年、もしくは無期限の設定がある。
対象はAWSサービスのログ。エージェントを入れればインスタンスのログも。収集したログはS3にエクスポートできる。
CloudWatch Logs Metric Filterを使うと、特定の文字列だけ抽出できる。errorを含むログのみ表示とか、errorを含むログを見つけたときだけ通知とか。
収集したログはAmazon Elasticsearch Serviceと連携し、ビジュアル化できる。
連携できる主要サービスはCloudtrail、Route53、Lambda、VPC、SNS、EC2、RDS。操作ログとかシステムログとか。
CloudWatch Events
リソースの変化をトリガーに、アクションを実行できるサービス。イベント、ターゲット、ルールがある。
イベントは、ログインしたら〜とか、何かが起こったときのこと。
ターゲットは行う処理のこと。
ルールはその2つのこと。〇〇したら☓☓する、みたいな感じ。
CloudTrail
AWSサービスの操作の監視。AWSマネジメントコンソールへのログインとか、ユーザーが操作した設定変更とか、AWSサービスが実施した操作など。標準で90日間、アクティビティを各リージョンに記録してる。
証跡を有効化すると、これをs3に保存してくれる。
リージョン毎に保存する方法と、全リージョンまとめたものを作る方法がある。全リージョンで有効化すると、s3に全リージョンのアクティビティログがまとめて記録される。
また、CloudWatch Logsへの送信を有効化するとCloudWatch Logsで見れる。
よって、CloudWatch Eventsの起動などもできる。
config
AWSリソースの構成管理と変更の監査を行うマネージドサービス。AWSの構成が企業のガバナンスに準拠しているかどうかを評価してくれる。
最大7年間の構成変更を記録できる。AWSリソースがいつ変更されたのかや、どの項目が変更されたのか等の履歴を記録。これをタイムラインで見ることができる。
変更されたときにSNSで通知できる。また、ログをS3に保存しておける。CloudTrailとの違いは、あっちは操作内容によってアクションを設定できるが、こっちは構成がコンプラに準拠しているかのチェックを行うだけ。
ルール
ルールをきめて、それに従っているかどうかの判断をしてくれる。要するに、MFAすることをルールにすれば、設定している人がコンプラ準拠、していない人は非準拠となる。
AWSできめたAWSマネージドルールと、ユーザが決めるカスタムルールがある。こっちはユーザが構成を定義し、ルールの評価にlambda関数を作成して使用する。
Configダッシュボードには結果のサマリが表示される。
Configアグリゲータは、ルールの評価結果を複数のアカウントやリージョンについて集約する。要するに一つのアカウントでとりまとめてくれる。
Trusted Advisor
現在の環境をリアルタイムで分析し、ベストプラクティスに沿ったアクションを推奨して通知してくれる。
以下5カテゴリ。
- コスト最適化
- パフォーマンス
- セキュリティ
- 耐障害性
- サービスの制限
オペレーション自動化サービス
CI/CDの話。インフラのコード化とか。以下のサービスがある。
CloudFormation
AWSリソースのテンプレによる自動デプロイサービス。インフラをコード化し自動デプロイできるようにする。
シンプルなテキストファイルによるテンプレートを使用することにより、人為的ミスを防ぎ、正確なデプロイができるようになる。
インフラのコード化をInfrastructure as Codeと呼ぶ。
基本的なネットワーク構成の作成や、Webアプリケーションの作成、管理機能の有効化などができる。
テンプレートはJSON形式化YAML形式で記載する。作成の際は一般的なテキストエディタかCloudFormationデザイナーを使用して作成できる。プレートスニペットというテンプレを参照できる。
CloudFormationでAWSリソースをプロビジョニング(準備)するには、CloudFormationスタックを作成して実施する。
テンプレとパラメータを入れればデプロイされる。デプロイに失敗した場合、作成されたAWSリソースは削除され、元に戻る。
テンプレ変更した後にスタックの更新をすると、デプロイ済みのAWSリソースの設定変更がされる。また、スタックを削除するとAWSリソースも削除される。
複数のリージョンやアカウントで一斉にプロビジョニングするにはCloudFormationスタックセットを作成する。スタックセットではスタックの設定に加えて、デプロイ先を指定する必要がある。
Elastic Beanstalk
Webアプリケーション環境を自動構築するサービス。Webアプリケーションを実行するのに必要なWebサーバ、アプリケーションサーバ、データベースなどの構成をAWSがしてくれる。要するにこれを使えば環境を自動構築してくれる。そこにコードをアップロードするだけでアプリがデプロイされる。簡単。
アプリケーションのバージョン管理も行ってくれる。
AWS Opsworks
Chef、Puppetを使用してサーバの構成管理を自動化してくれる。OpsWorksって文字が出てきたらChef、Puppetと覚えよう(理解のあきらめ)
三つの違いは、インフラの自動構成であればCloudFormation、Webアプリケーションの環境の自動構築ならElasticBeanstalk、Chefなどつかってたものをそのまま使いたいならOpsWorks。
ここまででいったん区切り。次回アプリケーション統合へ。