00pen

토이프로젝트를 할 때, 누군가 같이 해야하거나 퍼블릭에 서버를 올려야한다면 AWS나 다른 클라우드 서비스를 쓸 수 밖에 없다. 근데 기본적으로 서버 한 대(ec2) 랑 db 정돈 있어야하는데 그럴 때를 기준으로 비용 절약하는 팁을 알려주고자 한다.

1. 일단 free tier 아이디를 구하자.
 프리티어 아이디 하나면 AWS에서 프리티어에게 제공하는 ec2 한대와 db 하나(아마 t시리즈 micro)를 매우 저렴하게 제공해줄 것이다. 그러면 솔직히 거의 부담이 안 되므로 1년간 잘 쓰도록 하자.

2. 보안을 신경 쓸 필요없다면 ec2 대신 lightsail 서비스도 고려해보자.
 여기부터는 프리티어 기간을 다 썼을 때 부터 고려해야하는 부분이다. lightsail은 aws에서 아주 저렴하게 서버를 쓸 수 있도록 제공해주는 보급형(?) 같은 서비스다. 이걸 사용하면 아쉽게도 다른 AWS 서비스와 조합하기 힘들어지지만 시작해보기엔 좋은 선택이라고 생각한다.

3. 사용 시간에 따라서 비용절감 계획을 고민해보자.
 여기부터가 진짜 비용을 고민해야 될 때인 것 같다. 필자는 토이프로젝트 초반에는 동료들에게 iam 계정을 주고, ec2와 rds를 사용하는 시간에만 틀도록 했다. 외부 고객이 없는 상태이므로 그래도 됐다. 근데 진짜 계속 on-demand로 계속 올려놔야한다면 saving plan이나 예약 인스턴스를 고려해보자. all upfront(전체 선결제)로 하면 특정 스펙의 instance만 쓸 수 있는 단점이 있지만 가격은 20~30% 정도 절약할 수 있다.

4. storage 서비스로 나가는 돈을 절약하자.

위 사진을 보면 서버를 안 사용하고 있어도 ec2와 rds가 사용하는 storage에 과금이 된다. 특히 rds에는 SSD에 따라 과금 정책이 꽤 상이한데 보통 gp2, gp3, provisioned iops SSD가 있는데 토이프로젝트에는 gp3가 좋아보인다. 왜냐하면 기본 volume에 대한 비용이 gp2보다 저렴하고, 다른 부분에서 사용량이 많을 때 과금이 더 되는 구조라서 io를 신경쓸 필요 없는 토이프로젝트에서는 gp3가 좋아보인다. provisioned iops SSD 이건 실제 서비스에서 io가 많을 때 쓰는 용도이고, 비싸니 신경쓰지말자.

5. 마지막으로 결제되는 청구서를 잘 읽자.
 하다보면 elastic ip를 사용하는 경우도 있고, 라우팅이 필요한 경우도 존재할 수 있다. 중요한 건 눈 먼 돈이 나가는 걸 막기 위해서는 청구되는 금액을 계속 tracking하는 수 밖에 없는 것 같다. 따라서 청구서를 보고 불필요하게 나가는 돈이 있다면 그 부분을 최적화하면 된다고 생각한다.

 직장 내 디자이너 분과 밥을 먹다가 이런저런 얘기를 나누면서 그 분이 '이런 걸 만들어보고 싶다.' 라는데서 시작했다. 회사에서 개발하다보면 개발 스펙이나 방향에 아쉬움이 남을 때가 있었는데 그런 아쉬움을 해소할 수 있으면서 재미도 있을 것 같아 그 얘기를 가슴에 담아두었다. 나는 백엔드 개발을 하다보니 프론트엔드 개발을 해줄 사람이 필요했고, 마침 잘한다고 생각하는 프론트 개발자분에게 말씀을 드렸더니 좋다고 하셔서 진행하게 되었다.

 나와 프론트엔드 개발자 분은 진짜 사이드 프로젝트처럼 지식을 쌓으려고 시작했다면 디자이너 분은 사업적인 영역까지 생각하고 있었다. 그래서 은근히 진지모드로 진행했고, 오히려 그게 책임감을 갖게해서 진행하는데 도움이 되었던 것 같다. 사실 이제 경력이 막 2년된 내가 잘 할 수 있을지 걱정이 되긴 했지만 분명히 내가 도움이 될 수 있는 부분이 있었다.

특히 이 프로젝트의 성공을 떠나서 나중을 위해서 디자이너분과 프론트엔드 개발자 분에게 다른 방면으로도 도움을 줄 수 있을 거라고 생각했다. 협업을 하면서 백엔드 개발이 어떤 거고, 백엔드 개발자가 어떤 생각을 하는지 알려드릴 수 있는 기회라고 생각했다. 두 분은 실력적으로나 다른 면으로나 신뢰할 수 있는 사람이라고 생각했고, 이번 프로젝트가 아니더라도 다른 멋진 프로젝트를 할 수 있는 분들이라고 생각했다. 그래서 가비아에서 aws에 도메인을 어떻게 연결하는지, 서버를 어떻게 구성하려는지 디자이너 분께 설명드렸다. 그리고 프론트엔드 개발자 분은 백엔드의 어느정도 지식이 있고, 프론트 개발자지만 백엔드 관련한 지식이 충분하다고 생각했기 때문에 로컬에서 spring application을 올릴 수 있도록 설치해주면서 가끔 spring security를 만지면서 이런 걸 넣으면 이렇게 변하더라 라는걸 말씀드렸다. 회사에서 vue.js를 이용해 백오피스를 만들어보면서 얕은 지식이지만 프론트 관련 지식을 쌓은게 프론트엔드 분들과 협업할 때 많이 도움이 되었던 것처럼 이런 게 추후에 내가 아니더라도 다른 분들과 협업할 때 도움이 될 것이라고 생각했기 때문이다.

며칠 전에 다행히 public하게 모든 걸 띄워놓는 것까지 완성할 수 있었다.
서비스는 이제 시작이지만, 처음부터 끝까지 서버를 만들면서 front 배포할 때는 어떤 것들을 고려하면 좋을지도 많이 고민할 수 있었고, spring에서 유용하게 쓰이는 패턴들을 익히고, 사내에서도 조금씩 적용하는 등 많은 것을 배울 수 있어서 좋은 경험이었다. aws 비용을 줄이기 위해 처음에 ec2 한 대로 front, back 서버를 같이 띄우고, 배포할 때도 green-blue 전략을 채택하지 않고 기존 container를 stop & remove하고, 새로 올리는 방식을 채택하기도 했다. 그리고 처음 live에 홈페이지를 띄울 때 nginx 설정 관련해서 우여곡절도 있어서 이와 관련해서는 나중에 시간나면 다른 포스팅으로 기록해 놓으려고 한다.

이전까지는 사이드 프로젝트나 토이 프로젝트를 할 때 혼자 했었다. 근데 이제는 프론트엔드 개발자와 디자이너, 기획자 분들과 함께 하다보니 프로젝트가 온전히 나의 것이 아닌 상황이 되었고, 이 프로젝트를 위한 aws 계정을 파는 것까지는 아니더라도, 회사에서 쓰는 것처럼 내 계정을 root 계정으로 돌리고, 다른 분들께 aws console에 접속할 수 있는 권한과 관리자 권한을 드려야 한다는 생각이 들었다. 나도 이제 시작이지만 처음 이런 상황에 마주하게 되어서 조그마한 프로젝트지만 혼자하는 프로젝트가 아닌 분들께 도움이 되지 않을까 하는 생각에 기록해본다.

1. aws organization을 사용할 상황은 아니다.
 처음에는 막막해서 그냥 회사 dev aws에 내 계정은 어떻게 설정되어 있는지를 보았다. 들어가기 전에는 organziation을 만들어야 하는건가 싶었는데 그건 조직이 커졌을 때 devops 조직과, 그냥 개발팀을 나눈다던지, 결제 관련해서 나누어야 하는 상황일 때 쓰는 것이였다. 그래서 이건 pass.

2. 일단 토이프로젝트라서 아무 것도 만들어져있지 않은 상황이기 때문에 어느정도 개발된 후에 aws를 만들어도 된다.
 백도 프론트도 이제 처음 시작이기 때문에 github로 코드를 공유하면서 local에서 개발한 후, 어느정도 기반이 되었을 때에나 aws에 서버를 만들어도 늦지 않을 것 같다.

3. iam을 통해 관리자 group을 만들고, 자신을 user에 추가하고, 동료분들도 user에 추가한다.
 내 계정엔 admin이라는 user group을 만들고, user에 자신의 계정도 새로 만들어서 개발할 때 iam 계정을 통해 사용하도록 한다.( root 계정은 특별한 경우가 아니면 쓰지 않도록 아마존에서도 권장하는듯) 동료 분의 계정을 추가하기 위해 add user을 통해 user이름을 적고 아무 비밀번호를 적거나 auto generated password로 한 후에 required password reset을 체크한다. 다른 방법으로는 access key를 이건 sdk, api를 통해 aws를 사용하는 user를 위한 설정인듯 하니 pass. 
(auto generated password로 설정하면 계정을 만든 후에 welcome email(?)을 보내도록 하는 페이지가 뜰 때 거기에 auto generated password가 있다.)
 
 iam으로 접속할 때 12자리 계정 id가 아닌 별칭을 쓰고 싶다면 iam dashboard에서 오른쪽 사이드바(?)에 별칭 설정이 있다. 그걸 바꿔주면 된다.