Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

소개

클라우드 시스템은 위임이다. 컴퓨팅, 메모리, 디스크와 같은 하드웨어 외에도 로드밸런서, 메시지큐, 로깅, 모니터링, 배포, 확장, 데이터 수집 등을 IaaS, PaaS, SaaS 형태로 비즈니스로직으로 부터 분리하여 위임하는 시스템이다. 따라서 개발조직은 다른 것들에 신경쓰지 않고 서비스 개발에만 집중 할 수 있다.

 IaaS, PaaS, SaaS

클라우드에 대한 다양한 관점이 있겠는데, 이중에서 위임이라는 관정을 중요하게 보는 이유는 조직이 핵심가치인 비즈니스에만 집중할 수 있게 해주는 것, 이를 통해서 혁신을 이루기 쉬원 환경으로 만들어주는게 클라우드의 가장 큰 메리트라고 보기 때문이다. 나는 장표상에 계산되는 비용보다 더 중요한 관점이라고 생각한다.

 클라우드로의 위임

이 문서는 로깅의 위임을 다룬다.

문서의 한계

High-Level 아키텍처를 소개한다. 세부적인 설정, 구축은 다루지 않는다. 아키텍처의 주요 컴포넌트들의 설정과 연동은 AWS에 문서로 잘 정리되어 있으니 참고하면 된다.

시나리오

joinc company는 AWS를 이용해서 EC2 기반에서 웹 애플리케이션을 서비스하고 있다. 회사의 CTO는 서비스가 안정화되고 성장함에 따라서 기술부채를 갚아나가길 원하고 있다. 현재 서비스는 애플리케이션에서 발생하는 각 종 로그들이 표준 없이 분할되어서 관리하고 있음을 확인했다. 로그가 제대로 쌓이지 않으면, 고객의 활동을 분석 할 수 없고 향후 계획하고 있는 데이터 기반의 서비스가 불가능 할 것으로 예상됐다.

CTO는 아래의 이유로 로깅 시스템의 정비를 최우선 갚아야 할 기술부채로 설정했다.
  • 앞으로 6개월 후, 대대적인 서비스 개편이 있을 것이다. 여기에서 데이터 기반의 개인화 서비스, 데이터 분석 기반의 CRM 활동을 수행하려 한다.
  • 로깅은 당장 애플리케이션의 품질을 관리하기 위해서도 중앙에서 관리되어야 한다.
CTO는 소프트웨어 개발팀과 테이터팀, 인프라 팀에 아래와 같은 요구사항을 전달했다. 인프라팀의 솔류션 아키텍트는 개발팀과 협력하여 최적의 로깅 시스템을 구성해야 한다.
  • 개발자들은 애플리케이션에서 발생한 로그를 추적하고 검색 할 수 있어야 한다.
  • 애플리케이션 로그는 S3에 적재되어야 한다. S3를 Data Lake로 해서 데이터 분석팀이 분석작업을 수행 할 것이다.
  • 데이터 분석팀은 서비스 기획자와 애플리케이션 개발자와 논의하여 남겨야 할 데이터를 정의 한다.
EC2 기반으로 제약조건을 둔 이유는 EKS(kubernetes)는 EC2와는 다르게 구축되기 때문이다. EKS 기반의 중앙로깅 시스템을 따로 다룰 것이다.

핵심 컴포넌트 소개

중앙 로그 관리 시스템을 위한 핵심 컴포넌트을 소개한다. 로깅 시스템은 다양하게 구성될 수 있지만, 아래의 구성요소에서 크게 벗어나지는 않을 것이다. 나머지는 레고 조립과 비슷하게 컴포넌트들을 짜 맞추면 된다.

CloudWatch Logs

CloudWatch Logs는 AWS에서 제공하는 로그 저장 서비스다. CloudWatch Logs를 사용하면 모든 시스템, 애플리케이션에 대한 로그를 수집하고 검색할 수 있다. CloudWatch Logs의 장점은 아래와 같다.
  • 단일 중앙 로그 저장소 역할을 한다. 힘들여서 중앙 로그 저장소를 구성할 필요가 없다. 중앙로그 저장소의 구축과 운영은 힘들고 번거로운 작업이다.
  • CloudWatch Logs Insights로 대화형 쿼리를 이용해서 로그를 검색하고 분석 할 수 있다.
  • Kinesis와 같은 실시간 데이터 분석 처리 시스템으로 보내서 데이터 파이프라인을 구축 할 수 있다.
  • AWS에서 제공하는 CloudWatch Log Agent를 설치하고 간단히 설정하는 것으로 CloudWatch로 애플리케이션 로그를 전송 할 수 있다.
AWS에서 데이터 파이프라인을 구축할 때, CloudWatch에서 시작하는 것을 검토하는 경우가 많다. 관리를 할 필요가 없으며, SLA를 보장하고 그 자체가 통합된 저장소 역할을 하기 때문이다. 이 외에도 AWS 인프라에서 발행하는 로그, CloudTrail 까지 광범위하게 통합 할 수 있다.

Amazon Kinesis Data Streams & Kinesis Data Firehose

Amazon Kinesis는 고도로 확장 가능하고 내구력 있는 실시간 데이터 스트리밍 서비스다. Kafka와 유사한 서비스라고 생각하면 된다.

 Amazon Kinesis

파티션(Partitions) 대신 샤드(Shard)로 분산한다는 걸 제외하면, Kafka와 개념적인 차이는 없다.

Amazon Kinesis Data Firehose는 데이터를 다른 서비스로 로드하는 서비스다. 스트리밍 데이터를 캡쳐하고 변환해서 S3, Amazon Redshift, Amazon ElasticSearch, Datadog, New Refic, MongoDB, Splunk와 같은 외부 서비스 제공자로도 전송 할 수 있다.

AWS에서 데이터 스트림 시스템을 구축한다면 Kinesis와 Kafka(Amazon MSK) 중 하나를 선택하게 될 거다. 두 개의 차이점은 아래와 같다.
Kines is Kafka
G2.com의 사용자 리뷰 점수 4.1/5 4.4/5
데이터의 저장 위치 샤드 파티션
SDK 지원 Java, .NET, Go, Android Java
데이터 보유 기간 7일 사용자 설정
필요한 기술 수준 낮음 높음
저장 DynamoDB Zookeeper
가격 사용한 만큼 무료이지만 하드웨어 구매/구축 비용
개발자 지원 개발자 센터, 튜토리얼 튜토리얼, 모임, 동영상
성능 초당 30,000 초당 최대 20,000
Apache에 따르면 Fortune 100대 기업 중 80% 이상이 Kafka를 사용하고 신뢰하고 있다. 초기 시장을 압도적으로 선점한 관성도 어느 정도 작용 하고 있을 거라 본다.

MSK는 관리형 Kafka 서비스로 설정 프로세스를 간소화하고 DevOps 관리 부담을 덜 수 있다는 점에서, 실제 구축시 Kinesis와 Kafka를 고려해 볼 수 있다. 의사결정 트리는 아래와 같다.

 Kafka & Kinesis 의사결정 트리

기타 의사결정에 영향을 미치는 요소는 아래와 같다.
  • AWS Kinesis는 여전히 MSK에 비해서 프로비저닝이 더 간단하다.
  • AWS Kinesis는 AWS의 전용 기능이기 때문에 공급업체 종속성이 높아진다.
  • AWS Kinesis는 Video Streams, Analytics, Firehose와 같은 내장기능을 가진다. 직접 구성해야 하는 MSK에 비해서 애플리케이션 개발 및 유지 관리를 단순화 한다.
  • MSK 는 오픈소스인 Apache Kafka를 사용하기 때문에, 클라우드 - 온프레미스 통합, 다른 클라우드와의 통합이 수월하다.

AWS Glue

AWS는 관리형 ETL(Extract, Transform, Load) 서비스다. 단어 그 자체로 데이터를 추출하고, 추출된 데이터를 사용할 목적에 맞게 변환해서 적재하는 일을 한다. 이글을 쓰는 2021년 현재 소프트웨어 영역에서 가장 핫한 키워드는 ML 과 AI일 것이다. 그런데 왠지 빅 데이터, 데이터 처리 영역이 ML/AI와 따로 노는 경향이 있다. 입력이 쓰레기면 출력도 쓰레기다. 입력이 쓰레기인데 좋은 결과가 나올 수가 없다. 엔지니어들은 이러한 문제를 인식하기 시작했으며, MLOps라는 일련의 관행을 만들었다. 이 단어는 머신러닝과 지속적인 개발관행의 합성이다.

보고서에 따르면 AI 이니셔티브의 대댜수(최대 88%)가 테스트 단계를 넘어서는데 어려움을 겪고 있다. 반면 실제 AI와 머신러닝을 적용한 조직은 3 ~ 5%의 이윤증가를 보이고 있다. MLOps는 ML/AI 프로젝트가 테스트 단계를 무사히 넘어서게 하는데 커다란 역할을 한다.

데이터 처리라는 것이 결국 추출, 변환, 적재의 과정이라는 것을 생각해보자. AWS Glue MLOps를 수행하는데 큰 도움을 줄 것이다.

 AWS Glue

Glue는 Amazon Redshift, Amazon S3, Amazon RDS, DynamoDB 등의 데이터 소스로 부터 데이터를 추출한다. 데이터를 추출하기 위해서는 스키마를 알아야 하는데 Glue Catalog를 이용해서 스키마를 설정한다. 읽어온 데이터는 변환(ex. CSV에서 parquet로)하고, 데이터를 저장할 저장소(S3, Redshift, ElasticSearch..)로 적재한다.

데이터 분석가와 데이터 사이언티스트는 AWS Glue DataBrew를 사용하여 코드를 작성하지 않고도 데이터를 시각적으로 정리하고 정규화 할 수 있다. 애플리케이션 개발자는 AWS Glue Elastic Views 를 이용해서 다른 데이터 저장소간의 데이터를 조합하거나 복제하는 등의 작업을 할 수 있다. 이렇게 데이터 엔지니어링과 데이터 분석이 유기적으로 통합된다.

Amazon ElasticSearch

검색 바닥에서는 유명한 ElasticSearch의 클라우드 관리형 서비스다. 당연히 Kibana도 제공하기 때문에, ELK(ElasticSearch,LogStash,Kibana)와 동일한 환경을 구성할 수 있다. 애플리케이션 로그를 ElsasticSearch에 색인하여, 로그 모니터링, 통계, 분석, 추적에 사용 할 수 있다.

로깅 시스템 아키텍처

아래는 위에 소개한 컴포넌트들을 이용한 로깅 시스템 아키텍처다.

 로깅 시스템 아키텍처

EC2 인스턴스에 CloudWatch Log를 설치한다. 로그 스트림으로 호스트 이름을 설정하고 로그 그룹으로 애플리케이션 이름을 선택한다. 이렇게 하면 애플리케이션 이름단위로 로그가 쌓이고, 스트림으로 각 호스트를 식별 할 수 있다.

솔류션 아키텍트는 EC2 인스턴스의 특정한 위치에 로그파일을 쌓아 두면, 로그에이전트가 자동으로 수집하도록 설계했다. 로그 에이전트는 설치가 필요한데 EC2 인스턴스 유저 데이터(user data)에 스크립트를 실행해서 설치하도록 했다.

  • 로그는 JSON 포멧을 따른다.
  • /opt/joinc/logs 디렉토리 밑에 파일을 둔다.
  • Access Log와 Error Log를 분리한다. *_access.log, *_error.log 로 파일 포맷을 지킨다. 이렇게 하면 로그 그룹으로 쉽게 분리 할 수 있다.
EC2 인스턴스에서 애플리케이션을 가동하면, /opt/joinc/logs 디렉토리에 로그파일이 쌓이고 CloudWatch 로그 에이전트가 로그파일을 읽어서 CloudWatch로 전송한다.

이제 Kinesis Firehose 를 설정한다.
  1. CloudWatch로 부터의 로그를 받기 위한 stream을 생성한다.
  2. CloudWatch Log의 구독 필터를 생성하여 1에서 만든 stream으로 로그가 흐르도록 한다.
  3. 이제 kinesis data firehose는 cloudWatch 로그를 수신하게 됐다. 이 로그를 S3로 저장할 것이다.
  4. Kinesis data firehose는 Delivery stream을 이용해서 stream을 특정 목적지로 전송 할 수 있다. S3 버킷을 타겟으로 스트림을 생성한다.
  5. Kinesis data firehose는 타겟으로 Amazon S3, Amazon Redshift, Amazon Elasticsearch, Splunk를 선택 할 수 있다. Elasticsearch를 선택하는 것으로 전송 할 수 있다.
이렇게 해서 Log를 s3와 ElasticSearch로 전송 할 수 있게 됐다. ElasticSearch는 실시간 로그 모니터링/분석용으로 사용한다. S3는 데이터 레이크가 되며, AWS Glue(ETL)를 이용해서 Redshift(데이터 웨어하우스)를 구성할 수 있다. 다른 한편 Athena를 이용해서 S3로 부터 직접 데이터를 쿼리하여 분석 할 수 있다. 이들 데이터는 BI툴인 QuickSight를 이용해서 시각화 한다.

이벤트 관리 시스템

애플리케이션 로그 시스템을 구성하면서, 솔류션 아키텍트는 이 시스템에 "이벤트 관리" 기능을 추가하기로 했다. AWS CloudWatch는 애플리케이션 로그뿐만 아니라 AWS 클라우드 시스템에서 발생하는 로그, 보안/감사 로그들 까지 통합한다. 사고관리 기능을 넣는다면, 클라우드와 애플리케이션에서 발생하는 이벤트들을 처리/관리 할 수 있을 것이다.

솔류션 아키텍트는 Atlassian의 Opsgenie를 이용해서 이벤트 관리 시스템을 구축한 경험이 있다. 최근에는 Amazon EventBridge서비스가 생기면서 이벤트 통합이 좀 더 쉬워졌다.

Amazon EventBridge는 이벤트 기반 애플리케이션을 구축하도록 도와주는 서버리스 이벤트 버스다. EventBridge는 Zendesk, Shopify, Opsgenie 같은 이벤트 소스의 실시간 데이터 스트림을 AWS Lambda 및 기타 SaaS 애플리케이션으로 전송 할 수 있다. Opsgenie에서 발생한 이벤트를 EventBridge로 보내서 여러가지 처리를 할 수 있다는 의미다. 아래 그림을 보자.

 Opsgenie 기반의 이벤트 관리 시스템

애플리케이션과 클라우드에서 시스템/보안 이벤트를 OpsGenie에서 중앙 관리한다. Opsgenie는 AWS SNS, SQS 등과 통합되므로 쉽게 통합할 수 있다. OpsGenie는 일종의 IFTTT처럼 작동하며, 이벤트를 규칙에 따라서 분석해서 Slack, SNS, Jira, SMS 등을 실행 할 수 있다. Opsgenie는 이벤트를 관리하는게 주요 기능이지만 EventBridge를 연동함으로써, 람다를 실행해서 이벤트를 처리 할 수 있다.

예를들어 VPC 네트워크에 대한 변경이 CloudTrail에 기록되면 SNS를 통해서 OpsGenie로 전송된다. Opsgenie는 보안팀과 시스템 운영팀으로 Email, Slack 이벤트를 전송하는 한편, Lambda를 실행해서 왜 변경이 일어났는지를 검토해서 필요한 작업을 수행 할 수 있다.

참고