OpsNow가 처음 개발이 시작될 때부터 지금까지 대다수의 서비스는 EC2에 올라가 있습니다. 초창기에는 AWS 인프라로부터의 독립성을 보장받고 싶었고 그에 따라서 대부분의 기능을 EC2에 올려서 단순 VM처럼 이용했기 때문입니다. 시간이 지남에 따라서 비용 절감과 유지보수를 최소화하기 위한 노력이 시도되었는데, 이를 위해서는 AWS의 다양한 관리형 서비스를 이용하는 것이 훨씬 유리하다는 사실을 알게 되었습니다.
관리형 서비스는 개발자가 정말로 서비스 개발에만 집중할 수 있도록, 인프라 관리에 대한 부담을 덜어 주었습니다. 개발팀에서 전담 AWS SA (Solutions Architect) 또는 SRE (Site Reliability Engineering) 인원을 이용하기에는 인적, 비용적으로도 부담이 되었기 때문에 인프라 관리 요소를 최대한 줄여야만 본래의 업무에 집중할 수 있었습니다.
다양한 서비스들 중에서도 최근의 가장 핫한 트렌드를 꼽으라고 한다면 k8s (Kubernetes) 입니다. 그래서 저희도 시도했습니다. SRE를 위한 전문 팀에서 k8s 클러스터를 구축하고, 개발자들이 쉽게 이용할 수 있도록 다양한 매뉴얼을 쏟아내기 시작했습니다. 그리고 많은 개발자들이 포기했습니다. 😥
왜 실패했나?
도대체 왜 k8s로 이전하는 것이 실패했을까요? 이유는 물론 많았습니다.
- 개발팀과 SRE 팀 사이의 괴리
- 개발팀에서 k8s의 필요성 부재
- AWS 기능 사용의 제약
개발자들은 갑작스레 도입된 k8s를 공부하기에는 시간이 부족했습니다. SRE 팀에서는 매일같이 다양한 기능을 제공하였고, 그에 따른 가이드를 제공했지만 정작 그걸 자세히 보거나 이해하기에 시간이 절대적으로 부족했습니다. 그러다보니, 자연스럽게 k8s로의 전환에 비협조적이 될 수밖에 없었습니다.
특히나, B2B 솔루션인 OpsNow의 개발자 입장에서는 사용자가 B2C 솔루션만큼 많지가 않았기 때문에 지금 형상에서 굳이 전환을 해야 하는가에 대한 의구심도 많이 들었습니다. 당연히 전환은 해야 하겠지만, 그렇게 빠른 속도로 모든 서비스를 한 번에 전환해야 할만큼의 필요성은 인식하지 못했던 것입니다.
마지막으로, AWS의 IAM 역할과 보안 그룹에 대한 제약이 발목을 잡았습니다. IAM 역할을 k8s 내에서 사용하기 위해서는 별도의 작업이 필요했고, pod를 위한 보안 그룹은 EKS (Elastic Kubernetes Service)를 통해야만 사용 가능하며, 그마저도 Fargate에서는 적용 자체가 불가능한 상황입니다.
이처럼 AWS에서 제공되는 IAM 역할과 보안 그룹을 사용하기 어려운 상황에서 권한과 보안을 제어하려면 k8s 안에서 또 다시 별도의 레이어를 통한 권한과 보안 제어가 필요하였습니다. 당연히 중복된 기능에 대한 관리 부담이 가중될 수밖에 없는 상황이었습니다.
그럼 ECS로!
k8s로의 전환은 어렵다면, ECS (Elastic Container Service)는 어떨까요?
별도의 권한, 보안 레이어를 구성할 필요 없이 AWS에서 제공하는 기능 그대로 가상의 클러스터를 구축하고 그 안에 서비스를 생성, Fargate 기반의 작업을 실행하는 것이 가능한 ECS는 바로 우리가 원하는 최적의 서비스였습니다!
- 컨테이너 이미지와 서버리스인 Fargate를 이용한 빠른 배포가 가능
- CodeDeploy를 통한 블루/그린 배포가 가능
- AWS Cloud Map의 Namespace를 이용하여 서비스 매핑
- CloudWatch로의 로그 통합
- CloudWatch의 Container Insight를 통한 메트릭 통합
- 서비스 단위의 보안 그룹 설정
- 작업 단위의 IAM 역할 설정
Fargate와 CodeDeploy의 조합은 서비스 배포 안정성을 상당히 개선시켰습니다. AWS Cloud Map은 Namespace를 생성하여 마치 k8s와 유사하게 서비스 메시를 구축할 수 있는 단초를 제공합니다.
그리고, 별다른 설정 없이도 Fargate 내부에서 발생한 로그는 CloudWatch로 보내집니다. 이 뿐만 아니라, 개별 작업 하나하나에 대한 메트릭도 손쉽게 확인할 수 있습니다.
그리고 보안 측면에서는 서비스 단위로 보안 그룹 제어가 가능하고, 서비스 내부의 작업 단위로는 IAM 역할까지 제어가 가능하여 AWS에서 제공하는 기능을 그대로 물려받아 사용하는 것이 가능합니다. 이렇게 관리형 서비스는 개발자가 컨테이너 기반의 클러스터 서비스를 관리하는 부담을 완전히 덜어주었습니다. 🤩
물론 OpsNow에서도 장기적으로는 k8s로의 이전이 꼭 필요하다는 인식은 가지고 있습니다. 하지만, 현재 상황에서 비용과 인원 측면에서 가장 효율적인 방법은 ECS라고 판단을 했을 뿐입니다. 여러분의 서비스도 k8s에 무작정 얽매이지 않고 ECS를 대안으로 살펴보시는 것은 어떨까요?