커리어 피드

AWS 의 불안정성

 

(주) 글로우데이즈 / 18. 12. 04. 오후 2:49

AWS 는 서비스 개발에 있어 서버 운영의 부담을 줄여주고 생산성을 높힐 수 있습니다. 그래서 저희 글로우데이즈는 글로우픽 서비스를 개발 운영하는 데 AWS 에 대한 의존도를 높여가고 있습니다.

뿐만아니라 AWS 서비스 개발에 필요한 다양한 컴포넌트들을 지원하고 있어서 비교적 쉽게 그러한 컴포넌트들을 이용할 수 있게 해줍니다. 가령 memcached, redis 등의 in-memory cache 를 사용할 수 있도록 ElastiCache 를 지원하고, Elastic Search 나 Apache Spark 등 필요한 건 거의 다 있다 싶을만큼 다양합니다.

AWS 의 서비스 안정성은?

그런데 AWS 의 서비스 품질은 생각보다 안정적이지 않습니다. 대부분의 경우엔 AWS 위에서 개발한 어플리케이션의 문제를 먼저 의심해봐야 하겠지만, AWS 가 언제나 정상적으로 동작하는 건 아닙니다. 만일 이런 경우를 만나는 경우 대단히 많은 비용을 치루고 난 후에 발견하는 경우겠죠.

AWS 의 기술지원 엔지니어들은 SI 에서 흔히 말하는 "기술영업" 또는 "Delivery Engineer” 입니다. 기본적으로 AWS 의 솔루션을 홍보하고 도입하도록 하는 데 관심을 가지고 있지 사용중인 고객에게 발생한 문제를 해결하는 데 역량을 가지고 있는 인력들은 아닙니다. 보통 이런 경우 AWS 파트너사가 좀 더 현실적인 도움을 주는데 이들 또한 AWS 서비스 자체에서 발견된 이상한 문제들에 대해서는 잘 알지 못하고 속수무책이죠.

그러므로 사용자 커뮤니티 사이에서 서비스의 문제점을 공개적으로 지적하고 공유하는 게 필요해보입니다. 올해 한해동안 이상한 경험을 두번 했는데 여기 공유합니다.

AWS Batch

결론적으로 말하면 같은 Batch Job 이 약간의 시간차를 두고 두번 또는 세번씩 실행됩니다.


매시 실행되고 있는(starting) 배치작업 중 event_list 관련 작업이 2분 차 간격을 두고 두개 발견됨.


글로우픽 배치 작업은 crontab, django-crontab, spring-batch 등을 이용해서 실행되고 있었습니다. 그런데 배치 서버를 별도로 운영하는 등의 부담이 있어서 최근 Docker 기반으로 컨테이너화 하여 AWS ECR 에 등록한 후 AWS Batch + CloudWatch Event 로 실행하도록 했습니다.

그런데 위와 같이 짧은 시간 간격을 두고 두번 또는 세번씩 실행되는 경우가 지속적으로 발견되고 있습니다. 그리고 유독 한시간 간격으로 실행되도록 등록한 경우에만 문제가 발생합니다.

위 경우는 AWS 파트너사를 통해서 AWS 에 문의를 했으나 "그냥 그럴 수도 있다" 는 답변만 얻었습니다. 이로 인해 발생할 수 있는 서비스의 문제나 중복 비용부담도 "그럴 수 있는" 일인지, 그걸 판단하는 게 AWS 몫은 아닐텐데 말이죠.

AWS Aurora

하나의 클러스터로 묶인 DB 인스턴스의 parameter group 이 master 와 다른 경우 pending reboot 상태가 반복되며, pending reboot 상태인 노드로 로드가 몰리게 됨.

이 문제를 격었을 당시 master 한대와 세대의 read replica 를 rr, rr2, rr3 등의 postfix 를 붙여 Aurora cluster 를 구성하고 있었습니다. 푸시를 보낸 후 몰려드는 동시접속자를 버텨내지 못하고 서비스 품질이 떨어지는 상황이 반복되었더랬죠.



17:30경 푸시에 의해 rr, rr2, rr3 DB 로드가 100% 에 이르렀다가 내려가는 모습


위 그래프를 보면 rr 노드는 17:50경부터 로드가 내려가기 시작합니다. 그런데 rr2, rr3 는 그 이후로도 계속 100% 였다가 각각 18:05, 18:10 이 지나 로드가 내려갑니다. 클러스터의 로드밸런싱은 round robin 방식이므로 쿼리는 동등하게 분산되어야 할텐데 말입니다. 정말 로드밸런싱이 고루 되고 있을까요?



같은 시간대에 rr, rr2, rr3 의 분당 커넥션 수


같은 시간대 rr,rr2,rr3 의 커넥션 수를 보면 그렇지 않다는 걸 알 수 있습니다. rr3 저넥션 수는 뚝 떨어진 데 비해 rr2,rr3 는 계속 높은 수준을 유지하고 있는 걸 보면 DB 커넥션이 끊어지지 않고 남아있거나 rr2,rr3 에 상대적으로 많은 커넥션이 몰리는 문제가 있는 거겠죠.

DB 커넥션이 끊어지지 않고 있는 건 slow query 때문일 가능성도 있습니다. 그런데 slow query 가 rr 은 피해갔을 리가 없고, 이와 같은 문제가 여러차례 반복된 걸 보면 slow query 가 rr 만 피해가는 우연의 확률은 매우 작습니다.

slow query 가 아니어도 DB 에 대한 passive connection 이 유지되는 상태일 수도 있고, rr2, rr3 에 상대적으로 많은 커넥션이 몰리는 것일 수도 있습니다. 처음엔 후자의 문제로 생각하고 어플리케이션 구현을 살펴보고, route 53 의 로드밸런싱에 대해 확인해보는 등 장님 코끼리 다리 만지는 일을 계속할 수밖에 없었습니다.

그러다 이와 같은 문제가 rr2, rr3 에만 반복되자 rr2 와 rr3 노드가 pending reboot 상태라는 게 눈에 띄었습니다. 그래서 rr2 와 rr3 를 리부팅했고 그걸로 문제가 해결되는 줄 알았으나 rr2 와 rr3 는 어느시점부터 도로 pending reboot 상태로 바뀌게 되고 서비스 문제 또한 반복됐습니다.

결국 알아낸 건 master 와 rr 은 임의의 parameter group 을 지정한 데 반해 rr2, rr3 는 default parameter group 이 적용되어있는 차이점이 있다는 것이었습니다. 결국 rr2, rr3 인스턴스를 다시 만들어 parameter group 을 맞춰줬고 문제는 그렇게 해결됐습니다.

결론적으로 Aurora cluster 내 노드들이 parameter group 이 다른 경우 mater 와 다른 parameter group 이 적용된 노드들이 pending reboot 상태가 반복적으로 나타나고, pending reboot 상태의 노드는 서비스 로드가 몰렸을 때 비정상적으로 동작한다고 볼 수 있습니다.

결론

이러한 문제는 문제를 해결하는 과정에서 AWS 는 문제 진단에 도움이 되지 않았습니다. 어플리케이션에 문제가 있을 거라고만 생각하기 때문이죠. 파트너사 또는 AWS 에 문제를 리포트 한다 해서 고쳐졌다는 리포트를 받거나 사용자 커뮤니티에 문제가 공유되어 불필요한 에너지 낭비를 줄여주지도 않습니다.

아무래도 직접 서버를 운영할 때보다 드물게 발생하는 문제인 경우 원인 진단에서 대처까지 답답할 수밖에 없는 면이 있죠. 차라리 이용자 커뮤니티에서 이런 문제들이 공유되고 또 결국 AWS 에서 해결하는 걸 유도하도록 되었으면 하는 바람으로 글을 남깁니다.


#글로우데이즈 #개발자 #개발팀 #개발환경 #업무환경 #인사이트 #경험공유


관련 스택


모든 소비자가 신뢰할 수 있는 커머스플랫폼, 화장품 소비자들을 위한 가치 있는 정보를 제공하는 서비스로 발전하기 위해 끊임없이 '소비자의 목소리'를 경청 합니다.

팀 팔로우
© THE TEAMS - All rights reserved.

기업문화 엿볼 때, 더팀스

로그인

/