spot인스턴스가 자주 죽는 문제를 해결하기 위해 토론을 하다가, 시간이 지나 잘못된 선택인 것을 깨달은 이야기

추석이 끝나고 출근 후, 팀원과 재밌는 토론을 했습니다. 

 

1. 토론을 시작한 이유

개발환경은 비용을 절약하기 위해 EKS 인스턴스를 spot타입으로 사용하고 있습니다. 그런데, 개발자님이 최근 spot인스턴스가 너무 자주 종료되어 테스트 중 세션이 자꾸 끊기고 세션을 다시 붙는데 시간이 조금 걸린다고 문의를 주셨습니다. 그리고  replica 2개로 증가시켜달라고 요청했습니다.

 

2. EKS 환경

EKS spot 인스턴스는 karpenter로 관리되고 있었습니다. 그리고 spot 인스턴스에 있는 pod가 갑자기 종료되는 것을 막기 위해 NTH(Node Termination Handler)로 drain node를 미리하고 있었습니다.

 

3. 토론 시작

개발자님의 의견과 함께 저, Y님, K님이 여러 가지 후보 중에 장/단점을 이야기하고 선택을 하기로 했습니다. 

 

후보 목록

1. spot 인스턴스 개수를 2개로 증가
2. on-demand 인스턴스를 사용하여 높은 스펙을 선정하여 자원 파편화 최소화
3. 인스턴스를 on-demand: spot1:N 비율로 사용
4. 세션이 왜 자주 끊기는 지 원인 파악

 

개발환경에서 spot인스턴스를 사용한 목적이 비용을 아끼는 거여서 on-demand는 되도록 사용하고 싶지 않았습니다. 그래서 후보 2번, 3번은 우선순위를 낮췄습니다.

 

남은 후보는 1번 4번이 있었습니다. 저는 spot인스턴스 개수를 늘려봤자 spot인스턴스가 있기 때문에 같이 종료될 확률이 높아 지금과 달라질게 없다고 의견을 말했습니다. 

 

그래서 남은 후보인 4번을 선택하게 되었는데 시간이 지나서 4번이 잘못된 선택이라는 것을 알았습니다.  따라서 1번후보를 최종적으로 선택하고 시간이 지속되면 2,3번 후보 중 한개를 선택하는걸로 결론을 지었습니다.

 

4. 왜 4번 후보가 잘못된 선택이었을까?

시간이 지나서 왜 4번 후보가 잘못 되었다는 것을 알았을까요?

 

정답은 pod replica가 1개이면서 NTH의 특징때문입니다.

 

NTH는 spot인스턴스 종료를 2분전에 미리 받아 drain node를 수행합니다. drain node는 pod를 안전하게 종료하기 위해 evict API를 호출합니다. 이 때, pod replica는 1개이기 때문에 개발자님이 테스트 중에 자주 세션이 끊겼던 겁니다. evict API를 받은 pod는 종료되고 노드가 없어 pending상태가 됩니다. 곧이어 karpenter는 pending이벤트 때문에 노드를 생성하고 pod를 스케쥴링합니다.

 

정리하면 애초에 replica가 1개이기 때문에 4번 후보는 선택하지 않아도 될 문제였습니다. 그리고 NTH가 evict API를 호출한다는 내부 동작도 잠시 잊고 있었습니다. 저희가 잠깐 4번 후보를 선택했던 것은 여기서 다루진 않지만 pod부팅시간이 느리다는 것에 정신이 팔려 근본적인 원인을 놓쳤습니다.