Elastic Search APM 을 이용해서 AWS Lambda 서버 로깅하기

송윤주·2024년 2월 27일

클라우드

목록 보기

5/8

🚨주의) 2024.02.27 기준 엘라스틱 본사에 문의한 결과 AWS는 자신들 관할이 아니라 답변을 제대로 해줄 수 없다는 연락이 와서 결국 연결하지 못했음. 그래도 서버리스 외에 APM agent를 서버로 운영할 때는 APM agent 연결부분만 바꾸면 되기에 기록을 남긴다.

필자는 AWS Lambda를 이용해서 서버리스 프로젝트를 구현중이다. 그래서 해당 서버에 대한 로그를 Elastic APM(Application Performance Monitoring)을 활용해서 기록하고자 한다.
그것과 관련된 흐름은 아래와 같다.

Elastic APM 서버 설정

Elasticsearch 클러스터 연결

APM Server에 Lambda를 연결

Lambda 함수 구성

IAM 역할 및 정책 구성

모니터링 및 로깅 (ex. Kibana)

들어가기 앞서 APM 에 대해서 간단히 알아보고 진행해보자.

APM에 대해서

구성요소

APM Components (https://www.elastic.co/guide/en/apm/guide/8.6/apm-components.html)

Elastic APM 공식문서에 따르면 이 시스템은 아래의 주요 구성 요소로 구성된다.

1. APM Agents

역할: APM Agents는 모니터링 대상이 되는 애플리케이션 내부에 직접 설치되는 경량화된 라이브러리이다. 이들은 애플리케이션의 성능 데이터(예: 요청 시간, 데이터베이스 쿼리 성능 등)와 에러 로그를 실시간으로 수집한다.
작동 방식: 애플리케이션의 실행 과정을 자동으로 모니터링하며, 수집된 데이터를 APM Server로 전송한다. 각 프로그래밍 언어와 프레임워크에 맞춤화된 다양한 APM Agents가 제공된다.

2. APM Server

역할: APM Agents로부터 수집된 데이터를 받아, 처리 및 가공한 후 Elasticsearch에 저장한다. APM Server는 이 데이터를 인덱싱하여 검색과 분석이 용이하게 만든다.
작동 방식: APM Server는 Elastic Stack의 중심 컴포넌트로서, 데이터의 수집, 가공, 인덱싱 작업을 담당한다. APM Server는 일반적으로 별도의 서비스로 실행되며, 클라우드 환경 또는 온프레미스에서 배포할 수 있다.

Elastic APM의 구성요소와 관련하여 "APM Integration"이라는 용어가 등장한 것은 Elastic Stack의 최신 개발 방향성과 Elastic Agent의 도입과 관련이 있다. 기존에는 APM Server가 독립적인 컴포넌트로서 APM Agents로부터 데이터를 수집하고, 이를 Elasticsearch로 전송하는 역할을 담당했다. 그러나 Elastic Stack 7.11 이후부터 Elastic Agent와 Fleet의 도입으로 인프라스트럭처 및 애플리케이션 모니터링 방식에 중요한 변화가 생겼다.

APM Server와 APM Integration의 차이점

APM Server: 이전까지 APM Server는 Elastic APM 데이터를 처리하고 Elasticsearch로 전송하는 독립 실행형 서버로 운영되었으며 사용자는 APM Server를 별도로 설치하고 관리해야 했다.
APM Integration: Elastic Agent는 여러 Elastic Observability 기능을 통합하는 역할을 하며, "APM Integration"은 이러한 새로운 패러다임에서 APM 기능을 Elastic Agent와 통합하는 방식을 의미한다. 이를 통해 사용자는 Elastic Agent를 통해 APM을 포함한 다양한 데이터 수집 작업을 관리할 수 있게 되었다. APM Integration을 사용하면, Elastic Agent가 APM Server의 역할을 수행하게 되어, 별도의 APM Server 설치 없이도 APM 기능을 사용할 수 있다.

APM Integration의 이점

통합 관리: Elastic Agent를 통해 APM을 포함한 다양한 데이터 수집기를 중앙에서 관리할 수 있으므로, 배포 및 관리 작업이 간소화된다.
유연성: Elastic Agent는 단일 에이전트를 통해 로깅, 메트릭, APM 데이터 수집 등 다양한 관측 가능성 데이터를 수집할 수 있어, 복잡한 환경에서의 모니터링이 용이해진다.
확장성: Fleet를 사용하여 대규모의 Elastic Agent 배포를 원격으로 관리하고 구성할 수 있으므로, 대규모 인프라스트럭처에서도 효율적인 모니터링 솔루션을 제공한다.

결론적으로, "APM Integration"은 Elastic Agent를 통해 제공되는 APM 기능을 의미하며, 이는 전통적인 APM Server의 기능을 포함하고 있다.

3. Elasticsearch

역할: Elasticsearch는 APM Server로부터 전송된 데이터를 저장, 검색, 분석하는 검색 엔진이다. 이는 대량의 데이터를 효율적으로 처리하고, 복잡한 검색과 집계를 실시간으로 수행할 수 있다.
작동 방식: Elasticsearch 클러스터는 APM 데이터의 저장소 역할을 하며, 데이터 분석과 시각화를 위한 기반을 제공한다.

4. Kibana (APM UI 포함)

역할: Kibana는 Elasticsearch에 저장된 데이터를 시각화하고 분석하는 사용자 인터페이스를 제공한다. APM UI는 Kibana 내에 통합된 인터페이스로서, 성능 지표, 에러, 트랜잭션 등의 APM 데이터를 시각화한다.
작동 방식: Kibana를 통해 사용자는 데이터 대시보드를 생성하고 관리할 수 있으며, APM 데이터를 쉽게 조회하고 분석할 수 있다. APM UI는 사용자가 시스템의 성능 문제를 신속하게 파악하고 해결하는 데 도움을 준다.

데이터 모델

출처

Elastic APM의 데이터 모델은 애플리케이션 성능 모니터링 데이터를 구조화하는 방법을 정의한다. 이 모델은 여러 구성 요소로 나뉘며, 각각은 애플리케이션에서 수집된 다양한 유형의 데이터를 대표한다. 주요 구성 요소로는 트랜잭션(Transactions), 스팬(Spans), 에러(Errors), 및 메트릭(Metrics)이 있다.

1. 트랜잭션 (Transactions)

정의: 트랜잭션은 애플리케이션에서 실행된 작업의 단위. 예를 들어, 웹 요청, 배치 작업 실행 등이 트랜잭션으로 간주된다.
목적: 트랜잭션은 애플리케이션에서 수행된 작업의 성능을 측정하고 분석하는 데 사용된다. 각 트랜잭션은 실행 시간, 성공 여부, 관련 에러 등의 정보를 포함한다.

2. 스팬 (Spans)

정의: 스팬은 트랜잭션 내에서 수행된 개별 작업을 나타낸다. 데이터베이스 쿼리, 외부 HTTP 요청, 애플리케이션 내부에서의 메서드 호출 등이 스팬으로 기록된다.
목적: 스팬은 트랜잭션을 구성하는 세부 작업의 성능을 분석하고, 병목 현상이나 성능 저하의 원인을 식별하는 데 도움을 준다. 각 스팬은 시작 시간, 지속 시간, 유형 등의 정보를 포함한다.

3. 에러 (Errors)

정의: 에러는 애플리케이션 실행 중 발생한 예외나 문제를 나타낸다.
목적: 에러 정보를 통해 애플리케이션에서 발생한 문제를 식별하고, 문제의 원인을 분석할 수 있다. 에러 데이터에는 에러 메시지, 발생한 스택 트레이스, 관련 트랜잭션 정보 등이 포함된다.

4. 메트릭 (Metrics)

정의: 메트릭은 애플리케이션과 시스템의 성능 지표를 정량적으로 나타내는 데이터이다. CPU 사용량, 메모리 사용량, 응답 시간 등 다양한 성능 지표가 메트릭으로 수집된다.
목적: 메트릭 데이터를 분석하여 애플리케이션과 시스템의 전반적인 성능 상태를 모니터링하고, 성능 최적화를 위한 인사이트를 얻을 수 있다.

Fleet Server 설정

APM Server를 구성하기 위해서 두가지 방법을 고려할 수 있다.

출처: 공식문서 사진

APM Server 통합 활성화 (Elastic Cloud 사용 시): Elastic Cloud에서 제공하는 APM 및 Fleet 옵션을 사용하여 APM Server를 활성화한다. 배포 설정에서 APM을 선택하고, APM 서버를 배포에 추가한다.

APM Server 구성 (자체 호스팅 시):
APM Server를 설치한다. apm-server.yml 구성 파일을 편집하여 Elasticsearch 클러스터와의 연결을 설정한다.

여기서 나는 Elastic Cloud 사용을 할 것이기에 Fleet 서버를 사용하기로 결정했다. 관련 설정을 하기 위해 팔로 팔로미🙏

엘라스틱 키바나 콘솔에 로그인한다음에 Management에 있는 Fleet로 간다.

그러면 이런 화면이 나오는데 Add Fleet Server를 눌러보자.

get started with fleet 를 디폴트값을 그대로 반영하고 Install Fleet Server 를 위해 ec2 인스턴스를 하나 만들고 해당 명령어를 실행해서 깔아보자.

여기서 Fleet Server를 설치한다는 것은 Elastic Agent를 실행할 호스트 머신에 Fleet Server 기능을 설치하는 것을 의미한다.

위의 명령어를 모두 수행하게되면 Elastic Agent부분이 다 설정된 것! APM agent를 람다함수에 연결해주면 된다.

ec2 연결하기

ec2를 터미널 상에서 접근하는 흐름은 다음과 같다.

ec2 인스턴스 생성시 발급받은 .pem 파일이 있는 위치로 이동한다.

chmod 400 ec2key.pem 를 통해 권한을 축소시킨다.

ssh -i "checkbara.pem" ec2주소.ap-northeast-2.compute.amazonaws.com 를 실행한다.

그런다음에 Install Fleet Server 명령어를 모두 실행한다. 그러면 다음단계로 넘어간다.

Add agent

Fleet Server: Elastic Agent를 중앙에서 관리하고, 데이터를 수집하는 서비스
Elastic Agent: 실제 데이터를 수집하고, Fleet Server에 보내는 에이전트

일반적으로 Fleet Server는 중앙 관리 서버로 단독으로 설치되고, Elastic Agent는 Fleet Server에 연결하여 여러 호스트에서 데이터를 수집하는 용도로 설치된다. 하지만, 테스트 목적이거나 소규모 환경에서는 Fleet Server와 Elastic Agent를 동일한 호스트에 설치하는 것이 가능하다.

📍 결론적으로, EC2 인스턴스에 Fleet Server, Elastic Agent도 설치하면 인스턴스가 데이터 수집과 중앙 관리의 두 역할을 모두 수행하게 된다.

🚨 주의)실제 운영 환경에서는 보통 Fleet Server는 별도의 관리 호스트에 설치하고, Elastic Agent는 각각의 데이터를 수집할 호스트에 설치한다.

근데?!? 사실은 이러면 안된다.. Error: already installed at: /opt/Elastic/Agent 명령어를 수행하면 이런 에러가 발생한다.
애초에 fleet server install 하는 명령어가 agent도 깐거라서 그냥 안하면 된다. 나중에 다른 인스턴스에 설치할 때는 위 명령어를 수행하자!

Lambda에 연결하기

나는 총 2가지 방법을 시도했다.

람다 핸들러 함수내에 agent를 하드코딩하기

람다 환경변수에 agent 관련 내용 적기

결론부터 말하자면 둘다 실패했다.
1번을 수행하기 위해 아래와 같이 agent를 넣어주었다.

SERVICE_NAME = os.getenv('SERVICE_NAME')
SECRET_TOKEN = os.getenv('SECRET_TOKEN')
SERVER_URL = os.getenv('SERVER_URL')


# Elastic APM 구성
client = elasticapm.Client({
    'SERVICE_NAME': SERVICE_NAME,
    'SECRET_TOKEN': SECRET_TOKEN,
    'SERVER_URL': SERVER_URL,
})

근데 나온 에러는 Failed to submit message: 'HTTP 401: {"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate with provided credentials and anonymous access is not allowed for this request","additional_unsuccessful_credentials":"oauth2 token: invalid token","header":{"WWW-Authenticate":["Basic realm=\\"security\\" charset=\\"UTF-8\\"","Bearer realm=\\"security\\"","ApiKey"]}}], 와 여러가지 설정을 만졌는데 'HTTP 400: 400 Bad Request' 이런에러를 만났었다...
그래서 나는 컨테이너를 통해 람다함수를 만든 것이라 다른 건가 싶어서 공식 Docs를 확인해봤다.
람다 apm 관련 공식문서
위 레퍼런스를 참고로 해서 그대로 환경변수 설정을 다 해줬는데 agent가 제대로 실행이 안되는 건지 Elastic에 있는 observability에 APM에 내가 사용하고자 하는 람다 로그가 안쌓였다... 이걸 진짜 3일 내내 여러가지 시도를 했는데 결국 원인을 찾지 못했고 관계자분께 여쭤보니 맨 위에 언급한 답변을 주셨다...