Why my AWS EC2 Spot Instance terminate?

회사나 개인 프로젝트를 진행할 때 AWS를 이용할 일이 많았다. (회사의 경우 과거형)

특히, 서비스 중에서 EC2를 사용할 일이 많았는데 타사 대비 비싼 금액 때문에 좀 망설여 지는 부분이 있었다.

근데.. AWS에서 내 마음을 알았는지 Spot Instance 라는 친절한 요금 플랜을 만들어 주었다.

그래서 이 플랜으로 신나게 돌리고 있었는데! 왜! 갑자기 내 서버가 꺼지는가…?

그 궁금증에서 시작해 써본 글이다.

Spot Instance?

AWS EC2 에서는 아래와 같은 여러 요금 플랜을 제공하고 있다.

• On-demand
  • 제일 일반적인 요금 플랜
  • 별도의 설정 없이 생성하게 되면 이 옵션을 선택하게 됨
  • “사용한 만큼 지불한다” 의 정석
• Spot Instance
  • AWS에서 남는 인스턴스 자원을 활용하는 방식
  • AWS 전체 EC2 자원 중 On-demand 로 팔고 남은 자원을 싸게 파는 원리
  • KTX의 입석 열차 좌석표와 주식 거래랑 비슷하다고 생각하면 편하다
  • on-demand 대비 최대 90% 저렴한 가격으로 제공 (출처: AWS)
• Saving Plan
  • 사용량을 약정해서 결제하는 방식
  • 인스턴스 패밀리, AZ, OS에 관계 없이 적용할 수 있음
  • 1 ~ 3년 단위 계약 방식
• Reserved Instance
  • 1 ~ 3년 단위로 서버를 계약 방식
  • 인스턴스 패밀리, AZ, OS를 지정하여 계약해 함

이 중에서 스팟 인스턴스에 대해 설명하고, 왜 termination에 대해 고려하게 되었는지 글을 써 보도록 하겠다.

Spot Instance Mechanism

우선, 스팟 인스턴스의 기본적인 작동 구조에 대해 알아 보도록 하자.

무엇인가를 알아보기엔 AWS 공식 페이지가 짱이다. (번역기적 말투만 제외하면..)

여러 부분이 있지만 전체적인 구조는 원래 우리가 알던 EC2와 다른 점은 크게 없다.

대신 중요한 점은 이 서버는 우리가 잠시 빌린 것 뿐 이라는 것과 언제든지 AWS에 의해 서버가 반납될 수 있다라는 점은 알고 있어야 한다.

이 이유는 위에서 KTX의 입석 열차 좌석표 와 주식 거래로 비유 했는데 그 이유는 스팟 인스턴스를 이용하여 구매한 EC2는 KTX의 입석 열차 표라서 다른 On-demand 사용자가 나타나거나 스팟 인스턴스를 위한 자리가 없을 경우 자리를 비워 줘야 하기 때문이다 (=서버를 사용할 수 없기 때문).

AWS 에서는 이 방식을 경매 방식이라고 하는데 더 높은 비용을 지불하는 사람 순으로 스팟 인스턴스로 남은 리소스 (잉여 리소스) 를 배정하기 때문이다.

이 방법 말고도 1시간, 6시간 단위로 스팟 블록을 생성할 수 있는데 이는 특정 시간만 쓰고 자동적으로 버리고 싶은 사람에게 적절한 과금 방식이다. 이 블록 기간에는 termination 걱정 없이 사용할 수 있다.

Cause of termination

AWS 측에서 termination 되는 이유에 대해 아래와 같이 설명하고 있다.

• 가격 – 스팟 가격이 최고 가격보다 큽니다.
• 용량 – 미사용 EC2 인스턴스가 온디맨드 인스턴스 수요를 충족할 만큼 충분하지 않으면 Amazon EC2에서 스팟 인스턴스를 중단합니다. 인스턴스가 중단되는 순서는 Amazon EC2에서 결정됩니다.
• 제약 조건 – 요청에 시작 그룹 또는 가용 영역 그룹과 같은 제약 조건이 포함되는 경우 제약 조건을 더 이상 충족할 수 없으면 이러한 스팟 인스턴스가 그룹으로 종료됩니다.

[출처: AWS EC2 Documentation - 한글본]

사실 저 말만 봐선 잘 모른다. 특히 AWS Documentation을 읽으면서 드는 느낌인데 차라리 영어를 읽는게 더 편할 정도니.. (심지어 영문과 한글이 다르거나 명시되지 않은 경우가 있어 조심해야 한다)

여튼 이걸 나름 쉬운 말로 해석 해 보면..

• 가격 - Spot에 현재 형성된 가격대가 당신이 제시한 최대 가격보다 큰 경우
• 용량 - 스팟 인스턴스로 사용될 서버가 없는 경우 (모두 다 on-demand로 빠지는 경우를 말한다)
• 제약 조건 - 시작 그룹이나 가용 영역 그룹으로 설정하여 스팟 인스턴스를 이용하는 경우 제약 조건 중 충족하지 못하는 부분이 있으면 그룹 전체가 자동으로 종료

가격

근데 사실 내가 일반적 으로 경험 했을 때 스팟 인스턴스가 termination 되는 일은 잘 없다. 그러나..

위 그래프는 서울 리전에서의 스팟 인스턴스 평균 가격이다. (4개의 AZ)

여기서 유난히 볼록 튀어나온 그래프가 보이지 않는가?..

바로..

크리스마스..

그렇다. 크리스마스가 되면 서버가 많이 필요하다 == on-demand에서 남는 리소스가 적어진다.

그 결과는…? 균형가격의 결정에 의해 스팟 인스턴스의 시장 가격이 자연스럽게 올라간다.

그리고 또 신기한 점은 다른 리전에서의 그래프다.

해당 그래프는 바레인 리전의 스팟 인스턴스 평균 가격이다.

바레인은 이슬람교가 국교이고, 이슬람은 성탄절이라는게 없어서 쉬는 날도 아니다.

그러니깐 서버 사용량이 급격히 늘어나는 것도 아니기 때문에 스팟 인스턴스의 가격 차이도 크지 않다.

(단, 주의해야 할 점은 바레인 리전은 아직 많이 사용하지 않기 때문에 비교하기엔 약간 무리가 있을 수 있다. 근데 다른 리전들은 다 크리스마스를 국경일로 하는 나라여서..)

여튼, 그래서 저 가격을 맞추지 못한 인스턴스는 자연스럽게 계약이 해지된다.

용량

사람들이 잘 사용하지 않는 인스턴스는 on-demand로 많이 설정해 두지 않는다.

c5.large (linux/unix) 의 경우 일반적으로 많이 쓰는 인스턴스니 on-demand로 배정해 두는 리소스가 많다.

그러나 일반적으로 잘 사용하지 않는 GPU 기반 인스턴스 (다들 쓰나..?) 같은 경우에는 상대적으로 on-demand 배정이 적게 된다고 한다.

이러한 이유 때문에 on-demand 공급 자체가 적어 스팟 인스턴스로 넘어오는 리소스 자체가 적거나 아예 없는 경우가 종종 있다.

이러한 이유 때문에 스팟 인스턴스가 종료되거나 아예 생성되지 못하는 경우도 있었다.

Conclusion

여튼 스팟 인스턴스를 사용하면서 겪어봤던 삭제 경험들에 대해서 간략하게 설명해 보았다.

사실 처음에는 왜 내 인스턴스를 맘대로 삭제 하는지 몰라서 갑질(?) 하나 싶었는데 이런 심오한 이유가 있었더라..

실제로 많은 일들을 겪고 나서 시작 구성에서 스팟 비용 산정할 때 조금은 여유롭게 잡게 되었다. (혹시 안되면 failover로 on-demand로 넘어가야 하니..)

그러나 여전히 스팟 인스턴스는 비싼 인스턴스를 사용할 수 없는 나같은 중생에게 좋은 정책이다.. ㅎ