나에겐 등산스틱이 2개 있다.

몇년 전 한라산을 등반할 때 친구에게 선물받는 것과,

'23년 지리산 등반을 위해 구매한 것이 있다.

친구에게 선물받은 건, 당해년도의 한라산 등반과 지리산 등반 때 사용했고,

올해 구매한 스틱은 올해 지리산 등반을 위해 좀 더 가볍고 편리한 것을 구매해서 사용했다.

-- '23년도 스틱의 사용내역 --

'23. 5. (지리산) 성삼재 - (세석대피소 1박) - 천왕봉 - 장터목 - 중산리, 51.70km, 16시간 28분

'23. 6. (한라산) 관음사 - 성판악, 20.03km, 6시간 17분

'23. 6. (한라산) 영실 - 어리목, 누나들이 하나 씩 사용, 9.50km, 3시간 9분

'23. 6. 24. (설악산) 오색 - 대청 - 희운각 - 공룡능선 - 마등령 - 비선대 - 설악동, 22.53km, 9시간 46분

'23. 7. 12. (하남 검단산) 안내소 - 헬기장 - 정상 - 유길준 묘 - 안내소, 7Km, 2시간 15분.  끝.

전략이라 거창한 이름이 좀 부담스럽긴 하지만,

동서울에서 성삼재로 가는 버스는 지리산의 봄철 산불조심 기간이 종료되는 4월 말부터 시작되고 한겨울에는 운행하지 않는다.

[여행 전]

1. (버스예매) 성삼재 버스를 이용해 지리산에 가려면 버스 승차권 예매 시작일을 잘 확인하여 1개월 전에 예매해야 한다.

2. (대피소 신청) 대피소는 2주 전에 선착순으로 신청할 수 있다.

[여행]

1. (코스) 성삼재 - 노고단 - 반야봉 - 세석대피소(1박) - 장터목대피소 - 천왕봉 - 중산리

2. (서울복귀 팁)

  가. 천왕봉 일출을 본다면, 중산리에서 10:30 버스를 타고 원지로 이동할 수 있도록 하산할 수 있다면,

      원지에서 서울남부터미널로 오는 11:20 버스를 이용할 수 있다.

      ** 중산리에서 원지로 가는 버스는 직행이 아니고 시내버스처럼 여기저기 들렀다 가는데, 11:20까지는 간신히 맞출 수 있다.

  나. 하산시간을 맞추지 못한다면 원지에서 15:35에 남부터미널로 가는 버스도 있다.

  다. 아니면, 진주로 이동하여 고속버스를 타야 하는데

  ** 모든 버스편은 주말일 경우 매진되는 경우가 많으니 미리 예매해야 한다.

행정안전부에서 공공부문 정보자원 클라우드 네이티브 전환 추진계획을 수립한 모양이다.

클라우드 네이티브란 무엇인가?

CNCF Cloud Native Definition v1.0

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.

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.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고

동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다.

이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다.

Cloud Native Computing Foundation은 벤더 중립적인 오픈 소스 프로젝트 생태계를 육성하고 유지함으로써 해당 패러다임 채택을 촉진한다. 우리 재단은 최신 기술 수준의 패턴을 대중화하여 이런 혁신을 누구나 접근 가능하도록 한다.

(AWS) 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축, 배포 및 관리할 때의 소프트웨어 접근 방식

(Oracle)  클라우드 제공 모델에서 제공하는 분산 컴퓨팅을 활용하기 위해 애플리케이션을 구축 및 실행하는 개념을 의미합니다. 클라우드 네이티브 앱은 클라우드가 제공하는 확장성, 탄력성, 복원성, 유연성을 활용하도록 설계 및 구축되었습니다.

(Column) 클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 방식

(Microsoft) 클라우드 네이티브 아키텍처 및 기술은 클라우드에서 빌드된 워크로드를 디자인, 생성 및 운영하는 접근 방식으로, 클라우드 컴퓨팅 모델을 최대한 활용합니다

(NUTANIX)애플리케이션이 구축, 배포, 관리되는 방식을 혁신하는 전용 기술, 툴, 프로세스와 더불와 새로운 수준의 소프트웨어 추상화를 수반합니다.

(HPE) 클라우드 네이티브 애플리케이션은 애플리케이션에서 클라우드 환경을 활용하여 생산성을 높이는 최신 애플리케이션 개발 방식입니다. 전체 애플리케이션은 이러한 방식으로 작성, 개발, 배포되며 지속적으로 업데이트될 수 있습니다.

(ITWORLD) 클라우드 네이티브 애플리케이션은 클라우드의 동적이면서 확장적이고 매우 가용적인 속성을 지도 원칙으로 하여 구축된 소프트웨어 시스템이다. 클라우드 네이티브 애플리케이션 아키텍처는 소프트웨어 개발자가 기존 접근 방식을 사용할 때 직면하는 과제에 대한 대응이다. 특히 클라우드 네이티브 애플리케이션은 다음과 같다. 

(AWS) 클라우드 네이티브 애플리케이션은 마이크로서비스라는 여러 개의 상호 의존적인 소규모 서비스로 구성된 소프트웨어 프로그램입니다

클라우드 네이티브 스택이란 무엇인가요?

클라우드 네이티브 스택은 개발자가 클라우드 네이티브 애플리케이션을 구축, 관리 및 실행하는 데 사용하는 클라우드 네이티브 기술 계층을 설명하는 용어로, 다음과 같이 분류됩니다.

인프라 계층

인프라 계층은 클라우드 네이티브 스택의 기반입니다. 서드 파티 클라우드 제공업체가 관리하는 운영 체제, 스토리지, 네트워크 및 기타 컴퓨팅 리소스로 구성됩니다. 

프로비저닝 계층

프로비저닝 계층은 클라우드 환경을 할당하고 구성하는 다양한 클라우드 서비스로 구성됩니다.

런타임 계층

런타임 계층은 컨테이너가 작동할 수 있는 클라우드 네이티브 기술을 제공합니다. 여기에는 클라우드 데이터 스토리지, 네트워킹 기능, 그리고 컨테이너화된 리소스와 같은 컨테이너 런타임이 포함됩니다. 

오케스트레이션 및 관리 계층

오케스트레이션 및 관리는 다양한 클라우드 구성 요소를 통합하여 하나의 유닛으로 작동하도록 하는 역할을 합니다. 이는 기존 컴퓨팅 환경에서 운영 체제가 작동하는 방식과 유사합니다. 개발자는 Kubernetes와 같은 오케스트레이션 도구를 사용하여 다양한 시스템에서 클라우드 애플리케이션을 배포, 관리 및 확장합니다. 

애플리케이션 정의 및 개발 계층

이 클라우드 네이티브 스택 계층은 클라우드 네이티브 애플리케이션을 구축하기 위한 소프트웨어 기술로 구성됩니다. 예를 들어 개발자는 데이터베이스, 메시징, 컨테이너 이미지, 지속적 통합(CI) 및 지속적 전달(CD) 도구와 같은 클라우드 기술을 사용하여 클라우드 애플리케이션을 구축합니다. 

관측성 및 분석 도구

관측성 및 분석 도구는 클라우드 애플리케이션의 시스템 상태를 모니터링 및 평가하고 개선합니다. 개발자는 도구를 사용하여 CPU 사용량, 메모리, 지연 시간 등의 지표를 모니터링함으로써 앱의 서비스 품질에 문제가 없는지 확인합니다. 

 

클라우드 네이티브 정의

클라우드 네이티브라는 용어는 클라우드 제공 모델에서 제공하는 분산 컴퓨팅을 활용하기 위해 애플리케이션을 구축 및 실행하는 개념을 의미합니다. 클라우드 네이티브 앱은 클라우드가 제공하는 확장성, 탄력성, 복원성, 유연성을 활용하도록 설계 및 구축되었습니다.

Cloud Native Computing Foundation(CNCF)이 정의한 바와 같이 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 하이브리드 클라우드에서 확장 가능한 애플리케이션을 구축하고 실행할 수 있도록 지원합니다. 컨테이너, 서비스 메시, 마이크로 서비스, 변경 불가능한 인프라 및 선언형 API(애플리케이션 프로그래밍 인터페이스)와 같은 기능은 이러한 접근 방식을 가장 잘 보여줍니다.

이러한 기능은 탄력적이고 관리 가능하며 관찰 가능한 느슨하게 결합된 시스템을 사용할 수 있도록 해주며, 이를 통해 엔지니어는 최소한의 노력으로 자주 변경 사항을 적용할 수 있습니다.

클라우드 네이티브 서비스 살펴보기

사용자가 독보적인 응답성과 지속적인 혁신을 기대하는 최근의 복잡한 애플리케이션 환경에서는 비즈니스 시스템을 보다 전략적이고 유연하게 운영해야 합니다. 클라우드 네이티브의 관건은 민첩성을 유지하면서 빠르게 움직이는 것입니다.

클라우드 네이티브 서비스는 Kubernetes, Docker, 서버리스 함수, API 및 Kafka와 같은 기술을 사용하여 최신 애플리케이션 개발을 지원합니다. 업계 최고의 클라우드 제공업체를 통해 클라우드 툴과 서비스를 구현하므로 개발자가 운영 작업을 줄이고 애플리케이션을 더 빠르게 구축할 수 있습니다. 클라우드 네이티브 서비스는 개발자에게 마이크로서비스, 서버리스 함수와 같은 클라우드 네이티브 애플리케이션을 구축, 배포, 관리할 수 있는 종합적인 표준 기반 플랫폼을 제공합니다.

클라우드 네이티브 서비스를 사용하여 우수한 소프트웨어 제공

클라우드 네이티브의 잠재력을 최대한 활용하여 탄력 있고 관리 가능하며 확장 가능한 최신 클라우드 앱을 빠르고 쉽게 구축할 수 있는 방법을 알아보세요.

클라우드 네이티브 기술로 이전한 결과, 조직 플랫폼 전반에 걸쳐 고객 경험을 극대화할 수 있도록 하여 소프트웨어 개발 및 비즈니스 모델을 영구적으로 변경했습니다. 얼마 전까지만 해도 대다수 조직의 IT 인프라는 '클라우드 친화적'이었습니다. 클라우드로 전환한 IT 팀은 클라우드 네이티브 애플리케이션도 만들어 투자를 극대화하지 않으면 경쟁에서 크게 불리한 입장에 놓이게 됩니다. 기업이 경쟁사와 차별화되는 동시에 살아남기 위해서는 비즈니스 요구사항을 신속하게 조정하고 반복해야 합니다. 클라우드 인프라스트럭쳐는 탄력성과 온디맨드 기능을 갖추고 있어 모든 비즈니스를 클라우드 네이티브로 전환할 수 있습니다.

클라우드 네이티브 아키텍처란?

클라우드 네이티브 아키텍처는 기존의 온프레미스 인프라가 아닌 클라우드에 존재하도록 특별히 설계된 애플리케이션 또는 서비스의 설계를 말합니다. 성공적인 클라우드 전용 아키텍처는 유지보수가 용이하고 차세대 클라우드의 지원을 받는 동시에 비용 효율적이고 자가 복구가 가능해야 합니다. 클라우드 네이티브 아키텍처는 레거시 시스템에 비해 물리적 서버에 의존하지 않고도 더 높은 수준의 유연성을 제공합니다.

마이크로서비스와 서버리스 함수는 클라우드 네이티브 아키텍처에서 중대한 역할을 수행할 수 있습니다. 마이크로서비스는 클라우드 전용 애플리케이션 아키텍처의 핵심이며 클라우드로 전환하는 기업의 필수 도구가 되었습니다. 마이크로서비스는 애플리케이션을 여러 개의 독립된 서비스로 배열하며 각 서비스는 특정 기능을 제공합니다. 많은 소프트웨어 회사들이 마이크로서비스를 사용하고 있는데 이는 마이크로서비스가 DevOps를 지원하고, 유연성을 제공하며, 확장성을 향상시키는 동시에 비용을 절감해주기 때문입니다. 클라우드 네이티브 마이크로 서비스는 API를 통해 서로 통신하며 이벤트 기반 구조를 사용하여 각 애플리케이션의 전반적인 성능을 향상시킵니다. Oracle Cloud Native 서비스는 CNCF 트레일 맵을 따라 여정을 간소화하고 기업이 모던 클라우드 전용 애플리케이션의 구축, 배포, 관리를 쉽게 시작할 수 있도록 합니다.

기능

서버리스 함수이라는 용어는 개발자의 생산성 향상에 중점을 두는 구조 스타일을 나타냅니다. 서버리스 애플리케이션을 사용하면 이벤트 기반 아키텍처 및 다양한 서비스형 백엔드(BaaS) 모델을 통해 서비스형 함수(FaaS) 기반 플랫폼에서 코드를 작성할 수 있으며, 프로비저닝, 패치 적용, 확장, 보안, 고가용성 등에 대해 걱정할 필요가 없습니다. Oracle Functions와 같은 FaaS 플랫폼을 사용하면 애플리케이션이 이벤트에 의해 트리거될 때 동적으로 예약되고 요청 시 실행되는 작은 코드 조각(나노서비스)으로 분할됩니다. 이러한 접근 방식의 장점은 필요할 때만 코드가 호출 및 실행되며 실행 기간 동안 사용한 리소스에 대해서만 비용을 지불한다는 것입니다. 이는 애플리케이션이 서버에 로드되고 대부분의 시간을 요청을 기다리며 유휴 상태로 보내는 기존 서버와는 다른 방식입니다. 따라서 서버리스 컴퓨팅의 경우 유휴 리소스에 대한 비용은 지불하지 않고 실제로 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불합니다.

Cloud native services

Container Registry

OCI Container Registry는 컨테이너 이미지를 안전하게 저장하고 공유하기 위한 Oracle이 관리하는표준 기반의 개방형 Docker 레지스트리 서비스입니다. 엔지니어는 익숙한 Docker 명령줄 인터페이스(CLI)와 API를 사용하여 Docker 이미지를 쉽게 푸시하고 가져올 수 있습니다. 컨테이너 레지스트리는 컨테이너 수명주기를 지원하기 위해 Container Engine for Kubernetes, Identity and Access Management(IAM), Visual Builder Studio, 타사 개발자 및 DevOps 도구와 함께 작동합니다.Oracle’s

통지

OCI 통지는 Slack, PagerDuty, ServiceNow를 비롯한 경보 및 메시지를 Oracle Cloud Functions, 이메일, SMS 및 메시지 전달 파트너에게 전송하는 고가용성의 저지연성 게시/구독(pub/sub) 서비스입니다. 이 서비스는 안전한 액세스를 위해 OCI Identity and Access Management와 통합되어 트래픽 폭주 중에도 각 메시지를 전달합니다. 통지는 확장 가능하고 신뢰할 수 있는 클라우드 전용 애플리케이션을 구축하는 데 도움이 됩니다.

Streaming

OCI Streaming service는 개발자와 데이터 과학자를 위한 실시간 서버 미사용 Apache Kafka 호환 이벤트 스트리밍 플랫폼입니다. 이 관리형 이벤트 스트리밍 서비스는 실시간 스트리밍 데이터를 대규모로 수집, 저장 및 처리하며 널리 사용되는 오픈 소스인 Kafka API와의 완벽한 호환을 통해 종속성 문제를 줄입니다.

Container Engine

Container Engine for Kubernetes(OKE)는 모던 클라우드 네이티브 애플리케이션을 구축하는 데 필요한 시간과 비용을 줄일 수 있는 Oracle이 관리하는 컨테이너 통합 관리 서비스입니다. 다른 대부분의 공급업체와는 달리 Oracle Cloud Infrastructure는 Container Engine for Kubernetes를 성능이 뛰어나고 비용이 저렴한 컴퓨팅 형태에서 실행되는 무료 서비스로 제공합니다. DevOps 엔지니어는 수정되지 않은 오픈 소스 Kubernetes를 사용하여 애플리케이션 워크로드 이동성을 지원하고 업데이트와 패치를 자동화하여 운영을 간소화할 수 있습니다.

기능

Oracle Cloud Functions는 개발자가 인프라를 관리하지 않고도 애플리케이션을 생성, 실행 및 확장할 수 있는 서버리스 플랫폼으로, OCI, 플랫폼 서비스 및 SaaS 애플리케이션과도 통합됩니다. Functions는 오픈 소스 Fn Project를 기반으로 하기 때문에 개발자가 다른 클라우드와 온프레미스 환경으로 쉽게 이식 할 수 있는 애플리케이션을 생성할 수 있습니다. 함수 기반 코드는 일반적으로 짧은 기간 동안 실행되며 고객은 사용한 리소스에 대해서만 비용을 지불하면 됩니다.

Microsoft - 클라우드 네이티브란?

 팁

이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 전자책에서 발췌한 것으로, Docs 또는 오프라인에서 읽을 수 있는 다운로드 가능한 무료 PDF로 제공됩니다.NET.

PDF 다운로드

수행 중인 작업을 중지하고 동료에게 "클라우드 네이티브"라는 용어를 정의하도록 요청합니다. 몇 가지 다른 답변을 얻을 수 있는 좋은 기회가 될 것입니다.

간단한 정의로 시작해 보겠습니다.

‘클라우드 네이티브 아키텍처 및 기술은 클라우드에서 빌드된 워크로드를 디자인, 생성 및 운영하는 접근 방식으로, 클라우드 컴퓨팅 모델을 최대한 활용합니다.’

Cloud Native Computing Foundation은 다음과 같은 공식 정의를 제공합니다.

클라우드 네이티브 기술을 통해 조직은 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 최신 동적 환경에서 스케일링 가능한 애플리케이션을 빌드하고 실행할 수 있습니다. 이 방법의 예로 컨테이너, 서비스 메시, 마이크로 서비스, 변경할 수 없는 인프라 및 선언적 API를 들 수 있습니다.

이러한 기술을 통해 복원력 있고 관리 가능하며 관찰 가능한 느슨하게 결합된 시스템을 사용할 수 있습니다. 강력한 자동화와 결합되므로 엔지니어는 최소한의 수고로 자주 발생하며 예측 가능한 방식으로 높은 영향을 미치는 변경을 수행할 수 있습니다.

클라우드 네이티브는 ‘속도’ 및 ‘민첩성’에 관한 것입니다. 비즈니스 시스템은 비즈니스 역량을 활성화하는 측면에서 비즈니스 속도와 성장을 가속화하는 전략적 혁신 무기로 진화하고 있습니다. 새로운 아이디어를 즉시 출시하는 것이 필수적입니다.

동시에, 비즈니스 시스템은 더 많은 사용자 요구로 인해 점점 더 복잡해지고 있습니다. 빠른 응답성, 혁신적인 기능 및 제로 가동 중지 시간을 기대합니다. 성능 문제, 반복적인 오류 및 빠른 전환 능력 부족은 더 이상 허용되지 않습니다. 사용자들은 경쟁업체를 찾게 될 것입니다. 클라우드 네이티브 시스템은 빠른 변화, 더 큰 규모 및 복원력을 수용하도록 설계되었습니다.

다음은 클라우드 네이티브 기술을 구현한 일부 기업들입니다. 이러한 기업들이 달성한 속도, 민첩성 및 스케일링 기능에 대해 생각해 보세요.

여기서 볼 수 있듯이 Netflix, Uber 및 WeChat은 많은 독립 서비스로 구성된 클라우드 네이티브 시스템을 노출합니다. 이 아키텍처 스타일을 사용하면 시장 상황에 신속하게 대응할 수 있습니다. 전체 재배포 없이 복잡한 라이브 애플리케이션의 소규모 영역을 즉시 업데이트합니다. 필요에 따라 개별적으로 서비스를 스케일링합니다.

클라우드 네이티브의 속도와 민첩성은 여러 요인에서 파생됩니다. 가장 중요한 것은 ‘클라우드 인프라’입니다. 하지만 이것이 다가 아닙니다. 그림 1-3에 나와 있는 5개의 다른 기본 핵심 요소가 클라우드 네이티브 시스템의 기반이 됩니다.

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

각 핵심 요소의 중요성을 좀 더 잘 이해하는 시간을 좀 더 가져보겠습니다.

클라우드 네이티브 시스템은 클라우드 서비스 모델을 최대한 활용합니다.

가상화된 동적 클라우드 환경에서 성장하도록 설계된 이러한 시스템은 PaaS(Platform as a Service) 컴퓨팅 인프라 및 관리형 서비스를 광범위하게 사용합니다. 자동화를 통해 기본 인프라를 몇 분 안에 프로비저닝하고 주문형으로 크기 조정, 스케일링 또는 소멸시키는 ’삭제 가능’ 인프라로 처리합니다.

널리 허용되는 DevOps의 애완 동물 대 가축 개념을 고려해보세요. 기존 데이터 센터에서 서버는 물리적 머신인 ‘애완동물’로 취급되어 의미 있는 이름을 지정하고 ‘관리’합니다. 동일한 머신에 더 많은 리소스를 추가하여 스케일링합니다(스케일 업). 서버가 아프면 건강해지도록 간호합니다. 서버를 사용할 수 없게 되면 모든 사용자가 알 수 있습니다.

가축 서비스 모델은 다릅니다. 각 인스턴스를 가상 머신 또는 컨테이너로 프로비저닝합니다. 각 인스턴스는 동일하며 Service-01, Service-02 등과 같은 시스템 식별자가 할당됩니다. 더 많은 인스턴스를 만들어 스케일링합니다(스케일 아웃). 사용할 수 없게 되어도 아무도 모릅니다.

가축 모델은 ‘변경할 수 없는 인프라’를 수용합니다. 서버는 복구되거나 수정되지 않습니다. 한 서버에서 발생하거나 업데이트가 필요한 경우 삭제되고 새 서버가 프로비저닝되며 이러한 모든 작업은 자동화를 통해 수행됩니다.

클라우드 네이티브 시스템은 가축 서비스 모델을 수용합니다. 실행 중인 머신과 관계없이 인프라가 스케일 인되거나 스케일 아웃될 때도 계속 실행됩니다.

Azure 클라우드 플랫폼은 자동 스케일링, 자체 복구 및 모니터링 기능을 사용하여 이러한 유형의 고도로 탄력적인 인프라를 지원합니다.

클라우드 네이티브 앱을 디자인하려면 어떻게 해야 할까요? 아키텍처는 어떤 모습일까요? 어떤 원칙, 패턴 및 모범 사례를 준수할 것인가요? 어떤 인프라 및 운영 문제가 중요할까요?

클라우드 기반 애플리케이션을 생성하기 위한 널리 허용되는 방법은 12단계 응용입니다. 이 방식은 개발자가 최신 클라우드 환경에 최적화된 애플리케이션을 생성하기 위해 따르는 일련의 원칙과 사례를 설명합니다. 환경 전반의 이식성과 선언적 자동화에 특히 유의합니다.

모든 웹 기반 애플리케이션에 적용할 수 있지만 많은 실무자는 12단계를 클라우드 네이티브 앱 빌드를 위한 견고한 토대로 간주합니다. 이러한 원칙을 기준으로 하는 시스템은 신속하게 배포 및 확장할 수 있으며, 시장 변화에 신속하게 대응할 수 있는 기능을 추가할 수 있습니다.

다음 표에서는 12단계 방법론을 중점적으로 보여 줍니다.

Beyond the Twelve-Factor App(12단계 앱 그 이상) 책에서 저자인 Kevin Hoffman은 원래의 12가지 단계 각각에 대해 자세히 설명합니다(2011년 제작). 또한 오늘날의 최신 클라우드 애플리케이션 디자인을 반영하는 세 가지 추가 단계에 대해서도 설명합니다.

이 장과 책 전반에서 12개 이상의 요인에 대한 다양한 측면을 살펴보겠습니다.

특히 클라우드 네이티브 아키텍처를 구현할 때 클라우드 기반 워크로드를 디자인하고 배포하는 것은 어려울 수 있습니다. Microsoft는 사용자와 팀이 강력한 클라우드 솔루션을 제공하는 데 도움이 되는 업계 표준 모범 사례를 제공합니다.

Microsoft Well-Architected Framework는 클라우드 네이티브 워크로드의 품질을 개선하는 데 사용할 수 있는 일련의 안내 테넌트를 제공합니다. 이 프레임워크는 다음과 같이 뛰어난 아키텍처의 5가지 핵심 요소로 이루어져 있습니다.

시작하기 위해 Microsoft는 현재 클라우드 워크로드에서 잘 설계된 다섯 가지 핵심 요소를 평가하는 데 도움이 되는 일련의 온라인 평가를 제공합니다.

클라우드 네이티브 시스템은 최신 애플리케이션을 생성하기 위한 인기 있는 아키텍처 스타일인 마이크로 서비스를 수용합니다.

공유 패브릭을 통해 상호 작용하는 소규모 독립 서비스의 분산 집합으로 빌드된 마이크로 서비스는 다음과 같은 특성을 공유합니다.

• 각각은 더 큰 도메인 컨텍스트 내에서 특정 비즈니스 기능을 구현합니다.
• 각각은 자율적으로 개발되며 독립적으로 배포할 수 있습니다.
• 각각은 자체 데이터 스토리지 기술, 종속성 및 프로그래밍 플랫폼을 캡슐화하는 자체 포함형입니다.
• 각각은 자체 프로세스에서 실행되며 HTTP/HTTPS, gRPC, WebSockets 또는 AMQP와 같은 표준 통신 프로토콜을 사용하여 서로 통신합니다.
• 함께 애플리케이션을 구성합니다.

그림 1-4는 모놀리식 애플리케이션 접근 방식과 마이크로 서비스 접근 방식을 대조해서 보여 줍니다. 모놀리스가 단일 프로세스에서 실행되는 계층화된 아키텍처로 구성되는 방법을 확인합니다. 일반적으로 관계형 데이터베이스를 사용합니다. 그러나 마이크로 서비스 접근 방식은 기능을 각각 자체 논리, 상태 및 데이터를 갖는 독립적인 서비스로 분리합니다. 각 마이크로 서비스는 자체 데이터 저장소를 호스팅합니다.

그림 1-4. 모놀리식 대 마이크로 서비스 아키텍처

마이크로 서비스가 앞에서 설명한 12단계 응용에서 프로세스 원칙을 승격하는 방법을 확인합니다.

6단계는 “각 마이크로 서비스가 실행 중인 다른 서비스와 격리되어 자체 프로세스에서 실행되어야 함”을 지정합니다.

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

이 장 앞부분에서는 모놀리식으로 빌드된 전자 상거래 애플리케이션을 마이크로 서비스와 비교했습니다. 이 예제에서는 몇 가지 명확한 이점을 확인했습니다.

• 각 마이크로 서비스에는 자율 수명 주기가 있으며 독립적으로 발전하고 자주 배포할 수 있습니다. 새 기능 또는 업데이트를 배포하기 위해 분기별 릴리스를 기다릴 필요가 없습니다. 라이브 애플리케이션의 작은 영역을 업데이트하여 전체 시스템을 중단할 위험을 줄일 수 있습니다. 애플리케이션을 완전히 다시 배포하지 않고도 업데이트를 수행할 수 있습니다.
• 각 마이크로 서비스는 독립적으로 스케일링할 수 있습니다. 전체 애플리케이션을 단일 단위로 스케일링하는 대신, 원하는 성능 수준 및 서비스 수준 계약을 충족하기 위해 더 많은 처리 능력이 필요한 서비스만 스케일 아웃합니다. 세분화된 스케일링은 시스템을 보다 효율적으로 제어할 수 있도록 하며, 전체가 아니라 시스템의 일부를 스케일링함으로써 전반적인 비용을 줄이는 데 도움이 됩니다.

마이크로 서비스를 이해하기 위한 훌륭한 참조 가이드는 .NET 마이크로 서비스: 컨테이너화된 .NET 애플리케이션을 위한 아키텍처입니다. 이 책은 마이크로 서비스 디자인 및 아키텍처에 대해 자세히 설명합니다. Microsoft에서 무료로 다운로드할 수 있는 전체 스택 마이크로 서비스 참조 아키텍처의 부록에 해당합니다.

마이크로 서비스는 모든 최신 개발 플랫폼에서 만들 수 있습니다.

Microsoft .NET 플랫폼은 훌륭한 선택입니다. 무료 및 오픈 소스로 제공되는 이 플랫폼에는 마이크로 서비스 개발을 간소화하는 많은 기본 제공 기능이 있습니다. .NET 는 플랫폼 간입니다. 애플리케이션은 Windows, macOS 및 대부분의 Linux 버전에서 빌드하고 실행할 수 있습니다.

.NET 성능이 뛰어나고 Node.js 및 기타 경쟁 플랫폼에 비해 좋은 점수를 받았습니다. 흥미롭게도 TechEmpower는 많은 웹 애플리케이션 플랫폼 및 프레임워크에서 광범위한 성능 벤치마크 집합을 수행했습니다. .NET 상위 10위 안에 Node.js 및 기타 경쟁 플랫폼보다 훨씬 높은 점수를 받았습니다.

.NET 는 Microsoft 및 GitHub의 .NET 커뮤니티에서 유지 관리됩니다.

분산 클라우드 네이티브 마이크로 서비스는 엄청난 민첩성과 속도를 제공할 수 있지만 다음과 같은 많은 과제를 제시합니다.

프런트 엔드 클라이언트 애플리케이션은 백 엔드 코어 마이크로 서비스와 어떻게 통신합니까? 직접 통신을 허용할까요? 또는 유연성, 제어 및 보안을 제공하는 게이트웨이 외관을 사용하여 백 엔드 마이크로 서비스를 추상화할 수 있나요?

백 엔드 코어 마이크로 서비스는 서로 어떻게 통신하나요? 결합을 높이고 성능과 민첩성에 영향을 줄 수 있는 직접 HTTP 호출을 허용할까요? 또는 큐 및 토픽 기술과 분리된 메시징을 고려할 수 있나요?

통신은 클라우드 네이티브 통신 패턴 장에서 다룹니다.

마이크로 서비스 아키텍처는 시스템을 In-Process에서 Out-of-process 네트워크 통신으로 이동합니다. 분산 아키텍처에서 서비스 B가 서비스 A의 네트워크 호출에 응답하지 않으면 어떻게 되나요? 또는 서비스 C를 일시적으로 사용할 수 없게 되고 서비스 C를 호출하는 다른 서비스가 차단되면 어떻게 되나요?

복원력은 클라우드 네이티브 복원력 장에서 다룹니다.

기본적으로 각 마이크로 서비스는 자체 데이터를 캡슐화하여 퍼블릭 인터페이스를 통해 작업을 노출합니다. 그렇다면 데이터를 쿼리하거나 여러 서비스에서 트랜잭션을 구현하려면 어떻게 해야 할까요?

분산 데이터는 클라우드 네이티브 데이터 패턴 장에서 다룹니다.

마이크로 서비스로 어떻게 비밀 및 중요한 구성 데이터를 안전하게 저장하고 관리할 수 있나요?

비밀은 클라우드 네이티브 보안에서 자세히 설명합니다.

Dapr은 분산 오픈 소스 애플리케이션 런타임입니다. Dapr은 플러그형 구성 요소의 아키텍처를 통해 분산 애플리케이션의 내부 ‘배관’을 크게 간소화합니다. Dapr 런타임에서 미리 빌드된 인프라 기능 및 구성 요소와 애플리케이션을 바인딩하는 동적 글루를 제공합니다. 그림 1-5는 20,000피트 상공에서 바라본 Dapr을 보여 줍니다.

그림 1-5. 20,000피트 상공에서 바라본 Dapr

그림의 맨 위 행에서 Dapr이 인기 있는 개발 플랫폼에 언어별 SDK를 제공하는 방법을 확인합니다. Dapr v1에는 , Go, Node.js, Python, PHP, Java 및 JavaScript에 대한 .NET지원이 포함됩니다.

언어별 SDK는 개발자 환경을 향상시키지만 Dapr은 플랫폼에 구애받지 않습니다. 내부적으로 Dapr의 프로그래밍 모델은 표준 HTTP/gRPC 통신 프로토콜을 통해 기능을 노출합니다. 모든 프로그래밍 플랫폼은 네이티브 HTTP 및 gRPC API를 통해 Dapr을 호출할 수 있습니다.

그림의 가운데에 있는 파란색 상자는 Dapr 구성 요소를 나타냅니다. 각각은 애플리케이션에서 사용할 수 있는 분산 애플리케이션 기능에 대해 미리 빌드된 배관 코드를 노출합니다.

구성 요소 행은 애플리케이션에서 사용할 수 있는 미리 정의된 대규모 인프라 구성 요소 집합을 나타냅니다. 구성 요소를 작성할 필요가 없는 인프라 코드로 간주합니다.

아래쪽 행은 Dapr의 이식성과 실행할 수 있는 다양한 환경을 강조 표시합니다.

Microsoft는 Dapr을 학습하기 위한 개발자용 .NET 무료 전자책 Dapr을 제공합니다.

앞으로 Dapr은 클라우드 네이티브 애플리케이션 개발에 중대한 영향을 미칠 가능성이 있습니다.

모든 ‘클라우드 네이티브’ 대화에서 용어 ‘컨테이너’가 언급되는 것을 자주 듣게 될 것입니다. 클라우드 네이티브 패턴 책에서 저자인 Cornelia Davis는 “컨테이너가 클라우드 네이티브 소프트웨어의 뛰어난 활성화 요인”이라고 말합니다.” Cloud Native Computing Foundation은 클라우드 네이티브 여정을 시작하는 기업을 위한 지침인 클라우드 네이티브 트레일 맵의 첫 번째 단계로 마이크로 서비스 컨테이너화를 배치합니다.

마이크로 서비스를 컨테이너화하는 것은 간단합니다. 코드, 해당 종속성 및 런타임은 컨테이너 이미지라는 이진 파일로 패키지됩니다. 이미지는 이미지의 리포지토리 또는 라이브러리 역할을 하는 컨테이너 레지스트리에 저장됩니다. 레지스트리는 개발 컴퓨터, 데이터 센터 또는 퍼블릭 클라우드에 있을 수 있습니다. Docker 자체는 Docker Hub를 통해 퍼블릭 레지스트리를 유지 관리합니다. Azure 클라우드는 프라이빗 컨테이너 레지스트리를 사용하여 컨테이너 이미지를 실행할 클라우드 애플리케이션 가까이에 저장합니다.

애플리케이션이 시작되거나 스케일링되면 컨테이너 이미지를 실행 중인 컨테이너 인스턴스로 변환합니다. 인스턴스는 컨테이너 런타임 엔진이 설치된 모든 컴퓨터에서 실행됩니다. 필요한 수만큼 컨테이너화된 서비스의 인스턴스를 유지할 수 있습니다.

그림 1-6은 각각 자체 컨테이너에 있으며 모두 단일 호스트에서 실행되는 세 개의 서로 다른 마이크로 서비스를 보여 줍니다.

그림 1-6. 컨테이너 호스트에서 실행되는 여러 컨테이너

각 컨테이너가 서로 다를 수 있는 자체 종속성 및 런타임 집합을 유지 관리하는 방법에 유의하세요. 여기서는 동일한 호스트에서 실행되는 다양한 버전의 제품 마이크로 서비스를 볼 수 있습니다. 각 컨테이너는 기본 호스트 운영 체제, 메모리 및 프로세서의 조각을 공유하지만 서로 격리됩니다.

컨테이너 모델이 12단계 응용의 종속성 원칙을 얼마나 잘 수용하는지 확인합니다.

2단계는 “각 마이크로 서비스가 자체 종속성을 격리하고 패키징하여 전체 시스템에 영향을 주지 않으면서 변경 내용을 수용한다”고 지정합니다.

컨테이너는 Linux 및 Windows 워크로드를 모두 지원합니다. Azure 클라우드는 두 가지 모두를 공개적으로 수용합니다. 흥미롭게도 Windows Server가 아닌 Linux는 Azure에서 더 인기 있는 운영 체제가 되었습니다.

여러 컨테이너 공급업체가 있지만 Docker가 시장에서 가장 큰 지분을 차지했습니다. 이 회사는 소프트웨어 컨테이너 이동을 추진하고 있습니다. 또한 클라우드 네이티브 애플리케이션을 패키징, 배포 및 실행하기 위한 사실상 표준이 되었습니다.

컨테이너는 환경 전반에서 이식성을 제공하고 일관성을 보장합니다. 모든 항목을 단일 패키지로 캡슐화하여 기본 인프라에서 마이크로 서비스 및 종속성을 ‘격리’합니다.

Docker 런타임 엔진을 호스트하는 모든 환경에서 컨테이너를 배포할 수 있습니다. 또한 컨테이너화된 워크로드는 프레임워크, 소프트웨어 라이브러리 및 런타임 엔진을 사용하여 각 환경을 미리 구성하는 비용을 제거합니다.

기본 운영 체제 및 호스트 리소스를 공유하면 컨테이너의 공간이 전체 가상 머신보다 훨씬 더 작습니다. 크기가 작을수록 지정된 호스트가 한 번에 실행할 수 있는 마이크로 서비스 수 또는 ‘밀도’가 증가합니다.

Docker와 같은 도구는 이미지를 만들고 컨테이너를 실행하는 동안 이미지를 관리하는 도구도 필요합니다. 컨테이너 관리는 컨테이너 오케스트레이터라는 특수 소프트웨어 프로그램으로 수행됩니다. 많은 독립 실행 컨테이너를 사용하여 대규모로 작동하는 경우 오케스트레이션이 필수적입니다.

그림 1-7은 컨테이너 오케스트레이터가 자동화하는 관리 작업을 보여 줍니다.

그림 1-7. 컨테이너 오케스트레이터가 수행하는 작업

다음 표에서는 일반적인 오케스트레이션 작업에 대해 설명합니다.

컨테이너 오케스트레이터가 어떻게 12단계 응용의 삭제 가능성 및 동시성 원칙을 수용하는지 확인합니다.

9단계는 “서비스 인스턴스를 삭제할 수 있어야 하며, 빠른 시작을 선호하여 확장성 기회를 높이고 시스템을 올바른 상태로 유지하도록 정상적인 종료를 허용해야 함”을 지정합니다. 오케스트레이터와 함께 Docker 컨테이너는 기본적으로 이 요구 사항을 충족합니다.

8단계는 “서비스가 사용 가능한 가장 강력한 머신에서 단일 대규모 인스턴스를 스케일 업하지 않고, 많은 수의 동일한 소규모 프로세스(복사본)에서 스케일 아웃됨”을 지정합니다.

여러 컨테이너 오케스트레이터가 있지만 Kubernetes는 사실상 클라우드 네이티브 세계의 표준이 되었습니다. 컨테이너화된 워크로드를 관리하기 위한 이식 가능하고 확장 가능한 오픈 소스 플랫폼입니다.

Kubernetes의 고유한 인스턴스를 호스트할 수 있지만 리소스를 프로비저닝하고 관리하는 작업은 사용자가 담당합니다. 이러한 작업은 복잡할 수 있습니다. Azure 클라우드는 Kubernetes를 관리형 서비스로 제공합니다. AKS(Azure Kubernetes Service) 및 ARO(Azure Red Hat OpenShift)를 통해 Kubernetes를 설치하고 유지 관리할 필요 없이 해당 기능과 성능을 관리형 서비스로서 완전히 활용할 수 있습니다.

컨테이너 오케스트레이션은 클라우드 네이티브 애플리케이션 스케일링에 자세히 설명되어 있습니다.

클라우드 네이티브 시스템은 데이터 저장소, 메시지 브로커, 모니터링 및 ID 서비스와 같은 다양한 보조 리소스에 의존합니다. 이러한 서비스를 지원 서비스라고 합니다.

그림 1-8에서는 클라우드 네이티브 시스템에서 사용하는 많은 일반적인 지원 서비스를 보여 줍니다.

그림 1-8. 공통 지원 서비스

사용자 고유의 지원 서비스를 호스트할 수 있지만 해당 리소스의 라이선스, 프로비저닝 및 관리를 담당하게 됩니다.

클라우드 공급자는 다양한 ‘관리형 백업 서비스’ 모음을 제공합니다. 서비스를 소유하는 대신 사용하면 됩니다. 클라우드 공급자는 대규모로 리소스를 운영하며 성능, 보안 및 유지 관리를 담당합니다. 모니터링, 중복성 및 가용성은 서비스에 기본 제공됩니다. 공급자는 서비스 수준 성능을 보장하고 관리형 서비스를 완벽하게 지원합니다. 즉, 티켓을 열고 문제를 해결합니다.

클라우드 네이티브 시스템은 클라우드 공급업체의 관리형 지원 서비스를 적용합니다. 시간과 작업량의 절감은 상당할 수 있습니다. 직접 호스팅하고 문제를 겪게 되는 운영 위험을 해결하는 데는 비용이 많이 들 수 있습니다.

지원 서비스를 외부 구성에 저장된 구성 정보(URL 및 자격 증명)를 사용하여 마이크로 서비스에 동적으로 바인딩된 연결된 리소스로 처리하는 것이 가장 좋습니다. 이 지침은 이 장 앞부분에서 설명한 12단계 응용에 설명되어 있습니다.

‘4단계’는 지원 서비스가 “주소 지정 가능한 URL을 통해 노출되어야 함을 지정합니다. 이렇게 하면 애플리케이션에서 리소스가 분리되며 바꿔서 사용할 수 있습니다.”

‘3단계’는 “구성 정보가 마이크로 서비스 외부로 이동하며 코드 외부의 구성 관리 도구를 통해 외부화됨”을 지정합니다.

이 패턴을 사용하면 코드 변경 없이 백업 서비스를 연결하고 분리할 수 있습니다. 마이크로 서비스를 QA에서 스테이징 환경으로 승격할 수 있습니다. 스테이징에서 지원 서비스를 가리키도록 마이크로 서비스 구성을 업데이트하고 환경 변수를 통해 설정을 컨테이너에 삽입합니다.

클라우드 공급업체는 고유한 지원 서비스와 통신하기 위한 API를 제공합니다. 이러한 라이브러리는 독점적인 배관 및 복잡성을 캡슐화합니다. 그러나 이러한 API와 직접 통신하면 코드를 해당 특정 지원 서비스와 긴밀하게 결합할 수 있습니다. 공급업체 API의 구현 세부 정보를 격리하는 것은 널리 허용되는 사례입니다. 서비스 코드에 제네릭 작업을 노출하고 내부 공급 업체 코드를 래핑하는 중간 계층 또는 중간 API를 도입합니다. 이 느슨한 결합을 사용하면 주요 서비스 코드를 변경하지 않고도 한 백업 서비스를 다른 백업 서비스와 교체하거나 코드를 다른 클라우드 환경으로 이동할 수 있습니다. 앞에서 설명한 Dapr은 미리 빌드된 빌딩 블록 집합을 사용하여 이 모델을 따릅니다.

최종적으로 지원 서비스는 이 장 앞부분에서 설명하는 12단계 응용의 상태 비저장 원칙도 승격합니다.

‘6단계’는 “각 마이크로 서비스가 실행 중인 다른 서비스와 격리되어 자체 프로세스에서 실행되어야 하며, 필요한 상태를 분산 캐시 또는 데이터 저장소와 같은 지원 서비스에 외부화함”을 지정합니다.

지원 서비스는 클라우드 네이티브 데이터 패턴 및 클라우드 네이티브 통신 패턴에 설명되어 있습니다.

확인한 것처럼 클라우드 네이티브 시스템은 마이크로 서비스, 컨테이너 및 최신 시스템 디자인을 수용하여 속도와 민첩성을 달성합니다. 하지만 이는 일부에 불과합니다. 이러한 시스템이 실행되는 클라우드 환경을 어떻게 프로비저닝하나요? 앱 기능 및 업데이트를 신속하게 배포하려면 어떻게 해야 할까요? 전체적인 상황을 어떻게 설명할 수 있을까요?

Infrastructure as Code 또는 IaC의 널리 허용되는 사례를 입력합니다.

IaC를 사용하면 플랫폼 프로비저닝 및 애플리케이션 배포를 자동화할 수 있습니다. 기본적으로 DevOps 사례에 테스트 및 버전 관리와 같은 소프트웨어 엔지니어링 사례를 적용합니다. 인프라 및 배포는 자동화되고 일관되며 반복 가능합니다.

Azure Resource Manager, Azure Bicep, HashiCorp의 Terraform 및 Azure CLI와 같은 도구를 사용하여 필요한 클라우드 인프라를 선언적으로 스크립팅할 수 있습니다. 리소스 이름, 위치, 용량 및 비밀은 매개 변수화되며 동적입니다. 스크립트의 버전이 지정되고 프로젝트의 아티팩트로서 소스 제어에 체크 인됩니다. 스크립트를 호출하여 QA, 스테이징 및 프로덕션과 같은 시스템 환경에서 일관되고 반복 가능한 인프라를 프로비저닝합니다.

내부적으로 IaC는 idempotent입니다. 즉, 부작용 없이 동일한 스크립트를 반복해서 실행할 수 있습니다. 팀은 변경을 수행해야 하는 경우 스크립트를 편집하고 다시 실행합니다. 업데이트된 리소스만 영향을 받습니다.

작성자 Sam Guckenheimer는 Infrastructure as Code란 무엇인가 문서에서 "IaC를 구현하는 팀이 안정적인 환경을 신속하고 대규모로 제공”할 수 있는 방법에 대해 설명합니다. 팀은 환경을 수동으로 구성하지 않고 코드를 통해 환경의 원하는 상태를 표시하여 일관성을 적용합니다. IaC를 사용한 인프라 배포는 반복 가능하며 구성 드리프트 또는 누락된 종속성으로 인한 런타임 문제를 방지합니다. DevOps 팀은 통합 사례 및 도구 집합을 함께 사용하여 애플리케이션과 지원 인프라를 신속하고 안정적으로 대규모로 제공할 수 있습니다.

앞에서 설명한 12단계 응용은 완료된 코드를 실행 중인 애플리케이션으로 변환할 때 별도의 단계를 요구합니다.

5단계는 “각 릴리스는 빌드, 릴리스, 실행 스테이지마다 엄격히 구분되어야 합니다. 각각은 고유한 ID로 태그를 지정하고 롤백 기능을 지원해야 함”을 지정합니다.

최신 CI/CD 시스템은 이 원칙을 충족하는 데 도움이 될 수 있습니다. 사용자가 쉽게 사용할 수 있는 일관된 고품질 코드를 보장하는 데 도움이 되는 별도의 빌드 및 전송 단계를 제공합니다.

그림 1-9는 배포 프로세스 간의 분리를 보여 줍니다.

그림 1-9. CI/CD 파이프라인의 배포 단계

이전 그림에 나오는 작업 분리에 특히 유의합니다.

1. 개발자는 개발 환경에서 기능을 생성하여 코드, 실행 및 디버그로 이루어진 "내부 루프" 과정을 반복합니다.
2. 완료되면 해당 코드는 GitHub, Azure DevOps 또는 BitBucket과 같은 코드 리포지토리에 ‘푸시’됩니다.
3. 푸시는 코드를 이진 아티팩트로 변환하는 빌드 스테이지를 트리거합니다. 작업은 CI(연속 통합) 파이프라인으로 구현됩니다. 자동으로 애플리케이션을 빌드, 테스트 및 패키징합니다.
4. 이후 릴리스 스테이지가 이진 아티팩트를 넘겨받아서 외부 애플리케이션 및 환경 구성 정보를 적용한 후 변경이 불가능한 릴리스를 생성합니다. 릴리스는 지정된 환경에 배포됩니다. 이 작업은 CD(지속적인 업데이트) 파이프라인으로 구현됩니다. 각 릴리스를 식별할 수 있어야 합니다. “이 배포는 애플리케이션의 릴리스 2.1.1을 실행하고 있습니다.”라고 말할 수 있습니다.
5. 마지막으로, 릴리스된 기능이 대상 실행 환경에서 실행됩니다. 릴리스는 변경할 수 없습니다. 즉, 변경을 수행하면 새 릴리스가 만들어져야 합니다.

이러한 사례를 적용하여 조직은 소프트웨어를 전달하는 방법을 근본적으로 발전시켰습니다. 많은 조직들은 분기별 릴리스에서 주문형 업데이트로 전환했습니다. 목표는 개발 주기 초기에 문제를 찾아냄으로써 해결 비용을 줄이는 것입니다. 통합 간의 기간이 길어질수록 문제를 해결하는 데 더 많은 비용이 듭니다. 통합 프로세스의 일관성을 통해 팀은 코드 변경 내용을 좀 더 자주 커밋하여 협업 및 소프트웨어 품질을 높일 수 있습니다.

GitHub 및 Azure DevOps와 함께 Infrastructure as code 및 배포 자동화는 DevOps에 자세히 설명되어 있습니다.

관련 리소스

Kubernetes 라이프사이클 관리를 간소화하는 7가지 방법

관련 리소스

클라우드 네이티브 데이터센터를 위한 이상적인 토대 구축하기

컨테이너

컨테이너는 클라우드 네이티브 소프트웨어의 가장 작은 단위입니다. 컨테이너는 모든 디펜던시(예: 바이너리, 라이브러리)와 함께 통합된 코드 하나로 구성되며 별개의 프로세스로 실행됩니다. 이 덕분에 새로운 수준의 추상화가 가능합니다. 가상 머신(VM)이 기반 하드웨어에서 컴퓨팅 리소스를 추상화하듯이 컨테이너는 기반 운영 체제(OS)에서 애플리케이션을 추상화합니다.

컨테이너는 여러 가지 중요한 차이점 때문에 VM과 다릅니다. 컨테이너는 리소스 상면이 훨씬 더 작으며, 더 빨리 스핀업할 수 있고, 훨씬 더 쉽게 클라우드 환경 간에 이식할 수 있습니다. VM과 다르게 컨테이너는 수명이 짧습니다.

컨테이너는 마이크로서비스 소프트웨어 아키텍처의 길을 엽니다. 레거시 애플리케이션은 기본적으로 모놀리식이지만, 마이크로 서비스 기반 애플리케이션은 독립적으로 확장할 수 있고 운영 중단 없는 업그레이드를 지원하는 구성 가능한 작은 단위(서비스)의 집합으로 구축됩니다. 컨테이너 서비스는 공통된 기능을 수행하는 하나 이상의 컨테이너로 구성됩니다.

컨테이너화된/마이크로서비스 기반 애플리케이션은 개발자와 DevOps라는 IT 운영 팀 사이의 긴밀한 통합과 조율을 요구하는 효율화되고 가속화된 소프트웨어 개발 방법을 지원합니다.

그림 1: VM 및 컨테이너 비교

제조업에서 운송업, 소매업에 이르기까지 사실상 모든 업종에서 클라우드 기반 인프라로 전환하여 디지털 트랜스포메이션을 지원하고 있다. 사내 소프트웨어에서 클라우드 서비스로의 전환은 애플리케이션 개발 및 배포 프로세스, 특히, SaaS 애플리케이션으로 혁신적으로 변화했다. 하지만 클라우드를 자주 사용하는 것만으로는 충분하지 않다. 클라우드 네이티브 애플리케이션을 활용해 향상된 민첩성, 가용성, 확장성 및 전체 성능을 활용할 수 있어야 한다.

클라우드 네이티브 아키텍처는 현대 소프트웨어 개발의 표준이 되었다. 그러나 그 인기와 함께 불확실성도 나타났다. 애플리케이션이 클라우드 네이티브라는 것이 정확히 어떤 의미일까? ‘클라우드 네이티브’에 대한 정의는 오늘날 운영되는 클라우드 네이티브 애플리케이션의 수만큼 다양하다. 그러나 클라우드 네이티브 애플리케이션을 구축하고자 할 때 유용한 몇 가지 표준적이고 이해하기 쉬운 원칙이 있다.
 

ⓒ Getty Images Bank 

클라우드 네이티브의 의미

클라우드 네이티브 애플리케이션은 클라우드의 동적이면서 확장적이고 매우 가용적인 속성을 지도 원칙으로 하여 구축된 소프트웨어 시스템이다. 클라우드 네이티브 애플리케이션 아키텍처는 소프트웨어 개발자가 기존 접근 방식을 사용할 때 직면하는 과제에 대한 대응이다. 특히 클라우드 네이티브 애플리케이션은 다음과 같다. 
 

• 클라우드의 역동적인 리소스 할당을 활용. 즉, 애플리케이션의 설치 공간은 현재 애플리케이션에 주어진 수요에 따라 크기가 달라지며, 소비된 리소스는 현재 시점에 필요한 리소스에 맞게 조정될 것이다.
• 서비스 또는 마이크로서비스 아키텍처 활용. 마이크로 서비스를 사용하면 애플리케이션 크기와 복잡성을 관리하기 쉬운 방법으로 쉽게 확장할 수 있다.
• 컨테이너화. 컨테이너를 사용하면 복잡한 종속성 관리에 대한 우려없이 서로 다른 환경에서 빠르고 쉽게 서비스를 배치할 수 있다.
• 쿠버네티스를 사용하여 서비스를 조율. 컨테이너 오케스트레이션 및 관리를 위한 사실상의 표준인 쿠버네티스는 컨테이너를 시작하고, 컨테이너 간의 통신을 설정하고, 장애를 모니터링하며, 필요에 따라 컨테이너를 재시작하고, 현재 사용 사례의 필요에 따라 애플리케이션의 크기를 조정한다. 쿠버네티스는 클라우드와 긴밀하게 협력하여 동적으로 크기가 맞춰진 애플리케이션과 서비스를 만든다.
• 클라우드 관리 데이터베이스 및 기타 데이터 서비스의 데이터를 저장 및 관리. 애플리케이션 요구사항을 충족하고 대량의 데이터를 쉽게 사용할 수 있도록 자동으로 확장되는 클라우드 최적화 데이터 서비스는 클라우드 네이티브 애플리케이션의 표준 요구사항이다.
• 현대적 개발 및 운영 워크플로우를 사용. 데브옵스, 지속 통합 및 연속 전달(CI/CD), 깃 소스 코드 관리 및 유사한 프로세스와 절차가 포함된다.

또한 모든 클라우드 네이티브 애플리케이션은 아니지만 많은 애플리케이션이 클라우드에 구애받지 않도록 설계되거나 적어도 새로운 클라우드 공급자로 합리적으로 마이그레이션할 수 있다. 경우에 따라 클라우드 네이티브 애플리케이션은 하이브리드 클라우드 또는 멀티 클라우드 환경에서 작동한다.
 

왜 클라우드 네이티브 아키텍처를 사용하는가?

클라우드 네이티브 애플리케이션 개발 및 운영 프로세스와 절차는 최신 애플리케이션 경험의 중요한 측면을 강조하기 때문에 동종 최고의 최신 애플리케이션을 만들어 낸다.
 

• 자동화. 많은 IT 리소스가 수동적이고 반복적인 작업에 낭비될 수 있다. 여기에는 배포 관리, 테스트 제품군 실행, 하드웨어 추가/수정/업그레이드/해제와 같은 작업이 포함된다. 이러한 작업을 자동화하면 시간과 비용을 많이 절약할 수 있어 규모에 관계없이 비즈니스에 큰 이점이 있다. 클라우드 네이티브 원칙을 사용하여 애플리케이션을 구축하면 개발 및 운영 환경을 자동화하는 프로세스가 자연스럽게 진행된다.
• 민첩성. 민첩성은 변화를 신속하게 식별하고 대응하는 능력이다. 이것은 현대 비즈니스 환경에서 중요한 기술이다. 클라우드 네이티브 애플리케이션을 구축 및 운영하는 조직은 변화하는 비즈니스 및 기술 조건에 보다 신속하고 효과적으로 대응하고 보다 민첩하게 운영된다. 이 중 많은 부분이 클라우드 네이티브 아키텍처의 동적 특성에서 나온다.
• 확장성. 비즈니스가 성장함에 따라 애플리케이션의 리소스 요구사항도 증가한다. 사용량이 가장 많은 날에 발생하는 것과 같이 사용량이 급증하면 기존 애플리케이션 인프라가 크게 파괴될 수 있다. 고도로 동적인 클라우드 인프라를 통해 애플리케이션을 더 자동화되고 관리가능한 방식으로 확장할 수 있다. 그러나 이러한 클라우드 역동성은 공짜가 아니다. 동적 리소스 할당이 제대로 활용되도록 애플리케이션을 구축해야 한다. 클라우드 네이티브 애플리케이션은 이러한 동적 리소스를 위해 설계된다.
• 가용성. 가용성은 애플리케이션 중단, 유지보수 또는 업그레이드 절차로 인해 애플리케이션을 사용할 수 없는 것이 아니라 고객이 애플리케이션을 사용할 수 있는 시간의 비율을 측정한 것이다. 낮은 가용성은 일반적으로 심각한 고객 만족 문제가 된다. 높은 가용성을 유지하는 것은 고객 만족과 그에 따른 비즈니스 성장에 결정적이다.
• 자동 복원성. 애플리케이션 고장 및 장애가 발생하면, 문제를 해결하고 신속하게 정상 작동으로 돌아갈 수 있어야 한다. 복구가 자동화될수록 애플리케이션이 더 빨리 정상 운영으로 복귀할 수 있으며, 직원, 고객 및 비즈니스 전반에 대한 파괴적인 문제들도 줄어든다. 자동화된 복구는 고객에게 높은 수준의 서비스를 유지하도록 돕는다. 실패가 발생할 시점을 예측할 수 없지만, 실패에 대한 애플리케이션을 준비할 수 있다. 애플리케이션과 애플리케이션 인프라 모두에서 내결함성 설계 및 장애극복 메커니즘을 사용하면 복원력을 크게 향상시키고 그에 따라 가용성을 크게 높일 수 있다. 클라우드 네이티브 아키텍처는 최신 애플리케이션에서 자동 복원력을 장려하고 활용한다.
• 지속적 통합/지속적 배포(CI/CD). CI/CD는 구축, 테스트 및 배포를 자동화하여 소프트웨어가 개발 시스템에서 실제 제작 시스템으로 보다 빠르고 안정적으로 이동할 수 있도록 하는 소프트웨어 전달 프로세스다. 또한, 우수한 CI/CD 전략으로 애플리케이션 다운타임 없이 실행 중인 애플리케이션에 대한 변경 사항을 배포하고, 비즈니스 민첩성, 소프트웨어 품질 및 고객 반응성을 개선할 수 있다.

CI/CD가 없으면 일부 기업은 새 소프트웨어 버전을 배포하는 데 몇 주 또는 몇 달을 기다려야 한다. 고품질 CI/CD 시스템을 통해 클라우드 네이티브 애플리케이션을 매일, 매시간 또는 더 빠르게 배포할 수 있다. 아마존과 같은 기업은 시간당 수백 또는 수천 개의 업데이트 속도로 소매 애플리케이션을 변경하는 것으로 유명하다(달리 말해, 아마존은 1.6초마다 소프트웨어를 배포한다). 하지만 클라우드 네이티브 애플리케이션을 사용하고 구축을 완료할 때 애플리케이션을 중단하지 않아도 되는 견고하고 자동화된 CI/CD 프로세스를 보유한 경우에만 가능하다.

클라우드 네이티브 아키텍처로 마이그레이션하면 많은 이점이 있다. 클라우드 네이티브 애플리케이션은 자동화, 민첩성, 확장성 및 자동 복원력을 활용한다. 또한, 지속적인 배포와 내구성을 달성할 수 있도록 지원한다. 이러한 혜택은 모든 유형의 비즈니스에 적용될 수 있다. 클라우드 네이티브 원칙과 기법을 사용하여 소프트웨어를 개선하고 비즈니스를 더욱 효율적으로 만들 수 있다. 가장 중요한 것은 클라우드 네이티브 아키텍처를 통해 민첩성이 향상되어 빠르게 변화하는 경제 상황에서 비즈니스 경쟁력을 유지할 수 있다는 점이다.
editor@itworld.co.kr

원문보기:
https://www.itworld.co.kr/news/248260#csidx8fc6f61e340f5ad8357026caa6c52d1 

아이가 쓰던 노트북을 쓰기로 했다.

속도는 별로.. 요즘 컴퓨터가 아니고, 한 7~8년 정도 된

LG 15N53,

정확하게 언제 샀는지 기억나지 않는다.

컴퓨터의 큰 성능이 필요한 작업이 아직 없기에 일단은 버텨보려 한다.

그 대신 키보드, 마우스는 좋은 걸 사용하기로...

현 최저가 25만원하는  alienware 420k,

우연한 기회로 얻게 되었는데, 팔까말까 고민하다가, 그냥 내가 쓰기로...

마우스  ms3230w, 35,000원으로..

가격비교 해보니, 마우스 < 노트북 < 키보드 순이다.