VMS Solutions의 AWS 기반 데이터 아키텍처 구축과 보안 최적화 사례

VMS Solutions (브이엠에스 솔루션스)는 첨단 제조업의 생산 계획 최적화를 선도하는 APS(Advanced Planning and Scheduling) 전문기업으로, 2024년 가트너 아시아태평양 Supply Chain Planning 분야에서 Notable Vendor로 선정된 바 있습니다.

브이엠에스 솔루션스의 주력 제품인 MOZART는 고성능 데이터 처리와 시스템 연동을 통해 제조업체의 생산성을 혁신하며, 특히 클라우드 기반의 MOZART Cloud는 AWS 인프라를 활용해 뛰어난 확장성과 보안을 제공합니다.

MOZART Cloud는 AI 기반 예측 모델과 디지털 트윈 기술을 통해 실시간으로 생산 데이터를 분석하고, 변화하는 시장 수요와 생산 조건에 신속하게 대응할 수 있도록 지원합니다. 이를 통해 제조업체는 스마트팩토리를 구축하여 운영 효율성을 극대화하고, 복잡한 생산 환경에서도 정확한 데이터 기반 의사 결정을 내릴 수 있습니다.

또한, 공정 간 데이터 투명성을 높여 협업을 강화하고, 전체 생산 프로세스를 더욱 효율적으로 관리할 수 있습니다. 브이엠에스 솔루션스의 MOZART Cloud는 제조업의 디지털 전환을 가속화하는 핵심 플랫폼으로 자리 잡고 있습니다.

프로젝트 소개

MOZART Cloud는 방대한 데이터를 효율적으로 수집하고 관리하여 다양한 AI 기술을 쉽게 도입할 수 있도록 설계된 플랫폼입니다. 브이엠에스 솔루션스는 데이터의 수집, 분석, 보관 등 모든 과정에서 데이터를 효과적으로 활용하고, 이를 안전하게 보호할 수 있는 환경을 구축하는 것이 중요했습니다.

이를 해결하기 위해 브이엠에스 솔루션스는 AWS와 메가존클라우드와 함께 Partner-Led Data Lab을 진행했습니다. Partner-Led Data Lab은 AWS 파트너사가 주도하여 고객사의 환경에 적합한 인프라 구성을 파악하여 최적의 아키텍처를 함께 설계하는 프로그램입니다. 실습 세션을 통해 고객사는 AWS의 다양한 서비스와 솔루션을 실제 환경에서 효과적으로 활용하는 방법을 학습할 수 있습니다.

Data Lab 진행 과정에서 확장성과 효율성을 고려하여 서버리스 아키텍처 기반의 데이터 관리 시스템을 구축했습니다. AWS S3 데이터 레이크와 ETL 파이프라인을 활용해 데이터 적재 및 관리 효율성을 극대화 했으며, Amazon Athena를 사용해 대규모 데이터 분석 작업의 비용 효율성을 높였습니다. 데이터 보안을 강화하기 위해서 AWS Key Management Service (KMS)와 IAM을 통해 데이터를 암호화하고 권한을 관리했습니다. 실시간 보안 감시를 위해 GuardDuty와 Config를 사용했으며, 네트워크 보안을 위해 VPC, Security Group, Network ACL을 통합하여 다층적인 보안 체계를 구축했습니다.

또한, Amazon OpenSearch, Amazon CloudWatch, AWS Security Hub를 통해 실시간 모니터링 및 중앙 보안 관리 시스템을 운영하여 잠재적 위협을 조기에 감지하고 신속하게 대응할 수 있는 환경을 마련했습니다.

이러한 Data Lab 활동을 통해 브이엠에스 솔루션스는 제조업체가 데이터를 안전하게 관리 하면서도 AI 솔루션을 효과적으로 도입할 수 있는 최적의 데이터 아키텍처와 보안 체계를 구축했습니다.

아래 그림은 Data Lab 기간 동안 랩 목표에 맞게 실제 AWS 서비스를 실습해 볼 수 있도록 구성한 초기 아키텍처입니다.
이번 Lab의 주요 목표는 기존 시스템과 클라우드 간 데이터 인프라의 효율성을 극대화하는 것이었습니다. 이를 위해, 엔진 결과 데이터를 AWS S3에 성능 효율적으로 저장하고 처리할 수 있도록 최적의 파티션 키를 설정했습니다. 또한, 비용과 성능을 고려해 적절한 데이터 포맷과 압축 방식을 선택하여 저장 공간과 스캔 비용을 최적화 했습니다. 추가로, Amazon OpenSearch를 활용해 SIEM(보안 정보 및 이벤트 관리) 기반의 보안 관리와 로그 통합 시스템을 구축했습니다.

엔진 결과 데이터 S3 저장 및 파티션 키

-- 테이블 파티션 조회하기 - 1️⃣
SHOW PARTITIONS vms_test_stg.lot_history_gzip; 
 
-- 테이블 전체 파티션 생성하기 - 2️⃣ (S3 location 데이터 기반) : key=value 형태의 파티션 형식 준수 필요
-- MSCK REPAIR 명령어는 자동으로 파티션키를 생성해주는 편리한 기능이나 파티션이 많아지면 성능 이슈가 발생할 수 있음
MSCK REPAIR TABLE vms_test_stg.lot_history_gzip;
 
 
-----------------------------------------------------------------------------
-- 주로 조회하는 대상 데이터에 대해서만 쿼리할 수 있도록 파티션을 수동으로 관리하는 것을 권고함
-----------------------------------------------------------------------------
 
-- 수동으로 파티션 생성하기 - 3️⃣
ALTER TABLE vms_test_stg.lot_history_gzip ADD IF NOT EXISTS PARTITION (partition_key='aaaaaaaaaaaa@202410’);
 
-- 수동으로 파티션 삭제하기 - 4️⃣
ALTER TABLE vms_test_stg.lot_history_gzip DROP IF EXISTS PARTITION (partition_key='aaaaaaaaaaaaaa@202409’);
 
-- 파티션 삭제하고 조회하기 - 5️⃣ è S3에 데이터가 저장되어 있더라도 partition key 가 삭제되면 쿼리 조회가 안되는 것을 확인
SELECT * FROM vms_test_stg.lot_history_gzip;

Centralized Logging 시스템 구축 과정에서 가장 중요한 포인트는 데이터 저장시 S3 버킷 구조, 파티션 키 설계 부분이었습니다. 버킷 구조 와 파티션 키가 중요한 이유는 크게 2가지가 있습니다.

첫째, 버킷 구조 와 파티션 키를 활용해 데이터를 논리적으로 구분하면, 특정 조건의 데이터만 빠르게 조회할 수 있어 전체 데이터를 스캔할 필요가 없습니다. 예를 들어, 날짜나 지역별로 데이터를 구조화 하면, 특정 범위나 조건에 맞는 데이터를 쉽게 검색하고 효율적으로 접근할 수 있습니다. 이는 쿼리 실행 속도를 크게 높여줍니다.

둘째, 버킷 구조를 통해 데이터 수명 주기에 따라 데이터를 구분해 저장하면, 자주 접근하는 데이터는 고속 액세스 스토리지에, 장기 보관용 데이터는 저비용 스토리지 클래스로 저장할 수 있어 S3 비용을 절감할 수 있습니다.

아울러 버킷 구조와 파티션 키 이외에도 S3 에 데이터를 저장할 때 저장 포맷은 데이터의 처리 속도, 저장 공간 효율성, 비용 절감에 중요한 영향을 미칩니다. 적절한 포맷을 선택하면 쿼리 성능을 높이고, 데이터 스캔 크기를 줄여 비용을 절감할 수 있기 때문입니다. 예를 들어, Parquet와 같은 컬럼 기반 포맷은 분석에 적합하며, 데이터 압축과 파티셔닝을 활용해 S3 저장 공간을 효율적으로 사용할 수 있습니다. 샘플데이터를 가지고 테스트 한 후 검토 결과, 데이터 분석에 최적화된 Parquet 포맷에 Snappy 압축 방식으로 데이터를 저장하기로 결정하였으며, 이를 통해 쿼리 속도와 비용 절감 효과를 기대할 수 있습니다.

Athena 를 사용해 해당 테이블에 적용되어 있는 파티션 키를 1️⃣ 과 같이 조회할 수 있으며, 2️⃣ 와 같이 S3 에 저장 되어 있는 위치를 기반으로 전체 파티션을 생성할 수 도 있습니다.

자동 파티션 키 생성 방식(MSCK REPAIR)은 명령 한줄로 모든 누락된 파티션키를 생성할 수 있다는 이점이 있지만, 성능 문제를 초래할 수 있습니다. 이는 파티션키 수가 많아지면 MSCK 명령 수행시 모든 파티션 데이터를 확인하기 위해서 성능에 영향을 미칠 수 있기 때문입니다.

따라서 파티션이 너무 많아질 경우, 3️⃣ 과 4️⃣ 의 경우 처럼 ALTER TABLE ADD PARTITION이나 ALTER TABLE DROP PARTITION 명령어를 사용해 특정 파티션을 추가하거나 삭제할 수 있고, 운영시 쿼리하지 않는 일부 데이터의 파티션을 정리하거나, 특정 파티션만 남기고 나머지를 삭제하는 등의 수동 관리 방법을 병행할 수 있습니다.

아래의 표는 브이엠에스 솔루션스의 샘플 데이터를 활용하여 압축형식에 따라 테스트 한 결과 입니다.

Centralized Logging 시스템 구축을 위한 아키텍처 고민

다양한 로그를 효율적으로 수집하고 통합 관리하기 위해 처음 구상했던 아키텍처는 충분하지 않았습니다. 이에 따라 Data Lab을 진행하는 5일 동안 아키텍처 고도화 작업을 지속적으로 진행했습니다. 그 결과, 두 번째로 구상된 아키텍처는 다음과 같습니다.

위 아키텍처는 최종 형태가 아니었습니다. 상세 구현 과정에서 여러 시행착오를 겪으며 점차 개선하여 더욱 적합한 파이프라인을 완성해 나갔습니다. 이제부터 각 로그 유형별 상세 파이프라인 구축 단계를 하나씩 살펴보겠습니다.

SIEM(보안 정보 및 이벤트 관리) Centralized Logging 시스템 구축

이 파이프라인에서 AWS Config, Amazon GuardDuty, AWS Security Hub, Amazon EventBridge 그리고 Amazon Kinesis Data Firehose가 순차적으로 연결되면서 보안 로그를 수집, 모니터링, 알림하는 과정을 구현하였습니다.

AWS Config 는 AWS 리소스의 구성을 지속적으로 평가하고 기록하는 서비스입니다. 리소스의 설정 변경을 기록하고 이를 기준으로 규정 준수 여부를 평가할 수 있습니다. 각 리소스의 상태 변경 이벤트가 기록되며, 이를 통해 실시간 모니터링과 과거 구성 이력을 추적할 수 있습니다. Config 는 리소스와 관련된 모든 변경 사항을 기록하기 때문에 비용이 증가할 수 있습니다. 필요한 리소스만 모니터링 하도록 설정해 비용을 절감할 수 있도록 하는 것이 좋습니다. 규정 준수 규칙을 정의하여 특정 조건에서만 알림을 받을 수 있게 설정하는 것도 가능합니다.

Amazon GuardDuty 는 AWS 계정과 관련된 보안 위협을 실시간으로 탐지하는 서비스입니다. VPC flow 로그, AWS CloudTrail 이벤트, DNS 로그 등을 분석해 악성 활동을 탐지하며, 의심스러운 활동에 대한 경고를 생성합니다. GuardDuty 는 활성화 후, 계정에 대한 지속적인 모니터링을 수행하므로 비용이 발생할 수 있습니다. 또한, 오탐지를 줄이기 위해 특정 활동에 대한 화이트리스트를 설정할 수 있습니다. GuardDuty가 생성한 결과를 AWS Security Hub로 전송해 종합적으로 관리도 가능합니다.

AWS Security Hub는 AWS 전반에 걸친 보안 상태를 종합적으로 모니터링하고 관리하는 서비스입니다. GuardDuty, Config 등 여러 보안 서비스의 결과를 중앙화하여 보여주며, 표준 보안 프레임워크에 따라 보안 상태를 평가합니다. Security Hub를 활성화하면 여러 보안 결과가 자동으로 수집되므로, 알림 설정을 세심하게 관리해야 합니다. 중요도에 따라 알림을 우선순위화하고, 자동화된 대응을 설정해 업무를 간소화하는 것이 좋습니다. 비용 측면에서 Security Hub가 통합 데이터를 제공하기 때문에 데이터의 양과 필요한 규정 준수 프레임워크를 적절히 선택해야 하는것이 좋습니다.

Amazon EventBridge는 AWS 서비스와 애플리케이션 간 이벤트 스트림을 연결하는 서비스입니다. Security Hub에서 전달된 보안 이벤트를 필터링해 특정 조건에 따라 다른 서비스(예: Data Firehose)로 전달하거나 경고를 생성할 수 있습니다. EventBridge 의 규칙 설정은 정확해야 하며, 특정 조건에 맞는 이벤트만 전송하도록 필터를 세분화하는 것이 중요합니다. 너무 많은 이벤트가 전송되면 후속 처리에 과부하가 걸릴 수 있습니다.

Data Firehose는 실시간으로 스트리밍 데이터를 수집하고 S3, OpenSearch Service, Redshift 등 타겟 서비스에 적재하는 서비스입니다. 이 파이프라인에서는 보안 로그를 S3 나 OpenSearch로 전송해 검색 기능과 대시보드 구성까지 이루어집니다. Data Firehose 는 데이터를 실시간으로 수집해 전송하므로, 데이터 양이 많으면 저장 비용이 급증할 수 있습니다. 데이터를 적재할 대상(S3 나 OpenSearch 등)의 용량과 성능을 고려해 설정을 최적화하는 것이 중요합니다. 또한, Firehose 내에서 데이터 변환 기능을 사용해 데이터를 필요한 형식으로 조정할 수 있지만, 비용이 증가할 수 있습니다.

AWS Management Console 을 활용해서 SIEM 로깅 시스템 구축하는 단계를 살펴보겠습니다.

AWS Config 활성화
- AWS Management Console에서 AWS Config를 활성화합니다.
- 모니터링할 리소스와 평가할 규칙을 설정하여 특정 보안 그룹 설정이나 S3 버킷의 공개 액세스 여부 등을 정의합니다.
- 구성 변경 사항을 S3 버킷에 기록하도록 설정하여 로그 데이터를 저장합니다.
GuardDuty 활성화 및 연동
- AWS Console에서 GuardDuty를 활성화하고, VPC Flow 로그, CloudTrail 로그 등을 GuardDuty에서 분석할 수 있도록 설정합니다.
- GuardDuty가 이상 활동을 탐지하면 이를 Security Hub와 연동하여 보안 이벤트를 통합 관리할 수 있도록 구성합니다.
Security Hub 활성화
- AWS Console에서 Security Hub를 활성화합니다.
- GuardDuty와 AWS Config를 Security Hub에 연동하여 모든 보안 이벤트를 한 곳에서 관리합니다.
EventBridge 규칙 생성
- EventBridge에서 특정 심각도 이상의 보안 이벤트에 대한 규칙을 생성합니다.
- EventBridge 규칙에 따라 필터링된 이벤트를 Kinesis Data Firehose로 전달하여 로그 저장 및 분석 용도로 활용합니다.
Kinesis Data Firehose 설정
- Data Firehose를 생성하고 이벤트 데이터를 저장할 대상을 설정합니다 (예: S3, OpenSearch).
- 데이터 변환 기능을 활성화하여 JSON 데이터를 CSV 형식으로 변환하는 등 원하는 형식으로 데이터를 가공합니다.
보안 로그 수집 및 저장
- EventBridge 규칙에 따라 수집된 보안 로그를 Firehose로 전달하여 지정한 위치에 저장하도록 구성합니다.

이렇게 구성하면 AWS Config와 GuardDuty, Security Hub, EventBridge, Kinesis Data Firehose를 활용하여 보안 이벤트와 로그를 효율적으로 관리할 수 있습니다.

위 단계를 거쳐 정상적으로 설정이 되었다면, 아래 그림과 같이 Security Hub에서 통합된 보안로그가 지정한 OpenSearch 인덱스에 쌓이는것을 확인 할 수 있습니다.

AWS 서비스 로그 Centralized Logging 시스템 구축

CloudWatch Metric Streams 구축 과정

브이엠에스 솔루션스는 데이터 랩 프로젝트 이전에 이미 EC2, RDS 와 같은 AWS 서비스를 사용하고 있었습니다. EC2 인스턴스 RDS 와 같은 서비스들의 실시간 메트릭 데이터 통합의 필요성으로 인해 아래 그림과 같은 파이프라인을 구축하게 되었습니다. AWS 환경에서 발생하는 메트릭 데이터를 실시간으로 분석하고 애널리틱스 시스템과 손쉽게 연동 해야 하는 필요성이 커짐에 따라, 기존 CloudWatch 메트릭의 수집과 분석 한계를 보완하고자 설계하였습니다.

CloudWatch Metric Streams 는 AWS 내 메트릭 데이터의 실시간 분석, 외부 시스템 통합, 운영 효율성을 강화하기 위해 사용하였으며, 이를 통해 조직은 더 빠르고 정확한 데이터 기반 의사결정을 할 수 있습니다.

CloudWatch Metric Stream을 통해 전송할 대상 서비스로 Kinesis Data Firehose 를 지정합니다. 다음 Data Firehose 의 타겟으로 원하는 버킷(S3)을 선택하여 전송 목적지를 설정합니다. 다음 S3의 Put Object 를 인식하는 트리거를 활용한 Lambda 를 통해 OpenSearch로 데이터를 전송합니다.

아래의 코드는 Lambda 가 S3의 Put Object 를 인식하여 OpenSearch 로 CloudWatch Metric 데이터를 전송하는 샘플코드 입니다.

import json
import boto3
from opensearchpy import OpenSearch,  RequestsHttpConnection
from requests_aws4auth import AWS4Auth 
 
def lambda_handler(event, context):
    # S3와 OpenSearch 클라이언트 생성
    s3_client = boto3.client("s3")
    opensearch_region = os.getenv('OPENSEARCH_REGION')
    opensearch_host = os.getnv('OPENSEARCH_HOST') 
    opensearch_index = os.getenv('OPENSEARCH_INDEX') 

    awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token) 
    
    # OpenSearch 클라이언트 생성
    opensearch_client = OpenSearch(
        hosts=[{"host": opensearch_host, "port": 443}],
        http_auth=awsauth,
        use_ssl=True,
        verify_certs=True,
        connection_class=RequestsHttpConnection
    )
 
    # Parse the S3 put object event to get bucket name and key
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    key = key.replace("+", " ")  # URL 인코딩 처리
    
    # S3 객체 가져오기
    response = s3_client.get_object(Bucket=bucket, Key=key)
    body = response['Body'].read().decode('utf-8')
    
    # JSON 데이터를 배열로 변환
    metrics = [json.loads(metric) for metric in body.splitlines() if metric]
 
    # OpenSearch로 전송할 데이터 구성
    opensearch_data = []
    for metric in metrics:
        action = {"create": {}}
        opensearch_data.append(action)
        opensearch_data.append(metric)
 
    # OpenSearch로 데이터 전송
    response = opensearch_client.bulk(
        index=opensearch_index,
        body=opensearch_data
    )
 
    return {
        "statusCode": 200,
        "body": json.dumps("Successfully sent data to OpenSearch")
    }

위 코드를 작성한 후, Lambda 함수의 환경 변수를 설정해야 합니다.

좌측 환경 변수 탭에서 편집을 클릭하여 아래 환경 변수를 추가합니다.

키: OPENSEARCH_REGION, 값: ap-northeast-2
키: OPENSEARCH_HOST, 값: 사전 준비에서 생성한 호스트 주소(e.g. xxxxxxxxxxxxxxxxx.ap-northeast-2.aoss.amazonaws.com)
키: OPENSEARCH_INDEX, 값: 사전 준비에서 생성한 인덱스 명(e.g.sample-index)

아래와 같이 지정한 OpenSearch 의 인덱스 이름 아래에 CloudWatch Metric Streams 데이터가 쌓이는 것을 확인 할 수 있습니다. 그리고 OpenSearch dev tools 기능에서 DSL Query 를 활용하여 인덱스에 적재되어 있는 데이터를 적절한 필터 조건하에 검색이 가능했습니다.

Amazon OpenSearch 로그 수집 간 Pain point !

CloudWatch Metric stream 생성 시간 로그 epoch time 수정

OpenSearch로 CloudWatch Metric Stream 로그를 적재하는 과정에서 시간 필터를 통해 검색할 필요가 있었습니다. 그러나 로그의 시간 정보는 epoch 형식으로 제공되어 사용자가 매번 UTC+9(서울 시간)으로 변환해야 했고, 이는OpenSearch에서 검색 필터로 활용하기에도 적합하지 않았습니다. 따라서 인덱스에 적재될 때, 쉽게 확인할 수 있는 시간 정보 필드가 필요했습니다.

OpenSearch에서는 processors와 ingest 파이프라인이라는 기능을 제공합니다. Processors는 인덱싱 과정에서 필드를 편집할 수 있도록 해줍니다. 여기서는 epoch 형식으로 들어오는 타임스탬프 필드를 UTC 형식으로 변환하는 프로세서를 만들어 활용할 수 있습니다.

그 다음, ingest 파이프라인을 생성합니다. 이 파이프라인에서는 인덱스 이름을 와일드카드(*) 형식으로 지정할 수 있습니다. 예를 들어, test.*라는 이름으로 파이프라인을 설정하면, test로 시작하는 모든 인덱스가 이 파이프라인의 특징을 적용받아 인덱싱됩니다. 이 파이프라인에는 샤드 개수 설정과 함께, 미리 만들어둔 processor 기능도 적용할 수 있습니다.

이와 같은 설정을 통해 UTC 형식으로 변환된 새로운 시간 정보 필드가 생성되어, CloudWatch Metric Stream의 생성 시간 로그를 보다 쉽게 확인할 수 있게 됩니다. 이를 통해 사용자는 데이터의 시간 정보를 직관적으로 확인하고, 효율적인 로그 분석을 수행할 수 있습니다.
다음 processors와 ingest 파이프라인 설정하는 예시입니다.

PUT /_ingest/pipeline/vms_solutions_timestamp_convert
{
  "description": "vms_solutions_timestamp_convert",
  "processors": [
    {
      "date": {
        "field": "timestamp",
        "formats": [
          "dd/MM/yyyy",
          "epoch_millis"
        ],
        "target_field": "date",
        "output_format": "date_hour_minute",
        "timezone": "UTC"
      }
    }
  ]
}
PUT /_index_template/vms_template
{
  "index_patterns": [
    "vms-cloudwatch-sdk-zero-test*"
  ],
  "template": {
    "settings": {
      "index": {
        "number_of_shards": "3",
        "number_of_replicas": "1",
        "default_pipeline": "vms_solutions_timestamp_convert"
      }
    },
    "mappings": {
      "properties": {
        "date": {
          "format": "date_hour_minute",
          "type": "date"
        }
      }
    }
  },
  "priority": 200,
  "version": 1,
  "_meta": {
    "description": "vms_template"
  }
}

APP 로그 Centralized Logging 시스템 구축

브이엠에스 솔루션스는 레거시 환경에서 자체 엔진을 활용하여 결과 및 로그를 처리하는 프로세스를 운영하고 있습니다. 이를 AWS 클라우드와 효율적으로 통합하기 위해 앱 로그를 스트림으로 처리하는 작업이 필요했습니다. 이 과정에서 가장 적합한 솔루션으로 Kinesis Data Streams와 Data Firehose를 선택했습니다. Fluentd도 고려했지만, 시간 제약으로 인해 간편하게 구성할 수 있는 Kinesis를 통해 로그 수집 과정을 검증하기로 결정했습니다.

그러나 이 작업이 순조롭게 진행되지만은 않았습니다. 실제로 수집된 데이터의 시간(timestamp)을 기반으로 파티션 키를 설정해야 했는데, Kinesis Firehose의 경우 자동으로 생성되는 파티션 키는 스트림에 입력된 시간을 기준으로 저장되므로 다른 방법을 모색할 필요가 있었습니다.

Firehose에서는 이를 개선하기 위해 동적 파티셔닝 기능을 제공합니다. 이 기능을 사용하면 로그 내에 저장된 timestamp 데이터를 기반으로 데이터를 분할할 수 있습니다.
설정 과정에서는 다음과 같이 jq 표현식을 활용하여 설정을 진행합니다.

파라미터	jq 표현식
`project_id`	.project_id
`plan_ver`	.plan_ver
`year`	.event_timestamp\| strftime(“%Y”)
`month`	.event_timestamp\| strftime(“%m”)
`day`	.event_timestamp\| strftime(“%d”)
`hour`	.event_timestamp\| strftime(“%H”)

최종적으로 결정된 통합 Centralized Logging 시스템 아키텍처

지금까지 세 가지 방식의 로그 데이터 수집 방법을 살펴보았습니다. 처음 구상한 아키텍처를 기반으로 구현을 진행하면서 데이터 레이크(S3) 저장 구조에 대한 고민이 더욱 깊어졌습니다. 체계적인 관리를 위해 우선 S3에 모든 로그를 저장하기로 의사결정하였습니다. 이후, 상황에 따라 Athena를 활용한 데이터 가공 처리 및 OpenSearch로의 로딩 작업을 수행하는 구조로 최종 결정되었습니다.

이러한 결정은 효율적인 데이터 관리를 가능하게 하고, 다양한 분석 요구에 맞춰 유연하게 대응할 수 있는 기반을 마련하는 데 기여할 것입니다.

이를 통해 본래 목표했던 효율적인 데이터 저장 및 처리 구조인 데이터 레이크를 성공적으로 설계할 수 있었습니다. 다양한 시스템과 서비스, 그리고 보안 로그를 통합하여 저장하고 시각화함으로써, 원하는 목적을 달성할 수 있었습니다. 이러한 통합 관리 체계는 데이터의 가시성을 높이고, 효과적인 분석을 가능하게 하는 기반이 되었습니다.

결론

이번 프로젝트를 통해 브이엠에스 솔루션스는 제조업계에서 클라우드 기반 APS 솔루션을 도입하고 데이터 아키텍처와 보안을 효율적으로 관리하는데 성공적인 사례를 제시했습니다. 특히 AWS와 메가존클라우드와의 협력으로 Partner-Led Data Lab을 활용하여 클라우드의 확장성과 보안성을 극대화한 MOZART Cloud를 구축할 수 있었습니다.

MOZART Cloud는 제조업체들이 필요로 하는 고성능 데이터 처리와 보안 체계를 클라우드 환경에서 제공하며, 초기 인프라 부담을 줄이고 확장 가능한 SaaS 솔루션을 통해 생산 계획을 더욱 효율적으로 관리할 수 있도록 지원합니다.

제조업체가 클라우드로 전환하는 과정에서 마주하는 데이터 관리, 보안, 확장성 등 문제를 효과적으로 해결한 브이엠에스 솔루션스는 앞으로도 AWS와의 협업을 통해 클라우드 기반 스마트팩토리 구현을 위한 기술적 지원을 지속할 계획입니다.

양민철 / VMS Solutions

양민철 수석은 Mozart Cloud 인프라 설계와 아키텍처 개발을 담당하는 클라우드 인프라엔지니어로, 비즈니스 로직에 맞춘 최적화된 클라우드 환경을 설계합니다. 기술적 통찰력을 바탕으로 인프라 안정성과 확장성을 동시에 추구하며, 팀의 목표 달성을 위해 전략적으로 지원하고 있습니다.

배시현 / VMS Solutions

배시현 선임은 Mozart Cloud 인프라 엔지니어로, 인프라와 데이터 파이프라인의 설계 및구축을 담당하고 있습니다. SaaS 전환을 성공적으로 이끌며, 비용 절감과 시스템 안정성강화를 실현해 왔습니다. 지속적인 개선을 통해 고객에게 효율적이고 안정적인 클라우드 서비스를 제공하는 데 주력하고 있습니다.

김태룡 / VMS Solutions

김태룡 수석은 다양한 프로젝트 경험을 바탕으로 Mozart Cloud 고객의 니즈를 충족시키는 백엔드 엔지니어입니다. AWS 서비스를 활용한 최적의 아키텍처 설계를 통해 안정성과 확장성을 확보하며, 논리적 문제 해결과 세밀한 설계에 주력하고 있습니다. 항상 정확하고 효율적인 서비스 개발을 목표로 하고 있습니다.

이원석 / VMS Solutions

이원석 책임은 Mozart Cloud에서 데이터 기반의 의사결정을 지원하는 백엔드 서비스 개발을 담당하며, 데이터의 정확성과 운영 효율성을 높이는 데 주력합니다. 데이터 정합성유지와 실시간 데이터 처리 최적화에 강점을 지니고 있으며, 시스템 전반에서 데이터를효과적으로 활용할 수 있도록 설계합니다.

최경진 / Megazone Cloud

최경진 SA는 Megazone Cloud의 데이터 솔루션 전문가로서, 다양한 산업의 클라이언트가 데이터 기반 의사 결정을 내릴 수 있도록 돕고 있습니다. AWS 인프라 기반의 모던 데이터 아키텍처 설계에 강점을 두고, 데이터 레이크 구축 및 개인화 추천 시스템을 포함한 클라우드 네이티브 솔루션을 제공합니다. 실무 경험을 바탕으로 클라이언트의 문제 해결과 성과 향상을 전략적으로 지원하고 있습니다.

손덕기 / Megazone Cloud

손덕기 SA는 Megazone Cloud의 AWS 솔루션 아키텍트(SA)와 데이터 엔지니어로서, 클라우드 기반 데이터 아키텍처 설계 및 최적화 업무를담당하고 있습니다. 데이터 파이프라인 관련 구축 및 운영 업무를 맡고 있으며 다양한 고객의 데이터 요구 사항을 파악해AWS의 데이터 및 분석 서비스를 활용해 최적의 솔루션을 설계하고 구현합니다. 특히 데이터 파이프라인과 데이터 웨어하우스를 구축해 기업들이 데이터를 효과적으로 수집, 저장, 처리할 수 있도록 지원합니다.

이호재

이호재 SA는 IoT와 생성형 AI의 결합에 관심이 많으며, 고객들의 비즈니스 문제를 AWS의 기술을 통해 해결하고 구현하는데 도움을 드리고 있습니다.

AWS 기술 블로그