상명대학교 / 서광규 교수
2. 클라우드 네이티브 품질 모델
여기에서는 품질 모델의 현재 상태를 제시한다. 따라서 다양한 유형의 요소를 설명한 다음 모델의 모범적 요소를 더 자세히 기술한다. 예를 사용하여 공식화 및 검증 단계가 현재 상태로 이어지는 방식도 기술한다.
2-1. 품질 모델의 요소
클라우드 기반 애플리케이션의 소프트웨어 아키텍처에 대한 품질 모델은 Quamoco 메타 모델을 기반으로 하며, 현재 상태에서는 품질 측면, 제품 요인, 영향, 엔티티 및 부분적 측정이 정의된다.
즉, 제품 요인을 측정 가능하게 만드는 측정 제공을 완료하고 의미 있는 분석을 가능하게 하는 평가의 정의는 소프트웨어 아키텍처의 정량적 평가에 여전히 필요하다. 반면, 품질 모델의 제품 요인에 대한 소프트웨어 아키텍처의 수동 평가에 기반한 정성적 평가는 이미 가능할 것이다.
따라서 여기에서는 현재 형태의 품질 모델을 제시하고 품질 모델의 다양한 제품 요인에 특히 초점을 맞추어 기술한다. 이러한 요인을 이해하는 방법, 공식화에 사용된 근거 및 잠재적 평가에서 이러한 요인을 사용하는 방법을 기술한다.
시각적 형태의 품질 모델은 그림 2에 나와 있다. 여기에는 흰색 상자에 제품 요인과 회색 상자에 품질 측면이 포함된다. 연결 화살표는 긍정적 영향을 나타내는 영향 관계와 부정적 영향을 나타내는 영향 관계를 나타낸다. 품질 모델의 초점은 애플리케이션의 설계 시간에 있다는 점을 명시하는 것이 중요하다.
따라서 포함된 제품 요소는 애플리케이션의 아키텍처 표현을 기반으로 설계 시 평가 가능하도록 의도되었다. 배포 프로세스의 특성과 같은 추가 측면도 클라우드 네이티브 주제 내에서 중요하지만 이 품질 모델의 범위를 벗어난다.
[그림2. 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처를 위한 품질 모델]
그러나 애플리케이션의 적절한 아키텍처 표현이 무엇인지에 대한 결정을 내려야 한다. 일반적으로 품질 모델을 소스 코드와 배포 설명에 직접 적용하는 것이 상상할 수 있지만, 다양한 기술을 지원해야 하므로 구현이 점점 더 복잡해진다.
따라서 소프트웨어 아키텍처 모델에 의존하기로 결정하고 이러한 모델의 잠재적 엔터티를 공식화하는 것이 필요하다. 또한 기존 접근 방식 적용을 위해 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처에 대해 현재 사용 가능한 모델링 옵션을 검토도 필요한데 그 결과가 그림 3에 표시된 엔티티이다.
[그림3. 클라우드 기반 애플리케이션의 아키텍처 설명을 위해 제안된 엔티티]
이러한 엔티티와 이를 더 자세히 기술하는 추가 속성을 통해 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처를 모델링하여 이러한 아키텍처를 평가할 수 있다. 각 유형의 엔티티에 추가된 특정 속성의 공식화는 제품 요인과 관련된 해당 측정에 크게 의존한다. 이러한 속성은 구성 요소 구조와 함께 측정을 위한 데이터 기반을 제공한다. 따라서 속성의 정의는 사용된 측정에 따라 필요에 따라 조정할 수 있어 보다 유연성을 갖는다.
2-2. 대표적인 제품 요소
2.1절의 요소에 대한 일반적인 설명을 바탕으로 세 가지 모범적인 요인을 더 자세히 기술한다. 이러한 요인은 그림 2에서도 강조하여 표시되었다. 구체적으로 이러한 요인이 어떻게 공식화되고 검증되었는지, 그리고 필요한 엔티티와 측정값을 고려하여 클라우드 네이티브 아키텍처를 기반으로 어떻게 평가할 수 있는지 설명한다.
(1) 자동화된 인프라 프로비저닝
이 제품 요인은 "인프라 프로비저닝은 배포되어야 하는 구성 요소에서 명시적으로 명시되거나 추론된 구성 요소 요구 사항을 기반으로 자동화되어야 한다. 사용되는 인프라와 도구는 최소한의 수동 작업만 필요하다. 이상적으로는 구성 요소 배포에 추가 상호 작용이 필요하지 않도록 지속적인 제공 프로세스와 결합되어야 한다."로 설명되며 수정 가능성과 설치 가능성 모두에 긍정적인 영향을 미치는 것으로 간주된다.
초기 공식화는 "개발자가 커밋한 변경 사항과 프로덕션에 대한 제공 사이에 필요한 모든 수동 작업은 제공 속도를 크게 낮출 것이다”라고 쓰고 필요한 인프라의 자동화된 제공을 통해 수정이 간소화되고 더 빠르게 수행할 수 있다고 주장한다. 원래 공식화된 품질 모델에서 이 측면은 자동화된 인프라라는 제품 요인에 포함되지만, 검증 설문 조사의 결과는 다양한 품질 측면에 대한 여러 영향이 보고되었기 때문에 이 요인에 대한 모호성을 보여준다.
따라서 요인을 세분화하여 해당 품질 측면에 영향을 미치는 자동화된 인프라 프로비저닝과 자동화된 인프라 유지 관리라는 두 가지 별도 요인으로 분할이 가능하다. 일반적으로 자동화된 인프라 프로비저닝의 수정 가능성에 대한 긍정적 영향을 유지하는데 그 이유는 설문 조사 결과를 품질 모델을 세분화하는 기준으로 사용했기 때문이지 확실한 결과로 사용하지 않았기 때문이다.
제품 요인 자동화된 인프라 프로비저닝을 평가하려면 인프라 엔터티를 고려해야 하며 수동 작업이 거의 또는 전혀 없이 자동으로 프로비저닝할 수 있는지 평가해야 한다.
예를 들어 인프라가 클라우드 공급자에 의해 관리되고 구성 요소에서 필요할 때 프로비저닝할 수 있는 경우가 될 수 있다. 또 다른 사례는 인프라 코드 사용이라는 추가 제품 요인이 있는 Infrastructure as Code (IaC) 접근 방식을 사용하는 것이다.
따라서 적절한 측정 기준은 예를 들어 기본 지표로 자동으로 프로비저닝될 수 있는 인프라 엔터티의 비율이 될 수 있다.
[표1. 품질 요인 사례]
(2) 자율적 오류 처리
이 요인은 "클라우드 기반 애플리케이션 서비스는 다양한 수준에서 오류를 예상하고 클라우드 환경의 기능에 의존하여 오류를 처리하거나 영향을 최소화해야 한다.”로 설명된다. 호출 시간 초과, 안전한 호출을 위한 재시도 및 회로 차단 통신이라는 제품 요인에 대한 중재 요인이다.
회로 차단 통신은 문헌에서 정기적으로 언급되었으며 비일시적 오류에 회로 차단기 사용, "구성 요소가 실패할 가능성이 높고 일시적이지 않은 작업을 수행하지 못하도록 방지하는 데 사용할 수 있다.”따라서 영향을 받는 구성 요소가 다시 정상화될 때까지 대체 작업을 사용할 수 있다. 호출 시간 초과 및 안전한 호출을 위한 재시도도 기존 연구에 근거한다.
그러나 검증 설문 조사에서는 안전한 호출을 위한 재시 도와 회로 차단 통신만 고려할 수 있는데 호출 시간 초과가 클라우드 네이티브 애플리케이션에 덜 구체적이라고 가정이 가능하기 때문이다. 두 가지 모두 장애 허용에 대한 긍정적인 영향을 확인할 수 있었지만 응답 수가 적어 결과를 잠재적으로 유효한 것으로 표시할 수 있다.
이러한 제품 요소를 평가하려면 링크 엔터티를 분석하여 이러한 메커니즘이 사용되는지 확인해야 하며, 제품 요소인 안전한 호출을 위한 재시도의 경우 링크 가 연결된 엔드 포인트를 분석하여 여러 번 호출하는 것이 안전한지 확인해야 한다. 재시도 논리를 사용한 링크 수나 복잡한 장애 조치를 사용한 링크 수와 같은 적절한 측정 방법이 이미 선행연구에서 제안되었다.
(3) 일관된 중앙 집중형 로깅
이 요인은 "로깅 기능은 시스템 구성 요소의 로그를 결합하고 저장하는 중앙 집중형 구성 요소에 집중되어야 한다. 또한 로그는 상관 관계와 로그 분석이 용이하도록 형식과 세분성 수준에서 일관성이 있어야 한다.”로 설명된다. 이 요인은 문헌을 기반으로 공식화되었으며 로그가 중앙 구성 요소에 저장되어야 한다는 것, 로그가 일관된 형식으로 수집되어야 한다는 것, 로그 집계 및 분석 기능이 제공되어야 한다는 것과 같은 측면을 다룬다.
이 요소를 평가하기 위해서는 백업 서비스가 관련성이 있는데, 잠재적인 로깅 서비스가 그에 따라 모델링되고, 예를 들어 특정 엔드포인트에 로그를 보내는 것과 같이 어떤 구성 요소가 이 백업 서비스에 로그를 제공하는지 확인할 수 있기 때문으로 적절한 척도로 중앙 서비스로 로그를 내보내는 구성 요소 또는 인프라 노드의 비율을 사용할 수 있다.
2-3. 조치를 통한 지원
측정을 통한 제품 요인 지원은 소프트웨어 아키텍처의 정량적 평가를 가능하게 하는 핵심 측면이다. 품질 모델의 제품 요인에 대한 측정 지원과 관련하여 해결해야 할 두 가지 측면이 있다. 한편으로는 아직 기존 선행연구에 적합한 측정이 제안되지 않았거나 몇 가지만 제안된 제품 요인이 있다. 이러한 제품 요인에 대해서는 새로운 측정을 제안하고 검증할 필요가 있다. 다른 한편으로는 측정하는 내용 측면에서 부분적으로 매우 유사한 수많은 측정이 제안된 제품 요인이 있다. 이러한 제품 요인에 대해서는 제품 요인을 적절하고 이해하기 쉬운 방식으로 반영하는 의미 있는 측정을 선택해야 한다. 다음 단계로 추가 측정을 구조화된 방식으로 공식화하고 검증해야 한다.
3. 시사점
품질 모델에 대한 작업 중에 나타난 흥미로운 측면은 제품 요인과 설계 패턴이 어떻게 관련되어 있는가 하는 것이다. 많은 실무자 서적은 클라우드 네이티브를 달성하기 위한 패턴을 제시하고 과학 문헌에서도 아키텍처의 품질 평가는 종종 패턴을 기반으로 한다. 제품 요인과 패턴은 매우 상호 관련되어 있으며 어떤 경우에는 제품 요인이 패턴에 직접 매핑된다. 그러나 이상적으로는 패턴이 아키텍처 내의 특정 엔티티 형성과 해당 속성에 반영된다. 아키텍처를 평가할 때 특정 패턴이 사용되었다는 사실은 관련 제품 요인을 측정하는 해당 아키텍처 측정을 통해 측정할 수 있어야 한다. 따라서 이 제품 요인이 영향을 미치는 품질 측면은 원래 패턴이 목표로 삼은 품질 측면과 동일해야 하며, 본질적으로 특정 패턴을 사용하면 특정 품질 측면에 영향을 미치는 것과 동일한 결과가 나와야 한다.
또 다른 흥미로운 측면은 품질 모델에서 대부분의 영향 관계가 품질 측면에 대한 긍정적 영향을 설명한다는 것이다. 이는 품질 모델의 초기 공식화를 위해 클라우드 네이티브 애플리케이션을 구현하는 방법에 대한 실무자용 서적을 고려한 우리의 선택 방법론에 크게 기인한다. 일반적으로 품질 측면 간에 상충 관계가 있기 때문에 결국 이는 품질 모델에서도 볼 수 있어야 한다. 따라서 특히 사용 사례를 고려한 품질 모델에 대한 추가 작업은 애플리케이션 특성의 잠재적 부정적 영향에도 초점을 맞춰야 한다.
그림 2에 표시된 품질 모델이 클라우드 네이티브 애플리케이션의 특성이 여러 품질 측면에 미치는 영향을 적절하게 설명한다. Quamoco 메타 모델에 의존하기 때문에 품질 모델은 건전한 이론적 토대 위에 공식화된다. 이 모델은 소프트웨어 아키텍처의 품질 평가를 가능하게 하기 위해 추가로 개발될 수 있는 기반을 제공한다. 품질 모델을 공식화하는 데 사용한 방법론은 한편으로는 이 특정 사례에서 모델이 어떻게 개발되었는지 보여줄 수 있다. 그러나 다른 한편으로는 품질 모델을 개발할 때 보다 일반적으로 고려해야 할 사항과 사용할 수 있는 접근 방식을 보여준다. 따라서 방법론의 프레젠테이션과 입증된 적용은 품질 모델을 어떻게 공식화하고 검증할 수 있는지가 중요한데 이것이 품질 모델을 공식화하고 검증하는 여러 가지 방법 중 하나이며 반복적인 방식으로도 다양한 접근 방식을 취할 수 있기 때문이다. 사실, 품질 모델이 다양한 관점과 다양한 유형의 근거에 따라 검증될수록 해당 모델의 적용 가능성에 대한 확신도가 높아진다.
따라서 향후 고려하여야 할 주요 측면은 품질 모델에 대한 추가적인 검증 접근 방식인데 예를 들면 실험적 접근 방식을 사용이다. 이를 용이하게 하기 위해 해당 도구 지원이 중요하다. 특히, 도구 지원은 그림 3에 표시된 엔터티를 사용하여 소프트웨어 아키텍처의 직관적 모델링, 모델링된 아키텍처를 기반으로 한 측정값의 사양 및 자동화된 계산을 지원하여 품질 모델 평가에 사용할 수 있도록 해야 한다. 모델링 기능에 초점을 맞춘 프로토타입이 제시되었으며 도구 지원의 추가 구현을 위한 기반이다. 이와 관련하여 논의할 한 가지 측면은 아키텍처 모델이 어떻게 생성되는가이다. 일반적으로 소프트웨어에 대한 이해를 기반으로 소프트웨어 아키텍처를 수동으로 모델링하거나 소스 코드나 배포 설명자와 같은 아티팩트를 기반으로 모델을 자동으로 생성할 수 있다. 모델을 자동으로 생성할 수 있다면 도구 사용을 상당히 용이하게 할 수 있지만 문제는 도구를 차례로 적용해야 하는 클라우드 네이티브 애플리케이션 컨텍스트에서 사용 가능한 기술의 이질성이다. Infrastructure as Code (IaC) 아티팩트에서 모델을 자동으로 생성하는 이러한 접근 방식을 취했지만 하나의 특정 기술로 시작하여 지속적으로 추가 기술을 포함해야 한다. 품질 모델에서 아키텍처 특성과 품질 측면 간의 관계에 초점을 맞출 경우에는 소프트웨어 아키텍처의 수동 모델링만 제공하는 것이 일반적이다. 따라서 도구 지원에 대해서는 수동 모델링을 가능한 한 직관적으로 만드는 것이다. 또한 모델링 접근 방식을 표준으로 TOSCA를 기반으로 하는데 이는 어댑터가 사용 가능한 경우 다양한 기술의 배포 설명자를 TOSCA 템플릿으로 변환하기 위한 기반을 제공하므로 툴링의 호환성이 향상되기 때문이다.
4. 결론
클라우드 컴퓨팅에 대한 관심은 꾸준히 증가하고 있으며, 지속적인 기술 혁신으로 인해 제공 범위가 진화하고 있다. 따라서 클라우드 네이티브는 현대 클라우드 컴퓨팅 개념의 이점을 최대한 활용하는 방식으로 애플리케이션을 구축하는 용어로 자리 잡았다. 그러나 클라우드 네이티브라는 주제는 광범위하고 클라우드 컴퓨팅 기술의 다양성이 크다. 따라서 클라우드 네이티브 개념의 이점을 활용하고자 하는 개발자와 소프트웨어 아키텍트를 지원할 필요성이 있다. 클라우드 네이티브가 최근 주목할 만한 주제가 되면서, 클라우드 네이티브 개념과 기술로부터 애플리케이션이 어떻게 이익을 얻을 수 있는지 평가할 수 있는 것은 소프트웨어 개발자와 아키텍트에게 유리한 역량이다. 그러나 범위가 넓고 기술적 이질성이 있기 때문에 이를 평가하는 것이 쉬운 작업은 아니다. 본 고에서는 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처에 대한 품질 모델을 통해 이 과제를 해결하기 위한 접근 방식을 기술하였다.
아키텍처 특성이 다양한 품질 측면에 어떤 영향을 미치는지 설명하는 클라우드 네이티브 소프트웨어 아키텍처에 대한 품질 모델의 형태로 이 지원을 제공한다. 설계 시간에 초점을 맞추고 있으며, 클라우드 네이티브 특성과 해당 품질 측면에 따라 애플리케이션의 아키텍처 모델을 평가할 수 있다. 이론적 관점에서 품질 모델은 클라우드 네이티브 특성이 다양한 품질 측면에 어떤 영향을 미치는지에 대한 체계적인 이해하는 것이 필요한데 이는 소프트웨어 아키텍처의 정성적 평가에 품질 모델을 사용할 수 있는 가능성과 일치한다. 그러나 정량적 평가 및 보다 실용적인 관점에서는 품질 모델을 더욱 개선해야 하다.
본 고에서는 클라우드 네이티브 소프트웨어 아키텍처에 대한 품질 모델을 공식화하고 검증하기 위한 접근 방식과 현재 상태를 기술하였는데 개념적 및 방법론적 고려 사항의 더 큰 맥락에서 접근 방식을 통합적으로 기술하였다. 본 고에서는 클라우드 네이티브 소프트웨어 아키텍처와 관련된 특성에 대한 질적 개요를 제공하고, 애플리케이션의 건축적 모델을 기반으로 품질 평가의 기초를 제공하였다는 측면에서 의의를 갖는다.
참 고 문 헌
- Lichtenth?ler, R., Fritzsch, J., Wirtz, G.: Cloud-native architectural characteristics and their impacts on software quality: a validation survey. In: 2023 IEEE International Conference on Service-Oriented System Engineering (SOSE). IEEE Computer Society, Los Alamitos, CA, USA (2023).
- Lichtenth?ler, R., Wirtz, G.: Towards a quality model for cloudnative applications. In: Service-Oriented and Cloud Computing, pp. 109?117. Springer, New York (2022).
- Apel, S., Hertrampf, F., Sp?the, S.: Towards a metrics-based software quality rating for a microservice architecture. In: 19th I4CS, pp. 205?220. Springer, New York (2019).
- Wagner, S. et al.: The quamoco quality meta-model. Tech. Rep. TUM-I128, TU M?nchen, Institut f?r Informatik (2012).
- ISO/IEC: ISO/IEC 25000 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) (2014).
- Zdun, U., et al.: Microservice security metrics for secure communication, identity management, and observability. ACM Trans. Softw. Eng. Methodol. (2023).
- Lichtenth?ler, R., Wirtz, G.: Formulating a quality model for cloud-native software architectures: conceptual and methodological considerations, Cluster Computing, Volume 27, pages 4077?4093, (2024)
저작권 정책
K-ICT 클라우드혁신센터의 저작물인 『클라우드 기반 소프트웨어 아키텍처를 위한 품질 모델』은 K-ICT 클라우드혁신센터에서 상명대학교 서광규 교수에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.