품질 속성에 대한 생각

[binchoo]

ISO-25010 소프트웨어 품질 모델 표준
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

ISO-25010처럼 소프트웨어의 표준 품질 속성의 리스트가 있다는 걸 아는 이들이 많지 않습니다.
(저는 품질 시나리오를 보고 이게 어느 품질 속성에 들어가는 거지? 아리까리 할 때 참조하곤 합니다.)

사실 사람들은 이런 리스트를 그저 아카데믹한 나열로만 여깁니다. 아무 비즈니스 컨텍스트가 없는 상태에서, 품질 속성이 비즈니스 가치로 연결된다는 사실을 직관적으로 깨닫기는 어렵기도 하구요.

아키텍처 스타일과 태틱에 대한 내 생각

최근 민덕기 교수님이 참고용 책들과 강의 노트를 주셔서 3학년 때 들었던 시스템 설계 과목을 복기해 볼 수 있는 기회가 있었습니다.

아키텍쳐를 결정하는 크리티컬한 동인은 품질 요구사항입니다. 품질이 깨지면 기능 역시 깨지기 때문에, 품질 시나리오가 시스템 설계의 가장 높은 우선순위에 놓입니다.

그 외에도 '주기능 요구사항', '설계 목적', '아키텍처 스타일과 태틱, '레퍼런스 아키텍처', '기술 부채', '피드백 루프', '제약' 등이 아키텍처 관심사(Architectural Concerns)가 됩니다.

아키텍처 패턴과 태틱을 배우는 이유는, 그들이 무수한 시스템 사례 속에서 품질 속성을 해결해 줄, 우수하고 신빙성 있는 해법으로 인정받았기 때문입니다. 그들은 품질 속성 연구 집단의 경험과 연구에서 탄생했고 AWS의 Well-Architected 프레임워크에 잘 정돈되어 있기도 합니다.

초기 단계에서 식별되는 많은 요구사항들은, 설계가 고도화되면서 추상화 된 묶음으로 다뤄집니다.
이러한 요구사항 묶음을 해결하고자, 잘 들어맞는 아키텍처 스타일과 아키텍처 태틱이 선택됩니다.

그러므로 어떤 SW 솔루션을 이해해야 할 때 가장 먼저 봐야할 건, 그것의 기능의 리스트가 아니며, 그들을 위해 선택된 아키텍처 스타일과 태틱이어야 한다고 생각합니다.

새로운 기술 이해에 도움

이미 알고 있는 것에 비유하여 새로운 내용을 이해하는 것은 정말 유용하다고 생각합니다. 태틱이 이런 역할을 하더라구요.
설령 아주 신박한 솔루션으로 보일지라도, 까고 보면 삐까뻔쩍한 언어로 한 번 감싸 놨구나 깨닫게 됩니다.

• 서비스 메시 - Istiod라는 쿠버네티스에서 서비스 메시를 구성할 때 이용되는 오픈소스는 Data Plane과 Control Plane을 갖습니다. 데이터 플레인은 횡단 관심사 해결을 위해 붙이는 Envoy라는 프락시 집단을 일컫습니다. 다만 사이드카 컨테이너를 추가적인 태틱으로 쓰는 것이죠.
• 컨트롤 플레인에 들어있는 컴포넌트인 갤리, 파일럿, 시타델 이런 단어가 정말 무섭습니다⋯. 그들은 설정 주입을 태틱으로 하여 라우팅과 서비스 디스커버리, In-Flight 암호화의 설정을 지원하죠.
• 스프링 AOP에서 횡단 관심사를 해소하기 위해 기용한 AspectJ의 전술도, CGLIB 또는 JDK로 프락시 구현체를 만드는 겁니다.
• CDN이나 NGINX도 백워드 프락시를 전술로 하여 보안을 지원하고, 캐싱이라는 전술로 성능과 확장성을 지원합니다.

기술 간 비교에 도움

"Prometheus vs. Amazon CloudWatch의 차이점이 뭔가요?" 이 질문에 대답하려면 다들 어떻게 하시나요?

두 솔루션의 기능을 나열하고, 교집합과 차집합을 찾아내는 것으로 비교하고 계신가요?

저는 두 솔루션이 기반하는 태틱의 교집합과 차집합을 들여다 봐야 한다고 생각합니다.

가령 주어진 질문에 대해서

Prometheus는 메트릭 수집을 위해 Polling을 태틱으로 쓴다. 메트릭을 제공하는 엔드포인트를 프로메테우스 측에서 폴하는 것으로 한꺼번에 많은 종류의 메트릭을 획득할 수 있다. 따라서 네트워크의 홍수를 완화할 수 있다. 하지만 짧은 배치 프로세스가 있다면 프로메테우스가 폴을 놓칠 확률이 높아진다. 그래서 "푸시 게이트웨이"라는 것이 마련되어 있다.

CloudWatch는 메트릭 수집을 위해 Push을 태틱으로 쓴다. CloudWatch 에이전트 혹은 SDK에서 CloudWatch 측의 PutMetric API를 사용해서 메트릭을 전달한다. 따라서 Prometheus의 장단점과 반전이 된다. 한 편, CloudWatch는 완전 관리형 서비스이다. 가용성 및 확장성에 대해서 우리가 신경쓰지 않는다. 또 AWS 상의 수 많은 서비스들과 매끄럽게 통합된다.

라고, 그들의 태틱 차이로 인해 발생한 품질 시나리오의 차이를 얘기할 것입니다.

또 둘의 교집합이 단일 통합 저장소라는 점을 깨달을 것이며

아하⋯ 시스템의 가시성을 위해 하나의 저장소를 두는 것은 무척 중요하구나; 직접 이런 시스템을 구현하게 된다면 나도 이 전략을 고려해야겠다⋯. 생각하게 됩니다.

설계 관련해서 이러한 생각들이 정리가 되어서 끄적여 봤습니다.