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로 데이터를 보내기 위해 필요한 작업들을 하나씩 해보도록 하겠습니다. 

---

이어지는 글...

 

(#2/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4 AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라..

ondemand.tistory.com

 

 

(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확

ondemand.tistory.com

 

(4/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정

ondemand.tistory.com

 

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

 

[NEW] Ultimate AWS Certified Cloud Practitioner - 2021

Pass the Amazon Web Services Certified Cloud Practitioner CLF-C01 exam, Practice Exams included with explanations!

www.udemy.com

 

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

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 함수로 지정하면 됩니다. 끝!

 

 

 

 

두 번의 포스팅을 통해 VPC 와 Gateway 를 생성했습니다. 그럼 EC2 를 바로 만들면 되나요? 라고 생각하실 수 있겠습니다만 일단은 생성한 VPC 가 Gateway 를 통해 인터넷과 교감을 할 수 있도록 라우팅 테이블 Routing Table 을 설정하는 작업을 먼저 진행해 보겠습니다. 사실 순서는 큰 상관이 없지만 <네트워크에 대한 작업> 을 마무리하고 <서버에 대한 작업>을 한다고 생각하시면 좋겠습니다. 

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #1

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격

ondemand.tistory.com

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #2

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성`

ondemand.tistory.com

AWS 환경 준비 IPv6 대역을 갖고 있는 신규 VPC 생성 ("OpenVPN 구축 #1" 포스팅) VPC 내에 Public Subnet 생성 ("OpenVPN 구축 #1" 포스팅) Gateway 구성 : Internet Gateway / Egress Only Internet Gateway ("OpenVPN 구축 #2" 포스팅) Routing Table 조정 (본 포스팅!) IPv6 주소를 갖는 EC2 배포 (본 포스팅!) OpenVPN 설치 및 구성 VPN 접속 시험 기타 라우팅 조정

---

1.4 Routing Table 조정

라우팅 테이블 Routing Table 은 VPC 로 들어오는 트래픽과 나가는 트래픽에 대한 경로를 지정해 주는 역할을 합니다. 물론 라우팅 테이블만 설정했다고 하여 모든 통신이 정상적으로 이루어지는 것은 아닙니다. 말 그대로 경로에 대한 지정일 뿐, 실제 트래픽을 허용할 것인지는 Network ACL 과 Security Group 을 통해 IP 주소 대역, 포트 단위로 결정됩니다.

라우팅 테이블을 설정하기 위해서는 VPC 제품 하위 메뉴에 위치한 <Route Tables> 를 통해 진행할 수 있습니다. 기본적으로 VPC 가 생성되면 VPC 에 대한 기본 라우팅 테이블이 자동으로 생성됩니다. 기본 라우팅 테이블은 VPC 에 할당된 IPv4, IPv6 주소를 대상으로 VPC 내에서 (=local) 통신이 가능하도록 하는 정책만 들어 있는 상태입니다.

우리가 해야하는 일은 위 이미지의 핑크색 상자에 들어 있는 내용과 같이 외부로 부터의 트래픽 송수신을 위한 정책을 추가하는 것입니다. IGW (Internet Gateway) 로는 SSH 접근을 위해 IPv4 에 대한 정책을 추가했고, EIGW (Egress Only Internet Gateway) 에는 실제 v6 주소 목적지에 대한 VPN 터널링을 위해 IPv6 주소에 대한 정책을 추가했습니다.

정책 추가를 위해 라우팅 테이블 목록에서 IPv6 용으로 만든 VPC 에 할당된 기본 라우팅 테이블을 선택합니다. Actions 버튼을 누르지 않아도 화면 아랫쪽에서 <Routes> 탭을 선택하면 라우팅 테이블에 대한 상세 정책 목록이 출력됩니다. 정책 추가를 위해 <Edit routes> 버튼을 누르겠습니다. 

IPv4 의 모든 주소를 나타내는 CIDR block 은 0.0.0.0/0 으로 표기되며, IPv6 의 모든 주소를 나타내는 CIDR block 은 ::/0 으로 표기합니다. 목적지 주소에 v4, v6 에 대한 CIDR block 을 추가하고 v4 는 IGW 로, v6 는 EIGW 를 이용하도록 대상(Target) 제품을 지정해 줍니다. 이미 생성한 IGW 와 EIGW 가 드롭 다운 목록에 노출되기 때문에 설정은 쉽게 하실 수 있습니다. 경로 입력이 끝나면 우측 하단의 <Save Routes> 버튼을 누릅니다. 

 

1.5 IPv6 주소를 갖는 EC2 인스턴스 배포

네트워크의 구성이 끝났으니 이제 실제 OpenVPN 바이너리가 구동되고 목적이 v6 주소까지 터널링을 해줄 EC2 인스턴스를 생성해 보도록 하겠습니다. 사용자가 얼마나 많은지, 트래픽 규모가 어떠한지에 따라 인스턴스 타입이 결정되어야 하겠지만, 이 포스팅에서는 AWS 무료 티어에서도 사용할 수 있는 t2.micro 타입의 인스턴스를 사용하도록 하겠습니다. 소규모의 사용량이라면 이 인스턴스로도 큰 문제가 없습니다. 

EC2 인스턴스의 생성은 많이들 해보셨을 작업이기 때문에 주의할 점을 중심으로 설명드리겠습니다. EC2 생성 마법사의 세번째 단계에는 IP 주소 할당에 대한 정책을 선택하도록 되어 있습니다. 우리가 진행하는 OpenVPN 은 단일 인스턴스 환경이기 때문에, 해당 서버가 사용자들로부터 IPv4 를 통해 VPN 연결을 시도할 수 있어야 하고, IPv6 주소를 보유하여 v6 주소를 갖고 있는 목적지 서버와 연결할 수 있어야 합니다. 

 

이 목적을 달성하기 위해서는 <3. Configure Instance> 단계에서 하단에 있는 <Auto-assign Public IP> 와 <Auto-assign IPv6 IP> 를 Enable 로 선택하여 v4 와 v6 를 통해 공인 IP 를 사용할 수 있도록 해야 합니다. 그런데 IPv6 는 왜 <Public> 이라는 말이 없을까요? 기본적으로 IPv6 주소 체계는 Private / Public 를 가지고 있지 않습니다. 따라서 옵션의 이름도 단순히 <Auto-assign IPv6 IP> 라고 되어 있다는 점 참고하시기 바랍니다!

EC2 생성 마법사를 완료하고 인스턴스 생성을 기다립니다. 생성이 완료되면 위와 같은 화면을 볼 수 있게 됩니다. 다른 기본적인 사항은 특별히 확인할 내용이 없고, 네트워킹 Networking 탭을 중심으로 살펴보면 됩니다. 설명했던 것처럼 v4 는 Private, Public 의 주소가 할당되지만 v6 는 하나의 주소만 할당된 것이 보입니다. 이제 인프라의 준비가 끝났습니다. 

---

 

다음 포스팅에서는 OpenVPN 을 인스턴스에 설치하는 작업을 해보도록 하겠습니다. 

시장을 선도하고 있는 사업자의 움직임은 늘 새롭습니다. 모든 산업 영역이 그런 것은 아니지만 IT 분야, 특히 최근 화두인 클라우드 분야에서 만큼은 그런 것 같습니다. 퍼블릭 클라우드 서비스(Public Cloud Service) 부동의 선두주자인 아마존이 또 하나의 재미있는 모델을 내놓았습니다. 바로 AWS Marketplace 가 그것입니다. 아마존이 만든 클라우드 장터는 어떤 모습인지 가볍게 한번 보도록 하겠습니다.

 
AWS Marketplace 는 기본적으로 커스터마이징된 AMI(Amazon Machine Image)의 판매와 SaaS(Software as a Service) 사업자의 상품 판매 채널의 역할을 수행하는 모습입니다. 아마존 AWS 가 가지고 있는 장점 중 하나가 사용자들이 직접 AMI를 만들고 이를 통해 인스턴스를 생성할 수 있다는 것입니다. AWS Marketplace 는 이렇게 잘 설정하여 만든 서버 이미지를 일정한 비용을 받고 팔 수 있도록 했습니다. SaaS 사업자들에게는 AWS 의 빌링, 인프라스트럭쳐를 활용하면서 서비스의 제공에만 집중할 수 있도록 그림을 만들어 두었습니다. 

판매되고 있는 주요 AMI 를 보면 소프트웨어 인프라스트럭쳐(Software Infrastructure)가 가장 많습니다. 아무래도 AMI 를 커스터마이징해서 판매하는 형태이다 보니 자사의 소프트웨어 프레임워크, 미들웨어를 설정한 이미지를 파는 경우가 많아 보입니다. 재미있는 것은 Jumpbox 라는 파트너를 통해 다양한 오픈소스 탑재 AMI 도 제공하고 있다는 점임니다. 요즘 좋은 오픈소스들이 워낙 많다보니 이들의 사용량도 폭증하는 추세입니다. 하지만 문제가 발생하거나 설정상의 어려움을 겪을때 직접 문제점을 트러블 슈팅 해야한다는 이슈가 있었는데 이런 가려움을 긁어주는 방법으로 선택한 모델이 아닌가 싶습니다.



현재 참여중인 소프트웨어 벤더들로는 Microsoft 가 운영체제 중심으로 AMI 포트폴리오를 내놓았고 SAP, CA, McAfee 등이 상품을 등록해 놓고 판매를 시작했습니다. 소프트웨어의 판매를 원하는 회사를 발굴하고 있다는 메세지도 최상단에 놓여 있어 본격적으로 시장 활성화를 위해 달리는 모습이 눈에 보입니다. 아마존의 AWS Marketplace 가 얼마나 성공을 거둘수 있을지 한번 지켜봐야 하겠습니다.

- NoPD -