아마 실무에서 AWS를 관리하는 devops이거나 개인적으로 프로젝트를 진행하면서 AWS를 통해 서버를 사용하고 있다면 비용을 어떻게 절감할 수 있을지 고민을 많이 했을 것입니다. 그래서 대표적으로 비용을 절감하는 saving plan이나 예약 인스턴스를 많이 사용하셨을텐데 이 책에서는 이 뿐만 아니라 ec2 인스턴스 스펙부터 시작해 스토리지, 네트워킹 비용까지 절감할 수 있도록 도와줍니다.

표지

목차를 보면 가장 많은 고려하게 되는 순으로 컴퓨팅서비스, 스토리지, 네트워킹, 이렇게 되어있습니다.

012
목차

근데 저는 이 책에서 네트워킹 서비스 쪽을 추천하고 싶습니다. 왜냐하면 서비스가 커지면 커질 수록 알게 모르게 돈이 새나가는 부분이라고 생각하기 때문입니다. 특히 쿠버네티스 환경을 사용하게 되면 가끔 AWS 내부나 클러스터 내부에서 통신을 할 수 있는 부분을 인터넷망을 통하게 되어서 공짜로 통신할 거를 비용을 지불하게 될 수도 있으니까요.

이 책은 표도 많고, 자기가 필요한 부분을 읽는게 많이 도움이 될 수 있을 것 같아 앞 장부터 제가 흥미롭게 보았던 부분을 뽑자면, 컴퓨팅에서는 스펙별 특장점, 예약인스턴스와 세이빙 플랜에 대한 설명, 컨테이너 서비스 쪽입니다. 스토리지에서는 S3에서 스토리지 클래스 전환(스탠다드에서 글레시어로 변환한다던가) 부분이었습니다. 그리고 마지막으로 네트워킹 부분은 어렵지만 생소했던 부분이라 다 재미있었던 것 같습니다. 특히 아래 그림은 네트워킹에서 우리가 알게모르게 path별로 과금이 상이했다는 것을 보여줍니다.

네트워킹 비용

마지막으로 한줄평을 하자면 "devops라면 집에 한 권씩 챙겨둬서 손해보지 않을 책"입니다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

토이프로젝트를 할 때, 누군가 같이 해야하거나 퍼블릭에 서버를 올려야한다면 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하는 수 밖에 없는 것 같다. 따라서 청구서를 보고 불필요하게 나가는 돈이 있다면 그 부분을 최적화하면 된다고 생각한다.

이 책을 읽고, 첫번째로 들었던 생각은 기대했던 것보다 업무에서 쓸 수 있을만한 좋은 내용들이 곳곳에 있었다는 것이다. 근데 그런 것에 비해서 정말 입문(AWS를 처음 쓰는 사람)하는 사람이라면 별로 안 와닿는 내용이었을 수도 있을 것 같았다. 왜냐하면 중간중간 정말 실무에서 알면 좋을 만한 내용들을 담고 있었던 반면에 실습 부분은 정말 너무 쉬운 내용을 담고 있었기 때문이다. 예를 들어 EC2를 설명하는 장에서 EBS의 스펙들도 알려주고, ALB, NLB도 알려주고, X-Forward-For 과 같은 개념도 알려주는데 실제로 만드는 것은 EC2를 만들고 접속해보는 것까지 해본다...ㅠㅠ

그래서 "나는 정말 AWS를 처음 써본다!" 하는 사람은 이 책의 5장까지만 보고, 정말 이 책을 보면 좋을 만한 사람은 ec2, rds, s3 같은 서비스를 이미 만들어보고, 개발경력이 1년정도 있는 사람같다. 왜나하면 처음 aws를 접할 때는 서비스 스펙 같은 건 신경쓰지 않고, 프리티어에서 공짜로 쓸 수 있는 걸 쓸 거라고 생각하고, 필자 또한 그랬다. 근데 실제로 돈을 내보거나 devops를 하시는 분들은 가격같은 것도 신경을 많이 써야한다. 그러면 이 책에서 설명하는 해당 스펙의 장단점, 그리고 여러 서비스들을 어떻게 조합하는지가 중요해진다. 

업무에 바로 쓰는 AWS 입문

특히나 이 장의 처음에는 IAM에 대해 설명하고 있는데, 난 처음 aws 접할 때 IAM이 뭔지도 모르고 ec2를 만들어 쓰곤 했는데 여러 서비스를 조합하고, 회사에 들어가게 되면 그 때부터 IAM이 중요하게 된다. 그래서 IAM을 첫번째 장에 넣은 것도 저자의 의도였을 것이라고 본다. (베스핀 글로벌에서 교육을 받았을 때도 IAM을 배우는 것부터 시작했다.) 또한, 초반에는 (필자가) 주요하게 쓰는 서비스 ec2, rds 등을 설명하고 나중에는 dynamodb, api gateway 같이 자주 쓰지 않는 서비스가 나왔기 때문에 저자가 책의 구성에도 신경을 썼다고 생각한다.

 마지막으로 한줄평을 하자면 처음 읽을 때는 너무 쉬운 내용을 다루고 있는게 아닌가 하다가도 가면갈수록 좋은 내용, 꿀팁을 알려줘서 기대 이상이였다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다

난 신기한 걸 읽거나 보고, 그걸 이해하고 싶을 때 많이 찾아보고 공부하게 되는데 이번에는 데브시스터즈에서 장애 회고한 글을 보면서 aws ec2 와 그 외 여러가지들을 배우게 되었다.

https://tech.devsisters.com/posts/crk-launch-storage-postmortem/

 

쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기

쿠키런: 킹덤 런칭 후 4일 만에 기술적인 문제로 인해 발생했던 약 36시간의 장애에 대해 전해드리고자 합니다.

tech.devsisters.com

 

위 글에서는 매우 많은 것들이 행해졌고, 내가 알지 못하는 부분이 많았다. 그 중 dd command를 통해 disk를 복사한 후 데이터를 복원하려는 시도를 했다는 것 부분에서 데이터를 snapshoot하는 방식과 그게 aws에서는 어떻게 실행되는지 궁금했고, 거기에 대해 조사, 공부해 보았다. 예전엔 이런 걸 밑바닥부터 공부하기 어려웠는데 요즘에는 chatGPT를 통해 큰 그림을 보고 자세한 건 aws나 그 외에 문서에서 보면 쉽다. 그래서 먼저 내가 지금 쓰고 있는 맥북에서 partition을 어떻게 관리하고 있고, 그걸 어떻게 하면 dd command를 통해 복사할 수 있는지 물어보았다. 자세한 내용은 생략하고, 간단하게 말하자면 diskutil이라는 command를 통해 partition이 어떻게 사용되고 있는지 볼 수 있고, /dev/* 폴더가 그 걸 나타낸다고 말해준다. 그리고 파티션을 복사하고 싶으면 파티션을 만들고, unmount하고 복사하고  source를 destination에 복사를 하라고 한다(dd command를 통해서). 그리고 친절하게도 덮어 씌워질 수 있으니 조심하고, 새로운 이름을 지어달라고 설명해준다.

aws ec2

그럼 이걸 이제 aws에서 어떻게 적용되고 있는지 알기 위해서 AMI, EBS 키워드로 검색을 해보면 여러 글들이 나오는데 아래 참고글 링크를 보면 자세히 설명해주고 있다. 내가 이해한 내용을 쉽게 설명하자면 일반적으로 우리가 ec2 instance를 ami로 복사하는 건 os, bootloader, volume들을 한꺼번에 복사해주는 이미지를 만들어주는거고 거고, ebs는 그중에서 volume(disk 또는 partition으로 이해하면 될 듯) 담당해 주는 것이다. 따라서 ebs에 volume만 복사해주고 싶으면 원하는 ec2 instance에 volume(ebs)를 장착하고 위에서 복사했던 대로 복사하고 detach해주면 된다. 

참고글:https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-AMI-Snapshot-%EA%B0%9C%EB%85%90-%EB%B0%B1%EC%97%85-%EC%82%AC%EC%9A%A9%EB%B2%95-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-EBS-%EA%B0%9C%EB%85%90-%EC%82%AC%EC%9A%A9%EB%B2%95-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-EBS-Volume-%EC%B6%94%EA%B0%80%ED%95%98%EA%B8%B0

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

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

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

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

+ Recent posts