[패스트캠퍼스 챌린지 18일차] '76가지 DevOps 모의 실무 예제: AWS 기반 인프라 구축부터 재해복구, 보안까지' 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
※ 챌린지 URL: https://abit.ly/lisbva

 

수강시작 인증사진

 

  오늘 강의에서는 AWS EKS를 다뤄봤다. 강의를 듣기 전에는 단순히 “쿠버네티스를 AWS에서 쉽게 쓸 수 있다”는 정도로만 알고 있었는데, 구조나 실제 운영 측면에서 어떤 차이가 있는지 조금 더 자세히 살펴보니 생각보다 인프라 쪽 고민이 많이 줄어들 수 있겠다는 생각이 들게 됐던 강의였다.

 

  EKS는 말 그대로 쿠버네티스를 AWS에서 관리형으로 운영할 수 있는 서비스다. Control Plane (API Server, etcd, scheduler, controller-manager 등)을 직접 구성하고 유지할 필요 없이 AWS가 대신 운영해준다. 덕분에 사용자 입장에서는 워커 노드, 네트워크 구성, 스토리지 같은 부분에만 집중하면 된다. 특히, API 서버나 etcd의 고가용성을 직접 구성하지 않아도 된다는 점에서 꽤 큰 부담을 덜 수 있을 것 같다. 비용은 클러스터당 시간당 0.10달러로 계산되는데, 단순히 한 달 운영한다고 치면 약 73달러 정도라고 한다. 물론 이건 Control Plane에 대한 비용이고, 워커 노드는 EC2 인스턴스를 사용하는 만큼 별도로 과금된다.

 

  직접 EC2에 쿠버네티스를 올려서 운영하는 경우와 비교해보면, 확실히 운영 부담이 적다는 게 EKS의 가장 큰 장점이다. Control Plane 구성이나 업데이트, 장애 대응, 버전 관리 같은 이슈에 대해서는 AWS에서 일정 수준 이상 커버해주니까. 하지만 완전히 자유로운 커스터마이징이 필요한 경우엔 오히려 EKS가 제약이 될 수도 있겠다는 생각도 들었다. 예를 들어 기업 내부 보안 정책이나 특정 워크로드 특성상, 직접 컨트롤하고 싶은 부분이 있다면 EC2 위에 쿠버네티스를 직접 구성하는 방식도 여전히 유효할 것 같다.

 

  그리고 AWS ECS와도 비교를 해봤는데, ECS는 사실 AWS에 최적화된 컨테이너 오케스트레이션 서비스지만 오픈소스 생태계와의 연결성이나 인력 채용 관점에서는 한계가 있을 수 있다는 걸 다시금 느꼈다. 특히 쿠버네티스를 표준으로 삼고 있는 요즘 같은 분위기에서는 manifest 관리나 확장성 측면에서 EKS가 조금 더 유리할 수 있겠다는 생각도 든다.

 

  한편으로는 AWS에서 쿠버네티스를 쓴다는 건 결국 EC2, VPC, IAM 같은 AWS 자원들과 어떻게 잘 통합할지가 핵심이 되는 것 같다. 예를 들어 네트워크를 구성할 때 VPC CNI 플러그인을 사용해서 pod 단위로 ENI를 붙이는 구조가 기본인데, 이로 인해 pod 수에 제한이 생길 수 있다는 것도 새롭게 알게 됐다.  ENI 수 * (IPv4 수 - 1) + 2라는 공식으로 최대 pod 수가 결정된다고 하는데, m5.large 인스턴스를 예로 들면 한 노드에서 약 29개 pod까지 배포가 가능하다고 한다. 이건 노드 수를 설계할 때 꽤 중요한 고려사항이 될 것 같다.

 

  스토리지 옵션도 EBS, EFS, FSx for Lustre 등 다양하게 CSI 드라이버를 통해 지원되는데, 이 역시 워크로드 특성에 따라 잘 선택해야 할 것 같다. SAN 스토리지와 같은 볼륨을 원한다면 EBS, NAS처럼 네트워크를 통한 공유 용도라면 EFS, 빠른 I/O가 필요한 워크로드라면 FSx을 사용하면 된다고 한다.

 

  결론적으로, EKS는 쿠버네티스를 쉽게 쓰고 싶지만 운영 부담은 줄이고 싶은 경우 꽤 좋은 선택지라는 생각이 들었다. 다만 내부 정책이나 복잡한 커스터마이징이 필요하면 EC2 위에 직접 쿠버네티스를 운영하는 것도 여전히 의미 있는 방식이라고 느꼈다. 차후에 기회가 된다면 EKS로 쿠버네티스를 운영해보는 경험을 해보면 좋겠다는 생각을 했다.

 

수강종료 인증사진

수강종료 후 강의목차

수강종료 후 학습통계