EC2의 사이즈를 small 정도로 운영하니 메모리가 99%가 뜨면서 결국 서버가 내려가게 되었던 이슈가 있었다. 해당 이슈는 nginx의 세팅을 해줘서 메모리 누수를 막아줘야하는 이슈라고 한다. 나는 아래 블로그를 보고 참고했는데, 해결방법이 다양하니 밑에 여러 방안을 작성해봤다. https://velog.io/@stay136/gunicorn%EA%B3%BC-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%88%84%EC%88%98 원인 1) gunicorn의 max connection을 지정 안해주면 default(4개)로 잡히는데, 연결 안끊고 클라이언트가 5개이상 붙어있으면 서버가 클라이언트 소켓 accept를 못하게되고 무한으로 pending 되게 되는 현상으로 메모리 누수현상이 일어나..
AWS/ElasticBeanstalk
github action을 하는데 AWS Elastic Beanstalk - (17) 에서 했던 ssh ec2접속에서 에러가 나타났다. 2023/02/27 11:40:45 dial tcp ***:22: i/o timeout 이런 에러였다. - name: SSH Commands uses: appleboy/ssh-action@v0.1.6 with: host: ${{ secrets.AWS_SSH_HOST_DEV }} username: ${{ secrets.AWS_SSH_USERNAME }} key: ${{ secrets.AWS_SSH_KEY }} script_stop: true script: | cd / cd /etc/nginx sudo sed -i nginx.conf -e '/http {/a\'$'\n'' ..
저번글에서 nginx.conf에 client_max_body_size 0; 이걸 자동적으로 넣는것을 githubaction을 통해 해보고자 한다. 우선 githubaction secrets에 비밀키를 만들어서 넣는다. 기존에 만든건 제외하고 AWS_SSH_USERNAME, AWS_SSH_KEY, AWS_SSH_HOST 만 만든다. # EB EC2 instance - AWS_SSH_USERNAME의 default 값은 ec2-user 입니다. - AWS_SSH_HOST는 EC2 서버 PUBLIC IP주소입니다. - AWS_SSH_KEY는 EC2 인스턴스를 생성할 때 발급받은 키입니다. 파일을 열어서 다 넣으시면 됩니다. 아래와 같이 넣어주면 된다. AWS_SSH_HOST는 위의 ec2 instance pu..
Elastic Beanstalk에서 ‘client_max_body_size’를 수정하도록 nginx 구성 해보자. 글에 정리를 했었는데 , AWS Elastic Beanstalk - (8) 이대로 하면 안되었었다. 작업과정 나도 image 업로드를 하는데 413 에러가 떴다. 이 에러는 이미지 사이즈가 너무 커서 default image limit를 넘었다는 것이다. 하지만 언제나 공식문서와 현실은 다른...(fail...) 어떻게 했었냐면 nginx를 구성하기 위해서 .platform > nginx > conf.d > client_max_body_size.conf 파일을 만들었다. 그리고client_max_body_size를 바깥에 넣었었다. 이제보니 server 안에 넣으면 되는것 같은데...? 그리..
A태그 서브도메인 -> CNAME 서브도메인으로 변경하기 기존에는 가비아에 A 태그로 ip를 넣어서 서브 도메인을 사용했던 방식이었다. 근데 ip를 넣어서 서브도메인을 사용하면, 로드밸런서에 의해서나 서버가 다운되었을 때나 ec2 instance의 ip가 바뀌게 된다. 그래서 그때마다 ip를 변경해줘야한다는 번거로움이 있다 오늘은 A 태그 서브도메인 -> CNAME 서브도메인 + Route53 으로 변경해보자. A태그 도메인명 EC2 public ip TXT _acme-challenge.서브도메인명 txt주소 이렇게 넣어져 있었다. 이걸 Cname으로 변경하자 그냥 교체만 하면 된다. 위처럼 CNAME 서브도메인명 elastic-beanstalk-url. 위처럼 넣어주고 뒤에 점을 붙여줘야한다. 그리고 ..
release 서버를 배포하려고 로드 밸런서를 수정하려고 할 때, 아래와 같은 에러가 발생했다. 도메인으로 들어가려고 하니까 아래 에러가 떴다. 우선 이 에러가 난 이유는 확실했다. Elastic Beanstalk로 배포하는데, Would you like to enable Spot Fleet requests for this environment? (y/N): y 위처럼 Spot Fleet을 Yes로 했기 때문이다. 솔직히 뭔지 몰랐다. 이게 auto scaling 인줄 알았는데, auto scaling은 저절로 설정을 해주는거고, 이건 다른 설정이었다. 우선 뭔지 몰라서 n라고하고 배포하니까 Dev 서버 배포할때처럼 정상적으로 되었다. https://spot.io/resources/aws-autoscal..
테스트 한 Elastic Beanstalk의 instance가 삭제가 안된다. 인스턴스 종료를 눌러봐도 자동으로 재시작이 되어버린다. [참고] https://aws.amazon.com/ko/premiumsupport/knowledge-center/ec2-instance-relaunched-after-termination/ 종료된 EC2 인스턴스가 다시 시작된 이유 확인 닫기 Mitu의 동영상을 통해 자세히 알아보기(4:05) aws.amazon.com 위의 글을 보면 auto scaling group 때문이라고 한다. 삭제가 된다.
서버를 마이그레이션하고 배포를 하는데, postman으로 호출되는 것이 아래와 같은 에러를 내뱉었다. 지금 보니까 에러가 4xx라고 나와있는데 왤케 빙빙 삽질했는지... Environment health has transitioned from Ok to Severe. 100.0 % of the requests are erroring with HTTP 4xx. Insufficient request rate (12.0 requests/min) to determine application health. ELB processes are not healthy on all instances. ELB health is failing or not available for all instances.우선 삽질 목록을 말하..
