[AWS] EB 설정 팁

EB 구성 설정 시 주의 해야 할 것들을 정리해서 공유합니다.

EB 구성

소프트웨어

환경 속성 부분에 JAVA 옵션(JAVA_OPTS), 스프링 프로파일(SPRING_PROFILES_ACTIVE) 설정할 수 있습니다.

 

관련 속성을 소스 차원(ebextentions 파일들, spring.profiles.active 설정)에서 처리할 수도 있지만

EB 구성에서 설정하면 여러 환경이 있더라도 동일한 소스와 배포 프로세스를 가져갈 수 있다는 장점이 있습니다.

 

예를 들어 prod, dev 환경이 있는 경우 동일한 소스로 배포 배포하되 환경별로 사용하는 EC2 타입, 스프링 설정값들에 따라 JAVA 옵션, 스프링 프로파일만 다르게 해주면 됩니다. 

 

예시는 prod, dev 둘이지만 만약 환경이 prod, stage, qa, dev 등으로 더 많아진다면 이점은 더 커집니다.

인스턴스

디스크 FULL이 발생하지 않도록 넉넉히 디스크 용량을 설정해야 합니다.

 

디스크 용량 기본 설정이 낮은 편인데 그대로 두면 장애 상황 시 error, warn 로그가 막찍히면서 디스크 FULL이 되어 장애가 장애를 낳는 불상사가 생길 수 있습니다.

용량

이 부분은 각 서비스의 트래픽 패턴과 아키텍처에 따라 너무 달라 상세한 가이드를 드리기는 어렵습니다.

 

다만 CPU 기준으로 말씀 드리면 상위 임계값을 트래픽 변동성이 심한(갑자기 2~3배 트래픽이 들어올 수 있는) 서비스의 경우 40~50%, 트래픽 변동성이 적으면 60~70% 정도면 되지 않을까 합니다.

 

이 예시도 각 서비스마다 많이 다를 수밖에 없는데 처음에는 여유있게 했다가 점진적으로 타이트하게 바꾸어가면서 확인하는 것이 좋은 전략으로 보입니다. 예를 들어 CPU 기준으로 처음에 상위 임계값을 40%로 했다가 문제없는 것을 확인하면서 점진적으로 높여갈 수 있습니다.

 

인스턴스 수 조정 트리거 상위/하위 임계값 관련해서는 아래 2가지를 고려하면 좋습니다.

1) 최소 인스턴스 수에서 1회 증분이 되었을 때 하위 임계값 밑으로 바로 내려가지 않는지 확인

예) CPU 상위 임계값 50%, 하위 임계값 30%인 상황에서 CPU 50%가 되어 인스턴스 2->3대로 늘어났는데 바로 CPU 20%가 되는 경우

 

2) 인스턴스가 늘어날 때는 빠르게, 줄어들 때는 느리게

일반적으로 트래픽이 갑자기 늘어났을 때는 혹시 모를 추가 트래픽을 위해 한동안 여유 있는 상태를 유지하는 것이 좋습니다.

 

그래서 늘릴 때는 빨리 늘렸다가 줄어들 때는 느리게 줄어들도록 상위 임계값과 하위 임계값의 차이를 생각하는 것보다 조금 더 넉넉히 두는 것이 좋습니다.

롤링 업데이트와 배포

애플리케이션 배포와 구성 업데이트가 다르다는 것을 아는 것이 필요합니다.

애플리케이션 배포는 실제 소스 코드 배포와 관련된 설정이고 구성 업데이트는 가상 머신 설정과 VPC 구성 변경 시 동작 시에 대한 설정입니다.

 

예를 들어 blue/green 배포 시 애플리케이션 배포 설정은 한꺼번에 배포되도록 하겠지만 구성 업데이트 설정은 혹시 모를 인프라팀의 작업이나 자동 업데이트를 대비해 롤링 업데이트로 해 두는 것이 좋습니다.

모니터링

애매한 것이 상태 모니터링 규칙 사용자 정의 부분의 4xx와 관련된 설정인데 아래 사항을 참고할 수 있습니다.

1) 애플리케이션 4xx 무시: 활성 권장

대부분의 애플리케이션의 4xx(404) 등은 정상 응답으로 봐야 합니다.

4xx를 이상 응답으로 보면 외부 공격에 의해 의도하지 않게 정상 인스턴스가 로드밸런서에서 빠지게 될 수 있게 되면서 장애로 이어질 수 있습니다. 예) 404를 많이 발생시키는 크롤링

 

2) load balancer 4xx 무시: 상황에 따라 달라지지만 일반적인 사용케이스에서는 비활성 권장

WAF가 로드 밸런서와 연결되어 403이 다수 발생할 가능성이 있는 경우에 활성화 하지만 그렇지 않은 경우 기본값이 비활성이므로 굳이 활성시키지 않고 두는 것이 더 낫다고 봅니다.

 

기본값에서 변경할 때는 합당한 이유가 있어야 하기 때문입니다.

합당한 이유 없는 변경은 다른 작업자에게 뭔가 이유가 있지 않았을까 하는 혼란을 줄 수 있습니다.

 

상태이벤트를 CloudWatch Log로 스트리밍하는 것은 꼭 필요한 이유가 없다면 비활성하는 것을 권장합니다.

왜냐하면 로그 적재도 결국 돈이기 때문에 불필요한 로그는 적재하지 않아야 하기 때문입니다.

관리형 업데이트

의도하지 않은 업데이트가 일어나지 않도록 하기 위해 비활성 해 두는 것이 좋다고 생각합니다.