Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Partner TechShift] 클라우드 사업을 위한 3가지 소프트웨어 딜리버리 전략

1,503 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[Partner TechShift] 클라우드 사업을 위한 3가지 소프트웨어 딜리버리 전략

  1. 1. 클라우드 사업을 위한 3가지 소프트웨어 딜리버리 전략 김용우 솔루션스 아키텍트, Amazon Web Services
  2. 2. Software moves faster today
  3. 3. 다양한 S/W 배포방식
  4. 4. Software 배포(판매) , 어떻게 할 것인가? PKG S/W 맞춤형 구축(SI) Cloud SaaS 맞춤형 구축(SI) On-premise Amazon AMI PKG S/W OnlineOnsite Offline Online
  5. 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. 6. 간단한 S/W 배포방법 – AMI 공유 개발사 고객A
  7. 7. AWS CloudFormation 구성요소 템플릿 CloudFormation 서비스 스택 JSON/YAML 형식의 파일 파라미터 값 정의 생성 인프라 자원 정의 실제 구성 액션 구성된 AWS 서비스 포괄적인 AWS 서비스(제품) 지원 스택 구성요소 변경 가능 프레임 워크 Stack 생성 Stack 업데이트 에러감지 및 롤백
  8. 8. 보다 복잡한 소프트웨어 배포 – CloudFormation S/W를 포함한 전체 인프라 스택 자동 구성 Infrastructure as a Code (JSON or YAML)
  9. 9. CLOUDFORMATION TEMPLATE AWS CloudFormation 생성/배포 환경
  10. 10. Magento on AWS 예시 AWS QuickStart
  11. 11. 고객에게 직접 전달 (CF Template Link) Public Private CloudFormation 템플릿(Software) 배포(판매) 방식 QuickStart
  12. 12. 계획 요구사항 분석 설계 개발/구축 테스팅 유지보수 S/W 개발 및 배포 방식의 변화 최근 Web 기반 서비스 개발/운영 트렌드 데브 옵스 Dev Ops 전통적인 S/W 개발 흐름
  13. 13. 고객사 요구사항 추가/변경시 배포까지 자동화 하는 방법? https://www.flickr.com/photos/jurvetson/5201796697/
  14. 14. DevOps의 주요 구성요소  지속적 통합 (Continuous Integration)  배포 자동화 (Continuous Delivery & Deployment)
  15. 15. AWS 코드 시리즈 AWS CodePipeline AWS CodeCommit AWS CodeBuildAWS CodeDeploy AWS CodeStar
  16. 16. 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
  17. 17. AWS Code Pipeline 구성 Test 선택 Build 선택 Deploy 선택 Source 선택
  18. 18. 개발사 고객 A Pipeline 고객 B Pipeline 고객 C Pipeline 완성 (SW+환경) 피드백 테스트 S/W 개발 구성 테스트 운영 구성 테스트 운영 구성 테스트 운영 설계 Design Continuous Delivery via CodePipeline 템플릿 파라미터
  19. 19. SaaS 모델
  20. 20. SaaS의 주요 구성 요소 테넌트/Identity 관리 빌링/미터링 관리 및 모니터링 분석 확장성/가용성 스토리지 파티셔닝 배포 자동화 민첩성 SaaS
  21. 21. 멀티 테넌트 패턴 Tenant Tenant Tenant Tenant Tenant TenantTenant TenantTenantTenant TenantTenantTenant 단독구성 혼합(Hybrid) 풀(Pool) 방식
  22. 22. 테넌트 파티셔닝에 따른 장/단점 Silo 모델 Pool 모델 • 법규/규제에 대한 대응 용이 • 나뉘어진(Partitioned) 환경 • 테넌트 별 영향도 최소화 • 테넌트 별 튜닝 가능 • 테넌트 레벨 가용성 • 비용 (중복, 잉여 자원) • 민첩성 감소 • 관리의 복잡성 증대 • 분석/미터링 통합 이 어려움 • 민첩성 향상 • 비용 최적화 • 중앙 집중형 관리 • 보다 손 쉬운 구성 • 분석/미터링 통합 • 테넌트 영향 발생가능(자원 고갈 등) • 법규/규제상 지원 불가한 경우 발생가능 • 단일 가용성 (문제 발생시 다수 테넌트 영향) 장점 단점 장점 단점
  23. 23. SaaS 레퍼런스 아키텍쳐 신원(Identity) 테넌트 분리 데이터 분리 관리및모니터링 프로파일링및분석 미터링,빌링,테넌트관리 운영 관점 어플리케이션관점 기술/ 비즈니스 민첩성
  24. 24. SaaS Identity: Beyond the Front Door 테넌트 컨텍스트 관리 보안 및 분리 Tenant Access 테넌트 프로비저닝
  25. 25. 신규 테넌트(고객) 가입 신규 테넌트 가입 (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
  26. 26. SaaS 신원 관리 흐름 Web Application Tenant Identity Broker Identity Provider Multi-Factor Authentication AWS Cloud IAM Policy UserID: bob@abc.com TenantID: “93194942” Role: “Admin”
  27. 27. IAM Policy를 통해 테넌트의 접근 범위 설정 Web Tier App Tier Tenant1 접근 정책 고객 테이블 Tenant2 접근 정책 T1-버킷 T2-버킷
  28. 28. 특정 테넌트에 대한 컨텍스트 관리 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
  29. 29. 테넌트 분리 계층기반 분리 App Tier Web Tier App Tier 전체 스택 분리 네트워크 기반 분리
  30. 30. EC2 전체 스택 분리 컨테이너를 통한 분리 Container 인스턴스 Container 인스턴스 Container 인스턴스 Container 인스턴스 Tenant 1 Tenant 2 Tenant 1 Web Tier App Tier Tenant 2 테넌트 온 보딩, 빌링, 프로비져닝, 라우팅 Web Tier App Tier 전체 스택 분리
  31. 31. 계정 분리 테넌트 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 테넌트 온 보딩, 빌링, 프로비져닝, 라우팅
  32. 32. 단일 및 멀티 테넌트 모델의 혼용 Web Tier App Tier Tenant 1 Web Tier App Tier Tenant 2 Web Tier Tenants 3 … N (multi-tenant shared) App Tier 하이브리드 분리
  33. 33. 네트워크 기반 분리 Web Tier App Tier Web Tier App Tier Tenant 1 Tenant 2 T2– App SubnetT1 – App Subnet T2 – Web SubnetT1 – Web Subnet VPC 파티셔닝 서브넷 파티셔닝
  34. 34. 계층(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
  35. 35. Serverless SaaS REST API 정적 Web 컨텐트 AWS Lambda Functions Amazon CloudFront Storage Services  자원의 소비 효율성 향상  확장구성의 단순화  장애 대응성 향상  빠른 테넌트 온 보딩/프로비져닝  API 관리와 실행을 분리 주요 특징
  36. 36. Compute 파티셔닝 고려사항 • 모든 테넌트가 독립 환경을 가져야할 필요는 없음 • 풀 모델을 시작으로 요건 발생시 독립모델 추가 • 개별 테넌트에 대한 맞춤화 구성은 최대한 지양 • 서비스의 Health 및 활동 상황에 대한 통합 View 생성 • 새로운 테넌트를 프로비저닝 전에 서비스 Limit 확인/조정 • 테넌트별 자원 식별을 위해서 태깅 사용은 필수
  37. 37. 데이터 파티셔닝 테넌트 별로 개별 DB구성 테넌트 1 테넌트 2 Storage Storage 테넌트 1 테넌트 2 Schema Schema 단일 DB, 다중 스키마 Tenant Id Item Id A93-9494 239 B38-3929 3434 Schema 공유 DB, 단일 스키마
  38. 38. 멀티 테넌트 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테이블 멀티 테넌트 테이블
  39. 39. 관리 및 모니터링 S3 CloudWatch AWS Config CloudTrail TenantContext Splunk Sumologic Kibana • 테넌트 간 정책 수립 및 구성 • 테넌트 간 발생(가능)이슈를 적극적으로 파악 어플리케이션 서비스 Catalog Service Cart Service Ratings Service Tax Service
  40. 40. 테넌트 레벨 메트릭 수집 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
  41. 41. 마치며… • 파티셔닝 방안을 고려할때 서비스의 특성 및 관련규제 확인이 필요 • 스토리지는 테넌트별 데이터 분산/사용도 까지 고려해야 함 • 서비스의 안정성을 위해 테넌트별 모니터링 방안 수립은 매우 중요 • 미터링 과 다양한 메트릭 수집은 SaaS 서비스를 최적화/발전 시키는데 중요한 데이터가 됨 • 여러분이 SaaS 를 준비하신다면, 다른 SaaS서비스를 적용하시는 것을 주저하지 마세요.
  42. 42. 감사합니다.

×