데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인Amazon Web Services Korea
발표영상 다시보기: https://kr-resources.awscloud.com/data-databases-and-analytics/aurora-mysql-backtrack%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%B9%A0%EB%A5%B8-%EB%B3%B5%EA%B5%AC-%EB%B0%A9%EB%B2%95-%EC%A7%84%EA%B5%90%EC%84%A0-aws-database-modernization-day-%EC%98%A8%EB%9D%BC%EC%9D%B8-2
Aurora MySQL은 기존 MySQL의 운영에 추가한 많은 기능들을 제공해 드리고 있습니다. 이 중 복구에 관련된 기능인 Aurora MySQL PITR과 Backtrack에 대한 소개를 드리고자 합니다. 두 기능을 통해 운영 중 일어날 수 있는 rollback 상황에서, 어떠한 방식으로 복구를 할 수 있는지 실습해보실 수 있습니다.
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인Amazon Web Services Korea
발표영상 다시보기: https://kr-resources.awscloud.com/data-databases-and-analytics/aurora-mysql-backtrack%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%B9%A0%EB%A5%B8-%EB%B3%B5%EA%B5%AC-%EB%B0%A9%EB%B2%95-%EC%A7%84%EA%B5%90%EC%84%A0-aws-database-modernization-day-%EC%98%A8%EB%9D%BC%EC%9D%B8-2
Aurora MySQL은 기존 MySQL의 운영에 추가한 많은 기능들을 제공해 드리고 있습니다. 이 중 복구에 관련된 기능인 Aurora MySQL PITR과 Backtrack에 대한 소개를 드리고자 합니다. 두 기능을 통해 운영 중 일어날 수 있는 rollback 상황에서, 어떠한 방식으로 복구를 할 수 있는지 실습해보실 수 있습니다.
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...BESPIN GLOBAL
기존 레거시(Legacy) 시스템이 가지고 있는 변화하는 기술에 대한 빠른 대응과 비즈니스 어플리케이션 배포의 한계 등을 극복하기 위한 대안인 클라우드 도입.
클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유를 실제 사례를 통해 알려드립니다.
클라우드를 통해 비즈니스 혁신을 가속화하고 쉽고 정학하게 구현하실 수 있습니다.
[목차]
1. 클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유
2. 클라우드 마이그레이션의 기본 프로세스, 전략, 비용 절감 효과, 로드맵
3. 베스핀글로벌 구축 사례 : 오비맥주의 마이그레이션 사례 공유
AWS Lambda를 통해 서버리스 애플리케이션을 실행하는 경우, 애플리케이션 성능 문제를 효과적으로 진단하는 방법이 필요합니다. 본 세션에서는 분산 애플리케이션 성능 문제 발생 위치를 파악하고 디버깅 할 수 있는 추적 서비스인 AWS X-Ray를 소개합니다. X-Ray를 사용한 동적 스택 추적 및 디버깅, 호출에 대한 시각적 그래프를 사용하여 서버리스 애플리케이션을진단하는 방법을 설명합니다..
[AWS Summit Seoul 2017] 현재 많은 기업들이 기업 내에서 보유한 많은 인프라를 아마존 기반의 클라우드 환경으로 이관하고, 데이터센터와 클라우드를 연결한 후 시스템을 이관하는 것으로 요구하고 있습니다. 이 때 기존 시스템을 분석, 데이터 이관, 애플리케이션 이관 등의 복잡한 절차를 통해 시스템을 전환하게 됩니다.
본 발표에서는 그러한 복잡한 형태의 클라우드 이관 시 이를 분석, 전환할 수 있는 방법과 그에 대한 도구(AWS ISV 파트너 도구 및 신규 U2C 솔루션)를 소개하고 최적의 전환 방법을 설명합니다. 또한 르노삼성자동차 등의 실제 전환 고객 사례를 통해 DB 마이그레이션, 서버 마이그레이션에 대한 노하우를 들으실 수 있습니다.
회사 계정/패스워드 그대로 AWS 관리 콘솔 및 EC2 인스턴스 사용하기 - 이정훈, AWS 솔루션즈 아키텍트:: AWS Summit O...Amazon Web Services Korea
발표영상 다시보기: https://youtu.be/osSkxPm2CFA
다양한 정보보호 업무 중에 기본적인 항목이 사용자 인증 및 접근 관리입니다. 사용자 인증을 위한 아이덴티티 저장소는 매우 핵심적인 시스템으로 여러 개의 아이덴티티 시스템을 이용하는 것은 관리 부담과 보안 위험이 커질 수 있습니다. 본 세션에서는 기존의 기업 내의 아이덴티티 시스템을 이용하여 AWS의 리소스에 대한 접근 통제 방법을 포괄적으로 소개합니다.
게임 개발을 완료하고 출시 전에는 부하 테스트 과정이 필수입니다. 부하 테스트를 통해 서비스의 문제점을 미리 파악할 수 있습니다. 1부에서는 AWS 환경에서 게임 서비스에 대규모 부하를 주는 방법을 알아보겠습니다. 또한 AWS의 여러 서비스를 통해 이런 서비스 상황을 모니터링하는 방법을 알아 보겠습니다. 2부는 AWS에서 카오스 엔지니어링을 구현해보겠습니다.
[AWS & 베스핀글로벌, 바이오∙헬스케어∙제약사를 위한 세미나] AWS 101, Cloud Computing is New NormalBESPIN GLOBAL
AWS와 함께 하는 바이오 ∙ 헬스케어 ∙ 제약사를 위한 클라우드 세미나
'안전하게 클라우드로 날자'
어떻게 하면 클라우드를 통한 디지털 혁신과 비즈니스 성장을 이룰 수 있을까요?
AWS 를 통해 어떤 기업들이 혁신적인 서비스를 제공하고 있을까요?
도입 후에는 어떤 변화가 있고 어떻게 관리해야 할까요?
지난 6월 8일. AWS와 클라우드 전문가 베스핀글로벌이 바이오 · 헬스케어 · 제약 고객들만을 위해 쉽고 빠르게 클라우드를 도입할 수 있는 방법을 제시하는 세미나를 진행했습니다.
클라우드가 뭔지 궁금하지만 잘 모르겠다면, 클라우드를 도입하고는 싶지만 어디서부터 시작해야 할지 감이 오지 않으신다면, 베스핀글로벌과 상의하세요.
Amazon EKS를 위한 AWS CDK와 CDK8s 활용법 - 염지원, 김광영 AWS 솔루션즈 아키텍트 :: AWS Summit Seou...Amazon Web Services Korea
Amazon Elastic Kubernetes Service (Amazon EKS)를 통하여 오픈소스 컨테이너 오케이스트레이션 도구인 Kubernetes를 신규 도입하고자 하는 고객들이 폭발적으로 늘어나고 있습니다. AWS Cloud Development Kit (AWS CDK) 그리고 CDK8s 를 활용하여 개발자에게 친숙한 프로그래밍 언어로 Amazon EKS를 정의하고 Kubernetes 어플리케이션을 정의하는 데에 활용하는 방법을 소개하여, 새롭게 Amazon EKS를 사용해보고자 하는 고객들이 도입을 가속화할 수 있는 방법을 제시합니다.
AWS와 컴피턴시 파트너사 BSG Partners에서 준비한 “SAP on AWS: 경영혁신 플랫폼의 뉴 노멀” 온라인 세미나에서는 AWS 클라우드를 아껴주시는 SAP 고객분들께 온라인 세미나를 통해 SAP 를 AWS에 쉽고 빠르게 이관/구축 전략부터 Cloud 환경에 맞는 SAP license 정책까지 이번 세미나를 통해 제공하고 있습니다.
특히, 이번 웨비나 참석해 주시는 고객 중 SAP on AWS 도입 의사를 밝혀 주시는 고객께는 국내 유일 SAP 플래티넘 파트너이자 AWS의 SAP 컴피턴시 파트너사인 BSG Partners의 다양한 SAP 프로세스 지식과 융합한 Cloud Native Applications 적용 방안도 함께 제공하오니, 이번 온라인 세미나를 통해 SAP on AWS에 대한 새로운 지식 및 기업 내에서 Cloud Native Application 을 활용할 수 있는 다양한 아이디어를 찾으시길 바랍니다.
클라이드 네이티브 기반 Twelve Factor 앱 개발 - 윤석찬, AWS 테크에반젤리스트 :: AWS Summit Online Kore...Amazon Web Services Korea
* 발표 영상 보기: https://youtu.be/mTbS1ddjTE0
최신 애플리케이션 개발에서 만났던 문제를 해결하기 위한 12가지 원칙(Twelve Factor)을 소개하고, 클라우드 네이티브 기반으로 접목해 AWS의 솔루션을 소개합니다. 2012년 이후 최근 동향을 포함한 신규 항목과 전체를 관통하는 앱 현대화를 위한 패턴도 함께 소개합니다. 본 세션은 AWS Summit Online의 보너스 세션으로 아마존 닷컴 CTO의 기조 연설과 47개의 다양한 강연 세션을 더 보실 수 있습니다.
The document discusses data service level agreements (SLAs) in public cloud environments. It explains that achieving availability, consistency, and scalability is challenging due to Brewer's CAP theorem. It reviews strategies for relational and NoSQL databases to handle these tradeoffs, including dropping consistency or availability depending on needs. Code examples demonstrate typical operations for Cassandra, MongoDB, and Neo4J NoSQL databases. The conclusion recommends choosing solutions based on requirements and migrating to NoSQL as needed to address scaling issues.
reliability based design optimization for cloud migrationNishmitha B
reliability based design optimization for cloud migration is an application designed to manage applications..more precisely legacy applications..whose extraction n magmt. is crucial n troublesome.
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...BESPIN GLOBAL
기존 레거시(Legacy) 시스템이 가지고 있는 변화하는 기술에 대한 빠른 대응과 비즈니스 어플리케이션 배포의 한계 등을 극복하기 위한 대안인 클라우드 도입.
클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유를 실제 사례를 통해 알려드립니다.
클라우드를 통해 비즈니스 혁신을 가속화하고 쉽고 정학하게 구현하실 수 있습니다.
[목차]
1. 클라우드 국내 도입 현황과 클라우드로 마이그레이션을 해야 하는 이유
2. 클라우드 마이그레이션의 기본 프로세스, 전략, 비용 절감 효과, 로드맵
3. 베스핀글로벌 구축 사례 : 오비맥주의 마이그레이션 사례 공유
AWS Lambda를 통해 서버리스 애플리케이션을 실행하는 경우, 애플리케이션 성능 문제를 효과적으로 진단하는 방법이 필요합니다. 본 세션에서는 분산 애플리케이션 성능 문제 발생 위치를 파악하고 디버깅 할 수 있는 추적 서비스인 AWS X-Ray를 소개합니다. X-Ray를 사용한 동적 스택 추적 및 디버깅, 호출에 대한 시각적 그래프를 사용하여 서버리스 애플리케이션을진단하는 방법을 설명합니다..
[AWS Summit Seoul 2017] 현재 많은 기업들이 기업 내에서 보유한 많은 인프라를 아마존 기반의 클라우드 환경으로 이관하고, 데이터센터와 클라우드를 연결한 후 시스템을 이관하는 것으로 요구하고 있습니다. 이 때 기존 시스템을 분석, 데이터 이관, 애플리케이션 이관 등의 복잡한 절차를 통해 시스템을 전환하게 됩니다.
본 발표에서는 그러한 복잡한 형태의 클라우드 이관 시 이를 분석, 전환할 수 있는 방법과 그에 대한 도구(AWS ISV 파트너 도구 및 신규 U2C 솔루션)를 소개하고 최적의 전환 방법을 설명합니다. 또한 르노삼성자동차 등의 실제 전환 고객 사례를 통해 DB 마이그레이션, 서버 마이그레이션에 대한 노하우를 들으실 수 있습니다.
회사 계정/패스워드 그대로 AWS 관리 콘솔 및 EC2 인스턴스 사용하기 - 이정훈, AWS 솔루션즈 아키텍트:: AWS Summit O...Amazon Web Services Korea
발표영상 다시보기: https://youtu.be/osSkxPm2CFA
다양한 정보보호 업무 중에 기본적인 항목이 사용자 인증 및 접근 관리입니다. 사용자 인증을 위한 아이덴티티 저장소는 매우 핵심적인 시스템으로 여러 개의 아이덴티티 시스템을 이용하는 것은 관리 부담과 보안 위험이 커질 수 있습니다. 본 세션에서는 기존의 기업 내의 아이덴티티 시스템을 이용하여 AWS의 리소스에 대한 접근 통제 방법을 포괄적으로 소개합니다.
게임 개발을 완료하고 출시 전에는 부하 테스트 과정이 필수입니다. 부하 테스트를 통해 서비스의 문제점을 미리 파악할 수 있습니다. 1부에서는 AWS 환경에서 게임 서비스에 대규모 부하를 주는 방법을 알아보겠습니다. 또한 AWS의 여러 서비스를 통해 이런 서비스 상황을 모니터링하는 방법을 알아 보겠습니다. 2부는 AWS에서 카오스 엔지니어링을 구현해보겠습니다.
[AWS & 베스핀글로벌, 바이오∙헬스케어∙제약사를 위한 세미나] AWS 101, Cloud Computing is New NormalBESPIN GLOBAL
AWS와 함께 하는 바이오 ∙ 헬스케어 ∙ 제약사를 위한 클라우드 세미나
'안전하게 클라우드로 날자'
어떻게 하면 클라우드를 통한 디지털 혁신과 비즈니스 성장을 이룰 수 있을까요?
AWS 를 통해 어떤 기업들이 혁신적인 서비스를 제공하고 있을까요?
도입 후에는 어떤 변화가 있고 어떻게 관리해야 할까요?
지난 6월 8일. AWS와 클라우드 전문가 베스핀글로벌이 바이오 · 헬스케어 · 제약 고객들만을 위해 쉽고 빠르게 클라우드를 도입할 수 있는 방법을 제시하는 세미나를 진행했습니다.
클라우드가 뭔지 궁금하지만 잘 모르겠다면, 클라우드를 도입하고는 싶지만 어디서부터 시작해야 할지 감이 오지 않으신다면, 베스핀글로벌과 상의하세요.
Amazon EKS를 위한 AWS CDK와 CDK8s 활용법 - 염지원, 김광영 AWS 솔루션즈 아키텍트 :: AWS Summit Seou...Amazon Web Services Korea
Amazon Elastic Kubernetes Service (Amazon EKS)를 통하여 오픈소스 컨테이너 오케이스트레이션 도구인 Kubernetes를 신규 도입하고자 하는 고객들이 폭발적으로 늘어나고 있습니다. AWS Cloud Development Kit (AWS CDK) 그리고 CDK8s 를 활용하여 개발자에게 친숙한 프로그래밍 언어로 Amazon EKS를 정의하고 Kubernetes 어플리케이션을 정의하는 데에 활용하는 방법을 소개하여, 새롭게 Amazon EKS를 사용해보고자 하는 고객들이 도입을 가속화할 수 있는 방법을 제시합니다.
AWS와 컴피턴시 파트너사 BSG Partners에서 준비한 “SAP on AWS: 경영혁신 플랫폼의 뉴 노멀” 온라인 세미나에서는 AWS 클라우드를 아껴주시는 SAP 고객분들께 온라인 세미나를 통해 SAP 를 AWS에 쉽고 빠르게 이관/구축 전략부터 Cloud 환경에 맞는 SAP license 정책까지 이번 세미나를 통해 제공하고 있습니다.
특히, 이번 웨비나 참석해 주시는 고객 중 SAP on AWS 도입 의사를 밝혀 주시는 고객께는 국내 유일 SAP 플래티넘 파트너이자 AWS의 SAP 컴피턴시 파트너사인 BSG Partners의 다양한 SAP 프로세스 지식과 융합한 Cloud Native Applications 적용 방안도 함께 제공하오니, 이번 온라인 세미나를 통해 SAP on AWS에 대한 새로운 지식 및 기업 내에서 Cloud Native Application 을 활용할 수 있는 다양한 아이디어를 찾으시길 바랍니다.
클라이드 네이티브 기반 Twelve Factor 앱 개발 - 윤석찬, AWS 테크에반젤리스트 :: AWS Summit Online Kore...Amazon Web Services Korea
* 발표 영상 보기: https://youtu.be/mTbS1ddjTE0
최신 애플리케이션 개발에서 만났던 문제를 해결하기 위한 12가지 원칙(Twelve Factor)을 소개하고, 클라우드 네이티브 기반으로 접목해 AWS의 솔루션을 소개합니다. 2012년 이후 최근 동향을 포함한 신규 항목과 전체를 관통하는 앱 현대화를 위한 패턴도 함께 소개합니다. 본 세션은 AWS Summit Online의 보너스 세션으로 아마존 닷컴 CTO의 기조 연설과 47개의 다양한 강연 세션을 더 보실 수 있습니다.
The document discusses data service level agreements (SLAs) in public cloud environments. It explains that achieving availability, consistency, and scalability is challenging due to Brewer's CAP theorem. It reviews strategies for relational and NoSQL databases to handle these tradeoffs, including dropping consistency or availability depending on needs. Code examples demonstrate typical operations for Cassandra, MongoDB, and Neo4J NoSQL databases. The conclusion recommends choosing solutions based on requirements and migrating to NoSQL as needed to address scaling issues.
reliability based design optimization for cloud migrationNishmitha B
reliability based design optimization for cloud migration is an application designed to manage applications..more precisely legacy applications..whose extraction n magmt. is crucial n troublesome.
This document discusses metrics that can be used at various phases of the product development process, including code metrics during development, test addition metrics, test execution metrics, test coverage metrics, stability trends, prediction metrics, and bug metrics. The metrics are intended to provide objective indicators of product quality, check progress, aid decisions about phase exits/entries, and trigger actions for improvement. Key metrics discussed include code complexity, test coverage, bug trends, and achieving a goal of zero open bugs for release.
SLACC is a decision support system that aims to help cloud providers and users negotiate service level agreements (SLAs) by estimating key performance indicators (KPIs) and service level objectives (SLOs). It analyzes historical data and information about a provider's IT infrastructure to evaluate what levels of availability, response time, and other parameters a provider can likely offer or accept. The system is intended to enhance SLA specificity and support negotiation processes without directly interfering with existing cloud architectures.
The Path To Cloud - an Infograph on Cloud MigrationInApp
Public cloud use makes up 18% of cloud adoption, while private cloud accounts for 71% and hybrid models 6%. On average, cloud users leverage 1.5 public clouds and 1.7 private clouds, and are experimenting with 1.5 additional public clouds and 1.3 private clouds. Security is no longer the top cloud challenge, replaced by concerns about reliability, tech support, price, and reputation. The document is an infographic from InApp summarizing trends in cloud adoption from surveys by Right Scale and Amazon.
Innovation with Open Source: The New South Wales Judicial Commission experienceLinuxmalaysia Malaysia
Innovation with Open Source: The New South Wales Judicial Commission experience. MyGOSSCON 2008. Mr. Murali Sagi
Director,
Information Management & Corporate Services,
JUDICIAL COMMISSION OF NSW, SYDNEY, AUSTRALIA
5 Cloud Migration Experiences Not to Be RepeatedHostway|HOSTING
This document summarizes key lessons learned from cloud migration experiences that should be avoided. It discusses developing realistic project scopes that allow time for discovery and testing. Managing timelines carefully by estimating data transfer times and allowing ample testing periods is important. Avoiding security risks requires reviewing firewalls, intrusion detection, and compliance. Thorough testing that runs the test plan at least three times is crucial. Finally, clear communication of roles, access, expectations for maintenance windows and cutovers is needed.
Massimiliano Raks, Naples University on SPECS: Secure provisioning of cloud s...SLA-Ready Network
The cloud is both a risk and an opportunity depending on the service. Despite the opportunities, security is a top concern for a growing number of cloud service customers, and rightfully so. A key challenge is representing security and measuring it in a service level agreement? How can a cloud service provider grant the security level? And how can a cloud service customer automatically enforce it?
Prof. Massimiliano Raks, University of Naples, talks us through Security Service Level Agreement (SecureSLAs), looking at
Security SLA Negotiation, Security SLA (Automatic) Enforcement and Security SLA Continuous Monitoring with the SPECS platform for SecSLAs.
Forecast 2014 Keynote: State of Cloud Migration…What's Occurring Now, and Wha...Open Data Center Alliance
While public cloud computing continues to mature as a technology, those in charge of public cloud solutions within enterprises adopt the technology at their own pace, and for their own reasons. Indeed, they are all on separate journeys, but with many of the same business objectives. In order to determine the progress of enterprises’ journey to the public cloud, Gigaom created a survey designed to understanding what is happening within enterprises that are adopting public cloud computing.
Key items discovered in this survey include:
1. The use of public cloud computing is quickly expanding, and most organizations already exploit public cloud-based resources to run both critical and non-critical business systems.
2. Application development and testing are among the highest value uses of leveraging the public cloud, and most enterprises have moved from proof of concept to actual deployments in the last few years.
3. A larger number of business units leverage public cloud resources that are made up largely of AWS and a few other public cloud providers.
4. A surprising number of public cloud instances support the daily operations of many businesses, with a smaller percentage emerging as heavy users that leverage a massive amount of public cloud resources.
5. First cloud projects are a thing of the past, with most working on their second, third, or more major cloud deployments.
6. Change management and cloud governance are becoming more commonplace and accepted by enterprises.
In this lunchtime keynote presentation, David Linthicum provides a look at what’s occurring right now as enterprises move to public clouds using real data from real adopters. What’s more, Linthicum will provide predictions around what is likely to occur in the world of cloud computing in 2015 and 2016, as well as recommendations around how you can exploit changes and growth of cloud-based platforms to your own best advantage.
1) e-Zest's SLA Tracker (CWX) monitors application, platform, and infrastructure performance metrics in real-time for customers using Amazon AWS CloudWatch.
2) CWX defines application-level SLAs through an XML configuration and sends alerts by email and SMS when SLAs are breached to avoid heavy penalties.
3) The tool provides dashboards for end-user experience, application performance, platform components, and infrastructure components with metrics, alerts and is more cost effective than third-party options.
Assess enterprise applications for cloud migrationnanda1505
This document describes a method for assessing which enterprise applications are suitable for migration to the cloud using the Analytic Hierarchy Process (AHP). It involves evaluating applications across three dimensions: business value, technical fitment, and risk exposure. Each dimension has criteria that are organized hierarchically. The AHP method assigns numerical priorities to the criteria based on their relative importance. It then compares applications against the criteria to calculate an overall AHP score, which can help determine if an application is suitable for the cloud.
This document discusses measuring quality for JIRA Cloud releases. It begins with principles for metrics, including starting with questions to answer, collecting metrics to drive decisions rather than as an end, and being willing to discard metrics. It then discusses context around JIRA Cloud and challenges in measuring its quality. Specific metrics proposed include number of incidents and support cases per release. The document advocates learning from measurements by focusing on prevention initiatives rather than just root causes. It emphasizes continuous improvement through metrics.
This document discusses cloud computing and provides definitions, layers, architectures, and processes related to cloud computing. It begins with definitions of cloud computing and discusses how it gets its name from the internet symbol of a cloud. It then covers layers of cloud computing including software, platform, and infrastructure as services. Main cloud processes like migration and virtualization are described. The document presents an agenda and table of contents to guide the discussion.
Planning for a (Mostly) Hassle-Free Cloud Migration | VTUG 2016 Winter WarmerJoe Conlin
There is no "one right way" when it comes to a cloud migration or cloud transformation, and in this 2016 VTUG talk I explore some of the methods that have proven successful in my experience.
SLAs in Virtualized Cloud Computing Infrastructures with QoS Assurancetcucinotta
Cloud Computing is gaining momentum as one of the technologies that promises to subvert our own idea of computing. With an increasing usage of cloud applications and their consequent dependency from connectivity, the nowadays Personal Computer is becoming merely a mobile device acting as a front-end to on-line applications and services. This huge paradigm shift in computing is witnessed for example by big market players who announced the imminent launch of innovative products and Operating Systems (like Chrome notebooks and the accompanying Chrome OS2. by Google), which are capable of projecting the user into the network in a few seconds by booting and starting immediately a web browser and (mostly) nothing else. In such a challenging scenario, more and more of the applications that we traditionally used locally on our PC are being hosted on cloud infrastructures and operated remotely through the Internet. This includes not only batch tasks, but also interactive applications which need to operate inherently with good levels of responsiveness.
In this paper, the challenging problem is discussed of how to ensure predictable levels of Quality of Service (QoS) to cloud applications across the multiple layers of a typical cloud infrastructure, and how a reasonable Service Level Agreement (SLA) management and enforcement policy might look like. The scope of this paper represents a hands-on experience that was gained by the authors realising the IRMOS real-time cloud-computing infrastructure in the context of the IRMOS European Project
Outsourcing SLA versus Cloud SLA by Jurian BurgersITpreneurs
1. There are seven key topics to consider when drafting a cloud computing service level agreement (SLA) compared to a regular outsourcing SLA: chain liability, contract duration, exit strategy, security, sharing resources, internet dependability, and financial model.
2. The cloud SLA should address liability if the cloud service provider subcontracts work and limit the provider's responsibility. It also needs flexibility in contract duration and a clear exit strategy for returning data.
3. The cloud SLA must require evidence of security standards and controls for access, backups, and data integrity. It should also define how multi-tenant access is controlled.
4. The SLA needs clarity on responsibilities for internet connections and
Hierarchical SLA-based Service Selection for Multi-Cloud EnvironmentsSoodeh Farokhi
Cloud computing popularity is growing rapidly and consequently the number of companies offering their services in the form of Software-as-a-Service (SaaS) or Infrastructure-as-a-Service (IaaS) is increasing. The diversity and usage benefits of IaaS offers are encouraging SaaS providers to lease resources from the Cloud instead of operating their own data centers. However, the question remains for them how to, on the one hand, exploit Cloud benefits to gain less maintenance overheads and on the other hand, maximize the satisfactions of customers with a wide range of requirements. The complexity of addressing these issues prevent many SaaS providers to benefit from the Cloud infrastructures. In this paper, we propose HS4MC approach for automatic service selection by considering SLA claims of SaaS providers. The novelty of our approach lies
in the utilization of prospect theory for the service ranking that represents a natural choice for scoring of comparable services due to the users preferences. The HS4MC approach first constructs a set of SLAs based on the given accumulated SaaS provider requirements. Then, it selects a set of services that best fulfills the SLAs. We evaluate our approach in a simulated environment by comparing it with a state-of-the-art utility based algorithm. The evaluation results show that our approach selects services that more effectively satisfy the SLAs.
Autonomic SLA-driven Provisioning for Cloud Applicationsnbonvin
This document discusses challenges in deploying distributed applications on cloud infrastructure and proposes an autonomic framework called Scarce to address them. It notes that applications' components may be unevenly distributed across virtual machines with varying performance. Scarce uses autonomous agents that monitor components and make placement decisions. It employs an economic model where servers charge components rent based on resource usage, and components aim to maximize their balance of earnings and costs through actions like replication and migration. The framework also propagates service level agreements from parent to child components and automatically provisions resources to ensure performance guarantees are met under varying load. Evaluation results demonstrate its ability to adapt to changing loads and failures while maintaining scalability.
Join Catherine Roy, Director of PMO at HOSTING, and Kellen Amobi, Project Manager at HOSTING, on June 23 at 3 pm EST for Cloud Migration: Tales from the Trenches – an interactive webinar, in which they will discuss:
-Developing scopes and deadlines for complex projects
-Developing realistic schedules
-How to approach and define problems for c-level and team members
안녕하세요. 이희종입니다. 한국 오라클에서 근무 하고 있습니다.
저희 팀에서는 지식 먹방이라는 방송을 Youtube 채널을 통해서 하고 있구요. 이번에 마이크로서비스라는 주제를 가지고 한번 다루어 보는 시간을 가져 보았습니다. 아직 마이크로서비스라는 단어에 대해서 생소하신 분이라면 개념을 이해하기에 좋은 자료라고 생각됩니다.
방송영상은 https://www.youtube.com/watch?v=64t4Kck6JEQ 보실 수 있습니다.
이와 더불어 오라클 클라우드 서비스 중에 하나인 Application Container Cloud Service 에 대한 내용도 포함되어 있습니다.
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.
<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
최근 들어 MSA(Micro Service Architecture)에 대한 관심이 높아지고 Amazon과 넷플릭스, 11번가 등에서 MSA를 이용하여 성과를 보이자 많은 곳에서 MSA를 이용한 프로젝트가 많아 지고 있습니다.
MSA에 대한 내용은 방대하지만, 간단한 개요만 이라도 정리하여 올립니다.
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
Similar to Cloud migration pattern using microservices (20)
2. 본 문서는 Armin Balalaie, Abbas
Heydarnoori, Pooyan Jamshidi의
“Microservices Migration
Patterns”(2015)를 요약 정리한 것입니다.
3. 차례
Cloud Migration & Pattern Meta-model
Migration and Re-architecture Patterns
Selecting and Composing Migration Patterns
Adding New Patterns to the Repository
5. Cloud Migration
5
• Microservices를 이용한 Cloud Native Application으로의 이행은 복잡하고 어려운
문제
• 시행착오와 자원의 낭비를 줄이려면 방법론 필요
• 요구사항, 현 상태, 구성원들의 역량 등을 고려하면 단일한 방법론을 정립하는
것은 어려움 Situational Method Engineering (SME) 접근법
1) Meta-model에 따라 재사용 가능한 프로세스 패턴이나 method chunk(=이행 패턴)를
패턴저장소에 저장
2) 이전의 SME 경험을 활용하고 이행 패턴을 정의함으로써 microservices로의 이행 경험과
최신의 유사한 microservices 이행 패턴을 일반화
3) 그것들을 패턴 템플릿으로 변환하여 각 부분들이 메타 모델의 요소들과 일대일 대응
• 방법론 관리자들은 이 패턴 저장소에서 선택 지침에 따라 필요한 패턴을
선택하여 그 선택된 패턴을 사용하여 맞춤형 방법론 완성
6. Pattern Meta-model
6
method chunk가 적합한
상황과 개략적인
목적에 관한 정보
method chunk가
제안하는 솔루션을
설명
프로세스 부분을
수행할 때
생성되어야 하는
산출물을 설명
• 패턴 선택 시 사용
• method chunk의 출처가 되는
방법론이나 체험보고서에 대한 참조
제공.
• method chunk가 재사용될 수 있는
상황과 재사용의 목적을 설명
7. 이행 패턴 선택 요인(factor)
7
Factor Description
Architectural
Factors
Scalability 서비스를 수평 확장(scale-out)함으로써 어플리케이션의 확장성 증가
High Availability 서비스를 복제함으로써 어플리케이션의 가용성 증가
Fault Tolerance 어플리케이션 장애 발생의 기회를 줄이고 장애를 효과적으로 처리할 수 있는 방법을 제공
Modifiability 최소한의 부작용과 최종사용자에게 영향을 미치지 않고 어플리케이션의 변경을 가능하게 함
Polyglot-ness 어플리케이션이 다른 프로그래밍 언어와 데이터 저장소를 가질 수 이게 함
Decomposition 어플리케이션을 일련의 서비스로 나누는 재구조화(Re-architecting)
Understanding 어플리케이션의 현재 상태 인지
Visioning 이행 후 어플리케이션의 최종 상태 결정
Operational
Factors
Dynamicity 최종사용자에게 영향을 주지 않고도 어플리케이션을 실행 중에 변경할 수 있음
Resource-efficiency 어플리케이션 배포에 필요한 자원 양의 감소
Deployment 어플리케이션 배포 절차를 촉진하고 배포시 예외사항 제거
Monitoring 실행시에도 어플리케이션을 효과적으로 모니터링할 수 있음
10. Microservices의 필수 구성요소
10
Service Discovery
Load Balancer
Circuit Breaker
Edge Server
• 개별 서비스는 load 분산을 위해 여러 instance 사용
• 배포된 서비스, 서비스 자체의 정확한 주소와 port 번호의 추적 관리는 매우 복잡한 작업
• Service Discovery는 각 서비스의 가용한 instance를 찾아서 사용할 수 있도록 함
• 서비스를 여러 instance에 분산하는 역할
• Service Discovery로부터 어떤 instance가 가용한지를 확인
• Cloud Native Application의 핵심 중 하나가 fault toleration
• 개별 서비스의 장애가 전체 시스템의 장애가 도지 못하도록 하여 피해가 가장 낮은
수준에서 멈추도록 완화하는 역할
• API Gateway 서버를 설치하고 API를 통해 외부로 정보/기능을 공유하도록 하는 서버
• 외부에서 내부로 들어오는 모든 트래픽을 routing해 주는 서버
• Client는 시스템 서비스의 내부 구조의 변화에 영향을 받지 않음
• 소스 코드와 설정 정보(Configuration)의 분리 설정 정보가 바뀌어도 코드 전체를 다시
배포할 필요 없음
• Configuration serve에 설정 정보 저장 서비스들이 불러올 수 있도록 함(fetch)
Configuration Server
11. [MP1] Enable Continuous Integration
11
Technology Stack
Gitlab, Artifactory, Nexus, Jenkins, GoCD, Travis, Bamboo,
Teamcity
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
• Microservices로 이행하기 위한 소프트웨어 시스템이 있고 그것을
개발/운영하는 팀이 존재
• microservices를 도입 후 수많은 서비스를 어떻게 항상 대기상태
유지?
• Continuous Delivery를 도입할 수 있도록 시스템을 준비하는 방법?
• code repository, artifact repository, Continuous Integration server
도입
• 서비스는 분리된 저장소에 : 개별 이력과 빌드 라이프 사이클 관리
• 서비스의 code repository가 변경될 때마다 서비스별 Continuous
Integration job이 자동 실행 : repository 에서 새로운 코드를
가져오고, 테스트하고, 결과물을 만들어 artifact repository 등록
• 오류 발생시 오류를 전달받은 관련팀(서비스)은 오류가 해결될
때까지 모든 작업 정지
• 새로운 변경사항은 시스템의 안정성을 깨뜨릴 수 있으므로 반드시
미리 정의된 모든 테스트를 수행
Reuse Intention Build the Continuous Integration pipeline
Reuse Situation Deployment
12. [참고] Continuous Integration이란?
12
CI(Continuous Integration : 지속적인 통합)
• 지속적으로 소프트웨어 품질 관리를 적용하는 프로세스를 실행하는 것.
• 모든 가발을 완료한 뒤에 퀄리티 컨트롤을 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의
질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점
• 초기에 그리고 자주 통합해서 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백 사이클을 짧게
하여 소프트웨어 개발의 품질과 생산성을 향상시기는 것.
13. [MP2] Recover the Current Architecture
13
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
• 현재 운영하는 소프트웨어 시스템을 microservices로 이행 결정
• 이행 계획을 세우기 위해 아키텍처 파악, 분석
• 시스템의 청사진(big picture)은 무엇인가?
• 이행계획에 필요한 high-level 정보는 충분한가?
• Component and Service Architecture
- 아키텍처를 시각화 하여 설명 이해도 향상
- 각 구성요소의 내부 도메인 상세 내역 이해
• Technology Architecture:
- 현재 Technology stack에 대한 이해 : 아키텍처/비아키텍처 기능
- 언어, DB, 미들웨어, 라이브러리 등 모두 나열
• Deployment Architecture and Procedure
- 아키텍처 이해 과정에 개발팀과 운영팀 참가 공통된 이해
- 문서화는 이행 후에
Reuse Intention Create Migration Plan initial state
Reuse Situation Understanding
14. [MP3] Decompose the Monolith
14
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
N/A
단점 (Challenge)
• 복잡한 도메인을 갖고 있는 통짜구조(monolithic) 소프트웨어
시스템 : 시스템 복잡, 영역별 별도의 비기능 요건, 변경시 전체
재배포
Reuse Intention Re-architect a System to a set of services using Domain-driven Design
Reuse Situation Polyglot-ness, Decomposition, Modifiability
• 시스템을 더 작은 단위로 분해하는 방법은 무엇인가?
• 이 단위들은 어느 정도로 커야 하는가?
• 잘못된 시스템 분해 이행 과정 중 미해결 우려 성능저하 문제
• Domain-Driven Design (DDD) 기법 사용하여 서비스로 분해
- 시스템의 초기 분해에 사용
- DDD를 하위 도메인에 적용하여 더 작은 도메인 단위로 분해
• 각 도메인은 개별 배포 단위인 Bounded Context (BC) 구성 : 1:1
대응
• BC의 크기는 시스템 요구사항에 유동적으로 구성
• 처음에는 2~3개의 서비스로 시작 시스템이 커지고 팀의
이해도가 높아진 다음에 서비스들을 추가
15. [MP4] Decompose the Monolith Based on Data Ownership
15
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
N/A
단점 (Challenge)
• 복잡한 도메인을 갖고 있는 통짜구조(monolithic) 소프트웨어
시스템 : 시스템 복잡, 영역별 별도의 비기능 요건, 변경시 전체
재배포
Reuse Intention Re-architect a System to a set of services using Data Ownership
Reuse Situation Polyglot-ness, Decomposition, Modifiability
• 시스템을 더 작은 단위로 분해하는 방법은 무엇인가?
• 이 단위들은 어느 정도로 커야 하는가?
• 도메인이 매우 커서 여러 개의 하위 도메인을 갖는 경우에는
혼란스럽고 시간을 많이 잡아먹어서 적절한 분해를 할 수 없음
• 데이터의 소유권 여부에 따라서 시스템을 분해
• 하나의 단위로 결합 가능하고 단일 소유자인 데이터 개체의 집합을
그것이 지원하는 비즈니스 로직과 묶어 패키지화 함
• 다른 서비스는 자신의 소유가 아닌 개체의 복사본만 소유 적절한
동기화 필요
• 시스템에 있는 개체(entity)의 크기와 수에 의해 결정 : 도메인이
복잡하지 않으면 4~5개 정도
개별 개체는 그 서비스를
담당하는 소유자에
의해서만 수정되거나 생성
16. [MP5] Change Code Dependency to Service Call
16
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
N/A
단점 (Challenge)
• 소프트웨어 시스템은 microservices 아키텍처 스타일을 사용할 수
있도록 일련의 작은 서비스들로 분해되어 있으나 시스템의 어떤
구성 요소는 여전히 다른 서비스나 구성요소에 의존해서 실행
Reuse Intention Transform code-level dependency to service-level dependency
Reuse Situation Decomposition, Modifiability
• 코드 수준의 의존성을 서비스 수준의 의존성으로 바꾸는 적절한
시기?
• 적절하지 않은 때는 언제인가?
• 라이브러리의 종속성을 제거하고 메서드 호출 대신 서비스 호출을
사용하는 것은 때로는 성능 문제 야기
• 가능한 서비스 코드는 별도로 유지 : 서비스간 코드 종속성 배재
• 내부 개체나 인터페이스 스키마를 공유는 금지
• 거의 변경되지 않는 공통 라이브러리로 공유되는 코드(예 : 문자열
조작 라이브러리)는 공유하는 것이 합리적
• 공유하기 어려운 기능은 서비스로 만들어 공유
17. [MP6] Introduce Service Discovery
17
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Eureka, Consul, Apache Zookeeper, etc
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• 각 서비스는 운영 환경에 하나 이상의 인스턴스가 배포
• 서비스의 인스턴스의 수는 동적으로 변경 & 다른 시스템에도 배포
가능
Reuse Intention Introduce Dynamic Location of services’ instances using Service Discovery
Reuse Situation Scalability, High Availability, Dynamicity, Deployment
• 어떻게 서비스가 각기 동적으로 자리를 잡을 수 있을까?
• Edge Server나 Load Balancer는 어떻게 서비스의 인스턴스 목록을
알 수 있을까?
• SD는 서비스간 통신의 구심점이므로 여기가 잘못되면 Single-
point-of-failure
• 서비스 인스턴스의 주소를 저장하는 Service Discovery를 설정
• 개별 서비스 스스로 Registry에 등록 : 인스턴스로부터 주기적인
신호가 없거나 종료될 때 자동으로 해당 인스턴스가 registry에서
제거
• Edge Server, Load Balancer, 타 서비스는 Service Discovery를
통해 가용한 서비스 인스턴스의 목록을 받아서 필요한 서비스를
탐색
Service Discovery는 시스템의 핵심
구성요소이자 가용성이 매우 중요
복제 전략 필요
18. [MP7] Introduce Service Discovery Client
18
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Eureka는 서버 버전용 Java 클라이언트가 설치된 Service
Discovery
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• Service Discovery 설정
• 서비스의 인스턴스의 수는 동적으로 변경 & 다른 시스템에도 배포
가능
Reuse Intention Facilitate Dynamic Location of services’ instances using Service Discovery Client
Reuse Situation Scalability, High Availability, Dynamicity, Deployment
• Service Discovery는 새로운 인스턴스가 배포되었다는 것을 어떻게
알 수 있을까?
• 인스턴스가 종료되었다는 것은 어떻게 알 수 있을까?
• 사용중인 모든 프로그래밍 언어에 대해 클라이언트를 설치해야
하며 잘못 설치하면 서비스 코드가 복잡해짐
• 개별 서비스는 Service Discovery 주소를 알아야 하고 초기화되는
동안에 registry에 자체 등록
• 개별 인스턴스에서 registry로 주기적으로 신호(heartbeat)를
보내야만 사용가능한 인스턴스 목록에 계속 유지
• 종료 : 신호를 보내지 않거나 registry에 인스턴스 종료를 알림
서비스마다 클라이언트 설치
서비스를 자체 등록하고
Registry에 계속 신호 보냄
19. [MP8] Introduce Internal Load Balancer
19
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Ribbon은 Service Discovery인 Eureka와 잘 맞는 Java용
내부 load balancer
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• Service Discovery 설정
• 수많은 서비스 인스턴스 & 개별 서비스는 다른 서비스의
클라이언트
Reuse Intention Introduce Load Balancing between instances of a service using Internal Load Balancer
Reuse Situation Scalability, High Availability, Dynamicity
• 클라이언트의 조건에 따라 인스턴스 간에 어떻게 서비스 부하의
균형을 맞출 수 있을까?
• 외부 load balancer 없이 서비스의 부하 균형을 맞추는 방법은?
• SD와 통합될 수 있는 프로그래밍 언어용 내부 load balancer 생성
• 부하 분산 메커니즘이 중앙집중화되지 못함
• 내부에 load balancer를 가진 서비스가 SD에서 가용한 인스턴스
목록 확인 & 호출
• 내부 load balancer가 내부 측정기준을 사용해서 가용한
인스턴스들 간의 부하 균형(예, 인스턴스의 반응시간)
• 외부 load balancer없이 클라이언트마다 개별 부하 분산 메커니즘
사용
Service Registry에서
A 서비스 중에서 활성화된
인스턴스 (active instance)를
가져와서 그 중에 하나 선택
20. [MP9] Introduce External Load Balancer
20
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Amazon ELB, Nginx, HAProxy, Eureka
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• Service Discovery 설정
• 수많은 서비스 인스턴스 & 개별 서비스는 다른 서비스의
클라이언트
Reuse Intention Introduce Load Balancing between instances of a service using External Load Balancer
Reuse Situation Scalability, High Availability, Dynamicity
• 서비스 코드를 최소한으로 변경하고도 인스턴스 간의 서비스
부하를 분산시키는 방법은?
• 어떻게 하면 중앙집중화된 부하 분산을 할 수 있을까?
• 내부의 측정기준은 부하를 분산시키는 데 소용 없음
• load balancer를 proxy로 쓰려면 고가용성 부하 분산 클러스터
필요
• 중앙집중화된 알고리즘 사용 : Service Discovery에서 가용한
인스턴스의 목록을 가져와서 서비스의 인스턴스 간에 부하 분산
• Proxy 기능(비 추천) 또는 인스턴스 주소 지정자 기능 가능
• 부하 분산 주소 지정자(load balanced address locator) 역할을 하는
Service Discovery 설정
Service Registry에서
A 서비스 중에서 활성화된
인스턴스 (active instance)를
가져옴
21. [MP10] Introduce Circuit Breaker
21
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Hystrix
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• 사용자 요청사항의 일부는 시스템 내부에서 서비스 간의 통신 필요
Reuse Intention Introduce Fault Tolerance in inter-service communication using Circuit Breaker
Reuse Situation Fault Tolerance, High Availability
• 사용할 수 없는 서비스를 호출했을 때 빨리 실패하게 하여 서비스
호출이 시간 제한(time-out)에 걸릴 때까지 기다리지 않도록 하려면?
• 사용할 수 없는 서비스를 호출할 때 서비스를 대신하여 반응을
내보내 시스템 탄력성을 더 강하게 만들 수 있는 방법은 무엇인가?
• Open Circuit 상태에서 적절한 응답을 인식하는 것은 다소
어려우며 업무 관계자들의 협조 필요
• 서비스 소비자가 서비스를 호출할 때 Circuit Breaker 사용
• Close Circuit state : 서비스가 사용가능한 상태
• Open Circuit state : 서비스 반응을 모니터링하여 반응실패 횟수가
미리 정의한 문턱값을 넘어섰을 때 대응 응답 코드나 예외 반환,
캐싱 데이터 반환 등
• Half-open Circuit state : 시간 제한 이후에는 서비스 가용 여부를
확인하기 위해 서비스에 재접속 Open과 Close 결정/변경
22. [MP11] Introduce Configuration Server
22
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Spring Config Server, Archaius
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• 수많은 서비스 인스턴스
• 사용가능한 인스턴스 목록은 Service Discovery를 통해 제공
Reuse Intention Change a system’s configuration at runtime using Configuration Server
Reuse Situation Modifiability, Dynamicity, Deployment
• 실행중인 인스턴스 구성을 재배포하지 않고도 수정하는 방법은?
• 서비스 내에서 설정 정보 전파의 종착점(endpoint)과 사용 중인
모든 프로그래밍 언어에 대해 적응 전략을 구현
• 소스 코드와 소프트웨어 설정사항을 각각 저장할 두 개의 분리된
저장소가 별도로 마련
• 설정 저장소(configuration repository)에 변경 사항이 발생하면 이를
기준으로 실행되는 인스턴스에 전파되어야 하며 인스턴스는 그에
따라 스스로 적응
각 인스턴스는 구동시에 해당 설정
정보를 가져옴
나중에 변경된 설정정보는
실행중인 인스턴스에 push되며, 각
인스턴스는 스스로 알아서 적용
23. [MP12] Introduce Edge Server
23
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Zuul
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• 서비스의 초기화가 쉽기 때문에 새로운 서비스를 쉽게 도입
• 기존의 서비스도 새로운 요구사항에 맞게 재구성(re-architect) 쉬움
Reuse Intention Enable Dynamic Re-routing of external requests to internal services using Edge Server
Reuse Situation Modifiability, Dynamicity
• 최종사용자에게 서비스 내부 구조나 변화내용을 안보이게 하는
방법?
• 서비스 사용량과 전반적인 상태를 모니터링할 수 있는 방법은?
• 모든 트래픽이 통과하므로 single-point-of-failure 위험 부하 분산
메커니즘을 이용해 복제 필요
• 시스템의 출입문 역할을 하는 간접적인 층, Edge Server 도입
• 미리 정의된 설정사항에 따라서 동적인 트래픽 배분 역할
• 서비스 인스턴스의 주소는 하드 코딩하거나 Service Discovery에서
• 최종사용자는 이 층과만 인터페이스 : 내부 변경에 영향받지 않음
• 모든 트래픽이 통과하므로 전반적인 모니터링하기에 최적
24. [MP13] Containerize the Services
24
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Docker
단점 (Challenge)
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• Continuous Integration pipeline이 구축되어 작동 중
• 개발환경과 운영환경의 차이 때문에 같은 코드, 다른 결과
Reuse Intention Have the same behavior in development and production environment using Containerization
Reuse Situation Resource-efficiency, Deployment
• 개발/운영환경에서 같은 코드가 같은 결과를 가져오게 하는 방법은?
• 설정관리 도구의 복잡성과 수작업 배포의 어려움을 없앨 방법은?
• 컴퓨팅 자원의 과소비 : 가상화로 인해 서비스 격리에 많은 자원
소요
• 배포할 때 컨테이너라는 층을 하나 더 얹음 복잡도 증가
• 격리된 VM에서 서비스를 개별 배포, 설정 관리 도구로 필요 환경
제공
• 컨테이너 이미지 활용 설정관리 도구 불필요
• Continuous Integration pipeline에 컨테이너 이미지 구성(build)단계
추가 개별 이미지 저장소에 저장하여 운영/개발 환경에 실행
• 각 서비스는 서비스 컨테이너를 실행하기 위한 스크립트 소유
• 서비스 실행을 위한 환경변수 목록 관리 누구나 변수의 변화
감지
25. [MP14] Deploy into a Cluster and Orchestrate Containers
25
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Mesos+Marathon, Kubernetes
• 소프트웨어 시스템은 작은 서비스들로 분해되어 있으며,
• Continuous Integration pipeline이 구축 컨테이너 이미지 사용
• 서비스 숫자가 많아서 배포와 재배포가 복잡하고 관리 어려움
Reuse Intention Deploy service instances’ container images in a cluster using cluster management tools
Reuse Situation Resource-efficiency, Deployment
• 서비스 인스턴스를 클러스터에 배포하는 방법은?
• 최소의 노력으로 모든 서비스의 배포와 재배포를 조율하는 방법은?
• 컴퓨팅 노드의 클러스터를 관리할 수 있는 시스템 도입
- 필요에 따라 특정 인스턴스나 다른 노드에 컨테이너 이미지 배포
- 인스턴스의 장애 처리, 재시작
- 서비스를 자동 확장(auto-scaling)할 수 있는 수단 제공
- Service Discovery 같은 일부 서비스는 IP 주소 대신 이름으로
식별되어야 하므로 내부 (서비스)이름 확인 전략을 사용
• 배포 절차를 효과적으로 조율하기 위해서 서비스의 배포
아키텍처를 명시적으로 정의할 수 있는 수단을 제공
• 자동 확장, 서비스 장애관리 등은 클러스터 관리 도구가 수행
26. [MP15] Monitor the System and Provide Feedback
26
적용 상황 (Context)
의문 사항 (Problem)
해결 방안 (Solution)
Technology Stack
Collectd + Logstash + ElasticSearch + Kibana
• MSA 스타일로 소프트웨어 시스템 구축
• 운영계의 개별 서비스가 여러 개의 인스턴스를 갖는 컨테이너
클러스터에서 실행
Reuse Intention Monitor the running services’ instances and Provide feeback to the development team
Reuse Situation Monitoring, Modifiability
• Infrastructure는 어떻게 모니터링 할 것인가?
• 개발팀에 피드백하여 시스템을 재구성(re-architect)하는 방법은?
• 개별 서비스는 해당 서비스 관리팀의 운영(Ops) 파트가 직접 관리
• CPU와 RAM 사용량과 같은 모니터링 정보를 수집하여 모니터링
서버에 전달
• 모니터링 서버 : 정보들을 구문 분석하고 구조화된 정보 형태로
집계
• 인덱싱 서버 : 집계된 정보 저장 효율적으로 쿼리
• 모니터링 정보는 통해 서비스 개발(Dev) 파트가 성능 병목현상이나
기타 이상 현상을 제거하기 위해 아키텍처를 리팩토링하는 데 활용
30. 이행 패턴의 선택과 작성
• 이행 패턴의 초기 버전을 통해 현재 진행중인 이행 프로젝트를 위한 이행 계획
수립
1) 이행의 동인과 요구사항을 식별
2) 식별된 요구사항을 이행 패턴 표1에서 설명한 선택 요인(factor)와 맞춤
3) 관련 선택 요인을 기반으로 초기 버전이 제공하는 핵심 개념, Reuse Intention, 문제점 등을 고려하여
가장 적합한 패턴을 선택함으로써 일련의 이행 패턴을 도출
4) 각각의 패턴을 사용하는 맥락(Context)을 확인
5) 일련의 패턴들을 선택하여 이행 계획을 구성
• 다형성(polyglot-ness)에 대한 필요에 따라서 분해 패턴을 찾고, 그 다음에
프로젝트 도메인의 복잡성에 따라서 가장 적합한 패턴을 선택
• 저장소에서 적합한 이행 패턴을 선택한 다음에는, 요구사항과 프로젝트 상황,
제약사항(예, 시간, 인적/물적 예산 등)에 따라서 선택된 패턴으로 이행 패턴
작성
30
32. 새 패턴 추가하기
• Microservices는 아직 미성숙 단계이므로 이행 패턴의 완성도도 미흡한 상태
• 대신, microservices로 이행하는 새로운 경험을 통해 일반화된 새로운 이행
패턴을 추가함으로써 패턴 저장소를 확장
• 패턴을 정의할 때 메타 모델, 몇몇 선택 요인, 그리고 패턴의 내용(granularity)를
결정하는 요인들을 제공 메타 모델에 부합되도록 하고 패턴 저장소 강화
• 새로운 선택 요인이 필요하면 현재의 선택요인에 추가
32
34. [첨부] Continuous Integration server
1. Cl Server
• 빌드 프로세스를 관리하는 서버
• Jenkins, Hudson, CruiseControl.NET. TeamCity
2. SCM(Source Code Management)
• 소스코드 형상관리 시스템 : 소스코드의 개정과 백업 절차를
자동화하여 오류 수정 과정을 도와줄 수 있는 시스템
• 프로젝트 내에서 각자가 수정한 부분을 팀원 전체가 자동으로 동기화
• Subversion, Git, Mercurial
3. Build Tool
• 검파일. 테스트. 정적분석 등을 실시해 동작 가능한 소프트웨어를
생성
• Ant Maven. MSBuild. Make
4. Test Tool
• 테스트 코드에 따라 자동으로 테스트를 수행하는 도구. 빌드 툴의
스크립트에서 실행
• Unit. CppTest. MSTest, Selenium(사용자테스트 자동화 가능)
5. Test Coverage tool
• 테스트 코드가 대상 소스 코드에 다하 어느정도 커버하는지 분석하는
도구
• Emma, Cobertura, TestCocoon
6. Inspection Tool
• 프로그램을 실행하지 않고. 소스코드 자제로 품질을 판단할 수 있는
정적분석 도구
• 코딩 표준 준수, 코드 메트릭 측정. 중복코드. 코드 인스펙션 등 검사
• CheckStyle, FindBugs, Cppcheck, Valgrind
34
<출처> http://happystory.tistory.com/89
CI 서버란?
형상관리 서버에 Commit된 소스코드를 주기적으로 폴링하여
컴파일, 단위테스트, 코드 인스펙션 등의 과정을 수행하며 신규
또는 수정된 소스코드가 결함이 있는지 여부를 지속적으로 검증
검증 결과는 이메일, RSS 등을 통해 개발자들에게 전달
CI 시스템 구축을 위한 핵심 구성요소
Editor's Notes
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
DevOps => “피자 두 판 팀“
민첩하면서도 독립적인, 서로 신뢰하고 오너십을 가진 소규모의 서비스 팀
예) 아마존 AWS는 Appllo를 사용하여 1년간 약 5천만 번의 개발/테스트/배포 수행(=초당 1회)
Gitlab : Gitlab은 Git의 원격 저장소(또는 설치형) 기능과 이슈 트래커 기능 등을 제공하는 소프트웨어. 설치형 Github라는 컨셉으로 시작된 프로젝트이기 때문에 Github와 비슷
Artifactory : 보안, 클러스터, 고가용성 Docker registry를 제공하는 기업용 라이브러리 공유저장소관리 솔루션. 개발계부터 운영계까지 모든 결과물 추적 관리 솔루션
Nexus : repository 관리 솔루션
Jenkins : CI (Continuous Integration)를 위한 소스 배포 관리 솔루션. 구성원들이 각각 작업한 내용(소스코드)을 정기적으로 통합.
GoCD : Open source continuous delivery server to model and visualize complex workflows with ease
Travis : GitHub과 연동해 지속적 통합(Continuous Integration)을 호스팅해주는 서비스. GitHub 저장소에 새로운 커밋이 push되었을 때 CI 서버가 뒤에서 자동으로 새로운 커밋을 가져와서 빌드 테스트를 수행하고, 그 결과를 리포팅 해주는 서비스
Bamboo : 빌드, 테스트, 릴리즈를 워크플로우로 묶어서 자동화한 솔루션. JIRA Software, Bitbucket, Fisheye 및 HipChat과의 최적의 통합
Teamcity : 빌드자동화 솔루션
Gitlab : Gitlab은 Git의 원격 저장소(또는 설치형) 기능과 이슈 트래커 기능 등을 제공하는 소프트웨어. 설치형 Github라는 컨셉으로 시작된 프로젝트이기 때문에 Github와 비슷
Artifactory : 보안, 클러스터, 고가용성 Docker registry를 제공하는 기업용 라이브러리 공유저장소관리 솔루션. 개발계부터 운영계까지 모든 결과물 추적 관리 솔루션
Nexus : repository 관리 솔루션
Jenkins : CI (Continuous Integration)를 위한 소스 배포 관리 솔루션. 구성원들이 각각 작업한 내용(소스코드)을 정기적으로 통합.
GoCD : Open source continuous delivery server to model and visualize complex workflows with ease
Travis : GitHub과 연동해 지속적 통합(Continuous Integration)을 호스팅해주는 서비스. GitHub 저장소에 새로운 커밋이 push되었을 때 CI 서버가 뒤에서 자동으로 새로운 커밋을 가져와서 빌드 테스트를 수행하고, 그 결과를 리포팅 해주는 서비스
Bamboo : 빌드, 테스트, 릴리즈를 워크플로우로 묶어서 자동화한 솔루션. JIRA Software, Bitbucket, Fisheye 및 HipChat과의 최적의 통합
Teamcity : 빌드자동화 솔루션
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Eureka : Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.
Consul : a distributed, highly available, datacenter-aware, service discovery and configuration system.
Apache Zookeeper : a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Amazon ELB : Elastic Load Balancing
Nginx : 웹서버 소프트웨어로 웹서버, 리버스 프록시 및 메일 프록시 기능. 쓰레드 기반이 아닌 이벤트 기반
HAProxy : L4/L7 의 기능을 제공하는 소프트웨어 로드 밸런서
Eureka
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Netflex Archaius : a configuration management library with a focus on Dynamic Properties sourced from multiple configuration stores.
includes a set of java configuration management APIs used at Netflix.
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe differences between monolithic and microservices architecture in terms of number of services and scalability mechanisms
Describe SSaaS as a Mobile Backend as a Service through which mobile development time will be reduced and briefly mention its features
Describe SSaaS as a Mobile Backend as a Service through which mobile development time will be reduced and briefly mention its features