
분산형 애플리케이션으로의 전환이 본격화되고 있는데, 이는 주로 소비자와 빠르게 진행되는 비즈니스로서 "상시 작동"해야 한다는 우리의 필요성에 힘입은 것입니다. 이러한 필요성으로 인해 배포는 전 세계적으로 다양하고 신속하게 혁신할 수 있는 능력과 함께 더욱 복잡한 요구사항을 갖게 되었습니다.
클라우드는 오늘날의 애플리케이션을 위한 실질적인 배포 옵션이 되고 있습니다. 많은 클라우드 배포가 AWS에서 애플리케이션을 호스팅하여 (더 빠른 개발 및 혁신을 위해) 전 세계적으로 다양한 리전과 수많은 서비스를 제공하고 운영 비용과 자본 비용을 절감하는 방법을 선택합니다. AWS에서, 개발 팀은 Amazon EKS의 Kubernetes로 마이그레이션하고, 최신 서버리스 옵션을 테스트하며, 기존의 계층화된 애플리케이션을 보다 나은 서비스로 개선하는 데 추가적인 가치를 찾고 있습니다.
Elastic Observability는 AWS 서비스를 위한 30개의 기본 제공 통합 기능을 제공하며 앞으로 더 많은 서비스를 제공할 예정입니다.
몇 가지 통합 및 기능을 소개하는 간단한 리뷰는 이전 포스팅에서 확인하실 수 있습니다.
Elastic의 주요 AWS 서비스 통합에 대한 몇 가지 추가 포스팅은 다음과 같습니다.
- Elastic을 이용한 AWS Lambda의 서버리스 기능을 위한 APM(메트릭, 추적 및 로그)
- Lambda의 서버리스 포워더를 통해 AWS 서비스에서 Elastic으로 로그 수집
- Elastic의 Amazon S3 Storage Lens의 통합: 관리 간소화, 비용 제어, 위험 감소
- AWS FireLens로 컨테이너 로그인을 Elastic Cloud로 수집
AWS 통합의 전체 목록은 Elastic의 온라인 설명서에서 찾아보실 수 있습니다.
Elastic Observability는 네이티브 AWS 통합 외에도 로그뿐만 아니라 AWS 서비스 및 AWS 컴퓨팅 서비스(EC2, Lambda, EKS/ECS/Fargate)에서 실행되는 애플리케이션에 대한 메트릭도 집계합니다. 이 모든 데이터는 Elastic의 고급 머신 러닝 기능을 사용하여 시각적으로 그리고 보다 직관적으로 분석할 수 있으므로, 최종 사용자가 영향을 받기 전에 성능 문제와 표면적인 근본 원인을 파악하도록 지원합니다.
Elastic Observability가 서비스 맵, 추적, 종속성 및 ML 기반 메트릭 상관 관계와 같은 애플리케이션 성능 모니터링(APM) 기능을 제공하는 방법에 대한 자세한 내용은 다음과 같습니다.
- Elastic Observability의 APM 상관 관계: 트랜잭션 속도가 느리거나 실패한 원인이 될 수 있는 사항의 자동 식별
- Elastic과 AWS: 데이터 세트에서 가장 많은 값 가져오기
그렇습니다. Elastic은 AWS 컴퓨팅 서비스(EC2, Lambda, EKS/ECS/Fargate)의 AWS 서비스 및 애플리케이션에 대한 메트릭 수집, 집계 및 분석을 제공합니다. Elastic은 로그 이상의 의미를 갖습니다. AWS 환경을 위한 통합된 가시성 솔루션을 제공합니다.
이 블로그에서는, Elastic Observability가 AWS 서비스에서 실행되는 간단한 AWS 애플리케이션에 대한 메트릭을 모니터링할 수 있는 방법에 대해 검토하겠습니다. 여기에는 다음이 포함됩니다.
- AWS EC2
- AWS ELB
- AWS RDS(AuroraDB)
- AWS NAT Gateways
보시다시피, 통합을 설치하면 메트릭이 즉시 도착하고 즉시 메트릭 검토를 시작하실 수 있습니다.
이 블로그를 팔로우할 계획이신 경우를 위해, 이 데모를 설정하는 데 사용한 몇 가지 구성 요소와 세부 정보를 소개해 드립니다.
- Elastic Cloud 계정과 배포된 스택이 있는지 확인합니다(여기 지침 참조).
- AWS에서 필요한 데이터를 가져올 수 있는 권한을 가진 AWS 계정이 있는지 확인합니다. 자세한 내용은 Elastic 설명서를 참조하세요.
- 우리는 AWS의 3계층 앱을 사용하여 지시대로 설치하였습니다.
- 메트릭을 수집하고자 하는 4가지 서비스를 포함하는 일반적인 Elastic AWS Integration을 설치하는 방법을 안내해 드리겠습니다.
(Elastic AWS 통합에서 지원하는 서비스의 전체 목록) - 다른 블로그에서 AWS의 애플리케이션 모니터링(메트릭, 로그, 추적)을 포함하므로 애플리케이션 모니터링은 포함되지 않습니다. 대신 AWS 서비스를 쉽게 모니터링할 수 있는 방법에 초점을 맞출 것입니다.
- 메트릭을 보려면, 애플리케이션을 로드해야 합니다. 애플리케이션에 트래픽을 유도하기 위해 Playwright 스크립트도 만들었습니다.
Elastic 구성에 대해 자세히 살펴보기 전에, 모니터링하고 있는 내용을 검토해 보겠습니다. aws-three-tier-web-architecture-workshop의 지침을 따르면, 다음이 배포됩니다.

배포되는 내용:
- 서브넷이 6개인 VPC 1개
- AZ 2개
- AZ당 웹 서버 2개
- AZ당 2개의 애플리케이션 서버
- 외부 대면 애플리케이션 로드 밸런서 1개
- 내부 대면 애플리케이션 로드 밸런서 1개
- 애플리케이션 계층에 대한 트래픽을 관리하는 NAT 게이트웨이 2개
- 인터넷 게이트웨이 1개
- 읽기 복제본이 있는 RDS Aurora DB 1개
블로그 끝에서, 이 앱을 로드하기 위해 구현할 Playwright 스크립트도 제공할 예정입니다. 이렇게 하면 대시보드를 "밝히는" 메트릭을 유도하는 데 도움이 됩니다.
AWS의 3계층 앱에 나와 있는 지침과 워크숍 링크에 나와 있는 지침을 따릅니다. 워크숍은 여기에 나와 있습니다.
앱을 설치했으면, AWS에서 자격 증명을 가져옵니다. 이는 Elastic의 AWS 통합에 필요할 것입니다.
자격 증명에는 다음과 같은 여러 가지 옵션이 있습니다.
- 액세스 키를 직접 사용
- 임시 보안 자격 증명 사용
- 공유 자격 증명 파일 사용
- IAM 역할 Amazon Resource Name(ARN) 사용
Elastic Cloud 시작하기 지침에 따르세요.


Add AWS 통합을 선택합니다.

이것은 여러분이 자격 증명을 추가하고 Elastic에서 정책으로 저장되는 곳입니다. 이 정책은 다음 단계에서 에이전트 설치의 일부로 사용됩니다.
보시다시피, 일반적인 Elastic AWS Integration은 30개의 AWS 서비스로부터 상당한 양의 데이터를 수집하게 됩니다. 이 일반적인 Elastic AWS Integration을 설치하지 않으려면, 설치할 개별 통합을 선택할 수 있습니다.

마지막 단계에서 만든 정책의 이름을 선택합니다.

Add(추가) 에이전트 창의 지침에서 3단계를 따릅니다. 이를 위해서는 다음을 수행해야 합니다.
1: EC2 인스턴스를 불러옵니다
- t2.medium is minimum
- Linux - your choice of which
- Ensure you allow for Open reservation on the EC2 instance when you Launch it
2: 인스턴스에 로그인하고 Linux Tar 탭 아래의 명령을 실행합니다(아래는 예제입니다)
curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.5.0-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.5.0-linux-x86_64.tar.gz
cd elastic-agent-8.5.0-linux-x86_64
sudo ./elastic-agent install --url=https://37845638732625692c8ee914d88951dd96.fleet.us-central1.gcp.cloud.es.io:443 --enrollment-token=jkhfglkuwyvrquevuytqoeiyri
다음은 Playwright를 사용하여 AWS 3계층 애플리케이션의 웹사이트에 트래픽을 추가할 수 있는 간단한 스크립트입니다.
import { test, expect } from '@playwright/test';
test('homepage for AWS Threetierapp', async ({ page }) => {
await page.goto('http://web-tier-external-lb-1897463036.us-west-1.elb.amazonaws.com/#/db');
await page.fill('#transactions > tbody > tr > td:nth-child(2) > input', (Math.random()*100).toString())
await page.fill('#transactions > tbody > tr > td:nth-child(3) > input', (Math.random()*100).toString())
await page.waitForTimeout(1000)
await page.click('#transactions > tbody > tr:nth-child(2) > td:nth-child(1) > input[type=button]')
await page.waitForTimeout(4000)
});
이 스크립트는 세 개의 브라우저를 시작하게 되지만, 이 로드를 playwright.config.ts 파일의 한 브라우저로 제한할 수 있습니다.
이 연습을 위해, 우리는 웹사이트를 테스트하는 동안 약 5시간 동안 이 트래픽을 5분 간격으로 이를 실행했습니다.

어떻게 될지 한 번 볼까요!
이 모든 대시보드는 기본 제공되는 것으로, 다음의 모든 이미지에 대해, 우리는 우리 앱의 관련 항목으로만 보기를 좁혔습니다.
모든 대시보드에 걸쳐, 트래픽 생생기를 실행할 때로 기간을 제한했습니다.

4개의 EC2 인스턴스(웹 서버 2개와 애플리케이션 서버 2개)를 필터링하면, 다음을 확인할 수 있습니다.
1: 4개의 인스턴스가 모두 가동 중이며 상태 확인에 실패하지 않습니다.
2: 전체 기간에 걸쳐 평균 CPU 활용률을 확인할 수 있으며 이상이 없어 보입니다.
3: 데이터베이스에 행이 로드되면, 시간에 따라 집계하며 네트워크 바이트가 유입되고 유출되는 것을 볼 수 있습니다.
이 연습에서는 볼 수 있는 메트릭의 일부를 보여주지만, AWS EC2에서는 더 많은 메트릭을 사용할 수 있습니다. AWS 설명서에 나열된 메트릭은 특정 인스턴스의 검색 범위를 좁히는 데 도움이 되는 차원을 포함하여 모두 사용할 수 있습니다.

ELB 대시보드의 경우, 2개의 로드 밸런서(외부 웹 로드 밸런서 및 내부 애플리케이션 로드 밸런서)를 필터링합니다.
기본 제공 대시보드를 사용하면, 애플리케이션 ELB별 메트릭을 확인할 수 있습니다. AWS 설명서에 나열된 애플리케이션 ELB 특정 메트릭의 상당 부분을 그래프를 추가할 수 있습니다.
두 개의 로드 밸런서의 경우, 다음을 확인할 수 있습니다.
1: 두 호스트(ELB에 연결된 EC2 인스턴스) 모두 정상입니다.
2: 로드 밸런서 용량 단위(사용 중인 용량)와 요청 수 양쪽 모두 트래픽 생성 기간 동안 예상대로 증가했습니다.
3: 우리는 4XX와 2XX의 개수를 보여주기로 했습니다. 4XX는 애플리케이션의 문제 또는 애플리케이션 서버와의 연결 문제를 파악하는 데 도움이 될 것입니다.

RDS에 배포된 AuroraDB의 경우, 대시보드에서 Aurora의 기본 및 보조 인스턴스만을 필터링했습니다.
EC2, ELB와 마찬가지로, Cloudwatch의 대부분의 RDS 메트릭도 새 차트와 그래프를 생성할 수 있습니다. 이 대시보드에서는, 다음을 보여주는 것으로 압축했습니다.
1: 처리량 삽입 및 처리량 선택
2: 쓰기 지연 시간
3: CPU 사용량
4: 기간 동안의 일반 연결 수

애플리케이션 서버의 선두에 있는 2개의 NAT 인스턴스만 살펴보도록 필터링했습니다. 다른 대시보드와 마찬가지로, 필요에 따라 그래프 및 /kr/차트를 구축하는 데 다른 메트릭을 사용할 수 있습니다.
NAT 대시보드의 경우, 다음을 확인할 수 있습니다.
1: 패킷 손실이 없어 NAT 게이트웨이가 잘 되고 있습니다
2: 웹 서버에서 예상되는 활성 연결 수
3: 들어오는 바이트와 나가는 바이트에 대한 상당히 정상적인 메트릭 세트
축하합니다. 이제 애플리케이션에 대한 주요 AWS 서비스의 메트릭 모니터링을 시작하셨습니다!

2. Lambda 로드 포워더를 설치할 수 있습니다. 이 옵션은 여러 위치에서 로그를 가져오게 됩니다. 아래의 아키텍처 다이어그램을 참조하세요.

이 옵션에 대한 검토는 다음 블로그에서도 찾아보실 수 있습니다.
메트릭과 로드(또는 둘 중 하나)를 Elastic으로 가져오면, Elastic의 머신 러닝 기능을 통해 데이터 분석을 시작합니다. 이러한 기능에 대한 훌륭한 리뷰를 여기에서 찾아보실 수 있습니다.
그리고 Elastic의 블로그에 더 많은 동영상과 블로그가 있습니다.
Elastic Observability를 통해 AWS 서비스 메트릭을 모니터링하는 데 도움이 되는 방법을 이해하셨기를 바랍니다. 다음은 학습 내용과 여러분이 배우신 내용을 간단히 요약한 것입니다.
- Elastic Observability는 AWS 서비스 메트릭의 수집 및 분석을 지원합니다
- Elastic Agent를 통해 AWS Services에서 간편하게 수집을 설정합니다
- Elastic Observability에는 기본 제공(OOTB) AWS 서비스 대시보드가 여러 개 있어 정보를 사전 검토한 후 필요에 따라 수정할 수 있습니다
- Elastic Observability의 AWS 통합의 일환으로, 30개가 넘는 AWS 서비스가 지원되며, 계속해서 정기적으로 더 많은 서비스가 추가되고 있습니다
- 관련 블로그에서 언급된 바와 같이, Elastic의 머신 러닝 기능을 통해 AWS 서비스 메트릭을 분석할 수 있습니다
AWS Marketplace를 통해 가입하여 나만의 7일 무료 체험판을 시작하고, 전 세계적으로 AWS의 Elastic Cloud 리전에 대한 배포를 몇 분 안에 빠르게 시작하세요. AWS Marketplace에서 Elastic을 구매하신 경우, 월별 통합 청구 내역서에 포함되며 AWS에 대한 약정 지출에서 반영되어 차감됩니다.
이 게시물에 설명된 기능의 릴리즈 및 시기는 Elastic의 단독 재량에 따릅니다. 현재 이용할 수 없는 기능은 정시에 또는 전혀 제공되지 않을 수 있습니다.