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

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

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

플러터 환경을 새로 준비하다보면 이전에 맛보지(?) 못했던 다양한 에러를 만나곤 합니다. 특히 Java의 버전이 달라진 경우에 이같은 문제가 더 자주 발생합니다. 새로운 애플실리콘 M1 Mac 환경에서 플러터 개발 환경을 새로 셋업하다 만난 Java 에러에 대하여 해결 방법을 정리해 봅니다.

플러터 환경설치시 활용하게 되는 닥터(doctor)는 부족한 환경 설정을 쉽게 진단해주고 어떤 대응을 해야 하는지 알려주는 도구입니다. 문제는 가끔 여기서 알려준 대응 방법을 실행하는 것 자체가 문제가 되는 경우입니다. 오늘 겪은 이슈는 새롭게 플러터 환경 설정시 필요한 안드로이드 라이센스에 대한 동의 과정에서 발생했습니다. 

플러터 닥터의 메세지 살펴보기

안드로이드 스튜디오, 플러터 SDK를 설치한 후 flutter doctor를 수행하여 추가로 진행해야 하는 작업을 살펴보았습니다. 안드로이드 라이센스에 대한 동의가 필요하다고 하여 이 부분에 대한 안내에 따라 명령을 수행했습니다. 이전에 다른 노트북에서도 큰 문제 없이 안내된 명령을 복붙하는 것으로 충분했기에 안내된 명령을 실행했습니다. 그런데...

%  flutter doctor --android-licenses
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
	at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
	at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
	at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 5 more

이전에 만나보지 못했던 새로운 경험... 그것도 굉장히 기본적인 문제가 있는 것처럼 보이는 에러가 똬악 나타났습니다. Java 익셉션이라니... 더 이상의 안내가 없었기 때문에 구글링을 열심히 하여 몇 가지 단서를 찾았고 그 중 하나는 "안드로이드 SDK 커맨드라인 도구"의 설치 부재시 발생할 수 있다는 것이었습니다. 

안드로이드 SDK의 커맨드라인 툴킷 설치하기

안드로이드 SDK의 커맨드라인 툴킷을 설치하는 가장 간단한 방법은 안드로이드 스튜디오의 셋팅 메뉴를 이용하는 방법입니다. 안드로이드 스튜디오를 실행하고 왼쪽 <Customize> 메뉴를 선택하면 아랫쪽에 <All settings...> 메뉴가 보입니다. 메뉴를 선택합니다.

설정 화면이 열리면 <Appearance & Behavior> - <System Settings> - <Android SDK>메뉴를 선택하고 우측의 탭에서 <SDK Tools>를 선택합니다. 예상대로 커맨드라인 툴킷이 설치되어 있지 않은 것이 보입니다. 체크후 설치를 진행해 봅니다. 

안드로이드 라이센스 동의 작업 다시 해보기

100MB 정도 되는 패키지를 다운로드하고 설치하는 과정은 금세 끝납니다. 설치가 완료되었다면 다시 터미널 화면으로 이동하여 플러터 닥터를 이용해 안드로이드 라이센스 동의를 해보니 문제 없이 수행이 됩니다. 참고로 간혹 특정한 동의가 자동으로 되지 않는 경우가 있는데 라이센스 동의 명령을 이용시 상세 내용을 조회하면서 동의를 해주면 모든 라이센스에 동의가 진행됩니다. 

%  flutter doctor --android-licenses
All SDK package licenses accepted.======] 100% Computing updates...

이제 다시 한 번 플러터 닥터를 수행하여 필요한 절차를 살펴보겠습니다. 에러가 표시되던 Android toolchain 항목에 그린라이트가 들어온 것이 확인되네요!

간혹 새로운 장비에서 Dockerfile 을 이용하여 이미지를 빌드해야 하는 경우가 생깁니다. 늘 사용하던 장비와 빌드하던 이미지라면 특별히 문제가 생기지 않지만 새로운 오픈소스 코드나 다른 사람이 만들어둔 Dockerfile을 생각 없이 새 장비에서 빌드하다보면 에러 메세지로 당황하기 마련입니다. 

오늘도 어김 없이 새 장비에서 Dockerfile을 이용한 이미지 빌드 실패건을 겪었는데요 미래의 저를 위해 간단하게 내용을 정리해 봅니다. 한줄 요약을 하자면 Docker의 버전이 낮아서 발생한 문제였습니다. 

새로운 오픈소스를 Docker 이미지로 빌드후 구동하기 위해 소스코드를 클론하고 make docker 명령으로 이미지 빌드를 시도했습니다. go로 개발된 프로메테우스 익스포터류의 코드였는데요 잠시 빌드가 진행되는 듯 하더니 FROM으로 지정된 이미지의 포맷이 잘못되었다는 에러 메세지와 함께 빌드가 실패했습니다. 

$ make docker
docker build -t "akamai/akamai-gtm-metrics-exporter-linux-amd64:master" \
        -f ./Dockerfile \
        --build-arg ARCH="amd64" \
        --build-arg OS="linux" \
        ./
Sending build context to Docker daemon 15.25 MB
Step 1/8 : FROM docker.io/golang:1.16.6 AS builder
Error parsing reference: "docker.io/golang:1.16.6 AS builder" is not a valid repository/tag: invalid reference format
make: *** [common-docker-amd64] Error 1

도커 이미지가 없어서 그런가 생각해봤지만 docker image 명령을 쳐보면 이미지가 정상적으로 로컬 환경에 저장되어 있는 것이 확인되었습니다. 이미지의 빌드 넘버가 없어서 그런가하여 도커 허브에 들어가 golang 태그를 찾아봐도 분명 존재하는 태그였습니다.

$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
docker.io/golang                             1.16.6              028d102f774a        3 days ago          862 MB
docker.io/victoriametrics/victoria-metrics   latest              27ae96c3f0f7        2 weeks ago         23.5 MB
docker.io/prom/prometheus                    latest              9dfc442be98c        3 weeks ago         189 MB
docker.io/victoriametrics/vmagent            latest              4d8a8d15c6ec        4 weeks ago         20.4 MB
docker.io/prom/node-exporter                 latest              c19ae228f069        4 months ago        26 MB

문제는 도커의 버전이었습니다. 빌드하려던 Dockerfile의 내용을 꼼꼼히 살펴보지 않아 Dockerfile이 멀티 스테이지 빌드가 필요하다는 것을 미처 확인하지 못했던 것이죠. 멀티 스테이지 빌드는 경량 도커 이미지를 만들기 위한 방법으로 제공되는 빌드 방식이고 도커 17버전 이상에서 지원되는 것으로 확인됩니다. 도커를 새로운 버전으로 업데이트 하고 다시 빌드를 시도해 보았습니다.

// 설치된 버전 확인
$ docker --version
Docker version 1.13.1, build 7d71120/1.13.1

// 설치된 docker 삭제
$ sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine
                  
// Community Edition 설치를 위한 repo 정보 추가
$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

// 최신 버전의 docker 설치
$ sudo yum install docker-ce docker-ce-cli containerd.io

// docker daemon 구동
$ sudo systemctl start docker

// 설치된 버전 확인
$ docker --version
Docker version 20.10.7, build f0df350

// 이제 빌드가 잘 되네요!
$ make docker
docker build -t "akamai/akamai-gtm-metrics-exporter-linux-amd64:master" \
        -f ./Dockerfile \
        --build-arg ARCH="amd64" \
        --build-arg OS="linux" \
        ./
Sending build context to Docker daemon  15.25MB
Step 1/8 : FROM docker.io/golang:1.16.6 AS builder
1.16.6: Pulling from library/golang
Digest: sha256:4544ae57fc735d7e415603d194d9fb09589b8ad7acd4d66e928eabfb1ed85ff1
Status: Downloaded newer image for golang:1.16.6
 ---> 028d102f774a
Step 2/8 : WORKDIR /go/src/github.com/akamai/akamai-gtm-metrics-exporter
 ---> Running in dab4aaede8da
Removing intermediate container dab4aaede8da
...
..
...
Successfully built a005e3513fae
Successfully tagged akamai/akamai-gtm-metrics-exporter-linux-amd64:master

참 쉽죠!?

아마 대부분의 경우 리눅스 환경에 접근시 루트 권한이 아닌 계정을 쓰고 있을 겁니다. 이 환경에서 docker 명령을 쓰다보면 pull 등 기본적인 명령 수행시에도 permission denied 를 만나게 되어 sudo 를 남발해야 하는 경우가 종종 발생합니다. 조금더 쉽게 docker를 사용하고 작업을 수행하기 위해 간단한 사용자, 그룹 변경으로 문제를 회피하는 방법을 정리해 봅니다. 

제가 만났던 permission denied 는 docker pull #이미지# 를 수행하는 과정에 발생했습니다. 발생한 위치는 나름 정확하게 나와서 /var/run/docker.sock 파일에 대한 접근을 하는 과정에서 권한 문제가 발생한 것으로 확인됩니다.

$ docker pull victoriametrics/victoria-metrics
Using default tag: latest
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.26/images/create?fromImage=victoriametrics%2Fvictoria-metrics&tag=latest: dial unix /var/run/docker.sock: connect: permission denied

이 권한 문제는 /var/run/docker.sock 파일의 접근 권한이 root 사용자에게 한정되어 있기 때문에 발생합니다. 따라서 접근 권한을 낮추거나 실사용자가 포함된 그룹을 만들어 파일의 소유권을 변경하는 것이 가장 깔끔한 방법입니다. 

# root 사용자/그룹에게 접근 권한이 있습니다
$ ls -al /var/run/docker.sock
srw-rw---- 1 root root 0 Jul  8 16:35 /var/run/docker.sock

# docker 그룹을 새로 만들어 사용자($USER)를 docker 그룹에 추가후 파일의 권한을 변경합니다.
$ sudo /usr/sbin/groupadd -f docker
$ sudo /usr/sbin/usermod -aG docker $USER
$ sudo chown root:docker /var/run/docker.sock

# 변경후 권한은 이렇게 바뀌었습니다
$ ls -al /var/run/docker.sock
srw-rw---- 1 root docker 0 Jul  8 16:35 /var/run/docker.sock

이제 별 문제 없이 pull 할 수 있게 되었습니다. (만세)

$ docker pull victoriametrics/victoria-metrics
Using default tag: latest
Trying to pull repository docker.io/victoriametrics/victoria-metrics ...
latest: Pulling from docker.io/victoriametrics/victoria-metrics
5843afab3874: Pull complete
576d2fdb56fe: Pull complete
a4c69497911f: Pull complete
Digest: sha256:dedd22e46e72518f7944355dd6b236231948c6a24d60f7ca201a5c007013da64
Status: Downloaded newer image for docker.io/victoriametrics/victoria-metrics:latest

참고자료