Cloud Computing On Demand

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할 수 있...) 레코드 수량에 대한 비용 부담이 없기 때문에 요청량이 많지 않은 경우 비용이 꽤 저렴한 편이기도 합니다.

여튼, 이런저런 목적으로 Route53을 사용하게 되면 Route53에 대한 모니터링을 하고 싶어지는게 인지상정입니다. CloudWatch에서 기본적으로 제공되는 Route53의 메트릭들이 있긴 하지만 DNS 쿼리 자체에 대한 성공, 실패와 같은 모니터링은 CloudWatch의 메트릭으로는 모니터링이 불가합니다. 

서버의 Access Log를 분석하는 것처럼 Route53의 쿼리 질의 및 결과를 모니터링 하려면 CloudWatch가 제공하는 Logs기능을 이용해야 합니다. Route53에 구성한 Zone으로 들어오는 요청을 CloudWatch Logs로 수집하고 다시 이것을 ElasticSearch 등의 데이터 분석 도구로 전달하는 모니터링 체계를 만들어 보도록 하겠습니다. 

Route53 Hosted Zone에 Query Logging 설정하기

Route53에서 관리하는 Zone을 Hosted Zone이라 부릅니다. 개별 레코드를 만들어 Route53에 위임하는 경우도 있고, 혹은 최상위 Zone 자체를 Route53에서 관리(=Authoritative NS)하는 경우도 있습니다. 어느 경우던 기본 단위는 Hosted Zone이고 로그 수집의 최소 단위도 Hosted Zone입니다.

Route53에 구성한 Hosted Zone에 대하여 로깅을 하기 위해서는 AWS CloudWatch Logs를 이용해야 합니다. CloudWatch Logs로 로그를 전달하기 위해서는 Route53에서 로그를 전송하고자 하는 Hosted Zone 관리 화면으로 이동하여 기능을 활성화 해야 합니다. Hosted Zone 관리 화면에 진입하면 우측 상단에 `Configure query logging`이라는 버튼을 확인하실 수 있습니다. 

Query logging 기능 활성화는 무척 단순합니다. 새로운 Log Group 을 만들기 위해 `Create log group`을 선택하고 만들고자 하는 Log Group의 이름을 입력하면 됩니다. 이미 만들어 둔 Log Group이 있다면 해당 Log Group을 선택해도 무방합니다. 다만 그 경우 다른 성격의 Log가 섞일 수도 있겠죠?

Log Group의 이름은 식별이 용이하도록 Place Holder에서 가이드 하는 것처럼 `/aws/route53/#zone이름#`을 사용하는 것을 권장드립니다. 물론 `/aws`를 넣는것이 필요한가는 잘 모르겠습니다만... 여튼 그렇습니다. 값을 입력하고 하단의 `Create`버튼을 누르면 Log Group이 생성되고 다시 Hosted Zone 관리 화면으로 이동하게 됩니다. 

CloudWatch Logs에서 생성된 Log Group 확인

Route53 관리 화면에서 Log Group 생성을 마쳤으면 CloudWatch 관리 화면으로 이동하여 생성된 Log Group을 확인해 보도록 하겠습니다. CloudWatch 관리 화면의 왼쪽 메뉴중 `Logs` 하위에 있는 Log groups 메뉴를 선택합니다. 생성되어 있는 Log Group 목록이 출력되면 검색창에 /aws/route53 을 입력하거나 Zone 이름을 입력하여 Log Group을 찾을 수 있습니다.

생성된 로그 그룹에 들어가보면 이미 로그가 쌓이고 있는 놀라운 현상을 경험할 수 있습니다. 여느 인터넷 서비스가 그러하듯 DNS의 세계 역시 수많은 크롤러, 봇들이 돌아다니며 취약점을 가진 서버들을 찾거나 정보를 수집하는 경우가 많습니다. 로그가 쌓이고 있다고 해서 당황할 필요는 없겠죠?

여기까지 완료 되었다면 로그를 모으는 과정은 완료되었다고 보셔도 됩니다. 이제 이렇게 모은 로그를 AWS가 제공하는 데이터 관련 도구로 전달하는 작업을 해보겠습니다. CloudWatch Log는 구독 필터(Subscription filters)를 통해 AWS의 다른 제품으로 로그를 전송할 수 있습니다. 

그중 가장 단순하게 구성할 수 있는 것이 Elasticsearch 로 전송하는 방법입니다. 물론 Kinesis Data Stream으로 전송하는 `Kinesis subscription filter`도 있고 Kinesis Data Firehose로 전송하는 `Kinesis Firehose subscriptino filter`도 있습니다. 하지만 이쪽으로 전달하여 로그를 분석하는 것인 본 포스팅 시리즈에서는 다루지 않습니다. 

(2022.04.21 Update) AWS의 ElasticSearch가 OpenSearch로 바뀌면서 Actions 메뉴도 변경이 되었습니다!

여기부터는 조금 설정할 것들이 많아집니다. 다음 포스팅에서는 ES Cluster로 데이터를 보내기 위해 필요한 작업들을 하나씩 해보도록 하겠습니다. 

이어지는 글...

AWS에 대한 체계적인 공부가 필요하다면 아래의 Udemy 강의를 추천드립니다!

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

AWS에서 컴퓨팅 인프라를 운영하려면 머리가 아픕니다. 
늘 쓰던 것을 쓰면 큰 문제도 고민도(가령 묻지도 따지지도 않고 EC2) 없지만
새로운 제품을 써보려고 하면 일단 제품을 이해하는 것부터 허들입니다 ㅎㅎ
물론 한번 쓰기 시작하면 주머니가 탈탈 털릴 정도로 잘 쓰게 되긴 합니다. 

근래에 k8s 쪽을 다룰일이 계속 생기다 보니 AWS의 제품들에도 관심을 갖게 되었고
AWS가 제공하는 컨테이너 오퍼링을 한번 정리해보고 갈 필요가 생겼습니다. 
도대체 제품 설명만으로는 "뭥미?" 하는 경우가 종종 있으니...

그 중, 유명한 4가지 제품들을 한번 정리해 보겠습니다. 
순서대로 ECS, EKS, Fargate 그리고 ECR 입니다.

ECS, EKS vs. EC2, Fargate

ECS, EKS 를 하나로 묶고 EC2, Fargate를 하나로 묶을 수 있습니다. 
ECS는 Elastic Container Service로 Container 기반의 컴퓨팅 플랫폼이라 보면 되고 
EKS는 Elastic Kubernetes Service로 Container 기반이지만 k8s가 환경이라 보면 됩니다. 

이 두가지가 컨테이너에 대한 오케스트레이션을 담당한다고 보면
EC2, Fargate는 ECS, EKS가 동작하는 호스팅에 대한 레이어를 담당하는 제품들입니다. 
즉, EC2와 Fargate 위에 ECS, EKS가 동작한다고 이해하면 됩니다.

한줄 요약 : EC2, Fargate는 컨테이너를 위한 컴퓨팅 리소스이다 

ECS vs. EKS

그렇다면 ECS와 EKS는 어떤 차이가 있을까요?
둘다 컨테이너 오케스트레이션 환경이라는 공통점을 갖고 있지만 
ECS는 AWS 에서만 제공되는 오케스트레이션 환경이라 타플랫폼으로의 이식성이 떨어지지만
EKS는 쿠버네티스 환경이라 플랫폼간 이전이 더 용이합니다. 

한줄 요약 : ECS는 AWS Only, EKS는 범용 k8s

EC2 vs. Fargate

EC2는 워낙 유명하니 다들 잘 아실겁니다. 
쉽게 생각해서 가상머신(VM)이라고 봐도 무방합니다. 
즉, 독립된 환경이 있고 운영체제를 갖고 있는 컴퓨팅 리소스입니다. 

반면 Fargate는 가상머신보다 더 추상화된 컴퓨팅 환경입니다. 
서버 없이 코드를 실행하는 람다 Lambda 를 서버리스 Serverless 라고 부르는 것처럼
Fargate는 EC2의 서버리스 버전이라고 생각할 수 있겠습니다. 
서버가 없는 컴퓨팅 환경이 Fargate 입니다

한줄 요약 : 독립된 운영체제가 있으면 EC2, 서버리스 컴퓨팅 환경은 Fargate

참고 : https://aws.amazon.com/ko/blogs/korea/how-to-choose-aws-container-services/

Considerations

ECS와 EKS를 봤을때 느낌적 느낌으로 EKS가 비용이 더 나올것이라고 예상됩니다.
네, 정확히 그렇고 ECS가 비용적으로는 EKS 보다 저렴합니다. 
하지만 ECS는 k8s가 아니기 때문에 이야기 한 것처럼 이식성이 떨어집니다. 

어떤 플랫폼을 쓰던 비용을 계속 체크하면서 써야 하는 것이 퍼블릭 클라우드입니다. 
ECS, EKS, 그리고 EC2, Fargate...!
여러분의 선택은 무엇입니까? :-)

지난주 후반부, 한국 뿐만 아니라 전세계가 시끌시끌했습니다. 
사실상의 서버측 로깅 표준으로 자리잡힌 log4j 로깅 모듈의 보안 취약점이 발견되었고
공격방법이 인터넷에 고개되면서 Zero Day Vulnerability 가 발생했기 때문입니다.

취약점을 간단히 요약하자면,
"로그로 기록되어야 하는 문자열에 악의적인 내용을 집어넣어 원격지에서 서버의 코드, 명령을 실행할 수 있는 취약점이 있었음"
입니다.

취약점을 통해 외부에 노출되지 않은 LDAP 서버 등으로 악의적인 코드가 담긴 자바 클래스를 전송하고 
log4j 를 통해 이 클래스를 메모리에 로딩하는 방식으로 서버에 침투하게 됩니다. 
이번 취약점은 오래전 SSL 프로토콜의 취약점으로 명성을 날렸던 하트블리드(heartbleed)급으로 알려졌습니다.

취약점에 대한 대응은 크게 두가지 방식으로 진행되었습니다. 
1. 취약점이 패치된 log4j 가 배포되기 전까지는 코드 인젝션이 발생할 수 있는 JNDI 의 옵션을 끈다
2. 취약점 패치 버전 (2.15.0+) 가 배포된 후에는 새로운 log4j 로 교체한다

이런 대응이 여러 회사의 개발조직 중심으로 대응되는 동안 
물들어올때 노를 저어야 한다는 것을 잘 알고 있는 클라우드 벤더들은 
열심히 관련된 포스팅을 날리며 자사의 보안 솔루션들을 홍보하기 시작했습니다. 

간만에 글로벌 초대형 급의 취약점으로 주말이 시끌시끌 했습니다. 
아직까지 취약점은 현재 진행형이기 때문에 두눈 부릅뜨고
log4j 를 쓰는 곳이 없는지 살펴봐야 하겠습니다!

AWS의 CDN 제품인 CloudFront는 원본 서버에서 제공하는 기본 오브젝트를 지정할 수 있는 기능을 제공하고 있습니다. 보통은 원본 서버에서 사용하는 웹 서버에서 기본 오브젝트를 지정하는 경우가 많지만 S3 등 다른 제품을 함께 사용할 때는 기본 오브젝트를 지정할 수 있는 방법이 없기 때문에 파일명을 지정할 수 있는 기능이 필요합니다.

기본 루트 오브젝트 설정 Set Default Root Object

CloudFront Distribution의 기본 설정 탭에서 기본 루트 오브젝트를 설정할 수 있습니다. Distribution 목록에서 작업하려는 Dist ID를 선택하여 상세 화면으로 진입합니다. 상단 탭중 첫번째 탭인 General 탭으로 이동합니다. Settings 섹션의 `Edit` 버튼을 눌러 상세 설정 화면으로 진입해 봅니다. 

Edit 화면의 중간 정도를 살펴보면 `Default root object - optional` 항목을 찾으실 수 있습니다. 이곳에 지정된 파일 이름이 CloudFront를 통해 접근시 사용되는 기본적인 파일 이름이 됩니다. 가령 www.iamnopd.com  이라는 도메인이 있다고 가정했을 때, 브라우저에 www.iamnopd.com  만 입력해도 알아서 index.html 을 찾아 사용자 브라우저로 응답을 하게 되는 거죠. 

다양한 경로에 대한 기본 오브젝트 설정 

그런데 문제가 있습니다. `Default root object`에 지정한 파일 이름은 진짜, 레알, 루트 경로에 대한 요청에 대해서만 적용되는 한계가 있습니다. 가령 원본이 S3 버킷이라고 했을 때, 버킷의 최상위 경로에도 index.html 이 있고, 버킷에 생성되어 있는 api 폴더의 하위에도 index.html 이 있다고 해봅시다.

아마도 여러분이 기대하는 것은 www.iamnopd.com  접근시에도 index.html 을 읽어들이고 www.iamnopd.com/api  접근시에도 index.html 을 읽어들여 사용자에게 제공되는 시나리오였을겁니다. 하지만 첫번째 케이스와 달리 두번째 api 경로에 대한 접근은 index.html 을 알아서 패칭해오지 않습니다. 반드시 www.iamnopd.com/api/index.html  로 호출을 해야 컨텐츠를 읽어오게 됩니다.

원본의 서로 다른 경로를 특정 사용자 Path의 루트로 바인딩 하기 위해서는 (아시겠지만) 아래와 같이 동일 원본을 Origin Path만 분기하여 등록하면 됩니다. 이 구성과 Default root object 의 조합은 /api 경로에 대해서 적용되지 않는다는 상황으로 이해하지면 될 것 같습니다. 그러면 어떻게 하면 될까요?

CloudFront Function을 이용한 경로 조작

S3에서 뭔가를 하면 되지 않을까? 하고 생각했을지도 모르지만 그것보다는 CloudFront Function을 쓰면 간단하게 구현할 수 있습니다. 아시겠지만 Lambda@Edge를 쓰는 것보다 CloudFront Function을 쓰는 것이 사용도 간편하고(=기능이 다소 적고) 비용도 저렴합니다. 묻지도 따지지도 말고 바로 코드를 보겠습니다.

function handler(event) {
    var pathFrom = /^\/api$/g
    var pathTo   = '/api/index.html'
    var pathDecided = '';   
	var request = event.request;
    pathDecided = request.uri;

	if (pathDecided.match(pathFrom) != null) {
    	pathDecided = pathDecided.replace(pathFrom, pathTo);
	}

    request.uri = pathDecided;
    return request;
}

코드는 무척 간단합니다. 간단한 Regex 를 이용하여 들어온 URI (request.uri)를 단순히 문자열 비교한 후에 실제로 원본이 받게될 URI 를 변경해서 return 해주는 코드입니다. 요청량이 많아도 크게 부담스러운 금액이 나오지는 않을것 같습니다. 간단하지만 Default root object가 단일 경로에 대해서만 적용되는 제약을 회피(?)하는 방법을 살펴봤습니다 :-)

테스트도 참 쉽죠? 원하는 결과를 테스트를 통해 얻었다면, 만든 함수를 적용하고자 하는 Distribution의 Behavior의 Viewer Request 함수로 지정하면 됩니다. 끝!