https://governance.openstack.org/tc/reference/technical-vision.html 을 DeepL을 이용해서 기계번역하고, 살짝 수정한 것입니다. (2024.05.14)
목적
이 문서는 살아있는 문서입니다. 이 문서의 목적은 시간이 지남에 따라 진화하는 OpenStack 프로젝트의 결과물에 대한 OpenStack 커뮤니티의 비전을 문서화하는 것입니다. 또한 본질적으로 설명이 아닌 포부를 담고 있습니다. 즉, 특정 시점에 존재했던 오픈스택이 아니라 커뮤니티가 지향하는 오픈스택을 설명합니다.
프로젝트 팀은 제안된 기능을 평가하고 인터페이스를 설계할 때 이 문서를 참조하여 자신의 설계가 더 큰 구조 내에서 편안하게 맞고 애플리케이션 배포 패턴의 전반적인 환경에 기여할 수 있도록 할 수 있습니다.
무엇보다도 기술 위원회는 새로운 프로젝트 애플리케이션을 평가할 때 이 문서를 참조하여 OpenStack의 전반적인 기술 방향에 부합하는지 여부를 결정합니다. 여기에 설명된 비전에 맞지 않는 프로젝트를 진행 중이라고 해서 해당 프로젝트가 공식 OpenStack 프로젝트가 될 수 없다는 의미는 아니지만, 비전을 더욱 구체화하기 위해 이 문서에 패치를 제출해야 한다는 의미일 수 있습니다. 이 경우 새 프로젝트 신청서를 제출할 준비가 될 때까지 기다릴 필요가 없으므로 가능한 한 빨리 제출해야 합니다.
기술위원회는 이 문서를 사용하여 제안된 프로젝트 전반의 목표의 적합성과 우선순위를 평가할 수도 있습니다.
범위
이 문서의 범위는 최종 사용자가 상호작용하는 클라우드 서비스로 제한됩니다. 이는 오픈스택 프로젝트 맵의 메인 ‘OpenStack’ 버킷과 ‘OpenStack Operations’ 버킷의 일부에 해당합니다. OpenStack에는 배포 도구 및 클라이언트 라이브러리와 같은 다른 종류의 공식 프로젝트도 있지만, 이 문서에서 이러한 프로젝트에 대한 비전을 유추할 수 있는 것은 전혀 없습니다.
클라우드의 축
‘클라우드’의 의미에 대해서는 소프트웨어 개발자 수만큼이나 다양한 의견이 존재합니다. 하지만 클라우드가 중요한 의미를 지닌다는 점에는 모두 동의할 수 있습니다. 클라우드 컴퓨팅은 인프라 프로비저닝 및 프로비저닝 해제와 관련된 트랜잭션 비용을 거의 0에 가깝게 줄임으로써 리소스의 보다 효율적인 활용을 촉진하며, 이전 컴퓨팅 모델(가상화 포함)과 질적인 면에서 차이가 있기 때문에 그렇게 할 수 있습니다. 특히 두 가지 특징이 있습니다.
이러한 개념이 시스템의 모든 측면에 항상 적용되는 것은 아니지만, OpenStack의 모든 서비스는 직접적으로 또는 다른 서비스와 함께 작동하여 적용 가능한 모든 곳에서 이러한 개념을 준수할 것으로 기대합니다.
셀프 서비스
클라우드는 셀프 서비스입니다. 사용자가 사람의 작업이나 검토를 기다릴 필요 없이 필요에 따라 애플리케이션을 배포할 수 있는 기능을 제공합니다. 클라우드에는 티켓 트래커가 없습니다. 이 요구 사항은 여러 가지 즉각적인 결과를 가져옵니다.
첫째, 클라우드 서비스는 강력한 멀티테넌시를 제공해야 합니다. 사람의 검토 없이 여러 사용자(또는 사용자 그룹)에게 안전하게 서비스를 제공하려면 시스템의 테넌트 간에 리소스를 격리하여 한 테넌트가 제어하는 리소스가 다른 테넌트가 제어하는 리소스에 액세스하거나 영향을 미치지 않도록 해야 합니다.
또한 클라우드 서비스는 사용자에 대한 가치가 용량을 제공하는 운영자의 기회 비용을 초과하는 경우에만 용량이 활용되도록 하는 메커니즘을 갖추고 있어야 합니다. 퍼블릭 클라우드에서는 일반적으로 사용자에게 소비된 리소스에 대해 요금을 부과하는 방식으로 이를 수행합니다. 쿼터는 사용자와 클라우드 운영자 모두의 리스크를 제한하는 데 사용됩니다. 사용자의 경우, 특히 리소스 소비 수준이 부분적으로 자동 제어되는 경우 예상치 못한 높은 요금이 청구될 위험이 있습니다. 운영자의 입장에서는 기회 비용이 비선형적으로 증가하는 사용률 수준에 도달하는 것입니다. 프라이빗 클라우드는 차지백 메커니즘을 사용하지 않고 리소스 소비를 제어하기 위한 유일한 기술적 수단으로 할당량에만 의존하더라도 청구에 사용되는 것과 동일한 종류의 모니터링 및 보고 기능이 필요한 경우가 많습니다.
애플리케이션 제어
클라우드를 사용하면 애플리케이션 인프라에 대한 제어권을 애플리케이션 자체에 부여할 수 있습니다. 클라우드를 사용하면 루프에 사람이 개입할 필요가 없는 것처럼, 사용자가 루프에 개입할 필요도 없습니다. 클라우드에는 사용자 인터페이스(그래픽 또는 기타)가 있을 수 있지만 애플리케이션 프로그래밍 인터페이스가 있어야 합니다. 적절한 경우 이벤트 알림을 포함하여 애플리케이션이 읽을 수 있는 형태로 운영과 관련된 정보를 제공해야 합니다. 또한 애플리케이션의 어떤 부분도 클라우드 외부에 상주할 필요가 없으므로 클라우드 자체 내에서 실행 중인 애플리케이션의 API에 대한 보안 액세스가 용이하도록 설계되어야 합니다.
OpenStack 관련 고려 사항
대부분의 독점 클라우드는 단일 조직을 위해 설계된 소프트웨어에 의해 운영됩니다. OpenStack은 다릅니다. 퍼블릭 및 프라이빗 클라우드가 모두 다르며, 각각 다른 목표를 가지고 다른 조직에서 운영하며 다른 의사 결정을 내리는 수많은 OpenStack 클라우드가 있습니다. 이러한 클라우드에는 중복되는 사용자 집합이 있을 수 있습니다. 이로 인해 OpenStack에만 적용되는 일부 요구사항이 다른 클라우드에서 공유되지 않을 수 있습니다.
이러한 개념이 항상 시스템의 모든 측면에 적용될 수 있는 것은 아니지만, 적용 가능한 모든 프로젝트에서 OpenStack의 모든 프로젝트가 이러한 개념을 준수할 것으로 기대합니다.
상호 운용성
동일한 애플리케이션 설명(어떤 형태이든)은 최소한의 격리된 수정만으로 다양한 퍼블릭 및 프라이빗 OpenStack 클라우드에 배포할 수 있어야 합니다. 요구 사항이나 일반적인 OpenStack 배포 패턴이 다른 경우(예: 퍼블릭 클라우드와 프라이빗 클라우드 간), 애플리케이션을 한 OpenStack 클라우드에서 다른 클라우드에 이식할 수 있도록 두 환경 모두에서 사용할 수 있는 메커니즘을 설계하기 위해 노력해야 합니다. 백엔드 드라이버 차이 및 운영자의 파티셔닝 구성 선택과 같은 배포 구현 세부 사항은 가능한 한 리소스 소비자 경험에 누출되지 않도록 해야 하며, 특히 관리가 아닌 API 메서드의 동작을 변경해서는 안 됩니다.
양방향 호환성
단일 클라우드와 상호 작용할 때는 클라우드 소프트웨어의 변경이 이전 버전에서 최신 버전으로 진행되는 단조로운 방식이라고 가정하는 것이 합리적입니다. 하지만 사용자가 여러 클라우드와 상호 작용할 때는 이러한 가정이 더 이상 유효하지 않습니다. 최신 버전의 OpenStack과 상호 작용하는 사용자는 이전 버전의 OpenStack을 실행하는 다른 클라우드로 이동할 수 있습니다. 따라서 OpenStack 서비스는 구형 및 최신 클라이언트 모두에서 정상적으로 작동하거나 정상적으로 실패하는 방식으로 발전해야 합니다.
공용 API에 대한 모든 변경 사항은 버전이 지정되고 단계적으로 적용되어야 하며, 클라이언트가 사용 가능한 버전과 기능에 대해 스스로 점검할 수 있는 공통 메커니즘이 있어야 합니다.
프로젝트 간 종속성
모든 OpenStack 클라우드에 동일한 서비스 집합이 포함되어 있는 것은 아니며, 새로운 서비스를 배포하고 관리하려면 클라우드 운영자의 추가 작업이 필요합니다. 서비스가 다른 서비스의 기능을 재사용하는 것은 권장하지만, 하드 종속성을 추가하여 재사용을 극대화할 것을 요구하지는 않습니다. 하드 종속성을 추가하려면 항상 설계의 단순성과 운영 유연성 사이에서 절충점을 찾아야 합니다. 프로젝트는 보안에 민감한 코드의 표면적을 줄이거나, 중복 버그의 가능성을 줄이거나, 확장성이나 복원력과 같은 바람직한 속성을 구현하거나, 팀의 개발 속도를 높이는 등 궁극적으로 사용자에게 도움이 된다고 판단될 때 하드 종속성을 추가해야 합니다. 특히 운영자와 사용자에게 제공하는 보안상의 이점에 높은 가중치를 두어야 합니다.
특정 기능이 선택적 서비스가 있을 때만 사용할 수 있는 소프트 종속성은 많은 경우에 장단점을 해결할 수 있는 좋은 솔루션입니다.
구획
OpenStack 클라우드의 리전은 Keystone 서비스 카탈로그에서 별도의 서비스 엔드포인트 집합으로 정의되지만, 등록된 사용자는 동일한 인증 URL에서 시작하여 클라우드의 모든 리전에 액세스할 수 있는 공유 Keystone으로 정의됩니다. 이 의미는 OpenStack 소프트웨어에 의해 제어되므로 클라우드 간에 일관성이 유지되는 경향이 있습니다.
반면 하드웨어 또는 데이터센터의 물리적 토폴로지에 의해 정의되는 리소스 그룹은 개별 클라우드 사업자의 통제 하에 있습니다. 예를 들어, 많은 클라우드에는 공통 장애 지점을 공유하지 않는 지역 내 그룹인 ‘가용성 영역’이라는 개념이 포함되어 있습니다. OpenStack 소프트웨어는 클라우드 전반에 걸쳐 이러한 의미를 강제할 방법이 없으며, 클라우드 운영자가 리소스를 함께 그룹화하려는 다른 많은 이유가 있습니다. OpenStack 프로젝트는 운영자가 관리하는 리소스의 임의의 계층적 그룹을 만들 수 있도록 허용하고 그룹에 물리적 의미를 부여하지 않는 방향으로 나아갈 것을 권장합니다.
설계 목표
다음 설계 목표는 애플리케이션과 사용자에게 OpenStack 서비스 전체가 제공하고자 하는 기능을 나타냅니다. 모든 서비스나 기능이 나열된 모든 목표를 달성할 것으로 기대되는 것은 아닙니다(또는 달성할 수도 있습니다). 오히려 아래 목표 중 하나 이상의 목표를 달성하는 데 기여하는 모든 서비스는 OpenStack 프로젝트의 사명을 더욱 발전시키는 데 도움이 될 것입니다.
기본적인 물리 데이터센터 관리
오픈스택은 운영 중인 데이터센터의 존재를 전제로 하지 않으며, 데이터센터를 운영하고 소비자들이 리소스를 사용할 수 있도록 하는 도구를 제공합니다. OpenStack 전체 아래에는 필수 계층이 없습니다. 컴퓨팅, 스토리지, 네트워킹 하드웨어, 도메인 이름 시스템, ID 관리 시스템과 같은 외부 시스템을 처리하는 데 필요한 추상화를 제공합니다. OpenStack API는 다양한 공급업체와 오픈 소스 프로젝트에서 각각 구현될 수 있는 이러한 시스템에 대한 일관된 인터페이스를 제공합니다.
이러한 광범위한 기반은 OpenStack 자체 서비스뿐만 아니라 타사의 서비스까지 보다 전문화된 서비스를 호스팅할 수 있는 추상화를 제공합니다.
다른 서비스와 잘 어울림
오픈스택은 자체와 최종 사용자 애플리케이션 사이에 서비스형 플랫폼, 서버리스 컴퓨팅 플랫폼, 컨테이너 오케스트레이션 엔진 등 추가적인 추상화 계층을 지원하고 장려하며, 이를 통해 제공하는 컴퓨팅 용량 내에서 실행됩니다. 오픈스택은 이러한 계층을 제공하는 인기 있는 타사 오픈 소스 프로젝트의 오픈스택 클라우드에 대한 긴밀한 통합을 지원하는 도구를 제공해야 합니다.
여러 잠재적 백엔드 서비스에 대한 추상화 계층을 포함하는 OpenStack 프로젝트는 해당 추상화 계층을 독립형 엔티티로 제공하여 실제 OpenStack 클라우드와 독립적으로 외부 서비스에서 사용할 수 있도록 할 수도 있습니다.
하드웨어 가상화
일반적으로 특수 하드웨어에 의해 제공되는 모든 서비스의 경우, OpenStack은 멀티테넌트 환경에서 리소스 할당을 소프트웨어 정의로 제어할 수 있는 공급업체 독립적인 API를 제공하는 것을 목표로 합니다. 여기에는 가상 서버에만 국한되지 않고 스토리지, 라우터, 로드 밸런서, 방화벽, HSM, GPGPU, FPGA, ASIC(예: 비디오 코덱) 등이 포함될 수 있습니다.
이러한 하드웨어 범주 중 일부는 동일한 API를 기반으로 사용할 수 있는 순수 소프트웨어에 해당하는 제품이 있을 수 있으며, 이러한 경우 특수 하드웨어가 없는 클라우드에서도 애플리케이션을 이식할 수 있습니다.
무한하고 지속적인 확장
OpenStack은 애플리케이션 개발자에게 원칙적으로 애플리케이션을 재설계하지 않고도 아주 작은 워크로드에서 아주 큰 워크로드까지 효율적으로 확장할 수 있는 인터페이스를 제공하기 위해 노력하고 있습니다.
이는 부분적으로는 특정 애플리케이션에 개별 청크를 할당하고 활용하지 않는 청크 내의 초과 용량을 낭비하는 대신 소비자가 필요에 따라 용량을 사용하고 기본 리소스를 다른 애플리케이션 및 테넌트와 공유할 수 있도록 허용하는 것을 의미합니다.
사용자 정의 가능한 통합
OpenStack은 애플리케이션에 특정 배포 모델이나 아키텍처를 강요하지 않습니다. 모든 애플리케이션에는 고유한 요구사항이 있으며, OpenStack은 사전 정의된 배포 모델만 지원하는 배후에서 하드 와이어 작업을 수행하는 대신 공용 API를 통해 ‘사용자 공간’에서 서비스를 함께 연결할 수 있도록 함으로써 이러한 요구사항을 수용합니다.
이를 통해 애플리케이션 개발자는 클라이언트 측 글루를 사용하여 무엇이든 커스터마이징할 수 있지만, 반드시 그럴 필요는 없습니다. 오픈스택 서비스는 초기 배선 외에 클라이언트 측 상호 작용 없이도 클라우드 소비자가 서로 연결할 수 있을 정도로 충분히 통합되어야 합니다.
보안 모델은 오픈스택 서비스 간, 애플리케이션과 오픈스택 서비스 간 양방향 상호 작용을 모두 허용해야 합니다. 또한 클라우드 소비자는 애플리케이션이 설계된 대로 작동하는 데 필요한 최소한의 권한만 위임할 수 있어야 하며, 인터넷에 연결된 컴퓨터가 결국 손상될 가능성이 있는 환경에서 최대한의 보안을 유지하기 위해 자격 증명을 정기적으로 해지하고 교체할 수 있어야 합니다.
추상적인 특수 작업
애플리케이션의 특정 구성 요소(예: 데이터베이스)는 종종 이를 운영하기 위해 전문적인 기술을 필요로 합니다. 이러한 구성 요소 중 가장 일반적인 일부의 관리를 API로 추상화함으로써 OpenStack은 해당 구성 요소와 나머지 애플리케이션 간의 관계를 공식화할 수 있도록 합니다. 필요한 전문가를 활용할 수 있는 조직의 경우, 이를 통해 해당 전문가가 중앙 집중식 방식으로 작업하여 더 많은 애플리케이션을 다룰 수 있습니다. 다른 조직의 경우, 퍼블릭 또는 관리형 OpenStack 클라우드를 통해 다른 방법으로는 얻을 수 없었던 전문 기술에 액세스할 수 있습니다.
애플리케이션의 모든 재사용 가능한 구성 요소가 자체적인 OpenStack 서비스를 보장하는 것은 아닙니다. 일반적으로 복잡한 구성, 지속적인 수명 주기 관리 요구 사항, 정교한 OpenStack 인프라 요구 사항(예: 가상 서버 클러스터 관리)이 있는 경우에 적합한 후보입니다.
그래픽 사용자 인터페이스
GUI는 신규 사용자가 클라우드에 접근하고 일반 사용자가 클라우드의 낯선 영역을 실험하는 데 가장 좋은 방법일 때가 많습니다. 옵션과 워크플로우를 그래픽으로 표시하면 API나 CLI 설명서를 읽을 때와는 다른 방식으로 기능을 발견할 수 있습니다. 또한 GUI는 숙련된 사용자와 클라우드 운영자도 클라우드 리소스의 상태를 전반적으로 파악하고 리소스 간의 관계를 시각화할 수 있는 가장 좋은 방법이기도 합니다. 이러한 이유로, API 및 기타 사용자 인터페이스 외에도 OpenStack에는 웹 기반 그래픽 사용자 인터페이스가 포함되어야 합니다.
이 비전에 대한 프로젝트 팀의 반성
이 비전이 발표되었을 때, 프로젝트 팀은 자신의 프로젝트가 이 비전과 어떻게 비교되는지 판단하기 위해 자체 평가 또는 반성문을 작성하도록 권장되었습니다. 이러한 자체 평가의 모음은 아래에 나와 있습니다.
