Skip to main content
IBM Quantum Platform

조직을 위한 IBM 퀀텀 플랫폼 설정 시 고려 사항

IBM Quantum® Platform IBM Cloud® 계정의 IBM Quantum 컴퓨트 서비스 인스턴스 및 워크로드를 관리하는 대시보드이며, 액세스 관리 현황을 한눈에 파악할 수 있도록 간소화된 보기를 제공합니다. 조직의 IBM Cloud 계정에는 여러 사용자와 여러 Quantum Compute 인스턴스가 있을 수 있으며, 각 인스턴스에는 고유한 할당량이 부여됩니다. 신원 및 액세스 관리(IAM)는 어떤 사용자가 어떤 서비스 인스턴스에 액세스할 수 있는지 제어하므로, 필요한 경우 가시성을 제한하면서도 협업을 활성화할 수 있습니다. 유료 요금제를 사용하는 서비스 인스턴스가 있는 경우, 액세스 관리의 중요성이 더욱 커집니다. 계정, 사용자, 인스턴스 및 액세스 권한이 어떻게 상호 연관되어 있는지 개요를 보려면 ‘ IBM Cloud 계정 구조’를 참조하십시오. 이 가이드에서 언급된 액세스 그룹, 정책, 역할, 리소스 그룹과 같은 IAM 개념에 대한 자세한 내용은 IBM Cloud 의 IAM 문서를 참조하십시오.

이 가이드에서는 여러 서비스 인스턴스를 보유한 조직의 액세스 권한을 설정할 때 고려해야 할 결정 사항과 상충 관계를 설명합니다. 예를 들어, 팀이나 워크로드별로 하나의 인스턴스를 할당하는 경우 등이 있습니다.

Note

조직에 여러 개의 ‘ IBM Cloud ’ 계정이 있는 경우(예: 사업부별로 별도의 계정을 운영하며, 각 계정에 고유한 Quantum Compute 인스턴스가 있는 경우), 이를 단일 ‘ IBM Cloud Enterprise’ 계정 아래에 연결할 수 있습니다. 이 계정은 결제를 담당하는 하나의 주 계정과 하나 이상의 하위 계정으로 구성됩니다. 자녀 계정 간에 프리미엄 또는 플렉스 플랜 할당량을 재분배하려면, IBM Cloud 지원 센터 를 통해 IBM Quantum 지원팀에 문의해 주십시오. 자세한 내용은 ‘ IBM Cloud ’ 엔터프라이즈 계정 설명서를 참조하십시오.


개요

Note

IBM Cloud® 이 가이드에 설명된 메커니즘을 구현하는 여러 가지 방법을 제공합니다. 사용자 지정 역할에 대한 세부 정보를 제외하고, 대부분의 단계는 IBM Cloud 에 공통적으로 적용되는 내용이며 Quantum Compute에만 국한된 것은 아닙니다.

관련된 페르소나

이 가이드에서는 다음과 같은 페르소나들이 언급됩니다:

  • 사용자 : 양자 컴퓨팅 리소스( 서비스 인스턴스 )에 대한 접근 권한을 부여받은 사람으로, 해당 리소스를 통해 다른 사용자와 협업할 수 있는 사람. 사용자의 접근 권한은 관리자가 제어하며, 사용자는 서비스 인스턴스를 생성하거나 삭제할 수 없습니다.
  • 클라우드 관리자 : IBM Quantum 컴퓨팅 리소스를 소유하고, 해당 리소스에 액세스할 수 있는 사용자를 관리하는 IBM Cloud 계정 소유자입니다. 관리자는 리소스 소유자로서 유료 리소스 사용에 대한 요금이 청구됩니다.
  • IDP 관리자 : ID 공급자(IDP)에서 ID 및 해당 속성을 정의하는 관리자입니다.

용어집

이 가이드에서는 다음 용어를 사용합니다:

  • 리소스 : 클라우드 사용자 인터페이스(UI), CLI 또는 API를 통해 관리할 수 있는 객체를 지칭하는 ‘ IBM Cloud ’의 일반적인 용어입니다. 이 가이드에서 ‘리소스 ’란 양자 컴퓨팅 서비스 인스턴스를 의미합니다.
  • 서비스 인스턴스 : 서비스 인스턴스는 IBM Quantum 컴퓨트 서비스를 통해 클라우드 서비스, 특히 양자 컴퓨터에 액세스하는 데 사용됩니다. 이는 카탈로그를 통해 정의됩니다. 동일하거나 서로 다른 요금제를 기반으로 여러 서비스 인스턴스를 정의할 수 있으며, 이를 통해 서로 다른 양자 컴퓨팅 백엔드에 액세스할 수 있습니다. 자세한 내용은 이용 가능한 ‘ IBM Cloud ’ 요금제를 참조하십시오.

설정을 계획하세요

조직을 위해 IBM 퀀텀 플랫폼을 설정하기 전에 이러한 결정을 내려야 합니다:

  • 사용자 신원은 어떻게 정의되나요? IBM Cloud 사용자, 다른 IDP(신원 제공자)의 사용자, 또는 이 둘 모두를 설정할 수 있습니다.

    • 다른 IDP를 사용하는 경우, 사용자를 액세스 그룹에 할당하는 것은 클라우드 관리자인가요, 아니면 IDP 관리자인가요?
    • IDP 관리자가 동적 규칙을 통해 사용자를 할당하는 경우, 일치 키로 사용할 사용자 정의 IDP 사용자 속성이 필요합니다(예: 속성 team ).
  • 서비스 인스턴스가 몇 개나 필요하며, 각 인스턴스는 어떤 용도로 사용될 예정인가요? 인스턴스 이름을 신중하게 정하십시오. IBM Quantum Platform 사용자 인터페이스를 통해 서비스 인스턴스를 생성할 때마다, 플랫폼은 사용자를 대신하여 IAM에 추가 호출을 수행하여 해당 인스턴스에 대한 쓰기 권한을 부여하는 일치하는 액세스 그룹(인스턴스와 동일한 이름에 “Collaborators”가 추가된 이름)을 생성합니다. 따라서 인스턴스 이름은 액세스 그룹 이름이 되기도 합니다. 이 추가 단계는 IBM Quantum Platform 사용자 인터페이스를 통해 인스턴스를 생성할 때만 수행됩니다. Terraform, IBM Cloud CLI 또는 IBM Cloud API를 사용하여 인스턴스를 생성하는 경우에는 이러한 현상이 발생하지 않습니다.

    • 워크로드는 서비스 인스턴스에 속하며, 해당 인스턴스에 대한 액세스 권한이 있는 사용자는 해당 인스턴스의 워크로드를 볼 수 있습니다.
    • 서비스 인스턴스는 서로 다른 요금제를 기반으로 할 수 있으며, 이를 통해 서로 다른 백엔드 및 리소스 할당에 접근할 수 있습니다.
  • 어떤 사용자가 어떤 서비스 인스턴스에 접근해야 합니까?

  • 사용자가 워크로드를 삭제할 수 있어야 할까요? 서비스 인스턴스에 워크로드를 유지하면 비용 청구에 대한 추적성을 높일 수 있습니다.

  • 각 인스턴스에 대해 자동으로 생성되는 액세스 그룹을 사용할 것인지, 직접 추가 액세스 그룹을 생성할 것인지, 개별 사용자에게 직접 액세스 권한을 할당할 것인지, 아니면 인스턴스를 리소스 그룹으로 구성할 것인지 결정하십시오.

    • 액세스 그룹은 IBM Cloud 리소스에 대한 사용자 접근 권한을 제어하는 편리하고 일반적인 방법입니다. IBM Quantum Platform 사용자 인터페이스를 통해 생성하는 모든 서비스 인스턴스에는 이미 고유한 “Collaborators” 액세스 그룹이 설정되어 있습니다. 해당 그룹을 있는 그대로 사용할 수도 있고, ‘ IBM Cloud ’ 콘솔에서 추가 액세스 그룹을 생성하여 하나 이상의 인스턴스에 걸쳐 팀이나 워크로드(예: mlfinance)별로 사용자를 그룹화할 수도 있습니다. 각 액세스 그룹은 사용자가 특정 서비스 인스턴스나 리소스 그룹에 액세스할 수 있도록 허용하는 사용자 지정 역할을 사용합니다. 사용자 그룹 전체가 동일한 접근 권한을 공유할 필요가 없다면, 접근 그룹을 만들지 않고 개별 사용자에게 직접 접근 권한을 할당할 수도 있습니다.
      • IDP 속성을 기반으로 한 동적 규칙을 사용하여 사용자를 액세스 그룹에 할당할 경우, 서로 부분 문자열 관계에 있는 속성 값은 사용하지 마십시오. 예를 들어, 와 ml 를 속성 값으로 chemlab 사용하는 경우, 와 일치하는 규칙이 와도 일치하게 ml 되어 의도치 않게 예상보다 더 많은 접근 권한을 부여하게 됩니다 chemlab. 의도하지 않은 부분 문자열 일치를 chem-lab 방지하려면 및 ml 과 같은 고유한 값을 사용하거나 접두사나 접미사를 추가하십시오.
    • 리소스 그룹은 서비스 인스턴스를 명확하게 구분해야 할 때에만 사용됩니다. IBM Quantum Platform 에서 서비스 인스턴스를 생성할 때, 해당 인스턴스가 속할 리소스 그룹을 선택하고(태그를 추가할 수도 있음) 리소스 그룹을 생성하거나 관리하려면 IBM Cloud 콘솔을 사용해야 합니다. 리소스 그룹 내에서 더 많은 서비스 인스턴스가 생성되면, 해당 리소스 그룹에 대한 액세스 권한이 있는 모든 사용자는 액세스 그룹을 업데이트할 필요 없이 자동으로 해당 인스턴스를 확인할 수 있습니다. 리소스 그룹을 사용하기로 결정했다면, 먼저 액세스 그룹을 생성한 다음 이를 리소스 그룹에 할당하십시오.
    Note

    서비스 인스턴스는 하나의 리소스 그룹에만 속할 수 있으며, 인스턴스가 생성된 후에는 해당 할당을 변경할 수 없습니다. 따라서, 추후 서비스 인스턴스를 리소스 그룹 간에 이동해야 할 가능성이 있는 경우, 리소스 그룹만으로는 충분한 유연성을 제공하지 못할 수도 있습니다.


고려사항

환경을 설정할 때 다음 고려 사항을 이해해야 합니다.

더 세분화된 역할을 정의하십시오

사용자 정의 역할은 보다 세분화된 접근 제어를 위해 사용할 수 있습니다. 예를 들어, 일부 사용자는 서비스 인스턴스에서 작업을 수행하기 위해 전체 액세스 권한이 필요할 수 있는 반면, 다른 사용자는 서비스 인스턴스, 프로그램 및 워크로드에 대한 읽기 권한만 필요할 수도 있습니다.

이를 위해, MLreader 및 과 같은 두 가지 서로 다른 사용자 정의 역할을 정의하십시오 MLwriter. 사용자 정의 MLreader 역할에서 ‘취소’, ‘삭제’ 및 ‘업데이트’ 작업을 모두 제거하고, 모든 작업을 사용자 정의 MLwriter 역할에 포함시키십시오. 그런 다음 해당 역할을 두 개의 서로 다른 액세스 그룹에 각각 추가합니다.

Note

동적 규칙을 사용할 때, 즉 IDP 관리자가 사용자 정의 IDP 사용자 속성을 통해 액세스를 관리하는 경우, 서로의 부분 문자열인 IDP 사용자 정의 속성은 사용하지 마십시오. 예를 들어, ml 와 를 함께 사용하지 마십시오 mlReader. 의 문자열 비교에서는 도 허용되기 ml 때문입니다 mlReader. 이러한 충돌을 피하려면 MLwriterMLreader 를 사용할 수 있습니다.

예시는 ‘사용자 지정 역할 설정’을 참조하십시오.

공유 작업 부하 접근

액세스는 서비스 인스턴스에 적용됩니다. 따라서 인스턴스에 대한 쓰기 권한을 가진 사용자( IBM Quantum Platform 사용자 인터페이스를 통해 생성된 인스턴스에 대해 자동으로 생성되는 “Collaborators” 액세스 그룹을 통해 권한을 부여받은 사용자 포함)는 자신의 워크로드를 취소할 수 있을 뿐만 아니라, 해당 인스턴스 내의 다른 사용자의 워크로드를 조회하고 취소할 수도 있습니다. 이는 IAM의 작동 방식에 따른 것이며 변경할 수 없습니다.

계층적 구조 시뮬레이션

기본적으로 각 서비스 인스턴스의 액세스 권한은 독립적으로 관리되며, 예를 들어 IBM Quantum Platform 사용자 인터페이스를 통해 생성된 인스턴스의 경우 자동으로 생성되는 “Collaborators” 액세스 그룹을 통해 관리됩니다. IAM에는 그룹에 대한 기본 제공 계층 구조가 없지만, 여러 팀의 서비스 인스턴스를 참조하는 액세스 그룹을 생성하여 이를 대체할 수 있습니다. 광범위한 접근 권한이 필요한 사용자는 각 팀의 개별 접근 권한 그룹에 추가할 필요 없이, 하나의 “최상위” 그룹에만 추가하면 됩니다.

구성 설정의 일관되고 반복 가능한 배포

이 가이드에 설명된 단계를 자동화하면 사용자, 서비스 인스턴스 및 이들 간의 액세스 매핑을 일관되고 반복 가능한 방식으로 관리할 수 있습니다. 템플릿에 대해서는 Terraform IBM Cloud® Provider 문서를 참조하십시오.

Terraform을 사용하면 서비스 quantum-computing 인스턴스에 대한 할당 및 제한을 설정할 뿐만 아니라 백엔드 액세스를 제한할 수도 있습니다. 자세한 내용은 IBM Cloud 의 ‘Terraform 시작하기’를 참조하세요.

예:

resource "ibm_resource_instance" "instance1" {
  name       = "name"
  service    = "quantum-computing"
  plan       = "premium"
  location   = "us-east"
  parameters = {
    usage_allocation_seconds = "10" # Mandatory
    usage_limit_seconds      = "20" # Optional. If omitted, it can
            # continue using time after reaching the allocation
    backends                 = ["ibm_boston"] # Optional
  }
}

다음 단계

권장사항
이 페이지가 도움이 되었습니까?
GitHub에서 버그, 오타를 보고하거나 컨텐츠를 요청하십시오.