<개요>

- 기존에 사용하던 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 

<개요>

1. Aurora

Amazon에서 Full Managed Service로 제공하고 있는 RDB이다. MySQL, PostgreSQL과 호환되며 속도도 기존 MySQL, PostgreSQL보다 빠르도록 개선되었다. 

일반적인 CRUD용도로는 크게 부족함이 없으나 현재 다루고 있는 데이터의 건수가 너무나도 많아서 분석쿼리 수행시 엄청난 시간이 소요된다. (대략 2000만건 x 수십개)

 

2. 트랜잭션 처리 OLTP

Aurora는 관계형 데이터베이스이며 그중에서 OLTP에 적합한 Row기반의 데이터베이스이다. 간단히 설명하자면 transaction처리를 최우선으로 하는 것이 목적이다. 

<트랜잭션이란?>

작업수행의 논리적 단위를 말한다.

Database의 관점에서 시스템 트랜잭션, 사용자관점에서 비지니스 트랜잭션의 개념으로 나눌 수 있으며 일반적으로 비지니스 트랜잭션은 1개이상의 시스템 트랜잭션으로 이루어진다.

예를 들어서 계좌이체는 출금-> 입금의 단계를 거쳐야 하는데 이를 하나의 트랜잭션으로 묶어야 할 필요가 있으며 Spring과 같은 Framework에서는 Transaction Manager를 통해서 이를 Support한다.

트랜잭션의 성질 ACID를 살펴보면 그 특징을 더 자세히 알수 있다.

 

<Row-Oriented vs Column-Oriented>

 이러한 요건을 만족시키기 위해서 일반적으로 Row-Oriented storage방식으로 접근한다. 각 Row를 기반으로 데이터를 바라보며 데이터의 정합성, 이를 위한 데이터 정규화 등을 수행한다.

Column-Oriented방식은 이와는 다르게 하나의 속성의 값들에 빠르게 접근하는 것을 목표로한다. 주로 OLAP환경에서 많이 선호한다. 대규모 분석쿼리를 수행하는 것이 주목적이다.

Row-oriented : 하나의 Row가 정합성을 가지도록 효과적으로 정규화하는데 목표가 있다.

 

Column-oriented : aggregation에 유리하고 효율적인 압축이 가능하다.

 

이부분에 대해서만도 책 한권의 분량이 나오기 때문에 간단히만 언급하고 지나갑니다.

 

3. OLAP, Big Data, 분산병렬처리

OLAP의 영역에서 BigData 기술들이 사용되고 있다.

 

 대부분의 Big Data, 그 중에서도 DataLake를 처리하는 오픈소스들은 트랜잭션을 보장하는 것이 목적이 아니라 일단 빠르게 쌓아놓고 나중에 병렬처리를 통해서 대규모 분석쿼리를 수행하여 Insight를 도출하는 것이 일반적인 목표이다.

 

 

그 특성이 OLAP과 유사하며 실제로 아키텍처도 비슷하다.

빅데이터의 출현배경과 활용방법등을 보면 과거 DatawareHouse, BI등과 99%동일하다는 것을 알수 있다.

 최근에는 트랜잭션 처리에 대한 요구사항이 꾸준히 증가하여 transaction을 지원하는 기능들이 추가되고 있으나 최초 설계된 목적이 다르기 때문에 한계점이 있다. (Apache Hive)
<참고:https://icthuman.tistory.com/m/entry/Apache-hive-transaction>

 

Apache hive - transaction

<개요> Apache Hive는 HDFS에 저장되어 있는 파일데이터를 SQL 기반으로 처리할 수 있도록 하는 오픈소스이다. (모든 SQL을 지원하는 것은 아니며, 파일시스템 특성상 UPDATE, DELETE는 권장하지 않는다. ) 그러나..

icthuman.tistory.com

현재 BigData영역에서는 Apache Spark Eco System이 상당부분을 커버하고 있다.

(Spark Core, Streaming, SQL, MLlib) - 추후에 Aurora에서 Redshift로 마이그를 위해서 AWS에서 제공하는 Glue를 살펴볼텐데 이 역시 SparkContext를 기반으로 동작한다. 

 

4. AWS Redshift

AWS에서 제공하는 OLAP 데이터베이스이다. 기존에 AWS에서 제공하는 Aurora, S3, RDS등의 데이터 소스와 쉽게 호환될 수 있는 것이 가장 큰 장점이다.

OLTP 대비 분석쿼리의 성능을 끌어올리기 위해서 다음과 같은 구조를 적용하였다. (일반적인 OLAP DB특성)

MPP : 대용량처리를 위해서 쿼리를 분산병렬처리 한다. 데이터를 저장할때 Distribution Key를 사용하여 적절히 분배하고 이를 기반으로 각 노드간의 데이터 이동을 최소화하여 병렬처리 성능을 극대화 한다.

Columnar data storage : Disk I/O 비용을 감소시키고 분석쿼리의 성능을 향상시킨다. 

Data compression : 데이터를 압축하여 메모리에 적재후 쿼리 수행시에만 해제한다. 이를 통해서 분석쿼리 수행시 메모리를 조금더 효과적으로 사용할 수 있다. 

Result caching : 수행되는 쿼리들에 대해서 캐싱한다. 

 

5. 쿼리 수행속도 향상

기존에 약 8~10분정도 소요되던 쿼리가 30초 정도 걸리는 것을 확인하였다.

 

<참고사이트>

https://francois-encrenaz.net/what-is-a-dbms-a-rdbms-olap-and-oltp/

https://victorydntmd.tistory.com/129

https://mariadb.com/resources/blog/why-is-columnstore-important/
https://databricks.com/

https://diffzi.com/oltp-vs-olap/

https://www.dbbest.com/blog/column-oriented-database-technologies/

http://www.javachain.com/big-data-hadoop-in-data-warehouse/

 

<개요>

Azure WebApp을 다음과 같은이유로 잘 사용해왔다.

- Azure Devops와 연계하여 배포가 쉽다.

- 다양한 Runtime환경을 기본으로 제공한다. (node, java, C# 등)

- 통합 로깅, 모니터링, 대시보드 환경을 제공한다.

- Auto Scaling이 편리하다. (VM 단위보다 더욱 유동적이다.)

- 접속을 위한 싱글포인트를 제공한다.

 

- 이번에 AWS에서 시스템을 구축하게 되어서 비슷한 PaaS를 찾던 중 Elastic Beanstalk를 발견하고 사용하던 중 발생한 내용이다.

 

<현상>

- Elastic Beanstalk는 내부적으로 nginx 를 사용하고 있다.

- Spring Boot배포 후 접속하면 502 Bad gateway 발생

 

<상세오류 - 로그확인>

2020/03/12 06:12:07 [error] 3114#0: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 100.10.0.208, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:5000/", host: "userservice-env.eba-yqakdkhm.ap-northeast-2.elasticbeanstalk.com"


<해결과정>

- 구글링을 통해서 나오는 대표적인 해결방법은 포트변경이다. (AWS Beanstalk가 기본적으로 5000포트를 사용한다고 한다.)

Beanstalk내의 환경설정에서 SERVER_PORT를 5000으로 변경

하지만 나에게는 해당하지 않는 내용이었다. 과거 connection reset을 해결할때가 떠오르기 시작한다;;

 

조금 더 관련내용들을 찾아보았다.

https://stackoverflow.com/questions/52912663/aws-elastic-beanstalk-nginx-connect-failed-111-connection-refused

 

AWS elastic Beanstalk / nginx : connect() failed (111: Connection refused

I got this message connect() failed (111: Connection refused Here is my log: ------------------------------------- /var/log/nginx/error.log ------------------------------------- 2018/10/21 06:16...

stackoverflow.com

내용을 종합해보면 결국 application이 적절하게 기동되지 않거나 하여 nginx 가 해석할 수 없는 메시지를 돌려받았을 경우 발생한다.

- Beanstalk의 설정을 천천히 검토해보았다.

 구성, 환경변수, 네트워크, 로드 밸런서 등 이상이 없음을 확인하였다.

- 그렇다면 결국 application이 제대로 기동되지 않았을 확률이 높으나 해당 로그를 확인할 수 없는 것이 아쉽다.  (로컬에서는 정상적으로 기동하니까)

 

- AWS Beanstalk의 spring-boot application 기동방식이 궁금해지기 시작한다.

샘플어플리케이션으로 사용되는 예제는 다음과 같다.

https://github.com/spring-guides/gs-accessing-data-rest.git

 

해당 프로젝트의 pom.xml을 살펴보고 문제점을 찾았다. 아주 사소한....

<build> 태그의 <spring-boot-maven-plugin> 을 빼먹고 작성하지 않았다. 

 

 

<정리>

- Azure WebApp을 사용할때는 azure-webapp-maven-plugin을 사용했었다.

- 신규 프로젝트 구성시 initializer없이 구성하다 Public Cloud관련요소 작업 중 Build plugin실수로 삭제;;

- 정확한 로그를 확인할 수 없어서 약간 힘들었음

 

<Azure WebApp과 비교>

- Azure WebApp이 생성시 매우 간단하다. 클릭 몇번으로 끝

- 배포 역시 azure-webapp-maven-plugin을 사용하여 IDE에서 바로 배포하는 것도 쉽다.

  다만 version에 따른 사용법이 매우 다르기 때문에 주의해서 사용해야 한다. 

  예전에 사용했던 버전이 1.4.0 과 1.5.3 이었는데 세부속성과 사용법이 다르고, 설정 오류시 상세한 메시지를 확인하기가 어렵다.)

 

- AWS Beanstalk역시 기본설정은 간단하지만 상세화면으로 들아가면 항목이 매우 많다. 

( Azure의 경우 후발주자이다보니 PaaS를 중심으로 발전시켜 나갔고, 

  AWS의 경우 VM기반의 선발주자이다보니 제품 여기저기에서 VM중심의 구성이 많이 보인다.)

 

 

<참고>

https://aws.amazon.com/ko/blogs/devops/deploying-a-spring-boot-application-on-aws-using-aws-elastic-beanstalk/

https://github.com/spring-guides/gs-accessing-data-rest/

https://docs.microsoft.com/ko-kr/azure/java/spring-framework/deploy-containerized-spring-boot-java-app-with-maven-plugin

 

Maven을 사용하여 Azure에 Spring Boot 앱 배포

Azure Web Apps의 Maven 플러그 인을 사용하여 Spring Boot 앱을 Azure에 배포하는 방법을 알아봅니다.

docs.microsoft.com

 

다음에는 Azure Devops와 AWS Code Pipeline의 비교사용기를 ...

+ Recent posts