AWS
이 글은 누군가 AWS를 다룰 때 조금이나마 덜 고생하길 바라는 마음으로 작성하며, 부정확한 정보에 대한 지적, 정정을 환영하고 자신이 아는 바가 있다면 얼마든지 추가해주길 바랍니다. 앞으로 지속적으로 추가할 예정입니다.
What is AWS?
아마존 웹 서비스(AWS, Amazon Web Service)는 아마존닷컴의 클라우드 컴퓨팅 사업부이다. 아마존 웹 서비스는 다른 웹 사이트나 클라이언트측 응용 프로그램에 대해 온라인 서비스를 제공하고 있다.
Region
아마존은 클라우드 컴퓨팅을 제공하기 때문에, 데이터센터를 곳곳에 보유하고 있다. 주 고객층을 생각해 물리적으로 가까운 리전을 선택한다.
경우에 따라 다른 리전(서울-오하이오 등)끼리 데이터를 전송하는 경우가 있다. 서버가 서울에 있는데 RDS가 미국에 있다던가.. 이 경우 AWS간의 데이터 통신에도 요금이 부과된다. 같은 리전에서는 무료인 경우도 있고, 부과되더라도 훨씬 적다(관련 링크). 물론 AWS가 아닌 인터넷에 데이터를 보내는 것이 가장 비싸긴 하다. 인터넷이 아닌 VPC를 이용하면 요금이 무료라고 하지만, VPC 이용 요금을 부과하기 때문에 아예 공짜는 아니다.
있던 인스턴스가 없어지면 제일 먼저 의심하자. 오른쪽 상단에 region이 달라진 경우가 왕왕 있다.. 글로벌로 하면 모든 지역의 인스턴스가 보이긴하지만, 서울에 만들어 놓은 것을 미국이나 다른 지역에서는 당연히 안보인다.
VPC
Virtual Private Cloud. 요구에 맞게 자체적인 네트워크 환경을 구축할 수 있는 시스템이다. 우리 서비스 내에서 주고 받는 메시지들을 모두 퍼블릭(우리가 흔히 말하는 인터넷)에서 실행할 이유가 없다. 위에서도 말했듯, 환경변수를 가져와 컴파일 하는 상황에서 퍼블릭 네트워크로 접근하여 받아오는 게 보안상 좋을 리가 없다. 또 퍼블릭 네트워크 환경은 우리가 통제할 수 없는 변수(ex. 처리율이나 링크 속도, 네트워크 공격 등)들이 존재하고 VPC보다 훨씬 많다. 우리에게 필요한 대로, 서비스에 맞게 구성할 수 있는 우리만의 네트워크다.
서브넷
서브넷은 VPC 내의 IP 주소 범위를 나누어 구성한 네트워크 세그먼트다. VPC를 여러 개의 서브넷으로 나누어 네트워크를 구성한다. public과 private으로 구분되는데, 인터넷 게이트웨이에 연결되어 접근이 가능한지에 따라 나뉜다. VPC내에서 통신이 오고 가는 길이라고 생각하자. 퍼블릭은 마을 밖(인터넷)으로 나갈 수 있도록 길이 연결되어 있고, 프라이빗은 나가는 길이 없는, 지하철 2호선 같은 내부순환로다. 마을 밖의 도로는 어디든 쉽게 갈수야 있지만 모르는 사람의 공격(보안)을 받을 수도 있고, 시위 같은 외부 요인으로 인해 차가 막혀 통신이 지연될 가능성도 있다.
게이트웨이
- 인터넷 게이트웨이 : VPC와 인터넷을 연결해 주는 게이트웨이. 퍼블릭 서브넷의 리소스는 이것으로 연결된다.
- NAT 게이트웨이(Network Address Translation) : 프라이빗 서브넷 내의 리소스가 인터넷에 접근할 수 있도록 해주는 게이트웨이다. 프라이빗 서브넷은 인터넷에 연결되있지 않기 떄문에 외부 서비스에 접근하려면 필요하다.
ECS에 등록한 Task가 실행할 떄 필요한 S3 버킷 내의 환경 변수를 받아오지 못하는 문제를 겪었었다. Task는 S3 버킷과 통신하기 위해 서브넷 중 하나를 이용하게 되는데 서브넷 중 프라이빗 서브넷의 NAT 게이트웨이가 설정되어 있지 않았다. 따라서 VPC 밖에 있는 S3에 접근할 방법이 없어서 발생한 오류였다! NAT 게이트웨이를 새로 생성하고, 프라이빗 서브넷들의 라우팅 테이블에 새로 생성한 NAT 게이트웨이를 추가하여 해결하였다.
S3
Simple Storage Service, 객체 스토리지 서비스다. 쉽게 말하면 ‘저장소’다. 참조할 환경변수 파일, 컴파일할 파일, 참조할 HTML 템플릿 등을 저장할 수 있다. 이후에 언급할 ECS, Cloudfront 등 다양한 서비스에서 필요한 것을 가져갈 수 있다.
S3에서는 “버킷”이라는 단위가 있는데, S3 내에 저장소의 객체 단위라고 생각하면 된다. 같이 쓰는 파일들을 하나의 버킷에 담아 관리하고, 접근도 버킷 단위로 이루어진다. 엔드포인트로 누가 어떻게 접근할 수 있는지 설정할 수 있으니 혹시 S3와 관련된 에러가 발생한다면 버킷 정책에 어떻게 되어있는지, 퍼블릭 액세스가 가능한지 확인해볼 필요가 있다. 일반적으로 많이 오류가 발생하는 3가지를 꼽자면,
- Role에게 S3 버킷 객체에 접근하여 가져올 권한이 있는가?
- ECS에서 Task를 정의할 때 수행할 Role에게 권한이 있다면 받아올 수 없다. 내가 사용하고 있는 Role이 무엇인지 확인하고 IAM에서 해당 역할의 권한정책을 확인해보자.
- S3 버킷 객체가 액세스 가능한가?
- S3 버킷들을 보면 액세스에 대한 정보가 나온다. 퍼블릭은 접근 가능성에 대한 설정이 아니라 접근 방식에 대한 이야기이다. 퍼블릭으로 설정되면, 인터넷으로 접근 가능하다. 퍼블릭이 아니라면 VPC 내에 S3 엔드포인트를 생성하여 접근하여야 한다. 퍼블릭이 편하기야 하겠지만, 인터넷으로 접근할 수 있기 때문에 보안에 대해 생각해야 한다. 문제가 되는 S3가 퍼블릭이 아니라면 VPC 엔드포인트가 잘 설정되어있는 지 확인해보자.
- 정확하게 접근했는가?
- 버킷 내의 객체들은 각자 URL이 있다. 필요한 객체에 접근하기 위해 URL이 정확한지, 실제 그 위치에 객체가 있는지 확인하자.
ECS
Elastic Container Service. AWS에 서비스를 배포할 떄 쓰는 컨테이너다. Docker 컨테이너 관리에 쓰이는데, Capacity, Controller, Provisioning 3개의 layer로 구성된다. 각각 컨테이너가 실행되는 곳, 컨테이너에서 실행되는 애플리케이션을 배포하고 관리하는곳, 이 관리를 위한 도구 쯤으로 이해된다.
클러스터
클러스터는 컨테이너를 실행하는 논리적인 그룹이다. 컨테이너를 실행하기 위한 리소스(CPU, 메모리 등)의 풀을 제공해준다. 애플리케이션과 클러스터가 일대일 대응된다고 하기엔, 클러스터가 여러 애플리케이션에게 리소스를 제공할 수도 있기 때문에 적절하지 않다. 리소스를 제공하는 큰 창고쯤이라고 생각하자.
서비스
클러스터 내에는 서비스가 존재하는데, 특정 태스크를 정의,실행,관리 하는 역할을 한다. 태스크의 수명이나 healthcheck(잘 돌아가고 있는지 주기적으로 쿡쿡 찔러보는 것)등을 담당한다. 컨테이너 돌아가게 관리한다고 요약할 수 있겠다.
태스크 정의
Task definitio은 컨테이너를 실행할 때 사용하는 구성 파일이다. 환경 변수는 뭘 쓰고, CPU와 메모리는 얼마나 사용할 것이며, 컨테이너 이미지는 무엇인지 등을 설정하는 것이다. 태스크 정의를 바꾸는 것을 “개정”이라고 한다. 태스크 정의를 삭제하고 새로 만드는 것이 아니라 책 개정판을 내듯 기존에서 새로운 버전으로 바꾸는 것이다. 배포를 통해 적용하면 서비스가 멈추지 않고 컨테이너의 태스크 정의를 바꿀 수 있다. 참 공교롭게, 글로벌 테스트 서버의 개정판 버전과 등록한 Task 수가 동일해서 “아 Task를 추가할 떄마다 바꿔줘야 하나?” 라고 생각했는데 전혀 아니다.
(예약된) 태스크
컨테이너에서 실행하는 작업. 예약된 태스크에 가보면, 주기적으로 실행될 예약된 태스크들이 나와있다. 아래 고급 구성에는 어떤 행동이 발생하는지 볼 수 있다. 생성할 때 실행 주기,태스크 정의, VPC, 보안그룹, 역할을 정해준다. 실행주기를 입력하는 방법은 2가지인데 고정간격으로 실행하거나 (몇 분 or 시간 or 일 마다) cron 식으로 작성할 수 있다. 특정 요일, 일, 시간에만 작동되도록 설정하려면 cron식을 작성하면 된다. 원하는 작동을 파이썬 파일로 작성해놓고 Task로 해당 스크립트를 실행하도록 python -m src.cronjob.test 를 추가하는 방법으로 실행한다.
내가 예약한 Task가 작동했는지 확인하는 방법은 2가지가 있다. 첫번째는, 클러스터를 선택하고 태스크를 눌러서 “원하는 상태 필터링”을 모든 원하는 상태로 바꾸는 것이다. 마지막 상태가 중지됨인 것이 나타나는데, 빨간색은 오류고 회색(Essential container in task exited)은 Task가 정상적으로 끝났다는 의미이다. 이 목록에는 최근 한 시간 내에 실행된 것만 나타난다.`
이 후의 기록은 아래에서 설명할 Cloudwatch에서 볼 수있다. Cloutwatch의 기록은 실시간으로 반영이 안되니 경우에 따라서 필요한 걸 찾아보자.
IAM
Identity and Access Management(IAM). 중앙에서 역할, 정책 등 리소스에 대한 권한을 제어한다. 누가 어떤 리소스를 제어할 수 있는지 설정할 수 있다. AWS에 로그인할 떄 IAM 사용자인지 루트 사용자인지를 묻는데, 이떄 IAM 사용자는 이 서비스로 특정 루트 사용자에게 권한에 대한 제어를 받는 사용자를 뜻한다.
사용자 뿐 아니라 정책이나 역할의 정의도 설정할 수 있다. IAM 사용자가 권한이 없을 때 오류가 발생하는데, 루트 사용자에게 권한을 요청하자. 이 아래에 사용자, 서비스, 작업, 리소스 에 대한 정보도 같이 제공되니 요청할 때 포함시키면 수월하다.
Cloudfront
CDN을 제공하는 서비스. 정적 및 동적 웹 컨텐츠를 사용자에게 더 빨리 배포하도록 지원해주는 서비스다. 엣지 로케이션이라는 곳에서 콘텐츠를 제공하고, 만약 여기에 없다면 어디서 줄 지 지정할 수 있다. 뒤에 후술할 S3라는 저장소에서 제공하도록 설정할 수도 있다. CDN(Content Delivery Network)은 웹 컨텐츠의 복사본을 사용자에 가까운 곳에 두어 웹 성능 및 속도를 향상시켜준다. 이건 내 블로그에 이미지를 업로드할 떄 많이 사용하다보니 알게됐다. 미국에서 우리 서비스를 접속한 고객의 화면에 띄울 이미지는 적어도 북아메리카에 있는 서버에서 보내는게 물리적으로 빠르다.
Cloudwatch
AWS에서 발생하는 로그, 오류, 경고 메시지, 성능 등 다양한 지표를 볼 수 있는 서비스다. 각각의 서비스에 일일이 찾아가서 볼 필요 없이 계정 내의 다른 서비스에 관한 그래프나 로그 등을 확인할 수 있다.
로그 그룹의 로그 이벤트로 들어가면 선택한 서비스의 로그를 읽을 수 있어 오류 내용이나 코드 위치를 파악할 수 있다. 지표에선 특정 Task가 언제 어떤 상태였는지 한 눈에 볼 수있다. 아래 지표에서 선택박스를 선택하지 않으면 그래프가 나타나지 않으니 항상 확인하자.
