SWS Console: 클라우드 퀵빌더를 구축하다.
AWS 클라우드 아키텍쳐를 빠르게 구축할 수 있는 툴을 만들다.
AWS Cloud의 아키텍처는 점점 더 복잡해지고 있다.
Cloud Devops Engineer의 연봉은 US기준 147,220달러 ~ 156,348달러까지 올라간 만큼 중요해진 클라우드 엔지니어로 인해 기업이 채용한 개발자의 연 비용은 기하급수적으로 증가하고 있고 클라우드 기술은 급속도로 발전해가고 있다.
또한 점점 복잡해지고 어려운 클라우드 구조에 적응해야하는 신입 개발자 ~ 주니어 개발자들의 러닝 커브 역시 점점 높아지고 기업은 트레이닝하는 시간 만큼 비용써가며 직원들을 트레이닝하고 있다.
나는 이러한 현상들을 보며 이렇게 생각했다. 모두가 각자만의 방식으로 개발하고 있지만 특정 클라우드 아키텍쳐 템플릿을 정의하고 사용자한테 최소한의 입력으로 AWS Cloud에 내가 정의한 클라우드 아키텍처에 맞게 리소스를 생성 및 세팅해주는 플랫폼을 만든다면, 사람들은 클라우드 아키텍쳐를 고민하고 스터디하고 적용하며 보내는 오랜 시간과 비용을 좀 더 비즈니스에 집중하도록 만들 수 있지 않을까?
그 생각에서 시작된 플랫폼이 SWS Console이다.
SWS 콘솔은 첫 AWS 아키텍쳐의 VPC 셋업부터 프로젝트의 배포에 필요한 여러가지 아키텍쳐 구성을 최소한의 입력과 버튼 클릭으로 자신의 AWS Cloud 환경에 리소스를 생성할 수 있도록 해준다.
SWS AWS Cloud Quick Builder 기능들 보러가기
아래 이미지를 먼저 확인해보면,
우리는 위와 같이 Public Subnet과 Private Subnet을 구성하고, 그에 따라 Private하게 리소스를 사용하기 위해 Security Group을 구성하여 각 인스턴스 리소스를 배치하는데 이 작업을 하기위해서 학습해야할 내용이 너무 많고 또한 숙련된 개발자 또는 클라우드 개발자가 아니라면 스터디하고 클라우드의 구조를 파악하는데 많은 시간과 비용이 든다.
SWS Console은 이 구성을 하는데 5~10분이면 바로 구축이 된다.
또한 설정하는 방법은 아주 간단하다. SWS Console을 세팅하여 로컬로 SWS Console 어플리케이션 웹을 띄웠다면, 아래 이미지 처럼 프로젝트 이름을 입력하고 버튼하나만 클릭하면 위 아키텍쳐에 맞게 리소스들이 생성된다.
너무 쉽지 않은가? 비록 제한된 틀처럼 보일 수도 있지만 중요한건 위의 리소스를 만드는데 스터디하는 시간과 직접 구성하는 시간을 아낄 수 있다. SWS는 이러한 가치를 제공할 수 있도록 개발을 지속했다.
그래서 다음으로 생각했다. 우리가 SPA Project를 개발 했을 때 AWS 클라우드에 배포할 수 있는 방법은 대표적으로 생각했을 때 3가지로 나뉜다.
1. EC2에 업로드하여 Nginx, 아파치, 또는 스타트 스크립트로 SPA 프로젝트 직접적으로 실행
2. SPA Project를 도커라이징해서 ECR에 업로드하고 ECS에 올린 다음 ELB에 연결하여 내보내는 방법
3. SPA Project는 결국 Static이기 때문에 S3에 정적 웹 호스팅과 Cloudfront로 내보내는 방법
SWS는 3번을 선택 했을 때 비용이 많이 절약되고 효율적이라고 생각해 3번을 개발의 방향으로 잡고 이 서비스의 이름을 Frontend DMS라고 잡고 개발을 진행했다.
아이디어는 아래와 같았다.
사용자에게 SPA Project의 bundle.js와 index.html이 포함된 build 폴더를 zip으로 압축하여 받기만 하면 그 이후는 SWS 콘솔이 전부 아키텍쳐를 구축해주도록 개발하였다.
cloudfront 엔드포인트로 나가기 까지는 SPA Project의 빌드 파일을 S3에 업로드하고 정적 사이트 웹 호스팅 설정, 클라우드 프론트 Distribution 생성 및 연결해줘야하는 과정이 있다.
그러나 SWS Console을 사용하면 이 과정을 스터디하거나 고민할 필요가 없어진다.
아래와 같이 간단한 플로우로 구축이 완료되기 때문이다.
얼마나 쉬운가? 사용자는 더 이상 공부하지 않아도 SPA 프로젝트를 위와 같은 구조로 배포하고 구축할 수 있게된다.
우리는 여기서 그치지 않고 S3에 재업로드하고 클라우드 프론트 무효화를 동시에 진행해주는 옵션도 아래와 같이 제공해줬다.
우리는 위와 같이 계속 문제 해결에 집중했고 Cloudfront까지 배포했다면 마지막에 사용자가 하고싶은 것이 무엇인지 고민했다.
그때 생각난 것이 도메인 연결과 SSL 설정이었다. 마지막에 유저가 접근하려면 도메인은 필수 였고 이 역시 AWS Cloud가 기능은 제공해주지만 스터디해야할 내용은 많았고 이것까지 해결해줘야 이 솔루션이 의미있다고 생각했다.
그래서 우리는 생각했다. AWS의 Route53 서비스로 도메인만 구매하면 그 이후 문제들은 모두 SWS Console이 도메인을 선택하고 서브도메인만 입력하면 연결이 되도록 했다.
위 이미지를 보면 3번과 같이 Route53으로 구매한 도메인을 선택하고 Create SSL Certificate 버튼을 누르면 해당 도메인의 SSL Certificate 설정이 완료된다.
그 다음 6번의 Sub Domain 명만 사용자에게 입력받아서 Connect Domain 버튼을 누르면 https:// 로 해당 서브도메인으로 Route53에 연결까지 완료가된다.
너무 쉽지 않은가? 사용자는 AWS Cloud에 대한 지식이 없어도 클라우드에 프로젝트를 배포하고 사용자한테 내보내기까지 할 수 있다.
우리는 계속 사용자가 AWS Cloud에 대한 학습 없이도 클라우드 아키텍처를 구축할 수 있게 도와주는 툴을 만들어 개발자가 비즈니스에 조금 더 집중할 수 있도록 도와주고 나아가 적은 인원의 개발자로도 최대한의 AWS 리소스들을 사용할 수 있도록 가치를 제공할 것이다.
다음 기사는 다른 문제 해결에 대한 히스토리를 쓰려고 한다. 끝
