00pen

최근에 kubenetes도 배우고, helm도 배우면서 terraform을 배워야 겠다고 생각을 했었는데 타이밍에 맞게 이 책이 나온다고 해서 바로 읽어보았다. 

이 책에 대한 이야기를 하기 전에 요즘 클라우드 관련 기술의 트랜드를 보면 IaC나 helm 같은 기술들이 이끌어 나가는 것 같다. 해당 기술들의 특징은 명령형(imperative)가 아닌 선언형(declarative)라는 것인데 클라우드 기술들이 생겨난 이유를 생각해보면 당연한 걸지도 모르겠다는 생각이든다. 필자는 클라우드가 생겨난 이유가 기술의 발전이 점점 빨라지면서 그에 맞추어 대응하려면 클라우드에 서버를 두지 않고 물리적 서버를 고집한다거나 microservice가 필요한 시점에 monolithic한 아키텍처를 고집한다면 현 시대에서 얻을 수 있는 기술적 이점을 챙기지 못하기 때문에 클라우드가 잘 나가는 것이 아닐까 싶다. 그런 점에서 클라우드 서비스를 사용할 때 명령형으로 무언가 만든다면 한계가 있다고 느껴진다. 예를 들어 수십만개의 서버를 똑같은 환경으로 만들어야 한다면 명령형으로는 한계가 있을 것이다. 처음 만들 때야 한 번이라서 어떻게든 명령형으로 커버한다지만 여러 subnet에 나누어 넣어야한다던가, 도메인명을 다르게 한다던가 등... 여러 상황이 생겼을 때 명령형으로는 관리하기 매우 힘들 것이다. 따라서 관리 차원, 그리고 협업 차원에서 선언형은 어떻게 보면 필수가 아닌가 싶다.

이 책을 아직 완독하지는 못했지만 반 이상 읽은 시점에서 느끼는 건 실습하기 아주 편하게 만들어 놓았다는 것이다. 어떤 기술 책들은 실습하기가 좀 까다로워서 사놓고도 지식을 습득하지 못한 책들이 있는데 이 책은 특히나 로컬에서도 쉽게 실습을 할 수 있어서 유용한 책인 것 같다.

이전다음

01234567

목차를 보면 기본 지식 -> 모듈화 -> 실제 현업에 관련 내용 순이다. 아직 모듈화 전까지만 읽었지만 이정도만 읽어도 백엔드 개발자인 필자가 devops팀이 작성해놓은 terraform code를 이해할 수 있을 거라는 자신감이 든다... :)

가볍게 뒷 부분을 보기도 하였는데 현업에서의 가이드도 매우 흥미롭고, 리팩토링을 하는 과정을 상세하게 써 놓은 부분도 매우 흥미로웠다. 사실 리팩토링을 하는 것이 참 시간적으로나 기술적으로나 어려운 것이라고 생각하는데 이 과정을 책으로나마 읽을 수 있는 것은 좋은 경험이 될 거라고 생각한다.

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

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

Intellj에서 새로운 프로젝트를 만들고 main/test 폴더 위에서가 아닌 새로운 패키지를 만드려고 했는데 package, java/kotlin file 만들기가 new 에서 보이지 않았다. 아래처럼 보였다...

분명 package가 별 건 아니고 그냥 폴더일텐데... 폴더로 만들어서 그냥 java나 kotlin파일을 만들어서 돌려보려고 해도 안 먹는다. 사실 안 돌아가는건 말이 안 되고, intellj가 인식을 못한다.

해결방법은 {{ ProjectName }}.iml 이라는 intellj가 만들어주는 파일을 보면 xml형식으로 되어있는데 sourceFolder라는 속성이 있다. 근데 거기가 "file://$MODULE_DIR$/src" 가 아닌 "file://$MODULE_DIR$/src/main" 이런 식으로 되어있을거다. 그러면 src가 root가 아닌 main을 root로 보기 때문에 intellj가 다른 곳에 파일을 인식하지 않는다.

아래처럼 바꾸어 놓으면 다시 보인다!

<sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" />

파일 indexing을 사용자가 지정할 수 있도록 해놓은 것 같은데... 아무튼 처음 코틀린을 다루어 보려는데 책의 튜토리얼에서 한 시간 정도 헤맸다...ㅋㅋㅋ

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

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

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

그럼 이걸 이제 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 설정 관련해서 우여곡절도 있어서 이와 관련해서는 나중에 시간나면 다른 포스팅으로 기록해 놓으려고 한다.