DevOps/AWS

최근에 직접 예약 인스턴스와 세이빙 플랜을 비교하면서 MSP의 계약건을 진행해야하는 일이 있었다. 관련해서 예약 인스턴스와 세이빙 플랜이라는 것이 있다는 것은 알고 있었고, 개인적으로는 예약 인스턴스가 가능한 경우에는 예약 인스턴스, 그 외에 Fargate로 사용하는 부분은 세이빙 플랜을 쓰면 되겠지 하는 단순한 생각이 있었지만, 좀 더 레퍼런스를 찾아보면서 해당 내용을 명확히 정리하게 되었다. 정리하는 과정에서 RI(Reserved Instance)와 SP(Saving Plan)의 정의나 어떤 상황에서 쓰는지 뿐만 아니라, MSP 등 AWS를 사용할 때 있어서 꼭 알아야 하는 비용 관련된 부분은 정리했다. 이번 포스팅에서는 AWS를 사용하는 데 쓰는 비용을 아끼는 여러 방법들과 함께, 보통 이러한 AW..

최근에 Aurora RDS for Postgres를 버전 업그레이드해야 하는 상황이 있었다. 꽤 예전 버전을 쓰고 있었는데, AWS 측에서 RDS for postgres를 지원할 때, 특정 기간 동안 지원하기 때문이다. 지원 기간이 끝난 경우에는 추가 비용을 지불하고 RDS를 써야 한다. 공식적으로 지원하지는 않지만 확장 관리한다는 명목으로 꽤 많은 비용이 센다. 아무튼, 이러한 과정 속에서 RDS를 백업하고 작업을 진행했는데, 일반적으로는 AWS Lambda를 써서 RDS를 주기적으로 S3 dumpall을 사용하는 것으로 알고 있었다. 하지만 AWS Backup이라는 서비스가 나오게 되면서 보다 편리하고 간편하게 백업을 진행할 수 있게 되었다. 이번에는 데이터베이스를 백업하고 복구하는 의미인 재해복구(..

회사에서 AWS 관련된 설정들을 확인하는 과정에서 가장 눈에 띄는 것은 Data Transfer 비용이었다. 단순하게 리소스를 확인할 수 있는 다른 호스팅 서비스와 다르게, Data Transfer는 AWS의 트래픽 과금 정책에 따라서 지불하는 금액을 말한다. 사실 클라우드라는 것은 어딘가에 있는 온프레미즈이다(!) 한국에는 총 네 개의 AWS 데이터 센터가 있다. 일산? 평촌? 자세한 위치 파악은 힘들었으나, 네 개의 온프레미즈 데이터 센터가 있다. 당연히 그 데이터 센터에서는 네트워크 작업이 철저하게 되어있어. 우리가 AWS 콘솔을 통해서 사용하려고 하면 손쉽게 리소스를 가져다 쓸 수 있도록 되어있다. 우리가 인터넷을 사용하게 되면, 대한민국의 통신사( KT, SKT, LG U+ )를 통해서 트래픽이..

앞서 포스팅에서 프론트엔드 배포에 대한 설정은 끝났다. 이제 백엔드 배포와 함께 해당 프로젝트의 전반적인 CI/CD 구성을 끝낼 예정이다. 전반적인 아키텍처는 아래와 같이 구성될 예정이다. 이번에도 Github actions를 통해 IAM으로 접근하는 방법이다. 백엔드 개발자가 github actions 설정을 통해서 코드를 푸시하는 순간 바로 ECS를 통해 배포되도록 구성했다. 백엔드 배포는 프론트엔드와 같이 완전한 Serverless를 이루도록 설정해 두었다. 즉, 스케일 아웃이 설정에 따라 알아서 진행되는 아키텍처로 설계하였다. 먼저 프로젝트를 진행하기 전에 앞서 알아두어야할 것들이 몇 가지 있다. 첫 번째로는 서버리스 아키텍처를 위해 ECS의 Fargate를 사용하는데, 이 경우에는 메모리와 CP..

최근 피우다 프로젝트라는 공모전에 다섯 명으로 팀을 꾸려 참가하였다. 개발 경력이 가장 길었기에 PM이자 팀장 포지션으로 다른 개발자들을 서포트하는 포지션으로 프로젝트에 임하게 되었다. AWS를 통해 프론트엔드와 백엔드를 배포하는 CI/CD를 전체적으로 구성하였는데, 전체적인 아키텍처는 위와 같았다. freetier를 사용하는 수준에서 처리할 수 있었고, 수많은 AWS의 서비스를 사용함으로써 AWS 아키텍처의 기본기를 제대로 다뤄보았다고 생각했다.  이번 포스팅은 프론트엔드편과 백엔드편으로 나뉘어 배포하는 과정을 나타낸다. 해당 과정에 대해서 다시 한번 블로그에 복기함으로써 어떤 식으로 아키텍처를 구성했는지 리마인드함과 동시에 다른 개발자들도 참고할 수 있게 글을 작성한다. 이번 포스팅에서 다룰 전반적인..