EKS 통째로 재구성하기

인프라를 구성할 때는 항상 신중하게 계획하고 구성해야 합니다. 너무나도 당연하고 저도 계속 노력하고 있지만, 생각지도 못한 곳에서 문제가 터지기도 합니다.

지난 5월, IP 블록 충돌 문제로 인해 운영 환경 인프라를 통째로 재구성해야 했던 일이 있었습니다. 다행히도 K8s 환경을 본격적으로 이관하기 전이라 영향도가 크지 않았지만, 상당히 큰 작업이었습니다.

이번에는 이 과정에서 제가 겪은 시행착오와 그 과정에서 느낀 점을 적어보고자 합니다.

🚨 문제 발생

어느 때와 같이 회사 업무를 보고 있는데, 갑자기 멘션이 하나 왔습니다. 운영 환경에서 사용하던 EKS 클러스터의 IP 블록이 다른 곳의 IP와 충돌 위험이 있다는 것이었습니다.

처음 환경을 구성할 때 기존 IP 블록을 파악하기 힘들어 통상적인 범위 밖에서 Private IP 블록을 설정했고, 이를 팀 차원에서 발견하지 못했던 것이 원인이었습니다. 다행히 만들어지지 얼마 되지 않은 환경이었기 때문에, 영향도가 적을 때 빠르게 판단해 재구성 작업에 들어가기로 했습니다.

설정이 잘못되어 초기에 앱을 새로 만들거나 작은 인프라를 재구성해 본 적은 있지만, 이렇게 꽤나 큰 규모의 인프라 재구성은 처음이었습니다. 다행히도 새로운 인프라는 대부분 Terraform으로 구성되어 있었고, 겉보기에는 큰 문제가 없을 것 같았습니다.

개발 환경 EKS 재구성

무작정 개발 환경에서 재구성을 시작했습니다. 역시 만들어지지 얼마 되지 않았고, 거의 사용되지 않고 있었기 때문에 위험도는 거의 없었습니다.

결국 잘못된 것은 EKS에 연결된 VPC Private IP였기 때문에, 처음에는 단순히 “VPC의 IP 블록만 변경하면 되겠지?”라고 생각했습니다. 그렇게 되었으면 정말 좋았을 텐데, 현실은 그렇게 만만하지 않았습니다. EKS 클러스터를 유지하면서 VPC만 변경하는 것은 불가능했습니다.

이 변경 과정에서 정상적인 리소스도 정합성이 깨져 버렸고, terraform apply, terraform destroy조차 제대로 작동하지 않았습니다. 결국 의존성을 수동으로 몇몇 개를 지워 가면서 처리해야 했고, 우여곡절 끝에 리소스를 모두 지우고 새로 구성을 완료했습니다.
(다행히도 리소스를 모두 지우고 맨 땅에서 새로 구성하는 작업은 어렵지 않았습니다.)

운영 환경 EKS 재구성

이후 운영 환경에서는 동일한 실수를 반복하지 않기 위해 충분히 시간을 두고 계획을 세웠습니다.
결론적으로 내린 방향은 한 마디로 Create and Delete였습니다. 즉 EKS를 1벌 더 만들고, 서비스를 모두 이관한 뒤에 기존 클러스터를 삭제하는 계획이었죠.

그래서 아예 새로운 폴더를 만들어 새로운 EKS 클러스터를 구성하고, 중복될 수 없는 IAM Role이나 다른 리소스처럼 이관이 필요할 경우 terraform state rm 명령어로 기존 Terraform state에서 삭제하고, 새로운 Terraform state에 다시 import 하는 방식으로 진행했습니다. 그리고 서비스까지 모두 배포되면 Route 53 레코드만 변경해 주고, 트래픽 전환을 확인한 후 기존 리소스를 정리했습니다.

하지만 이 과정에서도 몇 가지 시행착오가 있었습니다.

1. Peering 연결 생성은 자동화할 수 없었습니다.
   • 정확히는, 같은 계정 + 같은 지역일 경우 자동 수락을 통해 자동화가 가능하지만, 아니라면 수동으로 수락해 Peering 연결을 생성해야 합니다.
   • 따라서 Terraform에서 리소스를 생성하더라도, 수동으로 수락 후 import 과정이 필요했습니다.
2. Terraform state 이동 후 S3 IAM Role의 키 정보를 참조하지 못하는 문제가 있었습니다.
   • 기존에 생성된 key 값으로 K8s Secret을 생성하고 있었고, 이 값을 import 후에는 참조할 수 없었습니다.
   • IAM User를 재생성하면 해결이 가능합니다. 다만, 궁극적으로는 AWS Secrets Manager 등을 사용해 관리하는 것이 좋습니다.
3. 삭제 과정에서도 Security Group이 지워지지 않아 VPC 삭제가 안 되는 등 깔끔하게 삭제되지 않는 리소스가 몇 개 있었습니다.
   • 이 경우는 수동으로 처리하였습니다.

그래도 최대한 계획을 세우고 안정적인 방향으로 진행했기 때문에 서비스에 거의 영향을 주지 않고 교체를 완료할 수 있었습니다.

배운 점

이런 큰 작업을 하면서 몇 가지 중요한 점을 배웠습니다:

1. 처음 시행착오를 겪은 게 개발 환경이라는 점이 정말 다행이었습니다.
   역시 무엇이든 운영 환경에 적용하기 전에는 시행착오가 필요하다는 것을 다시 한번 느꼈습니다.
2. 개발 환경에서 시행착오를 겪고 나서 바로 생각했던 것은, 운영 환경에서 동일한 과정을 거칠 수는 없다는 것이었습니다.
   적지만 실제 서비스가 돌아가고 있기 때문에 안정적인 계획이 필요했고, 실제로 이를 세워 진행했습니다. 엄청나게 짜임새 있는 계획이 필요한 것은 아니었지만, 그저 계획을 세우고 조심성을 챙기는 것만으로도 큰 도움이 되었던 것 같네요.
3. 겉으로는 작은 문제처럼 보여도 큰 임팩트를 줄 수 있다는 것을 배웠습니다. 이번 경우에도 바꾸어야 하는 것은 Private IP 블록 하나였지만, EKS 클러스터를 재구성하는 것 외에는 방법이 없었습니다. 특히 네트워크 설정은 매우 민감하고 클라우스 리소스와 깊게 연관되어 있어 더더욱 조심해야 함을 배웠습니다.

마치며

대단한 업적도 아니고, 내용도 많지 않고, 심지어 실수를 복구한 내용이라서 이를 블로그에 올리는 게 맞나 싶기도 했습니다. 하지만 이러한 내용도 누군가에게 도움이 될 수도 있고, 특히 저 자신에게 경각심을 줄 수 있기 때문에 기록하게 되었습니다.

다행히도 이후에 EKS 환경 구성은 순조롭게 진행되고 있고, 하나하나씩 이관 작업을 진행 중입니다. 지금도 매일매일 새로운 문제를 마주치고, 아직까지는 이러한 과정에서 엔지니어의 디테일이 중요하다고 느낍니다. 지금처럼 문제를 하나하나씩 해결해 나가며 저만의 가치를 찾아가려 합니다.