IT로 세상을 이롭게

<개요>

- 이번 글에서는 AWS Redshift를 사용한 경험에 대해서 주로 작성하였습니다.

- AWS Redshift 는 AWS 에서 제공하는 데이터 웨어하우스 솔루션입니다.
https://icthuman.tistory.com/m/entry/AWS-Aurora-vs-RedShift

- 비슷한 제품으로는 GCP BigQuery, Azure SQL Datawarehouse 등이 있습니다.

<내용>

간단히 두 제품을 비교해보면

- 사실 성능이라는 것은 비지니스 유스케이스와 밀접한 연관이 있습니다.

- 과거 Hadoop Eco에서도 Hive, Impala, Presto와 같은 다양한 소프트웨어가 있었는데, 수년간 시스템을 구축해본 결과 같은 생태계 내에서 동등한 발전속도를 가지고 있다는 전제라면 자신의 케이스와 매칭이 잘 되는 솔루션을 선택하는 것이 매우 중요합니다.

- 반대로 이야기하면 생태계의 규모가 크고, 발전속도가 빠른 (자주 릴리즈 되는) 소프트웨어는 다 이유가 있다로 설명할 수 있습니다. (다양한 케이스를 흡수하면서, 기존 케이스의 확장성을 보완하는 경우들입니다.)

- 두 제품의 성능 비교는 생략하고 Redshift내에서 선택하는 Node 타입에 대해서만 비교를 해보았습니다.
(실무에서 그렇게 까지 사용해 볼만한 비용이나 시간여유가 없었습니다. 다음에 GCP를 사용하게 될 기회가 생기면 비교해보겠습니다.)

<고밀도 컴퓨팅 DC2 vs 고밀도 스토리지 DS2>

- 저장 공간이 많이 필요하다면 DS2, 연산속도가 필요하다면 DC2를 선택하면 됩니다. (클러스터 생성 후 변경가능)

- 개발목적의 경우 large, 스테이징 / 운영의 목적으로 8xlarge를 선택하였습니다.

- RedShift의 경우 노드의 수는 x2 형태로 지정가능합니다.

- large 와 8xlarge의 경우 개당 노드로 단순하게 비용을 비교하면 약 20배 정도 차이가 납니다. (large(40) vs 8xlarge(2))

<속도 및 저장공간>

- dc2.large(4) vs dc2.8xlarge(2) 의 성능을 비교해 보았습니다.  소요된 Cost는 약 10배정도 입니다.

- dc2.large(4)의 경우 640GB 저장공간이 제공되며, dc2.8xlarge(2) 의 경우 5.1TB가 제공됩니다.

- 쿼리별 수행 속도 (캐시, 네트워크/CPU 상황등 고려해야하는 변수들이 있기 때문에 단순참고로만 보시길 바랍니다.)

- 대략 300개의 쿼리를 수행하는데 dc2.large(4) 에서 19분정도 소요되던 작업이 dc2.8xlarge(2)내에서 약1분30초 정도에 완료되는것을 확인할 수 있었습니다.

- 정리해보면 제공되는 저장공간은 약 8배, 처리속도는 약 9.5배정도에 근접합니다.

 (들어간 비용대비 정직한 결과를 보여줍니다.)

<정리>

AWS Redshift

- 클러스터 생성 후 노드타입을 변경하는 것도 가능합니다. 단, 적재되어 있는 데이터량에 따라서 다운타임이 존재

- Scale out 을 통해서 얻어지는 성능향상 효과도 있으나, 대규모 분산/병렬처리가 필요한 쿼리에만 해당하며

  일반적인 쿼리에서는 Scale up을 통한 vCPU, 메모리, I/O 의 성능향상 효과가 눈에 보입니다.

일반적인 선택가이드

- 대량의 비정형/반정형 데이터의 단순 가공의경우 S3로 Pipeline을 구축하고 Athena 로 검색하는 것이 가장 효율적

- Join이 없으며 수천만건 이상의 대량의 데이터를 쉽게 Scale out할 수 있는 구조를 원한다면 NoSQL

- Join이 필요하며 대규모 분석쿼리 및 표준SQL, 다양한 인터페이스가 필요한 경우 OLAP

- 트랜잭션처리가 가장 중요한 경우면 OLTP

<각 Public Cloud에 대한 개인적인 의견 + 동향>

- AWS의 경우 IaaS로 출발했던 구조로 인하여 상대적으로 Azure, GCP 에 비해서 Full manage, serverlees 솔루션이 부족

- GCP의 경우 BigTable, BigQuery가 뛰어난 성능을 가지고 있기 때문에, 최근 데이터처리에 특화된 어플리케이션이 필요한 경우 선택하는 수요가 늘고 있음

<참고사이트>

https://blog.panoply.io/a-full-comparison-of-redshift-and-bigquery

https://rudderstack.com/blog/aws-redshift-vs-google-bigquery-open-source-analytics/

https://www.xplenty.com/blog/redshift-vs-bigquery-comprehensive-guide/

https://db-engines.com/en/system/Amazon+Redshift%3BGoogle+BigQuery

https://aws.amazon.com/ko/redshift/pricing/

<개요>

- 기존에 사용하던 Aurora DB의 성능 문제로 AWS Redshift 로 제품군 변경

- EBS 를 사용하던 부분을 ECS로 변경하기 위해서 Docker 작업

<내용>

- ANSI SQL을 주로 사용하였다면 쿼리상의 큰 변화는 없다.

- MySQL driver를 pom.xml 에서 제거하고 Redshift driver를 추가한다.

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>

 <dependency>
            <groupId>com.amazon.redshift</groupId>
            <artifactId>redshift-jdbc42-no-awssdk</artifactId>
            <version>1.2.10.1009</version>
        </dependency>

- application.yml 파일에서도 DB url을 변경한다.

spring:
  profiles: dev
  datasource:
    driver-class-name: com.amazon.redshift.jdbc42.Driver
    url: jdbc:redshift://localhost:5439/dev
    username: 
    password: 

- docker file을 작성한다.[Dockerfile]

FROM openjdk:8-jdk-alpine
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

- maven package를 수행하고 다음과 같이 Docker 이미지를 build한다.

docker build -t {service-name} .

- docker 를 실행한다.

docker run -p 8200:8200 {service-name}

<오류상황>

- Local에서는 잘 동작하던 Application이 Docker 이미지에서는 잘 되지 않는 현상이 발생한다.

- 오류로그를 보면 다음과 같다.

Caused by: org.hibernate.HibernateException: Access to DialectResolutionInfo cannot be null when 'hibernate.dialect' not set
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:100) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:54) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:137) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:35) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:94) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263) ~[hibernate-core-5.3.7.Final.jar!/:5.3.7.Final]
	... 41 common frames omitted

hibernate dialect 가 설정되지 않았다는 내용이다.  

일반적으로는 명시하지 않아도 추천되어서 hibernate가 자동으로 지정하는데 docker내에서는 오류가 발생하는 것을 확인할 수 있다.

(자세한 원인파악이 필요하다. 우선은 해당 dialect를 명시하여 오류를 수정한다.)

- AWS Redshift는 PostgreSQL 8.0.2. 을 기반으로 수행되기 때문에 다음과 같이 Spring JPA를 세팅한다.

  jpa:
    database-platform: org.hibernate.dialect.PostgreSQL9Dialect
    generate-ddl: false
    hibernate:
      ddl-auto: none

<해결>

- docker 상에서도 정상적으로 서비스가 동작하는 것을 확인할 수 있다.

- 다음에는 AWS ECS 에서 해당 서비스를 기동한다.

<참고>

PostgreSQL을 기반으로 만들어졌으나 지원하지 않는 기능들이 있으니 확인해야 한다.

<AWS Redshift에서 제공하지 않는 PostgreSQL features>

• Table partitioning (range and list partitioning)
• Tablespaces
• Constraints
  • Unique
  • Foreign key
  • Primary key
  • Check constraints
  • Exclusion constraints

<AWS Redshift에서 제공하지 않는 PostgreSQL data types>

• Arrays
• BIT, BIT VARYING
• BYTEA
• Composite Types
• Date/Time Types
  • INTERVAL
  • TIME
• Enumerated Types
• Geometric Types
• HSTORE
• JSON
• Network Address Types
• Numeric Types
  • SERIAL, BIGSERIAL, SMALLSERIAL
  • MONEY
• Object Identifier Types
• Pseudo-Types
• Range Types
• Special Character Types
  • "char" – A single-byte internal type (where the data type named char is enclosed in quotation marks).
  • name – An internal type for object names.
  For more information about these types, see Special Character Types in the PostgreSQL documentation.
• Text Search Types
• TXID_SNAPSHOT
• UUID
• XML

https://docs.aws.amazon.com/redshift/latest/dg/c_redshift-and-postgres-sql.html