클라우드 네이티브 앱 구축을 위한 5가지 상식 원칙

"클라우드 네이티브" 또는 간단히 "클라우드" 애플리케이션은 클라우드 인프라에서 작동하도록 특별히 제작되었습니다. 일반적으로 컨테이너에 패키지된 느슨하게 결합된 마이크로서비스 세트로 구축되며, 이는 클라우드 플랫폼에서 관리됩니다. 이러한 애플리케이션은 기본적으로 오류에 대비되어 있습니다. 즉, 심각한 인프라 수준 오류가 발생하는 경우에도 안정적으로 작동하고 확장 가능합니다. 동전의 다른 면은 클라우드 플랫폼이 컨테이너 애플리케이션을 자동으로 관리할 수 있도록 컨테이너 애플리케이션에 부과하는 일련의 제한(계약)입니다.

클라우드 기반 애플리케이션으로의 전환의 필요성과 중요성을 충분히 인식하고 있지만, 많은 조직은 여전히 ​​어디서부터 시작해야 할지 모릅니다. 이 게시물에서는 컨테이너화된 애플리케이션을 개발할 때 따르면 클라우드 플랫폼의 잠재력을 실현하고 IT 인프라에 심각한 장애가 발생하는 경우에도 애플리케이션의 안정적인 운영 및 확장을 달성할 수 있는 여러 가지 원칙을 살펴보겠습니다. 수준. 여기에 설명된 원칙의 궁극적인 목표는 Kubernetes와 같은 클라우드 플랫폼에서 자동으로 관리할 수 있는 애플리케이션을 구축하는 방법을 배우는 것입니다.

소프트웨어 설계 원칙

프로그래밍 세계에서 원칙이란 소프트웨어를 개발할 때 따라야 하는 상당히 일반적인 규칙을 의미합니다. 모든 프로그래밍 언어로 작업할 때 사용할 수 있습니다. 각 원칙에는 고유한 목표가 있으며 이를 달성하기 위한 도구는 일반적으로 템플릿과 관행입니다. 또한 고품질 소프트웨어를 만들기 위한 여러 가지 기본 원칙이 있으며, 다른 모든 원칙도 여기에 따릅니다. 다음은 기본 원칙의 몇 가지 예입니다.

• 키스 (간단하게 유지하세요, 어리석게도) – 복잡하게 만들지 마세요.
• DRY (반복하지 마세요) - 반복하지 마세요.
• 야기 (필요하지 않을 것입니다.) - 즉시 필요하지 않은 것을 만들지 마십시오.
• SoC를 우려사항의 분리 - 책임을 공유합니다.

보시다시피, 이러한 원칙은 특정한 규칙을 설정하는 것이 아니라 많은 개발자가 공유하고 정기적으로 참조하는 실제 경험에 따른 소위 상식 고려 사항의 범주에 속합니다.
또한, 고체 – 로버트 마틴(Robert Martin)이 공식화한 객체 지향 프로그래밍 및 디자인의 처음 XNUMX가지 원칙 집합입니다. SOLID에는 함께 적용할 때 더 나은 소프트웨어 시스템을 만들고 장기적으로 더 나은 유지 관리에 도움이 되는 광범위하고 개방적이며 보완적인 원칙이 포함되어 있습니다.

SOLID 원칙은 OOP 분야에 속하며 클래스, 인터페이스 및 상속과 같은 개념 및 개념의 언어로 공식화됩니다. 비유하자면 클라우드 애플리케이션에 대한 개발 원칙도 공식화할 수 있으며 여기서는 기본 요소만 클래스가 아니라 컨테이너가 됩니다. 이러한 원칙을 따르면 Kubernetes와 같은 클라우드 플랫폼의 목표를 더 잘 충족하는 컨테이너화된 애플리케이션을 만들 수 있습니다.

클라우드 네이티브 컨테이너: Red Hat 접근 방식

오늘날 거의 모든 애플리케이션을 비교적 쉽게 컨테이너에 패키징할 수 있습니다. 그러나 Kubernetes와 같은 클라우드 플랫폼 내에서 애플리케이션을 효과적으로 자동화하고 조정하려면 추가적인 노력이 필요합니다.
아래에 설명된 아이디어의 기초는 방법론이었습니다. 열두 요소 앱 소스 코드 관리부터 모델 확장까지 웹 애플리케이션 구축의 다양한 측면에 대한 기타 많은 작업을 수행합니다. 설명된 원칙은 마이크로서비스를 기반으로 구축되고 Kubernetes와 같은 클라우드 플랫폼용으로 설계된 컨테이너화된 애플리케이션 개발에만 적용됩니다. 논의의 기본 요소는 컨테이너 이미지이고, 대상 컨테이너 런타임은 컨테이너 오케스트레이션 플랫폼입니다. 제안된 원칙의 목표는 대부분의 오케스트레이션 플랫폼에서 예약, 확장 및 모니터링 작업을 자동화할 수 있는 컨테이너를 만드는 것입니다. 원칙은 특별한 순서 없이 제시됩니다.

단일 관심 원칙(SCP)

이 원칙은 여러 면에서 단일 책임 원칙과 유사합니다. SRP)는 SOLID 세트의 일부이며 모든 객체는 하나의 책임을 가져야 하며 해당 책임은 클래스에 완전히 캡슐화되어야 함을 명시합니다. SRP의 요점은 모든 책임이 변경의 이유이며 클래스에는 변경의 이유가 하나만 있어야 한다는 것입니다.

SCP에서는 "책임"이라는 단어 대신 "우려"라는 단어를 사용하여 OOP 클래스에 비해 컨테이너의 더 높은 수준의 추상화와 더 넓은 목적을 나타냅니다. 그리고 SRP의 목표가 단 하나의 변경 이유를 갖는 것이라면 SCP 뒤에는 컨테이너를 재사용하고 교체할 수 있는 능력을 확장하려는 욕구가 있습니다. SRP를 따르고 단일 문제를 해결하고 기능적으로 완전한 방식으로 이를 수행하는 컨테이너를 생성하면 다양한 애플리케이션 컨텍스트에서 해당 컨테이너 이미지를 재사용할 가능성이 높아집니다.

SCP 원칙은 각 컨테이너가 하나의 문제를 해결하고 이를 잘 수행해야 한다고 명시합니다. 게다가 컨테이너 세계의 SCP는 OOP 세계의 SRP보다 달성하기가 더 쉽습니다. 컨테이너는 일반적으로 하나의 단일 프로세스를 실행하고 대부분의 경우 이 프로세스는 하나의 단일 작업을 해결하기 때문입니다.

컨테이너 마이크로서비스가 한 번에 여러 문제를 해결해야 하는 경우 단일 작업 컨테이너로 분할하고 사이드카 및 초기화 컨테이너 템플릿을 사용하여 하나의 포드(컨테이너 플랫폼 배포 단위) 내에 결합할 수 있습니다. 또한 SCP를 사용하면 기존 컨테이너(예: 웹 서버 또는 메시지 브로커)를 동일한 문제를 해결하지만 기능이 확장되거나 확장성이 더 뛰어난 새 컨테이너로 쉽게 교체할 수 있습니다.

높은 관찰 가능성 원칙(HOP)

애플리케이션을 패키징하고 실행하는 통일된 방법으로 컨테이너를 사용하는 경우 애플리케이션 자체는 블랙박스로 처리됩니다. 그러나 클라우드 컨테이너인 경우 런타임에 특수 API를 제공하여 컨테이너 상태를 모니터링하고 필요한 경우 적절한 조치를 취해야 합니다. 이것이 없으면 컨테이너 업데이트 및 수명 주기 관리 자동화를 통합할 수 없으며, 결과적으로 소프트웨어 시스템의 안정성과 유용성이 저하됩니다.

실제로 컨테이너화된 애플리케이션에는 최소한 활성 테스트 및 준비 테스트 등 다양한 유형의 상태 확인을 위한 API가 있어야 합니다. 애플리케이션이 더 많은 작업을 수행해야 한다고 주장하는 경우 해당 상태를 모니터링하는 다른 방법을 제공해야 합니다. 예를 들어 Fluentd, Logstash 및 기타 유사한 도구를 사용하여 로그 집계를 위해 STDERR 및 STDOUT을 통해 중요한 이벤트를 로깅합니다. OpenTracing, Prometheus 등과 같은 추적 및 메트릭 컬렉션 라이브러리와의 통합도 가능합니다.

일반적으로 애플리케이션은 여전히 ​​블랙박스로 취급될 수 있지만 최상의 방법으로 모니터링하고 관리하려면 플랫폼에 필요한 모든 API가 제공되어야 합니다.

수명주기 적합성 원칙(LCP)

LCP는 HOP와 정반대입니다. HOP에서는 컨테이너가 읽기 API를 플랫폼에 노출해야 한다고 명시하고 있지만 LCP에서는 애플리케이션이 플랫폼의 정보를 수락할 수 있어야 합니다. 더욱이 컨테이너는 이벤트를 수신할 뿐만 아니라 적응, 즉 이벤트에 반응해야 합니다. 따라서 플랫폼에 API 작성을 제공하기 위한 요구 사항으로 간주될 수 있는 원칙의 이름입니다.

플랫폼에는 컨테이너의 수명주기를 관리하는 데 도움이 되는 다양한 유형의 이벤트가 있습니다. 그러나 어느 것을 인식하고 어떻게 반응할지 결정하는 것은 애플리케이션 자체에 달려 있습니다.

일부 이벤트는 다른 이벤트보다 더 중요하다는 것이 분명합니다. 예를 들어, 응용 프로그램이 충돌을 잘 견디지 못하는 경우 신호: 종료(SIGTERM) 메시지를 수락하고 종료 루틴을 최대한 빨리 시작하여 SIGTERM 뒤에 오는 신호: 종료(SIGKILL)를 포착해야 합니다.

또한 PostStart 및 PreStop과 같은 이벤트는 애플리케이션의 수명 주기에 중요할 수 있습니다. 예를 들어, 애플리케이션을 시작한 후 요청에 응답하려면 약간의 준비 시간이 필요할 수 있습니다. 또는 애플리케이션이 종료될 때 특별한 방법으로 리소스를 해제해야 합니다.

이미지 불변성 원칙(IIP)

컨테이너화된 애플리케이션은 다른 환경에서 실행되더라도 구축 후 변경되지 않은 상태로 유지되어야 한다는 것이 일반적으로 받아들여집니다. 이를 위해서는 런타임 시 데이터 스토리지를 외부화하고(즉, 이를 위해 외부 도구를 사용) 각 환경에 대해 고유한 컨테이너를 수정하거나 생성하는 대신 외부 런타임별 구성에 의존해야 합니다. 애플리케이션을 변경한 후에는 컨테이너 이미지를 다시 빌드하고 사용된 모든 환경에 배포해야 합니다. 그런데 IT 시스템을 관리할 때 서버와 인프라의 불변성 원칙이라는 유사한 원칙이 사용됩니다.

IIP의 목표는 다양한 런타임 환경에 대한 별도의 컨테이너 이미지 생성을 방지하고 적절한 환경별 구성과 함께 어디에서나 동일한 이미지를 사용하는 것입니다. 이 원칙을 따르면 애플리케이션 업데이트의 롤백 및 롤포워드와 같은 클라우드 시스템 자동화의 관점에서 중요한 사례를 구현할 수 있습니다.

공정 일회용 원칙(PDP)

컨테이너의 가장 중요한 특징 중 하나는 임시성입니다. 즉, 컨테이너 인스턴스는 생성 및 삭제가 용이하므로 언제든지 다른 인스턴스로 쉽게 교체할 수 있습니다. 이러한 교체에는 서비스 가능성 테스트 실패, 애플리케이션 확장, 다른 호스트로의 이전, 플랫폼 리소스 고갈 또는 기타 상황 등 여러 가지 이유가 있을 수 있습니다.

결과적으로 컨테이너화된 애플리케이션은 일부 외부 수단을 사용하여 상태를 유지하거나 이를 위해 중복성을 갖춘 내부 분산 체계를 사용해야 합니다. 또한 애플리케이션은 빠르게 시작하고 빠르게 종료해야 하며 갑작스러운 치명적인 하드웨어 오류에 대비해야 합니다.

이 원칙을 구현하는 데 도움이 되는 한 가지 방법은 컨테이너를 작게 유지하는 것입니다. 클라우드 환경에서는 컨테이너 인스턴스를 시작할 호스트를 자동으로 선택할 수 있으므로 컨테이너가 작을수록 더 빠르게 시작됩니다. 즉, 네트워크를 통해 대상 호스트에 더 빠르게 복사됩니다.

자체 봉쇄 원칙(S-CP)

이 원리에 따라 조립 단계에서 필요한 모든 구성 요소가 컨테이너에 포함됩니다. 컨테이너는 시스템에 순수 Linux 커널만 있다는 가정하에 구축되어야 하므로 필요한 모든 추가 라이브러리를 컨테이너 자체에 배치해야 합니다. 또한 해당 프로그래밍 언어의 런타임, 애플리케이션 플랫폼(필요한 경우), 컨테이너 애플리케이션이 실행되는 동안 필요한 기타 종속성 등도 포함되어야 합니다.

환경마다 다르며 런타임 시 Kubernetes ConfigMap 등을 통해 제공되어야 하는 구성에는 예외가 있습니다.

애플리케이션에는 여러 컨테이너화된 구성 요소(예: 컨테이너화된 웹 애플리케이션 내의 별도 DBMS 컨테이너)가 포함될 수 있습니다. S-CP 원칙에 따르면 이러한 컨테이너를 하나로 결합해서는 안 되며, DBMS 컨테이너에는 데이터베이스 운영에 필요한 모든 것이 포함되고, 웹 애플리케이션 컨테이너에는 웹 운영에 필요한 모든 것이 포함되도록 만들어야 합니다. 응용 프로그램, 동일한 웹 서버. 결과적으로 런타임 시 웹 애플리케이션 컨테이너는 DBMS 컨테이너에 의존하고 필요에 따라 이에 액세스합니다.

런타임 제한 원칙(RCP)

S-CP 원칙은 컨테이너를 구축하는 방법과 이미지 바이너리에 포함해야 하는 내용을 정의합니다. 그러나 컨테이너는 파일 크기라는 한 가지 특성만 갖는 단순한 "블랙 박스"가 아닙니다. 실행 중에 컨테이너는 사용된 메모리 양, CPU 시간, 기타 시스템 리소스 등 다른 차원을 취합니다.

그리고 여기서 컨테이너가 시스템 리소스에 대한 요구 사항을 제거하고 이를 플랫폼으로 전송해야 하는 RCP 원칙이 유용합니다. 각 컨테이너의 리소스 프로필(필요한 CPU, 메모리, 네트워크 및 디스크 리소스의 양)을 통해 플랫폼은 예약 및 자동 크기 조정을 최적으로 수행하고, IT 용량을 관리하고, 컨테이너에 대한 SLA 수준을 유지할 수 있습니다.

컨테이너의 리소스 요구 사항을 충족하는 것 외에도 애플리케이션이 자체 경계를 벗어나지 않는 것도 중요합니다. 그렇지 않으면 리소스 부족이 발생할 때 플랫폼이 이를 종료하거나 마이그레이션해야 하는 애플리케이션 목록에 포함할 가능성이 높습니다.

클라우드 우선에 대해 이야기할 때 우리는 작업 방식에 대해 이야기합니다.
위에서 우리는 클라우드 환경을 위한 고품질 컨테이너 애플리케이션을 구축하기 위한 방법론적 기반을 설정하는 여러 가지 일반 원칙을 공식화했습니다.

이러한 일반 원칙 외에도 컨테이너 작업을 위한 고급 방법과 기술이 추가로 필요합니다. 또한 보다 구체적이고 상황에 따라 적용(또는 적용하지 않음)해야 하는 몇 가지 간단한 권장 사항이 있습니다.

• 이미지 크기를 줄이십시오. 임시 파일을 삭제하고 불필요한 패키지를 설치하지 마십시오. 컨테이너 크기가 작을수록 더 빨리 조립되어 네트워크를 통해 대상 호스트에 복사됩니다.
• 임의의 사용자 ID에 중점을 둡니다. sudo 명령이나 특수 사용자 ID를 사용하여 컨테이너를 시작하지 마세요.
• 중요한 포트 표시: 런타임에 포트 번호를 설정할 수 있지만 EXPOSE 명령을 사용하여 포트 번호를 지정하는 것이 더 좋습니다. 이렇게 하면 다른 사람과 프로그램이 이미지를 더 쉽게 사용할 수 있습니다.
• 볼륨에 영구 데이터 저장: 컨테이너가 폐기된 후에도 남아 있어야 하는 데이터는 볼륨에 기록되어야 합니다.
• 이미지 메타데이터 작성: 태그, 라벨 및 주석을 사용하면 이미지를 더 쉽게 사용할 수 있습니다. 다른 개발자들이 감사할 것입니다.
• 호스트 및 이미지 동기화: 일부 컨테이너화된 애플리케이션에서는 시간이나 컴퓨터 ID와 같은 특정 속성에 대해 호스트와 동기화하기 위해 컨테이너가 필요합니다.
• 결론적으로, 위에 나열된 원칙을 보다 효과적으로 구현하는 데 도움이 되는 템플릿과 모범 사례를 공유합니다.
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

OpenShift Container Platform의 새 버전에 대한 웹 세미나 - 4
11 월 11.00 일 XNUMX

당신이 배울 내용:

• 불변의 Red Hat Enterprise Linux CoreOS
• OpenShift 서비스 메시
• 연산자 프레임워크
• K네이티브 프레임워크

출처 : habr.com