어찌어찌?하다가 accidentally 팀장으로 들어오게 된 회사라 내가 서비스 아키텍처를 전부 짜서 진행해보았다, 이게 잘한건가?싶으면서도 주변 도움도 받고 훌륭한 동료와도 상의하면서 이게 최선이라는 합리화(?)와 함께 만들어보았다 ㅎㅎ

Archietacture

AWS와 친해지기

AWS에는 정말정말 수많은 기능이 있다. 뛰어난 DevOps여도 그 모든 것들을 다 써보고 다 아는 사람 많지 않다고들 하던데.. 나도 기존에는 간단 EC2에서 인스턴스 만들어 배포만 해보았지만, 이번엔 나름 elastic beanstalk, ECR, Codepipeline을 활용하여 배포해보았다. 실제로 해보면서 느꼈던 점들을 간단하게 적어보려고 한다.

Elastic Beanstalk

전 회사에서는 만들어져 있던것을 쓰기만 했어서 몰랐지만, 이번에 빈스토크 환경을 초기부터 만들어보면서 beanstalk은 배포에 있어서 필요한 것들을 한 묶음으로 해놓은 패키지 같은 느낌이 들었다.

좋았던 점:
서버를 구축하는 과정에 있어서 필요한 모든 것들을 물어봐주고 설정하게끔 해준다.
1. 서비스 액세스: 역할을 지정해 줄 수 있다, 기존 서비스 역할을 불러올 수도 있고, 빈스토크 환경을 만들면서 자동으로 생성해주기도 한다.
2. VPC: aws에서 설정해놓은 vpc도 물어봐준다, 만들어 놓았다면 리스트에 다 뜰것이고, 없다면 새로 만들어야 한다. 리프레쉬 귀찮으니 빈스토크 환경 전에 미리 만들어놓으면 좋다.
3. 인스턴스: 설정 4단계쯤에 eb 환경설정을 하며 자동으로 설정해줄 인스턴스를 설정하는 단계가 있는데, 오토 스케일링 그룹에서 환경 유형을 밸런싱된 로드로 설정하면 auto scaleup이 된다, 인스턴스 유형은 물론(micro던 small)이던 오토스케일업 전의 인스턴스의 최소 최대 개수까지 설정이 가능하다. 나는 개인적으로 이 부분이 EB의 가장 큰 장점인거 같다.

아쉬운 점:
1. EB를 통해 자동 생성된 인스턴스들은 독립적으로 분리가 되지 않는거 같다. 예를들어 수동으로 인스턴스 유형을 EC2가서 변경한다던가는 안되고, EB 환경을 날리면 해당 인스턴스들도 함께 날아간다. 기왕 만드는거 인스턴스도 완벽하게 분리 가능하게 만들어놨으면 기깔났을거 같다.
2. DB는 EB 환경 내부에서 생성해도 이제는(?) 완벽하게 분리가 될 수 있게끔 한거 같다. 이 부분은 직접 물리적으로 실험을 안해봐서 정확하게는 모르겠다. 다만 문서에 보면 EB내에서 DB 생성시 독립적으로 분리할 것인지 종속할 것인지를 묻기 때문에 가능한것으로 보인다.

Elastic Container Registry

말 그대로 컨테이너 레지스트리, 걍 우리만의 docker hub라고 생각하면 될거 같다. docker가 너무 상용화 되면서 ECR과 ECS를 많이들 쓰는거 같다.

특징: private과 public repository가 나누어져 있다. 사내 서비스들이야 private repository에 이미지화 해서 저장하는게 맞지만, public은 언제 쓰려나 생각해봤는데, 협업시 타사에 이미지만 제공해줄때 쓰지 않을까 싶었다. 요새는 docker로 이미지로 말아서 주는 곳도 많으니까..

CodePipeline

CodeBuild, CodeDeploy를 한대 묶어 놓은 CI/CD라고 생각하면 되지 않을까 싶다. 개인적으로는 github action보다 성능적으로 뛰어난거 같다. 공짜툴보다 못 하면 그것도 문제긴 하지만..

특징:
1단계 Source: 특정깃헙레포의 브랜치를 지정해주면 push나 merge로 변화가 생길때 트리거를 만들어준다.

2단계 Build: 간단한 서비스라면 빌드 단계 스킵해도 되지만 docker로 말아준다던가 보통은 필요한거 같다. 이번에 써보면서 명확한 장점을 느낀 부분이 있는데 이건 뒤에 언급하겠다. buildspec.yml파일로 제어 하는데, 이름 바꾸고 싶다면 CodeBuild에 가서 파일이름 설정해주면 됨.

3단계 Deploy: 이번에는 EB 기반이기때문에 작업 공금자 설정에 AWS Elastic Beanstalk를 넣었다. 일반 EC2로 환경이고, 빌드 후 특별한 작업이 있다면 파일 하나 만들어서 script 넣어주고 artifacts에다가 그 파일 경로 만들어주면 된다.

명확한 단점:
진행하며 정말 이해가 안가는 부분이 있었는데 CodeBuild에서의 서비스 역할은 IAM에 가면 안뜬다는 충격적인 일이었다.. 안 믿을까봐 사진도 올리고 싶은데 회사거라 그럴수는 없다.

말 그대로 사진 속 내가 지워놓은 저 역할에 IAM가서 모든 역할(루트권한으로 봐도) 안뜬다는거였다. 아마존 개발자들 너무 바빠서 아직 반영을 못한건지.. 아무튼 덕분에 build단계에서 계속 내가 모르는 서비스역할이 secretsmanager에 등록한 .env 읽을 권한 없어서 빌드 못 한다는 에러를 수십번 마주했었다는 썰이...

느낀점:

AWS는 위대하다. 분명 위대..하겠지?ㅎ vpc설정 빼고 혼자 쫙 다 하면서 개바쁘긴 했지만 느낀점은 명확했다. 기존에 멍청하게 EC2인스턴스에서 코드 받고 docker 말아서 띄웠을때는 물리적 코드 저장하랴, 코드 이미지화해서 말아주랴 인스턴스 내부에서 하는 일이 많았던거 같은데, ECR과 CodeBuild를 사용해보니, 빌드는 CodeBuild에서 해주고, 실질적으로 서비스가 도는 인스턴스에선 ECR가서 이미지 받아오고 도커 컨테이너만 띄워주니까 인스턴스가 으마무시하게 절약되는 효과가 있는거 같다. 이렇게 하니 리액트같이 무거운 빌드도 인스턴스유형 small로도 커버칠 수 있을거 같았다. (아직 실제로 해보진 않았지만..;)

-----------끝-------------