비용: 비용을 품질로 보는 시각은 주류가 아니지만, 클라우드의 등장으로 점점 많이 언급되는 것 같습니다.
품질 속성에 대한 나의 고찰
아키텍쳐 패턴을 결정하는 것은 소프트웨어 품질 요구사항입니다. 품질이 깨지면 기능 역시 깨지기 때문에, 품질 속성은 시스템 설계의 가장 높은 우선순위에 놓입니다.
ISO-25010 처럼 표준 품질 속성의 리스트가 있다는 걸 아는 이들이 많지 않습니다. 사실 사람들은 이러한 품질 속성 리스트를 그저 아카데믹한 나열로 여깁니다. 아무런 비즈니스 컨텍스트가 없는 상태에서, 품질 속성이 비즈니스 가치로 연결된다는 사실을 직관적으로 깨닫기는 어렵기 때문입니다.
그러나 아키텍처 패턴과 태틱을 배우는 이유는, 그들이 무수한 시스템 사례 속에서 품질 속성을 해결해주는, 우수하고 신빙성 있는 해법으로 인정받았기 때문입니다. 그들은 AWS의 Well-Architected 프레임워크나 많은 품질 속성 연구 집단의 경험과 연구에서 탄생했습니다.
SW의 설계 초기 식별된 수많은 요구사항들은, 설계가 고도화되면서 추상화 된 묶음으로 다뤄지고, 이러한 요구사항 묶음을 해결하기 위해서 가장 들어맞는 아키텍처 스타일과 아키텍처 태틱이 선택됩니다.
따라서, 어떤 SW 솔루션을 이해해야 할 때 가장 먼저 봐야할 것은, 그것의 기능의 리스트가 아니고 그들이 선택한 스타일과 태틱이어야 합니다.
Prometheus vs. AWS CloudWatch의 차이점이 뭔가요? 라는 질문에 대답하려면 다들 어떻게 하시나요?
두 솔루션의 기능을 나열하고, 교집합과 차집합을 찾아내는 것으로 비교하고 계신가요?
저는 이 방법이 좋지 않다고 생각합니다. 오히려 두 솔루션이 기반하는 태틱이 무엇이고 그것의 교집합과 차집합을 들여다 보아야 합니다. 가령 주어진 질문에 대해서
Prometheus는 메트릭 수집을 위해 "Poll"을 태틱으로 쓴다. 메트릭을 제공하는 엔드포인트를 프로메테우스 측에서 폴하는 것으로 한 꺼번에 많은 종류의 메트릭을 획득할 수 있다. 따라서 네트워크의 홍수를 완화할 수 있다. 하지만 짧은 배치 프로세스가 있다면 프로메테우스가 폴을 놓칠 확률이 높아진다. 그래서 "푸시 게이트웨이"라는 것이 마련되어 있다.
CloudWatch는 메트릭 수집을 위해 "Put"을 태틱으로 쓴다. 따라서 Prometheus의 장단점과 반전이 된다. 한 편, CloudWatch는 "클라우드 서비스"이다. 따라서 AWS 상의 수 많은 서비스들과 매끄럽게 통합된다.
라고, 그들의 선택 차이로 인해 발생한 품질 요구사항의 커버리지 차이를 얘기할 것입니다.
그리고 둘의 공통 태틱은 "메트릭&로그의 단일 통합 저장소"라는 점을 깨닫고, 아하 시스템의 가시성을 위해 하나의 저장소를 두는 것은 무척 중요하구나, 직접 이런 시스템을 구현하게 된다면 나도 이 전략을 택해야 겠군⋯ 생각하게 됩니다.
실제 구현에는 AWS 서비스를 사용하게 될 듯
내가 직접 품질 요구사항을 만족하는 아키텍처를 배치해 본다고 생각하면, 머리가 많이 아플텐데요.
요즘 AWS 서비스들을 알아보면서 아마존 AWS가 이미 아키텍트들의 고민을 모두 섭렵해 서비스화 해 놓았다고 느꼈습니다.
그리고 2가지 AWS 서비스 가이드를 첨부합니다. AWS 서비스를 적용하는 예시들을 아는 데 적당하다고 생각했습니다.
마치며
이 책 덕분에 유명한 실 서비스들에 적용된, 전형적인 아키텍처를 살펴 볼 수 있었습니다.
품질 속성에 대한 나의 고찰
아키텍쳐 패턴을 결정하는 것은 소프트웨어 품질 요구사항입니다. 품질이 깨지면 기능 역시 깨지기 때문에, 품질 속성은 시스템 설계의 가장 높은 우선순위에 놓입니다.
ISO-25010 처럼 표준 품질 속성의 리스트가 있다는 걸 아는 이들이 많지 않습니다. 사실 사람들은 이러한 품질 속성 리스트를 그저 아카데믹한 나열로 여깁니다. 아무런 비즈니스 컨텍스트가 없는 상태에서, 품질 속성이 비즈니스 가치로 연결된다는 사실을 직관적으로 깨닫기는 어렵기 때문입니다.
그러나 아키텍처 패턴과 태틱을 배우는 이유는, 그들이 무수한 시스템 사례 속에서 품질 속성을 해결해주는, 우수하고 신빙성 있는 해법으로 인정받았기 때문입니다. 그들은 AWS의 Well-Architected 프레임워크나 많은 품질 속성 연구 집단의 경험과 연구에서 탄생했습니다.
SW의 설계 초기 식별된 수많은 요구사항들은, 설계가 고도화되면서 추상화 된 묶음으로 다뤄지고, 이러한 요구사항 묶음을 해결하기 위해서 가장 들어맞는 아키텍처 스타일과 아키텍처 태틱이 선택됩니다.
따라서, 어떤 SW 솔루션을 이해해야 할 때 가장 먼저 봐야할 것은, 그것의 기능의 리스트가 아니고 그들이 선택한 스타일과 태틱이어야 합니다.
Prometheus vs. AWS CloudWatch의 차이점이 뭔가요? 라는 질문에 대답하려면 다들 어떻게 하시나요? 두 솔루션의 기능을 나열하고, 교집합과 차집합을 찾아내는 것으로 비교하고 계신가요?
저는 이 방법이 좋지 않다고 생각합니다. 오히려 두 솔루션이 기반하는 태틱이 무엇이고 그것의 교집합과 차집합을 들여다 보아야 합니다. 가령 주어진 질문에 대해서
라고, 그들의 선택 차이로 인해 발생한 품질 요구사항의 커버리지 차이를 얘기할 것입니다. 그리고 둘의 공통 태틱은 "메트릭&로그의 단일 통합 저장소"라는 점을 깨닫고, 아하 시스템의 가시성을 위해 하나의 저장소를 두는 것은 무척 중요하구나, 직접 이런 시스템을 구현하게 된다면 나도 이 전략을 택해야 겠군⋯ 생각하게 됩니다.
실제 구현에는 AWS 서비스를 사용하게 될 듯
내가 직접 품질 요구사항을 만족하는 아키텍처를 배치해 본다고 생각하면, 머리가 많이 아플텐데요. 요즘 AWS 서비스들을 알아보면서 아마존 AWS가 이미 아키텍트들의 고민을 모두 섭렵해 서비스화 해 놓았다고 느꼈습니다.
그리고 2가지 AWS 서비스 가이드를 첨부합니다. AWS 서비스를 적용하는 예시들을 아는 데 적당하다고 생각했습니다.
고가용성을 위한 멀티 리젼 액티브-액티브 아키텍쳐 Architecture patterns for multi-region active-active (pdf)
서버리스 어플리케이션 모델 SAM serverless using aws lamdba for java developers.pdf