11/27/2020

Snowflake, BigQuery, Redshift 비교

빅데이터와 분석은 오늘날 업계의 비즈니스를 발전시키는 근본적인 힘으로 작용되었습니다. 수년 동안 매초 생성되는 데이터의 양은 기하급수적으로 증가했으며, 이로 인해 데이터를 처리하는데 효율적인 클라우드 데이터웨어 하우스 기술이 등장했습니다.

데이터웨어 하우스는 데이터를 효율적으로 활용하여 심층적인 통찰력을 도출하는데 매우 중요합니다. 어떤 데이터웨어 하우스가 내 비즈니스에 적합한가?라는 고민이 생길 것 입니다.

데이타웨어 하우스 아키텍처는 빠르게 변화하고 있습니다. 기업은 기존 On-Premise대신 낮은 초기 비용, 향상된 확장성 및 성능을 갖춘 클라우드 기반 데이터웨어 하우스로 점차 이동하고 있습니다.

클라우드기반 데이터웨어 하우스 선택시 고려할 점

클라우드상에서의 데이터웨어 하우스를 선택해야 할 경우 다음을 고려해야 합니다.

데이터웨어 하우스 지리적 위치

아래의 국가에서 해당 솔루션을 사용할 수 있습니다.


데이터 양

데이터 볼륨

  • Postgres, MySQL, MSSQL 및 기타 여러 RDBMS는 최대 1TB 크기의 데이터를 지원하고 이 크기를 초과하면 성능이 저하될 가능성이 존재합니다.
  • Redshift, BigQuery, Snowflake는 최적의 방식으로 최대 수 PB의 데이터 세트 크기를 지원합니다.

데이터 형식

데이터 소스

기존 서비스가 클라우드를 사용하고 있지 않으면 VPN응 이용해 데이터를 전송해야 합니다. 따라서 데이터 파이프 라인 구축에 대한 비용도 고려해야 합니다. 각 서비스별 예제는 다음과 같습니다.

1. Redshift


2. BigQuery


3. Snowflake


파이프라인은 환경에 따라 달라집니다.

보안

구매 결정에 영향을 미치는 주요 요소는 보안입니다. 데이터가 제3장에게 유출되지 않아야 합니다. 세가지 솔루션 모두 데이터를 보호하기 위한 보안 조치가 내장되어 있습니다.


가격 모델

가성비를 가진 솔루션을 결정하는 것은 측정하기가 어려운 부분입니다. 사용 사례를 기반으로 설명하도록 하겠습니다. 아래는 각 솔루션별 가격 모델입니다.

Redshift는 리소스가 미리 결정되기 때문에 예측 가능성이 높습니다. Snowflake는 소요 시간에 따라 가격이 달라지기 때문에 쉽게 측정할 수 있지만, BigQuery는 필요한 쿼리 리소스가 다양하기에 예측하기가 어렵습니다.

가격 책정 모델을 기반으로 각 서비스에 가장 적합한 사례를 살펴보겠습니다.

Redshift

일정한 계산이 필요한 시나리오에 적합합니다.

e.g.

  • NASDAQ 일일 레포트: 데이터 보고를 위한 워크로드
  • 자동 광고 입찰: 광고의 입찰은 실시간으로 예측 모델을 통해 조정
  • 라이브 대시 보드: 새로 고침을 통한 지속적인 쿼리로 라이브 데이터 스트리밍

BigQuery

워크로드가 급증하는 시나리오에 가장 적합합니다. (유휴 시간이 길고 가끔 많은양의 쿼리를 실행하는 경우)

e.g.

  • 권장 모델: 전자상거래 애플리케이션을 위해 하루에 한번 실행
  • 임시보고: 분기별 보고서에 복잡한 쿼리가 있는 경우
  • 영업 인텔리전스: 영업 또는 마케팅 팀이 원하는 방식으로 데이터를 분석하여 임시로 수행할 경우
  • 기계 학습: 데이터, 소비자 행동에서 새로운 패턴을 발견하는 경우

Snowflake

안정적이고 지속적인 사용 패턴에 가장 적합합니다. 하지만 지속적으로 Up/Down 스케일링이 필요합니다.

e.g.

  • 비즈니스 인텔리전스 회사: 데이터의 패턴을 찾기 위해 동시에 데이터를 쿼리하는 사용자가 많은 경우 (100명 ~ 1000명)
  • 데이터를 서비스로 제공: 분석 사용자 인터페이스 또는 데이터 API의 형태로 분석 목적의 데이터를 수천개의 클라이언트에 제공하는 경우

클라우드 기반 데이터웨어 하우스 소개 및 비교

현재 시점에 고려해야 할 데이터웨어 하우스는 Amazon Redshift, Google BigQuery, Snowflake입니다.

본 글에서는 언급한 3가지 솔루션에 대해서 비교하려고 합니다.

Amazon Redshift란?

Redshift는 비즈니스 인텔리전스(BI) 도구와 원할하게 통합 될 수 있는 Managed형 클라우드 데이터웨어 하우스 서비스라고 할 수 있습니다. 웨어하우스에 ETL(Extract, Transform, Load)만 있으면 현명한 비즈니스 의사결정을 내리기가 수월해집니다.

AWS를 사용하면 작은 사이즈의 데이터로 시작하고 요구에 따라 원할하게 확장/축소 할 수 있습니다. 이를 통해 기업은 데이터를 활용하여 자사 또는 고객에 대한 비즈니스 통찰력을 얻을 수 있습니다.

클라우드 데이터웨어 하우스를 사용하려면 Redshift 클러스터로 알려진 노드 그룹을 사용해야 합니다. 클러스터를 프로비저닝 한 후에 데이터 분석 쿼리를 실행하기 위해 데이터 세트를 업로드 해야 합니다.

데이터 세트의 크기에 관계없이 동일한 SQL 기반 도구 및 BI 솔루션을 사용하여 빠른 쿼리 성능을 이용할 수 있습니다.

Google BigQuery란?

Google BigQuery는 Google의 자체 데이터웨어 하우징 솔루션입니다. 2010년에 처음 출시되었고 C-Store 및 MonetDB에 이어 일반적으로 사용할 수 있는 최초의 데이터웨어 하우스 솔루션 중 하나였습니다.

BigQuery는 Google Cloud Platform으로 알려진 Google의 전체 클라우드 컴퓨팅 생태계에서 중요한 부분입니다.

Dremel은 BigQuery에서 쿼리를 실행하는데 사용되는 Google에서 개발한 강력한 쿼리 엔진입니다. Google에 의하면 Dremel은 “매우 큰 데이터 세트에서 SQL과 같은 유사한 쿼리를 실행하고 단 몇 초만에 정확한 결과를 얻을 수 있는 쿼리서비스”입니다.

BugQuery 및 Dremel은 리소스를 할당하고 Dremel 작업에 데이터를 제공하는데 도움이 되는 Borg 및 Colossus와 같은 다른 Google 클라우드 기술을 활용할 수 있습니다.

SnowFlake란?

Redshift와 Snowflake는 관계형 데이터베이스 관리 시스템입니다. SaaS(Software-as-a-Service) 모델로 제공되는 구조화된 데이터와 반 구조화된 데이터 모두를 지원하는 데이터웨어 하우스입니다.

이는 기존 데이터베이스 또는 빅 데이터 소프트웨어 플랫폼(e.g. Hadoop)위에 구축되지 않는 것을 의미합니다. 대신 Snowflake는 클라우드 용으로 설계된 고유한 아키텍처가 존재하는 SQL 데이터베이스 엔진을 사용합니다.

Snowflake는 빠르고 사용자 친화적이며 기존 데이터웨어 하우스보다 더 많은 유연성을 제공합니다.

Redshift ETL과 Snowflake ETL을 모두 사용하는 경우 두 솔루션간에 많은 유사점이 있음을 알고 있을 것입니다.

Snowflake는 Snowflake Elastic Data Warehouse의 형태로 클라우드 기반 데이터 스토리지 및 분석을 제공합니다. 사용자는 클라우드 기반 하드웨어 및 소프트웨어를 사용하여 데이터를 분석하고 저장 할 수 있습니다.

물리 데이터는 Amazon S3에 저장됩니다. Snowflake ETL을 사용하는 경우 Hadoop과 같은 기술을 사용하지 않고도 퍼블릭 클라우드 시스템을 활용할 수 있습니다.

이러한 클라우드웨어 하우스 시스템은 모두 강력하며 데이터 관리와 관련하여 몇 가지 고유한 기능을 제공합니다. 그러나 각 솔루션별 차이점은 존재합니다.

회사에 적합한 솔루션을 선택하려면 통합, 데이터베이스 기능, 유지 관리, 보안등의 비용도 비교해야 합니다.

기능 비교

Computing Layer

  • BigQuery: 분산 컴퓨팅에서 실행됩니다. Google이 제공하는 각 데이터센터의 Borg에서 실행됩니다.
  • Redshift: AWS 가상 머신에서 실행되는 ParAccel의 독점 포크 (부분적으로 Postgres에서 포크됨), Postgres라고 하나 많이 다름
  • SnowFlake: 클라우드(AWS, GCP, Azure)의 가상머신에서 실행되는 Intelligent Predicate Pushdown + Smart Caching이 포함된 독점 컴퓨팅 엔진이고 C-Store, MonetDB에서 영감을 얻은 하이브리드 컬럼 시스템

Storage Layer

Redshift, BigQuery, Snowflake 모두 Hot/Warm/Cold 스토리지를 구현합니다.

  • Big Query: 독점적이며 ColumnIO를 스토리지 형식으로 사용하고 Colossus 파일 시스템에 저장됩니다. 분산 컴퓨팅과 스토리지를 완전히 분리합니다.
  • Redshift: 독점적이지만 일반적으로 SSD(dc1, dc2) / HDD (ds1, ds2) 또는 독점 컬럼 형식을 사용하는 S3기반 (RA3)을 포함하여 혼합됩니다 RA3는 컴퓨팅과 스토리지를 분리하는 반면에 다른 모든 노드 유형은 컴퓨팅과 스토리지를 함께 지역화합니다.
  • Snowflake: 원하는 클라우드의 컴퓨팅/객체 스토리지에서 실행되는 메모리/SSD/객체 저장소의 독점적인 Row 형식으로 제공하며 메타 데이터 캐싱을 사용하여 PAX(하이브리드 컬럼 형식)로 저장됩니다.

Compression

  • BigQuery: ColumnIO 열 형식으로 처리되는 독점 압축입니다. BigQuery는 지속적으로 내부에서 데이터를 압축하지만 압축되지 않은 바이트를 스캔하는 것처럼 쿼리 요금이 청구됩니다.
  • Redshift: Redshift는 LZO, ZStandard와 같은 개방형 알고리즘을 구현하여 투명한 압축을 달성합니다. 최근에 자체 독점 압축 알고리즘(AZ64)을 출시했지만 데이터 유형 선택이 제한적입니다. 열을 압축할 방법을 선택할 수 있습니다. Analyze Compression은 쿼리 패턴과 열에 저장하려는 데이터에 따라 압축 방식을 선택하는 것이 가장 좋습니다.
  • SnowFlake: 자체 압축 레이어를 제공합니다. BigQuery와 달리 스캔한 바이트에 대해서는 요금이 청구되지 않지만 쿼리 플래너가 압축 및 테이블 통계를 활용하여 더 적은 데이터를 스캔하기에 컴퓨팅 비용을 줄일 수 있습니다.

Deployments

  • BigQuery, Redshift, Snowflake 모두 클라우드위에서 동작됩니다.
  • BigQuery: 클라우드 전용이고 Google Cloud Platform내에서만 사용이 가능합니다.
  • Redshift: 클라우드 전용이고 Amazon Web Services내에서만 사용이 가능합니다.
  • Snowflake: 클라우드 전용이고 선호하는 클라우드 유형(AWS, GCP, Azure)에 배포가 가능합니다.

데이터 접근

데이터에 쉽게 접근할 수 없다면 데이터웨어 하우스는 많이 사용될 수 없습니다. 일반적으로 데이터베이스는 ODBC/JDBC에 의존해왔지만 시간이 지남에 따라 새로운 형태의 데이터 검색 및 핸들링이 필요합니다.

  • BigQuery ** Simba 드라이버를 통한 ODBC/JDBC 접근 ** BigQuery 사용자 인터페이스 ** BigQuery 연결 API ** BigQuery Jobs API ** BigQuery Storage API ** BigQuery CLI
  • Redshift ** AWS 제공 드라이버를 통한 ODBC/JDBC 접근 ** Redshift 사용자 인터페이스 ** 데이터 접근 API ** AWS CLI ** Postgres CLI
  • Snowflake ** 드라이버를 통한 ODBC/JDBC 접근 ** Spark 플러그인 (spark-snowflake)을 통한 접근 ** Kafka를 통한 접근 ** 특정 언어용 Python/Node.js/Go/.Net 드라이버 ** SnowSQL ** Snowsight

암호화

세가지 솔루션은 저장 및 전송 중 일부 암호화 방법을 제공합니다.

  • BigQuery: Google에서 제공하는 암호화 키 관리 서비스(KMS) 또는 CMEK를 사용하여 암호화
  • Redshift: AWS 키관리 서비스를 사용하여 암호화
  • Snowflake: 종단간 암호화, VPS(Virtual Private Snowflake)는 전용 서버의 메모리에 암호화 키를 저장하는 기능 제공

타사 도구 지원 (시각화, 데이터 모델링)

대부분의 인기 있는 도구는 모든 데이터베이스를 지원합니다.

AWS와 GCP는 모두 고유한 시각화/데이터 모델링 소프트웨어(각각 QuickSight, Looker/Data Studio)를 제공합니다.

모든 기능 앞에 “Snow”를 배치하는 전통에 따라 Snowflake는 몇 가지 기본 데이터 시각화를 수행할 수 있는 Snowsight를 제공합니다.

Query Language

쿼리 언어 없이는 훌륭한 데이터베이스를 제공할 수 없습니다.

  • BigQuery: BigQuery는 Legacy(BigQuery라고 함) SQL과 표준 SQL이라는 두 가지 주요 언어를 제공합니다.
  • Redshift: ANSI와도 호환되며 Postgres에 대한 경험이 있다면 익숙한 언어를 제공합니다.
  • Snowflake: ANSI와 호환되는 Snowflake 쿼리 언어는 작업하기가 매우 수월합니다. 언어는 처음부터 명확하게 설계되었으며 중첩된 데이터로 작업하는 경우 대부분 쉽게 작업이 가능합니다.

BigQuery와 Redshift는 모두 지리 공간 데이터 쿼리를 지원합니다. Snowflake는 현재 지리 공간 데이터에 대한 미리보기 기능을 제공합니다. 모든 구현은 네이티브 유형을 사용하거나 텍스트 표현(e.g. GeoJSON)간에 변환할 수 있습니다.

통합 쿼리

통합 쿼리는 기존 분석(OLAP) 스타일 데이터베이스와 일반적인 행기반 트랜잭션 스타일의 데이터베이스(Postgres, MySQL)사이의 격차를 해소하기 위해 설계된 기능입니다.

  • BigQuery: Postgres 및 MySQL 데이터베이스 지원을 포함하는 CloudSQL을 통해 통합 쿼리를 지원합니다. 다른 소스로는 Google 스프레트시트 및 Google Cloud Storage가 있습니다.
  • Redshift: Amazon RDS(Postgres, MySQL 및 Aurora)에 대한 통합 쿼리 지원을 합니다.
  • Snowflake: 현재 통합 쿼리를 지원하지 않습니다.

사용자 정의 함수(UDF)

UDF는 데이터베이스에서 수행 할 수 있는 작업에 추가적인 유연성을 도입 할 수 있는 방법입니다. 데이터베이스에 로직을 배포할 수 있다는 점은 과거로 회귀할 수 있지만, 특정 상황에서는 필요할 수 있습니다.

  • BigQuery: SQL 및 Java Script로 사용자 정의 함수 작성을 지원합니다. Java Script 함수의 경우 복잡한 UDF를 작성시 Google Cloud Storage의 외부 라이브러리를 포함할 수 있습니다.
  • Redshift: SQL 또는 Pythob으로 UDF를 작성할 수 있습니다. BigQuery와 유사하게 외부 라이브러리 및 함수를 쉽게 패키징하고 S3에서 호스팅 할 수 있습니다. Python에 대한 지원은 없습니다. 반면 Lambda UDF를 도입했습니다.
  • Snowflake: SQL 및 Java Script 함수를 지원합니다. 하지만 외부 라이브러리를 사용할 수 없습니다.

캐싱

  • BigQuery: 쿼리를 캐시하고 인메모리 캐시를 제공하는 중간 캐시를 제공합니다. 캐시된 쿼리는 비용이 발생하지 않습니다. 캐싱 엔진은 데이터 스튜디오뿐만 아니라 BigQuery에서도 사용 될 수 있기에 쿼리 소스에 관계없이 스마트한 중간 캐싱이 가능합니다.
  • Redshift: 쿼리 및 결과를 캐싱합니다. (노드 유형 및 메모리/디스크의 사용 가능한 스토리지에 따라 다름)
  • Snowflake: 콜드 데이터 스토리지와 분리된 중간 스토리지에 Hot/Warm 쿼리 캐시를 제공합니다.

스트리밍

데이터를 데이터베이스에 빠르고 안정적으로 저장하는 것은 매우 어려운 문제입니다.

  • BigQuery: 기본 스트리밍, 하나의 테이블처럼 보이도록 주어진 테이블에서 분할 된 데이터로 스트리밍 버퍼를 조정하는 몇 가지 방법이 존재합니다. 그러나 이것은 대부분 추상화됩니다.
  • Redshift: Redshit로 마이크로 배치를 할 수 있지만, 기본 스트리밍 기능은 없습니다. 마이크로 배치를 시작하는 가장 쉬운 방법은 Kinesis Firehose를 통해 Redshift를 직접 연결하는 것입니다.
  • Snowflake: Snowpipe를 통해 Amazon S3, Google Cloud Storage, Azure Blob Storage에서 마이크로 배치를 할 수 있지만, 기본 스트리밍 기능은 없습니다.

데이터 소스

일부 제품에서는 데이터베이스 자체에 데이터를 저장하지 않고도 데이터를 쿼리 할 수 있습니다. 이는 유용 할 수 있지만 데이터 현지화 및 최적화 된 데이터 구조를 활용할 수 없을만큼 성능이 현저히 떨어지는 경향이 있습니다.

  • BigQuery: 통합 쿼리를 통해 Cloud Storage, Google Drive, Bigtable, Cloud SQL등을 비롯한 일부 외부 데이터 소스에 대한 연결을 설정 할 수 있습니다.
  • Redshift: S3와 Redshift Cluster 사이의 중간 컴퓨팅 계층 역할을 하는 Redshift Spectrum을 통해 S3에 있는 데이터에 연결할 수 있습니다. 통합 쿼리 설정이 있는 경우에는 RDS(Postgres, MySQL 또는 Aurora)를 쿼리 할 수 있습니다.
  • Snowflake: BigQuery 및 Redshift와 마찬가지로 최상의 성능을 위해서 Snowflake내에 있는 것이 이상적입니다. 그러나 Snowflake는 Snowflake로 데이터를 가져 오지 않고도 주요 클라우드 (Amazon S3, Google Cloud Storage, Azure Blog Storage)의 객체 스토리지에 연결할 수 있는 외부 테이블 기능을 제공합니다.

끝으로,

클라우드 기반의 데이터웨어 하우스를 선택하려는 분들께 도움이 되길 희망합니다.

References:

  • www.xplenty.com/blog/redshift-vs-snowflake/
  • www.xplenty.com/blog/snowflake-vs-bigquery/#bigquery
  • fivetran.com/blog/warehouse-benchmark




9/14/2020

Microservice와 Monolith 선택 가이드

우선 이 글을 읽기전에 이전에 작성했던 글을 먼저 읽어 보길 바랍니다.

  • 마이크로 서비스에 대해서 생각해보기

프로젝트를 시작할 때 기술 스택에 대해서 고민을 합니다. 아키텍처 관점에서는 크게 두 가지가 있습니다. 일반적으로 “마이크로서비스” 또는 “모놀리식” 둘 중 하나를 선택을 합니다.

위 두가지 중에 어떤 아키텍처를 선택해야 할까요? 본 글에서는 모놀리식 아키텍처와 마이크로서비스 아키텍처를 선택하는 방법에 대해서 언급하려고 합니다.

모놀리식 아키텍처와 마이크로 서비스 아키텍처 선택하기

두 가지 접근 방식은 고유한 장/단점을 지니고 있습니다. 백엔드 아키텍처를 선택할 때 선택의 자유가 있다는 얘기입니다. 그러나 우리는 선택을 해야 하고, 방향을 결정 할 때, 도움이 되는 몇 가지 질문을 생각해보세요.

익숙한 분야의 비즈니스인지?

고객의 니즈와 업무 도메인을 알고 있는 상황에서 일할때에는 명확한 설계가 용이합니다. 하지만 새로운 비즈니스에서는 달라집니다. 비즈니스가 익숙치 않기 때문에 고려해야 할 요소의 양이 많기 때문입니다.

따라서 마이크로 서비스 아키텍처를 사용하는 것은 비즈니스를 완전히 이해하는 경우에 적합합니다. 그렇지 않으면 모놀리식 방식으로 진행하는 것이 좋습니다.

Team은 준비되어 있는지?

팀원들이 마이크로 서비스를 구현하는 방법을 모두 숙지하고 있는지 확인을 해야 합니다. 아니면 모놀리식의 단순성내에서 작업하는 것을 더 선호하는지에 대해서도 확인해야 합니다. 과거 프로젝트를 수행시 고객사의 팀원들은 마이크로 서비스보다 모놀리식 방식으로 개발 하는 것을 더 선호했습니다. Lerning Curve 기간이 끝난후에는 괜찮아졌지만, 이에 대해 시간을 할애하거나 팀원들이 새로운 기술을 받을 수 있는 준비가 되었는지를 고려해야 합니다. 이 질문에 대해 답을 할 수 있으면 마이크로 서비스를 선택하세요.

인프라 환경은 준비되어 있는지?

마이크로 서비스는 개발에서 배포에 이르기까지 클라우드 기반 인프라를 사용하는 것이 유리합니다. 당신이 속한 곳에서 클라우드 환경을 이용할 수 있는지 확인해보세요.

비즈니스의 위험을 평가했나요?

대부분의 기업은 마이크로 서비스가 자신들의 비즈니스에 적합하다고 생각합니다. 하지만, 그들이 만든 애플리케이션이 비즈니스적으로 기대한 만큼 성장하거나 확장되지 않을 가능성이 존재합니다. 비즈니스가 계속 성장하고 확장될 수 있다라는 확신이 들면 마이크로 서비스를 선택하시길 바랍니다.

모놀리식은 언제 선택하나요?

  • 팀이 최초 만들어졌을때
  • 비즈니스 PoC를 진행 할 때
  • 마이크로 서비스에 대한 경험이 없는 경우

마이크로 서비스는 언제 선택하나요?

  • 독립적으로 빠른 배포가 필요할 때
  • 비즈니스를 확장하거나 팀을 확장해야 할 때
  • 매우 효율적인 플랫폼을 구축해야 할 때
  • Waterfall과 같은 방식이 아니라 Agile방식으로 서비스를 진화시켜야 할 때
  • 프로젝트 기간이 촉박하지 않을 때

결론

마이크로 서비스와 모놀리식을 현 시장에서 비교하자면 전자가 Hot하다는 것은 부정할 수 없습니다. 대부분의 의사결정권자들은 자신의 애플리케이션이 마이크로 서비스 아키텍처를 기반으로 한다고 말하고 싶어합니다. 그러나 마이크로 서비스에만 집중하고 비즈니스 도메인과 역량을 고려하지 않는다는 것은 위험하고 위의 질문들을 기반으로 마이크로 서비스가 줄 수 있는 실제 가치를 측정해야 합니다.

가장 현명한 접근 방식은 모놀리식으로 접근하여 새로운 애플리케이션을 개발하고 운영을 하면서 “성능 모니터링”, “비즈니스 확장성”등과 같은 백데이터를 근거로 마이크로 서비스의 정당성을 확보한 경우에 이동하는 것입니다. (물론, 모놀리식으로 개발을 하더라도 Package단위로는 서비스가 분리되는 것이 좋겠지요. 미래를 위해…)

기존 비즈니스의 경우, 비즈니스가 익숙한 상황이고 티밍이 되어있고 비즈니스가 확장되고 있다면, 마이크로 서비스를 고려할 수 있습니다. 그러나 스타트업이나 새로 시작하는 회사에서는 마이크로서비스를 채택하면 성공에 부정적인 영향을 미칠 가능성이 높습니다.

위에 언급한 내용을 보시고 잘 판단하셔서 아키텍처를 선정 하시길 바랍니다.

2/09/2020

Service Mesh 아키텍처 스타일 비교

이전 글에서 서비스 메시에 대해서 간략히 언급했었습니다. 서비스 메시가 무엇인지 아직 모르시는 분은 링크 를 통해 읽어보세요.

본 글에서는 서비스 메시의 아키텍처 스타일에 대해서 얘기하고자 합니다.

우리가 이미 알고 있는 방법일 수 도 있습니다.

  • Library 방식: 라이브러리로 필요 기능들이 제공되며, 애플리케이션의 코드 레벨로 사용되어야 합니다. (어찌 보면, 서비스 메시라고 할 순 없지만 서비스 메시를 구현하기 위한 대안? 으로 이해하시면 될 것 같습니다.)
  • Node Agent 방식: Node Agent나 Daemon에 의해서 기능들이 제공됩니다.
  • Sidecar 방식: 컨테이너내에 sidecar로 proxy가 적용되어 기능들이 제공됩니다.

이제 각각의 아키텍처 스타일에 대해 상세히 살펴 볼까요?

타입별 Service Mesh Architectures

Library Architecture


라이브러리를 이용하게 되면 위의 그림에서 표현했듯이 각 마이크로 서비스 애플리케이션에 서비스 메시 기능을 구현하는 라이브러리 코드가 포함됩니다. (e.g. Hystrix, Ribbon)

이 기능은 서비스내에서 독점적으로 하나의 프로그래밍 언어만 사용하는 경우에 적합합니다. 라이브러리로 접근하게 되면 인프라 환경에 크게 영향을 받지 않습니다.

하지만, 대부분은 Polyglot 형태로 마이크로 서비스를 실행하고 있습니다. 이 경우 사용하는 프로그래밍 언어마다 라이브러리가 존재해야 합니다. 따라서 라이브러리 방식을 채택할 경우에는 제약이 존재합니다.

Node Agent Architecture

라이브러리 아키텍처 이후에 나온 대안입니다. 모든 노드에서 실행되는 별도의 Agent가 존재하며, 이 기종간 쉽게 혼합될 수 있는 이점을 제공합니다.

모든 노드에 하나의 노드 에이전트가 필요하기에 이 아키텍처를 채택하기 위해서는 인프라와 협업이 필요합니다. 즉, 운영체제에 TCP 패킷을 보내거나 받을 수 있도록 역할을 위임합니다.

공유를 한다는 것은 리소스 차원에서 효율적으로 보일 수 있지만, 여러개의 마이크로 서비스가 하나의 노드를 공유하는 모델이기 때문에, 선점에 대한 문제가 있을 수 있습니다. 예를 들어서 노드에 속해 있는 모든 마이크로 서비스가 노드 에이전트에 요청을 하면 노드 에이전트는 먼저 요청한 마이크로 서비스의 업무를 처리해야 합니다. 효율적으로 리소스를 공유할 수 있다면, 나쁘지 않은 방법이라고 생각합니다.


사이드카는 가장 마지막에 나온 아키텍처입니다. Istio가 Envoy와 함께 사용되는 모델입니다. 서비스 메시의 경우 사이드카는 애플리케이션 안팎의 모든 네트워크 트래픽을 처리합니다.

이 접근법은 지금까지 설명한 라이브러리와 노드 에이전트 접근법 사이에 존재합니다. 예를 들어서, 모든 노드에서 새 에이전트를 실행하지 않고도 사이드카 서비스 메시를 배포할 수 있습니다. (사이드카에 대한 내용은 이전 포스팅에서 설명했습니다.) 노드 에이전트와는 달리 각 Pod에 배포가 되기에 더 많은 리소스가 필요합니다만, 개인적인 관점에서는 얻는 이득이 더 크다고 생각됩니다.

어떤 방식을 채택하는 것이 효율적일까요? 여러 상황들을 고려하여 적합한 방식을 선택해보세요.

다음 포스팅에서는 각 아키텍처 타입별 오픈소스/상용 솔루션에 대해서 이야기 하도록 하겠습니다.

2/05/2020

Service Mesh Architecture (서비스 메시 아키텍처)

마이크로 서비스는 소프트웨어 산업에 많은 영향을 주었습니다. Monolithic에서 마이크로 서비스 아키텍처로 전환하면 독립적으로 더 자주 애플리케이션을 배포 할 수 있습니다.

그러나 마이크로 서비스 아키텍처를 채택하는 것은 분산 시스템을 설계 할 때 발생하는 문제들을 가지고 있고 이 문제를 해결해야 한다는 것을 의미합니다.

분산 컴퓨팅의 오류를 살펴 볼까요?

  • 네트워크는 신뢰할 수 있다.
  • 지연 시간은 0이다.
  • 네트워크 대역폭은 무한하다.
  • 네트워크는 안전하다.
  • Topology는 변하지 않는다.
  • 관리자 한명이 모든 것을 처리한다.
  • 데이터 전달 비용은 0이다.
  • 동종 네트워크이다.

마이크로 서비스 아키텍처 사용시 네트워크에 대하여 종속성이 생깁니다. 이는 안정성에 문제를 유발합니다. 서비스 수가 증가하게 되면 각 서비스간 상호 작용을 처리하고, 상태를 모니터링하고, 로깅 및 측정을 수행하고, 여러 장애 지점을 체크하는 등의 작업을 수행해야 합니다. 서비스간 통신을 신뢰할 수 있도록 각 서비스에는 위에서 언급한 것들을 처리하는 공통 기능이 필요합니다. 그러나 다양한 언어로 작성된 수많은 마이크로 서비스를 사용해야 한다면 많은 노력을 해야 합니다.

서비스 메시란 무엇인가?

서비스 메시는 MSA에서 서비스 간 통신을 처리하는 인프라 레이어(통신에 대한 기본 베이스)로 정의할 수 있습니다. 서비스 메시는 MSA와 관련된 복잡성을 줄이고 아래와 같은 기능을 제공합니다.

  • Load Balancing
  • Service Discovery
  • Health check
  • Authentication
  • Traffic management and routing
  • Circuit breaking and failover policy
  • Security
  • Metrics and telemetry
  • Fault injection

서비스 메시가 필요한 이유?

MSA에서 서비스간 통신 처리는 쉽지 않습니다. 위에서 언급한 Service discovery, Load balancing과 같은 기능을 제공하기 위해서는 Fat library에 의존하게 됩니다. Netflix는 Hystrix, Eureka등 자체 라이브러리를 만들었습니다.

그러나 이러한 구성 요소는 애플리케이션의 코드내에서 구성해야 합니다.

사용하는 Language에 따라 구현 방식도 다릅니다. Fat Library가 version up 될때마다 애플리케이션에 반영 후 테스트하고 배포해야 합니다. 그리고 애플케이션의 비즈니스 코드와 MSA 통신을 위한 코드가 혼합되는 문제가 발생합니다. 이는 긴밀한 결합이고 전반적으로 애플리케이션의 복잡성을 증가시킵니다. 코드에 혼합되기 때문에 개발자는 매커니즘과 구성 방법등을 이해해야합니다. 그렇지 않으면 문제가 발생 했을때에 해결할 수 없기 때문입니다.

이러한 이유는 서비스 메시가 나오게 된 계기가 됩니다. 위에서 언급한 복잡성을 애플리케이션에서 분리하여 Service Proxy에 주입하여 처리 할 수 있습니다. Service Proxy는 Traffic management, Circuit break, Service discovery, Authentication, Monitoring, Security등과 같은 기능을 제공합니다. 따라서 애플리케이션 관점에서는 비즈니스 기능만 구현하면 됩니다. 비즈니스 기능을 개발하는 개발자들이 매커니즘과 구성 방법을 이해할 필요도 없고요.

서비스 메시의 도입으로 명확하게 책임을 분리할 수 있습니다. 개발자들의 삶은 더 편안해지게 됩니다. 문제가 발생할 경우 개발자는 애플리케이션의 문제인지 네트워크의 문제인지에 따라서 근본적인 원인을 쉽게 식별할 수 있게 됩니다.

서비스 메시가 구현되는 방식은?

서비스 메시를 적용하기 위해서는 마이크로 서비스와 함께 Proxy를 배포해야 합니다. 이를 Side car pattern이라고 합니다.

사이드카는 애플리케이션에서 복잡성을 제거하고 Service discovery, Traffic management, Load balancing, Circuit break등과 같은 기능을 처리 합니다.

Lyft의 Envoy는 Cloud Native Application을 위해 설계된 가장 인기 있는 Open source proxy입니다. Envoy는 모든 마이크로 서비스와 함께 실행되며 플랫폼에 상관없이 필요한 기능을 제공합니다. 서비스에 대한 모든 트래픽은 Envoy proxy를 통해 흐르게 됩니다.

Istio란 무엇인가?

Istio는 마이크로 서비스를 연결, 관리, 보호하기 위한 플랫폼 입니다. Kubernetes 커뮤니티에서 인기가 많고 널리 채택되고 있습니다.

Istio는 Intelligent Routing, Load balancing, Service discovery, policy enforcement(정책 시행), in-depth telemetry(심층적인 원격 측정), circuit breaking과 재시도 기능, 로깅, 모니터링등과 같은 MSA에 필요한 기능을 제공합니다.

Istio는 현재 시점에서 서비스 메시를 가장 잘 구현한 것 중 하나입니다. Istio외에 linkerd, conduit이 존재합니다. 위에서 언급된 기능에 대한 지식이 없이도 마이크로 서비스를 배포 할 수 있습니다.

현재 시장에서는 Monolithic 서비스를 마이크로 서비스로 분리하는 작업을 진행중입니다. 이는 더 많은 서비스를 관리해야 한다는 입장이기도 하고 이는 부담으로 다가올 수 있습니다. 서비스 메시는 이러한 상황에서 애플리케이션에 코드 주입없이 복잡성을 제거해줍니다.

MSA로의 전환을 생각한다면 서비스 메시도 고려해보세요.

참고:

  • https://dzone.com/articles/the-rise-of-service-mesh-architecture


11/18/2019

마이크로 서비스(MSA) 관련 Tool

마이크로 서비스 Tool이라고 표현했지만, 다양한 기술의 모음이라고 생각하면 된다. 이번 글에서는 서로 다른 용도로 사용되는 마이크로 서비스 Tool에 대해서 살펴 볼 것이다.

운영체제

어플리케이션을 만들때에 가장 중요한 요소 중 하나는 적합한 기반을 설정하는 것이고, 결국 어플리케이션은 운영체제를 기반으로 수행되게 된다. Linux는 이런 운영체제중에 하나이며 가장 일반적으로 사용된다. Linux container를 사용하여 실행 환경 및 보안, 네트워킹, 스토리지와 같은 부분을 조절할 수 있다.

프로그래밍 언어

마이크로 서비스의 주요 장점은 다른 언어와 기술을 사용할 수 있다는 점이다. 따라서 개발자는 자유롭게 기술 스택을 선택하고 어플리케이션을 개발 할 수 있다. 그러나 현재 시점에서 가장 많이 사용되는 언어는 Java기반의 Spring Boot이다.

Spring Boot

Spring Boot는 단 몇줄의 코드로 REST기반의 마이크로 서비스 개발을 단순화 한다.

  • 어플리케이션 개발을 빨리 시작하기 위해 일련의 자동 구성 기능을 제공
  • WAR 파일의 사용을 피하기 위해 Embedded Container(e.g. Tomcat)을 제공
  • Maven 구성을 단순화하여 개발자의 시간을 줄여줌
  • 개발 및 생산에서 어플리케이션을 모니터링하고 관리하기 위한 API를 제공

API 관리 및 테스트 도구

Postman

Postman은 API테스트를 쉽게 할 수 있도록 도와주는 UI 기반의 툴이다.

  • Postman의 도움으로 인해 RESTful API 리소스 탐색이 매우 쉬워진다. 또한 결과 테스트도 도움이 많이 된다.
  • Postman은 어플리케이션의 개발 사이클과 쉽게 통합된다. (CI에서 활용 가능)
  • 여러 버전의 API를 유지/관리하는 기능을 제공한다.
  • 작성된 전체 Collection을 다른 개발자와 공유할 수 있다. (한명만 작업해두면 재사용이 가능하다는 의미)

API Fortress

API Fortress는 부하 테스트, 상태 모니터링 및 기능 테스트를 자동화하는 Tool이다.

  • 이 도구는 API 관리 플랫폼을 점검하는 용도이다.
  • GUI를 제공하기에 API에 대한 테스트 작성/실행을 쉽게 제공한다.
  • 손쉽게 사용할 수 있도록 기능이 제공되기에 End to End 테스트를 단순화 한다.

메시징

마이크로 서비스는 다른 서비스간 통신이 많기 때문에 Messaging Queue를 사용할 수 있다. 메시징에 사용되는 도구는 아래와 같다.

Apache kafka

Apache Kafka는 LinkedIn에서 처음 개발한 분산 Pub/Sub 메시징 시스템이고 현재 Apache 프로젝트의 일부이다. Kafka는 확장 가능하고 민첩한 장점을 지니고 있다. 데이터 처리 또는 API 호출에 사용할 수 있는 분산 스트림 처리 플랫폼이다.

Apache Kafka의 기능은 아래와 같다.

  • Kafka는 안정적인 성능을 유지하기 위해서 Pub/Sub에 대한 처리량이 높다.
  • 다운 타임 제로 및 데이터 손실 제로를 보장한다.

RabbitMQ

Kafka와 마찬가지로 이 툴을 사용하여 마이크로 서비스를 서로 연결하여 분산 시스템의 문제를 해결 할 수 있다. 각 개별 서비스간에 이벤트를 교환 할 수 있다.

  • 안정성, 지속성, Publisher 확인 및 고가용성과 같은 기능을 제공한다.
  • 여러 메시징 프로토콜을 지원한다.

Orchestration 도구

Kubernetes

Kubernetes는 오픈 소스 컨테이너 관리 도구이다. 컨테이너 관리에는 컨테이너 배포, 컨테이너 확장 및 스케일 제거, 컨테이너 로드 밸런싱등이 포함된다.

관점에 따라서 Kubernetes가 평범하고 중요하지 않다고 느낄 수 있다. 그러나 컨테이너 관리를 위해서는 Kubernetes가 필요하고 컨테이너를 만들기 위해서는 Docker가 필요하다. Kubernetes의 기능은 아래와 같다.

  • Kubernetes를 사용하면 이미지를 다시 작성하지 않고도 어플리케이션 구성을 배포하고 업데이트 할 수 있다.
  • Kubernetes는 서비스 관리 외에도 배치 및 CI 워크로드를 관리하여 실패한 컨테이너를 교체 할 수 도 있다.
  • Kubernetes는 CLI와 대시 보드를 제공한다.
  • Kubernetes를 사용하면 원하는 스토리지 시스템을 마운트 할 수 있다. 로컬 스토리지를 선택하거나 GCP 또는 AWS와 같은 퍼블릭 클라우드 공급자를 선택 혹은 NFS, ISCSI등과 같은 공유 네트워크 스토리지 시스템을 사용할 수 있다.

Istio

Istio는 Kubernetes에서 서비스 배포를 지원한다. 또한 마이크로 서비스 통신에 대한 관리 효율성, 보안 및 안정성을 위한 기능을 제공한다. 이는 Service Mesh 기술에 의해 수행되므로 어플리케이션과 마이크로 서비스 간의 관계 및 상호 작용을 향상 시킬 수 있다.

  • 서비스의 자동 추적, 모니터링 및 로깅을 수행한다.
  • 관리 권한 부여, 인증 및 서비스간 통신 암호화를 통해 서비스를 보호한다.
  • Istio는 서비스간 트래픽 및 API 호출 흐름을 제어한다.
  • 정책을 적용하고 시행한다.

모니터링 도구

어플리케이션이 빌드되면 어플리케이션의 작동을 모니터링하는 것은 매우 중요하다. 어플리케이션을 모니터링하기 위해 아래에 언급된 도구를 사용할 수 있다.

Prometheus

Prometheus는 이상 패턴을 감지하여 추적하고 모니터링 정보를 시각화 할 수 있다.

  • 유연한 Query 언어를 제공한다.
  • 서비스 디스커버리 또는 정적 구성을 통해 대상을 발견
  • 대시 보드 및 그래프를 제공한다.

Logstash

Logstash는 로그를 확인할 수 있는 오픈 소스 도구이다. 이 툴을 사용하면 데이터를 숨기거나 중앙에 집중 시키거나 변환할 수 있다.

  • Logstash는 동시에 여러 가지 공통 소스에서 이벤트를 가져 오는 다양한 입력을 지원한다.
  • 이 툴은 복잡성에 관계없이 데이터를 변환하고 준비하는 것을 목표로 한다.
  • Logstash를 사용하면 전송 데이터를 선택할 수 있다.
  • 200개가 넘는 플러그인이 존재하고 이를 이용하여 원하는대로 파이프 라인을 만들고 구성할 수 있다.