[AWS ALB] EC2で最初の接続だけ異常に重い時

EC2で最初の接続だけ異常に重く、一度接続すると、サクサク動く。
何故だ?curlで計測したところ、以下の様に最初の接続に130秒もかかっている。

$ curl ‘https://*.com/login’ -H ‘Accept-Encoding: gzip, deflate, sdch’ ept-Language: en-US,en;q=0.8,ja;q=0.6′ -H ‘Upgrade-Insecure-Requests: 1’ -H ‘User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36’ -H ‘Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8’ -H ‘Connection: keep-alive’ –compressed -o /dev/null -w “%{time_starttransfer}\n” -s
130.982826

最初、メモリが問題かと思って、増設し、さらにswapもつけたが、それでも変わらない。

$ df
ファイルシス 1K-ブロック 使用 使用可 使用% マウント位置
devtmpfs 492676 0 492676 0% /dev
tmpfs 503444 0 503444 0% /dev/shm
tmpfs 503444 524 502920 1% /run
tmpfs 503444 0 503444 0% /sys/fs/cgroup
/dev/xvda1 18862060 13096136 5765924 70% /
tmpfs 100692 0 100692 0% /run/user/1000

$ free
total used free shared buff/cache available
Mem: 1006892 713376 72396 352 221120 154016
Swap: 1048572 768 1047804

明らかにおかしいと思ったら、2つのsubnetのうち1つがinternet gatewayにアタッチされていなかったのが原因。

AWS Elastic Load Balancing: Seeing extremely long initial connection time
https://stackoverflow.com/questions/35523421/aws-elastic-load-balancing-seeing-extremely-long-initial-connection-time

ALBだとAZで2つのsubnetの設定が必要だが、今回はインスタンスは1つしか使わないので、internet gatewayには1つしかアタッチしてなかった。もう一つのpublic subnetをigwにアタッチしたところ、0.63msに改善

$ curl ‘https://*.com/login’ -H ‘Accept-Encoding: gzip, deflate, sdch’ -H ‘Accept-Language: en-US,en;q=0.8,ja;q=0.6’ -H ‘Upgrade-Insecure-Requests: 1’ -H ‘User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36’ -H ‘Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8’ -H ‘Connection: keep-alive’ –compressed -o /dev/null -w “%{time_starttransfer}\n” -s
0.638270

メモリの問題じゃなかったああああああああああああああああああ 
なんてこったい

[AWS EBS] EC2でEBSの使用率が100%になった場合

EC2でEBSの使用率が100%になった場合、
1. AWSコンソールのEBSVolumes -> Action-> modify volume
2. EC2サーバにSSHログインし、”sudo xfs_growfs -d /”でボリューム拡張を反映
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

### EBSが100%になった時
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs tmpfs tmpfs tmpfs /dev/xvda1 tmpfs
482M 0 482M 0% /dev
492M 0 492M 0% /dev/shm 492M 25M 467M 6% /run
492M 0 492M 0% /sys/fs/cgroup
8.0G 8.0G 12M 100% /
99M 0 99M 0% /run/user/1000

-> サーバーにアクセスできなくなる。
-> MySQLが落ちる

サーバーのエラーログ
—–
(28)No space left on device: [client 61.206.21.97:9568] AH00646: Error writing to logs/access_log, referer:

## 対応法
sshログイン
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 12G 0 disk
└─xvda1 202:1 0 12G 0 part /
// 8Gから12Gに増やしたことが確認できるが、この時点ではまだ反映されていない
$ df -hT
ファイルシス タイプ サイズ 使用 残り 使用% マウント位置
devtmpfs devtmpfs 482M 0 482M 0% /dev
tmpfs tmpfs 492M 0 492M 0% /dev/shm
tmpfs tmpfs 492M 25M 467M 6% /run
tmpfs tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 xfs 8.0G 8.0G 12M 100% /
tmpfs tmpfs 99M 0 99M 0% /run/user/1000
$ sudo xfs_growfs -d /
meta-data=/dev/xvda1 isize=512 agcount=4, agsize=524159 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0
data = bsize=4096 blocks=2096635, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2096635 to 3145211
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 482M 0 482M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 25M 467M 6% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 12G 8.0G 4.1G 67% /
tmpfs 99M 0 99M 0% /run/user/1000

### MySQL再起動
$ sudo systemctl restart mysqld.service
$ sudo systemctl start mysqld.service
$ sudo systemctl enable mysqld.service
$ systemctl status mysqld.service

Mackerelでファイル使用率が90%以上になってたのに、見逃してた。。
やっちまったわ。

[AWS ELB] ALBのログをS3に出力

apache2のaccess.log, error.logだけでなく、ALBのログも取得したい

1. S2にbucketを作成します。
– access-log-hoge
– permissionは Block all public access でOK

2. bucket policyを編集する
account IDで、tokyoは582318560864となる。
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html
ap-northeast-1 Asia Pacific (Tokyo) 582318560864

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::582318560864:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::access-log-hoge/AWSLogs/${aws-id}/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::access-log-hoge/AWSLogs/${aws-id}/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::access-log-hoge"
    }
  ]
}

4. ALB側でaccess logをenabledにする

5. bucket
logファイルの出力を確認

うん、なんか出来てるっぽいな。

以下のようなディレクトリで出力される
Amazon S3 / access-log-hoge / AWSLogs/ ${account-id}/ elasticloadbalancing/ ap-northeast-1/ 2021/ 01/ 17/

ファイル名
${account-id}_elasticloadbalancing_ap-northeast-1_app.hoge-prd-alb.*.log.gz

gzファイルなのでdownloadして中身をみる。
うーん、timestampがUTCなのがちょっと見にくいが、そのほかはapacheのaccess.logのように確認できる

CodeDeployでBlockTrafficとAllowTrafficに5分以上かかる時

CodeDeployでBlockTrafficとAllowTrafficに5分以上かかる時

ALBのHealth checkが原因とのこと
defaultでTimeout 5 seconds, Interval 30 secondsとなっているので、ELB Targets Groupsから、Health Checkの設定をそれぞれ、2秒、5秒に変更する

AWSのフォーラムでも回答されています。
Developer Forum

Yes CodeDeploy depends on the ELB Health Check settings that you have configured your ELB with. After an instance is bound to the ELB, CodeDeploy wait for the status if the instance to be healthy ("inService") behind the load balancer. This health check is done by ELB and depends on the health check configuration you have set.

ELBで異なるsubnetのEC2に冗長化する書き方

ELBで負荷分散して冗長化する

### public subnetを二つ用意
– availability zoneが異なるpublic subnetの中に、それぞれEC2を配置する
現状

dev-vpc(192.168.0.0/16)
dev-subnet-public1(192.168.1.0/28) ap-northeast-1a ・・・web-prd-01 
dev-subnet-private1(192.168.2.0/28) ap-northeast-1a ・・・RDS MultiAZ
dev-subnet-private2(192.168.3.0/28) ap-northeast-1c・・・RDS MultiAZ 

上記を踏まえ、以下のsubnetを作成する
1.dev-subnet-public2(192.168.4.0/28) ap-northeast-1c ・・・web-prd-02
2.作成済みのpublic route tableを関連付ける(internet gatewayは紐付け済)

### AMIからインスタンス作成
– web-prd-01のAMIからインスタンスを複製する
– VPCにdev-vpc、subnetにdev-subnet-public2を割り当てる
– Auto-assign Public IP Enable, IAM role s3readonly

-インスタンスを起動し、動作確認
-SSHログインしてファイルも確認する

### ロードバランサの構築
– EC2左メニューLOAD BALANCINGのTarget Groupsの作成
– target group name: ${app name}-target-group
– target type: instance
– Protocol: HTTP
– Port: 80
– VPC:dev-vpc
– Health check settings: http, /

作成したtarget-groupにAction-> Register and deregister instance/ip targets からweb-prd-01, web-prd-02を紐付ける

### ALBの作成
Name: ${appName}-prd-alb
Scheme: internet-facing
IP address type: ipv4
Lisnter: http:80
Availability Zones:
VPC: dev-vpc
Subnet: dev-subnet-public1, dev-subnet-public2

Configure Security Groups
-> ALBのSecurity Groupを作成する
-> alb-${appName}-security-group
-> Custom TCP

Configure Routing
– Target group: Existing target group
– Name: ${appName}-target-group
– Protocol Port: HTTP 80

### security groupを新規に作成
インバウンドルールに、ALBのみから受け付けるように設定する
– SSH:0.0.0.0/0
– HTTP: ${albのsecuritygroup ID}
インスタンス(web-prd-01, web-prd-02)のセキュリティグループを新規に作成したセキュリティグループに変更

->ALBのDNS nameを叩いて動作確認
->instanceのpublic ipを叩いてもresponseが返ってこない事を確認

UnHealthyHostCount, Latency

UnHealthyHostCount
Number of healthy EC2 instances registered with the load balancer in the specified Availability Zone. Hosts that do not fail the health check beyond the unhealthy threshold are considered healthy. When evaluating this metric, the dimensions should be defined by LoadBalancerName and AvailabilityZone.
This metric represents the number of healthy instances in the specified Availability Zone. Instances may become unhealthy due to connection problems such as non-200 responses (for HTTP and HTTPS health checks) and timeouts when doing health checks. In order to get the total number of all healthy hosts, this metric needs to get each registered AvailabilityZone and add all metrics together.

Latency
The elapsed time from request leaving the load balancer to receiving the corresponding response.

ELB access log

ELBでアクセスログが取得できる。

2014-03-07T07:25:38.285777Z elber 130.0.237.XX:37522 172.31.4.218:80 0.000066 0.00105 0.000037 404 404 0 570 "GET http://54.249.27.XX:80/actus4/ HTTP/1.1"
2014-03-07T07:26:43.731149Z elber 77.50.22.XXX:53477 172.31.4.218:80 0.000053 0.000866 0.000053 200 200 0 10 "GET http://54.249.27.XX:80/ HTTP/1.0"
2014-03-07T07:26:44.410747Z elber 77.50.22.XXX:53656 172.31.4.218:80 0.000052 0.000853 0.000039 404 404 0 168 "GET http://54.249.27.XX:80/foltia/ HTTP/1.0"
2014-03-07T07:26:45.084730Z elber 77.50.22.XXX:53839 172.31.4.218:80 0.000061 0.000874 0.000035 404 404 0 168 "GET http://54.249.27.XX:80/epgrec/do-record.sh HTTP/1.0"
2014-03-07T07:28:12.386207Z elber 189.206.75.XX:64289 172.31.4.218:80 0.000062 0.000924 0.000035 404 404 0 168 "GET http://54.249.27.XX:80/manager/html HTTP/1.1"

問題は、項目。

timestamp
The time accessed by the Client. UTC time, recorded in ISO 8601 format.
2014-02-15T23: 39: 43. 945958 Z

Name of ELB
ELB Name: test-loadbalancer

Client
Port Client IP address and port number
192.168.131.39.2817

Backend
port IP address and port number of the instance to which communication was distributed by ELB. This will tell you which server it was assigned to 10.0.0.0:80

request_processing_time
The time between the ELB receiving a request from the client and sending the request to the instance
0.000073

backend_processing_time
The time it takes for the ELB to send a request to an instance and the instance returns a response.
0.001048

response_processing_time
The time from when the ELB receives a response from an instance to when it returns a response to the client.
0.000057

elb_status_code
response status code.
200

backend_status_code
Response status code of the instance to which the ELB sent the request.
200

received_bytes
Size of received request (bytes)
0

sent_bytes
Size of sent request (bytes)
29

request
request from a client
“GET http://www.example.com:80/HTTP/1.1”

ELB http 460

What is HTTP 460 on ELB
The load balancer received a request from a client, but the client closed the connection with the load balancer before the idle timeout expired.

Check if the client timeout period is longer than the load balancer idle timeout period. Before the client timeout period expires, make sure that target returns a response to the client, or if the client supports it, increase the client timeout period to match the load balancer idle timeout.