spring.io 레퍼런스(sagan project)를 통해서 배우는 spring 개발사례에 대해서 발표하고 정리한 프레젠테이션입니다. 작년에 SpringOne에서 발표된 inside spring.io 내용과 저의 개인적인 분석을 통해서 내용을 정리했습니다.
'입문자' 분들을 대상으로 정리했기 때문에 가능한한 간결하고 직관적으로 내용들을 표현했으며 깊게 들어가는 내용들은 거의 생략을 하였습니다.
자세한 내용들을 원하시면 프레젠테이션 중간중간에 관련 link를 첨부하였으니 같이 보시면은 도움이 되실것 같습니다.
The Spring Web model-view-controller (MVC) framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale and theme resolution as well as support for uploading files.
Scala, Spring-Boot, JPA를 활용한 웹 애플리케이션 개발 과정에 대해 다룬다. Spring-Boot와 JPA 조합만으로도 생산성 있는 웹 애플리케이션 개발이 가능하다. 이 조합만으로도 충분히 의미가 있지만 여기에 Scala라는 약간은 불편한 듯 보이는 언어를 도입함으로써 얻을 수 있는 즐거움을 공유한다. Spring-Boot + JPA 조합에 Scala를 적용하면서의 좌충우돌 경험담을 전한다.
spring.io 레퍼런스(sagan project)를 통해서 배우는 spring 개발사례에 대해서 발표하고 정리한 프레젠테이션입니다. 작년에 SpringOne에서 발표된 inside spring.io 내용과 저의 개인적인 분석을 통해서 내용을 정리했습니다.
'입문자' 분들을 대상으로 정리했기 때문에 가능한한 간결하고 직관적으로 내용들을 표현했으며 깊게 들어가는 내용들은 거의 생략을 하였습니다.
자세한 내용들을 원하시면 프레젠테이션 중간중간에 관련 link를 첨부하였으니 같이 보시면은 도움이 되실것 같습니다.
The Spring Web model-view-controller (MVC) framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale and theme resolution as well as support for uploading files.
Scala, Spring-Boot, JPA를 활용한 웹 애플리케이션 개발 과정에 대해 다룬다. Spring-Boot와 JPA 조합만으로도 생산성 있는 웹 애플리케이션 개발이 가능하다. 이 조합만으로도 충분히 의미가 있지만 여기에 Scala라는 약간은 불편한 듯 보이는 언어를 도입함으로써 얻을 수 있는 즐거움을 공유한다. Spring-Boot + JPA 조합에 Scala를 적용하면서의 좌충우돌 경험담을 전한다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
성공적인 디지털 트랜스포메이션을 위해서는 클라우드 전환이 필수적인데요, 많은 기업에서 막상 클라우드를 도입할 때 여러가지 장벽에 맞닥뜨리게 됩니다.
클라우드 마이그레이션에 관한 여러분의 고민을 시원하게 해결해주기 위해 Global Public Cloud의 독보적인 선두 AWS(Amazone Web Services)와 클라우드 마이그레이션 전문기업 오픈소스컨설팅이 만났습니다!
많은 기업들이 마이그레이션 수행할 때 가장 많이 하는 질문 Top 10에 대한 기술 전문가의 노하우가 담긴 답변을 공유합니다.
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤...Amazon Web Services Korea
클라우드 마이레이션은 단순한 업무의 환경 이전 차원을 넘어 미래를 준비하는 긴 여정의 출발점이기도 합니다. 또한, 클라우드 마이그레이션의 전략,기술 준비사항은 기존의 IT 운영 환경에 비례하여 매우 다양하며 복잡 합니다. 이번 세션에서는 AWS MSP 파트너사인 오픈소스 컨설팅, 스마일 샤크의 다양한 클라우드 마이그레이션 사례 및 운영 환경 최적화 사례를 기반으로 여러분들의 클라우드 여정에 도움을 드리고자 합니다.
4. 구 배치 수집 현황
• 스케쥴링 : RAC XML에 명시된 Quart JOB 을 수행
• 마샬링 : Xstream
• 일 수집 데이터 평균 건수 : 10만건
• 배치 JOB 건수 : 9 건
• JOB 이력 관리 단일 테이블을 통해 전체 JOB 이 수행 여부 체크
• (조건 : 완료가 안되었거나 작업 완료후 4시간 지난경우)
5. 문제점
• 특정 시간 혹은 작업 이력테이블상에선 알수 없는
이유로 인해 배치가 동작이 안됨
• 특정 JOb 구동시 3시간 30 분 이상 소요
가 되며
시간이 지날수록 점차 증대
• 재 구동시에도 반복적인 현상 발생되며 톰켓상 오류로는
배치 상세 문제 확인이 어렵고 테스트가 불가능
.
6. 장애 및 지연 원인
• 1건 처리시마다 Sleep 구간을 두어 시간이 지연
• 대량의 데이타 등록후 데이타 미삭제로 인해
인덱스 단편화 발생되어 성능 하락
• 특정 JOB 실패시 작업 이력 테이블 삭제가 되며
해당 JOB 재시도가 아닌 전체 배치 재 구동되어 시간 지연
• 데이터 한건마다 트랜잭션을 수행하며 대량 데이터 일괄 처리를
위한 ORM BATCH 기능 부재
7. 조치 사항
• 시간 체크주기를 3 시간에서 4 시간 으로 임시 증가
• 배치를 재 구동후 전체가 완료될때까지 수동 모니터링
• JOB 별로 하나씩 처리후 Tomcat Restart 후 반복 확인
8. 근본적인 문제
• 로깅 및 메세지 , 예외 처리 문제
– 특정 배치 JOB 에 대한 실행, 시작, 종료, 성공 여부, 오류 사항에 대한 로그가
없어서 명확한 원인 파악이 불가능
• 모니터링 시스템에 대한 부재
– 배치 오류시 개발자에 의한 확인보다는 장애 확인요청에 의한 대응
• 일괄 처리 정책 미흡
– 대량의 데이터 처리시 DB 에 영향을 최소화 하며 일정 단위로 나누어 한꺼번에
처리하는 방법이 필요함
• 부분 처리에 대한 고려 필요
– 실행 중인 작업이 중간에 에러 발생시 전체 작업을 재시도하기때문에 진행 부분에
대한 파악이 어려움
• 테스트 환경의 어려움 :
– 처리되는 전체작업을 하나의 단위로 처리하는 경우가 많기 때문에 에러 발생시 디
버깅에 어렵다.
9. OVERVIEW
• 배치 소개
• 개선 방향
• 솔류션 평가 및 선정
• 추진 계획
• 개선 결과
11. 사용자와의 상호 작용
• 일반적인 온라인 Application 과 달리 사용자에 의해
실행이 결정되지 않는다 .
• 주어진 시간외에 독립적으로 배치를 실행 지원
• 실시간 동작되는 배치를 업무 필요상 중단 혹은 재
시작을 손쉽게 할수 있어야 한다.
12. 정해진 시간내에 실행이 완료
• 사업 및 기획 요구 특성에 따라 수집 데이터 증가되고
있으며 전형적인 CNP 패턴으로 유사 코드 반복으로
인해 정책 반영이 느림
• WAS 위에 동작되는 어플리케이션으로 서로 다른 배치
가
영향을 주고 받아 성능 문제 발생
• 업무 로직 개선과 배치 분리 개선 병행
13. 대량의 데이터를 다루기 위한
성능 최적화
• 배치 처리 에러 발생시 전체가 롤백됨
• 트랜잭션 단위가 껀별로 진행되어 성능지연
• 전체 ( 성공 &실패) 단위로 배치가 구성되어 부분 처
리 미흡
• FILE 및 DB I/O 최소화 및 프로그램 최적화
• 병렬 처리
14. 관리 시스템 구축과 기반 설계
• 모듈 활용의 부족
• ORM BATCH 기능 부재
• 장애 관련 모니터링 시스템 부족
• 배치 상세 모니터링 시스템 구성
• 아키텍처 모듈 최적화
• 배치 정책 (재시도, 재시작,건너뛰기) 수립
• SPRING 및 오픈 소스 최대 활용
• Jenkins 활용한 배치 모니터링 시스템 구성
15. 배치 서비스 표준화
• 배치에서의 정보 항목등이 명확하지 않음
– 작업주기, 작업 유형 , 작업 현황 정의
• 배치 기술 유형이 불분명하고 , 기술 유형별로 구현 방
법이 상이
– 입출력 리소스 추상화 , 사용 도구 , 처리 흐름 , 적
용 기술
16. 배치 서비스 표준화
• 개인역량에 따라 각기 배치 어플리케이션의 보안 , 성
능,
자원관리 개발이 이루어지고 품질 확보가 어려움
• 기존 Batch SYSTEM
– Linux 의 Crontab을 이용한 Shell Script
– Windows 의 작업스케쥴러를 이용한 batch script
– Web Service 안에 Web Call 호출 방식
– Web Service 안에 QuartzJob 이용
– 자체 배치 플랫폼 개발
– Legacy (C, C++, php, ETL, rsync, perl, python, Pure Java)
17. 배치 서비스 표준화
• 트랜잭션에 대한 깊은 고민 부족
– 지나치게 긴 트랜잭션은 DB 자원 (Rollback
Segement)
한계 부딪칠 가능성 높다
– 짧은 트랜잭션은 좋은 성능 보장이 어려움
DB 및 운영 특성에 맞게 일정 사이즈로 데이터
를
균일하게 Fetch 하여 적정횟수 만큼 Commit
문서 참고 : http://helloworld.naver.com/helloworld/1247
18. 배치 서비스 표준화 개선 절차
• 비즈니스 변화에 대한 빠른 대응과 저 비용으로
고품질을 만들수 있어야 한다.
• 유형별로 빨리 만들어 낼수 있어야 한다.
• 반복되는 로깅, 보안, 예외처리, 신경 끄기
• 개발자에게 노출이 필요한 부분 최소화
• 배치 기반 특성이 충분히 반영되어야 한다
19. OVERVIEW
• 배치 소개
• 개선 방향
• 솔류션 평가 및 선정
• 추진 계획
• 개선 결과
20. 솔류션 평가 및 선정
• SPRING BATCH
• SPRING DATA JPA
• SPRING BOOT
• JdbcTemplate
• Java Configuration
21. SPRING BATCH + ALPHA
• Run Tier : 실행과 스케쥴링 담당 ( Spring Boot, Jenkins)
• Job Tier : 전체적인 JOB 수행 책임 (Spring Batch)
• Application Tier : JOB 을 수행하는 필요한 컴포넌트
(Spring Data Jpa, Java Configuration)
• Data Tier : DataBase, Flat, XML 등 물리적 데이터 리소스
22. SPRING BATCH
• Spring 의 기술력과 컨설팅 회사인 Accenture 의
대형 금융권 배치 기술 아키텍처의 경험이 녹여듬
• 자바 환경에서 사실상 표준인 Spring 활용
• 국내 및 해외 유수 보험 및 금융기관에서 채택되어
전사 표준 배치로 사용중
• Spring 추상화 기술로 특정 기술에 종속적이지 않음
24. SPRING BATCH
문서 참고 : http://docs.spring.io/spring-batch-old/1.1.x/spring-batch-docs/reference/html-single/index.html
25. SPRING BATCH
• 혼자 이해하던 복잡한 Legacy 배치를 배치 프
레임워크 변환후 동료들과 공유 가능
• JOB 문제시 추적 범위가 좁혀져 오류 발생시
원인파악이 쉬움
• 코딩량이 이전에 비해 ½로 줄어듬
• 배치 로직 구현이 단일건 대상으로 이해가 쉬
움
26. SPRING DATA JPA
• 도메인 클래스에 대한 투명한 감시 및 관리
• 페이징 지원, 다이나믹 쿼리 수행, 데이터 엑세스 코드를 도메인에 통합
• ANNOTATION 으로 테이블 매핑
28. SPRING DATA JPA
• 반복적인 쿼리 노가다 삽질 작업 제거
• 엔티티 기반 도메인 설계에 집중
• 비즈니스 로직 구현 최소화
• 인터페이스 정의만 하면 알아서 구현체 생성
• 변경 사항에 대한 개발 기간 단축
• 코딩량이 이전의 ½ 로 줄어듬
• 손쉬운 테스트 코드 작성
29. SPRING BOOT
• Spring 프로젝트 개발을 빠르고 다양한 방법으로
시작할수 있도록 한다.
• 설정을 위해 별도의 코드 구현이 없으며 XML 이
필요치 않다.
• Tomcat 과 Jetty가 내장됨
• 임베디드서버, 시큐리티, 헬스체크, 외부 설정 연
계등 개발의 모든 사이클을 제공한다.
31. SPRING BOOT
Endpoints
ID 설명
Autoconfig 자동 설정되거나 설정되지 않는 목록들과 그 이유
Bean 어플리케이션에서 선언한 Bean 목록들
Configprops Properties 로 선언된 목록들
Dump Thread Dump
Env 시스템 환경 및 어플리케이션 환경 목록
Health 어플리케이션 상태 체크
Info 어플리케이션 정보
metrics 어플리케이션의 메트릭스 정보
mappings @RequestMapping 에 매핑된 경로 정보
shutdown 어플리케이션 종료
trace Http 요청 정보
36. OVERVIEW
• 배치 소개
• 개선 방향
• 솔류션 평가 및 선정
• 추진 계획
• 개선 결과
37. 추진 계획
2014
3월 4월 5월
13 19 03 30 08 20 28
Start With GitHub
1차 Prototype 구현
성능 테스트
Major JOB 완료
및 모듈 구성
2차 Prototype
Spring Data JPA 연동
Spring Boot 연동
망별 성능 테스트
End With Live Deploy
Jenkins 을 활용한 스케쥴링
Timeline
38. OVERVIEW
• 배치 소개
• 개선 방향
• 솔류션 평가 및 선정
• 추진 계획
• 개선 결과
43. 운영 및 모니터링 개선
• Spring Batch Listener 를 활용한 배치 상세 로그 관리
– Job 별 수행건수, 수행시간, 에러메세지, 배치 상태,
커밋, 롤백, 파라미터 관리, Skip, 에외 처리 기록…
44. 운영 및 모니터링 개선
Spring Boot 를 활용한 어플리케이션 생성 , JOB 손쉬운 관리
#SPRING BATCH
Spring.batch.job.names=armorItemXmlToDbJob
Spring.batch.job.enabled=true
Spring.batch.initalizer.enabled=false
• spring.batch.job.names : Context 에 등록된 Bean 중 해당하는 JOB 만 명시적으로 선
언하여 사용할지 선택하며 comma 로 구분
• spring,batch.job.enabled : Spring Ruuner 가 구동시 모든 JOB 을 수행할지 여부
• spring,batch.initializer.enable : 데이타베이스 플랫폼에 해당하는 SQL 초기화 스크립
트를 수행 여부
45. 테스트 및 유지보수 개선
• 망별 환경설정을 통해 XML , URL Resource 자동 분기
– Spring.profiles.active, spring.core.io.resource
46. 테스트 및 유지보수 개선
• 단계별 JOB 수행 및 테스트 코드를 통해 빠른 테스트
진행 및 선택적 확인 가능
– Full Test Code Support
47. 테스트 및 유지보수 개선
• SPRING DATA JPA를 통한 반복적 쿼리 작업 제거
NO
48. 테스트 및 유지보수 개선
• Web Project에서 배치를 제거하여 관심 분리
• 유지보수 집중화
WEB WEB
BATCH
BATCH
49. 로직 개선
• 쿼리 및 비즈니스 로직 최소화
MVC
패턴
SPRING
DATA
SPRING
BATCH
SPRING
DATA
Domain -> Service -> ServiceImpl -> DAO -> DaoImpl -> 쿼리
Domain -> Service -> Repository
Domain -> Processor
51. 고려사항
• 코드양은 줄어드는 반면 개념이해는 필수
• SPRING 프로젝트들은 계속 진화중
• SPRING-BATCH 는 동일 JOB Repository 에 동일한 JOB-NAME 과
JOB-PARAMETER 로 JOB Instance 생성 불가
• BATCH JOB 은 성격이 다양하기 때문에 SPRING에서 다양한 해결
방법을 지원한다
• 바퀴를 재 개발하지 말고 오픈 소스를 찾아서 사용하자
• 장애 발생을 최소화 하고 TestCase를 통해 사전에 문제를 예방
• 테스트가 어느 자리, 어느 망에서도 쉽게 재현되도록 준비