Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)SANG WON PARK
2020년 데이터산업진흥원에서 발표한 자료를 일부 편집하여 공유함.
2020년 당시에 Data Platform에서 AI lifecycle를 효율적으로 지원하는 platform을 적극적으로 검토 및 설계하는 작업을 진행하였고, 이 때 검토 및 활용했던 기술들을 기업 관점에서 필요한 내용을 기준으로 정리하였다.
기업들은 전통적인 방식으로의 혁신에 한계를 체감하고 있으며, 최근 AI기반으로 성공적인 혁신(비즈니스 강화, 새로운 비즈니스로 전환 등)에 성공한 기업들을 빠르게 벤치마크 하고 있다.
이렇게 AI 기반으로 기업을 혁신하는 것은 고도화된 AI 모델의 도입으로 해결되지 않으며, 수많은 기술들의 최적화된 조합 및 활용이 필요하다.
이 자료에서는 그 중 AI모델에 핵심적인 데이터를 적시에, 고품질의 형태로, 빠르고 안정적으로 제공할 수 기술 트렌드를 소개한다.
전체 내용은
- AI기반 혁신이란?
- 혁신을 위해서는 어떤 점이 어려운가?
- 고품질 데이터 확보 기술
- 빠르게 AI 모델을 학습하는 기술
- 적시에 다양한 AI 모델을 비즈니스에 적용하는 기술
2020년 기준으로 작성된 자료라, 일부 기술 트렌드가 반영되지 않을 수 있으나 아직까지 많은 기업들이 고민하고 해결하고자 하는 영역이라 참고할 수 있을 것 같다.
이 내용을 기준으로 발표한 영상 링크 : https://www.youtube.com/watch?v=OVm4-uk59ZA
사례들로 알아보는 컨테이너, 언제 어떻게 쓰면 좋을까? – 김성수 AWS 솔루션즈 아키텍트, 허준 AWS 어카운트 매니저, 이창명 선데이토...Amazon Web Services Korea
컨테이너를 활용할 수 있는 Workload는 정해져 있는 걸까? 이제는 주변에서 쉽게 보고 들을 수 있는 컨테이너, 하지만 정작 내가 쓰려면 어떻게 써야 할지 감을 잡기 어려운 것도 사실이죠. 유명 게임, 웹 서비스에서 컨테이너를 어떻게, 왜 쓰게 되었는지를 알아봅니다. 그리고 컨테이너에 올리는 작업의 특성을 파악하면 활용할수 있는 팁들까지, 실사례를 통해서 알아봅니다!
본 강연에서는 금융 감독원의 클라우드 이용 가이드라인에 맞추어 바로 도입 가능한 HPC, 빅데이터, 백업, VDI 등의 업무에 대하여 간단하게 소개하고 AWS 상에서 구축하기 위한 참조 아키텍쳐와 특장점 및 고객 사례에 대해 설명해 드릴 예정입니다.
연사: 정영준 솔루션 아키텍트, 아마존 웹서비스
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...BESPIN GLOBAL
기존 레거시(Legacy) 시스템이 가지고 있는 변화하는 기술에 대한 빠른 대응과 비즈니스 어플리케이션 배포의 한계 등을 극복하기 위한 대안인 클라우드 도입.
클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유를 실제 사례를 통해 알려드립니다.
클라우드를 통해 비즈니스 혁신을 가속화하고 쉽고 정학하게 구현하실 수 있습니다.
[목차]
1. 클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유
2. 클라우드 마이그레이션의 기본 프로세스, 전략, 비용 절감 효과, 로드맵
3. 베스핀글로벌 구축 사례 : 오비맥주의 마이그레이션 사례 공유
designing, implementing and delivering microservices with event storming, spr...uEngine Solutions
Implementing Microservices is something like an adventure. Analyzing and decomposing microservices with applying DDD and make them into code, all is not easy. With new simple approach - Event storming, designing and implementing an event-driven MSA became easier ever seen before.
Taeyo.NET & ASP.NET Korea 2018 세미나 'Show me the code' 세션 슬라이드
슬라이드 원본 다운로드: https://1drv.ms/p/s!ArHM66R5MeWxgoA-Ntbq7mne1AARMQ
소스코드: https://github.com/Reacture/FoxOffice
GDG Korea Android Conference(2015년 4월 18일)의 "네이티브 크로스 플랫폼 개발 도구, Xamarin Forms를 사용한 MVVM 패턴과 테스팅" 세션 슬라이드입니다.
데모에 사용된 소스코드는 여기에 있습니다.
https://github.com/gyuwon/xforms-user-manager
Reactive Model-View-ViewModel ArchitectureGyuwon Yi
컨텐츠 중심의 모바일 서비스 응용프로그램을 개발하기 위해 MVVM(Model-View-ViewModel) 패턴과 Rx(Reactive Extensions)를 활용해 설계한 Reactive MVVM 아키텍쳐를 설명합니다. 조금 더 자세한 설명은 블로그 포스트를 참고하세요. https://justhackem.wordpress.com/2015/03/19/rmvvm-architecture/
4. 설계는 결과
• 나는 JOIN 구문을 싫어하지 않음
• 나는 관계형 데이터베이스도 싫어하지 않음
• 데이터베이스 선택은 설계
• 설계의 목적은 도메인 요구사항
5. 새로운 설계 기법을 익히는 것은
• 기존 설계 기법을 배척하기 위함이 아님
• 도메인 요구사항을 만족시키기 위한 선택지를 늘리는 것
6. 기본 설계 원칙
• 높은 응집(High Cohesion)
• 낮은 결함(Low Coupling)
• 정보 숨김(Information Hiding)
7. 오마이랩 기술 팀 소개
• CTO 포함 프로그래머 4인
• 시니어 2인/ 주니어 2인(신입 1인)
• 글로벌 Multitenant 호텔 상품 관리 서비스 개발 중
• Multitenant 서비스 개발 경험자 없음
• 제품 관리자(Product Manager) 없음
• 디자이너 없음
• 거대 경쟁사들
• 경영진의 빠른 출시 요구
• Startup이 아님
9. 시스템 설계 요구사항
• 메시지 중심(Message-Driven)
• 다중입주(Multitenancy)
• 구독 모델(Subscription Business Model)
• 확장성(Scalability)
• 엄격한 인증 및 권한부여(Authentication and Authorization)
• 높은 반응성(Responsive)
• 다중 지역 배치(Multi-region Deployment)
• 감사 기록(Audit Log)
• 무중단(No Downtime)
11. 모놀리스(Monolith)
• 하나의 응용프로그램
• 하나의 데이터베이스
• 단순한 구조
• 만들기 쉬움
• 이해하기 쉬움
• 코드가 결합되기 쉬움
• 심각하지만 견딜만 함
• 데이터가 결합되기 쉬움
• 기능을 변경하거나 추가하기 여러움
• 매우 심각함
12. 사용자 관리
• 사용자 정보가 다른 기능과 결합되면 설계 변경이 어려움
• 직접 경험
• 적지 않은 간접 경험
• 다중입주를 위한 권한관리 기능을 분리하면 설계와 운영에 도움
• IAM(Identity and Access Management, IAM) 기능을 독립된 구성요소로 분리
13. 구독 모델
• 구독 모델은 ‘채널 관리자’보다는 ‘클라우드 서비스’와 관련
• 구독 수준에 따른 서비스 접근 관리
• 과금 청구
• 회계 시스템 연동
• 서비스 입주자(Tenant)의 구독에 따른 접근 관리가 핵심
• 서비스(채널 관리자)에 혼합되면 설계 복잡도와 변경 비용이 상승
• 서비스 구독 관리 기능을 독립된 구성요소로 분리
14. API Gateways
• 3개의 UI 응용프로그램
• 호텔 운영자 응용프로그램
• 채널 운영자 응용프로그램
• 내부 관리자 응용프로그램
• 시스템 통합(System Integration) 목적의 공개 API
• 사용자 및 입주자에 따른 서비스 접근 관리
19. 채널 관리자 – 채널 간 시스템 통합
질의에 의한 통합
• 채널이 채널 관리자에게
• “재고가 몇 개야?”
이벤트에 의한 통합
• 채널 관리자가 채널에게
• “재고가 n개로 변경되었어.”
20. Azure Event Hubs
• 실시간 대용량 데이터 스트림 서비스
• 소비자 그룹(Consumer Groups)
• 발행/ 구독 패턴
• 서비스 간 약한 결합
• 메시지 분할(Partitions)
• 분할 키
• 하나의 분할에 대해 하나의 소비자 그룹은 동시에 최대 하나의 처리기 등록 가능
• 메시지 순서 관리
• 동시성 처리
• 메시지 처리자 수평 규모 확장 고려
• 메시지 보존(Capture)
• Azure Blob Storage/ Azure Data Lake Store
• Apache Avro 구조
21. Service B
Service A
소비자 그룹과 분할
Instance
Instance
Instance
Instance
Instance
Partition 1
Partition 2
Partition 3
Partitioning
ConsumerGroupAConsumerGroupB
ScaleScale
23. 이벤트에 의한 외부 서비스 통합
Event
Publisher
Service
Service
Service
Service
Message
Broker
Service
Services Service
External
Service
External
Service
External
Service
Event Message
25. 안정적인 이벤트 발행
• 이벤트 수신자(채널) 장애 상황 고려
• 비동기(Asynchronous)
• 최소 일 회 배달(At-Least-Once Delivery)
26. 이벤트 소싱(Event Sourcing)
• 도메인에서 발생하는 모든 이벤트를 기록
• 동사(이벤트 이름) + 명사(이벤트 속성)
• 상태는 일련의 이벤트의 결과
• 특정 시점의 상태를 복원 가능
• 임피던스 불일치(Impedance Mismatch)가 존재하지 않음
• 최소 일 회 배달 구현 용이
• 가장 신뢰할 수 있는 감사 기록
• 이벤트 저장소
27. Azure Table Storage
• NoSQL 키-값 저장소
• 단순한 구조
• 데이터 분할(Partitioning)
• 높은 성능
• 상대적으로 저렴한 비용
• 최대 500TiB 테이블 크기
• 최대 1MiB 엔터티 크기
28. Azure SQL Database
• Database as a Service
• DTU
• 4TB maximum storage
• Singleton/ Elastic Pool
• Monitoring and Tuning
29. 이벤트 저장소
Azure Table Storage
• 500TiB
• 높은 가격 대 성능 비
• 키-값
• 키: {object-type}*{object-id}*{version}
• 값: 이벤트 데이터
• 우선 고려 대상
SQL Database
• 4TB
• 개체 속성에 Unique Index 적용
• 사용자 계정
• Username
• Email
• Unique Index가 정말로 필요한가?
30. 롤링 스냅샷(Rolling Snapshot)
• 역사가 긴(많은 이벤트를 가진) 집합체
• 개체 복원 성능을 높이기 위해 주기적으로 최근의 상태를 저장
• Memento Pattern
Event 3
Event 2
Event 1
…
Σ(i=1, N–2) Event i
Event N
Event N-1
Event N-2
Snapshot
31. 롤링 스냅샷 저장소
• 키-값
• 키: {object-id}
• 값
• 버전
• 직렬화 된 개체 상태
• Azure Blob Storage
33. CQRS(Command and Query Responsibility Segregation)
• 상태 변경 책임과 상태 질의 책임을 분리하는 설계 기법
• 책임을 분리하는 수준은 다양함
• 개체
• 도메인 논리
• 데이터베이스
• 서비스
• 이벤트 소싱
• 이벤트 소싱은 질의 기능에 대한 다양한 비즈니스 요구를 충족하지 못함
• 데이터베이스 이상 수준의 CQRS 조합이 사실상 필수
34. 채널 관리자 인벤토리 그리드(Inventory Grid)
• 지정한 기간 내 다수 엔터티의 상태를 한 번에 표시
• 2~4주 시간 범위(Time Window)
• 각 엔터티는 일 별 데이터를 포함
• 엔터티는 십 여 개에서 최대 천 개 이상도 가능
35. 채널 관리자 인벤토리 그리드(Inventory Grid)
Date Date Date Date Date Date Date Date Date Date
RoomType
RoomType
RoomRate
RoomRate
RoomRate
Channel
Channel
Channel
Channel
36. 인벤토리 그리드 전통적 데이터 설계
• 전통적 방식에서 데이터의 물리적 배치 기준은 엔터티
• 상태를 변경하는 작업에 유리
• 하나의 엔터티에 포함된 일 별 데이터는 다양한 속성을 공유
• 인벤토리 그리드 질의 기능에 불리
• 다수의 엔터티
• 물리적으로 분산된 데이터를 조회
• 관계형 데이터베이스를 사용할 경우 무거운 JOIN 구문 실행
37. 엔터티 단위 인벤토리 분리
Date Date Date Date Date Date Date Date Date Date
RoomType
RoomType
RoomRate
RoomRate
RoomRate
Channel
Channel
Channel
Channel
38. 인벤토리 그리드와 CQRS
Command Side
• 변경 작업 기준의 데이터 분리
• 집합체(Aggregate)
Query Side
• 1개월 단위 패키지
• 키-값
• 키: {tenant-id}*{year}*{month}
• 값: 직렬화 된 그리드 데이터
39. 월 단위 인벤토리 읽기 모델 분리
Date Date Date Date Date Date Date Date Date Date
RoomType
RoomType
RoomRate
RoomRate
RoomRate
Channel
Channel
Channel
Channel
Key-Value Key-Value
40. 낙관적 명령 검사와 낙관적 갱신
• 최종 일관성(Eventual Consistency)
• 읽기 데이터베이스 완전 신뢰 불가
• 읽기 데이터베이스 기준의 낙관적 명령 유효성 검사
• 클라이언트는 낙관적 명령 검사 결과 기준의 낙관적 뷰 갱신
• 확장성, 반응성, 복원성, 일관성 등 중 어떤 가치가 더 중요한 지
도메인 기준으로 판단
41. CQRS와 비동기 분산 명령 프로세스
UI
Read Model
Generator
Message BusAPI
Read Model
Database
Command
Processor
Event Store
Validate Command
Optimistically
Command
Command
Acceptance
Command Command
Raise Event
Update
Update View
Optimistically
1
2
4
5
3 6
7
8
45. 전역 트래픽 지연 최소화
• 코드 다중 지역 배치
• Azure Traffic Manager
• 위성 지역 명령 전달자
• 위성 지역 데이터 배치
• 데이터 읽기 지연 최소화
• 낙관적 명령 유효성 검사
46. 다중 지역 배치
Hub Region
Message Bus
Domain Model
Read Model
Satellite Region A
API
Command Forwarder
Read Database Replica
Satellite Region B
API
Command Forwarder
Read Database ReplicaReplicate Replicate
Commands Commands
47. Azure Cosmos DB
• 턴키 전역 배포(Turnkey Global Distribution)
• 다중 모델 API
SQL API, MongoDB API, Casandra API, Graph API, Table API and more …
• 쉬운 수평 규모 확장(Horizontal Scale)
• 데이터 분할(Partitioning)
• 컨테이너 별 과금
• 최대 2 MB SQL API 문서 크기
48. 전역 배치 비동기 분산 명령 프로세스
Command Forwarder
<< Service Bus >>
Message Broker
<< Event Hub >>
Processors
<< App Services >>
Event Store
<< Table Storage, SQL Database >>
Read Database
<< Cosmos DB >>
Read Database Replica
<< Cosmos DB >>
API
<< API App >>
UI(SPA)
<< Web App >>
Load Balancer
<< Traffic Manager >>
Satellite Region Hub Region
Validate Command
Optimistically
Replicate
Update Read Model
Command AcceptanceCommand
Update View Optimistically
1
2
3
4
5
6
7 8
9
10
11