Simplify the complex ID system

[seokho-son]

(현황)

현재 기능적 중복이 있는 서브시스템이, 각자의 ID 관리 체계를 가지고 있음. (CB-Tumblebug, CB-Spider, CSP, ...)

• CB-SP

  • NameId: CB-SP의 리소스 오브젝트 아이덴티파이어 (CB-SP 입장에서), CSP의 리소스 명칭 (CSP 입장에서)
    • CB-TB가 CB-SP에 리소스 생성 요청시, Name을 지정하여 요청하면, 해당 Name을 활용하여 CB-SP에서 ID Transform을 수행함 (현재, 이를 disable 하는 옵션 제공 중)
    • CB-SP는 CB-TB가 관리하는 Namespace 체계가 없으므로, CB-TB가 Namespace를 주입하기 위해서, 부득이하게 리소스 생성 요청시 Name에 namespace를 프리픽스로 추가함 (이를 추가하지 않으면, CB-SP에서는 NS를 무시하게 되므로 이름공간 충돌이 발생할 수 있음)
    • NameId를 CSP 리소스 요청시 요청 name 값으로 활용함
  • SystemId: CSP의 리소스 ID (CSP 입장에서)
    • CSP가 자동으로 생성하거나, 요청 Name을 그대로 ID로 활용

• CSP

  • Identifier (휴먼리더블, 시스템생성 등 다양)

• CB-TB

  • Name: CB-TB의 오브젝트 명칭 (현재, ID 생성에 활용)
  • Id: CB-TB의 오브젝트 아이덴티파이어 (현재, 사용자가 요청한 Name과 동일)
  • Csp${resourceType}Id: CSP의 리소스 ID (CSP 입장에서)
  • Csp${resourceType}Name: CSP의 리소스 명칭 (CSP 입장에서), CB-SP의 리소스 오브젝트 아이덴티파이어 (CB-SP 입장에서)
    • CB-TB 사용자가 CB-SP의 리소스 오브젝트 아이덴티파이어를 직접 인지할 필요는 없음
    • CB-SP 호출시 내부적으로 활용하는 아이덴티파이어임

(이슈)

CB-TB 입장에서는 ID, NAME 등이 복잡하게 얽혀있고, 내부적으로 살펴보면, 하부 서브시스템 내부에서도 이름 공간 분리가 일어나고 있으며, ID의 형태 변경이 여러번 일어나고 있음. 또한 CSP의 기존 자원 등록시에도 CB-TB에서 복잡하고 처리하기 까다로운 부분이 발생함.

• 의견: 따라서, ID 관리 체계들을 정리하여, 시스템 내부 개념의 복잡성을 줄여줄 필요가 있음.
• 의견: 각 시스템의 ID 체계에서 가장 중요한 것은, ID가 아이덴티파이어로서의 역할을 수행할 수 있는가이며, 이 ID가 어떤 방식/형태로 구성되었는지는 크게 중요하지 않음(이름의 형태 든, UUID이든, XID이든). 앞으로, Annotation, Label 등 다양한 체계를 통해서, 해당 ID가 어떤 오브젝트인지는 인지시킬 필요.

(개선 방향)

• CB-TB는 CB-SP의 ID 변환 옵션을 사용하지 않는 것을 기본으로 함. https://github.com/cloud-barista/cb-spider/wiki/ID-Transformation-ON-OFF-Guide (CB-SP의 NameId가 변경되지 않음)
• CB-TB는 CB-SP에 리소스 생성 요청시, name을 임의 조정(ns-id-....) 하지 않고, 시스템 와이드 UID를 생성하여 요청
  • CB-SP 생성 요청시 NameId를, 모든 CSP에 문제가 생기지 않는 CSP 공통 최소 길이(20자), 특수문자 제외한 ID로 지정할 수 있도록 함
    • NameId 요청 값을 CB-TB의 예전 활용 방식인 XID로 자동 생성 (CB-TB 시스템 전체 차원에서 UID가 됨)
    • 참고: CSP는 리소스 생성시 지정 가능한 ID(또는 명칭)에 제약이 있으며, 이는 CSP 및 resource type 별로 상이함 (https://github.com/cloud-barista/cb-spider/blob/75c7183874e7b268adc46c22103faf9cd9f5d7a8/cloud-driver-libs/cloudos_meta.yaml#L19)
• CSP 기존 자원 등록시, NameId 요청 값을 CB-TB가 사용자 요청값(CSP특성에 따른 고정문구일 수도 있음)으로 직접 전달 (CB-SP는 이를 변형하지 않고, CSP에게 전달)

(개선 예상 결과)

CSP에게 리소스 생성 요청시, CB-TB가 생성한 CB-TB 내에서 시스템 와이드한 UID (XID형태)로 생성 요청하게 됨.

• CB-TB

  • Name: CB-TB의 오브젝트 명칭 (현재, ID 생성에 활용)
  • Id: CB-TB의 오브젝트 아이덴티파이어 (현재, 사용자가 요청한 Name과 동일)
  • Csp${resourceType}Name: CB-TB가 요청시 활용한 값 (XID형태-20자, 또는 CSP기존자원 등록시 사용자가 원하는 값, 특수값 등) == CB-SP.NameId
  • Csp${resourceType}Id: CSP가 자체 내부 생성하는 CSP_ID (Csp${resourceType}Name와 동일할 수도 있음) == CB-SP.SystemId

• CB-SP (CB-TB 사용자가 체계를 직접 알 필요는 없음)

  • NameId: CB-TB가 요청시 활용한 값 == CB-TB.Csp${resourceType}Name
  • SystemId: CSP가 자체 내부 생성하는 CSP_ID == CB-TB.Csp${resourceType}Id

(참고)

• XID 생성시, 중복 여부를 확인하지 않고자 함 (1경 개 ID 생성시, 중복 확률 계산)

  - **총 고유 ID 공간**: \( N = 2^{96} \) ≈ \( 7.9 \times 10^{28} \)
  - **이미 생성된 ID 수**: \( k = 10^{16} \)
  
  중복 확률 \( P \)는 생일 문제(Birthday Problem) 접근법을 사용하여 다음과 같이 근사할 수 있습니다:
  
  \[P \approx 1 - e^{-\frac{k^2}{2N}}\]
  
  계산을 적용하면:
  
  \[P \approx 1 - e^{-\frac{(10^{16})^2}{2 \times 7.9 \times 10^{28}}}\]
  
  \[P \approx 1 - e^{-\frac{10^{32}}{1.58 \times 10^{29}}}\]
  
  \[P \approx 1 - e^{-632.91}\]
  
  결과적으로:
  
  - \( e^{-632.91} \)는 매우 작은 값으로, \( P \approx 1 - 0 \), 즉 **충돌 확률이 매우 작다**고 할 수 있습니다.
  
  1경 개의 XID를 이미 생성한 상황에서 추가로 1개의 XID를 생성할 때 중복될 확률은 사실상 0에 가깝습니다. 이를 무시해도 좋을 만큼 작은 값입니다.
  

[seokho-son]

참고: 향후에는 CB-TB 리소스 오브젝트의 ID 까지 시스템 생성 UID로 변경하여, 내부를 모두 일치 시킬 수도 있음.
(적용하는 경우, 사용자가 리소스 제어를 위해서, 항상 ID를 조회한 후에만 처리가 가능하게 될 수도 있음)

[seokho-son]

참고: 현재 XID를 생성하는 GenUid() 함수는 변형없이 그대로 사용하고자 함.

기존에는 CB-SP 및 CSP까지 CB-TB의 NS 개념을 내려보내기 위해서, NS 프리픽스를 첨부하는 작업을 하였으나, 이 작업에 의해서 결국 ID의 형태가 길어지고, CSP가 길어진 ID를 거절할 가능성이 생김.

XID를 그대로 활용하더라도, 중복 ID가 생성될 확률이 0에 가까우므로,
NS를 굳이 나누지 않고, 시스템 전체에서도 UID가 되도록 함.

단점은, CSP 콘솔에서, NS 명칭으로 추정이 어렵다는 부분이 있으나, 이는 label, annotation 등을 통해서 해결해나가는 것으로 방향을 잡고자 함.

[seokho-son]

참고: CSP 중에서 특정 리소스 생성시, 만약 id의 길이를 20자 보다 더 작게 요구하면, XID 수정이 필요하게 됨. (XID 기본이 20자, 현재 CSP 최소 ID 길이: NCP의 K8s ID가 20자)