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를 쓰는 것ㅇ기 때문에 서버의 로그를 바로 획득하기 어렵습니다.

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

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

업무에 따라 다르겠지만 개인적으로는 DNS 에 대한 핸들링이 무척 많이 필요합니다. 커맨드라인에서 Shell 스크립트를 이용해서 여러가지를 만들어 사용하고 있긴 하지만, 가능하면 Python 이나 node.js 로 필요한 기능을 만들어 사용하는 것이 좋지 않을까 생각하고 있었습니다.

Python 쪽에서 사용할 수 있는 DNS 패키지가 어떤것이 있는지 살펴보다보니 `dnspython` 이라는 걸출한 물건이 있는 것을 발견했습니다. 패키지 공식 페이지에서 이야기 하는 것처럼 dnspython 은 DNS Toolkit 을 표방하고 있습니다. 정말 많은 기능들을 제공하고 있기 때문에 DNS 관련한 도구 개발에 무척 도움이 될 것 같습니다. 

간단하게는 Resolver 역할을 수행하는 것에서 시작할 수 있고, 좀 멀리 나가면 Zone 에 대한 핸들링도 수행할 수 있는 것 같습니다. 개인적으로 사용해 본 내용이 Resolver 중심이고 도메인 이름에 대한 핸들링 정도여서, 실제 필요한 과제에 맞도록 Research 는 조금 더 해봐야 할 것 같습니다. PyPi 에 패키지가 등록되어 있기 때문에 pip 로 패키지를 설치하면 편리하게 사용해 보실 수 있습니다. 

인터넷을 구성하는 많은 요소들 중 도메인 Domain 은 가장 널리 사용되는 것 중 하나입니다. 도메인은 기억하기 어려운 IP 주소를 사람에게 친숙한 방식으로 제공해주는 기술이지요. 안전한 데이터 교환을 위해 사용되는 HTTPS 와 SSL 인증서 역시 도메인 이름을 적극 사용하고 있습니다. 

도메인 이름에는 보통 알파벳과 숫자, 그리고 몇 가지 기호가 사용되는데요, 오늘은 그 중 알파벳에 대한 이야기를 하고자 합니다. 알파벳은 잘 아시는 것처럼 대문자 Uppercase 와 소문자 Lowercase 로 구분됩니다. 도메인 이름의 규격은 알파벳의 대문자와 소문자 중 어떤 것을 사용하도록 하고 있을까요?

도메인 이름에 관한 규격, RFC 1034

도메인 이름에 대한 규격은 RFC 1034 문서에 기술되어 있습니다. 문서의 제목은 `DOMAIN NAMES - CONCEPTS AND FACILITIES` 로 도메인, 그리고 도메인을 다루는 시스템을 설계할 때 따라야 하는 규격들에 대한 이야기를 하고 있는 문서입니다. 

문서의 초두에 나오는 목적 Goal 절을 읽어보면 도메인 이름의 규격이 왜, 어떻게 정해졌는지를 가늠할 수 있는 내용들이 나옵니다. 그 중에서도 가장 눈에 띄는 것은 역시 영어는 두괄식이다라는 것을 느끼게 해줍니다. 첫번째 문단에 나온 내용은 아래와 같습니다. 

The primary goal is a consistent name space which will be used for referring to resources. (RFC 1034, p2)

DNS 와 도메인을 사용하는 이유는 명확합니다. 네트워크에 연결되어 있는 자원들 중 내가 필요로 하는 리소스를 쉽게, 일관성 있게 찾을 수 있도록 해주기 위함입니다. 이를 위해서 일관된 규칙을 갖는 네임스페이스를 만드는 것이 설계의 목적입니다.

대문자와 소문자를 허용하는 것, 그리고 실제로 그것이 어떤 리소스를 지칭하도록 해야 하는가? 에 대한 답은 이미 여기서 나왔다고 생각합니다. 미국 뉴욕의 엠파이어 스테이트 빌딩을 이야기 할 때, EMPIRE STATE BUILDING 이든 empire state building 이든 상관이 없어야겠죠? (문법적으로 고유명사는.... 과 같은 이야기는 일단 자치합시다!)

대소문자 모두 사용할 수는 있지만 둘은 동일하다!

우리가 궁금해 하는 대소문자 사용에 대한 이야기는 문서의 10 페이지에 언급됩니다. 3.5 절의 뒷 부분에 가면 Note that 으로 시작하는 문장이 나옵니다. 여기서 문서는 도메인을 다루는 시스템에서 도메인 이름은 대소문자를 모두 사용할 수 있다고 이야기 하고 있습니다. 

하지만 중요한 것은 이어지는 문장입니다. "No significance is attached to the case" 대소문자 구분은 별로 의미 없다는 말입니다. 그리고 혹시나 오해가 생길까봐 That is 로 한번 더 확인사살을 해주고 있습니다. 

Two names with the same spelling but different case are to be trated as if identical. (RFC 1034, p10)

즉, 대소문자를 자유롭게 사용할 수 있긴 하지만 동일한 것으로 취급해야 한다는 결론입니다. Stack Overflow 등에 올라오는 글들을 보다 보면 특정한 제품군 등에서는 대소문자를 구분하는 경우도 있고, 브라우저들이 어떻게 핸들링 하는가에 대한 이슈도 있긴 한 것 같습니다. 그렇지만 일단 규격이 이야기 하는 것은 대소문자에 관계 없이 동일한 것으로 취급해야 한다라는 점, 기억해 두시기 바랍니다!