Cloud Computing On Demand

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정 매핑 작업이 남아 있습니다. 사실 어떤 계정으로 ES Cluster가 제공하는 Kibana를 쓸 것이냐는 선택이 폭이 무척 넓고 구현 방법도 다양합니다.

특히 보안관점에서 탄탄해지려면 이 포스팅 시리즈의 내용만으로는 부족합니다. 다만 우리의 목적은 빠르게 로그를 적재해 보는 것이기 때문에 앞선 포스팅들에서도 간단하게 IP를 통해 접근을 제어하고 별도로 만든 특정 Master Account로 로그인하도록 했었습니다.

여기에 더하여 AWS가 ES Cluster에 데이터를 적재할 수 있도록 하기 위해서 Lambda를 위해 생성한 IAM Role을 ES Cluster의 권한에 매핑하도록 하겠습니다.

IAM Role을 Kibana에 매핑하기

먼저 Kibana에 생성했던 Master Account로 로그인을 합니다. 좌측 메뉴의 `Open Distro for Elasticsearch > Security` 메뉴에 진입하면 7개의 서브 메뉴가 나옵니다. 그 중 `Roles`를 선택하고 쓰기 권한이 있는 특정한 Role을 찾거나 만들도록 하겠습니다.

간단한 시험을 위해 여기서는 `all_access` Role을 사용하도록 하겠습니다. 네, 보안적으로 좋은 프랙티스는 아닙니다!

ES Cluster의 all_access Role에 Lambda에 부여한 AWS IAM Role의 ARN을 매핑해 줘야 합니다. 잠시 AWS의 IAM 관리 화면으로 넘어가서 Role화면으로 이동하겠습니다.

ES Cluster의 Role인지 IAM의 Role인지 헷갈리지 않도록 유의하시기 바랍니다! IAM 관리 화면에서 앞서 생성한 Lambda용 Role을 찾아 해당 Role의 ARN을 복사하겠습니다.

복사한 ARN을 ES Cluster의 Kibana 화면에서 선택한 쓰기 권한이 있는 Role에 추가해 줍니다. Mapped Users 탭의 Manage mapping 버튼을 누르고 Backend Roles 에 ARN을 추가한다음 Map 버튼을 누릅니다. 에러가 발생하지 않았다면 문제가 없는 것입니다.

이제 거의 끝났습니다. 쓰기 권한이 있는 ES Cluster Role에 IAM Lambda Role이 연결되었기 때문에 로그가 클러스터에 적재되기 시작했을 겁니다. 만약 이렇게 했는데도 로그가 쌓이지 않는다면 권한 부여하는 과정에 잘못된 ARN을 복사해 왔을 가능성이 있습니다. 차근히 화면을 보면서 다시 설정하시면 문제 없을 것이라 생각합니다.

이제 `Index Management`로 이동하여 로그가 들어오는지 확인해 보겠습니다. CloudWatch Logs에서 보내는 로그의 기본 인덱스명은 cwl로 시작합니다. 아래와 같이 cwl로 시작하는 로그들이 들어오는게 보이는지 확인하겠습니다.

이제 좌측 메뉴의 `Kibana` 섹션에서 Discover 메뉴를 선택하고 인덱스 패턴을 만들어 보겠습니다. 여기부터는 ES 혹은 Kibana의 영역이기 때문에 더 자세한 설명은 생략하도록 하겠습니다. 인덱스 패턴까지 만들고 저장했다면 이제 로그를 쿼리할 수 있게 됩니다.

생성한 인덱스에 우리가 앞서 Subcription filter 생성시 지정했던 것처럼 Field 이름들이 잘 들어오고 있는지도 확인할 수 있습니다. 대략 보니 크게 문제 없어 보입니다. 눈치 채셨겠지만 filter 설정시 사용한 컬럼 이름들이 Kibana의 Field로 사용되기 때문에 적절한 키워드를 사용해 주시면 되겠습니다.

Kibana의 Discover 화면에서 최근 15분간의 데이터를 조회해 봤습니다. 네~ 무척 잘 들어오고 있습니다. 모자이크 처리를 해두긴 했지만 지정한 컬럼별로 데이터가 잘 꽂히고 있는 것을 확인할 수 있었습니다.

아직 실트래픽이 실리고 있지 않아 쿼리 규모가 아주 작습니다만 실제 사용자 트래픽을 수용할 때는 적절히 클러스터의 규모를 조정해 줄 필요가 있습니다.

Elasticsearch 에 데이터가 적재되지 않을때 트러블 슈팅

이렇게 고생해서 셋업을 했는데 ES 클러스터에 데이터가 적재되지 않는 경우 무척 난감하실겁니다. 리소스들을 다시 정리하는 것도 일이고... 어디서 잘못된 것인지 찾는것도 스트레스입니다.

대부분의 경우 AWS CloudWatch Logs 기술 문서와 ElasticSearch 기술 문서에 내용이 나와 있긴 하지만 그래도 잘 안되는 경우 아래의 문서를 참고하실 수 있습니다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/

지금까지 4개의 포스팅을 통해 Route53의 DNS 쿼리 로그를 CloudWatch Logs와 Elasticsearch를 활용하여 적재하고 분석하는 환경을 만들어 봤습니다.

DNS 쿼리는 상용 서비스 단계에서 무척 많은 로그를 남기게 됩니다. 때문에 많은 기업들이 on-premise에서 활용하는 서비스용 Authoritative NS에 대해서는 평상시에 로그를 특별히 남기지 않는 경우도 많습니다.

AWS를 통해 Route53을 쓰는 것은 일종의 Managed DNS 또는 Managed GSLB를 쓰는 것ㅇ기 때문에 서버의 로그를 바로 획득하기 어렵습니다.

하지만 (돈을 조금 낸다면.. 속닥속닥..) 로그를 쉽게 적재하고 분석할 수 있는 방법이 제공되고 있으니 필요할 때 유용히 활용할 수 있으면 좋겠습니다. 시리즈 글은 아래의 링크들을 참고하시기 바랍니다!

본 블로그의 글들은 제휴 마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

2021년이 밝았습니다. 새해가 되면 여러가지 계획을 세우기 마련인데요, 작심삼일이 되지 않도록 3일마다 마음을 다잡을 필요가 있습니다. 계획성 있게 하기에 좋은 것이 역시 자격증 취득인지라, 기술 습득과 자격 취득을 한번에 할 수 있는 좋은 자격 프로그램들이 많습니다.

그 중에서도 IT 직군에 계신 분들이 가장 관심이 많은 것이 AWS 의 자격증들일 것입니다. 그 시작점이라고 할 수 있는 자격증이 Solutions Architet Associate 라고 생각합니다. 저 역시 2019년 11월에 취득을 했는데요, 공부 방법을 간단하게 정리해 보았습니다.

AWS SAA 시험의 개요

AWS 의 Solutions Architect 시험은 AWS 의 제품들을 잘 이해하여 비즈니스 요구사항을 수용할 수 있는 인프라 환경을 설계할 수 있는 능력을 시험합니다. 방대한 AWS 제품들을 공부해야 하기 때문에 계획성 있게 학습하는 것이 중요합니다. 

특히 SAA 시험은 고객의 비즈니스 상황, 문제 시나리오에 대하여 어떤 식으로 대응할 것인지를 묻는 문제들이 여럿 출제됩니다. 따라서 문제 상황을 잘 이해하고 적절한 해결 방안을 AWS 의 제품, 그리고 제품의 특징을 활용하여 해소할 수 있는 방법을 제시해야 합니다. 이같은 시험 문제 패턴은 시험 요강에서도 확인할 수 있습니다. 

상당히 실무적인 시험이기 때문에 실전 경험이 많다면 자격증을 준비하는 것이 훨씬 수월합니다. 하지만 실전 경험이 부족하다 하더라도 다양한 자료를 통해서 학습하고 시험에 응시하여 충분히 취득할 수 있는 자격이기도 합니다. 어떤 방향으로 공부를 해야 하는지 역시 공식 가이드에 잘 나타나 있습니다. 

공식 시험 가이드 및 자료

시험에 대한 공식 가이드가 상당히 자세히 제공됩니다. 가장 먼저 보면 좋은 자료는 예제 문항과 시험 안내서입니다. 흔히 자격시험은 기출문제 풀이나 족보를 찾기 십상인데요 제대로 실력을 함양하기 위해서는 덤프는 가능한 보지 않을 것을 권장드립니다. 대신 온라인 강의 등에서 챕터별로 제공되는 연습문제를 충실히 풀어내면 합격하는데 큰 지장은 없습니다. 

> AWS 공식 시험 준비 가이드 [바로가기]
> AWS 시험 안내서 [바로가기] - 출제 비중에 관한 내용이 언급되어 있습니다
> SAA 시험 공식 예제 [바로가기] - 공부 시작전에 꼭 읽어보시기 바랍니다!

글을 적으며 Udemy 에 들어가보니 2021 년 새해를 맞이하여 Udemy 에서 연습문제를 20달러에서 9.99달러로 할인 판매를 하고 있습니다. 1월 4일까지 할인이라고는 하지만 연장될 수도 있으니 관심 있는 분들은 구입해 보시는 것도 좋겠습니다! 참고로 AWS 공식 시험 등록 센터에서는 20달러에 판매됩니다. (65문항씩 6개의 시험 자료가 들어가 있습니다)

추천 온라인 강의 - Udemy

유튜브나 블로그에도 좋은 자료를 정리해 주신 분들이 많습니다. 하지만, 개인적으로 추천드리는 것은 Udemy 의 아래 강의입니다. 영어 발음도 또렷해서 듣기에 어렵지 않고, 시험을 영어로 치는 경우에 많은 도움이 됩니다. 짧은 동영상들로 구성되어 있어 출퇴근길에 한 두개씩 듣거나, 화장실, 산책길에 틈틈히 학습하기에 좋습니다. 

요즘 강의 시장도 경쟁이 치열하다보니 구입한 강의에 대한 유지보수(?)도 잘 됩니다. AWS 는 지속적으로 개선되고 진화하고 있기 때문에 주기적으로 시험도 갱신이 됩니다. 이 강의를 제공하는 Ryan 님도 [SAA-C02] 등으로 최신 시험 범위에 맞추어 컨텐츠를 계속 업데이트 해주고 있습니다. 

지금 보니 제가 구입한 이 강의도 9.99 달러로 2021년 얼리버드 할인이 진행중이네요! 저는 거의 2만원돈 주고 샀던것 같은데... 여러분 꿀 기회를 놓치지 마십시오! 뭘 하던간에 연초에 하나 정도 몰아쳐야 한다는 것, 다들 아시죠? 인간의 의지는 박약합니다!

[ Udemy - AWS SAA-02 시험 강의 살펴보기 (바로가기) ]

(2021.08 업데이트) Cloudguru가 Pluralsight에 인수되면서 강의들이 Udemy에서 일단 다 빠진 것 같습니다. 그 다음으로 대권(?)을 잡은 강의를 추천해 드립니다! Cloudguru의 Ryan님이 미국 스타일의 발음으로 유쾌한 강의를 해주었다면, Stephane님의 아래 강의는 제2외국어로 영어를 배운 사람의 느낌으로 조금 더 편안한(?) 발음으로 강의를 해주고 있습니다. 그래도 꼼꼼히 시험에 필요한 것들과 AWS의 기초 지식을 잘 챙겨주고 있다는 점에서는 동급 최강이라 하겠습니다! 2021년 버전으로 업데이트가 되었으니 한 번 살펴보시기 바랍니다!

[ Stepane님의 AWS SAA-C02 시험 강의 살펴보기 (바로가기) ]

시험 등록

재미있는 것은 시험을 위한 연습 시험도 유료로 볼 수 있습니다. 최근에 취득한 자격이 AWS 자격증 하나이다보니 다른 기술 자격증도 이런 유료 연습 시험이 있는지는 잘 모르겠습니다. 비용은 20달러로 크게 부담되지 않지만 꼭 쳐봐야 하는 것은 아닙니다. 앞서 말씀드린 것처럼 연초 얼리버드 할인 9.99 달러 행사중이니 필요하신분은 공식 사이트 대신 Udemy 에서 구입하시면 좋을 것 같습니다.

시험은 150 달러로 비싼편은 아닙니다. 한국어로 시험을 볼 수도 있지만 그냥 영어로 보는 것이 훨씬 편합니다. AWS 의 한글 자료들이 잘 되어 있는 편이긴 하지만 꼼꼼히 보다보면 번역기를 돌렸거나 비전공자가 번역하여 문제가 있는 경우들이 종종 발견됩니다. 영어로 보고, 영어로 시험 보는 것이 베스트입니다.

[ 시험등록하러 가기 (바로가기) ]

올 한해는 연초부터 좀 달려보려고 이것저것 공부를 하고 있습니다. AWS 도 SAA 취득한지 1년이 넘었으니 다른 자격증을 준비해 보려는 중입니다. 여러분들도 힘차에 2021년을 시작하는 의미에서 자격증 취득 어떠십니까? :-)

본 포스팅은 직접 돈내고 취득한 AWS 자격증 이야기 입니다.
다만, 제휴마케팅을 통해 소정의 수수료를 받을 수 있습니다.

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

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 을 인스턴스에 설치하는 작업을 해보도록 하겠습니다. 

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성` 을 했고 `VPC 내에 Public Subnet 생성` 까지 완료했습니다. 자세한 내용은 아래 링크를 통해 지난 포스팅을 참고하시기 바랍니다!

1.3. Gateway 구성

1.3.1. Internet Gateway

OpenVPN 을 이용한 IPv6 VPN 구성시 VPC 에는 두개의 Gateway 가 필요합니다. 보통 v4 주소 환경에서 인터넷으로 나가고 들어오는 트래픽 처리를 위해 사용하는 Internet Gateway 가 첫번째 요소입니다. v4 주소라고 명기한 것은 다 이유가 있겠죠? Internet Gateway 는 나가는 트래픽, 즉 아웃바운드 트래픽에 대하여 IPv6 주소를 처리하지 못합니다. 이 때문에 별도로 Egress Only Gateway 를 구성해야 합니다.

정리를 잘 해두기 위하여 위의 내용은 취소선으로만 표기하고 나두었습니다. AWS 에서 제공하는 Gateway 에는 Internet Gateway 와 Egress Only Internet Gateway 가 있습니다. Internet Gateway 는 양방향 (Inbound, Outbound) 의 인터넷 트래픽을 위해 사용하는 구성 요소이고 Egress Only Internet Gateway 는 단방향 (Outbound) 전용 게이트웨이 입니다. 

왜 그렇게 기억하고 있었는지 모르겠지만 OpenVPN 을 통해 실제 IPv6 를 사용하는 서버까지 터널링을 위해서 꼭 Egress Only Internet Gateway 를 사용할 필요는 없습니다. 다만, 각 인스턴스로 IPv6 로 요청이 들어오지 않도록 확실히 분리할 필요가 있다면 IPv6 터널링 용으로 Egress Only Internet Gateway 를 사용하면 됩니다.

Internet Gateway 를 생성하기 위해 VPC 제품 페이지에서 Internet Gateway 메뉴로 들어갑니다. 별도의 VPC 를 만들었기 때문에 Default VPC 에 있는 Internet Gateway 를 사용할 수는 없습니다. Internet Gateway 는 VPC 단위로 연결할 수 있다는 것도 기억해 두면 좋겠습니다. 제 경우 구분을 위해 Tag 에 "ipv6" 를 넣어주었습니다.

Internet Gateway 가 생성되면 어떤 VPC 와도 연결되어 있지 않은 상태입니다. 아래의 화면에서 보이는 것처럼 Detached 라는 메세지가 연결된 VPC 가 없다는 것을 알려줍니다. 우측 상단의 "Actions" 버튼을 눌러 앞서 생성한 VPC 에 연결(Attach) 해보도록 하겠습니다. 

앞서 가이드 했던 것처럼 VPC 생성시에도 Tag 를 잘 달아두었다면 Attach to VPC 를 하는 과정에 어려움 없이 VPC 를 잘 선택할 수 있습니다. 물론 제 경우 VPC 가 하나라서 Tag 가 있고 없고 상관은 없습니다만 규모가 좀 되는 인프라를 운영중이시면 Tag 가 확실히 도움이 될 겁니다. VPC 를 선택후 <Attach internet gateway> 버튼을 눌러 연결 작업을 마무리 합니다. 

연결 작업이 정상적으로 완료되면 아래와 같은 Summary 화면을 보게 됩니다. 연결한 내용에 이상이 없는지 한 번 살펴보고 지나가시면 됩니다. 

1.3.2. Egress Only Internet Gateway

설명했던 것처럼 VPN 연결은 IPv4 로만 허용하고 터널링은 IPv6 를 쓰기 위해 Egress Only Internet Gateway 를 따로 만들어 보도록 하곘습니다. AWS 의 제품 설명 페이지를 유심히 읽어 보셨다면 아시겠지만 Egress Only Internet Gateway 는 IPv6 전용입니다. IPv4 를 터널링 한다면 Internet Gateway 만 사용하는 것으로 충분합니다. 

VPC 화면의 메뉴중 <Egress Only Internet Gateway> 를 선택합니다. 새로운 Egress Only Internet Gateway 를 아래 화면처럼 생성하도록 하겠습니다. 일반 Internet Gateway 와 특별히 차이가 없기 때문에 Tag 지정만 유의해서 진행하시면 되겠습니다. VPC 목록에도 Tag 가 표시되기 때문에 VPC 생성시 Tag 를 잘 달아두었다면 어려움 없으실 겁니다. 

생성된 Egress Only Internet Gateway 는 eigw 로 시작되는 고유 ID 를 갖게 됩니다. Internet Gateway 의 생성 화면과 달리 생성 할때 이미 VPC 를 지정했기 때문에 별로도 Attach 하는 과정이 나오지는 않습니다. 비슷한 제품인데 담당 조직이 다른지 생성 화면과 절차가 차이가 있네요? Egress Only Internet Gateway 가 훨씬 편한 것 같습니다 ^^

이번 포스팅에서는 두개의 Internet Gateway 를 생성해 보았습니다. 다음 포스팅에서는 VPC 의 라우팅 테이블을 설정하여 OpenVPN 트래픽이 정상적으로 EC2 를 통해 연결되고 터널링 될 수 있도록 해보겠습니다.