클라우드 네이티브 애플리케이션의 정의와 특징, 그리고 12요소 방법론과 15요소 방법론에 대해 논의하고자 합니다. 이러한 표준은 마이크로서비스 개발자가 알아야 할 필수 개념으로, 향후 마이크로서비스의 다양한 개념을 구축할 때 기반이 될 것입니다.
클라우드 네이티브 애플리케이션이란?
클라우드 네이티브 애플리케이션은 클라우드 환경에서 최적의 성능을 발휘하도록 설계되고 개발된 소프트웨어 애플리케이션입니다. 이러한 애플리케이션은 클라우드 컴퓨팅의 원칙을 최대한 활용하며, 확장성, 탄력성, 유연성과 같은 클라우드의 장점을 충분히 이용하도록 구축됩니다.
간단히 말해,
클라우드 네이티브 애플리케이션은 클라우드 환경에서 실행될 수 있도록 설계된 애플리케이션입니다.
이러한 애플리케이션은 클라우드 제공자의 서비스와 기술을 최대한 활용할 수 있도록 최적화되어 있습니다.
클라우드 네이티브 컴퓨팅 재단(CNCF)의 공식 정의
클라우드 네이티브 컴퓨팅 재단(CNCF)의 정의에 따르면, 클라우드 네이티브 기술은 조직이 확장 가능한 애플리케이션을 현대적인 동적 환경(예: 퍼블릭, 프라이빗, 하이브리드 클라우드)에서 구축하고 실행할 수 있도록 합니다. 이러한 기술을 사용하면 특정 클라우드 환경에 종속되지 않고, 다양한 클라우드 환경에서 일관된 성능을 유지할 수 있습니다.
클라우드 네이티브 애플리케이션의 특징
클라우드 네이티브 애플리케이션은 다음과 같은 기술을 활용하여 다양한 클라우드 환경에서 작동할 수 있습니다.
- 컨테이너: 애플리케이션을 독립적인 환경에서 실행할 수 있게 합니다.
- 서비스 메시: 마이크로서비스 간의 통신을 관리하고 최적화합니다.
- 마이크로서비스: 독립적인 서비스로 분리하여 애플리케이션을 개발하고 관리합니다.
- 불변 인프라: 인프라 변경 없이 애플리케이션을 일관되게 배포할 수 있습니다.
- 선언적 API: 상태를 명확하게 정의하고 이를 자동으로 관리할 수 있게 합니다.
이러한 기술은 루즈 커플링(loose coupling)된 시스템을 개발하게 하여, 시스템이 탄력적이고, 관리 가능하며, 관찰 가능하게 만듭니다. 이는 시스템이 장애를 견디고, 쉽게 관리되며, 시스템의 상태를 명확하게 파악할 수 있음을 의미합니다.
클라우드 네이티브 애플리케이션의 이점
- 고빈도 변경: 클라우드 네이티브 애플리케이션은 소규모 변경 사항이나 기능 개선을 자주 수행할 수 있습니다.
- 예측 가능성: 변경 사항이 예측 가능하게 배포되고 운영되므로, 결함이나 회귀 문제를 최소화할 수 있습니다.
- 개발자 및 조직의 자유: 조직은 애플리케이션의 다양한 부분을 독립적으로 개발하고 테스트할 수 있는 자유를 얻게 됩니다.
클라우드 네이티브 애플리케이션의 중요한 특성
클라우드 네이티브 애플리케이션의 주요 특성에 대해 살펴보겠습니다. 아래 살펴볼 특성은 특정 애플리케이션을 클라우드 네이티브 애플리케이션이다 할 수 있는 근거가 될 중요한 특성입니다.
1. 마이크로서비스 아키텍처
마이크로서비스는 클라우드 네이티브 애플리케이션의 핵심 특성 중 하나입니다. 마이크로서비스는 비즈니스 로직을 작고 독립적인 서비스로 분리하여 구축합니다. 이러한 구조는 애플리케이션을 병렬로 개발하고 독립적으로 배포하며 확장할 수 있는 유연성을 제공합니다.
루즈 커플링: 마이크로서비스는 서로 느슨하게 결합되어 있어 개별 서비스가 다른 서비스에 영향을 주지 않고 독립적으로 동작할 수 있습니다.
독립적 배포 및 확장: 각 마이크로서비스는 개별적으로 배포 및 확장될 수 있습니다.
2. 컨테이너화
클라우드 네이티브 애플리케이션은 일반적으로 컨테이너를 사용하여 패키징되고 배포됩니다. Docker와 같은 컨테이너 기술은 애플리케이션이 경량의 일관된 실행 환경에서 실행될 수 있도록 지원하며, 이를 통해 다양한 클라우드 플랫폼 및 인프라에서 쉽게 이식될 수 있습니다.
이식성: 컨테이너는 로컬 시스템, AWS, GCP, Azure와 같은 다양한 클라우드 환경에서 동일하게 동작합니다.
일관성: 컨테이너는 애플리케이션 실행 환경을 동일하게 유지하여 환경 간의 차이로 인한 문제를 최소화합니다.
3. 확장성과 탄력성
클라우드 네이티브 애플리케이션은 수평 확장과 탄력성을 제공합니다. 마이크로서비스와 컨테이너 기술을 사용하면 애플리케이션이 들어오는 트래픽에 맞춰 자동으로 확장되거나 축소될 수 있습니다.
자동 확장: Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼을 사용하여 자동으로 서비스 인스턴스를 추가하거나 제거할 수 있습니다.
탄력성: 애플리케이션은 변화하는 요구에 따라 유연하게 대응할 수 있습니다.
4. DevOps 관행 준수
클라우드 네이티브 애플리케이션은 DevOps 관행을 적극적으로 채택하여 개발팀과 운영팀 간의 협업 문화를 증진합니다. 이를 통해 지속적 통합(Continuous Integration), 지속적 전달(Continuous Delivery), 자동 배포 파이프라인 등을 통해 소프트웨어 개발 및 배포 프로세스를 간소화합니다.
자동화: DevOps를 통해 자동화된 테스트, 빌드, 배포 프로세스를 구현하여 개발 속도를 높이고 오류를 줄일 수 있습니다.
지속적 통합 및 배포: 지속적 통합과 배포는 코드 변경이 빠르게 프로덕션에 반영될 수 있도록 지원합니다.
5. 탄력성과 장애 복구 능력
클라우드 네이티브 애플리케이션은 탄력성과 장애 복구 능력을 가지고 있습니다. 이러한 애플리케이션은 장애를 견디고, 자동으로 복구되며, 고가용성을 유지할 수 있습니다.
다중 지역 배포: 마이크로서비스를 여러 지역에 배포하여 특정 지역의 장애가 발생하더라도 다른 지역에서 서비스가 지속될 수 있습니다.
자동 장애 복구: Kubernetes와 같은 플랫폼을 사용하여 장애가 발생한 서비스 인스턴스를 자동으로 복구할 수 있습니다.
6. 클라우드 네이티브 서비스 활용
클라우드 네이티브 애플리케이션은 클라우드 제공자의 다양한 서비스를 최대한 활용합니다. 이러한 서비스는 인프라를 자동으로 관리하고 모니터링하여 개발자가 애플리케이션 로직에 집중할 수 있도록 돕습니다.
인프라 관리 부담 감소: 클라우드 제공자가 인프라를 관리하므로, 개발자는 비즈니스 로직과 애플리케이션 개선에 집중할 수 있습니다.
클라우드 네이티브 애플리케이션과 전통적인 애플리케이션의 차이점
그렇다면 무엇이 일반 전통적인 애플리케이션과 클라우드 네이티브 애플리케이션을 나누는지 궁금합니다. 두 종류의 애플리케이션 간 차이를 공부해도록 합니다.
1. 예측 가능한 동작 vs. 예측 불가능한 동작
클라우드 네이티브 애플리케이션: 이 애플리케이션은 예측 가능한 동작을 제공합니다. 마이크로서비스 환경에서 문제가 발생하면, 각 서비스가 독립적으로 동작하므로 문제의 원인을 쉽게 추적할 수 있습니다. 예외가 발생한 위치를 빠르게 파악할 수 있어 디버깅이 용이합니다.
전통적인 애플리케이션: 전통적인 모놀리식 애플리케이션은 모든 비즈니스 로직이 하나의 코드베이스에 결합되어 있어 문제가 발생했을 때 원인을 추적하기 어렵습니다. 예외가 발생한 위치를 찾기 위해 전체 코드를 디버깅해야 하므로, 동작이 예측 불가능합니다.
2. 운영 체제(OS) 의존성
클라우드 네이티브 애플리케이션: 클라우드 네이티브 애플리케이션은 운영 체제에 의존하지 않습니다. Docker와 같은 컨테이너 기술을 사용하여 운영 체제를 추상화하며, 다양한 운영 체제에서 동일하게 실행될 수 있습니다.
전통적인 애플리케이션: 전통적인 애플리케이션은 운영 체제에 의존적입니다. 특정 OS에서만 제대로 동작하며, 이를 다른 OS로 이식하는 데 어려움이 있습니다.
3. 적절한 크기 조정 vs. 과도한 용량
클라우드 네이티브 애플리케이션: 이 애플리케이션은 적절한 크기와 용량으로 설계됩니다. 각 마이크로서비스는 독립적으로 동작하며, 비즈니스 로직이 적절하게 분리되어 있습니다.
전통적인 애플리케이션: 전통적인 애플리케이션은 비즈니스 로직이 단일 코드베이스에 포함되어 있어, 과도한 용량을 가지며, 서비스 간에 의존성이 높습니다.
4. 지속적 배포 vs. 폭포수 개발
클라우드 네이티브 애플리케이션: DevOps 원칙과 자동화를 통해 지속적 통합(CI) 및 지속적 배포(CD)를 지원합니다. 이를 통해 애자일 방식으로 소프트웨어를 개발하고 배포할 수 있습니다.
전통적인 애플리케이션: 폭포수 개발 방식을 따르며, 애자일 방식의 개발과 배포를 지원하지 않습니다. 이는 변화에 빠르게 대응하지 못하는 결과를 초래합니다.
5. 신속한 복구 및 자동 확장 vs. 느린 복구와 수동 확장
클라우드 네이티브 애플리케이션: 자동화된 복구와 확장 기능을 제공합니다. Kubernetes와 같은 플랫폼을 사용하여 마이크로서비스의 인스턴스가 실패하면 자동으로 새로운 인스턴스를 생성하고 복구할 수 있습니다. 또한 트래픽에 따라 자동으로 확장됩니다.
전통적인 애플리케이션: 자동화된 복구와 확장 기능이 부족합니다. 문제가 발생하면 수동으로 해결해야 하며, 확장성도 제한적입니다.
12 Factor Methodology
12 Factor Methodology는 2012년에 Heroku의 엔지니어링 팀이 소개한 개발 원칙으로, 클라우드 네이티브 애플리케이션을 설계하고 개발할 때 따라야 할 12가지 원칙을 제시합니다. 이 원칙들은 Heroku 팀이 오랜 기간 동안 클라우드 네이티브 애플리케이션을 구축하면서 쌓은 경험을 바탕으로 만들어졌습니다.
12 Factor Methodology를 따르면 다음과 같은 이점을 얻을 수 있습니다.
- 클라우드 플랫폼 배포 준비: 어떤 클라우드 플랫폼이든 애플리케이션을 원활하게 배포할 수 있습니다.
- 확장성 및 탄력성 지원: 애플리케이션이 확장성과 탄력성을 기본적으로 지원합니다.
- 시스템 이식성: 애플리케이션이 다양한 시스템과 환경에서 문제없이 실행될 수 있습니다.
- 지속적 배포와 애자일 개발: 클라우드 네이티브 애플리케이션은 지속적 배포와 애자일 개발 방법론을 지원합니다.
앞서 공부했던 클라우드 네이티브 애플리케이션의 특성과도 유사합니다.
이러한 12 Factor Methodology는 시간이 지나면서 일부 영역에서 개선이 필요하게 되었습니다. 이에 따라 Kevin Hoffman이라는 사람이 12 Factor Methodology를 확장하여 15 Factor Methodology를 제안했습니다. 그는 자신의 책 "Beyond the Twelve-Factor App"에서 세 가지 추가 원칙을 도입하여 이 방법론을 최신 상태로 업데이트했습니다.
15 Factor Methodology는 현재 마이크로서비스 및 클라우드 네이티브 애플리케이션 개발에서 가장 최신의 표준으로 간주됩니다.
정리하자면,
- 12 Factor Methodology: 12factor.net이라는 웹사이트에서 이 방법론의 12가지 원칙을 확인할 수 있습니다. 이 웹사이트는 각 원칙에 대한 자세한 설명을 제공합니다.
- 15 Factor Methodology: Kevin Hoffman's 책에서 설명된 3가지 추가 원칙을 포함하여, 클라우드 네이티브 애플리케이션을 최신 기술에 맞게 개발하는 방법을 안내합니다.
15 Factor Methodology
최신 표준이라 할 수 있는 15가지 방법론을 하나씩 살펴보겠습니다.
1. 하나의 코드베이스, 하나의 애플리케이션
- 원칙: 하나의 애플리케이션은 하나의 코드베이스를 가져야 합니다.
각 애플리케이션 또는 마이크로서비스는 자체적인 전용 코드베이스를 가져야 하며, 이 코드베이스는 독립적으로 관리되어야 합니다. 공통된 코드가 여러 마이크로서비스에서 사용된다면, 해당 코드는 별도의 라이브러리로 관리하거나 백엔드 서비스로 독립적으로 배포해야 합니다.
실행 방법: 코드베이스는 단일 GitHub 리포지토리 또는 버전 관리 시스템에서 관리되어야 하며, 모든 환경에서 동일한 코드베이스가 사용되도록 해야 합니다. 환경별로 재구성된 코드베이스 패키지를 생성하지 말고, 단 한 번 패키징된 아티팩트를 모든 환경에 배포해야 합니다.
2. API 우선 설계
- 원칙: API 우선 설계를 채택해야 합니다.
클라우드 네이티브 애플리케이션에서는 API 우선 접근 방식을 채택해야 합니다. 즉, 모든 비즈니스 로직은 가능한 한 API를 통해 설계되고 개발되어야 합니다.
이점: API 우선 접근 방식은 비즈니스 로직이 다른 마이크로서비스 또는 API에 의해 호출될 수 있는 유연성을 제공합니다. 또한, 이 방식은 배포 파이프라인에서 통합 테스트를 쉽게 수행할 수 있게 하며, API 뒤에서 내부 구현을 수정해도 다른 팀이나 애플리케이션에 영향을 미치지 않습니다.
3. 의존성 관리
- 원칙: 모든 의존성을 명시적으로 선언하고 관리해야 합니다.
애플리케이션의 모든 의존성은 단일 매니페스트 파일에 명시적으로 선언되어야 하며, 이는 빌드 툴이 중앙 저장소에서 필요한 라이브러리를 자동으로 다운로드할 수 있도록 해야 합니다.
예시: 자바 애플리케이션에서는 Maven 또는 Gradle을 사용하여 pom.xml 또는 build.gradle 파일에 의존성을 선언합니다. 빌드 툴은 이 파일을 읽고 필요한 라이브러리를 중앙 저장소에서 다운로드하여 로컬 리포지토리에 저장합니다. 이후, 이 의존성 라이브러리들이 패키징 과정에서 애플리케이션과 함께 포함됩니다.
4. 설계, 빌드, 릴리스, 실행
- 원칙: 애플리케이션 코드베이스는 설계 단계에서 실행 단계까지 명확한 단계별 프로세스를 따라야 합니다.
설계 단계: 필요한 기술, 의존성, 도구를 식별하고 개발 및 단위 테스트를 수행합니다.
빌드 단계: 코드베이스를 컴파일하고 패키징하여 불변의 아티팩트를 생성합니다. 각 빌드 아티팩트는 고유한 식별 번호를 가져야 합니다.
릴리스 단계: 빌드 아티팩트를 배포 구성과 결합하여 불변의 릴리스 구성 요소를 만듭니다. 이러한 릴리스 구성 요소는 중앙 저장소에 저장되어야 하며, 필요시 롤백을 쉽게 할 수 있도록 합니다.
실행 단계: 애플리케이션을 지정된 환경에서 실행합니다.
5. 구성, 자격 증명 및 코드 분리
- 원칙: 구성 요소는 코드베이스와 분리되어야 하며, 애플리케이션은 외부에서 구성 정보를 주입받아야 합니다.
구성 요소는 환경 간에 달라질 수 있는 요소로, 데이터베이스 속성, 메시지 시스템 속성, 외부 API 자격 증명, 기능 플래그 등이 포함됩니다. 이러한 구성 요소는 코드베이스와 함께 저장되지 않아야 하며, 환경 간에 독립적으로 관리되어야 합니다.
실행 방법: 코드베이스는 불변의 상태로 유지되어야 하며, 각 환경에 배포할 때 필요한 구성 요소는 런타임에 주입되어야 합니다. 이를 통해 환경 간 일관성을 유지할 수 있습니다.
6. 로그 관리 (Logs)
- 원칙: 로그 관리는 애플리케이션의 책임이 아니라 외부 도구를 통해 관리해야 합니다.
전통적인 모놀리식 애플리케이션에서는 로그를 서버의 파일이나 폴더에 기록하고, 개발자는 특정 날짜와 시간에 대한 로그 파일을 열어 문제를 추적합니다. 그러나 마이크로서비스나 클라우드 네이티브 애플리케이션에서는 수백 개의 마이크로서비스가 있을 수 있기 때문에 이 방법은 비효율적입니다.
실행 방법: 애플리케이션은 로그를 표준 출력으로 리디렉션하고, 로그 집계 도구(log aggregator)가 이 로그들을 수집하여 단일 위치에서 로그를 관리하도록 해야 합니다. 개발자와 운영 팀은 이 도구를 사용해 모든 마이크로서비스의 로그를 중앙에서 확인하고 디버깅할 수 있습니다.
7. 애플리케이션 폐기성 (Disposability)
- 원칙: 애플리케이션은 신속하게 시작되고, 필요에 따라 안전하게 종료될 수 있어야 합니다.
클라우드 네이티브 애플리케이션에서는 특정 마이크로서비스가 응답하지 않거나 중단되었을 때 자동으로 종료하고 새로운 인스턴스를 생성하는 것이 중요합니다. 또한 높은 트래픽이 발생할 때는 추가 인스턴스를 생성하여 부하를 처리하고, 부하가 줄어들면 인스턴스를 줄일 수 있어야 합니다.
실행 방법: 애플리케이션은 빠르게 시작될 수 있어야 하며, 종료 시에는 새로운 요청을 받지 않고, 진행 중인 요청은 안전하게 완료된 후 종료되어야 합니다. 이는 시스템의 탄력성과 복원력을 보장하는 데 필수적입니다. 이를 구현하기 위해 Spring Boot 프레임워크와 Docker 컨테이너를 사용하며, Kubernetes와 같은 오케스트레이션 플랫폼을 통해 자동으로 애플리케이션을 관리합니다.
8. 백엔드 서비스 (Backing Services)
- 원칙: 외부 리소스(데이터베이스, 메일 서버, 메시지 브로커 등)는 독립적으로 교체 가능하도록 관리해야 합니다.
마이크로서비스는 여러 외부 리소스에 의존할 수 있으며, 이러한 리소스를 백엔드 서비스라고 합니다. 이러한 서비스들은 애플리케이션 코드와 분리되어 관리되어야 하며, 필요에 따라 쉽게 교체될 수 있어야 합니다.
실행 방법: 데이터베이스와 같은 리소스는 외부 설정 파일을 통해 URL, 사용자 이름, 비밀번호 등의 정보를 제공받아야 하며, 애플리케이션의 코드베이스와는 독립적으로 관리되어야 합니다. 예를 들어, 개발 환경에서는 로컬 데이터베이스를 사용하고, 프로덕션 환경에서는 클라우드 데이터베이스를 사용할 수 있어야 합니다.
9. 환경 일관성 (Environment Parity)
- 원칙: 개발, 테스트, 프로덕션 환경 간의 차이를 최소화하고, 모든 환경이 일관되도록 유지해야 합니다.
환경 간 차이가 크면 애플리케이션의 동작이 예측 불가능해지며, 디버깅이 어려워집니다. 따라서 모든 환경이 최대한 유사하게 유지되도록 해야 합니다.
실행 방법: 이를 위해 지속적 통합(CI)과 지속적 배포(CD) 파이프라인을 채택하여 코드 변경이 신속하게 모든 환경에 배포되도록 합니다. 또한, 개발자와 운영팀 간의 협력을 강화하여 모든 환경에서 동일한 도구와 버전을 사용하도록 해야 합니다.
10. 관리 작업 (Administrative Processes)
- 원칙: 데이터베이스 마이그레이션, 배치 작업 등 관리 작업도 애플리케이션 코드와 별도로 관리되어야 합니다.
애플리케이션을 지원하는 관리 작업(예: 데이터베이스 마이그레이션, 배치 작업)은 독립적인 프로세스로 관리되어야 하며, 애플리케이션과 동일한 환경에서 실행되어야 합니다.
실행 방법: 관리 작업은 독립적인 마이크로서비스로 배포하여 필요할 때만 실행하고, 사용 후에는 폐기할 수 있어야 합니다. 이를 통해 관리 작업이 애플리케이션의 비즈니스 로직과 혼재되지 않도록 하고, 필요에 따라 손쉽게 관리 작업을 수행할 수 있습니다.
11. 포트 바인딩 (Port Binding)
- 원칙: 클라우드 네이티브 애플리케이션은 자체 서버를 포함하고, 서비스는 포트 바인딩을 통해 외부에 노출해야 합니다.
전통적인 Java 웹 애플리케이션은 Tomcat, Jetty 등의 서버 컨테이너에서 실행되지만, 클라우드 네이티브 애플리케이션은 외부 서버에 의존하지 않고 자체 서버를 포함해야 합니다. 예를 들어, Spring Boot를 사용하면 애플리케이션에 내장된 서버를 사용하여 애플리케이션이 실행됩니다.
실행 방법: 애플리케이션은 자체 서버를 통해 실행되며, 포트 바인딩을 통해 외부 네트워크에 서비스가 노출됩니다. Docker 컨테이너를 시작할 때 docker run 명령어에서 포트 매핑을 사용하여 포트를 바인딩할 수 있습니다. 이를 통해 클라우드 네이티브 애플리케이션은 외부 서버에 의존하지 않으며, 모든 애플리케이션이 독립적으로 실행될 수 있습니다.
12. 상태 없는 프로세스 (Stateless Processes)
- 원칙: 애플리케이션은 상태를 저장하지 않는 프로세스로 설계되어야 합니다.
클라우드 네이티브 애플리케이션은 확장성을 염두에 두고 설계되며, 이를 위해 상태 없는 프로세스를 사용해야 합니다. 예를 들어, 계좌 서비스의 여러 인스턴스를 실행할 때 각 인스턴스가 서로 상태를 공유하지 않아야 합니다.
실행 방법: 애플리케이션 인스턴스는 상태를 저장하지 않고, 모든 상태 정보(예: 사용자 세션, 캐시 정보)는 데이터베이스나 Redis와 같은 외부 저장소에 저장되어야 합니다. 이를 통해 인스턴스가 중단되거나 새로 생성되더라도 데이터 손실 없이 정상적으로 작동할 수 있습니다.
13. 동시성 (Concurrency)
- 원칙: 애플리케이션은 동시성을 지원하여 다수의 사용자 요청을 동시에 처리할 수 있어야 합니다.
클라우드 네이티브 애플리케이션은 다수의 사용자 요청을 동시에 처리할 수 있어야 하며, 이를 위해 프로세스의 동시성을 관리할 수 있어야 합니다.
실행 방법: Java와 같은 언어는 기본적으로 다중 스레드를 사용하여 동시성을 지원합니다. 또한 애플리케이션을 수평적으로 확장하여 여러 인스턴스가 동시에 여러 요청을 처리할 수 있도록 해야 합니다. 이를 통해 애플리케이션의 성능과 확장성을 극대화할 수 있습니다.
14. 텔레메트리 (Telemetry)
- 원칙: 클라우드 네이티브 애플리케이션은 원격 모니터링 및 관리가 가능하도록 텔레메트리 데이터를 수집하고 제공해야 합니다.
마이크로서비스 환경에서는 여러 애플리케이션과 서비스가 실행되므로, 로그, 메트릭, 트레이스, 상태 등의 텔레메트리 데이터를 수집하여 중앙에서 모니터링할 수 있어야 합니다.
실행 방법: 각 마이크로서비스는 정확하고 종합적인 데이터를 제공해야 하며, 이를 통해 시스템의 동작을 원격에서 모니터링하고 관리할 수 있어야 합니다. 이 텔레메트리 데이터는 로그 분석, 성능 모니터링, 트랜잭션 추적 등 다양한 용도로 사용될 수 있습니다.
15. 인증 및 권한 부여 (Authentication and Authorization)
- 원칙: 클라우드 네이티브 애플리케이션은 보안 표준을 준수하며, 모든 통신과 상호작용은 인증 및 권한 부여를 통해 보호되어야 합니다.
클라우드 네이티브 애플리케이션에서는 보안이 매우 중요하며, 모든 요청은 인증을 통해 사용자 신원을 확인하고, 권한 부여를 통해 사용자가 수행할 수 있는 작업을 제한해야 합니다.
실행 방법: 애플리케이션은 OAuth 2.1, OpenID Connect 등의 표준을 사용하여 보안을 강화해야 하며, 모든 통신은 HTTPS를 통해 암호화되어야 합니다. 이를 통해 애플리케이션의 보안을 강화하고, 악의적인 접근을 방지할 수 있습니다.
