클라우드 네이티브 정의Defining cloud native

수행 하 고 있는 작업 및 동료의 10 자를 중지 합니다.Stop what you're doing and text ten of your colleagues. "클라우드 네이티브" 라는 용어를 정의 하도록 요청 합니다.Ask them to define the term "Cloud Native". 10 개의 서로 다른 답을 얻을 수 있는 좋은 기회입니다.Good chance you'll get ten different answers.

클라우드 기본은 중요 한 비즈니스 시스템을 구성 하는 방법에 대 한 고려 사항입니다.Cloud native is all about changing the way you think about constructing critical business systems.

클라우드 네이티브 시스템은 신속한 변화, 대규모 및 복원 력을 수용 하도록 설계 되었습니다.Cloud-native systems are designed to embrace rapid change, large scale, and resilience.

Cloud Native 컴퓨팅 Foundation은 공식 정의를 제공 합니다.The Cloud Native Computing Foundation provides an official definition:

클라우드 기본 기술을 통해 조직은 공용, 사설 및 하이브리드 클라우드와 같은 최신의 동적 환경에서 확장 가능한 응용 프로그램을 빌드 및 실행할 수 있습니다. 컨테이너, 서비스 메시, 마이크로 서비스, 변경할 수 없는 인프라 및 선언적 Api는이 접근 방식을 exemplify 합니다.Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

이러한 기술을 통해 탄력적이 고 관리 하기 쉽고 관찰 가능한 느슨하게 결합 된 시스템을 사용할 수 있습니다. 강력한 자동화와 결합 되어 엔지니어가 toil을 최소화 하면서 높은 영향을 미치는 변화를 자주 내릴 수 있습니다.These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

응용 프로그램은 더 많은 사용자가 요구 하는 점점 점점 더 복잡 해지고 있습니다.Applications have become increasingly complex with users demanding more and more. 사용자는 신속한 응답성, 혁신적인 기능 및 가동 중지 시간을 예측할 수 있습니다.Users expect rapid responsiveness, innovative features, and zero downtime. 성능 문제, 반복 되는 오류 및 빠르게 이동할 수 없는 것은 더 이상 허용 되지 않습니다.Performance problems, recurring errors, and the inability to move fast are no longer acceptable. 경쟁 업체에 쉽게 이동할 수 있습니다.They'll easily move to your competitor.

클라우드 네이티브는 속도민첩성에 대 한 것입니다.Cloud native is about speed and agility. 비즈니스 시스템은 비즈니스 기능을 사용 하 여 비즈니스 속도와 성장을 가속화 하는 전략적 변환의 무기로 발전 하 고 있습니다.Business systems are evolving from enabling business capabilities to being weapons of strategic transformation that accelerate business velocity and growth. 시장에 즉시 아이디어를 얻는 것이 필수적입니다.It's imperative to get ideas to market immediately.

이러한 기술을 구현한 회사는 다음과 같습니다.Here are some companies who have implemented these techniques. 달성 한 속도, 민첩성 및 확장성을 고려 합니다.Think about the speed, agility, and scalability they've achieved.

회사Company 환경Experience
NetflixNetflix 에는 프로덕션에서 600 개 이상의 서비스가 있습니다.Has 600+ services in production. 하루에 100 회 배포 합니다.Deploys hundred times per day.
UberUber 에는 프로덕션 환경에서 1000 개 이상의 서비스가 있습니다.Has 1,000+ services in production. 매주 몇 천 번 배포 합니다.Deploys several thousand times each week.
WeChatWeChat 에는 프로덕션 환경에 3,000 개 이상의 서비스가 있습니다.Has 3,000+ services in production. 하루에 1000 번 배포 합니다.Deploys 1,000 times a day.

여기에서 볼 수 있듯이 Netflix, Uber 및 WeChat는 수많은 독립 마이크로 서비스로 구성 된 시스템을 노출 합니다.As you can see, Netflix, Uber, and WeChat expose systems that consist of hundreds of independent microservices. 이 아키텍처 스타일을 통해 시장 상황에 신속 하 게 대응할 수 있습니다.This architectural style enables them to rapidly respond to market conditions. 이러한 사용자는 라이브, 복잡 한 응용 프로그램의 작은 영역을 즉시 업데이트 하 고 필요에 따라 이러한 영역을 개별적으로 확장할 수 있습니다.They can instantaneously update small areas of a live, complex application, and individually scale those areas as needed.

Cloud native의 속도 및 민첩성은 다양 한 요소에서 제공 됩니다.The speed and agility of cloud native come about from a number of factors. 가장는 클라우드 인프라입니다.Foremost is cloud infrastructure. 그림 1-3에 표시 된 5 가지 추가 기본 핵심 요소 클라우드 기본 시스템에 대 한 bedrock을 제공 합니다.Five additional foundational pillars shown in Figure 1-3 also provide the bedrock for cloud-native systems.

클라우드 네이티브 기본 핵심 요소

그림 1-3.Figure 1-3. 클라우드 네이티브 기본 핵심 요소Cloud-native foundational pillars

각 기둥의 중요도를 보다 잘 이해 하는 데 약간의 시간이 걸릴 수 있습니다.Let's take some time to better understand the significance of each pillar.

클라우드 ...The cloud…

클라우드 기본 시스템은 클라우드 서비스 모델을 최대한 활용 합니다.Cloud-native systems take full advantage of the cloud service model.

가상화 된 동적 클라우드 환경에서 올립니다 설계 된 이러한 시스템은 PaaS (Platform as a Service) 계산 인프라와 관리 되는 서비스를 광범위 하 게 사용 합니다.Designed to thrive in a dynamic, virtualized cloud environment, these systems make extensive use of Platform as a Service (PaaS) compute infrastructure and managed services. 기본 인프라를 몇 분 내에 삭제 가능 프로 비전 된 것으로 처리 하 고 자동화를 통해 필요에 따라 크기 조정, 크기 조정, 이동 또는 제거 합니다.They treat the underlying infrastructure as disposable - provisioned in minutes and resized, scaled, moved, or destroyed on demand – via automation.

애완 동물 vs. 결국에서 널리 승인 된 devops 개념을 고려 합니다.Consider the widely accepted DevOps concept of Pets vs. Cattle. 기존 데이터 센터에서 서버는 애완 동물으로 처리 됩니다. 물리적 컴퓨터는 의미 있는 이름을 지정 하 고는 확인 개체만입니다.In a traditional data center, servers are treated as Pets: a physical machine, given a meaningful name, and cared for. 동일한 컴퓨터에 리소스를 더 추가 하 여 크기를 조정 합니다 (확장).You scale by adding more resources to the same machine (scaling up). 서버를 병가로 전환 하면 간호사 됩니다.If the server becomes sick, you nurse it back to health. 서버를 사용할 수 없게 되 면 모든 사용자가 알림을 받을 수 있습니다.Should the server become unavailable, everyone notices.

결국 서비스 모델이 서로 다릅니다.The Cattle service model is different. 각 인스턴스를 가상 컴퓨터 또는 컨테이너로 프로 비전 합니다.You provision each instance as a virtual machine or container. 동일 하 고 서비스-01, 서비스-02 등의 시스템 식별자가 할당 됩니다.They're identical and assigned a system identifier such as Service-01, Service-02, and so on. 이러한 항목을 더 만들어 크기를 조정 합니다 (규모 확장).You scale by creating more of them (scaling out). 하나를 사용할 수 없게 되 면 아무도 알림을 하지 않습니다.When one becomes unavailable, nobody notices.

결국 모델은 변경할 수 없는 인프라를 수용 합니다.The cattle model embraces immutable infrastructure. 서버가 복구 되거나 수정 되지 않습니다.Servers aren't repaired or modified. 오류가 발생 하거나 업데이트가 필요한 경우에는 완전히 제거 되며 자동화를 통해 모두 프로 비전 됩니다.If one fails or requires updating, it's destroyed and a new one is provisioned – all done via automation.

클라우드 네이티브 시스템은 결국 서비스 모델을 수용 합니다.Cloud-native systems embrace the Cattle service model. 인프라는 실행 중인 컴퓨터와 관계 없이 규모를 확장 하거나 축소할 때 계속 해 서 실행 됩니다.They continue to run as the infrastructure scales in or out with no regard to the machines upon which they're running.

Azure 클라우드 플랫폼은 자동 크기 조정, 자동 복구 및 모니터링 기능을 제공 하는 이러한 유형의 매우 탄력적 인프라를 지원 합니다.The Azure cloud platform supports this type of highly elastic infrastructure with automatic scaling, self-healing, and monitoring capabilities.

최신 디자인Modern design

클라우드 네이티브 앱을 어떻게 디자인 하나요?How would you design a cloud-native app? 아키텍처는 다음과 같습니다.What would your architecture look like? 어떤 원칙, 패턴 및 모범 사례를 준수 하나요?To what principles, patterns, and best practices would you adhere? 중요 한 인프라 및 운영 우려는 무엇 인가요?What infrastructure and operational concerns would be important?

12 단계 응용 프로그램The Twelve-Factor Application

클라우드 기반 응용 프로그램을 구성 하는 데 널리 사용 되는 방법은 12 단계 응용 프로그램입니다.A widely accepted methodology for constructing cloud-based applications is the Twelve-Factor Application. 개발자가 최신 클라우드 환경에 최적화 된 응용 프로그램을 만들기 위해 따라야 하는 원칙과 관행을 설명 합니다.It describes a set of principles and practices that developers follow to construct applications optimized for modern cloud environments. 환경 및 선언적 자동화에서 이식성에 대 한 특별 한 주의가 제공 됩니다.Special attention is given to portability across environments and declarative automation.

모든 웹 기반 응용 프로그램에 적용 가능 하지만 많은 전문가는 클라우드 네이티브 앱을 빌드하기 위한 견고한 기반으로 12 단계를 고려 합니다.While applicable to any web-based application, many practitioners consider Twelve-Factor as a solid foundation for building cloud-native apps. 이러한 원칙을 바탕으로 구축 된 시스템은 신속 하 게 배포 하 고 확장할 수 있으며 시장 변화에 신속 하 게 대응할 수 있는 기능을 추가할Systems built upon these principles can deploy and scale rapidly and add features to react quickly to market changes.

다음 표에서는 12 단계 방법을 중점적으로 설명 합니다.The following table highlights the Twelve-Factor methodology:

요인Factor 설명Explanation
11 코드 베이스Code Base 자체 리포지토리에 저장 된 각 마이크로 서비스에 대 한 단일 코드 베이스입니다.A single code base for each microservice, stored in its own repository. 버전 제어로 추적 되 고 여러 환경 (QA, 스테이징, 프로덕션)에 배포할 수 있습니다.Tracked with version control, it can deploy to multiple environments (QA, Staging, Production).
22 종속성Dependencies 각 마이크로 서비스는 자체 종속성을 격리 하 고 패키지 하 여 전체 시스템에 영향을 주지 않고 변경 내용을 수용 합니다.Each microservice isolates and packages its own dependencies, embracing changes without impacting the entire system.
33 구성Configurations 구성 정보는 코드 외부의 구성 관리 도구를 통해 마이크로 서비스 및 표면화 된 외부로 이동 됩니다.Configuration information is moved out of the microservice and externalized through a configuration management tool outside of the code. 동일한 배포가 올바른 구성이 적용 된 환경에서 전파 될 수 있습니다.The same deployment can propagate across environments with the correct configuration applied.
44 서비스 지원Backing Services 보조 리소스 (데이터 저장소, 캐시, 메시지 브로커)는 주소 지정 가능 URL을 통해 노출 되어야 합니다.Ancillary resources (data stores, caches, message brokers) should be exposed via an addressable URL. 이렇게 하면 응용 프로그램에서 리소스를 분리 하 여 상호 교환이 가능 합니다.Doing so decouples the resource from the application, enabling it to be interchangeable.
55 빌드, 릴리스, 실행Build, Release, Run 각 릴리스는 빌드, 릴리스 및 실행 단계에서 엄격한 분리를 적용 해야 합니다.Each release must enforce a strict separation across the build, release, and run stages. 각에는 고유한 ID로 태그를 지정 하 고 롤백하는 기능을 지원 해야 합니다.Each should be tagged with a unique ID and support the ability to roll back. 최신 CI/CD 시스템은이 원칙을 충족 하는 데 도움이 됩니다.Modern CI/CD systems help fulfill this principle.
66 프로세스Processes 각 마이크로 서비스는 실행 중인 다른 서비스와 분리 된 자체 프로세스에서 실행 되어야 합니다.Each microservice should execute in its own process, isolated from other running services. 분산 캐시 또는 데이터 저장소와 같은 지원 서비스에 필요한 상태를 외부화 합니다.Externalize required state to a backing service such as a distributed cache or data store.
77 포트 바인딩Port Binding 각 마이크로 서비스는 자체 포트에서 노출 되는 인터페이스 및 기능과 함께 자체 포함 되어야 합니다.Each microservice should be self-contained with its interfaces and functionality exposed on its own port. 이렇게 하면 다른 마이크로 서비스와의 격리가 제공 됩니다.Doing so provides isolation from other microservices.
88 동시성Concurrency 서비스는 사용 가능한 가장 강력한 컴퓨터에서 단일 큰 인스턴스를 확장 하는 것과는 반대로, 많은 수의 작은 동일한 프로세스 (복사본)로 확장 됩니다.Services scale out across a large number of small identical processes (copies) as opposed to scaling-up a single large instance on the most powerful machine available.
99 DisposabilityDisposability 서비스 인스턴스는 삭제 가능 해야 하며, 확장성 기회를 높이고 정상적인 종료를 찾은 다음 하 여 시스템을 올바른 상태로 유지 해야 합니다.Service instances should be disposable, favoring fast startups to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker 컨테이너는 기본적으로이 요구 사항을 충족 합니다.Docker containers along with an orchestrator inherently satisfy this requirement.
1010 개발/Prod 패리티Dev/Prod Parity 응용 프로그램 수명 주기 전반에 걸쳐 최대한 많은 바로 가기를 방지 하 여 환경을 최대한 유사 하 게 유지 합니다.Keep environments across the application lifecycle as similar as possible, avoiding costly shortcuts. 여기서는 컨테이너를 채택 하는 것이 동일한 실행 환경을 승격 하 여 크게 기여할 수 있습니다.Here, the adoption of containers can greatly contribute by promoting the same execution environment.
1111 로깅Logging 마이크로 서비스에 의해 생성 된 로그를 이벤트 스트림으로 처리 합니다.Treat logs generated by microservices as event streams. 이벤트 집계를 사용 하 여 처리 하 고 데이터를 Azure Monitor 또는 Splunk 등의 데이터 마이닝/로그 관리 도구에 전파 하 고 결국 장기 보관 합니다.Process them with an event aggregator and propagate the data to data-mining/log management tools like Azure Monitor or Splunk and eventually long-term archival.
1212 관리 프로세스Admin Processes 관리/관리 작업을 일회성 프로세스로 실행 합니다.Run administrative/management tasks as one-off processes. 작업에는 보고서에 대 한 데이터 정리 및 끌어오기 분석이 포함 될 수 있습니다.Tasks can include data cleanup and pulling analytics for a report. 이러한 작업을 실행 하는 도구는 프로덕션 환경에서 호출 해야 하지만 응용 프로그램과는 별도로 호출 해야 합니다.Tools executing these tasks should be invoked from the production environment, but separately from the application.

이 책에서 12 단계 앱 외의 작성자 Kevin hoffman은는 각각의 원래 12 가지 요소 (2011로 작성 됨)를 자세히 설명 합니다.In the book, Beyond the Twelve-Factor App, author Kevin Hoffman details each of the original 12 factors (written in 2011). 또한 오늘날의 최신 클라우드 응용 프로그램 디자인을 반영 하는 세 가지 추가 요소에 대해 설명 합니다.Additionally, he discusses three additional factors that reflect today's modern cloud application design.

새 요소New Factor 설명Explanation
1313 API 우선API First 모든 것을 서비스로 설정 합니다.Make everything a service. 프런트 엔드 클라이언트, 게이트웨이 또는 다른 서비스에서 코드를 사용 한다고 가정 합니다.Assume your code will be consumed by a front-end client, gateway, or another service.
1414 원격 분석Telemetry 워크스테이션에서는 응용 프로그램 및 해당 동작을 자세히 확인할 수 있습니다.On a workstation, you have deep visibility into your application and its behavior. 클라우드에서는 그렇지 않습니다.In the cloud, you don't. 디자인에 모니터링, 도메인별 및 상태/시스템 데이터 컬렉션이 포함 되어 있는지 확인 합니다.Make sure your design includes the collection of monitoring, domain-specific, and health/system data.
1515 인증/권한 부여Authentication/ Authorization 시작에서 id를 구현 합니다.Implement identity from the start. 공용 클라우드에서 사용할 수 있는 RBAC (역할 기반 액세스 제어) 기능을 고려 합니다.Consider RBAC (role-based access control) features available in public clouds.

이 장과 설명서 전체에서 12 개 이상의 요소를 모두 참조 합니다.We'll refer to many of the 12+ factors in this chapter and throughout the book.

중요 한 디자인 고려 사항Critical Design Considerations

12 단계 방법에서 제공 하는 지침 외에도 분산 시스템을 구성할 때 몇 가지 중요 한 디자인 결정을 내려야 합니다.Beyond the guidance provided from the twelve-factor methodology, there are several critical design decisions you must make when constructing distributed systems.

통신Communication

프런트 엔드 클라이언트 응용 프로그램은 백업 된 핵심 서비스와 통신 하는 방법How will front-end client applications communicate with backed-end core services? 직접 통신을 허용 하 시겠습니까?Will you allow direct communication? 또는 유연성, 제어 및 보안을 제공 하는 게이트웨이 외관을 사용 하 여 백 엔드 서비스를 추상화할 수 있습니다.Or, might you abstract the back-end services with a gateway façade that provides flexibility, control, and security?

백 엔드 핵심 서비스는 서로 통신 하는 방법How will back-end core services communicate with each other? 결합 및 성능에 영향을 주는 직접 HTTP 호출을 허용 하나요?Will you allow direct HTTP calls that lead to coupling and impact performance and agility? 또는 큐 및 토픽 기술로 분리 된 메시징을 고려할 수 있습니다.Or might you consider decoupled messaging with queue and topic technologies?

통신에 대 한 자세한 내용은 4 장 클라우드 네이티브 통신 패턴을 참조 하세요.Communication is covered in detail Chapter 4, Cloud-Native Communication Patterns.

복원력Resiliency

마이크로 서비스 아키텍처는 시스템을 in-process에서 out-of-process 네트워크 통신으로 이동 합니다.A microservices architecture moves your system from in-process to out-of-process network communication. 분산 아키텍처에서 서비스 B가 서비스 A의 네트워크 호출에 응답 하지 않으면 어떻게 되나요?In a distributed architecture, what happens when Service B isn't responding to a network call from Service A? 또는 서비스 C를 일시적으로 사용할 수 없게 되 고이 서비스를 호출 하는 다른 서비스가 차단 되 면 어떻게 되나요?Or, what happens when Service C becomes temporarily unavailable and other services calling it are blocked?

복원 력은 6 장, 클라우드 기본 복원 력에 자세히 설명 되어 있습니다.Resiliency is covered in detail Chapter 6, Cloud-Native Resiliency.

분산 데이터Distributed Data

기본적으로 각 마이크로 서비스는 자체 데이터를 캡슐화 하 여 공용 인터페이스를 통해 작업을 노출 합니다.By design, each microservice encapsulates its own data, exposing operations via its public interface. 그렇다면 여러 서비스에서 데이터를 쿼리하거나 트랜잭션을 구현 하는 방법은 무엇입니까?If so, how do you query data or implement a transaction across multiple services?

분산 데이터에 대 한 자세한 내용은 5 장, 클라우드 네이티브 데이터 패턴을 참조 하세요.Distributed data is covered in detail Chapter 5, Cloud-Native Data Patterns.

IDIdentity

서비스에서 액세스 하는 사용자 및 사용 권한을 식별 하는 방법은 무엇 인가요?How will your service identify who is accessing it and what permissions they have?

Id는 세부 정보 Chapter 8, id에 설명 되어 있습니다.Identity is covered in detail Chapter 8, Identity.

마이크로 서비스Microservices

클라우드 네이티브 시스템은 최신 응용 프로그램을 구성 하는 데 널리 사용 되는 아키텍처 스타일 인 마이크로 서비스를 수용 합니다.Cloud-native systems embrace microservices, a popular architectural style for constructing modern applications.

공유 패브릭을 통해 상호 작용 하는 소규모 독립 서비스의 분산 된 집합으로 구축 된 마이크로 서비스는 다음과 같은 특징을 공유 합니다.Built as a distributed set of small, independent services that interact through a shared fabric, microservices share the following characteristics:

  • 각는 더 큰 도메인 컨텍스트 내에서 특정 비즈니스 기능을 구현 합니다.Each implements a specific business capability within a larger domain context.

  • 각은 자율적으로 개발 되며 독립적으로 배포할 수 있습니다.Each is developed autonomously and can be deployed independently.

  • 각은 자체 데이터 저장소 기술 (SQL, NoSQL) 및 프로그래밍 플랫폼을 캡슐화 하는 자체 포함 됩니다.Each is self-contained encapsulating its own data storage technology (SQL, NoSQL) and programming platform.

  • 각는 자체 프로세스에서 실행 되 고 HTTP/HTTPS, Websocket 또는 Amqp와 같은 표준 통신 프로토콜을 사용 하 여 다른 사용자와 통신 합니다.Each runs in its own process and communicates with others using standard communication protocols such as HTTP/HTTPS, WebSockets, or AMQP.

  • 응용 프로그램을 구성 하기 위해 함께 구성 됩니다.They compose together to form an application.

그림 1-4은 마이크로 서비스 접근 방식과 모놀리식 응용 프로그램 접근 방식을 대조 합니다.Figure 1-4 contrasts a monolithic application approach with a microservices approach. 단일 프로세스에서 실행 되는 계층화 된 아키텍처로 모놀리식를 구성 하는 방법을 확인 합니다.Note how the monolith is composed of a layered architecture, which executes in a single process. 일반적으로 관계형 데이터베이스를 사용 합니다.It typically consumes a relational database. 그러나 마이크로 서비스 접근 방식은 논리와 데이터를 포함 하는 독립적인 서비스로 기능을 분리 합니다.The microservice approach, however, segregates functionality into independent services that include logic and data. 각 마이크로 서비스는 자체 데이터 저장소를 호스팅합니다.Each microservice hosts its own datastore.

모놀리식 배포 및 마이크로 서비스

그림 1-4.Figure 1-4. 모놀리식 배포 및 마이크로 서비스Monolithic deployment versus microservices

마이크로 서비스는 12 단계 응용 프로그램에서 "한 코드 베이스, 한 응용 프로그램" 원칙을 승격 하는 방법에 대해 설명 합니다.Note how microservices promote the "One Codebase, One Application" principle from the Twelve-Factor Application, discussed earlier in the chapter.

요소 # 1은 자체 리포지토리에 저장 된 각 마이크로 서비스에 대해 단일 코드 베이스를 지정 합니다. 버전 제어로 추적 되 고 여러 환경에 배포할 수 있습니다. "Factor #1 specifies "A single codebase for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple environments."

마이크로 서비스를 사용하는 이유는 무엇인가요?Why microservices?

마이크로 서비스는 민첩성을 제공 합니다.Microservices provide agility.

이 장에서는 마이크로 서비스를 사용 하 여 모놀리식로 빌드된 전자 상거래 응용 프로그램을 비교 했습니다.Earlier in the chapter, we compared an eCommerce application built as a monolith to that with microservices. 이 예제에서는 다음과 같은 몇 가지 분명 한 이점이 있습니다.In the example, we saw some clear benefits:

  • 각 마이크로 서비스는 자치 수명 주기를 가지 며 독립적으로 발전 하 고 자주 배포할 수 있습니다.Each microservice has an autonomous lifecycle and can evolve independently and deploy frequently. 분기별 릴리스가 새 기능이 나 업데이트를 배포할 때까지 기다릴 필요가 없습니다.You don't have to wait for a quarterly release to deploy a new features or update. 전체 시스템을 방해 하는 위험을 줄일 수 있는 복잡 한 응용 프로그램의 작은 영역을 업데이트할 수 있습니다.You can update a small area of a complex application with less risk of disrupting the entire system.

  • 각 마이크로 서비스은 독립적으로 확장 될 수 있습니다.Each microservice can scale independently. 전체 응용 프로그램을 단일 단위로 확장 하는 대신 더 많은 처리 능력 또는 네트워크 대역폭이 필요한 서비스만 확장할 수 있습니다.Instead of scaling the entire application as a single unit, you scale out only those services that require more processing power or network bandwidth. 크기 조정에 대 한이 세분화 된 접근 방식을 사용 하면 시스템을 보다 효과적으로 제어할 수 있으며, 모든 것이 아니라 시스템의 일부를 확장할 때 전체 비용을 줄일 수 있습니다.This fine-grained approach to scaling provides for greater control of your system and helps to reduce overall costs as you scale portions of your system, not everything.

마이크로 서비스를 이해 하기 위한 뛰어난 참조 가이드는 .Net 마이크로 서비스: 컨테이너 화 된 .Net 응용 프로그램용 아키텍처입니다.An excellent reference guide for understanding microservices is .NET Microservices: Architecture for Containerized .NET Applications. 책은 마이크로 서비스 디자인 및 아키텍처로 다이브.The book deep dives into microservices design and architecture. Microsoft에서 제공 하는 무료 다운로드로 제공 되는 전체 스택 마이크로 서비스 참조 아키텍처 에 대 한 부록입니다.It's a companion for a full-stack microservice reference architecture available as a free download from Microsoft.

마이크로 서비스 개발Developing microservices

마이크로 서비스는 모든 최신 개발 플랫폼을 사용 하 여 만들 수 있습니다.Microservices can be created with any modern development platform.

Microsoft .NET Core 플랫폼을 선택 하는 것이 좋습니다.The Microsoft .NET Core platform is an excellent choice. 무료 오픈 소스는 마이크로 서비스 개발을 간소화 하는 여러 가지 기본 제공 기능을 제공 합니다.Free and open source, it has many built-in features to simplify microservice development. .NET Core는 플랫폼 간입니다..NET Core is cross-platform. Windows, macOS 및 대부분의 Linux에서 응용 프로그램을 빌드하고 실행할 수 있습니다.Applications can be built and run on Windows, macOS, and most flavors of Linux.

.NET Core는 성능이 뛰어나고 Node.js 및 기타 경쟁 플랫폼과 비교 하 여 잘 점수가 매겨집니다..NET Core is highly performant and has scored well in comparison to Node.js and other competing platforms. 흥미롭게도 TechEmpower 는 여러 웹 응용 프로그램 플랫폼 및 프레임 워크에서 광범위 한 성능 벤치 마크 를 수행 했습니다.Interestingly, TechEmpower conducted an extensive set of performance benchmarks across many web application platforms and frameworks. 상위 10 개 이상의 Node.js 및 기타 경쟁 플랫폼에서 .NET Core 점수가 매겨집니다..NET Core scored in the top 10 - well above Node.js and other competing platforms.

.NET Core는 Microsoft 및 GitHub의 .NET 커뮤니티에서 유지 관리 됩니다..NET Core is maintained by Microsoft and the .NET community on GitHub.

컨테이너Containers

오늘날 cloud native와 관련 된 모든 대화에서 언급 된 용어 컨테이너 를 듣게 됩니다.Nowadays, it's natural to hear the term container mentioned in any conversation concerning cloud native. 책의 클라우드 네이티브 패턴에서 Davis는 "컨테이너는 클라우드 네이티브 소프트웨어를 잘 실현할 수 있습니다." 라는 것을 관찰 합니다.In the book, Cloud Native Patterns, author Cornelia Davis observes that, "Containers are a great enabler of cloud-native software." 클라우드 네이티브 컴퓨팅 파운데이션은 마이크로 서비스 컨테이너 화를 클라우드 기본 구조 에 첫 번째 단계로 제공 합니다. 즉, 클라우드 기본 전환을 시작 하는 기업에 대 한 지침을 제공 합니다.The Cloud Native Computing Foundation places microservice containerization as the first step in their Cloud-Native Trail Map - guidance for enterprises beginning their cloud-native journey.

컨테이너 화 a 마이크로 서비스는 간단 하 고 간단 합니다.Containerizing a microservice is simple and straightforward. 코드, 해당 종속성 및 런타임은 컨테이너 이미지라는 이진으로 패키지 됩니다.The code, its dependencies, and runtime are packaged into a binary called a container image. 이미지는 이미지에 대 한 리포지토리 또는 라이브러리 역할을 하는 컨테이너 레지스트리에저장 됩니다.Images are stored in a container registry, which acts as a repository or library for images. 레지스트리는 개발 컴퓨터, 데이터 센터 또는 공용 클라우드에서 찾을 수 있습니다.A registry can be located on your development computer, in your data center, or in a public cloud. Docker 자체는 Docker 허브를 통해 공용 레지스트리를 유지 관리 합니다.Docker itself maintains a public registry via Docker Hub. Azure cloud는 컨테이너를 실행 하는 클라우드 응용 프로그램에 가까운 컨테이너 이미지를 저장 하는 컨테이너 레지스트리 기능을 제공 합니다.The Azure cloud features a container registry to store container images close to the cloud applications that will run them.

필요한 경우 이미지를 실행 중인 컨테이너 인스턴스로 변환 합니다.When needed, you transform the image into a running container instance. 인스턴스는 컨테이너 런타임 엔진이 설치 된 모든 컴퓨터에서 실행 됩니다.The instance runs on any computer that has a container runtime engine installed. 필요에 따라 컨테이너 화 된 서비스의 인스턴스를 여러 개 포함할 수 있습니다.You can have as many instances of the containerized service as needed.

그림 1-5은 단일 호스트에서 실행 되는 각각의 고유한 컨테이너에 있는 세 가지 마이크로 서비스를 보여 줍니다.Figure 1-5 shows three different microservices, each in its own container, running on a single host.

컨테이너 호스트에서 실행되는 여러 컨테이너

그림 1-5.Figure 1-5. 컨테이너 호스트에서 실행되는 여러 컨테이너Multiple containers running on a container host

각 컨테이너가 서로 다를 수 있는 고유한 종속성 및 런타임 집합을 유지 관리 하는 방법을 확인 합니다.Note how each container maintains its own set of dependencies and runtime, which can be different. 여기에는 동일한 호스트에서 실행 되는 여러 버전의 제품 마이크로 서비스이 표시 됩니다.Here, we see different versions of the Product microservice running on the same host. 각 컨테이너는 기본 호스트 운영 체제, 메모리 및 프로세서의 조각을 공유 하지만 서로 격리 되어 있습니다.Each container shares a slice of the underlying host operating system, memory, and processor, but is isolated from one another.

컨테이너 모델이 12 단계 응용 프로그램에서 "종속성" 원칙을 수용 하는 정도를 확인 합니다.Note how well the container model embraces the "Dependencies" principle from the Twelve-Factor Application.

요소 # 2는 "각 마이크로 서비스 자체 종속성을 격리 하 고 패키지 하 여 전체 시스템에 영향을 주지 않고 변경 내용을 수용 하도록 지정 합니다."Factor #2 specifies that "Each microservice isolates and packages its own dependencies, embracing changes without impacting the entire system."

컨테이너는 Linux 및 Windows 작업을 모두 지원 합니다.Containers support both Linux and Windows workloads. Azure 클라우드는 모두 개방적으로 수용 합니다.The Azure cloud openly embraces both. 흥미롭게도 Azure에서 가장 인기 있는 운영 체제가 되기 때문에 Windows Server가 아닌 Linux입니다.Interestingly, it's Linux, not Windows Server, that has become the most popular operating system in Azure.

여러 컨테이너 공급 업체가 존재 하는 반면 Docker는 사자의 시장 공유를 캡처 했습니다.While several container vendors exist, Docker has captured the lion's share of the market. 회사에서 소프트웨어 컨테이너 이동을 구동 했습니다.The company has been driving the software container movement. 클라우드 네이티브 응용 프로그램을 패키지, 배포 및 실행 하기 위한 사실상 표준이 되었습니다.It has become the de facto standard for packaging, deploying, and running cloud-native applications.

컨테이너는 무엇 인가요?Why containers?

컨테이너는 이식성을 제공 하 고 환경 간에 일관성을 보장 합니다.Containers provide portability and guarantee consistency across environments. 모든 항목을 단일 패키지로 캡슐화 하 여 기본 인프라에서 마이크로 서비스 및 해당 종속성을 격리 합니다.By encapsulating everything into a single package, you isolate the microservice and its dependencies from the underlying infrastructure.

Docker 런타임 엔진을 포함 하는 모든 환경에서 동일한 컨테이너를 배포할 수 있습니다.You can deploy that same container in any environment that has the Docker runtime engine. 또한 컨테이너 화 된 워크 로드는 프레임 워크, 소프트웨어 라이브러리 및 런타임 엔진을 사용 하 여 각 환경에 대 한 사전 구성 비용을 제거 합니다.Containerized workloads also eliminate the expense of pre-configuring each environment with frameworks, software libraries, and runtime engines.

기본 운영 체제 및 호스트 리소스를 공유 하 여 컨테이너는 전체 가상 컴퓨터 보다 훨씬 적은 공간을 차지 합니다.By sharing the underlying operating system and host resources, containers have a much smaller footprint than a full virtual machine. 크기가 작을수록 지정 된 호스트를 한 번에 실행할 수 있는 마이크로 서비스 수 또는 밀도가높아집니다.The smaller size increases the density, or number of microservices, that a given host can run at one time.

컨테이너 오케스트레이션Container orchestration

Docker와 같은 도구는 이미지를 만들고 컨테이너를 실행 하는 동안 관리 하는 도구도 필요 합니다.While tools such as Docker create images and run containers, you also need tools to manage them. 컨테이너 관리는 컨테이너 orchestrator 라는 특수 소프트웨어 프로그램을 사용 하 여 수행 됩니다.Container management is done with a special software program called a container orchestrator. 규모에 맞게 작동 하는 경우 컨테이너 오케스트레이션이 필수적입니다.When operating at scale, container orchestration is essential.

그림 1-6에서는 컨테이너 orchestrator 제공 하는 관리 작업을 보여 줍니다.Figure 1-6 shows management tasks that container orchestrators provide.

컨테이너 orchestrator

그림 1-6.Figure 1-6. 컨테이너 orchestratorWhat container orchestrators do

다음 표에서는 일반적인 오케스트레이션 작업을 설명 합니다.The following table describes common orchestration tasks.

작업Tasks 설명Explanation
일정 계획Scheduling 컨테이너 인스턴스를 자동으로 프로 비전 합니다.Automatically provision container instances.
선호도/선호도 방지Affinity/anti-affinity 컨테이너를 서로 가까운 곳 이나 멀리 프로 비전 하 여 가용성과 성능을 지원 합니다.Provision containers nearby or far apart from each other, helping availability and performance.
상태 모니터링Health monitoring 자동으로 오류를 검색 하 고 수정 합니다.Automatically detect and correct failures.
장애 조치Failover 실패 한 인스턴스를 정상 컴퓨터에 자동으로 다시 구축.Automatically reprovision failed instance to healthy machines.
확장Scaling 필요에 맞게 컨테이너 인스턴스를 자동으로 추가 또는 제거 합니다.Automatically add or remove container instance to meet demand.
네트워킹Networking 컨테이너 통신을 위한 네트워킹 오버레이를 관리 합니다.Manage a networking overlay for container communication.
서비스 검색Service Discovery 컨테이너를 사용 하 여 서로를 찾습니다.Enable containers to locate each other.
롤링 업그레이드Rolling Upgrades 가동 중지 시간이 0 인 증분 업그레이드를 조정 합니다.Coordinate incremental upgrades with zero downtime deployment. 문제가 있는 변경 내용을 자동으로 롤백합니다.Automatically roll back problematic changes.

Orchestrator는이 장의 앞부분에서 설명한 12 단계 응용 프로그램에서 disposability 및 동시성 원리를 수용 하는 방법에 유의 하세요.Note how orchestrators embrace the disposability and concurrency principles from the Twelve-Factor Application, discussed earlier in the chapter.

요소 # 9는 "서비스 인스턴스를 삭제 가능 하도록 지정 하 여 확장성 기회를 높이고 정상적인 종료를 찾은 다음 하 여 시스템을 올바른 상태로 유지 하도록 지정 합니다. Docker 컨테이너는 기본적으로이 요구 사항을 충족 합니다. "Factor #9 specifies that "Service instances should be disposable, favoring fast startups to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker containers along with an orchestrator inherently satisfy this requirement."

요소 # 8은 "서비스가 사용 가능한 가장 강력한 컴퓨터에서 단일 큰 인스턴스를 확장 하는 것과는 달리, 많은 수의 작은 동일한 프로세스 (복사본)에 걸쳐 규모를 확장 하도록 지정 합니다."Factor #8 specifies that "Services scale out across a large number of small identical processes (copies) as opposed to scaling-up a single large instance on the most powerful machine available."

여러 컨테이너 orchestrator 있는 동안 Kubernetes 는 클라우드 네이티브 세계에 대 한 사실상의 표준이 되었습니다.While several container orchestrators exist, Kubernetes has become the de facto standard for the cloud-native world. 컨테이너 화 된 워크 로드를 관리 하기 위한 이식 가능 하 고 확장 가능한 오픈 소스 플랫폼입니다.It's a portable, extensible, open-source platform for managing containerized workloads.

Kubernetes의 고유한 인스턴스를 호스트할 수 있지만이를 위해 리소스를 프로 비전 하 고 관리 해야 합니다 .이는 복잡할 수 있습니다.You could host your own instance of Kubernetes, but then you'd be responsible for provisioning and managing its resources - which can be complex. Azure cloud Kubernetes는 관리 서비스인 AKS (Azure Kubernetes service)로 제공 됩니다.The Azure cloud features Kubernetes as a managed service, Azure Kubernetes Service (AKS). 관리 서비스를 사용 하면 해당 기능을 설치 및 유지 관리 하지 않고도 해당 기능을 완벽 하 게 활용할 수 있습니다.A managed service allows you to fully leverage its features, without having to install and maintain it.

Azure Kubernetes 서비스는 클라우드 네이티브 응용 프로그램 크기 조정2 장에서 설명 합니다.Azure Kubernetes Services is covered in detail Chapter 2, Scaling Cloud-Native Applications.

서비스 지원Backing services

클라우드 네이티브 시스템은 데이터 저장소, 메시지 브로커, 모니터링 및 id 서비스와 같은 다양 한 보조 리소스에 따라 달라 집니다.Cloud-native systems depend upon many different ancillary resources, such as data stores, message brokers, monitoring, and identity services. 이러한 서비스를 지원 서비스라고 합니다.These services are known as backing services.

그림 1-7은 클라우드 네이티브 시스템에서 사용 하는 여러 일반적인 지원 서비스를 보여 줍니다.Figure 1-7 shows many common backing services that cloud-native systems consume.

일반적인 지원 서비스

그림 1-7.Figure 1-7. 일반적인 지원 서비스Common backing services

지원 서비스는 12 단계 응용 프로그램에서 "상태 비저장" 원칙을 승격 합니다 .이에 대해서는이 장의 앞부분에서 설명 했습니다.Backing services promote the "Statelessness" principle from the Twelve-Factor Application, discussed earlier in the chapter.

요소 # 6 은 "각 마이크로 서비스가 실행 중인 다른 서비스와 격리 된 자체 프로세스에서 실행 되도록 지정 합니다.Factor #6 specifies that, "Each microservice should execute in its own process, isolated from other running services. 분산 캐시 또는 데이터 저장소와 같은 지원 서비스에 필요한 상태를 외부화. "Externalize required state to a backing service such as a distributed cache or data store."

자신의 지원 서비스를 호스트할 수 있지만 이러한 리소스를 라이선싱, 프로 비전 및 관리할 책임이 있습니다.You could host your own backing services, but then you'd be responsible for licensing, provisioning, and managing those resources.

클라우드 공급자는 다양 한 관리 지원 서비스를 제공 합니다.Cloud providers offer a rich assortment of managed backing services. 서비스를 소유 하는 대신 서비스를 사용 하기만 하면 됩니다.Instead of owning the service, you simply consume it. 공급자는 리소스를 대규모로 작동 하 고 성능, 보안 및 유지 관리에 대 한 책임을 집니다.The provider operates the resource at scale and bears the responsibility for performance, security, and maintenance. 모니터링, 중복성 및 가용성은 서비스에 기본 제공 됩니다.Monitoring, redundancy, and availability are built into the service. 공급자는 관리 되는 서비스를 완전히 지원 합니다. 티켓을 열고 문제를 해결 합니다.Providers fully support their managed services - open a ticket and they fix your issue.

클라우드 기본 시스템은 클라우드 공급 업체의 관리 되는 백업 서비스를 선호 합니다.Cloud-native systems favor managed backing services from cloud vendors. 시간과 노력이 절약 됩니다.The savings in time and labor are great. 사용자가 직접 호스트 하 고 문제를 발생 시킬 위험이 있습니다.The operational risk of hosting your own and experiencing trouble can get expensive fast.

가장 좋은 방법은 지원 서비스를 연결 된 리소스로처리 하는 것입니다 .이는 외부 구성에 저장 된 정보 (URL 및 자격 증명)를 사용 하 여 마이크로 서비스에 동적으로 바인딩됩니다.A best practice is to treat a backing service as an attached resource, dynamically bound to a microservice with information (a URL and credentials) stored in an external configuration. 이 지침은이 장에서 설명 하는 12 단계 응용 프로그램에서 설명 합니다.This guidance is spelled out in the Twelve-Factor Application, discussed earlier in the chapter.

요소 # 4 는 주소 지정 가능 URL을 통해 지원 서비스를 노출 하도록 지정 합니다.Factor #4 specifies that backing services "should be exposed via an addressable URL. 이렇게 하면 응용 프로그램에서 리소스를 분리 하 여 상호 교환이 가능 합니다. "Doing so decouples the resource from the application, enabling it to be interchangeable."

요소 # 3 은 "구성 정보를 코드 외부의 구성 관리 도구를 통해 마이크로 서비스 및 표면화 된 외부로 이동" 하도록 지정 합니다.Factor #3 specifies that "Configuration information is moved out of the microservice and externalized through a configuration management tool outside of the code."

이 패턴을 사용 하면 코드를 변경 하지 않고 지원 서비스를 연결 및 분리할 수 있습니다.With this pattern, a backing service can be attached and detached without code changes. 마이크로 서비스를 QA에서 스테이징 환경으로 승격할 수 있습니다.You might promote a microservice from QA to a staging environment. 준비의 지원 서비스를 가리키도록 마이크로 서비스 구성을 업데이트 하 고 환경 변수를 통해 컨테이너에 설정을 삽입 합니다.You update the microservice configuration to point to the backing services in staging and inject the settings into your container through an environment variable.

클라우드 공급 업체는 자체 지원 서비스와 통신할 수 있는 Api를 제공 합니다.Cloud vendors provide APIs for you to communicate with their proprietary backing services. 이러한 라이브러리는 배관 및 복잡성을 캡슐화 합니다.These libraries encapsulate the plumbing and complexity. 이러한 Api와 직접 통신 하는 것은 코드를 백업 서비스에 긴밀 하 게 두는 것입니다.Communicating directly with these APIs will tightly couple your code to the backing service. 공급 업체 API의 구현 세부 정보를 안전 하 게 유지 하는 것이 더 좋습니다.It's a better practice to insulate the implementation details of the vendor API. Intermediation 계층 또는 중간 API를 도입 하 여 서비스 코드에 일반 작업을 노출 합니다.Introduce an intermediation layer, or intermediate API, exposing generic operations to your service code. 이러한 느슨한 결합을 통해 한 지원 서비스를 다른 서비스 코드를 변경 하지 않고도 다른 공용 클라우드로 전환할 수 있습니다.This loose coupling enables you to swap out one backing service for another or move your code to a different public cloud without having to make changes to the mainline service code.

지원 서비스에 대 한 자세한 내용은 5 장, 클라우드 네이티브 데이터 패턴및 4 장, 클라우드 네이티브 통신 패턴을 참조 하세요.Backing services are discussed in detail Chapter 5, Cloud-Native Data Patterns, and Chapter 4, Cloud-Native Communication Patterns.

AutomationAutomation

앞서 살펴본 것 처럼 클라우드 네이티브 시스템은 마이크로 서비스, 컨테이너 및 최신 시스템 디자인을 수용 하 여 속도와 민첩성을 구현 합니다.As you've seen, cloud-native systems embrace microservices, containers, and modern system design to achieve speed and agility. 그러나이는 스토리의 일부일 뿐입니다.But, that's only part of the story. 이러한 시스템이 실행 되는 클라우드 환경을 프로 비전 하려면 어떻게 해야 하나요?How do you provision the cloud environments upon which these systems run? 앱 기능 및 업데이트를 신속 하 게 배포 하려면 어떻게 해야 하나요?How do you rapidly deploy app features and updates? 전체 사진을 어떻게 반올림 하나요?How do you round out the full picture?

널리 승인 된 인프라 사례를 코드또는 IaC로 입력 합니다.Enter the widely accepted practice of Infrastructure as Code, or IaC.

IaC를 사용 하 여 플랫폼 프로 비전 및 응용 프로그램 배포를 자동화 합니다.With IaC, you automate platform provisioning and application deployment. 기본적으로 DevOps 사례에 테스트 및 버전 관리와 같은 소프트웨어 엔지니어링 사례를 적용 합니다.You essentially apply software engineering practices such as testing and versioning to your DevOps practices. 인프라 및 배포는 자동화 되 고 일관 되며 반복 가능 합니다.Your infrastructure and deployments are automated, consistent, and repeatable.

인프라 자동화Automating infrastructure

Azure Resource Manager, terraform 및 Azure CLI와 같은 도구를 사용 하 여 필요한 클라우드 인프라를 선언적으로 스크립팅할 수 있습니다.Tools like Azure Resource Manager, Terraform, and the Azure CLI, enable you to declaratively script the cloud infrastructure you require. 리소스 이름, 위치, 용량 및 암호는 매개 변수화 된 및 동적입니다.Resource names, locations, capacities, and secrets are parameterized and dynamic. 이 스크립트는 프로젝트의 아티팩트로 버전이 지정 되 고 소스 제어에 체크 인 됩니다.The script is versioned and checked into source control as an artifact of your project. 스크립트를 호출 하 여 QA, 스테이징 및 프로덕션과 같은 시스템 환경에서 일관 되 고 반복 가능한 인프라를 프로 비전 합니다.You invoke the script to provision a consistent and repeatable infrastructure across system environments, such as QA, staging, and production.

내부적으로, IaC는 idempotent 이며,이는 부작용 없이 동일한 스크립트를 반복 해 서 실행할 수 있음을 의미 합니다.Under the hood, IaC is idempotent, meaning that you can run the same script over and over without side effects. 팀에서 변경 해야 하는 경우 스크립트를 편집 하 고 다시 실행 합니다.If the team needs to make a change, they edit and rerun the script. 업데이트 된 리소스만 영향을 받습니다.Only the updated resources are affected.

문서에서 코드로 서의 인프라 란 무엇이며, 제작자 Sam Guckenheimer는 "IaC를 구현 하는 팀이 안정적인 환경을 신속 하 고 대규모로 제공할 수 있는 방법에 대해 설명 합니다.In the article, What is Infrastructure as Code, Author Sam Guckenheimer describes how, "Teams who implement IaC can deliver stable environments rapidly and at scale. 팀은 환경을 수동으로 구성 하는 것을 방지 하 고 코드를 통해 환경의 원하는 상태를 표시 하 여 일관성을 적용 합니다.Teams avoid manual configuration of environments and enforce consistency by representing the desired state of their environments via code. IaC를 사용 하 여 인프라를 배포 하는 것은 반복 가능 하며, 구성 드리프트 또는 누락 종속성으로 인 한 런타임 문제를 방지Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies. DevOps 팀은 통합 된 사례 및 도구 집합과 함께 작업 하 여 응용 프로그램 및 지원 인프라를 신속 하 고 안정적 이며 대규모로 제공할 수 있습니다. "DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly, reliably, and at scale."

배포 자동화Automating deployments

앞에서 설명한 12 단계 응용 프로그램은 완성 된 코드를 실행 중인 응용 프로그램으로 변환할 때 별도의 단계를 호출 합니다.The Twelve-Factor Application, discussed earlier, calls for separate steps when transforming completed code into a running application.

요소 # 5 는 "각 릴리스가 빌드, 릴리스 및 실행 단계에서 엄격한 분리를 적용 해야 함을 지정 합니다.Factor #5 specifies that "Each release must enforce a strict separation across the build, release and run stages. 각각은 고유한 ID로 태그를 지정 하 고 롤백하는 기능을 지원 해야 합니다. "Each should be tagged with a unique ID and support the ability to roll back."

최신 CI/CD 시스템은이 원칙을 충족 하는 데 도움이 됩니다.Modern CI/CD systems help fulfill this principle. 별도의 배포 단계를 제공 하 고 사용자가 쉽게 사용할 수 있는 일관 되 고 품질 코드를 보장 하는 데 도움이 됩니다.They provide separate deployment steps and help ensure consistent and quality code that's readily available to users.

그림 1-8에서는 배포 프로세스를 분리 하는 방법을 보여 줍니다.Figure 1-8 shows the separation across the deployment process.

CI/CD 파이프라인의 배포 단계

그림 1-8.Figure 1-8. CI/CD 파이프라인의 배포 단계Deployment steps in a CI/CD Pipeline

위의 그림에서는 작업 분리에 특히 주의를 기울여야 합니다.In the previous figure, pay special attention to separation of tasks.

개발자는 개발 환경에서 기능을 생성 하 여 코드의 "내부 루프", 실행 및 디버그를 반복 합니다.The developer constructs a feature in their development environment, iterating through what is called the "inner loop" of code, run, and debug. 완료 되 면 코드는 GitHub, Azure DevOps 또는 BitBucket와 같은 코드 리포지토리로 푸시됩니다 .When complete, that code is pushed into a code repository, such as GitHub, Azure DevOps, or BitBucket.

푸시는 코드를 이진 아티팩트로 변환 하는 빌드 단계를 트리거합니다.The push triggers a build stage that transforms the code into a binary artifact. 작업은 CI (지속적인 통합 ) 파이프라인을 사용 하 여 구현 됩니다.The work is implemented with a Continuous Integration (CI) pipeline. 응용 프로그램을 자동으로 빌드, 테스트 및 패키지 합니다.It automatically builds, tests, and packages the application.

릴리스 단계는 이진 아티팩트를 선택 하 고, 외부 응용 프로그램 및 환경 구성 정보를 적용 하 고, 변경할 수 없는 릴리스를 생성 합니다.The release stage picks up the binary artifact, applies external application and environment configuration information, and produces an immutable release. 릴리스가 지정 된 환경에 배포 됩니다.The release is deployed to a specified environment. 작업은 CD (지속적인 업데이트 ) 파이프라인을 사용 하 여 구현 됩니다.The work is implemented with a Continuous Delivery(CD) pipeline. 각 릴리스를 식별할 수 있어야 합니다.Each release should be identifiable. "이 배포가 응용 프로그램의 릴리스 2.1.1을 실행 하 고 있습니다." 라고 표시 될 수 있습니다.You can say, "This deployment is running Release 2.1.1 of the application."

마지막으로, 릴리스된 기능은 대상 실행 환경에서 실행 됩니다.Finally, the released feature is run in the target execution environment. 릴리스를 변경할 수 없습니다. 즉, 모든 변경 내용은 새 릴리스를 만들어야 합니다.Releases are immutable meaning that any change must create a new release.

이러한 사례를 적용 하면 조직에서 소프트웨어를 제공 하는 방법을 크게 진화 하 고 있습니다.Applying these practices, organizations have radically evolved how they ship software. 대다수는 분기별 릴리스에서 주문형 업데이트로 이동 했습니다.Many have moved from quarterly releases to on-demand updates. 목표는 수정 비용이 저렴 한 개발 주기의 초기에 문제를 파악 하는 것입니다.The goal is to catch problems early in the development cycle when they're less expensive to fix. 통합 간의 지속 시간이 길수록 더 비싼 문제가 해결 됩니다.The longer the duration between integrations, the more expensive problems become to resolve. 통합 프로세스에서 일관성을 사용 하면 팀에서 코드 변경 내용을 더 자주 커밋할 수 있으므로 공동 작업 및 소프트웨어 품질을 높일 수 있습니다.With consistency in the integration process, teams can commit code changes more frequently, leading to better collaboration and software quality.

Azure PipelinesAzure Pipelines

Azure 클라우드에는 그림 1-9에 표시 된 Azure DevOps 제품의 일부인 AZURE PIPELINES이라는 새로운 CI/CD 서비스가 포함 되어 있습니다.The Azure cloud includes a new CI/CD service entitled Azure Pipelines, which is part of the Azure DevOps offering shown in Figure 1-9.

DevOps의 Azure Pipelines

그림 1-9.Figure 1-9. Azure DevOps 제품Azure DevOps offerings

Azure Pipelines는 CI (지속적인 통합) 및 CD (지속적인 업데이트)를 결합 하는 클라우드 서비스입니다.Azure Pipelines is a cloud service that combines continuous integration (CI) and continuous delivery (CD). 코드를 자동으로 테스트, 빌드 및 모든 대상에 제공할 수 있습니다.You can automatically test, build, and ship your code to any target.

앱에 대 한 코드의 나머지 부분과 함께 YAML 파일의 코드에서 파이프라인을 정의 합니다.You define your pipeline in code in a YAML file alongside the rest of the code for your app.

  • 파이프라인은 코드를 사용 하 여 버전이 지정 되며 동일한 분기 구조를 따릅니다.The pipeline is versioned with your code and follows the same branching structure.
  • 끌어오기 요청 및 분기 빌드 정책의 코드 검토를 통해 변경 내용의 유효성을 검사합니다.You get validation of your changes through code reviews in pull requests and branch build policies.
  • 사용 하는 모든 분기는 azure-pipelines 파일을 수정 하 여 빌드 정책을 사용자 지정할 수 있습니다.Every branch you use can customize the build policy by modifying the azure-pipelines.yml file.
  • 파이프라인 파일이 버전 제어에 체크 인 되 고 문제가 있는 경우 조사할 수 있습니다.The pipeline file is checked into version control and can be investigated if there's a problem.

Azure Pipelines 서비스는 대부분의 Git 공급자를 지원 하 고 Linux, macOS 또는 Windows 플랫폼에서 작성 된 응용 프로그램에 대 한 배포 파이프라인을 생성할 수 있습니다.The Azure Pipelines service supports most Git providers and can generate deployment pipelines for applications written on the Linux, macOS, or Windows platforms. 여기에는 Java, .NET, JavaScript, Python, PHP, Go, XCode 및 c + +에 대 한 지원이 포함 됩니다.It includes support for Java, .NET, JavaScript, Python, PHP, Go, XCode, and C++.