Batch 작업의 경우 코드 상에서 cron으로 Job 스케줄링을 진행하고 있음.

이 스케줄에 따라 수행된 Job과 Step을 모니터링 할 수 있는 배치 관리 도구를 리서치하여 사용하고자 함.

결론: Jenkins / Spring Cloud Data Flow / TeamCity 중 선택

Jenkins

• 장점
  1. 대시보드 / 이력관리 등 관리를 위한 도구가 기본으로 제공됨 >> 모니터링 용도로 적합
  2. Email, Slack 등 여러 소프트웨어와 통합해 알림 설정 가능 >> 모니터링 용도로 적합
  3. 다양한 Job 실행 방법을 제공 >> 모니터링으로만 사용한다면 중요하지 않음
     1. cron 스케줄링
     2. 직접 수동 실행
     3. HTTP API
     4. Job Trigger : 현재 Job 실행 후 지정된 배치를 후속 실행시키는 것도 가능
  4. 풍부한 레퍼런스
     1. 오래되고 인기 있는 소프트웨어라, 관련 커뮤니티/자료/플러그인이 활성화 되어 있어 다양한 기능을 쓸 수 있고 정보를 얻기 쉬움
        1. Monitoring >> 모니터링 용도로 적합
           • Jenkins HTTP API 응답시간, 메모리, CPU 등을 모니터링 해주는 플러그인
  5. 파이프라인 >> 모니터링으로만 사용한다면 중요하지 않음
     1. Step이 아닌 Job을 최소 단위로 사용한 파이프라인을 만들어 순차 실행, 병렬 실행, 병렬+순차 실행 등으로 실행 순서를 다양하게 설정할 수 있음
     2. 파이프라인에서 간단히 반복문으로 날짜를 변경해 Loop 실행이 가능
  6. Master-Slave Node 환경을 이용한 배치의 분산 실행 (본래 용도는 분산 빌드) >> 모니터링으로만 사용한다면 중요하지 않음
     1. 여분의 서버가 있고 SSH로 연결이 가능하다면, Master 젠킨스가 별도의 실행 환경을 구성해 Slave Node로 batch 분산 처리를 해 줌
        1. 예를 들어, Slave Node로 특정 일자를 4등분하여 처리하는 것도 가능
           
           
• 단점
  1. 검색 기능/페이징 기능이 빈약해, 원하는 실행 기록을 찾는 것이 어려움
  2. 모니터링을 위해 배치 실행 기록을 검색하는 데 구현할 것이 많다 (초기 설정이 많이 필요)
     1. Jenkins API를 이용해 배치 실행 기록을 검색하는 데 API호출이 많이 필요하므로, 이것을 좋은 성능으로 보여주기 위해 내부에 코드로 작성할 부분이 있음
        
        

Spring Cloud Data Flow

• 장점
  1. Spring Framework와 매우 밀접하게 사용할 수 있음
     1. 배치 프로젝트에 @EnableTask를 붙여 Spring Cloud Data Flow에 Task로 쉽게 등록하는 등 => 스프링 클라우드 테스크와 스프링 배치를 통합시켜 테이블을 연결해 모니터링이 가능
  2. Batch 모니터링이 수월하다는 평가 (대시보드와 UI가 잘 되어 있고 활용이 편리)
     1. 필요하면 GUI를 이용해 배치를 설정하는 것도 가능
     2. 세부 상태 리포트 조회, 실패 잡 재시작 기능 제공
  3. Cloud Foundry와 Kubernetes 환경에서 스트리밍(Streaming) 및 일괄 처리(Batch Data Processing) 파이프라인을 구축하기 위한 툴킷 >> 배치 모니터링에는 배치 관련 기능만 사용
  4. Docker와 Kubernetes 연동이 가능
• 단점
  1. 국내에서 사용하기 시작한지 얼마 되지 않아서, 사용 방법에 대한 레퍼런스가 많지 않음
     1. 구축에 시간이 얼마나 걸리는지 알 수 없음
     2. 문제가 생겼을 때 해결에 시간이 걸릴 수 있음

TeamCity

• 장점
  1. IntelliJ와 통합되어 모니터링이 원활
     1. 친절한 UI/UX, 인텔리제이에서 바로 확인이 가능한 UI
  2. Docker와 연동이 쉬움
  3. Job, Step 실행 순서의 제약 없이 원하는 부분만 외부에서 실행시킬 수 있음
  4. 운영 환경에서도 잘 동작하는지 확인하는 테스트를 로컬에서 원격으로 실행시킬 수 있어, 동작 확인을 위한 배포가 필요하지 않음
     1. remote로 테스트하면서 관련 로그를 인텔리제이를 통해 알려줌
  5. 무중단 배포가 가능
• 단점
  1. 유료이다.
     1. 하지만 무료 버전으로도 기능이 충분하다고 함

GitLab CI/CD

• 장점
  1. 소스 코드와 CI/CD 파이프라인을 한 곳에서 관리하는 통합된 환경
     1. .gitlab-ci.yml 파일 사용으로 파이프라인을 정의. 이 파일은 프로젝트 소스 코드에 포함되어 있으므로 개발자들이 별도의 화면 전환 없이 코드와 함께 파이프라인을 설정하고 업데이트 할 수 있음
     2. 설정 파일 자체를 검증할 수 있고, 잘못 설정하더라도 이전 상태로 돌아가기 쉬움
  2. GitLab 설치 즉시 사용할 수 있는 간편함
  3. 다양한 러너 지원
     1. Docker 러너를 사용해 수많은 기능을 바로 사용
  4. 젠킨스와 달리 셀프 호스팅이나 SaaS 제공이 됨
• 단점
  1. Jenkins에 비해 플러그인 생태계가 좁다. = 원하는 기능을 사용하기 어려운 경우들이 있어 작은 프로젝트에 적용하는 것이 좋다는 의견이 있음

AWS CodePipeline + AWS Batch

• 장점
  1. AWS 서비스인 Batch를 사용해, Batch 작업을 GUI를 이용해 만들 수 있음
  2. AWS Batch를 CodePipeline 서비스와 연결하면 Batch 작업 모니터링이 가능
  3. AWS Batch는 추가 비용이 없고 무료, Batch가 돌아갈 때 사용한 AWS 리소스에 대한 가격만 지불(EC2 등)
• 단점
  1. Batch 코드상에 있는 내용을 AWS UI로 옮겨서 작성이 필요. 이 때 이미 작성한 Batch 코드를 삭제하고 AWS의 서비스 상에 세팅을 해야하는데, 이미 batch 코드를 작성해 둔 프로젝트의 진행 상황 상 시간이 걸리고 불필요한 작업이 될 것이라 예상

백엔드에서 작업한 API를 사용하기 위한 기본 정보를 프론트엔드에 API 문서로 전달하는 것이 여러 모로 보기 좋고 의사소통에도 도움이 된다.

• API 문서 작성 이유

API 문서화 도구인 Swagger를 사용하기도 하지만, Swagger만으로는 전달하는 정보에 한계가 있다.

예를 들면, ENUM 값을 어떤 것들을 넣을 수 있는지, Response body에서 어떤 값들이 필수인지 아닌지 등이다.

• API 문서 작성 위치

보통은 팀에서 사용하는 업무용 위키에 올려 공유하면 편하다. 현재 팀에서는 Confluence를 사용 중이다.

그래서 업무를 하면서 사용하기 좋았던 API 문서 양식을 글로 작성해 보았다.

*혹시 더 좋은 양식이 있다면 댓글로 의견 주세요!!

(API 이름) GetADetail

Request URL

Path Parameter

Headers

Authorization: Bearer ${accessToken}

Request body

Request body가 있을 경우 입력
json 양식 등

Response body

Response body가 있을 경우 입력
json 양식 등

Error code

로드 밸런서를 생성한 후, 작업 > 'Load Balancer' 속성 편집에 들어가면,

활성화된 모든 가용 영역의 정상 대상 간 트래픽을 어떻게 주고 받을 지 설정을 할 수 있다.

교차 영역 로드 밸런싱을 활성화하면, 로드 밸런서가 각 가용 영역(AZ)에 있는 모든 대상 그룹에 트래픽을 고르게 분배할 수 있도록 한다. 이 기능을 사용하면 가용 영역 간 트래픽 분포가 고르게 되어 특정 가용 영역에 과부하가 걸리는 것을 방지할 수 있다.

교차 영역 로드 밸런싱의 장점

1. 고른 트래픽 분배: 각 가용 영역의 인스턴스에 트래픽이 균등하게 분배된다.
2. 높은 가용성: 특정 가용 영역에 장애가 발생해도 다른 가용 영역의 인스턴스가 트래픽을 처리할 수 있다.
3. 성능 향상: 모든 인스턴스가 고르게 부하를 분담하므로 성능이 최적화된다.

그러나 설정을 할 때 어떤 로드밸런서이냐에 따라, 그리고 비용에 따라 주의할 점이 있다.

주의사항

• Application Load Balancer (ALB): ALB는 기본적으로 교차 영역 로드 밸런싱이 활성화되어 있으며, 이를 비활성화할 수 없다.
• Network Load Balancer (NLB): NLB에서는 기본적으로 비활성화되어 있으며, 활성화하려면 명시적으로 설정해야 한다.
• Classic Load Balancer (CLB): CLB에서는 선택적으로 활성화 할 수 있다.

비용

NLB와 CLB의 경우, 원래 비활성화 되어 있던 교차 영역 로드 밸런싱을 활성화하면 트래픽 분배와 관련된 추가 네트워크 비용이 발생할 수 있으므로 사용 시 이를 고려해야 한다.

참고자료

ChatGPT 3.5