Rails 명령을 두드리면 컨테이너가 떨어졌지만 ECS의 메모리와 CPU 설정을 변경하면 다시 이야기

결론

아래와 같이 ECS의 컨테이너 메모리와 CPU 유닛 수를 변경하면 고쳤다.

컨테이너 메모리 : 300MiB → 1024MiB

컨테이너 CPU: 500 → 512 유닛 수

( 무료 이미지입니다. )

사건

컨테이너에 들어가서 Rails 명령을 두드리면 컨테이너가 떨어집니다

502 Bad Gateway에서 화면 표시조차 되지 않을 때도 있었다

왠지 프로덕션 환경에서는 떨어지지 않았다

스테이징 환경 만 떨어졌다 → ECS 인스턴스가 떨어지면 자동 시작 무한 루프

Rails 6계로 버전 업하면 스테이징 환경의 화면도 표시되게 되었다

여전히 Rails 명령을 두드리면 컨테이너가 떨어졌습니다

EC2 인스턴스 유형

프로덕션 환경: m4.large

스테이징 환경:t3.large

참고 자료

잠시만 기다려주세요! 정말 사용해야 할 T 인스턴스가 있습니까?

ECS에서 EFS를 다루기위한 한 걸음으로 EC2 기반의 CPU와 메모리 설정을 시도했습니다.

시도한 메모

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가 요구되어 요령을 넘어 버렸다