結論
下記のようにECSのコンテナメモリとCPUユニット数を変更したら直った
- コンテナメモリ：300MiB → 1024MiB
- コンテナCPU：500 → 512ユニット数
(フリー画像です)
事象
- コンテナに入ってRailsコマンドを叩くとコンテナが落ちる
- 502 Bad Gatewayで画面表示さえされない時もあった
- なぜか本番環境では落ちてなかった
- ステージング環境だけ落ちてた → ECSのインスタンスが落ちては自動立ち上げの無限ループ
- Rails 6系にバージョンアップするとステージング環境の画面も表示されるようになった
- 相変わらずRailsコマンドを叩くとコンテナは落ちた
EC2のインスタンスタイプ
- 本番環境：m4.large
- ステージング環境：t3.large
参考資料
試したことメモ
- Railsコマンドテスト
-
rails -vは問題なかった。ほかRailsコマンドはダメなのでRailsアプリ内のスクリプトが動くとだめなのかも? - spring killしてRailsコマンド実施
- springを起動しない設定の
DISABLE_SPRING=1を環境変数に設定してRailsコマンド実施 - 直接指定 →
$ DISABLE_SPRING=1 RAILS_ENV=staging ./bin/rails console - 環境変数とか見直し
- Railsバージョンを上げてみた
- Railsコマンドが走ってた場所まで戻して試してみた
- topで実行プロセス見てみた → springじゃね?に繋がる
- タスク定義の不要なやつを削除してみた
- ほかAWSで紐づけている設定見直し
- ECSのメモリ制限をハード制限・ソフト制限ともに3000MiBに設定
まとめ
多分ECSコンテナの要領不足。な気がします。
メモリよりCPUユニット数の方が決定打でした。
EC2のインスタンスタイプも適当に設定しちゃダメだと痛感しました。
インフラ周り疎いので詳しい方いたら教えてください。
余談
ちなみにコンテナCPUを500 → 1024に設定するとタスク定義が更新できなくなってしまった。
適切なユニット数を設定するのが大事みたい。
→ CPU1024MiBにすると、ECS常時2インスタンスだとして、切り替えのタイミングで2→4になり1024MiB*4が要求されて要領を超えてしまってた