常連

お世話になります。

EC2でrailsアプリをインスタンス3つでauto scalingしています。

アクセスすると以下のインスタンス1 ~ 3のうちどれかにつながるのですが

```
インスタンス1 > A.html.erb : A.css
インスタンス2 > B.html.erb : B.css
インスタンス3 > C.html.erb : C.css
```

1回のアクセスで、html.erbはAに、cssはBにつながる、という事は起こるのでしょうか？
(cssは /public/packs/css にあります)


#### 補足：

インスタンス1でcssを編集し
`$ rails assets:precompile` をしました。

(インスタンス1 ~ 3にあるrailsの内容はcssの一部以外全て同じです)

アクセスするとたまにcssがnot foundでコンソールエラーが出ます。
(体感的に 1/3 の確率でA.html.erb、 2/3の確率で B または C.css => 5回に1回ぐらいnot foundエラー）

awsのauto scalingはviewとcssで切り分けて割り振られるか

**前提**
---
Auto Scalingグループ及び起動テンプレートは以下の内容で作成しました。

◆EC2>起動テンプレート>AutoScalingTest
・グループの詳細
希望する容量：2
最小キャパシティ：0
最大キャパシティ：2

・起動テンプレート
EIPtest

◆EC2>起動テンプレート
・起動テンプレートの詳細
起動テンプレート名：EIPtest

・インスタンスの詳細
AMI：windows server 2019

・ネットワークインターフェース
パブリックIPの自動割り当て：有効
※その他は未設定

・高度な詳細
IAMインスタンスプロフィール
```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeAddresses",
        "ec2:AssociateAddress"
        ],
      "Effect": "Allow",
      "Resource": "*"
    }
   ]
}
```
こちらを参考
[auto scalingでElasticIPを自動割り当て](https://zuntan02.hateblo.jp/entry/2019/09/19/211035)

◆Elastic IP
IDを2つ発行

**試したこと**
---
以下のサイトのようにIAMロールの作成・Bashスクリプトをユーザーデータに張り付けて起動テンプレートに割り当てを行いましたが、起動したEC2にはElastic IPは関連付けされませんでした。
[auto scalingでElasticIPを自動割り当て](https://zuntan02.hateblo.jp/entry/2019/09/19/211035)
[Auto Scaling で追加したEC2 インスタンスにEIP を自動で紐づける](https://qiita.com/kanadeee/items/955eb8710e97a4ed5fd3)
[起動時に複数のEIPの中から一つを設定する](https://dev.classmethod.jp/articles/choose-eip-from-addresspool/)

**実現したいこと**
---
上記の構築でAuto Scalingで起動するEC2インスタンスにElastic IPを自動的に割り当てたいのですが、色々とサイトを調べたり設定を変えたりしても出来ませんでした。
よろしくお願いいたします。

因みに「試したこと」の内容はAMIをLinuxに変更なら可能ということでしょうか。

AWS Auto Scalingで起動するEC2インスタンスにElastic IPを自動的に割り当てたい

たとえばWebアプリのAPサーバをAutoScalingしようとした際、
新規で起動したサーバへのアプリのデプロイ方式はどんなものが推奨されるか、
あるいはそれぞれのやり方でメリット・デメリットあるようであれば比較を教えてください。

（例）
最新アプリをデプロイ済のゴールデンAMIを作成し、それを元にAutoScalingする
メリット：スケール速度が速い
デメリット：アプリ更新時にAMIの作成し直しが必要となる

AutoScaling時のアプリのデプロイ方式について

以下のような構成で、EC2終端で接続元の認証をしようとしています。
また、ELB配下のEC2はターゲットグループ指定でAutoscaleします。

クライアントPC(クライアント証明書)⇒ELB⇒EC2(nginx)

この前提で、以下二点教えてください。

１．最初、CLBを使ってTCP443をTCP443に投げれば良いかと思っていましたが、
CLBはターゲットグループではなくインスタンス単位の指定しか出来ませんでした。
このサイトのパターン4が今回の構成の場合適切な認識ですが、
その理解でよろしいでしょうか？
https://recipe.kc-cloud.jp/archives/11067

２．ALBやCLBでは443⇒443をしようとするとサーバ証明書が必須でしたが、
NLBを使うとサーバ証明書の指定がないのはなぜでしょうか？

ELB構成の設計について教えてください

Rails初心者エンジニアです。
WebアプリのプロトタイプをAWS上にデプロイ・運用していく予定で、本番環境の構築を進めております。

###実現したいこと
サーバー自動復旧の準備として、Amazon Linux2上で、アプリサーバー（Unicorn）の自動起動の設定を行いたい

###実施内容
0. systemdを使ってunicornを起動するユニットファイル（/etc/systemd/system/unicorn.service）を作成し
0. 設定内容を反映 `sudo systemctl daemon-reload`
0. 確認のため手動でsystemctlで起動 `sudo systemctl start unicorn.service`


**unicorn.serviceファイルの内容**
```
[Unit]
Description=The unicorn process
After=network.target remote-fs.target nss-lookup.target
Before=nginx.service

[Service]
User=myname
WorkingDirectory=/var/www/rails/myapp
SyslogIdentifier=unicorn
Type=simple
Restart=on-failure

Environment=RAILS_ENV=production
Environment=UNICORN_CONF=/var/www/rails/myapp/config/unicorn.conf.rb
Environment=BUNDLE_GEMFILE=/var/www/rails/myapp/Gemfile
EnvironmentFile=/etc/environment

ExecStart=/bin/bash -l -c 'bundle exec unicorn_rails -c ${UNICORN_CONF} -E ${RAILS_ENV} -D'
ExecStop=/usr/bin/kill -QUIT $MAINPID
ExecReload=/usr/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

```

参考にしたサイト：
[Amazon Linux 2 で unicorn を systemd を使って立ち上げる](https://qiita.com/piggydev/items/50f8d9d958f42445493f)

###発生事象
Unicronが起動せず、ログは以下の通りとなっております。
```lang-text
● unicorn.service - The unicorn process
   Loaded: loaded (/etc/systemd/system/unicorn.service; disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since 木 2020-11-19 22:03:24 JST; 1h 22min ago
  Process: 29782 ExecStop=/usr/bin/kill -QUIT $MAINPID (code=exited, status=1/FAILURE)
  Process: 29382 ExecStart=/bin/bash -l -c bundle exec unicorn_rails -c ${UNICORN_CONF} -E ${RAILS_ENV} -D (code=exited, status=0/SUCCESS)
 Main PID: 29382 (code=exited, status=0/SUCCESS)

11月 19 22:03:24 xxx.compute.internal systemd[1]: Unit unicorn.service entered failed state.
11月 19 22:03:24 xxx.compute.internal systemd[1]: unicorn.service failed.
11月 19 22:03:24 xxx.compute.internal systemd[1]: unicorn.service holdoff time over, scheduling restart.
11月 19 22:03:24 xxx.compute.internal systemd[1]: start request repeated too quickly for unicorn.service
11月 19 22:03:24 xxx.compute.internal systemd[1]: Failed to start The unicorn process.
11月 19 22:03:24 xxx.compute.internal systemd[1]: Unit unicorn.service entered failed state.
11月 19 22:03:24 xxx.compute.internal systemd[1]: unicorn.service failed.
```

###質問
ログから、ExecStop=/usr/bin/kill -QUIT $MAINPID (code=exited, status=1/FAILURE)で失敗していると思われますが、原因や対応方法が分からず困っております。
ご支援のほど、よろしくお願いいたします。

※前提として、systemdを使わず、ワーキングディレクトリで直接`bundle exec unicorn_rails -c /var/www/rails/myapp/config/unicorn.conf.rb -D -E production`コマンドを入力し、Unicornが起動することは確認済みです。

###試したこと#1
環境変数を使用せず、unicornの再起動は実施しないようunicorn.serviceファイルを以下の通り変更。

```
[Unit]
Description=The unicorn process
After=network.target remote-fs.target nss-lookup.target
Before=nginx.service

[Service]
User=myname
WorkingDirectory=/var/www/rails/myapp
SyslogIdentifier=unicorn
Type=simple

ExecStart=/bin/bash -l -c 'bundle exec unicorn_rails -c /var/www/rails/myapp/config/unicorn.conf.rb -E production -D'
ExecStop=/usr/bin/kill -QUIT $MAINPID
ExecReload=/usr/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target
```

実行したところ、Unicornは起動せず、ログは以下の通り。
```lang-text
● unicorn.service - The unicorn process
   Loaded: loaded (/etc/systemd/system/unicorn.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 金 2020-11-20 11:23:04 JST; 36s ago
  Process: 6590 ExecStop=/usr/bin/kill -QUIT $MAINPID (code=exited, status=1/FAILURE)
  Process: 6190 ExecStart=/bin/bash -l -c bundle exec unicorn_rails -c /var/www/rails/myapp/config/unicorn.conf.rb -E production -D (code=exited, status=0/SUCCESS)
 Main PID: 6190 (code=exited, status=0/SUCCESS)

11月 20 11:23:03 xxx.compute.internal systemd[1]: Started The unicorn process.
11月 20 11:23:03 xxx.compute.internal systemd[1]: Starting The unicorn process...
11月 20 11:23:04 xxx.compute.internal unicorn[6590]: kill: not enough arguments
11月 20 11:23:04 xxx.compute.internal systemd[1]: unicorn.service: control process exited, code=exited status=1
11月 20 11:23:04 xxx.compute.internal systemd[1]: Unit unicorn.service entered failed state.
11月 20 11:23:04 xxx.compute.internal systemd[1]: unicorn.service failed.
```

unicorn.serviceのジャーナル。
```
(・・・中略・・・)
11月 20 10:44:15 xxx.compute.internal unicorn[5569]: kill: not enough arguments
11月 20 10:44:17 xxx.compute.internal unicorn[5972]: kill: not enough arguments
11月 20 11:23:04 xxx.compute.internal unicorn[6590]: kill: not enough arguments
11月 25 09:48:42 xxx.compute.internal unicorn[16521]: kill: not enough arguments

```

###試したこと#2
unicorn.serviceファイルにおいて、依存関係や、ExecStop、 ExecReloadを削除し、ExecStartのみのシンプルな内容で実行。
```
[Unit]
Description=The unicorn process

[Service]
User=myname
WorkingDirectory=/var/www/rails/myapp
SyslogIdentifier=unicorn
Type=simple

ExecStart=/bin/bash -l -c 'bundle exec unicorn_rails -c /var/www/rails/myapp/config/unicorn.conf.rb -E production -D'

[Install]
WantedBy=multi-user.target
```

これまでと異なるログを得られたが、依然としてUnicronは起動せず、原因不明。
```
● unicorn.service - The unicorn process
   Loaded: loaded (/etc/systemd/system/unicorn.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

11月 25 09:48:40 xxx.compute.internal systemd[1]: Started The unicorn process.
11月 25 09:48:40 xxx.compute.internal systemd[1]: Starting The unicorn process...
11月 25 09:48:42 xxx.compute.internal unicorn[16521]: kill: not enough arguments
11月 25 09:48:42 xxx.compute.internal systemd[1]: unicorn.service: control process exited, code=exited status=1
11月 25 09:48:42 xxx.compute.internal systemd[1]: Unit unicorn.service entered failed state.
11月 25 09:48:42 xxx.compute.internal systemd[1]: unicorn.service failed.
11月 25 10:04:26 xxx.compute.internal systemd[1]: Started The unicorn process.
11月 25 10:04:26 xxx.compute.internal systemd[1]: Starting The unicorn process...
11月 25 11:23:00 xxx.compute.internal systemd[1]: Started The unicorn process.
11月 25 11:23:00 xxx.compute.internal systemd[1]: Starting The unicorn process...
```

unicorn.logの内容は以下の通り。
```
I, [2020-11-25T09:48:41.677152 #16516]  INFO -- : Refreshing Gem list
I, [2020-11-25T09:48:42.436156 #16516]  INFO -- : unlinking existing socket=/var/www/rails/myapp/tmp/sockets/.unicorn.sock
I, [2020-11-25T09:48:42.436349 #16516]  INFO -- : listening on addr=/var/www/rails/myapp/tmp/sockets/.unicorn.sock fd=9
I, [2020-11-25T09:48:42.469695 #16516]  INFO -- : master process ready
I, [2020-11-25T09:48:42.477058 #16520]  INFO -- : worker=1 ready
I, [2020-11-25T09:48:42.478356 #16519]  INFO -- : worker=0 ready
I, [2020-11-25T09:48:42.583104 #16516]  INFO -- : reaped #<Process::Status: pid 16519 exit 0> worker=0
I, [2020-11-25T09:48:42.583221 #16516]  INFO -- : reaped #<Process::Status: pid 16520 exit 0> worker=1
I, [2020-11-25T09:48:42.583295 #16516]  INFO -- : master complete
```

###試したこと#3
ExecStartのパスを/bin/bashからワーキングディレクトリ（/var/www/rails/myapp）に変更して実行。
```
[Unit]
Description=The unicorn process

[Service]
User=myname
WorkingDirectory=/var/www/rails/myapp
SyslogIdentifier=unicorn
Type=simple

ExecStart=/var/www/rails/myapp 'bundle exec unicorn_rails -c /var/www/rails/myapp/config/unicorn.conf.rb -E production -D'

[Install]
WantedBy=multi-user.target
```
権限エラー発生してしまう。
```
systemd[19988]: Failed at step EXEC spawning /var/www/rails/myapp: Permission denied
```
コマンドラインから、同ディレクトリ・同コマンドを入力してUnicornが起動することは確認済みにも関わらず、上記エラーが発生してしまう。
なお、同ディレクトリには実行権限が付与されていることも確認済みであり、エラー発生原因が不明。
```
drwxrwxr-x 15 myname myname 4096 11月  3 13:12 myapp
```

Amazon Linux2で、systemdを使ってUnicornを起動したい

* AWS EC2上で、railsをpumaで本番稼働しています。

* EC2はauto scalingで2つのインスタンスを起動しており、ユーザーがドメイン(例: https://abc.jp)にアクセスするとそのインスタンスのうちどちらかにアクセスが割り振られます。

* 一定時間経つと（約3日ぐらい）メモリがいっぱいになってOOMキラーが動き、railsが落ちるので、OOMキラーが動いたタイミングで
`/etc/sysctl.conf`の設定でインスタンスが再起動するようにしています。

* ユーザーがサイトを訪問して、ページ内のフォームに入力後、送信ボタンを押した瞬間にメモリがいっぱいになり、OOMキラーが動いた場合、ユーザーが入力した内容はもう1つのインスタンスに渡されて、ページは表示されるのでしょうか？

なにぶん経験が浅く、railsをauto scalingで稼働させるには、普通どうやるのかの方法をよく分かっておりません

* ユーザーがアクセス中にOOMキラーが起こった場合は、フォームに入力していた内容はどうなるのか。どうすれば入力の送信完了まで担保できるのか

* こういった時はどう対処するのが普通なのか

* [puma_worker_killer](https://github.com/schneems/puma_worker_killer)
というのは、READMEを読む限り使わない方がいいように見えるが、実際はどうなのか


を教えていただきたいです。


よろしくお願いします。

参考サイト： [https://jp.quora.com/purodakushon-no-Rails-sa-ba-no-riyou-memori-ga-hitasura-zouka-shi-tei-ku-you-na-kyodou-wo-kansoku-shita-toki-dou-taiou-suru-no-ga-yoi-desu-ka](https://jp.quora.com/purodakushon-no-Rails-sa-ba-no-riyou-memori-ga-hitasura-zouka-shi-tei-ku-you-na-kyodou-wo-kansoku-shita-toki-dou-taiou-suru-no-ga-yoi-desu-ka)

【rails】メモリ断片化の対処法を知りたい

###前提・実現したいこと
ここに質問したいことを詳細に書いてください
AWS でAuto Scallingを使用し、自動スケールアウト、スケールインしたい。

###発生している問題・エラーメッセージ
Cloud Watch上でもCPU使用率は100%付近となっており、スケールアウト条件に到達しているはずではあるのですがスケールアウトしないという状況です。
![イメージ説明](961329af1c14e252b5fab1d39839541b.png)

###試したこと
[AWS EC2 Auto Scaling オートスケーリングの設定](https://sys-guard.com/post-11684/)
こちらのページを参考に設定しました。
ただし、Application Load Balancerではなく、Classic Load Balancerを使用していますので、その点は変更しています。

Auto Scallingグループを作成した時に、EC2が1台起動しますが、yes > /dev/null でそのEC2インスタンスにCPUに負荷をかけ、Cloud Watch上で100%付近になっており、スケールアウト条件に到達しているはずではあるのですがスケールアウトしません。Auto Scallingのアクティビティ履歴を見ても、新たにEC2インスタンスを起動しようとしている履歴はありません。手動でターゲットグループの希望数を変更すればスケーリングはうまく行っています。

スケーリングポリシー等はこちらです。↓

ターゲットグループ
希望:1
最小:1
最大:3

ヘルスチェックのタイプ
EC2
ヘルスチェックの猶予時間
300sec

Decrease Group Size
ポリシータイプ:ステップスケーリング
次の場合にポリシーを実行:アラート名
アラームしきい値を超えました: CPUUtilization <= 30（連続する 3600 秒 x 1）
アクションを実行:削除 1 インスタンス	
次の条件の場合 30 >= CPUUtilization > -無限大

Increase Group Size
ポリシータイプ:ステップスケーリング
次の場合にポリシーを実行:アラート名
アラームしきい値を超えました: CPUUtilization >= 80（連続する 300 秒 x 1）
アクションを実行:追加 1 インスタンス	
次の条件の場合 80 <= CPUUtilization < +無限大
インスタンスは: 300 秒のウォームアップが各ステップ後に必要です

AWSのAutoscalling設定 スケールアウトしない

Rails初心者エンジニアです。
WebアプリのプロトタイプをAWS上にデプロイ・運用していく予定で、本番環境の構築を進めております。

###実現したいこと
EC2上のWebアプリの可用性を維持（インスタンス数１台を維持）するため、AWS EC2 Auto Scalingでサーバーを自動復旧する設定をしたい

###実施内容
0. EC2で立てたインスタンス（インスタンスタイプ：t2.micro, ストレージ：8G）からAMIを作成
0. 上記1で作成したAMIを使用し、起動設定を作成（インスタンスタイプ、ストレージ、セキュリティグループなどの設定は1と同じ。自動起動したインスタンスにも同じ鍵でSSHログインしたいため、既存のキーペアを選択。）
0. 上記2の起動設定を使用してAuto Scalingグループを作成

**Auto Scalingグループの設定内容**
```

・グループサイズ : 希望する容量1、最小キャパシティ1、最大キャパシティ1
・サブネット ： 既存のEC2インスタンスと同じものを選択
・ロードバランシング : チェックを入れ、ターゲットグループを選択
・ヘルスチェックのタイプ : EC2 & ELB
・ヘルスチェックの猶予期間 : 300
・インスタンスのスケールイン保護 : 保護なし スケールインから
・終了ポリシー : Default
・デフォルトのクールダウン : 300

```

###発生事象
EC2インスタンス（キャプチャのstart-aws-instance）に問題が無いにも関わらず、Auto Scallingによって、インスタンスの自動生成・終了が約8分毎に繰り返されてしまう。

**インスタンス一覧**
![イメージ説明](aef7429f6a43b373856ecd55b69cdda4.png)

**ELBのターゲット一覧（Auto Scalingのヘルスチェックがhealthyとならない）**
![イメージ説明](2848268833489530adff10bba94b917b.png)

**Auto Scalingグループのアクティビティ履歴（約8分毎にインスタンスの起動・終了を繰り返している）**
![イメージ説明](01cdb3fa70807c0a08ea03fcc0206b40.png)

**ポート状態の確認結果**
```unhealty
Netid   State     Recv-Q    Send-Q                         Local Address:Port         Peer Address:Port     
udp     UNCONN    0         0                                  127.0.0.1:323               0.0.0.0:*        
udp     UNCONN    0         0                                    0.0.0.0:68                0.0.0.0:*        
udp     UNCONN    0         0                                    0.0.0.0:111               0.0.0.0:*        
udp     UNCONN    0         0                                    0.0.0.0:728               0.0.0.0:*        
udp     UNCONN    0         0                                      [::1]:323                  [::]:*        
udp     UNCONN    0         0             [fe80::89d:beff:fed1:a24]%eth0:546                  [::]:*        
udp     UNCONN    0         0                                       [::]:111                  [::]:*        
udp     UNCONN    0         0                                       [::]:728                  [::]:*        
tcp     LISTEN    0         128                                  0.0.0.0:22                0.0.0.0:*        
tcp     LISTEN    0         100                                127.0.0.1:25                0.0.0.0:*        
tcp     LISTEN    0         128                                  0.0.0.0:111               0.0.0.0:*        
tcp     ESTAB     0         36                             172.31.11.230:22          60.60.230.194:51511    
tcp     LISTEN    0         128                                     [::]:22                   [::]:*        
tcp     LISTEN    0         128                                     [::]:111                  [::]:* 
```
```healty
Netid    State         Recv-Q     Send-Q                            Local Address:Port          Peer Address:Port     
udp      UNCONN        0          0                                     127.0.0.1:323                0.0.0.0:*        
udp      UNCONN        0          0                                       0.0.0.0:68                 0.0.0.0:*        
udp      UNCONN        0          0                                       0.0.0.0:111                0.0.0.0:*        
udp      UNCONN        0          0                                       0.0.0.0:727                0.0.0.0:*        
udp      UNCONN        0          0                                         [::1]:323                   [::]:*        
udp      UNCONN        0          0               [fe80::884:abff:fe94:f3e4]%eth0:546                   [::]:*        
udp      UNCONN        0          0                                          [::]:111                   [::]:*        
udp      UNCONN        0          0                                          [::]:727                   [::]:*        
tcp      LISTEN        0          128                                     0.0.0.0:111                0.0.0.0:*        
tcp      LISTEN        0          128                                     0.0.0.0:80                 0.0.0.0:*        
tcp      LISTEN        0          128                                     0.0.0.0:22                 0.0.0.0:*        
tcp      LISTEN        0          100                                   127.0.0.1:25                 0.0.0.0:*        
tcp      TIME-WAIT     0          0                                  172.31.14.50:80           172.31.28.107:60516    
tcp      ESTAB         0          36                                 172.31.14.50:22           60.60.230.194:51517    
tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34352    
tcp      TIME-WAIT     0          0                                  172.31.14.50:80           172.31.28.107:60502    
tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34362    
tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34376    
tcp      LISTEN        0          128                                        [::]:111                   [::]:*        
tcp      LISTEN        0          128                                        [::]:80                    [::]:*        
tcp      LISTEN        0          128                                        [::]:22                    [::]:*       
```


###質問
インスタンス乱立の要因は、Auto Scalingのヘルスチェックが上手くできてないことと想定しておりますが、詳細分かっておらず困っております。
EC2インスタンス（キャプチャのstart-aws-instance）に問題が生じた場合のみ、Auto Scalingで1台のサーバーを自動復旧するようにしたいのですが、発生事象の原因と対処法について、アドバイスいただきたく、よろしくお願いいたします。