運用メモ

クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。

それをクラウドアーキテクティング原則として整理している

日時作業：

1)cloudwatch を見て、リソースの状況を把握する

①平均値を常に把握する
②把握している、平均値の上限越えがあった場合、インスタンスサイズの検討する(スケールアップ/スケースアウト)

障害対応：

1)ローカルからどのホストのどのアプリケーション（ポート番号）への接続が行われているか確認を行う

netstat -alnA inet

netstat -n | grep 80

アクティブセッション数を確認：

watch -d -n 1 "netstat -alpn | grep -E ':(80|443) ' | awk {'print $5'} | sed -e 's/\:[^.]*$//' | sort | uniq -c"

Cloudwatch監視項目：

[EC2]

①CPU使用率

②CPUクレジット消費数・残数（t2系のインスタンスのバーストできるクレジット）

③ディスクのread・writeのI/O数、バイト数

④ネットワークのイン・アウトの使用バイト数

⑤システムチェック（AWSホスト側のネットワーク、ハード等の状態と、EC2インスタンスステータスチェック状態）

⑥ログ監視

CloudWatchの詳細：

メトリクス	内容	単位
CPUUtilization	CPU使用率	パーセント
DiskReadOps	ディスク読み取り数	数
DiskWriteOps	ディスク書き込み数	数
DiskReadBytes	ディスク読み取り量	Bytes
DiskWriteBytes	ディスク書き込み量	Bytes
NetworkIn	ネットワーク受信量	Bytes
NetworkOut	ネットワーク送信量	Bytes
StatusCheckFailed	インスタンスステータスチェックかシステムステータスチェックのどちらかが失敗した場合1になる。	0(成功) 1(失敗)
StatusCheckFailed_Instance	インスタンスステータスチェックは、個々のEC2インスタンスのソフトウェアやネットワークの状態確認。失敗した場合1になる。	0(成功) 1(失敗)
StatusCheckFailed_System	システムステータスチェックは、EC2インスタンスに必要なAWSシステムの状態確認。失敗した場合1になる。	0(成功) 1(失敗)

[ELB]

①バックエンドの正常・異常なホスト数（ヘルスチェック成功？失敗？）

②バックエンドへのリクエスト数

③バックエンドへのリクエストのレイテンシ

④ELBが返した、4XX、5XXのエラーコード数

⑤バックエンドが返した、2XX、3XX、4XX、5XX

⑥バックエンドとの接続失敗した数

⑦バックエンドへの保留中のリクエスト、キューが一杯のため拒否したリクエスト

[RDS]

①リードレプリカ利用時の、マスター側で専有しているバイナリログの容量（バイト）

②CPU使用率

③CPUクレジット消費数・残数（t2系のインスタンスのバーストできるクレジット）

④データベースへの接続数

⑤read・writeのキューの数（負荷などで、書き込み・読み込み待ちになったキュー数）

⑥利用可能なメモリ容量（EC2では取得できないがRDSでは取得可能）

⑦利用可能なストレージ容量（EC2では取得できないがRDSでは取得可能）

⑧MySQL、マルチAZ利用時のレプリケーションラグの秒数

⑨RDSのswap総容量

⑩秒間あたりの書き込み操作数、読み込み操作数

⑪１回の書き込みにかかる平均秒数、１回の読み込みにかかる平均秒数

⑫１回の書き込みにかかる平均バイト数、１回の読み込みにかかる平均バイト数

⑬受信時のネットワークトラフィック（バイト/秒）、送信時のネットワークトラフィック（バイト/秒）

CloudWatchの詳細：

メトリクス	内容	単位
BinLogDiskUsage	マスターのバイナリログのサイズ	Bytes
CPUUtilization	CPU使用率	パーセント
DatabaseConnections	DBコネクション数	数
DiskQueueDepth	ディスクI/Oキュー数	数
FreeableMemory	空きメモリ量	Bytes
FreeStorageSpace	空きディスクスペース量	Bytes
ReplicaLag	リードレプリカのタイムラグ	秒
SwapUsage	スワップ使用量	Bytes
ReadIOPS	読み込みIOPS	数/秒
WriteIOPS	書き込みIOPS	数/秒
ReadLatency	読み込みレイテンシ	秒
WriteLatency	書き込みレイテンシ	秒
ReadThroughput	読み込みスループット	bytes/秒
WriteThroughput	書き込みスループット	bytes/秒

参照先：

https://avinton.com/blog/2017/10/linux-network-troubleshooting/

ログの確認：

ネットワーク障害が発生した際に、ログに何らかの障害情報が記載されている可能性が高いと考えられます。

具体的には下記のログを確認することが有効と考えられます。

①一般的なログ。サービス起動時の出力など

1	var/log/messages

②認証、セキュリティ関連のログ 

1	/var/log/secure

③メール関連のログ 

1	/var/log/maillog

④カーネルが出力したメッセージのログ。ハードの故障の際にはこちら。 

1	/var/log/dmesg

⑤WEBサーバに関連のログ 

1	/var/log/httpd

備考：

その他Linux上のログは var/log/ 配下に出力されます。

各種 log を確認し、failなどのエラーを表す記載があるようでしたら、

付随するメッセージに従い、原因を除去します。

接続状況確認：

①netstat -ap | grep "LISTEN "

②netstat -ltupn

③netstat又は、ssコマンドで、現在開いているポートを一覧表示することができる。

オプション	説明
-l	Listenしているポートのみ表示
-t	TCPを表示
-u	UDPを表示
-n	ポートやホストを数値で表示
-p	ポートを開いているプロセスを表示（sudo）
-4	IPv4のみ
-6	IPv6のみ

80/443ポートの確認：

来れば数秒間隔で更新される（接続数を確認できる）

watch -d -n 1 "netstat -an |grep :80 |wc -l"

sudo watch -d -n 1 "netstat -plan|egrep ':(80|443) '|awk {'print $5'}|sed -e 's/\:[^.]*$//'|sort|uniq -c|sort -nk 1"

ps auxf | grep httpd

ELBに関するHTTPコードについて

HTTPCode_Backend_2XX：

(3)及び(4)のレスポンスで200系のHTTPレスポンスを行い、(1)〜(4)までのステップを全て正常に完了した場合、HTTPCode_Backend_2XXとしてカウントされます。

一般的に最も健全な動作と言えるでしょう。

HTTPCode_Backend_4XX：

(1)〜(4)までのステップを全て正常に完了したのだが、3のレスポンスが400系レスポンスであり、その結果(4)のレスポンスが400系として完了した場合、これはHTTPCode_Backend_4XXとしてカウントされます。存在しないリソースにアクセスして404がとなった場合や、Web APIに於いて必須のパラメータが足りなかった場合の400レスポンス等、クライアント側の「リクエストの仕方」に問題がある場合、400系のレスポンスを返すのが一般的ですね。

HTTPCode_Backend_5XX：

(1)〜(4)までのステップを全て正常に完了したのだが、(3)のレスポンスが500系レスポンスであり、その結果(4)のレスポンスが500系として完了した場合、これはHTTPCode_Backend_5XXとしてカウントされます。アプリケーション層でのエラーにより正常なレスポンスが返せなかった場合の500、メンテナンス中の503等、

エラーの原因がサーバ側にある場合、500系のレスポンスを返すのが一般的です。

ELBが独自の判断によりステータスコードを返す場合（HTTPCode_ELB_*）

以上の通り、普通は「バックエンドから受け取ったレスポンス(3)をそのままクライアントに返す(4)」のが

ELBの動きです。

しかし、特定の状況下ではELBは独自の判断で(4)のレスポンスを行います。

HTTPCode_ELB_4XX：

①HTTP 400: BAD_REQUEST

そもそも(1)のリクエストが日本語でおｋHTTPリクエストとして解釈不能な場合、ELBは(2)のリクエスト転送を行わず（行えず？）、400を返します。

②HTTP 405: METHOD_NOT_ALLOWED

(1)のリクエストにおけるHTTPメソッド名（GETやPOST等）が127文字を超えていた場合、ELBは(2)のリクエスト転送を行わず、405を返します。

HTTPメソッドは、よく知られたGET, POST, OPTIONS等の他に、独自の拡張が可能です。（RFC 2616 Section 5.1.1参照）

このような拡張を利用していた時、無駄に長いHTTPメソッド名が使われる可能性もゼロではありません。

HTTPの仕様上、この長さには制限は無いようですが、ELBとしては127文字を上限としているようです。

③HTTP 408: Request Timeout

(1)のリクエストでタイムアウトが発生した場合、ELBは(2)のリクエスト転送を行わず（行えず？）、408を返します。

例えば、ネットワーク切断が発生した場合や、Content-Lengthの値よりも実際のサイズが小さくてELBが続きを待ってしまう場合など、ELBが(1)の完了を認識できずにタイムアウトした場合があてはまります。

HTTPCode_ELB_5XX：

①HTTP 502: Bad Gateway

(3)のレスポンスが日本語でHTTPレスポンスとして解釈不能な場合、ELBは502を返します。

②HTTP 503: Service Unavailable(ELBの高負荷系)

Case 1:

突発的なアクセスによりELB自体がキャパシティを超えてしまった場合です。

ELBは、負荷に応じて自動スケールします。

 ->ELBを突発的な負荷が襲った場合、スケーリングが間に合わないことがあります。

また、負荷により「スケールアップ」が行われた場合、ELBのDNS名から正引きされるIPアドレスが変わります。

つまり、古い（小さな）インスタンスと、新しい（大きな）インスタンスにバトンタッチが起こります。

しかし、クライアントがDNSキャッシュを持っていた場合、スケールアップ前の古いインスタンスに対してリクエストを送り続けてしまうことがあります。

こういった場合にも、キャパ超えのレスポンスとして503が返されるでしょう。

このようなケースに対しては、ベンチマークツール等を利用して本番想定の負荷をあらかじめ掛けておき

ELBの自動的なスケーリングによる調整を期待した上で、本番運用を開始するといった対応が必要です。

このような対応が行えない場合、AWSサポートのビジネスまたはエンタープライズに加入しているのであれば

暖気申請を行うことも可能です。

AWSサポートに対して、いつ頃どの程度のリクエストが来るのか、事前に通知を行うことにより、リクエストを充分受け付けられる規模にあらかじめスケールをしてもらえます。

Case 2: 

(3)を行った後(4)が返ってくるのに時間が掛かり、(3)のリクエストがタイムアウトした場合です。

このタイムアウト時間は通常60秒です。

このケースに対応する場合、アプリケーションが60秒以内にレスポンスを返すように何らかの対応を行うのが

第一選択ですが、サポートに依頼することによりタイムアウト時間を最大17分まで延長することができるようです。

docker エラー解析

参照先：

https://make-ship.com/?p=761

エラーコード確認；

docker ps -a

ログを確認する

docker logs [container_name]

Flowログの作成方法

参照先：

https://dev.classmethod.jp/articles/introduce-to-vpc-flow-log/

1)ロググループから新規作成する

2)VPCダッシュボードに移動して、対象のVPCを選択

3)権限設定を選ぶ

4)許可を選択

5)作成ボタンを押す

設定後、VPCからのログがCloudwatch logに入ってくるのでCloudwatch log(インサイト)で

アクセス先が確認しやすくなる

(今回、サンプルイメージを使ってみました。様々な集計が出来そう)