[도서후기] 소프트웨어 아키텍처 101

도서의 표지

이 책은 제1부에서는 소프트웨어 아키텍처의 기초 제2부에서는 다양한 아키텍처 스타일, 제3부에서는 개발자, 기타 이해 관계자와의 협력에 필요한 다양한 방법과 소프트웨어 기술에 관한 내용을 담고 있습니다.소프트웨어 아키텍처의 진화한 부분을 보면 익스트림 프로그래밍의 엔지니어링 사례에서 지속 전달(CD), 뚱보 오푸스의 혁신, 마이크로 서비스 컨테이너화, 그리고 클라우드에 근거한 자원에 이르기까지 모든 지속적인 혁신을 새로운 기능과 트레이드 오프를 만들어 냈습니다.능력이 변화되면서 업계를 바라보며 아키텍트의 시선도 달라졌어요.새로운 시대에는 그것에 걸맞도록 새로운 사례, 툴, 측정 패턴 등 많은 변화가 필요합니다.소프트웨어 아키텍트는 전문가로 간주되는 소프트웨어 개발자로서, 고 수준의 설계를 결정하고 소프트웨어 코딩 표준 툴, 플랫폼 등 기술 표준을 지시한다.출처:위키 피디아

인기글

Chapter 4. 아키텍처 특성 정의된 문제를 소프트웨어에서 해결하려면 우선 설계는 시스템 요구 사항을 수집하고 그것을 실장 하기 위해서 필요한 각종 기술을 소프트웨어 개발 프로세스에 따라서 정리합니다.다만 이 밖에도 아키텍트는 소프트웨어 솔루션을 설계할 때 많은 것을 고려해야 합니다.아키텍트는 개발 팀과 함께 도메인 또는 사업 요건을 정의할 수 있지만 주로 소프트웨어에서 처리하는 일 중 도메인 기능과 직접 관계 없는 것, 즉 아키텍처 특성을 정의, 발견, 분석하는 일을 합니다.아키텍처 특성은 다음의 3가지 기준을 충족시킵니다.·비 도메인 설계 고려 사항을 명시한다.·설계의 구조적 측면에 영향을 준다.·애플리케이션의 성공에 있어서(절대적으로)중요하다.아키텍처 특성 목록 1. 운용 아키텍처 특성

용어 정의 가용성 시스템은 얼마나 오래 사용 가능해야 할까?(24/7인 경우, 장해 발생 시 시스템을 신속히 재가동하는 순서가 마련돼야 한다)연속성 재해 복구 능력 성능 스트레스 테스트, 피크 분석 기능의 사용 빈도 분석, 필요 용량 응답 시간 등 성능과 관련한 능력 복구성 비즈니스 연속성 요구 사항(장애 발생 시에 얼마나 빨리 재가동되는가), 백업 전략과 하드웨어 다중화 요건에 영향을 미치는 신뢰성/안전성 시스템에 Fail-Safe이 필요한가?Fail-Safe가 시스템 가동에 필수인가?견고성 프로그램 실행 중에 인터넷 접속 끊어져, 정전, 하드웨어 실패 등 오류 및 경계 조건에 견딜 수 있는 능력 확장성 사용자 수, 요청 수가 늘고도 시스템이 그에 맞는 성능을 발휘하는 능력

2. 구조적 구조 특성용어 정의 설정성 엔드 유저가 소프트웨어 설정을 간단히 바꿀 수 있을까?신기능을 짜넣는 것의 중요성, 설치성 필요한 모든 플랫폼 시스템을 얼마나 쉽게 설치하는가?활용성/재사용 공통 성분을 복수의 제품으로 활용하는가?지역성 데이터를 입력/조회하는 화면에 다언어 대응 할까?보수성 시스템을 얼마나 쉽게 변경/개선하는가?이식성의 1개 이상의 플랫폼에서 시스템을 실행하는가?지원성 애플리케이션은 어느 정도의 테크니컬지원을 필요로 할까?시스템에서 발생한 에러를 디버깅 하기에는 로깅 및 기타 기능이 어느 차원에서 지원될 필요가 있습니까?업그레이드성이 애플리케이션/솔루션의 옛 버전을 새 버전으로 쉽고 신속하게 업그레이드하는가?3. 아키텍처 공통 특성용어 정의로의 접근성 색맹, 청각 장애자 등 모든 이용자가 접속하는데 불편이 없는가?보관성 데이터를 다르게 보존해야 하는가, 아니면 일정 시간 경과 후에 삭제해야 하는가?인증 사용자가 본인임을 증명하기 위해서 필요한 보안 요구 사항인가 사용자가 애플리케이션에서 정해진 기능만을 사용하도록 강제하는 보안 요구 사항 합법성 시스템의 운영상의 법적 제약 조건이 있는가?회사는 어떤 권리를 유보해야 하는가?애플리케이션을 개발/배포하는 방법에도 다른 법적 규정이 있는가?프라이버시 회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능(예를 들어 암호화 트랜잭션은 DBA나 네트워크 설계도 해독 불가)보안 데이터를 암호화한 후 데이터베이스에 보관해야 하는가?내부 시스템 간 네트워크 통신도 암호화 해야 하는가?원격 사용자 접근은 어떤 종류의 인증이 필요한가?사용성/달성성 사용자가 애플리케이션/솔루션을 이용해서 목적을 달성하기 위해서 필요한 교육/훈련의 수준, 사용성의 요구 사항도 다른 아키텍처의 이슈에 못지않게 진지하게 다뤄야 한다.용어 정의 접근성 색맹, 청각장애인 등 모든 사용자가 접근하는데 불편함이 없다?보관성 데이터를 따로 아카이브해야 하는가, 아니면 일정 시간 경과 후 삭제해야 하는가?인증 사용자가 본인임을 증명하기 위해 필요한 보안요구사항 인가 사용자가 애플리케이션에서 정해진 기능만을 사용할 수 있도록 강제하는 보안요구사항 합법성 시스템의 운영상 법적 제약조건이 있는가? 회사는 어떤 권리를 유보해야 하는가? 애플리케이션을 개발/배포하는 방법에도 다른 법적 규정이 있는가?프라이버시 회사 내부의 임직원 트랜잭션을 외부로 내보내지 않는 기능(예를 들어 암호화 트랜잭션은 DBA나 네트워크 아키텍트도 해독할 수 없음) 보안 데이터를 암호화한 후 데이터베이스에 보관해야 하는가? 내부 시스템 간의 네트워크 통신도 암호화해야 하는가? 원격 사용자 접속은 어떤 종류의 인증이 필요한가요?사용성/달성성 사용자가 애플리케이션/솔루션을 이용해 목적을 달성하기 위해 필요한 교육/훈련 수준, 사용성 요구사항도 다른 아키텍처 이슈 못지않게 진지하게 다뤄야 한다.소프트웨어 아키텍처는 모호한 것들뿐이다.국제 표준 기구(ISO)기능 목록·성능 효율:기존의 조건에서 자원 양에 비례하는 성능 측정 값, 시간의 특징(응답 시간, 처리 시간, 처리율), 자원 사용(사용한 자원의 종류와 양)능력(최대 설정된 문턱을 넘는 정도)·호환성:제품 시스템 컴포넌트가 다른 제품과 정보를 교환하고 동일한 하드웨어/소프트웨어 환경을 공유하면서 필요한 기능을 수행할 수 있는 정도, 공존(환경과 자원을 다른 제품과 공유하면서 효율적으로 사용 할 정도의 상호 운용성)효율적으로 만족에 사용할 수 있는 정도 적합성 인지도, 학습성, 사용자 오류 방지, 액세시 비리티·신뢰성:특정 조건 하에서 시스템이 기능하는 정도 성숙도, 가용성, 내 고장성, 복구성·보안:사람이나 다른 제품,시스템이 자신의 인증 수준에 맞추어 데이터에 접근할 수 있도록 소프트웨어가 정보를 보호하는 정도, 기밀성, 완전성, 부인 방지, 책임 소재, 진위, 유지 보수성:개발자가 얼마나 효율적으로 소프트웨어를 개선할지 환경에 변화를 보이도록 환경에 변화와 발전을 나타내고 있습니다.모듈성, 재이용성, 분석성, 수정성, 시험성·이식성:개발자가 하드웨어, 소프트웨어 또는 다른 운용 환경에 있는 시스템, 제품 컴포넌트를 다른 장소로 옮길 수 있을 정도의 것. 적응성·설치성·기능 적합도: 주어진 조건에서 제품 및 시스템을 가동할 때 명시/암묵적인 요구 사항을 충족시키는 정도에 최고의 아키텍처를 고집하지 않고 나쁜 것 중에서 가장 좋은 아키텍처를 선택하세요.Chapter 5. 아키텍처 특성 식별 아키텍처를 구축하거나 기존 아키텍처의 타당성을 검증할 때 제일 먼저 할 일은 아키텍처 특성을 식별하는 것이다.주어진 문제 영역과 애플리케이션의 아키텍처 특성(~성)을 정확히 식별하기 위해서, 아키텍트는 해당 도메인을 잘 이해하고 있어야 하며, 도메인의 이해 관계자와 협력하고 도메인의 관점에서 중요한 것을 결정해야 합니다.도메인의 관심권에서 아키텍처 특성을 도출하는 설계는 도메인의 관심사를 올바른 해석하고 정확한 아키텍처 특성을 식별할 필요가 있습니다.아키텍처에서 가장 일반적인 안티 패턴은 모든 아키텍처 특성을 지원하는 제네릭아키텍처를 설계하는 것입니다.지원 가능한 아키텍처 특성 하나 하나가 시스템 설계 전체를 복잡하게 하는 요인이기 때문에 너무 많은 아키텍처 특성을 받아들이자 아키텍트, 개발자가 당초 의도했던 문제 영역의 해결을 시도하기 전에 아키텍쳐가 복잡하게 되어서 버립니다.아키텍처 특성의 개수에 얽매이지 말고 되도록 설계를 단순화하는 것이 좋습니다.대부분의 아키텍처 특성은 핵심 도메인의 이해 관계자의 의견을 듣고 도메인의 관점에서 무엇이 중요한지 의견을 교환하면서 정리됩니다.이런 과정이 언뜻 대수롭지 않게 느껴지지만, 아키텍트와 도메인의 이해 관계자가 서로 다른 언어로 말한다는 것이 문제입니다.아키텍트는 확장성, 상호 운용성, 내 고장성, 학습성, 가용성 운운하지만 도메인의 이해 관계자는 인수 합병, 고객 만족, 출시 시점, 경쟁 우위를 논하는 방식입니다.요건에서 아키텍처 특성 도출 요건정의서에 명시된 문장에서 도출된 아키텍처 특성도 있습니다.예를 들어 예상 고객의 수와 그에 따른 확장의 문제는 통상, 도메인의 관심사에 필수적인 단골 고객입니다.아키텍트가 아는 도메인 지식으로부터 도출되는 특성도 있지만 이것이 설계가 도메인 지식을 갖고 있으면 좋은 이유입니다.아키텍처에서는 틀린 답은 없고 비싼 답밖에 없습니다.Chapter 6. 아키텍처 특성 측정 및 구조 설계는 소프트웨어 프로젝트의 거의 모든 분야에 걸쳐서 매우 다양한 아키텍처 특성을 다루는 사람입니다.성능, 탄력성 확장성 등의 운용 특성이 모듈성, 배포성 같은 구조적인 관심사와 섞이고 있습니다.아키텍처 특성 측정 1. 운용 시금 2. 구조적 측정 3. 프로세스 측정 구조와 헬스 함수 1. 아키텍처 특성 관리 2. 피트니스 함수 Chapter7. 아키텍처 특성 범위 소프트웨어 아키텍처의 세계에서는 전통적으로 아키텍처 특성의 범위를 시스템 수준에 두는 것을 당연시하고 있었습니다.가령 아키텍트가 측정 가능성을 논할 때는 통상 시스템 전체의 확장성을 말합니다.10년 전까지는 거의 모든 시스템은 단일 결정으로 된 칩이던 것이 안전한 전제이었지만, 현대적인 공학 기술의 등장과 마이크로 서비스 등의 아키텍처 스타일이 가능한 아키텍처 특성의 범위는 상당히 좁혀졌습니다.커플링과 카 네이선스 구심/원심 커플링 같은 코드 수준의 커플링 메트릭은 아키텍처 분석용으로는 세분도가 너무 비쌉니다.2개의 컴포넌트 중 어느 쪽이 변경되면 다른 한쪽도 변경할 필요가 있어 시스템 전체의 정합성이 맞고 있다면 이들은 연줄 센스를 갖고 있다는 것입니다.동적 연결에는 동기와 비 동기 2종류가 있습니다.분산 서비스끼리 동기 호출하면 호출부는 호출부의 응답을 기다려야 하는데 대한 이벤트 기반 아키텍처의 비동기 호출은 파이어 앤드 포어 바게뜨 방식이어서 운용 아키텍처에서 2개의 서비스는 개별적으로 동작시킬 수 있습니다.아키텍처 양자와 입도 소프트웨어를 연결시키는 것은 컴포넌트차원의 연결만이 아닙니다.많은 비즈니스 개념은 의미적으로 복수의 시스템부품을 조합해서 기능적으로 응집하고 있습니다.소프트웨어를 정상적으로 설계 분석, 발전시키기 위해서 개발자는 문제가 되는 연결 지점을 모두 살펴볼 필요가 있습니다.Chapter 8. 컴포넌트 기반의 사고 모듈에 관련하는 코드 다발하려고 했지만 아키텍트는 보통 모듈을 물리적으로 장착한 컴포넌트로 생각하고 있습니다.개발자는 자기 개발 플랫폼에서 다양한 방법으로 모듈을 물리적으로 포장합니다.이처럼 모듈을 물리적으로 포장한 것을 컴포넌트는 Java jar, Dotnet dll, Ruby gem파일처럼 대부분의 언어는 포장을 지원합니다.컴포넌트 범위 컴포넌트는 아티팩트를 만들어 필요에 응하고 중첩하고 계층화하고 언어에 특정 메커니즘을 제공합니다.컴포넌트는 아키텍처에서 서브 시스템 또는 레이어의 형태로 나타나고 많은 행사프로세서 전용의 전개 가능한 작업 단위입니다.서비스는 또 다른 종류의 컴포넌트로 자신의 주소 공간에서 실행되며, TCP/IP 같은 저질 네트워크 프로토콜이나 REST메시지 큐처럼 높은 레벨 포맷을 통해서 통신합니다.마이크로 서비스 같은 아키텍처에서는 서비스는 배포 가능한 독립된 단위를 형성합니다컴포넌트는 아키텍처의 근사적인 모듈성을 구성하는 요소로서 설계에 매우 중요한 고려 사항입니다.실제로 아키텍트가 결정하는 중요 항목의1개는 아키텍처 기능의 최상위의 분할에 관련하고 있습니다.아키텍트의 역할 아키텍트는 아키텍처 내부 컴퍼넌트를 정의, 개선, 관리, 제어하는 것을 실시합니다.소프트웨어 아키텍트는 아키텍처 특성과 소프트웨어 시스템 요구 사항을 종합하면 비즈니스 분석가, 분야별 전문가, 개발자, QA, 운영자 등과 함께 소프트웨어 초기 설계를 실시합니다.개발자 롤 개발자는 설계와 공동 설계한 컴포넌트에 근거하여 클래스, 함수 서브 컴포넌트로 쪼갭니다.보통 클래스, 함수 설계는 아키텍트, 기술 리더 개발자 공동 책임이지만, 거의 대부분이 개발자가 담당합니다.개발자는 아키텍트가 설계한 컴포넌트가 최종본이라고 생각할 게 아니랍니다.모든 소프트웨어 설계는 에타ー 레이션을 거치고 더욱 세련됩니다.초기 설계는 일단 초안으로 보고, 향후 구현을 하고 모든 것을 밝힐 하나씩 개선하면 됩니다.컴포넌트 식별 플로 컴포넌트 식별은 후보를 도출하고 피드백에 의해서 다음의 프로세스를 반복하는 것이 최적입니다.1. 초기 컴포넌트 식별 2. 요구 사항을 컴포넌트에 배정 3. 역할과 책임의 분석 4. 아키텍처 특성 분석 5. 컴포넌트 재구성 컴포넌트의 세분도에서 가장 적절한 세분성을 발견하는 것은 설계의 가장 어려운 작업1개입니다.컴포넌트를 쪼개고 설계하면, 컴포넌트 간의 통신이 많아서 그렇다고 크게 나누다 보면 내부적으로 연결이 증가하고 배포, 테스트가 어렵고 모듈성의 관점에서도 부정적인 영향을 미칩니다.컴포넌트 설계 부품 설계”왕도” 아닙니다.팀과 조직에서 사용하는 소프트웨어 개발 프로세스와 더불어 다양한 기술과 트레이드 오프가 있지만, 아키텍트는 아키텍처를 설계하면서 요구 사항을 접수, 어플리케이션을 구성하는 구성 요소를 그리고 볼 필요가 있습니다.Part II아키텍처 스타일 Chapter 9. 기초 건축 스타일은 종종 아키텍처 패턴이라고도 불리며 각종 아키텍처 특성을 다루는 컴포넌트의 명명된 관계를 기술합니다.아키텍처 스타일의 명칭은 숙련된 설계 사이에서 쉽게 말할 수 있는 이름으로서 붙여지고 있습니다.아키텍트는 기초적인 아키텍처 스타일의 명칭에 익숙할 필요가 있습니다.아키텍처 스타일은 각 명칭별 설계 패턴의 존재 이유이기도 하다, 다수의 상세 정보가 포함되어 있습니다.또 건축 스타일은 토폴로지와 기본 전제인 아키텍처 특성을 유익한 것이 해로운 것 양쪽에서 기술합니다.기초 패턴 소프트웨어 아키텍처의 역사를 통하여 끊임없이 나타나고 다시 나타나는 패턴이 있으며 이들의 패턴은 코드, 배포 또는 아키텍처의 다른 부분을 구성하는 시야를 넓히고 줍니다.초기에는 이전 투구, 유니터리 아키텍처, 클라이언트/서버 아키텍처가 대표적입니다.이 가운데 3티아 아키텍처는 1990년대 후반 인기를 누렸던 아키텍처에서 더 많은 레이어로 분리합니다.WEB/WAS/DB를 나누어 3티아라고 부릅니다.모 놀리식-분산 아키텍처 아키텍처 스타결정 기준 복제 캐시 분산 캐시 최적화 성능 일관성 캐시 크기 작음(<100MB) 큰(>500MB) 데이터 유형 정적임 매우 동적인 업데이트 빈도 비교적 낮음 매우 높고 성장성 좋음결정 기준 복제 캐시 분산 캐시 최적화 성능 일관성 캐시 크기 작음(<100MB) 큰(>500MB) 데이터 유형 정적임 매우 동적인 업데이트 빈도 비교적 낮음 매우 높고 성장성 좋음가동률 연간 다운타임(일당) 90.0% 36일 12시간(2.4시간) 99.0% 87시간 46분(14분) 99.9% 8시간 46분(86초) 99.99% 52분 33초(7초) 99.999% 5분 35초(1초) 99.99% 31.5초(86밀리초)소프트웨어 아키텍트는 리더인 소프트웨어 아키텍트는 개발 팀을 이끌고 아키텍처를 구현하는 리더입니다.유능한 소프트웨어 아키텍트가 된 50%정도는 효과적인 대인 기술, 조정 능력, 리더십에 있다고 생각합니다.아키텍트는 비전을 가져야 하지만 현실적인 솔루션을 적용할 필요가 있습니다.즉, 다음과 같은 요소와 제약 조건을 모두 고려해야 합니다.·예산 제약 등의 비용 요소·시간 제약 등의 시간 요소·개발 팀 스킬 세트 및 수준·아키텍처 결정에 관한 트레이드 오프와 의미·제안된 아키텍처 설계 또는 솔루션의 기술적 한계 아키텍트로서 존중되려면 실용적인 것과 비전을 가진 것의 균형을 잘 잡는 것이 중요합니다.비즈니스의 이해 관계자는 여러가지 제약 조건에 적합한 비전이 가미된 솔루션을 높이 평가하고 개발자는 실장의 관점에서 솔루션이 실용적이라는 사실에 높은 점수를 줄것입니다.개발 팀과의 융합 아키텍트의 달력은 대부분의 경우 다양한 회의에서 가득합니다.유능한 소프트웨어 아키텍트로서 성공하는 중요한 포인트 1개는 개발 팀에 더 많은 시간을 보내는 것입니다.Chapter 24. 직업 경력 개발 아키텍트는 경력을 통해서 끊임없이 배워야 합니다.테크놀로지의 세계는 어지러울 만큼 변화가 빠릅니다.아키텍트는 기술인 비즈니스이며 관련 자료에 항상 관심을 갖고 개인 저장소에 제대로 쌓아 두어야 합니다.20분 룰 아키텍트에는 기술의 깊이보다 폭이 중요하고 이 폭을 유지하는 데는 시간과 노력이 필요합니다.아키텍트는 당연히 이 일을 일상화 해야 하지만 다양한 웹 사이트를 돌아다니며 기사를 읽고 프레젠테이션을 보고 팟 캐스트를 듣는 시간에 천혜의 아키텍트는 얼마나 있을까요?아마 많지 않다고 생각합니다.이들의 균형을 유지하는 스킬로서 20분의 룰이 있습니다.아키텍트로서 경력을 유지하기 위해서 새로운 것을 배우거나 특정 주제에 깊숙이 잠입하다 시간을 매일 최소 20분은 할애하라는 규칙입니다.개인 레이더의 개발자에게 절실했던 것은 기술 레이더이었습니다.기존 기술과 초기 기술 위험과 보상을 평가하는 살아 있는 문서입니다.총평 이 책을 통해서 배울 점은 다양한 아키텍처에 대해서 한번씩 볼 수 있어 좋았고, 스스로 기술에 대한 끊임 없는 연구와 학습이 필요하다는 것을 절실히 느끼게 되었습니다.경력 20년이 지났지만, 깊이가 아직 부족하고 기술은 매우 빨리 진화한다는 점에서 고민하고 있는 것 같습니다.다시 클라우드를 공부하고 있지만 몇년 사이에 급속히 변화한 현실을 바라보며 다시 정신을 차리고 많은 시간을 투자할 계획입니다.#도서 리뷰, 소프트웨어,#아키텍처, 설계,#한빛 미디어,#클라우드,#ABLECLOUD,#ABLESTACK,#HCI