최신이야기 | 브레인즈컴퍼니

메인 페이지로 이동
블로그
최신이야기

블로그

클라우드(Cloud) 관리와 AWS가 뭔가요?

이운형 2023.11.16

오늘날 IT 인프라 운영환경은 매우 복잡해졌어요. 갑작스러운 환경 변화에 따라 신속한 대응도 필요한 시점이죠. 이러한 현상으로 많은 기업들이 온프레미스(On-premise) 환경에서 클라우드(Cloud) 환경으로 전환하는 추세이기도 해요.

클라우드 컴퓨팅 서비스 중에는 여러 벤더가 있는데요. 대표적으론 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)가 있어요.

그중 ‘AWS’는 국내 클라우드 시장에서 3년 간 70% 내외의 시장점유율로, 1위를 차지했는데요(*클라우드 서비스 분야 실태조사(2022), 공정거래위원회)

이처럼 높은 점유율을 가진 1) AWS의 주요 서비스를 살펴보고 2) 하이브리드 클라우드 모니터링이 필요한 이유는 무엇인지 3) AWS의 각종 서비스를 모니터링할 수 있는 제니우스(Zenius)도 함께 소개해 드릴게요!

AWS(Amazon Web Services)란?

AWS는 ‘Amazon Web Services’의 약어로, 아마존 닷컴이 제공하는 클라우드 컴퓨팅 플랫폼 및 서비스의 집합이에요. AWS에서 제공하는 여러 가지 서비스를 이용하면, 기업 및 개인이 필요한 컴퓨팅 리소스를 유연하게 확장하고 관리할 수 있죠. AWS 주요 서비스는 다음과 같아요!

AWS 주요 서비스

▪Amazon VPC(Amazon Virtual Private Cloud)

격리된 네트워크 환경을 구성하게 해주는 서비스예요. AWS의 동일 계정이나, 서로 다른 계정 간에 격리된 네트워크를 연결할 수 있도록 다양한 옵션들을 제공해 줘요.

▪Amazon EC2(Amazon Elastic Compute Cloud)

AWS에서 가장 많이 사용되는 컴퓨팅 서비스예요. 가상 서버를 호스팅 할 때 사용하죠. 리눅스나 윈도우 환경 등 다양한 인스턴스 유형을 지원하고, 필요에 따라 성능을 조정할 수 있어요. 생성 가능한 인스턴스 타입은 리전 별 차이가 있으나, 100개~300개에 이를 정도로 방대하답니다.

▪AWS Lambda

AWS에서 제공하는 서버리스 컴퓨팅 플랫폼이에요. 여기서 ‘서버리스’란 개발자가 서버의 존재를 신경 쓸 필요가 없다는 뜻이에요. AWS에서는 서버 인프라에 대한 프로비저닝, 유지관리 등을 대신 처리해 주죠. 이처럼 개발자가 비즈니스 로직에 집중하여 코드를 실행하게 해줘요.

▪Amazon S3

AWS에서 제공하는 스토리지 서비스예요. S3는 파일시스템이 아닌 오브젝트 스토리지 서비스로, 모든 파일에 API를 통해 접근 가능해요. 무제한적인 확장성, 높은 가용성과 내구성을 제공하며 단일 파일을 최대 5TB까지 업로드할 수 있어요.

▪Amazon EBS(Amazon Elastic Block Store)

EC2 인스턴스에 장착하여 사용할 수 있는 가상 저장 장치에요. EBS를 연결하여 파일을 저장하면, EC2 인스턴스와 관계없이 데이터를 영구적으로 보관 가능해요. 이 밖에도 AWS에서 제공하는 서비스는 매우 방대한대요. 아래 URL로 접속 시, 필요한 서비스 목록 확인이 가능하답니다!

? 더 많은 AWS 서비스가 궁금하다면?

온프레미스와 AWS의 차이

온프레미스 방식은, 클라우드 컴퓨팅 서비스가 나오기 전까지 기업에서 전통적으로 사용한 ‘일반적인 인프라 구축 방식’이에요. 온프레미스 환경에서 서버를 운영하면, 호스팅 서비스를 이용하거나 서버를 직접 구매 또는 임대하죠. 그다음 데이터 센터(IDC, Internet Data Center) 또는 기업 전산실에 설치하여 운영해요.

하지만 물리적인 서버를 직접 설치할 경우, 많은 시간과 비용이 소모되어 이를 위한 운영 공간과 인력이 필요할 수 있어요.

예시를 들어 볼게요. 대형 콘서트 예매, 대학교 수강신청, 입시 원서 접수 등 단기간에 트래픽이 급증했다가 감소되는 경우를 생각해 볼까요? 이때 ‘온프레미스 방식’으로 시스템을 구축한다면, 매우 많은 비용 낭비가 발생하게 될 거예요.

반면 AWS의 경우는 어떨까요? 인터넷이 연결된 어디에서든 쉽게 인프라를 구축하고, 사용한 만큼 비용을 지불할 수 있어요. 큰 이벤트를 처리한 후 생성된 리소스를 간편하게 삭제할 수 있죠. 이처럼 온프레미스 방식과 대비한다면, 남는 자원에 대한 비용 고민이 없어지겠죠?

하이브리드 클라우드 모니터링이 필요한 이유

이처럼 AWS는 매우 유연하고 확장성 있는 클라우드 서비스예요. 하지만 모든 서비스를 AWS를 이용해서 서비스하는 것은 한계가 있는데요. 이유는 다음과 같아요.

▪보안 및 규정 준수

민감한 데이터나 규정 준수가 필요한 업무의 경우, 사설 클라우드나 온프레미스 환경의 자체 데이터 센터를 통해 운영하려는 경향이 있어요.

▪비용 효율

AWS는 사용한 만큼 비용을 지불하기 때문에, 예측할 수 없는 트래픽 증가 등에 대응하기에 좋아요. 하지만 서비스에 따라 온프레미스 환경에서 운영하는 것이 비용 측면에서 더 효율적인 경우가 있죠.

이처럼 많은 기업이 AWS를 이용한 클라우드 서비스로 전환하는 추세지만, 당분간 온프레미스 방식과 결합한 하이브리드 클라우드 운영환경이 많은 편이에요.

그렇다면 이러한 하이브리드 클라우드 운영 환경을 모니터링할 수 있는 방법이 없을까요? 바로 ‘제니우스’를 활용한다면 가능해요!

제니우스를 이용한 하이브리드 클라우드 모니터링 구성도

제니우스 하이브리드 클라우드 모니터링 프로세스를 간략히 소개할게요!

우선 클라우드 환경 단계에서는 AWS 서비스를 이용하여 구축된 클라우드 환경 정보를 RestAPI 방식으로 수집해요. CMS Manager는 AWS 클라우드 환경에서 수집한 정보를 취합 후 스토리지에 저장해 주죠.

EMS Manager는 온프레미스 환경에서 수집한 정보를 취합 후 스토리지에 저장해 줘요. Web UI에서는 스토리지에 저장된 데이터를 이용하여, 사용자에게 모니터링 정보를 제공한답니다!

제니우스에서 AWS 모니터링하기

제니우스를 이용한 ‘하이브리드 클라우드 모니터링 구성’을 좀 더 자세히 살펴볼까요?

▪CMS > 모니터링 > 요약 : 위 그림은 AWS 통합 요약 페이지인데요. EC2, RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있어요.

▪EMS > 토폴로지 > 클라우드 맵 : 리전 별 자동 구성형 클라우드 맵 페이지에서는, AWS 리전 별 이용하는 서비스와 연관관계를 클라우드 맵이 자동으로 구성해 줘요.

▪CMS > 클라우드서비스 > EC2 > 주요 성능 지표 : 주요 성능지표 모니터링 페이지에서는 AWS 콘솔에 접속하지 않고, AWS 주요 성능 지표에 대한 모니터링 추이를 확인할 수 있어요.

▪EMS > 오버뷰 : 오버뷰를 통한 온프레미스 + AWS 통합 모니터링 페이지에서는, AWS 모니터링 항목과 온프레미스 환경 모니터링 항목의 통합 현황판을 확인할 수 있어요.

이처럼 AWS와 온프레미스 환경은 물론, 더 다양한 환경의 인프라 모니터링을 위해 제니우스를 사용을 해보는 건 어떨까요?

이운형Technical Consulting팀

Technical Consulting팀에서 제품구축과 유지보수 업무를 수행하고 있습니다.

필진 글 더보기

추천 콘텐츠

Filebeat vs Logstash, 대규모 로그 수집 환경에서 더 적합한 선택은?! Filebeat vs Logstash, 대규모 로그 수집 환경에서 더 적합한 선택은?! 대규모 시스템에서 로그는 단순한 기록이 아니라, 장애 진단과 보안 분석, 운영 자동화를 위한 핵심 데이터 소스입니다. 하지만 로그 수집량이 기하급수적으로 늘어나면 기존 Logstash 기반 아키텍처는 JVM 오버헤드와 자원 점유 문제로 병목이 발생하기 쉽습니다. 이런 한계를 보완하기 위해 주목받는 것이 Filebeat입니다. 경량 Go 기반으로 설계된 Filebeat은 CPU와 메모리 부담을 최소화하고, 수집과 전송에 집중함으로써 분산 환경에서도 안정적으로 동작할 수 있습니다. 이번 글에서는 왜 Logstash 대신 Filebeat을 선택하게 되었는지, 그리고 이를 통해 어떤 운영상의 안정성과 효율성을 확보할 수 있었는지 살펴보겠습니다. 1. 왜 Logstash 대신 Filebeat를 사용하게 되었나? 통합로그관리 시스템 개발 초창기 파일 로그 수집 에이전트로 Logstash를 사용했습니다. 그러나 고객사의 폭발적인 로그 증가와 대규모 환경 요구사항에 효과적으로 대응하고 시스템의 안정성을 위해, 로그 수집 에이전트를 Filebeat로 전환하게 되었습니다. 왜? Logstash 기반 아키텍처를 바꾸었는지, 그리고 Filebeat 도입이 가져온 기술적 이점과 주요 설정은 무엇인지 자세히 살펴보겠습니다. * 수집 에이전트 교체, 무엇이 문제였고 무엇을 얻었나? 수집해야 할 로그 소스(서버, 네트워크 장비, 보안 솔루션 등)가 폭발적으로 증가하면서, 기존의 Logstash 기반 수집 아키텍처는 다음과 같은 근본적인 한계에 직면했습니다. 안정적인 SIEM 운영을 위해서는 수집 에이전트의 경량화, 안정성, 리소스 효율성 확보가 최우선 과제였으며, 그 해답으로 Filebeat를 선택하게 되었습니다. Filebeat는 Logstash의 경량화된 버전으로, 에이전트 수집 역할을 담당합니다. 즉, 로그가 생성되는 서버에 설치되어 로그 파일을 읽고 바로 OpenSearch(이전의 Elasticsearch) 또는 Kafka와 같은 목적지로 전송하는 역할을 합니다. Filebeat는 Go 언어로 개발되어 메모리 사용량이 극히 적고, CPU 부하도 거의 발생시키지 않습니다. Filebeat로 변경은 단순히 도구를 바꾼 것이 아닌, 로그 파이프라인의 효율성과 안정성을 극대화하는 전략적 선택이었습니다. 다음으로는 Logstash에서 Filebeat로 전환함으로써 얻은 주요 장점과 기술적인 이점, 그리고 Filebeat의 주요 설정에 대해 살펴보겠습니다. 2.Filebeat 전환을 통한 구체적인 이점은?! Filebeat로의 전환은 성능 개선을 넘어, 파일 수집 아키텍처를 현대적인 분산 처리 구조로 진화시켜 안정성, 유연성, 개발 효율이라는 세 가지 핵심 이점을 확보했습니다. (How Filebeat works) [1] 데이터 흐름 제어 및 안정성 Filebeat의 가장 중요한 기능 중 하나는 백프레셔(Backpressure) 메커니즘입니다. Filebeat는 데이터를 전송하는 중앙 시스템(Kafka 또는 OpenSearch Ingest Node)에 부하가 걸려 처리 속도가 느려질 경우, 스스로 로그 전송 속도를 늦춥니다. 이 지능적인 흐름 제어 덕분에 중앙 시스템의 과부하를 막고, 데이터 파이프라인이 붕괴되는 것을 방지하여 안정적인 로그 흐름을 보장합니다. [2] 유연한 운영 환경 Filebeat는 탁월한 운영 유연성을 제공합니다. 특히 filebeat.config.inputs 기능을 활용한 동적 설정 관리는 Filebeat 재시작 없이 새로운 로그 소스를 실시간으로 추가/변경할 수 있게 해 운영의 유연성을 극대화합니다. Zenius SIEM 역시 설정 편집 기능을 제공하여 이러한 운영 유연성을 확보하고 있습니다. [3] 메타데이터 사전 분류와 ECS 정규화 fields.* 기능을 이용해 수집 단계에서 로그 유형(mtype) 등을 태깅하여 중앙 시스템의 ECS(Elastic Common Schema) 기반 정규화를 위한 '분류 키' 역할을 합니다. ECS를 통해 모든 로그가 표준화되므로, 상관관계 분석 및 일관된 검색/시각화 효율이 극대화됩니다. *여기서 ECS란?* ECS는 보안 이벤트, 로그 등 모든 데이터를 공통된 필드 이름으로 정의하는 표준 스키마입니다. 서로 다른 로그 소스(예: Apache, Windows 이벤트)에서 수집된 데이터라도 ECS를 적용하면 동일한 표준 필드(source.ip, destination.port 등)를 갖게 되어 검색과 분석이 용이해집니다. 예시) cpu_pct 라는 ECS가 있다면 “cpu > 60” 검색 시 해당 ESC가 적용된 모든 로그를 찾아 로그의 수집,출처 및 내용을보여줄 수 있음 *SIEM에서의 이점 극대화* - 일관성 확보: 모든 로그가 ECS를 기반으로 표준화되므로, 분석가들은 매번 다른 필드 이름을 외울 필요 없이 표준화된 필드로 일관성 있게 검색 및 대시보드를 구축할 수 있습니다. - 분석 효율성 확보: 모든 로그가 공통 스키마를 따르기 때문에 상관관계 분석(Correlation)을 효율적으로 수행하여 보안 위협을 신속하고 정확하게 식별하는 데 큰 도움이 됩니다. 결론적으로, Filebeat의 fields.* 기능은 단순 태깅을 넘어, 데이터를 중앙에서 ECS로 효율적이고 정확하게 정규화하기 위한 SIEM 아키텍처의 필수적인 개발 포인트입니다. 다음 내용에서는 Filebeat의 구체적인 작동 방식을 정의하는 주요 설정들을 살펴보겠습니다. 3.Filebeat 주요 설정 Filebeat를 사용하기 위해서는 filebeat.yml 파일에 주요 설정을 정의해야 합니다. 이 파일에는 어떤 로그 파일을 모니터링할지, 어떤 포맷으로 데이터를 전송할지, 그리고 어떤 목적지로 보낼지에 대한 정보가 포함됩니다. [1] Filebeat 핵심 환경 설정 (Configuration) 로그 파일 수집 자체를 제외한 Filebeat의 실행 환경, 관리 유연성, 데이터 전송 메커니즘, 그리고 운영 안정성을 정의합니다. 이러한 설정은 SIEM 아키텍처의 견고함을 결정하는 핵심 요소입니다. (설정은 환경에 따라 변경 가능하며 아래는 예시로 설정한 부분을 설명 합니다.) [2] filebeat.inputs - 로그 파일 모니터링 정의 (수집) Filebeat가 어떤 로그 파일을 읽고 수집할지 정의하며, 수집된 로그에 메타데이터를 부여하는 핵심 부분입니다. 가장 일반적인 설정은 paths를 사용하여 로그 파일의 경로를 지정하는 것입니다. 위 설정은 /var/log/secure/ 파일을 읽도록 Filebeat에 지시합니다. fields를 사용하여 로그에 메타데이터를 추가할 수 있습니다. [3] Processors - 경량 데이터 가공 로그를 목적지로 전송하기 직전에 간단한 가공을 수행하여 중앙 시스템의 부하를 줄이고 필수 메타데이터를 추가할 수 있습니다. (메타데이터 추가 예시) (Drop 설정 예시, (ex)Linux audit log 수집 시 특정 경로의 로그 제외 설정) [4] Output - 데이터 전송 목적지 정의 로그 수집 및 가공을 마친 데이터를 전송할 최종 목적지를 정의합니다. 아래 예시에서는 Kafka를 목적지로 사용하여 대규모 로그 처리 및 부하 분산의 이점을 확보합니다. Filebeat의 filebeat.yml에 있는 다양한 설정 옵션들은 로그 수집의 안정성과 효율성을 결정하는 핵심적인 요소입니다. 이러한 주요 설정 기능들을 적절히 활용한다면, 대규모 환경에서도 안정적이고 효율적인 수집 체계를 성공적으로 구축할 수 있습니다. 이제 마지막으로, Zenius SIEM에서 이러한 Filebeat 설정 기능들이 실제로 어떻게 활용되었는지 살펴보겠습니다. 4. Zenius SIEM의 Filebeat 활용 (중앙 집중식 Filebeat 관리) Zenius SIEM 솔루션은 Filebeat의 기술적 장점을 실제 운영 환경에서 활용 할 수 있도록 YML 설정 편집 및 중앙 집중식 관리 기능을 제공합니다. 이는 대규모 에이전트 환경의 운영 부담을 획기적으로 줄여주며, 고객이 Filebeat의 세밀한 기술적 기능을 직접 제어하고 커스터마이징할 수 있게 합니다. - GUI 기반 YML 편집기 및 전용 설정 기능 Zenius SIEM은 운영자가 Filebeat의 설정을 세밀하게 제어하고 편리하게 관리할 수 있도록 GUI 기반 YML 편집기를 제공합니다. 운영자는 이 환경에서 Filebeat의 모든 YML 설정 (Inputs, Processors, Output 등)을 직접 수정하고 커스터마이징 할 수 있습니다. 특히 로그 수집 안정성에 필수적인 핵심 기능, 예를 들어, 멀티라인 패턴, negate, match, tail files, 동시 수집 파일 수, include lines, exclude lines은 별도의 전용 인터페이스를 통해 더욱 편리하게 설정할 수 있도록 지원하여, 복잡한 설정도 쉽게 관리할 수 있습니다. - 중앙 집중식 설정 수백 대의 서버에 설치된 Filebeat 에이전트의 설정을 관리하고 설정과 동시에 Filebeat의 동적 설정 기능 (filebeat.config.inputs 등)을 활용하여 에이전트 재시작 없이 즉시 변경 사항을 반영한다는 것입니다. 이는 서비스 중단 없이 운영 환경을 유지할 수 있게 해줍니다. - 에이전트 제어 및 상태 모니터링 분산된 로그 수집 환경을 통합적으로 관리하기 위해, Zenius SIEM은 에이전트 제어 및 상태 모니터링 기능을 제공합니다. 각 에이전트의 실행 상태 확인, 원격 재시작, 버전 관리 등의 제어 기능을 단일 시스템에서 제공하여, 운영자가 분산된 에이전트 환경을 쉽게 관리하고 장애 발생 시 신속하게 대응할 수 있도록 돕습니다. (수집 상태 모니터링 기능) (에이전트 관리 기능) 5. 마치며 지금까지 Logstash에서 Filebeat로의 전환 배경과 그 이유, Filebeat의 주요 기능과 설정, 그리고 Zenius SIEM 환경에서의 실제 활용 사례를 중심으로 살펴보았습니다. 이번 전환은 단순한 에이전트 교체를 넘어, 대규모 환경의 요구사항에 보다 적합한 아키텍처를 구축하기 위한 전략적인 선택이었습니다. Filebeat 도입을 통해 Zenius SIEM은 다음과 같은 측면에서 운영 기반을 한층 강화할 수 있었습니다: -경량화 및 안정성 향상 Go 언어 기반의 경량 구조로 서버 자원 사용을 최소화하고, 백프레셔(Backpressure) 및 레지스트리(Registry) 기능을 통해 로그 유실 없는 안정적인 수집 환경을 구현했습니다. -운영 유연성과 분석 효율성 확보 동적 설정 관리 기능을 통해 다양한 환경에서 유연하게 운영할 수 있었으며, ECS 필드 구조(fields.*)를 적극 활용해 로그 분석과 데이터 정규화를 보다 체계적으로 수행할 수 있게 되었습니다. Zenius SIEM은 이러한 Filebeat를 중앙 집중식 관리 시스템과 통합하여, 고객 환경에 최적화된 안정적이고 효율적인 로그 수집 서비스를 제공하고 있습니다. 지금까지 Logstash에서 Filebeat로의 전환을 통해 어떤 기술적 변화가 있었고, 그것이 실제 운영 환경에 어떻게 적용되었는지를 정리해 보았습니다. 변화하는 IT 환경 속에서 로그 수집 방식 또한 지속적으로 진화하고 있으며, 앞으로도 이에 대한 다양한 시도와 고민은 계속될 것입니다. 2025.10.21