돌이켜보면..
아키텍쳐와 워크플로우는 주어진 리소스와 문화에 따라 모두 재각각일 것이다.
반드시 옳은 아키텍쳐와 워크플로우란 존재하지 않을지도 모른다.
심지어 "지금 다른 아키텍쳐로 옮기기에 필요한 리소스가 부족해서"가 이유인 경우도 있다.
하나의 클라우드 서비스 업체에 너무 종속적이진 않는지, 마이그레이션할 계획이 있는지, 해외 진출 계획이 있는지 등등 고려해야할 사항이 너무나 많기 때문에 아키텍쳐를 어떻게 만들어갈 것인가는 항상 어려운 숙제인것 같다.
하지만 언제나 좋은 결론은 주어진 리소스 내에서 최대한의 효율을 내는 방법인 것 같다.
워크플로우와 아키텍쳐 설계의 부재
입사 2일차 간단한 회사 소개, 커뮤니케이션 툴 초대 및 간단한 코드 리뷰를 받았다.
가장 큰 문제점은 실 서비스 서버와 개발 서버를 같은 AWS 인스턴스를 사용하고 있었다는 것...
AWS EC2 또한 매우 저렴한 인스턴스를 사용하고 있었기에, 개발 중 약간의 실수만 있어도 실 서비스가 다운 되어 버리는 재앙이 일어나고 있었다.
또한 지금까지 개발팀장님 혼자 개발을 진행해왔기에, 정착된 워크 플로우 또한 없었다.
정리하면 정착된 워크플로우가 없고 아키텍쳐 또한 외주 업체에서 받은 그대로 유지하고 있는 상황이였다.
언제 서버가 다운될지 모르는 상태로 작업 자체가 힘든 상황이었다.
개발팀장님에게 지금까지 이렇게 작업한 이유가 따로 있는지 여쭤봤다.
현재까지 거의 혼자 작업하여 협업을 크게 고려하지 않았고, 사용량이 적었던 만큼 인스턴스 또한 다운되는 경우가 없었다는 것이였다.
이에 따로 스테이징 서버를 독립적으로 두고 개발을 해야하는게 어떤지 의견을 내보았다.
답변은 당연히 YES!
바로 작업을 시작했다.
필요한 아키텍쳐와 워크플로우는 간단하게!
시간, 비용, 인력의 리소스가 모두 무족한 상황이었기에 가장 빠르고 간단하게 만들 수 있는 워크플로우와 아키텍쳐가 필요로 했다.
워크플로우
필요한 개발은 로컬에서 진행하고, 테스트는 스테이징에서 진행 그리고 마지막으로 실 서비스 배포 라는 매우 간단한 워크플로우로 진행하기로 결정하였다.
아키텍쳐
아키텍쳐 또한 간단하게 구성하였다.
데이터에비스는 하나의 RDS를 사용하되 데이터베이스를 분리하여 사용하고, 실 서비스 디비를 매일 오전3시 스테이징에 덤프하도록 설정해두었다.
EC2 와 S3 버킷은 분리하여 사용하도록 하였다.
