1. 상황

휴면회원에 대한 기록을 쌓는 배치 프로세스에 대하여 쿼리를 작성 중이었다. 프로세스 흐름도는 다음과 같다.

 

 

2. 문제점

    - 연관성이 없는 각 select에 대해 단일 스레드를 통해서 순차적으로 쿼리를 실행하였기 때문에, 현재 상황보다 더 많은 테이블에 대해 작 

       업을 할 경우, 많은 시간이 소모된다.

    - @Transactional이 동작하는 사이클에 대해서 제대로 알고 쓰지 못하였기 때문에, rollback이 제대로 되지 않고 있다.

    - Spring Boot Batch Starter가 있음에도 불구하고 일반 절차 함수를 작성하듯이 프로그램을 작성하였다.

    - 후에 내가 작성한 프레임워크에 다른 배치 프로세스가 추가적으로 작성하는 것을 잘 몰랐기 때문에, 확장성이 덜 고려된 공통 코드를            작성하였다.

    - 작성한 프레임워크는 jar파일로 build되어 

   

 

 

 

3. 개선(해야할)점

    - 상호 관련이 없고, 연계성이 없는 쿼리의 경우는 단일 스레드에서 작업하지 않고, 복수개의 스레드에서 작업하여 속도를 향상시킨다.

    - 자체 코드 리뷰 결과, @Transactional을 사용한 @Service 내부의 method에서 catch문에서 exception을 던지고 있지 않기 때문에, 

       Spring에서는 exception을 감지하지 못하고, rollback를 시키지 않는 점이 발견되었다. 각 catch 문에 대해서 마지막에 exception을

       던져서 rollback이 가능하게 한다.

    - AOP에서 배치프로세스에 대한 로그를 작성할 때, @Transactional 어노테이션 걸린 서비스에 대해 동작하도록 되어있는데, 이를 조금 

      더 적절한 방법으로 대체할 수 있으면 대체를 하는 것이 좋다.

    - 불필요하게 Embadded Tomcat과 서버가 실행되는 것을 disable하여 jar 파일이 실행되기 전 준비단계를 줄였다.

    - JVM이 running 되기 전 단계에서 프로세스를 처리하도록 ApplicationListener를 이용하여 ContextRefreshedEvent에 대해 핸들링   

       하였다. 그러나, ContextRefreshedEvent의 경우는 Context가 바뀌는 상황마다 ApplicationListener가 호출되므로, spring이 시작할 

       때, 단발성으로 호출되도록 ApplicationStartingEvent같은 것을 사용하는 것이 더 좋을 듯하다.

    - 실행파일 형태로 cron에 걸수 있도록 설계하라하여 지금 상황과 같이 설계하였다. 그러나, 현행방법과 데몬이 계속 떠있는 방식 중 어   

       떤것이 더 효율적일까를 따져봐야 할 것이다.

'회고' 카테고리의 다른 글

20200624 회고 - 배치 프로세스 및 데이터베이스  (0) 2020.07.28
2019 회고  (2) 2020.02.01
20191126 회고 - 프로그래밍 패턴  (0) 2019.11.26

0. Table of content

 

 

 

1. 목표 아키텍처

 

 

 

 

 

2. Apache Kafka Download

 

다음 명령어를 통해 Apache Kafka 최신 버전을 다운받고 java1.8을 설치한다.

sudo yum install -y java-1.8.0-openjdk-devel.x86_64
 
wget http://apache.mirror.cdnetworks.com/kafka/2.5.0/kafka-2.5.0-src.tgz
 
tar -xzf kafka-2.5.0-src.tgz

 

압축을 해제하면 다음과 같은 구조의 디렉토리를 볼 수 있을 것이다.

 

 

 

3. Zookeeper Cluster Configuration

 

Zookeeper Cluster를 구성하기 위해 3개의 VM을 생성하였으며, 상세 config 및 서버 스펙은 다음과 같다.

IP AddressZookeeper IdKafka Broker IdInstance Type

IP Address Zookeeper Id Kafka Broker Id Instance Type
10.0.6.218 1 1 t2.medium
10.0.7.5 2 2 t2.medium
10.0.6.195 3 3 t2.medium

 

ZooKeeper 데이터 디렉토리에는 특정 서빙 앙상블에 의해 저장된 znodes의 영구 사본 인 파일이 있습니다.

각 zookeeper의 설정을 {kafkaDir}/config/zookeeper.properties에 다음과 같이 3개의 vm에 입력한다.

# 여러 zookeeper에 의해 저장된 znode의 사본과 zookeeper id를 저장하는 dir
dataDir=/home/ec2-user/zookeeper

# zookeeper가 coordinate하고 있는 kafka에 접속하기 위한 클라이언트 port
clientPort=2181

# 클라이언트 connection 접속 제한 개수
maxClientCnxns=10

# Follower가 leader에 접속하고 싱크를 맞추기 위해 허용된 시간. 값이 증가할수록 zookeeper가 책임지는 데이터의 양이 증가한다.
initLimit=5

to allow followers to sync with ZooKeeper. If followers fall too far behind a leader, they will be dropped.
# Follower가 Zookeeper에 싱크를 맞추기 위해 허용된 시간. Follower가 leader에 대해 싱크를 맞추지 못하면 drop 된다고 햔다.
syncLimit=2

# Zookeeper VM의 정보
# 형식 : server.{id}={VM HostName or IP address}:{Cluster Sync Port}:{Leader Election Port}
# 입력시, localhost는 기입하지 않으며, 무조건 hostname, ip address를 이용하여 기입한더ㅏ.
server.1=10.0.6.218:2888:3888
server.2=10.0.7.5:2888:3888
server.3=10.0.6.195:2888:3888

 

 

또한, 각 Zookeeper id를 다음과 위에서 설정한 dataDir 경로에 myid라는 파일을 만들어 다음과 같이 입력한다.

echo 1 > {Your zookeeper dataDir in zookeeper.properties}/myid

 

입력한 후, 다음과 같이 각 VM의 zookeeper를 다음 명령어로 실행시킨다.

정상적으로 동작이 되는 경우는 첨부된 다음과 같은 사진과 같은 화면을 볼 수 있다.

# 테스트를 위해 데몬으로 실행시키지 않음.
# kafka cluster 실행을 위해서는 -daemon 옵션으로 백그라운드 실행시킨다.
bin/zookeeper-server-start.sh config/zookeeper.properties

 

 

4. Kafka Cluster Configuration

[업데이트 예정]

 

5. 참고자료

    - https://zookeeper.apache.org/doc/r3.4.7/zookeeperAdmin.html 

    - https://kafka.apache.org/documentation/#brokerconfigs 

 

6. 삽질프로젝트 로그

    - 20200630 : Zookeeper Cluster VM생성 완료

    - 20200701 : Zookeeper Cluster 구성완료

 

'IT > OpenSource' 카테고리의 다른 글

[OpenSource] Apache Kafka  (0) 2020.09.07
[Apache Kafka] Kafka Cluster 구성하기(수정중)  (0) 2020.07.01

1. 대시보드에서 나타내야 할 것

- 기간에 따른 사용자 수

- 인기글 리스트

- 유입 경로 및 채널

- 유입 키워드

- 유입자 현황 차트 (척도 : 기간, Refere URL, 컨텐츠, 디바이스)

 

 

2. 추가 구현하고 싶은 것

- 전날 유입자 통계를 카카오톡으로 알림 받기

- 현재 학습하고 있는 OAuth2.0을 이용하여 대시보드 사이트 인증

- 일일 평균 유입자 현황

- 현재 기능별로 레포지토리가 분리되어있고, kafka broker에 다양한 로그들을 수집할 예정이기 때문에 향후 kubernetes를 적용할 예정

 

 

3. 사용할 기술

- DB : DynamoDB or MongoDB (조회성이 많기 때문에 RDB보다 NOSQL이 낫다고 판단) with JPA

- Message Broker : Apache Kafka (Topic은 YYYYmmDD 형식 사용, content는 json형식의 로그데이터 / 일일 배치로 DB BulkUpdate)

- Framework : spring boot with jstl (다른 가벼운 것을 써도 되지만, 학습 차원에서 사용하도록 한다.)

- 언어 : Java1.8

- 인증 : Oauth2.0(Spring Security 사용 예정), jwt

 

 

4. 수집해야할 정보

- 블로그 유입자들이 클릭한 컨텐츠

- 유입 시간대

- 블로그를 조회한 Referer URL

 

 

 

5. 아키텍처 구성도

 

 

6. 참고 문헌

- KISA 고시 및 권고 : www.kisa.or.kr/public/laws/laws2.jsp

- Apache Kafka Documentation : www.kafka.apache.org/documentation/

- RFC6749 : www.tools.ietf.org/html/rfc6749

 

 

7. 수정 로그

2020.05.13 : 최초 작성

2020.05.20 : 아키텍처 다이어그램 추가 완료

2020.06.11 : 아키텍처를 AWS로 옮기는 중, 불필요한 로드밸런서 개수와 외부 노출 서비스의 도메인 연결로 인해 아키텍처 수정중.

2020.06.16 : 서비스별 로드밸런서 아키텍처 적용 및 향후 계획(kubernetes 적용 예정) 추가

2020.06.30 : 운영 환경을 생각하고 설계할 것이기 때문에 kafka와 zookeeper를 분리하는 아키텍처 적용 예정

2020.07.01 : Zookeeper Cluster 구성 완료

+ Recent posts