GuardiOne Motor (가디원 모터)에는 아마존웹서비스(AWS: Amazon Web Service)가 적극 활용되었습니다. AWS에서 제공하는 다양한 서비스들을 이용하다 보니, 자주 사용하는 서비스와 해당 서비스의 설정들을 템플릿화하면 더욱 더 편리하겠다는 생각이 들었습니다.
그래서 이번 포스트에서는 AWS의 서비스들을 템플릿화 해주는 툴인 AWS CloudFormation와 이 툴을 기반으로 전체 제품을 구축해본 경험에 대해 소개해드리고자 합니다.
1. AWS 서비스를 템플릿화하여 관리해야 하는 이유
가디원 모터의 서비스 구조
가디원 모터의 서비스 구조
가디원 모터의 서비스 구조는 위와 같으며, 해당 구조는 실제로 AWS 서비스들을 이용해 구성되었습니다. 코드로 구현한 각 API들을 Container화 시킨 후, AWS의 서비스들을 이용해 네트워크 설정, 배포, 로드밸런싱, 오토스케일링, DNS 설정 등을 구현해 실제 고객들에게 제공합니다.
가디원 모터에 적용된 AWS 서비스 구조
가디원 모터에 적용된 AWS 서비스 구조
단 하나의 제품을 구성하는 데에도 많은 AWS의 기능이 사용됩니다. 이러한 AWS 기능들은 개발자가 AWS 콘솔을 통해 직접 구성해야 하지만, AWS 콘솔에서는 여러 기능에 대한 설정을 비교적 쉽게 할 수 있도록 UI를 제공하고 있기 때문에 과정이 크게 어렵지 않습니다.
하지만 콘솔을 통해서만 AWS 서비스들을 관리하게 될 경우, 아래와 같은 문제가 발생할 수 있습니다.
•
각 서비스에 변동이 생길 경우, 이력(버전)을 관리하기 어려움
•
각 서비스간 강한 의존성을 가지고 있는 경우가 많기 때문에, 하나의 서비스를 수정하게 되면 수정이 제대로 이루어지지 않거나, 다른 서비스에 예상치 못한 영향을 끼칠 수 있음
•
가디원 모터의 경우, 개발 시기(phase)에 따라 dev live prod와 같이, 동일한 서비스를 분리해서 배포됨. 그렇기 때문에 콘솔에서 작업 시 AWS 생성 작업을 반복해야 하고, 실수할 경우 테스트 환경과 배포 환경이 달라질 수 있음
dev live prod란?
각 AWS 서비스들을 AWS CloudFormation 을 통해 하나로 템플릿화하여 관리하면, 위와 같은 문제점들을 해결할 수 있을 뿐만 아니라 아래와 같은 편리함도 생깁니다!
•
모든 서비스를 템플릿에 대한 문서(.yaml)로 관리할 수 있기 때문에, git을 이용한 이력(버전) 관리가 가능 (아래 .yaml 파일 예시 참고)
•
각 의존성을 템플릿에 명시할 수 있기 때문에 예상치 못한 영향을 사전에 방지 가능
•
같은 구성의 서비스는 하나의 템플릿으로 동일하게 만들어 낼 수 있으므로, 동일한 서비스를 생성하는 데 드는 비용 절감
AWS CloudFormation
AWS CloudFormation에 대한 자세한 내용은 아래 공식 홈페이지에 자세히 기술되어 있습니다.
2. 실제로 AWS CloudFormation을 활용해보니…
CloudFormation을 활용해서 가디원 모터를 템플릿화한 경험을 소개합니다.
작업 방향
1.
적용 범위 선정
•
가디원 모터에서 이미 사용되고 있는 AWS 서비스들을 CloudFormation을 통해 생성/관리하자
•
dev live prod의 3가지 phase로 관리할 때 반복 작업이 필요한 부분을 템플릿화하자
2.
현재 모터에서 사용 중인 AWS 서비스
•
Raw data 등을 저장하기 위한 S3
•
VPC, subnet, routing table 등 기본 네트워크 관련 서비스
•
docker image를 보관하는 ECR 서비스
•
docker 컨테이너 오케스트레이션을 위한 ECS 서비스 (ECS cluster, task definition, service)
•
서비스의 부하 관리를 위한 Loadbalancer 서비스 (Application Loadbalancer, Targetgroup)
•
데이터 관리를 위한 RDS
•
DNS 생성 및 관리를 위한 Route53
위 서비스 중, 주황색 블록 처리한 서비스들에 대해 CloudFormation을 적용했습니다. 나머지 서비스들은 아래의 이유 때문에 적용하지 않았습니다.
•
S3, ECR, RDS
◦
각각 기존의 docker image와 데이터를 백업하고 옮기는 작업이 필요
◦
한번 만들면 크게 바뀌지 않음
템플릿 구조
가디원 모터를 위해 4개의 템플릿 파일을 만들었습니다.
Network template
ECS Cluster template
Algorithm API template & Dataio, Backend API template
4개의 템플릿을 실행시켜 위의 AWS 전체 구조를 한번에 생성하고 관리합니다. 4개의 template의 실행순서는 아래 그림과 같습니다.
템플릿의 실행 순서
Root Template
지금까지 AWS 서비스의 종류와 기능에 따라 4가지 템플릿으로 나누었습니다.
하지만 아직도 각 phase에 따른 서비스를 생성하려면 템플릿 개수만큼 반복하여 AWS 서비스를 생성해야 합니다. 또한 각 템플릿들은 서로 의존성(dependency)이 있기 때문에 생성과 제거를 할 때 순서를 신경 써야하는 문제가 있습니다.
이럴 때 필요한 게 Root Template 입니다. CloudFormation에서는 Nested Stack 이라는 기능을 이용해 여러 개의 템플릿을 하나의 템플릿으로 관리하고 실행할 수 있습니다.
Nested Stack 공식 문서 그림
모터 서비스는 각 phase에 대한 서비스를 생성하지만 network 부분은 서로 공유하도록 구성하려 합니다. 따라서 network 부분을 제외한 나머지 부분들을 Root Template으로 구성하였습니다. 이 Root Template의 이름은 Application template이라고 부르겠습니다.
Application 템플릿을 사용한 구조
위 그림과 같이 구성하게 되면, network 부분만 미리 생성 시, 나머지 부분들은 phase에 맞게 설정을 쉽게 바꿀 수 있으며 우리가 사용하고자 하는 AWS 서비스를 간편하게 생성할 수 있습니다.
아래는 AWS의 CloudFormation 콘솔화면입니다.
콘솔에서 템플릿을 실행하여 서비스를 실행하게 되면, CloudFormation에서는 Stack이라는 단위로 모듈을 관리합니다. App template으로 Stack을 생성하면 구성한 서비스에 필요한 모든 AWS 기능들이 만들어집니다.
3. CloudFormation 적용 후기
작업 과정
동일한 구조의 서비스를 여러 개 구성하는 경우 굉장히 편하게 작업할 수 있게 되었습니다. 또한 구성된 AWS 서비스들의 삭제/재생성이 매우 쉬워졌습니다.
버전 관리
구성하고 싶은 AWS 서비스들을 text 파일 형태(.yaml)로 관리하므로써, git을 이용한 버전 관리가 용이하게 되었습니다.
팀원 간 협업
팀원 간 소통 시에도 AWS 콘솔 화면을 통하는 것보다 템플릿을 통해 소통하는 것이 더 원활하였습니다.
학습 비용
각 AWS 서비스의 설정을 config로 하나 하나 다뤄야 하기 때문에, 콘솔에서 제공하는 UI로 설정할 때보다 CloudFormation으로 설정하는 것이 각 AWS 서비스에 대한 더 높은 이해를 필요로 합니다. 실제로 도입을 시작한 초반에는 학습 시간이 많이 필요했습니다.
모터 팀에서 AWS CloudFormation을 도입하면서, 우리 시스템의 부족한 부분도 한번 더 살펴보게 되었고, 유지보수 측면에서 큰 이점을 가지게 되었다고 생각합니다. 후기를 끝으로 포스트 마치겠습니다.
AWS CloudFormation 도입을 통해 높은 수준의 예지보전 인사이트를 제공하고 있는 가디원 모터가 궁금하시다면 아래 링크들에서 더 자세히 확인하실 수 있습니다.
가디원 모터 자세히 알아보기
•
웹페이지 링크
참조
이 글을 쓴 사람
김 경 환 | Solution Dev. 팀
원프레딕트의 산업설비 솔루션 개발을 하고 있습니다.
AI 기술을 이용해 다양한 문제를 해결하는 소프트웨어 엔지니어입니다. 원활한 개발 협업을 위한 시스템을 구축하는 데에 관심이 많습니다.
게임을 하는 것도 좋아하고 보는 것도 좋아합니다. 현실도 게임처럼 매일매일 Level up!
원프레딕트 홈페이지
https://onepredict.ai/
원프레딕트 블로그
https://blog.onepredict.ai/
원프레딕트 기술 블로그
https://tech.onepredict.ai