AWS

지난 포스트에서는 EC2 인스턴스에 PostgreSQL DBMS을 설치하는 방법에 대해 이야기해보았다. 데이터베이스는 정해진 백엔드 어플리케이션의 요청만 받아야 하므로, 나는 PostgreSQL DBMS를 브라이빗 서브넷에 위치한 EC2에 설치하려 했다. 하지만 나는 곧 당혹스러운 상황에 직면하게 되었다.NAT 게이트웨이를 붙이면 외부로 DBMS 설치 데이터를 요청하고 그 응답을 받을 수 있다. 데이터를 요청하기 위해서는 EC2에 접속해서 명령어를 입력해야 하는데, 문제는 ─ 그야 당연히 "프라이빗" 서브넷인 만큼  ─ 외부 인터넷과 연결된 퍼블릭 IP가 존재하지 않는다는 것이었다. 외부와 연결되어있지 않으니 ssh 접속 자체가 불가능했다. 나는 몇 가지 방법을 생각해보았다. 프라이빗 서브넷에 IGW를 ..

최근까지만 해도 나는 postgreSQL DBMS를 돌릴 플랫폼으로 "AWS RDS"를 사용했다. 이유야 여럿 있겠지만 AWS 안에서 제공하는 서비스라 네트워크 관리하는 것도 편리하고, 따로 이것저것 설치할 필요 없이 자동으로 세팅된다는 점도 좋았다.그러나 몇 달에 걸쳐 RDS 요금이 가파르게 상승하기 시작했고, 이대로 방치했다가는 안그래도 얇은 지갑 사정에 심대한 위기가 찾아올 게 불보듯 뻔했다. 요금은 중대 사안이다. 당장 RDS를 버리지는 않는다 해도 어떤 대안이 있는지 정도는 찾아둬야 할 것 같았다. 찾아보니 EC2 인스턴스에서도 ─ 간단한 듯하면서도 복잡한 듯한 과정을 거치고 나면 ─ postgreSQL DBMS를 돌릴 수 있었다. 백엔드 개발자 지인에게 물어보니 대부분 돈 아끼고 싶으면 RDS..

https 통신을 구현하기 위해서는 SSL 인증서가 필요하고, SSL 인증서를 발급받으려면 DNS 인증을 받아야 하는데, 이를 위해서는 도메인이 필요하다. Route 53에서 직접 구매하거나, 외부에서 구매한 도메인을 Route 53에 등록해두어야 한다. NS 레코드는 도메인 이름을 네임서버 주소로 매핑하며, SOA 레코드는 특정 도메인의 DNS 존(zone)의 시작을 나타내며, 해당 존에 대한 주요 정보를 제공한다. Route 53이렇게 준비가 되면 Route 53 호스팅 영역에서 A 레코드를 하나 생성해야 한다. A 레코드는 원래 도메인 이름을 IPv4로 매핑하는 레코드지만, 별칭을 사용하면 일부 AWS 리소스로 트래픽을 라우팅해주기도 한다. 나는 ALB로 라우팅될 수 있도록 설정해주었다. 이렇게하는..

workflows프로젝트의 main 브랜치로 PR이 머지되면 github action이 동작한다github action은 github secrets로 관리되고 있는 환경 변수를 모아 .env 파일을 만든다github action은 main branch를 checkout하고, .env 파일과 함께 zip으로 압축한다github action은 압축한 파일을 S3로 업로드하고, CodeDeploy로 하여금 배포 사실을 알린다CodeDeploy는 EC2의 CodeDeploy-Agent에게 배포 사실을 알린다EC2의 CodeDeploy-Agent는 S3에 업로드된 zip 파일을 가져와 압축을 푼다EC2의 CodeDeploy-Agent가 프로젝트 내부에 있는 appspec.yml 파일을 읽고 수행한다전체적인 동작 ..

우리는 앞선 포스트를 통해 S3에 이미지를 저장하는 두 가지 방법에 대해 알아보았다. 이렇게 저장된 자원들은 REST API를 통해 접근할 수 있다. 따라서 아래와 같은 방식으로 요청하면 특정 버킷으로부터 이미지 파일을 가져올 수 있다.https://[버킷 이름].[리전 이름].amazonaws.com/[파일 이름] 그런데 이러한 주소를 직접 사용하는 것은 문제가 없을까? 이러한 주소를 직접 클라이언트에 건네준다는 것은 곧 내가 사용하고 있는 S3가 어느 리전에 위치해있는지, 버킷 이름은 무엇인지와 같은 정보가 무방비하게 노출되어버리고 만다는 의미가 된다. 따라서 이번에도 백엔드 서버가 S3와 클라이언트 사이를 중개해주어야 하는데, 나는 여기서 presigned URL을 사용하고 있다. pURL은 그저 ..