이 블로그는 원래 tfir.io에 게시되었습니다.
Kubernetes는 널리 사용되는 컨테이너 오케스트레이션 시스템으로 Cloud Native Computing Foundation의 핵심 프로젝트입니다. 컨테이너와 컨테이너식 애플리케이션은 물론 하나 이상의 컨테이너 그룹인 ‘포드’의 배포, 수명 주기, 운영을 자동화합니다. 이러한 각 워크로드와 함께 플랫폼 자체도 이벤트 데이터를 생성할 수 있으며, 다양한 유형의 데이터가 이러한 프로세스에 연결되어 있습니다. 로그는 간단한 “yep, got here” 디버그 메시지부터 트랜잭션 정보를 제공하는 상세한 웹 서버 액세스 로그에 이르기까지 다양합니다. 메트릭 또는 시계열 데이터는 일정 간격으로 측정되는 숫자 값입니다. 예를 들어 초당 순간 작업 수, 캐시 적중률, 사이트에 액세스하는 고객 수, 지난 5초 동안 컨테이너가 사용한 CPU 또는 메모리 양과 같은 기본적인 항목이 이에 해당합니다.
Observability는 이러한 로그와 메트릭을 가져와서 일반적으로 상관관계 데이터 저장 공간에서 검색 가능하게 만들며, 로그와 메트릭은 주로 애플리케이션 추적 데이터와 결합됩니다. 이 추적 데이터 또는 상세한 애플리케이션 성능 모니터링(APM) 정보는 애플리케이션 또는 서비스가 실행되는 위치, 상호 작용하는 방법 및 내용, 발생한 모든 오류를 캡처합니다. 로그와 메트릭은 애플리케이션의 블랙박스 뷰를 제공하고 APM 데이터는 애플리케이션 내부에서 발생하는 상황을 보여줍니다.
로그, 메트릭 및 애플리케이션 추적 데이터를 결합하면 평균 탐지 및 해결 시간을 줄이거나 오류 또는 인시던트를 줄일 수 있지만, Kubernetes 배포와 같이 애플리케이션 배포 모델이 진화함에 따라 동적 환경 중 실제로 어디에서 상황이 발생하고 있는지 이해하는 것이 매우 중요해졌습니다. 바로 메타데이터가 중요한 역할을 하는 부분입니다.
메타데이터란 정확히 무엇인가?
Webster의 정의에 따르면 메타데이터는 ‘다른 데이터에 대한 정보를 제공하는 데이터’입니다. 아주 간단하죠? 메타데이터는 다양한 위치에서 쉽게 찾을 수 있습니다. 이 블로그 게시물을 호스팅하는 페이지에도 메타데이터가 있습니다. 메타데이터에는 SEO 태그, 다양한 브라우저가 페이지를 적절하게 형식화하는 데 도움이 되는 힌트, 페이지를 설명하는 데 도움이 되는 키워드가 포함되어 있습니다. 마찬가지로 모바일 디바이스의 사진 한 장에도 많은 메타데이터가 있습니다. 아래 스니펫을 참조하세요.
ExifTool Version Number : 11.11 File Name : 60398459048__A20828DD-FAA4-4133-BA1F-059DEC9E7332.jpeg Directory : . File Size : 2.8 MB File Modification Date/Time : 2020:02:21 08:30:01-05:00 File Access Date/Time : 2020:02:21 08:30:23-05:00 File Inode Change Date/Time : 2020:02:21 08:30:22-05:00 MIME Type : image/jpeg JFIF Version : 1.01 Acceleration Vector : -0.03239090369 -0.9104139204 -0.3862404525 Exif Byte Order : Big-endian (Motorola, MM) Make : Apple Camera Model Name : iPhone XS Orientation : Rotate 90 CW X Resolution : 72 Y Resolution : 72 Exif Image Width : 4032 Exif Image Height : 3024
“아이폰의 MIME 유형을 아는 것이 통합 가시성 이니셔티브에 어떻게 도움이 됩니까?”라고 물으실 수 있습니다. 답은 도움이 되지 않는다입니다. 이는 이미지 메타데이터의 목적이 아니기 때문이죠. 하지만 메타데이터가 어떤 역할을 하는지 가늠해 보실 수 있습니다. 아이폰 메타데이터를 사용하면 사진의 크기, 방향, 사진을 찍을 때 얼마나 흔들렸는지를 필터링할 수 있습니다. (물론 추가 작업이 필요합니다.) 이제, 사용자 환경의 통합 가시성 데이터, 즉 로그, 메트릭 및 애플리케이션 추적 데이터를 상호 연관시키고 탐색하는 데 도움이 되는 내용을 살펴보겠습니다.
소프트웨어 및 하드웨어 배포 트렌드
단일 데이터 센터의 단일 목적 베어 메탈 서버에서 모놀리식 애플리케이션을 실행하던 시대는 지났습니다. 물론 이렇게 전용 워크로드를 실행하는 것이 여전히 일반적이며 아무런 문제도 없습니다. 많은 대규모 애플리케이션 및 제품이 최대한 많은 컴퓨팅을 필요로 하기 때문이죠. 그러나 소프트웨어 및 하드웨어 배포 모델 전반의 업계 트렌드는 마이크로서비스와 컨테이너로 전환하는 것입니다.
그림의 왼쪽에서 오른쪽으로 이동하는 트렌드는 급격하게 진행되지 않습니다. 많은 기업이 다양한 하드웨어 패턴과 함께 다양한 소프트웨어 배포 모델을 병렬로 실행하게 됩니다. 가상 머신 또는 클라우드 인스턴스는 클라이언트/서버 또는 SOA 애플리케이션을 실행하고, Kubernetes 또는 Docker에서 오케스트레이션하는 컨테이너는 마이크로서비스용 이미지를 실행합니다. 대부분의 경우 한 배포 모델의 애플리케이션과 서비스가 다른 배포 모델의 서비스를 활용하게 됩니다. 즉, 새로운 마이크로서비스가 여전히 베어 메탈에 호스팅된 데이터베이스를 사용하고 있을 수 있습니다.
이러한 이기종 시스템의 특성으로 인해 메타데이터가 더욱더 중요해집니다. 컨테이너, 포드, 동적으로 예약된 마이크로서비스로 전환이 이루어짐에 따라 데이터 센터에서 서버 하나를 가리키며 “내 애플리케이션이 모두 여기에 있습니다”라고 말하기가 더 어려워지고 있습니다. 한 서버에 다 있을 수도 있지만 바로 뒤에 있는 다른 4개의 서버에 분산되어 있을 수도 있습니다.
여기에서 위치 메타데이터가 중요한 역할을 합니다. 여기에서 위치는 위도와 경도를 말하는 것이 아니라 주소 체계를 의미합니다. 최소한 데이터의 출처, 즉 데이터가 로그인지 메트릭 또는 애플리케이션 추적 데이터인지를 논리적으로 파악할 수 있습니다.
인프라 특성
위치, 위치, 위치
필요한 것은 현재 구성된 환경에 따라 다르지만 미래에 대비한 계획을 수립해야 합니다. 캡처할 수 있는 양은 특정 작업이 어디에서 실행되고 있는지에 따라 다릅니다. 베어 메탈에서 실행되는 모놀리식 애플리케이션의 경우 사용자는 Kubernetes 포드 세부 정보를 캡처하지 않을 것이며 물론 그래도 상관없습니다. 어디에서 작업이 실행되고 있는지 알 수 있도록 기본적으로 이동 경로를 제공해야 합니다. 그 이유는 잠시 후에 살펴보겠습니다.
Elastic에서는 위치 메타데이터를 통해 작업이 물리적으로 실행되고 있는 애플리케이션 수준까지 메타데이터 계층 구조를 제공하려고 합니다.
데이터 센터
데이터 센터 메타데이터는 도시 이름 등 각 데이터 센터의 고유 식별자를 포함해야 합니다. 클라우드 서비스 제공자의 경우는 도시 이름이 모호할 수 있지만 이에 해당하는 식별자들이 있습니다. 이 경우에는 클라우드 서비스 제공자와 우리가 서비스를 실행하고 있는 리전(예: GCP, europe-west1, 가용 영역 b)을 활용할 수 있습니다.
특정 호스트가 프로덕션 또는 테스트를 위해 예약되어 있거나 여러 프로젝트 간에 분할되어 있는 등 데이터 센터에 전용 티어가 있다면 이 정보도 메타데이터에 추가해야 합니다. 이는 마치 데이터 센터 내에 벽으로 둘러싸인 영역이나 데이터 센터 내 데이터 센터와 같습니다.
호스트 정보
베어 메탈이나 가상화 환경, 클라우드 인스턴스, 어디에서 실행하든 일부 호스트 정보가 정기적으로 제공됩니다. 각 호스트에는 호스트 이름, IP 주소, 하드웨어 모델 또는 인스턴스 유형, 구성된 RAM 및 저장 공간, 심지어 운영 체제 정보에 대한 속성이 있습니다. 여기에서 더 나아가 호스트가 상주하는 위치(데이터 센터의 층수, 랙, 열, 쉘프 정보) 등 훨씬 더 상세한 정보를 포함할 수도 있습니다. 불량 전원이나 배선으로 전체 랙이 영향을 받기도 합니다.
애플리케이션 세부 정보
현재, 각 작업이 실행되는 위치를 식별할 수 있는 충분한 정보가 있지만, 이는 호스트 수준까지의 정보이며 각 호스트가 여러 다양한 서비스 또는 애플리케이션을 실행하고 있을 수 있습니다. 애플리케이션과 서비스의 경우에는 이에 맞는 수준의 메타데이터를 추가해야 합니다. 너무 구체적으로 들어가면 설명이 길어질 수 있으므로 여기에서는 개괄적 수준에서 Kubernetes에서 오케스트레이션하는 마이크로서비스를 사용하는 좀 더 복잡한 시나리오를 살펴보겠습니다. 이를 베어 메탈 애플리케이션 및 가상화 환경에 적용하는 것은 매우 간단합니다.
Kubernetes 및 Docker의 컨테이너는 일정 수준의 메타데이터를 자동으로 제공하므로 이 메타데이터를 포함하면 됩니다. 최소한 컨테이너 및/또는 포드 이름, 컨테이너의 기반으로 사용된 이미지 및 버전, 시작 시간을 메타데이터에 포함해야 합니다. 또한 네트워크 이름 및 IP 정보, 네트워크, 메모리 또는 저장 공간 할당량도 포함하는 것이 이상적입니다. 호스트 정보와 유사한 부분을 눈치채셨나요? 컨테이너와 가상 머신은 기본적으로 다른 호스트에서 실행되는 호스트입니다. 따라서 동일한 정보를 추출하면 됩니다.
가상화된 환경에서 작업할 때도 동일한 유추를 할 수 있습니다. 호스트와 마찬가지로 가상 호스트에도 이름, IP 주소, 메모리 및 저장 공간 제한과 같은 동일한 상위 수준의 세부 정보가 있습니다.
여기에서 약간의 딜레마가 발생하는데요. 일부 필드 이름이 중복되어 있습니다. 메타데이터는 계층 구조를 유지해야 한다는 것을 기억하셔야 합니다. 계층 구조에서 호스트 메타데이터는 컨테이너 또는 가상 머신 메타데이터보다 높은 위치에 있습니다.
├── NYC DC 1
│ ├── Host 1
│ │ ├── vm 1
│ │ ├── vm 2
│ │ └── vm 3
│ └── Host 2
│ ├── vm 1
│ └── vm 2
└── NYC DC 2
└── Host 1
├── vm 1
├── vm 2
├── vm 3
└── vm 4
따라서 중복된 필드 이름이 서로 충돌하지 않도록 예측 가능하고 서로 다른 네임스페이스에 값을 배치해야 합니다. 가장 좋은 방법은 이를 키/값 페어로 전달하는 것입니다. 예를 들어 NYC DC 1에 있는 Host 1의 vm 2에 대한 메타데이터에는 다음이 포함될 수 있습니다.
dc.name: "NYC DC 1" dc.floor: 2 <other dc fields> host.name: "Host 1" host.IP: … host.available_memory_mb: 16384 vm.name: "vm 1" vm.IP: …
컨테이너는 계층 구조가 약간 다릅니다. 하나의 Kubernetes 클러스터가 여러 호스트를 포괄할 수 있기 때문입니다. 이 경우 특정 포드 또는 컨테이너의 위치 정보뿐만 아니라 위에 언급한 해당 오케스트레이션 메타데이터에도 신경을 써야 합니다. 그러면 메타데이터가 애플리케이션에 대한 통합 가시성을 향상하는 데 어떤 도움이 되는지 살펴보겠습니다.
애플리케이션 통합 가시성
시스템에서 실행되고 있는 항목의 위치를 정확하게 설명하는 방법을 알았으니 이제 실제 데이터를 수집하는 방법을 살펴보겠습니다. (메타데이터는 다른 데이터를 설명한다는 것을 기억하세요.) ‘통합 가시성의 3가지 요소’는 로그, 메트릭, 애플리케이션 추적 데이터(APM 데이터라고도 함)이며 때때로 가동 시간 데이터가 4번째 ‘요소’로 포함되기도 합니다. 로그와 메트릭을 수집할 때는 아래 다이어그램에 나와 있는 것처럼 에코시스템의 각 계층에서 수집해야 합니다. 여기에는 각 추상화에 대해 수집해야 하는 통합 가시성 데이터의 유형에 대한 정보가 포함됩니다.
예를 들어 데이터 센터 내 각 호스트 또는 네트워크 요소로부터 로그, 메트릭 및 가용성 데이터를 수집해야 하며, 애플리케이션 및 서비스의 경우에는 APM도 수집해야 합니다.
Elastic에서는 각 티어에 해당하는 메타데이터로 위에 언급된 모든 요소를 보강하여 애플리케이션, 인프라 및 전체 에코시스템의 통합 가시성을 높입니다. 이를 구현하는 방법은 여러 가지가 있습니다. 각 이벤트 또는 추적과 함께 메타데이터를 전송하여 검색과 필터링이 빠르게 수행되도록 하거나 에코시스템에서 정적 영역의 메타데이터를 저장한 다음 나중에 상호 참조하도록 할 수 있습니다. 두 번째 방법이 약간의 공간을 절약할 수 있지만, 특히 동적 에코시스템에서는 오래되거나 쓸모 없는 정보가 될 위험이 있습니다.
퍼즐 맞추기
메타데이터로 보강된 통합 가시성 데이터를 사용하면 특정 APM 데이터 또는 로그를 보는 데만 국한되지 않고 선택한 패싯을 기반으로 데이터를 분석할 수 있습니다. 예를 들어 현재 CPU 활용률을 다음과 같이 호스트별 또는 서비스별로 나눌 수 있습니다.
아니면 동일한 파라미터를 원하는 시간대별로 확인할 수도 있습니다.
이를 통해 재구성하려는 세부 정보를 선택하여 다른 방법으로는 해결할 수 없는 다음과 같은 질문에 답할 수 있습니다.
- 미국 데이터 센터가 EMEA 데이터 센터와 비교하여 과다 사용되고 있나요?
- 에코시스템에서 다른 랙보다 오류가 더 많이 발생하는 랙이 있나요?
- 일부 개발용 인프라를 프로덕션용으로 변경할 수 있나요?
- 전자 상거래 앱의 컨테이너와 포드는 어떤 물리적 호스트에서 실행되고 있나요?
- 마지막으로, 내 아이폰 사진이 왜 항상 흐릿하게 나오나요?
결론
메타데이터는 데이터를 집계하고 분석하는 새로운 방법을 제공함으로써 분석에 새로운 차원을 추가하여 비즈니스 및 운영 문제에 대한 답을 얻도록 도와줍니다. 통합 가시성 이니셔티브에 사용하는 솔루션이 비즈니스와 함께 성장할 준비가 되어 있는지 확인하고, Elastic Common Schema와 같이 검색 가능하고 탐색 가능한 메타데이터를 고려하여 메타데이터가 여러분이 기대하는 바를 충족하도록 하십시오.