1.
AWS Amplify + Nextjs 를 이용해 프론트 서비스를 하고 있다. Amplify를 알고 나서, 아니 이렇게 편한 서비스가? IT 인력이 적은 스타트업에서 이만한 서비스가 없다고 생각했다. 거기다 AWS에서 운영하는 서비스이니 믿고 쓸 수 밖에. 그렇게 1년을 넘게 개발하고 테스트하고 배포해 봤다. 다시는 Amplify를 쓰지 않겠다는 다짐만 남았다.
2.
Amplify를 쓰면서 발견한 문제점들이다.
- 콜드 스타트 문제
- 성능 모드 활성화 시 캐시 초기화를 못 하는 문제
- 다이나믹 IP로 생성돼 통제가 어려움
- 이용자가 많지 않아 레퍼런스가 적음
- AWS에서 활발히 지원 안 함
- 디버깅이 불가
3.
# 콜트 스타트 문제
- 프론트 사이트의 첫 접속자는 몇초간의 로딩이 걸린다. 3~5초, 많이 걸리는 곳은 10초 이상도 걸린다고 한다. 누군가 접속하고 나면 그 다음부터는 빠르게 접속된다. 하지만 대략 5~10분 정도 아무도 접속 안 하고 다시 접속하면 3~5초 로딩이 걸린다. 전형적인 콜드 스타트 문제.
- 프론트 첫 페이지가 이러면 서비스 못 한다. github의 Amplify 페이지 이슈에 관련 내용도 있고 끊임없이 컴플레인이 들어오고 있지만 AWS측의 답변은 해당 문제를 손 보고 있다는 것 뿐. 그게 몇 년째이다. 올해 AWS측의 관련 문제를 해결했다는 답변이 달렸지만 해결되지 않았다.
- 현재 서비스 중인 프론트는 관련 문제를 해결했다. 방법은 프론트 번들 사이즈를 줄인 것. MUI 같은 컴포넌트 서비스들은 번들 용량을 꽤 차지하기도 하고 이것저것 패키지를 설치하다 보면 용량은 금방 커진다. 번들 사이즈를 줄이니 콜드 스타트 문제는 확 줄었다. 4~5초 걸리던 로딩 속도가 1초 미만이다.
- 최초에 서비스는 죽어있고 사이트 접속하면 그때 환경 구성하고 패키지 다운받고 프론트 서비스 준비를 한다. 다운 받아야 할 패키지가 많고 용량이 크다면 오래 걸릴 수 밖에 없다. 최대한 번들을 작게 유지해야 백그라운드 과정에서 시간을 뺏기지 않는다. 우리회사 서비스는 간단해서 번들 줄이는게 쉬웠지만 안 그런 회사도 있을 것이다.
- 콜드 스타트 문제를 해결하기 위한 다른 방법이 사이트에 주기적으로 접속하는 것이다. 그런데 ping만 날리거나 단순히 페이지만 긁어가는 식으로는 콜드 스타트 해결이 안 된다. 아마 캐시가 응답을 하기 때문인 것 같다.
- route53의 dns health check 라는 서비스가 있는데 이걸로는 안 된다. aws event bridge → lambda → 서비스 를 호출하는 방식으로 처리했는데 이때 lambda에서 호출할 때 쿼리 스트링으로 날짜+시간 값 같은 것을 붙여 캐시를 우회하도록 해야 한다. 이렇게 주기적으로, 1~5분 사이로 계속 호출을 시키면 콜드 스타트 문제에 어느정도 대응은 된다.
4.
# 성능 모드 활성화 시 캐시 초기화를 못 하는 문제
- Amplify 설정에 성능 모드라는게 있다. 캐시를 활성화해주는 모드이다. 그런데 이게 문제다. 서비스를 짧은 간격으로 배포하다 보면 어느 순간부터 사이트가 꼬인다. 캐시에서 이전 버전의 번들 파일을 불러오려고 하고 그럼 파일이 없으니 사이트가 깨진다.
- 특수한 경우에 나타나는데 브라우저에서 캐시 삭제를 하고 나면 이런 현상이 발생한다. 그리고 어느정도, 약 12시간 정도의 시간이 지나면 캐시가 초기화되고 정상화 된다.
- 캐시를 초기화하는 부분이 있으면 되는데 Amplify에는 그런 부분이 없다. Amplify가 사용한다는 cloudfront를 아무리 뒤져봐도 캐시를 초기화할 수 있는 부분이 없다. (서울 리전만 안 보이는 것일 수도)
- 배포하고 나서 사이트가 꼬이면 마냥 기다리는 수밖에 없다. 아니면 사이트 url에 강제로 쿼리 스트링을 붙여 캐시를 안 타게 해야 한다. 배포가 잦다면 차라리 성능 모드를 끄고 쓰는게 낫다.
5.
# 다이나믹 IP
- 프론트를 Amplify로 쓰고 백엔드에서 프론트 IP로 접근 제약을 건다고 하면 방법이 없다. Amplify는 다이나믹 IP로 생성되서 IP를 특정지을 수 없다.
- AWS 내에서 VPC로 네트워크를 나눠도 Amplify는 어디 포함시키기가 힘들다. 통제가 어렵다.
6.
# 레퍼런스 부족
- 의외로 Amplify 이용자가 많지 않고 그래서 레퍼런스도 적다. 인터넷에 레퍼런스가 적으면 ChatGPT도 해결 못 해준다. 문제가 생기면 스스로 해결해야 한다.
7.
# AWS 지원 부족
- 이용자가 적어서 돈이 안 되니 AWS에서도 활발히 지원 안 해준다.
8.
# 디버깅이 불가
- 디버깅을 할 수가 없다. 배포하면 끝이다.
9.
- Amplify는 추천하지 않는다. 편하다는 장점말고 단점이 더 많은 서비스이다. 가볍고 간단하고 크리티컬하지 않은 서비스에 사용하는 건 나쁘지 않은 선택이지만 중요 서비스에 사용하는 건 못할 짓이다. 운영 인력이 부족해 편한 서비스를 써야 한다면 차라리 Elastic Beanstalk를 쓰자.
10.
- 추가로 Amplify의 콜드 스타트 문제로 검색하다 보면 Vercel의 호스팅 서비스를 써서 문제를 해결했다는 글이 많다. 그래서 동일한 서비스를 Vercel에 올려놓고 써 봤는데 콜드 스타트 문제가 Amplify 보다 더 심했다.
- Vercel을 써서 해결했다는 글은 Vercel 직원들이 쓴게 아닐까 합리적 의심 중. AWS도 해결 못 하는 콜드 스타트 문제를 Vercel이 해결했을리 없다. 상식적으로 말이 안 된다.
- Amplify의 대안이 Vercel은 아니다.
