Cloud Computing On Demand

Grafana 8.x 이상 버전에서는 웹 소켓을 이용하여 업데이트 되는 데이터를 패치해 옵니다.
이전에는 별도의 HTTP Request를 이용했지만, 이제는 웹 소켓을 이용해 
매번 연결을 보내는 오버헤드를 줄이려는 의도라고 생각합니다. 
Grafana 에서는 이 기능을 Grafana Live라 부릅니다. 

Grafana 인스턴스가 직접 엔드포인트를 제공하면 웹 소켓 이용에 특별한 문제가 없으나
여러가지 이유로 앞단에 NGINX 등을 통한 리버스 프락시를 구현해 두었다면
웹 소켓 연결이 제대로 맺어지지 않는 문제가 있습니다.

물론 Grafana 의 동작 자체는 문제가 없고 브라우저 개발자 도구/콘솔상에 
보기 싫은 빨간색 에러가 잔뜩 찍히는 불편함이 있습니다.

방법#1. Grafana Live 기능을 꺼버리자!

가장 쉬운 방법은 Grafana Live 기능을 꺼버리는 방법입니다. 
다만 이 방법은 Grafana Live 문서에서 이야기 하고 있는 기술의 장점을 버리는 선택이 됩니다. 
그렇지만 굳이 필요 없다면 기능을 꺼버리는 것이 여러모로 더 나은 선택일 수도 있습니다.

Grafana 설정 파일인 grafana.ini 혹은 custom.ini 에 
[live] 섹션을 찾아 max_connections 값을 0으로 설정하면 기능을 끌 수 있습니다. 

방법#2. 리버스 프락시에 웹 소켓 설정을 추가하자!

조금 더 적극적인 사용자이고 새로운 기술들을 활용해 보고 싶다면?
구성해 둔 리버스 프락시의 설정을 업데이트하여 웹 소켓을 잘 소화하도록 수정할 수 있습니다. 
여기에서는 가장 널리 사용되는 nginx를 리버스 프락시로 사용한 경우입니다. 

웹 소켓은 hop-by-hop, 즉 클라이언트와 nginx, 그리고 nginx와 Grafana 사이의 연결을 별도로 취급합니다. 
클라이언트가 Grafana와 웹 소켓을 통한 데이터 교환을 하기 위해서는 
nginx가 웹 소켓과 관련하여 일종의 터널링을 해주어야 합니다. 
마치 nginx가 없는 것처럼 클라이언트와 Grafana 사이를 연결해 주어야 하는 것입니다. 

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}

사용자 환경에 따라 nginx 설정 파일을 쪼개서 쓸 수도 있기 때문에 
공식 문서에서 가이드 하고 있는 예제 설정을 가져왔습니다. 

웹 소켓은 Upgrade 헤더를 이용하여 웹 소켓 사용이 가능한지를 체크하고 
문제가 없는 경우에만 커넥션을 맺고 데이터를 흘리는 구조입니다.

설정의 내용은 클라이언트와 nginx 간에 Upgrade 헤더 값에 따라 
변수($connection_upgrade) 값을 지정하고 
이 값을 Grafana로 요청을 보낼때 사용하는 방식입니다. 

마지막의 location 블록을 보면 클라이언트가 보낸
Upgrade 헤더 값($http_upgrade)을 Upgrade 요청 헤더에 지정하고 
map 블록으로 지정한 $connection_upgrade 변수 값을 
Connection 헤더에 담아 Grafana로 보내는 것을 확인할 수 있습니다. 

이렇게 설정하고 nginx config을 리로드 하면 에러가 깔끔하게 사라집니다!

nginx 기준으로 위와 같은 형태로 구성하는 것은 1.13.x 이후 버전부터 가능합니다. 
혹시나 예상대로 잘 동작하지 않으면 nginx의 버전을 살펴보기 바랍니다!

꾸준히 판매되고 있는 저의 번역서 NGINX 쿡북!
아직 구매하지 않았다면 아래 링크로 고고씽~ 구매 달려주시기 바랍니다!

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

데이터베이스 마이그레이션은 참 번거로운 작업입니다.
상황에 따라서는 메인터넌스를 걸고 서비스를 잠시 중단해야 할 수도 있고
그걸 원하지 않는다면 dual-write 등의 수단을 통해
데이터베이스를 싱크업 하는 과정을 수행해야만 합니다. 

마이그레이션이 이번 글의 주제는 아닙니다.
다만 마이그레이션이 필요하지만 메인터넌스 윈도우를 만들고 싶지 않아 
데이터베이스를 매뉴얼하게 옮기는 것을 고민하다
문득 <데이터베이스의 모든 테이블 레코드 갯수를 한번에 뽑고 싶다>는
자체 요구사항이 생겨 확인한 내용을 정리해 봅니다.

데이터베이스의 모든 레코드 갯수 쿼리

데이터베이스에 있는 모든 테이블의 레코드 갯수를 카운트 하는 것은
아래의 쿼리를 통해 수행할 수 있습니다. 

SELECT SUM(TABLE_ROWS) 
  FROM INFORMATION_SCHEMA.TABLES 
 WHERE TABLE_SCHEMA = '##데이터베이스이름##';

모든 테이블 단위로 레코드 갯수 그룹화하는 쿼리

데이터베이스 내에 테이블이 많다면
각 테이블별로 레코드 갯수를 카운트 하고 싶을지도 모릅니다. 
INFORMATION_SCHEMA.TABLES 가 갖고 있는
몇 가지 컬럼을 활용해서 Group By 하면 쉽게 쿼리할 수 있습니다. 

SELECT TABLE_NAME, TABLE_ROWS
  FROM INFORMATION_SCHEMA.TABLES 
 WHERE TABLE_SCHEMA = '##데이터베이스이름##';

자, 이제 마이그레이션을....다시... ㅜㅜ

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

(1편) Route53 로그 수집을 위한 Logging Group 설정 및 CloudWatch Logs 기본 설정 살펴보기

(2편) Route53 DNS 로그 수집을 위한 ElasticSearch Cluster만들기

앞선 두 포스팅을 잘 따라오셨다면 우리는 CloudWatch Logs의 기본적인 설정을 만들었고 AWS ElasticSearch Cluster까지 만드셨을 겁니다. 이제 만들어진 ES Cluster로 로그를 적재하기 위한 Subscription filter 구성 작업을 해보도록 하겠습니다. CloudWatch Logs의 관리 화면으로 이동하여 설정을 시작하겠습니다. 

Log Group에 대한 Elasticsearch subscription filter 설정하기

CloudWatch Logs 관리 화면에 진입하면 설정되어 있는 여러 Log Group 목록이 나옵니다. Log Group이 많은 경우 빠른 식별을 위해 제품 명을 Log group 이름에 넣으라고 말씀드렸던 것을 기억하시겠지요? 가이드를 잘 따라오셨다면 검색창에 키워드를 입력하여 쉽게 Log group을 찾을 수 있습니다. 

체크 박스로 로그 그룹을 선택하고 상단 `Actions` 드롭다운 메뉴를 누르겠습니다. 메뉴중 `Subscription filters`를 선택하면 4가지 필터 옵션을 선택하는 팝업이 이어집니다. 우리는 첫번째 항목으로 위치한 `Create Elasticsearch subscription filter`를 선택하겠습니다. 

필터 설정 화면은 크게 세 부분으로 나뉘어져 있습니다. 가장 첫번째 섹션은 `Choose destination`입니다. 이곳에서는 로그를 보낼 목적지를 선택하게 되는데요, 우리가 만든 AWS Elasticsearch Cluster의 도메인 이름을 이곳에 지정하게 됩니다.

AWS상에 여러개의 어카운트를 생성하여 사용하고 있다면 `Another account`를 선택하여 다른 어카운트의 ES Cluster로 로그를 전송하는 것도 가능합니다만 이 포스팅의 범위를 넘어서는 내용이니 설명은 따로 하지 않겠습니다. 우리는 기본 값인 `This account`를 선택한 상태에서 설정 작업을 진행하도록 하겠습니다. 

간혹 "만들어둔 ES Cluster가 목록에 보이지 않아요!" 라는 분들이 계십니다. ES Cluster는 결국은 EC2를 생성하고 Elasticsearch를 설치, 구동하는 것이기 때문에 생성되는데 생각보다 시간이 좀 걸립니다. 경험상 오래 걸릴때는 10분 정도까지 기다리기도 했으니 혹시나 클러스터 목록에 생성한 ES Cluster가 나오지 않는다면 조금 후에 다시 시도해 보시기 바랍니다. 리프레시 버튼이 없으니 뒤로 갔다가 다시 와야 한다는 점도 기억해 두면 좋겠네요.

첫번째 섹션 `Choose destination`에서 ES Cluster를 선택하면 화면이 늘어나면서 Lambda IAM Execution Role을 선택하라는 안내를 만나게 됩니다. 지금까지 여기저기 옮겨 다니면서 설정을 해왔는데 IAM 으로 다시 또 돌아가야 한다니... 이쯤에서 한숨을 한번 내쉬는 것이 정상입니다 ㅎㅎ 다행히도 우측에 Refresh 버튼이 있기 때문에 별도 창으로 IAM 관리 화면을 열고 Route53로그를 ElasticSearch가 잘 받을 수 있도록 Role을 만들어 보도록 하겠습니다.

그런데 갑자기 왠 Lambda일까요? Lambda가 필요한 이유는 간단합니다. Route53의 로그는 CloudWatch Logs를 통해 수집되면 gzip으로 압축된 상태로 저장됩니다. CloudWatch는 ES Cluster로 이 압축파일을 손대지 않고 그대~~로 전달합니다.. 따라서 이를 Unzip하고 ES에 주입하는 단계가 필요하고 이를 위해서 Lambda를 사용합니다. Lambda 코딩에 자신이 없다구요? 다행히도 우리가 Lambda코드를 만들 필요 없이 적당한 권한만 할당되면 미리 준비된 코드가 구동되는 방식입니다.

IAM에서 Lambda용 Role 설정하기

IAM 관리 화면을 별도 창으로 열어보겠습니다. 우리는 IAM의 Roles 메뉴에 진입하여 새로운 Role을 작성하도록 하겠습니다. 아래의 이미지에 나온 것처럼 Permission Policy에 우선 `AWSLambdaBasicExecutionRole`을 붙여 주겠습니다. 

(Update 2022.04.22) AWS Console이 업데이트 되면서 IAM 도 화면이 많이 변경되었습니다. 당황하지 마시고 하나씩~ 보시면서 설정하시면 오히려 더 편리하기도 합니다!

`AWSLambdaBasicExecutionRole`이라는 Managed Policy가 추가 되었다면 `Add inline policy`버튼을 눌러 아래의 JSON을 입력합니다. JSON의 내용중 Resource의 Account ID, Region ID, ES Cluster Name등은 각자의 어카운트 환경과 설정에 맞게 수정해서 넣어야 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "es:*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:es:#ES가생성된리전#:#ACCOUNT_ID#:domain/#ES도메인명#/*"
        }
    ]
}

퍼미션 설정이 되었다면 이 권한을 갖게될 계정이 신뢰할 수 있는 서비스를 지정하겠습니다. 생성된 Role을 활용하는 주체는 CloudWatch Logs가 됩니다. CloudWatch Log는 Lambda를 실행해야 하기 때문에 Trusted Relationships에는 lambda.amazonaws.com 서비스를 추가해야 합니다. JSON 기준으로 Trust relationship을 보면 아래와 같습니다. 공통 영역이니 그대로 복사해서 붙여 넣어도 무방합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

여기까지 완료되었다면 IAM Role의 설정이 완료된 것입니다. 다시 CloudWatch Logs에서 subscription filter를 선택하던 화면으로 돌아가서 Lambda IAM Execution Role 지정 영역의 Refresh 를 눌러 방금 만든 Role이 나오는지 확인합니다. 저는 기억하기 좋게 cwlogs_route53_to_es 라고 Role 이름을 지었습니다. 생성한 Role을 선택후 다음 섹션으로 넘어가겠습니다. 

(Update 2022.04.22) Lambda IAM 생성/지정하는 부분이 보이지 않는 경우 아직 OpenSearch 클러스터 생성이 완료되지 않은 것입니다. 조금 기다렸다가 다시 Subscription Filter 를 생성하시기 바랍니다.!   아래와 같은 에러가 발생하면 커피 한잔, 담배 한대 피우고 오시기 바랍니다!!!

로그 포맷 설정

Subscription filters 설정의 두번째 섹션인 `Configure log format and filters`에서는 로그 포맷을 정의하게 됩니다. 정의된 로그 포맷으로 규격을 맞추어 CloudWatch Logs에서 Lambda를 거쳐 ES로 로그가 전달되는 식입니다. 포맷을 별도로 정의하지 않으면 ES에서는 `@message` 컬럼으로만 로그 데이터가 저장됩니다. 따라서 저장된 로그를 조회하거나 다루기 쉽게 하려면 로그 포맷을 지정하는 것이 중요합니다. 

안타깝게도 사전에 정의된 Log format 목록에는 Route53이 CloudWatch Logs를 통해 전달하는 포맷 정보가 기본 항목으로 들어 있지 않습니다. 따라서 Log format으로 `Space Delimited`를 선택하고 2021년 8월 기준 로그에 대해서 만든 아래의 내용을 필터 패턴에 넣어주면 ElasticSearch Cluster에서 사용하기 편한 컬럼을 만들고 저장할 수 있게 됩니다.

[version, timestamp, zone_id, domain, rr_type, error, protocol, region, resolver_ip, edns0]

마지막 섹션인 `Test pattern`에서는 이미 수집되기 시작한 CloudWatch Logs의 샘플 로그를 이용하여 입력한 filter pattern이 데이터를 잘 구분해 내는지 확인해 볼 수 있습니다. 앞선 포스팅에서 확인했던 것처럼 이미 로그가 쌓이고 있을 것이기 때문에 쌓인 로그 중 하나를 선택하여 입력한 필터가 데이터를 잘 구분해 주는지 확인해 보겠습니다. 

데이터가 잘 쌓이고 있고 필터가 적당히 구성되었다면 위 그림에서 볼 수 있는 것처럼 로그를 잘 구분하고 있는 것을 확인할 수 있습니다. 이제 모든 구성이 끝났으니 화면 맨 아래의 `Start streaming`을 눌러 데이터 전송을 시작하겠습니다. 문제가 없다면 성공 메세지와 함께 Subscription filters가 생성된 것을 확인할 수 있습니다.

이제 4편에서 모든 구성을 마무리하고 ES 에서 데이터를 조회해 보는 일만 남았습니다.

지난 글에서는 Route53 로그 추출을 위한 사전 작업으로 Route53의 대상 Hosted Zone에 Query Logging을 설정하고 CloudWatch Logs로 로그를 전송하도록 구성을 했습니다. 로그가 정상적으로 CloudWatch Logs로 수집되기 시작했기 때문에, 이번 글에서는 `Subscription filters`를 생성하여 <로그를 구독할 서비스를 설정>하고 CloudWatch Logs의 로그를 해당 서비스가 구독하도록 하겠습니다.

다만 이 작업을 진행하기 전에 Amazon ElasticSearch를 향한 `Subscription filters` 생성시 입력해야 하는 ElasticSearch Cluster 도메인을 먼저 만들고, 해당 도메인을 filter에 지정하는 작업을 해보도록 하겠습니다. 참고로 CloudWatch Logs에서 생성할 수 있는 filter는 4가지 정도가 있습니다만 AWS ElasticSearch로 전송하는 것이 가장 간단합니다. 

Amazon Elasticsearch Cluster 생성하기

`Elasticsearch subscription filter`를 설정하기 위해서 AWS Web Console 에서 `Amazon Elasticsearch`를 선택하고 관리 화면으로 이동하도록 하겠습니다. 제가 사용하는 Account에는 생성된 ES Cluster가 없기 때문에 아래 화면과 같습니다만, 미리 생성되어 있거나 사용중인 ES Cluster가 있다면 목록에 해당 클러스터의 이름이 보일것입니다.

어쨌든 우리는 새로운 클러스터를 만들어야 하기 때문에 `Create domain`을 눌러 새로운 ElasticSearch Amazon OpenSearch Cluster를 구성해 보도록 하겠습니다. 새로운 클러스터 생성시 `도메인`을 지정하게 되고, 이후 CloudWatch에서 subscription filter를 설정할 때도 생성한 도메인 이름을 선택하게 됩니다. 

간단하게 짧은 시간동안 Route53 DNS의 로그를 수집하여 분석해야 하거나 로그 양이 많지 않은 경우라면 클러스터에 사용되는 리소스 규모를 적당한 크기로 선택하는 것이 좋습니다. ElasticSearch 생성의 첫 단계에서 `Development and testing` 타입으로 클러스터를 생성해도 무방할지 생각해 보시기 바랍니다. 설명에 따르면 이 옵션을 쓰면 AWS Region의 가용성 영역을 하나만 사용하게 되고 HA(High Availability)를 보장받기 힘듭니다. 그럼에도 불구하고 우리는 공부를 하는 중이니 간단하게 클러스터를 구성하도록 하겠습니다.

두번째 화면에서는 할당될 Elasticsearch 클러스터의 도메인(Domain)으로 사용할 키워드를 입력합니다. 앞서 이야기 한 것처럼 여기에서 입력한 키워드를 클러스터 선택시 사용하게 됩니다. 이외에도 자동 튜닝, 인스턴스 타입, 스토리지 크기 등을 정하게 됩니다만 크게 필요가 없다면 옵션을 끄는 것이 비용 관점에서 유리합니다. 물론 성능이 좋은 ES 클러스터를 만들어야 한다면 세세하게 설정을 손봐야 하겠지만 일단 로그를 흘리면서 ES로 던지고, ES와 함께 제공되는 Kibana에서 조회해 보는 것이 목적이니 기본 값으로 시험해 봐도 무방하다.

(Update 2022.04.21) Amazon OpenSearch 로 제품이 변경되면서 설정 화면이 약간 바뀌었습니다. 아래와 같이 `Deployment type` 선택이 약간 아래로 밀렸고 Name 지정을 먼저 하도록 바뀌었습니다. 순서만 약간 바뀌었을 뿐, 입력하고 선택하는 내용은 대부분 큰 변경이 없습니다. 1. 먼저 Domain Name과 Deployment Type을 선택합니다. 시험중이라면 `Development and testing`을 선택하여 단일 리전에만 배포합니다.

다음으로 ES와 Kibana에 접근할 수 있는 접근 권한을 설정해야 합니다. VPC내에서만 접근 가능하게 하거나 Cognito 등을 연동하여 IAM 기반으로 접근할 수 있도록 하는 것이 좋습니다만 시험을 위해서 Public Access로 구성을 진행하고 <Fine-grained access control> 섹션에서 `Create master user`를 눌러 단순하게 ID, Password로 접근하게 하는 방법을 써도 무방합니다. Production용 시스템을 구성한다면 이렇게 구성하지 않는 것이 Job Security에 유리하겠습니다 :-)

(Update 2022.04.21) 시험적으로 만들어보는 중이니 `Network`는 `Public access`로 `Fine-grained access control`도 `Create master user`를 이용하도록 합시다. 이전 버전과 큰 차이는 없습니다.  `Access Policy` 역시 단순한 시험을 위해 IP ACL로 설정해 보았습니다.

이후 AWS의 꽃 중 하나인 Tag 설정 단계가 있지만 시험용 설정을 위해서는 굳이 설정하지 않아도 됩니다. 마지막으로 `Review` 단계에서 입력한 값들을 한번 더 검증하고 문제가 없다면 `Confirm` 버튼을 눌러 ElasticSearch Cluster 생성을 마무리 하도록 하겠습니다.

늘 느끼는 것이지만 AWS를 비롯한 Public Cloud에서는 이것 저것 설정하고 준비해야 할 것들이 꽤 많습니다. 이어지는 글들에서는 CloudWatch Logs에서 Subscription filter를 생성하고 IAM에서 필요로 하는 권한을 설정하는 작업을 진행하도록 하겠습니다. 

AWS 입문자라면 AWS 자격증 공부를 통해 체계적으로 전반적인 AWS 에코시스템을 학습하는 것이 좋습니다. udemy 베스트셀러 강의를 통해 자격증과 AWS 지식을 함께 쌓아보시면 어떨까요?

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

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 강의를 추천드립니다!

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

파이썬을 이용한 머신러닝 학습을 하다보면
여러가지 알고리즘을 구현한 패키지를 많이 쓰게 됩니다. 
알고리즘 자체를 이해하고 구현하려는 것이 아닌 이상
잘 정비되어 등록된 패키지를 쓰는 것이 훨씬 유용합니다.

그 중 하나가 LightGBM으로 Gradient Boosting Model 알고리즘의 구현체입니다. 
이름에서 알 수 있는 것처럼 Light 가 붙어 있기 때문에 
최대한 가볍고 빠르게 GBM 알고리즘 방식으로 
데이터를 분석하기 위해 사용되는 알고리즘 입니다. 

여튼, 참 좋은 물건이지만 가끔 pip로 설치되지 않을 때가 있습니다. 
설치가 잘 안되는 경우 직접 코드를 다운로드 받아 빌드할 필요가 있습니다. 

설치방법 #1. pip install lightgbm

가장 기본적인 설치방법입니다. 
pip를 이용해서 lightgbm 을 설치하는 방식이죠. 
네, 이걸로 잘 되기만 했다면 이 포스팅을 쓰고 있지도 않을 것 같습니다 ㅎㅎ

pip install lightgbm

설치방법 #2. homebrew를 이용한 설치 (macOS)

제가 mac을 쓰고 있어서...homebrew 를 이용한 설치 방법도 정리해 봅니다. 
homebrew 에서도 패키지 이름이 lightgbm 으로 되어 있기 때문에 
brew install lightgbm 명령을 이용하시면 되겠습니다. 

brew install lightgbm

설치방법 #3. GitHub에서 소스코드 받아서 빌드하기

#1, #2의 방법으로 설치가 잘 되지 않았다면 GitHub에 업데이트 된
lightgbm 소스코드를 다운로드 받아 cmake나 gcc로 빌드할 수도 있습니다. 

////////////////////////////////////// using cmake 
// Install CMake, if not installed
brew install cmake

// Install OpenMP
brew install libomp

// Build and Install
git clone --recursive https://github.com/microsoft/LightGBM
cd LightGBM
mkdir build
cd build
cmake ..
make -j4

////////////////////////////////////// using gcc
// Install CMake, if not installed
brew install cmake

// Install gcc
brew install gcc # -> CHECK GCC VERSION!!

// Build and Install
git clone --recursive https://github.com/microsoft/LightGBM
cd LightGBM
export CXX=g++-7 CC=gcc-7  # -> USE INSTALLED GCC VERSION!!
mkdir build
cd build
cmake ..
make -j4

제 경우는 #3의 cmake 활용 방법으로 설치할 수 있었습니다. 
즐거운 머신러닝 학습 되시길 바랍니다~!

더 자세한 소스 기반 빌드는... 아래쪽입니다!

서버를 운영할 때 중요한 것중 하나가 디스크가 꽉 차지 않도록 유지하는 것입니다. 
디스크가 꽉 차게 되면 여러 어플리케이션들이 오동작 할 수 있으며 
심각한 경우 로그인이 어려워질수도 있습니다. 

디스크 용량 확인

디스크가 꽉 찼는지 확인하기 위해서는 df 명령을 사용합니다. 

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        40G   40G  372M 100% /
devtmpfs        1.9G     0  1.9G   0% /dev

이제 용량을 많이 차지하는 파일을 찾아보겠습니다.

폴더별 용량 확인

루트 경로에서 du 명령을 사용해 폴더별 사용량을 체크해 볼 수 있습니다.
미쳐 캡쳐하기 전에 파일을 삭제, 정리하는 바람에 아래 예제에는 큰 용량의 파일이 보이진 않네요

$ sudo du -sh * | sort -hr
3.8G    usr
1.9G    var
1.6G    home
218M    opt
205M    boot
200M    run
35M     etc
764K    tmp
196K    root
0       sys
0       srv

파일 삭제 후에도 용량이 안늘어난다면?

간혹 파일 삭제 후에도 용량이 확보되지 않을때가 있습니다. 
이 경우 활성 프로세스나 좀비 프로세스가 파일 디스크립터를 들고 있어서일 가능성이 높습니다. 
이때는 lsof 명령을 이용해 문제가 되는 프로세스를 식별할 수 있습니다. 

$ /usr/sbin/lsof / | grep deleted
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
...

PID 컬럼에서 프로세스 ID를 확인한 후 ps 명령으로 재차 확인을 합니다. 
문제의 프로세스를 kill -9 #PID# 등의 명령으로 종료한뒤
lsof 명령을 다시 실행하면 문제의 FD 들이 삭제된 것을 확인할 수 있습니다. 

$ kill -9 12345
$ /usr/sbin/lsof / | grep deleted

이후 df 명령을 사용해서 디스크 용량을 확인하면
공간이 확보된 것을 확인할 수 있습니다. 

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        40G  7.8G   33G  20% /
devtmpfs        1.9G     0  1.9G   0% /dev

Udemy의 리눅스 커맨드라인 부트캠프 강의로 리눅스 기초 체력을 향상시켜 보세요!

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

React를 공부하고 있는 중입니다.
React를 공부하려다 그동안 확바뀐 Node.js 까지 익히는 중입니다 ㅎㅎ
npm의 유틸리티중 하나인 npx를 이용해서 create-react-app 패키지를 설치하고 
이를 이용한 보일러 플레이팅을 하는 것이 보고 있는 책의 예제입니다.

그런데!

놀랍게도 (언제나 그렇듯이) 개발 환경 구성부터 산넘어 산입니다. 
오늘 만난 에러는 npx를 이용한 React 보일러 플레이팅 중 발생했습니다. 

% npx create-react-app test
npm ERR! cb.apply is not a function

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/nopd/.npm/_logs/2022-02-05T17_54_47_354Z-debug.log
[ 'create-react-app@latest' ] 설치가 오류 코드 1로 실패했습니다

뭔가 발음하기에도 거시기한 cb.apply가 함수가 아니라는 에러!
아버지를 아버지라 부르지 못하고... 함수를 함수라 부르지 못하는 것인가 싶었지만 차치하고...
몇 군데 검색을 해봐도 딱히 쓸만한 방법을 찾질 못했습니다. 

구글 검색에서 걸린 것들은 대부분, 
- node_module 관련 경로를 다 지우고 다시 해봐라 
- node 버전을 올려라 
- 캐시를 지워라 
정도였던 것으로 기억됩니다.
안타깝게도 전부 저한테는 쓸모가 없었습니다. 

뭐가 문제일까 하다가 발견한 것이 Mac 환경에서 brew로 설치한 패키지들과 
설치된 경로를 알긴 어렵지만, 여튼 설치되어 있는 node 관련 패키지들이
서로 다른 경로에 있지만 후자가 우선순위를 갖게 되면서 문제처럼 보였습니다. 

사실 create-react-app 을 설치하기 전에도 
node의 버전이 brew에서 확인되는 것과 다르네? 하면서
/usr 하위에 만들어져 있던 심링크를 삭제했던 기억이 뇌리를 스쳤습니다. 

혹시 npx도..!?!?!?!?!

정답이었습니다. 
brew로 최신 버전의 npx를 설치했지만, 
이는 which npx 로 확인했을 때의 경로와 차이가 있었습니다. 

// #################### BEFORE
% which npx
/usr/local/bin/npx

// #################### AFTER
% which npx
/opt/homebrew/bin/npx

그렇습니다.
brew는 독립적인 생명체라, /opt/homebrew/bin 하위에 패키지를 저장하고 있었습니다.
원래 /usr/local/bin 경로에 있던 npx를 과감하게 삭제하니 모든것이 정상으로 돌아왔습니다!

% npx create-react-app test
Need to install the following packages:
  create-react-app
Ok to proceed? (y)
npm WARN deprecated tar@2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.

Creating a new React app in /Users/nopd/dev/clonecoding_practice/test.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...


added 1365 packages in 47s

169 packages are looking for funding
  run `npm fund` for details

Initialized a git repository.

Installing template dependencies using npm...
npm WARN deprecated source-map-resolve@0.6.0: See https://github.com/lydell/source-map-resolve#deprecated

added 33 packages in 2s

169 packages are looking for funding
  run `npm fund` for details
Removing template package using npm...


removed 1 package, and audited 1398 packages in 1s

169 packages are looking for funding
  run `npm fund` for details

8 moderate severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

Created git commit.

Success! Created test at /Users/nopd/dev/clonecoding_practice/test
Inside that directory, you can run several commands:

  npm start
    Starts the development server.

  npm run build
    Bundles the app into static files for production.

  npm test
    Starts the test runner.

  npm run eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd test
  npm start

Mac 환경에서 brew를 이용해서 node를 설치했고 
혹시나 pkg 를 다운로드받아 설치한 적이 있는 것 같은 기억이 있다면 
포스팅에 소개한 방법을 이용해 평안한 하루를 만드시기 바라겠습니다!