박선용 AWS 솔루션즈 아키텍트
- 모놀리식 어플리케이션을 마이크로 서비스로 전환하는 과정을 순차적으로 살펴본다
- 모놀리식 vs 마이크로서비스
- 모놀리식 아키텍처에서 작은 단위 하나의 어플리케이션이 통채로 있을 경우 장점은 분명하다.
- 모듈별로 분화된 마이크로서비스 아키텍처는 빠르게 확장하고 변화하는데 최적화 되어있다.
- 마이크로서비스 아키택처(장점)
- 개별 서비스를 소규모 모듈로 구성 가능
- 장애에 강해짐
- 장기적 기술 종속을 감소
- CI/CD의 장점을 극대화함
- 단점
- 개발 환경의 미성숙
- 배포의 복잡성(언어, 환경, 프레임웍이 각각 다르므로)
- 시스템의 메모리 소요가 상대적으로 높아짐
- 엔터프라이즈에서는 보통
- 기존에 만들어진 어플리케이션 환경에서
- 대규모 기능이 하나의 어플리케이션에 집중되어있고
- 서로 복잡하게 연계된 어플리케이션 환경을 가지고 있다.
- MSA 아키텍처로의 전환
- 어떤경우에 전환 검토해야 하나?
- 쉽고 빠른 어플리케이션의 변경
- 새로운 개발자의 빠른 적응
- 새 기술의 빠른 적응
- CI/CD
- 어떤경우에 전환 검토해야 하나?
- MSA 전환시 중요사항
- 안정적인 아키텍처일 것
- 서비스는 연계가 강한 기능들의 집합일 것
- 동일한 이유로 변경되는 것들은 하나의 서비스 일 것
- 서비스끼리는 느슨한 결함일 것
- 각각의 서비스는 테스트 가능할 것
- 각 서비스는 2 pizza팀이 개발/관리가 가능할 정도의 규모일 것
- 가이드라인
- 객체지향 원칙중
- SRP(Single Responsibility Principle)
- CCP(Common Closure Principle)
- 객체지향 원칙중
- 어떤 기준으로 분할 할 것인가?
- 비즈니스 역량에 기준한 분할
- 서비스의 중요도에 따라서 분할한다.
- 서브 도메인에 의한 분할
- 도메인 주도 디자인(DDD)
- 비즈니스의 문제 영역을 도메인으로 호칭
- 도메인은 여러개의 서브 도메인으로 구성
- 서브 도메인 구분
- 핵심 / 지원 / 일반
- 문제점
- 서브 도메인을 특정하는것이 어렵다.
- 도메인 주도 디자인(DDD)
- 비즈니스 역량에 기준한 분할
- 비즈니스 관점 vs 시스템 관점
- 실무적인 접근
- 각 기능의 상위 서비스 API 정의
- 서비스 API를 기준으로 각 모듈 정의
- 코어와 아닌 것을 구분
- 어플리케이션의 로직 구조 및 Data관점 탈피
- 실무적인 접근
- 서비스 별 데이터 패턴
- 서비스별 테이블, 서비스별 스키마, 서비스별 데이터베이스
- API 게이트웨이 패턴
- 다양한 어플리케이션에 대한 단일한 접근 포인트를 제공한다.
- 회로 차단기(Circuit Breaker) 패턴
- 클라이언트가 전기 회로 차단기와 비슷한 방식으로 기능하는 프록시를 통해 원격 서비스를 호출하는 패턴
- 전환시 고민할 문제들
- 아키텍처 품질 목표
- 확장성, 가용성, 민첩성, 운용 편의성, 성능 등
- 분할
- 어플리케이션
- 데이터
- 고민
- 데이터 분할의 어려움
- 어플리케이션 분할의 어려움
- 아키텍처 품질 목표
- 메인 데이터베이스
- 외래 키의 제거
- 공유 데이터
- 공유 데이터를 사용하는 어플리케이션은 공유 서비스로 만들어야 한다.
- 스키마 분리
- 리포팅 혹은 분석 데이터 베이스
- 리포팅 시스템 데이터만을 위한 API는 이득 대비 손실이 너무 크다.
- 메인 데이터베이스와 리포팅 데이터베이스 간에 데이터 펌프가 필요하다.
- 이벤트 데이터 펌프는
- 서비스가 이벤트를 발생시키면
- 데이터펌프가 데이터를 리포팅시스템으로 전달한다.
- 좀 더 디커플링 된다.
- 개발에 많은 부담이 있다.
- 데이터베이스 리팩토링
- 1단계 - 단일 스키마
- 2단계 - 스키마 분리
- 3단계 - 어플리케이션 분리
- 컨테이너와 AWS 서비스
- 컨테이너 고려
- 아키텍처 품질 목표
- 확장성, 가용성, 민첩성, 운용 편의성, 성능 등
- 아키텍처 품질 목표
- 마이크로 서비스 어플리케이션은
- 서로 다른 어플리케이션 스택
- 서로 다른 하드웨어 배포 환경
- 어떻게 서로 다른 환경에서 모든 어플리케이션을 운용할 수 있을 것인가?
- 어떻게 한개의 환경에서 다른 환경으로 쉽게 마이그레이션 할 것인가?
- 소프트웨어 딜리버리 단위로 생각해봤을 떄
- 가볍고, 이식성 좋고, 일관된 것은
- 컨테이너 환경이더라.
- 배포하고 어디서나 무엇이든 실행한다.
- 현재 서비스 매핑
- 2세대 MSA 아키텍처 사진 첨부
- 컨테이너 고려
- 초기 시스템 설계시 부터 고려해야 한다.
- 기존 어플리케이션에 대해서는 전환계획을 수립해야 한다
- 발견, 패턴, 분할, 매핑 등 단계별 접근 고려
- 각 비즈니스 단위의 구분, 서비스의 요구사항 등 고려
- 데이터 분할에 대한 전략
- 컨테이너 기술 및 서버리스 서비스의 활용
엑셈 류길현 이사
- 클라우드향 애플리케이션 특징
- Auto Scaling 구조
- WAS, 컨테이너의 증가/축소가 잦음
- 마이크로서비스 아키텍처
- Auto Scaling 구조
- 클라우드향 애플리케이션 모니터링 대응방안
- Auto Scale In/Out 대상 모니터링 제공
- 복잡한 구조의 서비스 연계를 통합적으로 모니터링 제공
- 신속한 장애 대응을 위한 초단위 실시간 모니터링 필요
- 인프라 이외의 애플리케이션, 비즈니스 단위의 통합 모니터링 대응이 필요
- 관리/운영자에 의존적인 방식보다는 AI기반 Smart 모니터링
- 장애 발생시 사후 문제 분석 보다는, 기존 정상 부하 패턴에 따른 이상치 탐지시 사전에 예측
- 클라우드 환경의 다양한 관리 솔루션 연동 필요성
- AWS 콘솔, openshift, kubernetes 등 연동 지원이 필요함
- 실시간 성능 모니터링
- 모든 노드들에 대한 실시간 성능 모니터링, 장애발생시 이벤트 발생 및 원인 분석 기능
- 실시간 액티비티 현황과 주요 지표 추이, 트랜잭션 패턴 차트를 통하여 서비스 현황 파악
- Topology View
- 전체 시스템 아키텍처에 대한 자동 토폴로지 구성
- 전체 시스템 아키텍처의 트랜잭션에 대한 정보 제공
- Transaction Path View
- 개별 트랜잭션의 End-to-End 플로우를 통해 직관적인 거래 흐름과 지연 구간 파악
- 구간 별 응답시간을 제공하여 서비스에 영향을 주는 구간을 즉시 분석 가능
- 비즈니스 관점의 대시보드
- 비즈니스 관점의 구간별 성능 모니터링 제공
- 금융권 - 여신, 수신, 전자금융, 상품처리 등 비즈니스 단위 구간별 상세 성능 모니터링
- 단위 트랜잭션 관점이 아닌 주문 건수, 매출액 현황 등 비즈니스 관점의 모니터링 제공
- 단순히 WEB-WAS-DB로 구성된 환경에서도 비즈니스 트랜잭션 관점에서도 모니터링 제공
- 장애 예측 시스템
- 다양한 성능 데이터 수집 분석을 통한 사전 장애 예측 시스템
- 원천 데이터 수집
- 성능 데이터 수집 및 가공
- 사전 장애 예측 및 장애 패턴 학습(딥러닝)
- 다양한 성능 데이터 수집 분석을 통한 사전 장애 예측 시스템
- AI 적용 분야
- 부하/장애 예측
- 부하 예측
- 과거 수집 데이터를 인공지능이 지속적으로 학습하여 미래 부하를 예측
- 장애 예측
- 수집된 데이터의 트랜드를 예측하여 미래 특정 시점에 장애가 발생할지를 미리 알려줌
- 비정상 탐지
- 과거 데이터를 기반으로 신뢰 궤적을 그리고 해당 궤적을 바탕으로 비정상 탐지 기능 제공
- 부하 예측
- 장애 분석
- 부하 패턴 분석
- 부하 패턴을 다수의 유형으로 범주화하여 학습
- 인과 관계 분석
- 비정상 발생 후, 인공지능에서 해당 문제에 대한 연관 지표 학습을 통하여 증상/징후를 찾아주는 기능
- 근본 원인 분석
- 사전에 고객사별 장애의 원인 및 분석하는 방법을 Rule로 등록, 장애 발생시 인공지능 Rule Engine에서 장애에 대한 원인 분석 결과 제공
- 부하 패턴 분석
- 부하/장애 예측