Day10 CLIによるAWSの操作とシステム監視
マネージメントコンソールからの操作をターミナルでできる
> aws --v aws-cli/1.16.96 Python/2.7.15 Windows/10 botocore/1.12.86
batchインスタンスを起動
> cd .aws > more config [default] output = json region = ap-northrast-1
IAM→ユーザ
アクセスキー シークレットキーを控えて入力する
> aws configure AWS Access Key ID : xxx AWS Secret Access Key : xxx Default region name : ap-northeast-1 Default output format : json
Windows PowerShellでコマンドを叩くと、S3のバケット名を取得できるが変なエラーが出る
> aws s3 ls C:\Program Files\Amazon\AWSCLI\.\dateutil\parser\_parser.py:1175: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
Set-Item env:tz -Value jst
でUnicodeWarningが出なくなる。
他の権限で操作したいとき、--profileオプションを付けて、切り替える
> aws configure --profile 設定名 > aws s3 ls --profile 設定名
- コマンドリファレンス
aws — AWS CLI 1.16.96 Command Reference
S3バケットを作って、ファイルをアップロードする
// make bucket // aws-cli-cmd-testというバケット名で作成 > aws s3 mb s3://aws-cli-cmd-test aws s3 ls > aws s3 cp ファイル名 s3://aws-cli-cmd-test
CloudWatchについて
https://aws.amazon.com/jp/cloudwatch/
AWSリソースの状況を監視する
メトリクス AWSが標準で提供するメトリクス Disk,Network,CPU,Statusなど メトリクスを独自にカスタムもできる
CloudWatchの設定
ClowdWatch→アラームの作成
メトリクスの選択
メトリクスの選択→EC2
CPUUtilizationを選択割り当てられた EC2 コンピュートユニットのうち、現在インスタンス上で使用されているものの比率。このメトリクスは、選択されたインスタンス上でアプリケーションを実行するのに必要な処理能力を表します。
パーセンタイル統計を使用するには、詳細モニタリングを有効にする必要があります。
インスタンスタイプによっては、インスタンスがフルプロセッサコアに割り当てられていない場合に、オペレーティングシステムのツールが CloudWatch よりも低い比率を示す場合があります。
単位: パーセント
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.htmlアラームの定義
名前:BatchCPUMoreThan10percent
説明:BatchCPUMoreThan10percent
CPU使用率が10%を超えたときにアラームを出すように設定
一旦アラームの作成
- 通知先の設定
アクション→変更→通知
+新しいリスト
通知の送信先:CloudWatchAlert
メールリスト:通知先のメールアドレス
Batchインスタンスにログインして、負荷を上げる
yes > /dev/null &
設定値を超えるとアラームが出る
Day11 コンテンツキャッシュとインメモリキャッシュ
CloudFrontについて
CDN(Contents Delivery Network)を配置して、CDNからのキャッシュを利用することでサーバの負荷を下げる。 世界中に100を超えるエッジロケーションが存在する。
- CloudFrontの導入
ELBの前段に配置する - オリジンサーバの指定
- キャッシュのふるまいの設定
- キャッシュTTLの設定
- その他の設定
CloudFront→Create Distribution→Web Get Started
Origin Settings
Origin Domain Name:ELBのDNS
基本的にデフォルトDefault Cache Behavior Settings
- Object Caching: Customize
Minimum TTL:20
Maximum TTL:20
Default TTL:20
TTL(Time to live)=コンテンツがエッジキャッシュに保持される期間の管理 (有効期限)
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
作成まで10分ほどかかる。
IDをクリック、Domain Name:xxx.cloudfront.net
にアクセスするとページが見れる。
- CloudFrontを試してみる
起動しているインスタンスのindex.phpを一部変えてみる。
ELBのDNSにアクセスしてみると変更が適用されている。
http://xxx.ap-northeast-1.elb.amazonaws.com/
xxx.cloudfront.netにアクセスしても変わっていないが、20秒後にアクセスすると変更が適用されている。
20秒毎にTTLを見に行くので、データが更新されるまで最大20秒、時間がかかる。
Curlコマンドでのキャッシュを確認する
curl -v http://xxx.cloudfront.net/ > /dev/null < Age: 18 < X-Cache: Hit from cloudfront
CloudFrontを使う際のポイント
- キャッシュTTLの設計
短すぎるとキャッシュしている意味が薄れてしまうし、長すぎるとコンテンツのアップロードが更新されない。バランスを考慮する必要がある。リアルタイム性が高い場合は、デプロイ時にキャッシュをクリアするなどのフローを考える。 - CloudWatchで監視する
CloudFrontのメトリクスがある。CloudWatch を使用した CloudFront アクティビティの監視 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html
デフォルトでは、オリジンから HTTP 4xx または 5xx ステータスコードが返されると、CloudFront はこれらのエラーレスポンスを 5 分間キャッシュします。 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages-expiration.html
- Popular Object Reportをもとに設定を定期的に見直す キャッシュのヒット率などをもとにTTLを見直す
ElasticCacheについて
CDNのデータベース版。
頻繁にアクセスするデータをデータベースではなくてインメモリキャッシュに格納することでデータベースの負荷を軽減する設計パターン。
ElasticCacheの導入 プライベートサブネットに配置 1. サブネットグループの作成 2. パラメータグループの作成 3. ノードタイプの設定 4. レプリケーションの設定 5. セキュリティグループの設定
今回はRedisを使う ElasticCache→パラメータグループ default.Redisはパラメータグループを変更できないので、パラメータグループの作成を行う。
パラメータグループの作成
ファミリー:Redis 4.0サブネットグループの作成 アベイラビリティーゾーン:ap-northeast-1a
サブネットid:private-1a
追加セキュリティグループの作成 EC2→セキュリティグループの作成 インバウンド
カスタムTCP ポート:6379 ソース:batch-sg,web-sgからの接続を許可する 作成
ElasticCache→Redis→作成 クラスターエンジン:Redis エンジンバージョンの互換性:4.0.10 パラメータグループ:先程作ったパラメータグループ ノード:t2.micro レプリケーション数:0
サブネットグループ:先程作ったサブネットグループ 優先アベイラビリティーゾーン:指定なし
セキュリティグループ:先程作ったセキュリティグループを追加
- Redisのインストール Batchインスタンスに接続
> sudo yum install -y redis --enablerepo=epel // redisのプライマリエンドポイント > redis-cli -h redis.xxx.xxx.apne1.cache.amazonaws.com
ElasticCacheを使う際のポイント
キャッシュするデータの選定
頻繁に更新するようなデータはキャッシュヒットしにくいので意味がない。更新は少ないけど、頻繁に参照されるものは効果が高い。耐障害性への考慮
マルチノードで構築する。RDSと同じようにマルチAZ構成になるようにする。単一AZの障害で止まらないようにする。負荷テストを実施して、ノードのタイプを決定する