연사: 김용우 | 아마존웹서비스 솔루션아키텍트

1. 클라우드 사업을 위한 3가지
소프트웨어 딜리버리 전략
김용우 솔루션스 아키텍트, Amazon Web Services

2. Software moves
faster today

3. 다양한 S/W 배포방식

4. Software 배포(판매) , 어떻게 할 것인가?
PKG S/W
맞춤형 구축(SI)
Cloud
SaaS
맞춤형 구축(SI)
On-premise
Amazon AMI
PKG S/W
OnlineOnsite
Offline Online

5. 간단한 S/W 배포방법 – AMI 공유
AWS cloud
AWS cloud
AWS cloud
AWS cloud
PKG S/W
AMI 공유
고객 A
고객 B
고객 C
고객 D
AMI – Amazon Machine Image

6. 간단한 S/W 배포방법 – AMI 공유
개발사 고객A

7. AWS CloudFormation 구성요소
템플릿 CloudFormation 서비스 스택
JSON/YAML 형식의 파일
파라미터 값 정의
생성 인프라 자원 정의
실제 구성 액션
구성된 AWS 서비스
포괄적인 AWS 서비스(제품)
지원
스택 구성요소 변경 가능
프레임 워크
Stack 생성
Stack 업데이트
에러감지 및 롤백

8. 보다 복잡한 소프트웨어 배포 – CloudFormation
S/W를 포함한 전체 인프라 스택 자동 구성
Infrastructure as a Code (JSON or YAML)

9. CLOUDFORMATION
TEMPLATE
AWS CloudFormation 생성/배포 환경

10. Magento on AWS 예시
AWS QuickStart

12. 고객에게 직접 전달
(CF Template Link)
Public Private
CloudFormation 템플릿(Software) 배포(판매) 방식
QuickStart

13. 계획 요구사항 분석 설계 개발/구축 테스팅 유지보수
S/W 개발 및 배포 방식의 변화
최근 Web 기반 서비스 개발/운영 트렌드
데브 옵스
Dev Ops
전통적인 S/W 개발 흐름

14. 고객사 요구사항 추가/변경시
배포까지 자동화 하는 방법?
https://www.flickr.com/photos/jurvetson/5201796697/

15. DevOps의 주요 구성요소
 지속적 통합 (Continuous Integration)
 배포 자동화 (Continuous Delivery & Deployment)

16. AWS 코드 시리즈
AWS CodePipeline AWS CodeCommit AWS CodeBuildAWS CodeDeploy
AWS CodeStar

17. AWS 코드 서비스를 이용한 배포 Pipeline 구성
Auto Scaling group
Availability Zone
security
group
Security group
root volume
data volume
app
server
승인/검증 CloudFormation
(기본환경 구성)
CodeBuild
CodePipeline
CodeCommit
개발팀
Git Push
Git Pull
CodeDeploy

18. AWS Code Pipeline 구성
Test
선택
Build
선택
Deploy
선택
Source
선택

19. 개발사
고객 A Pipeline
고객 B Pipeline
고객 C Pipeline
완성
(SW+환경)
피드백
테스트
S/W
개발
구성 테스트 운영
구성 테스트 운영
구성 테스트 운영
설계
Design
Continuous Delivery via CodePipeline
템플릿 파라미터

20. SaaS 모델

21. SaaS의 주요 구성 요소
테넌트/Identity
관리
빌링/미터링
관리 및 모니터링
분석
확장성/가용성
스토리지 파티셔닝
배포 자동화
민첩성
SaaS

22. 멀티 테넌트 패턴
Tenant Tenant
Tenant Tenant
Tenant TenantTenant
TenantTenantTenant
TenantTenantTenant
단독구성 혼합(Hybrid) 풀(Pool) 방식

23. 테넌트 파티셔닝에 따른 장/단점
Silo 모델 Pool 모델
• 법규/규제에 대한 대응 용이
• 나뉘어진(Partitioned) 환경
• 테넌트 별 영향도 최소화
• 테넌트 별 튜닝 가능
• 테넌트 레벨 가용성
• 비용 (중복, 잉여 자원)
• 민첩성 감소
• 관리의 복잡성 증대
• 분석/미터링 통합 이 어려움
• 민첩성 향상
• 비용 최적화
• 중앙 집중형 관리
• 보다 손 쉬운 구성
• 분석/미터링 통합
• 테넌트 영향 발생가능(자원 고갈 등)
• 법규/규제상 지원 불가한 경우 발생가능
• 단일 가용성 (문제 발생시 다수 테넌트 영향)
장점
단점
장점
단점

24. SaaS 레퍼런스 아키텍쳐
신원(Identity)
테넌트 분리
데이터 분리
관리및모니터링
프로파일링및분석
미터링,빌링,테넌트관리
운영 관점
어플리케이션관점
기술/ 비즈니스 민첩성

25. SaaS Identity: Beyond the Front Door
테넌트
컨텍스트 관리
보안 및
분리
Tenant
Access
테넌트
프로비저닝

26. 신규 테넌트(고객) 가입
신규 테넌트 가입
(Subscription)
Tenant
Identity Broker Identity Provider
테넌트 관리 빌링
• User: bob@test.com
• TenantID: 491048735
• TenantID: 491048735
• Domain: tenant1.abc.com
• Tier: Platinum
• Status: Active
Domain
Provisioning
SSL
Certificate
Tenant
IAM Policy
User Identity + Tenant Identity = SaaS Identity

27. SaaS 신원 관리 흐름
Web
Application
Tenant
Identity
Broker
Identity Provider
Multi-Factor
Authentication
AWS Cloud
IAM Policy
UserID: bob@abc.com
TenantID: “93194942”
Role: “Admin”

28. IAM Policy를 통해 테넌트의 접근 범위 설정
Web Tier
App Tier
Tenant1
접근 정책
고객 테이블
Tenant2
접근 정책
T1-버킷 T2-버킷

29. 특정 테넌트에 대한 컨텍스트 관리
Tenant
Access Control
Homepage
Access Control
Catalog Service
Access Control
Cart Service
TenantContext
{
UserID: “bob@abc.com”
Role: “Admin”,
TenantID: “93194942”
}
JWT Token
Authorization: Bearer<JWT>
Authorization: Bearer<JWT>
Authorization: Bearer<JWT>
Access Control
Auth ServiceTenant Service

30. 테넌트 분리
계층기반 분리
App Tier
Web Tier
App Tier
전체 스택 분리 네트워크 기반 분리

31. EC2 전체 스택 분리 컨테이너를 통한 분리
Container
인스턴스
Container
인스턴스
Container
인스턴스
Container
인스턴스
Tenant 1 Tenant 2
Tenant 1
Web Tier
App Tier
Tenant 2
테넌트 온 보딩, 빌링, 프로비져닝, 라우팅
Web Tier
App Tier
전체 스택 분리

32. 계정 분리
테넌트 1 (AWS Account A) 테넌트 2 (AWS Account B)
Auto Scaling Group
Web Server Web Server
Auto Scaling Group
App Server App Server
Availability Zone 1
Availability Zone 2
Region
Auto Scaling Group
Web Server Web Server
Auto Scaling Group
App Server App Server
Availability Zone 1
Availability Zone 2
Region
테넌트 온 보딩, 빌링, 프로비져닝, 라우팅

33. 단일 및 멀티 테넌트 모델의 혼용
Web Tier
App Tier
Tenant 1
Web Tier
App Tier
Tenant 2
Web Tier
Tenants 3 … N
(multi-tenant shared)
App Tier
하이브리드 분리

34. 네트워크 기반 분리
Web Tier
App Tier
Web Tier
App Tier
Tenant 1 Tenant 2
T2– App SubnetT1 – App Subnet
T2 – Web SubnetT1 – Web Subnet
VPC 파티셔닝 서브넷 파티셔닝

35. 계층(Layer)기반 테넌트 분리
Billing
Administration
On-Boarding
테넌트 1 테넌트 2
Web
App
Web
App
Route 53
Web Tier
App: Tenant 1 App: Tenant 2
Billing
Administration
On-Boarding Route 53
Web Tier
Billing
Administration
On-Boarding Route 53
AppTier

36. Serverless SaaS
REST API
정적 Web 컨텐트
AWS Lambda Functions
Amazon
CloudFront
Storage Services
 자원의 소비 효율성 향상
 확장구성의 단순화
 장애 대응성 향상
 빠른 테넌트 온 보딩/프로비져닝
 API 관리와 실행을 분리
주요 특징

37. Compute 파티셔닝 고려사항
• 모든 테넌트가 독립 환경을 가져야할 필요는 없음
• 풀 모델을 시작으로 요건 발생시 독립모델 추가
• 개별 테넌트에 대한 맞춤화 구성은 최대한 지양
• 서비스의 Health 및 활동 상황에 대한 통합 View 생성
• 새로운 테넌트를 프로비저닝 전에 서비스 Limit 확인/조정
• 테넌트별 자원 식별을 위해서 태깅 사용은 필수

38. 데이터 파티셔닝
테넌트 별로
개별 DB구성
테넌트 1 테넌트 2
Storage Storage
테넌트 1
테넌트 2
Schema
Schema
단일 DB,
다중 스키마
Tenant Id Item Id
A93-9494 239
B38-3929 3434
Schema
공유 DB,
단일 스키마

39. 멀티 테넌트 RDS
테넌트 1
인스턴스
테넌트 2
인스턴스
Tenant 2
Tenant 1
Tenant 1 84049-49 True
Tenant 2 82-84-949 False
Tenant 1 Bob Smith
Tenant 2 Lisa Johnson
테넌트 ID기반으로 나뉜
테이블
개별 DB인스턴스 개별 DB테이블
멀티 테넌트
테이블

40. 관리 및 모니터링
S3
CloudWatch
AWS Config
CloudTrail
TenantContext
Splunk
Sumologic
Kibana
• 테넌트 간 정책 수립 및 구성
• 테넌트 간 발생(가능)이슈를 적극적으로 파악
어플리케이션 서비스
Catalog
Service
Cart
Service
Ratings
Service
Tax
Service

41. 테넌트 레벨 메트릭 수집
Application Flows
Service Activity
Storage Activity
Scaling Activity
…
테넌트 레벨 메트릭
Order Service Cart Service
Tenant-centric Dashboard
• 시스템 및 테넌트 레벨 메트릭을 통해 서비스 최적화
• 자원에 대한 소비를 개별 테넌트 레벨로 한정시켜야 함
Tenant1: Catalog search
Tenant4: Ship order
Tenant2: Cart update IOPS
Tenant7: Ship order
CloudWatch

42. 마치며…
• 파티셔닝 방안을 고려할때 서비스의 특성 및 관련규제 확인이 필요
• 스토리지는 테넌트별 데이터 분산/사용도 까지 고려해야 함
• 서비스의 안정성을 위해 테넌트별 모니터링 방안 수립은 매우 중요
• 미터링 과 다양한 메트릭 수집은 SaaS 서비스를 최적화/발전 시키는데
중요한 데이터가 됨
• 여러분이 SaaS 를 준비하신다면, 다른 SaaS서비스를 적용하시는 것을
주저하지 마세요.

43. 감사합니다.