엔지니어링
[소프트웨어 아키텍처 101] 13. 서비스 기반 아키텍처 스타일
[소프트웨어 아키텍처 101] 13. 서비스 기반 아키텍처 스타일
2024.09.14인상깊은 부분분산 시스템에서의 데이터 무결성BASE 분산 트랜잭션라는 새로운 개념의 존재를 알게 됨분산도가 높은 아키텍처에서는 최종 일관성 기반의 BASE 분산 트랜잭션 활용. 이 기법은 최종 일관성 기반이므로 ACID 트랜잭션 레벨의 데이터 무결성은 지원하지 않음최종 일관성이란 별도로 분리된 배포 단위에서 처리된 데이터를 미리 알 수 없는 어느 시점에 모두 일관된 상태로 동기화한다.확장성, 성능, 가용성을 얻는 대가로 데이터 일관성과 무결성을 희생하는 트레이드오프인 셈이다트랜잭션 사가오케스트레이션 및 코레오그래피DB 분리 시 도메인 서비스 간 상호 통신 방지와 데이터베이스 간 중복 데이터 방지를 고려서비스 기반 아키텍처에서 단일 모놀리식 데이터베이스를 개별 데이터베이스로 분리할 수 있고, 마이크로서비스..
[소프트웨어 아키텍처 101] 12. 마이크로커널 아키텍처 스타일
[소프트웨어 아키텍처 101] 12. 마이크로커널 아키텍처 스타일
2024.09.07인상깊은 부분보험 청구처럼 비즈니스 케이스가 복잡한 경우에도 사용이 용이하겠다요약마이크로커널 아키텍처(microkernel architecture) 혹은 플러그인 아키텍처(plug-in architechture)제품 기반 어플리케이션(단일 모놀리식 배포 단위로 패키징해서 다운로드 및 설치가 가능하며, 보통 고객 사이트에서 서드파티 제품으로 설치되는)에 적합비제품(nonproduct) 고객 비즈니스 어플리케이션에서도 많이 사용예시) IDE와 같은 텍스트 에디터예시) Payment Processing이 코어 시스템을 나타내는 도메인이라면, 결제 수단(신용카드, 페이팔, 선불 카드 등)이 플러그인 컴포넌트12.1 토폴로지마이크로커널 아키텍처 스타일은 코어 시스템과 플러그인 컴포넌트라는 두 가지 아키텍처 요소로..
[소프트웨어 아키텍처 101] 11. TODO
[소프트웨어 아키텍처 101] 11. TODO
2024.08.31
[소프트웨어 아키텍처 101] 9. 아키텍처 스타일 기초
[소프트웨어 아키텍처 101] 9. 아키텍처 스타일 기초
2024.08.10인상깊은 부분/내 생각실무에서 순수하게 모놀리식을 쓰는 경우가 많을까?s3, serverless, firebase 등을 활용하는 순간 내 시스템 배포는 모놀리식 이어도 전체적인 모습은 분산 아키텍처를 사용하게 되는 거 아닐까?이 경우 분산아키텍처에서 고려해야하는 요소들을 제3자(네트워크를 이용하는) 연동 파트에서도 고려해야한다.비중의 문제인걸까? 완전한 모놀리식은 보기 어려운 것 같다.으음! 아키텍처 차원에서는 모놀리식이라고 보는게 맞으려나? 내가 컨트롤할 수 있는 영역을 어떻게 바라보고 다루느냐도 중요하니까..분산 아키텍처에서의 트랜잭션최종일관성을 기반으로 트랜잭셔널 사가와 BASE 기법을 사용한다.확장성, 성능, 가용성을 얻는 대가로 데이터 일관성과 무결성을 희생하는 트레이드오프인 셈이다요약아키텍처 ..
[소프트웨어 아키텍처 101] 8. 컴포넌트 기반 사고
[소프트웨어 아키텍처 101] 8. 컴포넌트 기반 사고
2024.07.11인상깊은 부분[[콘웨이 법칙]]조직구조나 의사소통 방식이 시스템에 묻어난다는 현상, 콘웨이 법칙은 살아있다. “조직문화부터 MSA까지” | 요즘IT최상위 아키텍처를 분하하는 두 가지 방법기술 분할(ex: 레이어드, Common/Local)과 도메인 분할(ex: DDD, 모듈러 아키텍처)아키텍트는 개발자, 비즈니스 분석가, 도메인 전문가와 협력해서 시스템을 어떻게 분할할지(즉, 기술 분할할지, 도메인 분할할지) 결정하고 그에 따른 초기 컴포넌트를 설계한다.컴포넌트 세분도[[아키텍처 101 8. 컴포넌트 기반 사고#컴포넌트 세분도]]적절한 크기/단위의 컴포넌트 식별은 어려운 것 같다.아키텍처 스타일에 따른 컴포넌트 식별 방법 케미p154 [[아키텍처 101 8. 컴포넌트 기반 사고#8.6 컴포넌트 설계]]식..
[소프트웨어 아키텍처 101] 7. 아키텍처 특성 범위
[소프트웨어 아키텍처 101] 7. 아키텍처 특성 범위
2024.07.09인상깊은 부분[[커네이선스]] 생각보다 자주 언급되는 개념이다.3장 대충 넘겼는데 나중에 다시 읽어야할수도..궁금한 것[[커네이선스]]를 결합 혹은 의존이라는 개념과 동일하다고 생각해도 될까? 단순 코드레벨이 아니라 비즈니스 개념 상의 결합/의존/응집을 표현하고자 하는걸까?요약7.1 커플링과 커네이선스[[커네이선스]] 정의 : 두 컴포넌트 중 한쪽이 변경될 경우 다른 쪽도 변경해야 전체 시스템의 정합성이 맞는다면 이들은 커네이선스를 갖고 있는 것이다. (= 결합 or 의존을 갖고있다고 받아들이면 되나)정적 커네이선스 (정적 코드 분석으로 발견할 수 있는 것)동적 커네이선스 (런타임 동작에 관한 것) : 동적 커네이선스는 동기, 비동기 두 종류가 있음동기 : 분산 서비스끼리 동기 호출을 하면 호출부(cal..
[소프트웨어 아키텍처 101] 6. 아키텍처 특성의 측정 및 거버넌스
[소프트웨어 아키텍처 101] 6. 아키텍처 특성의 측정 및 거버넌스
2024.06.25인상깊은 부분엔지니어는 아무 수치나 대충 목표로 삼는 게 아니라, 시간에 따라 어떤 추이를 보이는지 측정하고 통계 모델을 수립한다.예를 들어, 특정 API의 평균 응답 시간(p116~p117)의 단축을 목표로 한다면, max와 p99, p90의 평균 응답 시간을 얻고 각 구간별 목표 응답속도를 목표한다는 뜻인 것 같다.그리고 목표한 수치를 벗어나는 경우 알림을 받아서, 모델 자체가 부정확했거나(팀이 알고 싶어 하는 것), 뭔가 잘못되었거나(역시 팀이 알고 싶어 하는 것) 두 가지 중 하나일 것이다.모델 자체가 부정확했다는 뜻은, 구간별 평균 응답에 대한 측정이 잘못되어서 목표수치 설정을 잘못했다는 뜻이려나?아키텍처 특성 정의 시의 문제점은, 아키텍처 특성을 객관적으로 정의하면 모두 해결된다.정말 그럴까?..
[소프트웨어 아키텍처 101] 5. 아키텍처 특성 식별
[소프트웨어 아키텍처 101] 5. 아키텍처 특성 식별
2024.06.18인상깊은 부분도메인 관심사에서 도출한 아키텍처 특성비즈니스 이해도를 바탕으로 도메인 이해관계자들과 대화를 통해 시스템의 숨겨진 기술적인 요구사항을 찾아내야한다는 점을 이야기로 풀어주어서 좋았음유저 대비 성능 기준선특정 유저 수 기준으로 어느 정도의 성능이 나와야 하는 지 생각해보는 것예를 들어 UI 페이지에 API를 새로 추가해야할 때, 일평균 UI 페이지를 방문자 수와 어느 시간대에 주로 접근하는지 알면 API가 지원해야하는 성능(즉, 1초에 몇 개의 요청을 처리해야하는 지)를 알 수 있음아키텍처에서는 틀린 답은 없고 값비싼 답만 있습니다!띵언이네..기술 발전과 클라우드의 등장으로 인프라 비용이 많이 저렴해지고 관리하기도 쉬워졌지만, 보통 확장성과 가용성을 지원하려면 서버 비용이 더 든다. 그리고 이를..
[소프트웨어 아키텍처 101] 4. 아키텍처 특성 정의
[소프트웨어 아키텍처 101] 4. 아키텍처 특성 정의
2024.06.03요약아키텍처 특성 정의아키텍트는 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행함아키텍처 특성은 아래 세 가지 기준을 충족함비도메인 설계 고려 사항을 명시 : 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시함설계의 구조적 측면에 영향 : 예를 들어, 어떤 시스템이든 기본 보안을 준수해야 하지만, 뭔가 특별한 것을 설계해야 한다면 보안은 아키텍처 특성 수준으로 격상됨어플리케이션 성공에 절대적으로 중요아키텍처 특성을 적게 선정하는 것도 중요한 책무암묵적 아키텍처 특성은 요구사항 정의서에는 없지만 프로젝트 성공에 꼭 필요한 특성 (ex..
[소프트웨어 아키텍처 101] 3. 모듈성
[소프트웨어 아키텍처 101] 3. 모듈성
2024.05.12인상깊은 부분응집에 대한 정의이 책에서는 응집을 아래와 같이 정의하였다. 언뜻 직관적으로 표현하였지만, 해석의 여지가 많아보인다. 코드 레벨의 설계에 대한 공부를 하려면 다른 책을 읽는 게 좋겠다.응집은 한 모듈의 파트가 동일한 모듈 안에 얼마나 포함되어 있는지를 나타냅니다. 다시 말해, 모듈을 구성하는 파트가 서로 얼마나 연관되어 있는가, 하는 것입니다. 이상적으로 응집된 모듈이라면 모든 파트가 함께 패키징되어 있겠죠.오브젝트 책에서는 응집도와 결합도에 대해 아래와 같은 질문을 던졌다.오브젝트 책에서 말한 응집도, 결합도에 대한 정의와 질문에 대한 답은 별도 포스팅할 예정이다.모듈 내의 요소가 얼마나 강하게 연관돼 있어야 응집도가 높다고 말할 수 있는가? 모듈 사이에 어느 정도의 의존성만 남겨야 결합도..
[소프트웨어 아키텍처 101] 2. 아키텍처 사고
[소프트웨어 아키텍처 101] 2. 아키텍처 사고
2024.05.07인상깊은 부분기술 폭2장에서도 1장과 마찬가지로 기술폭에 대한 언급이 나와서 좀 더 생각해봄문제를 해결할 수 있는 특정 기술보다는, 그 문제를 해결할 수 있는 여러 기술을 알라는 조언으로 생각하는 게 좋겠음내가 알던 좋은 아키텍트 겸 리더는 훌륭한 개발자로 깊이를 만든 후 폭을 넓힌 것 같음. 혹은 둘 다 동시에 진행한 것으로 보여짐.개인적인 경험으로 미루어 볼 때 깊이가 없으면 폭을 넓히기도 쉽지 않음.기본적으로 어떤 문제를 해결하기 위해 다양한 솔루션을 확인하고, 특정 기술 한 두 가지 정도는 뾰족하게 가져가야 좋을 것 같음.경매 시스템의 트레이드 오프개인적으로 마음에 드는 예제 p60 ~ p63요약아키텍처 사고 방식은 크게 4 가지로 구성아키텍처와 설계의 차이 이해 및 개발팀과 어떻게 협력해야할 지..
[소프트웨어 아키텍처 101] 1. 서론
[소프트웨어 아키텍처 101] 1. 서론
2024.05.06서문이 책은 지난 10년 동안 일어난 모든 혁신과 더불어 오늘날의 새로운 구조와 관점에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴본다.이 책의 부제는 '엔지니어링 접근 방식'이다.기존 소프트웨어 아키텍처에서 당연시됐던 많은 공리들을 최근 생태계와 설계 아키텍처의 관점에서, 그리고 요즘 전반적인 추세와 비교하여 다시 한번 돌아보겠다.인상깊은 부분아키텍처를 공부하기 어려웠던 이유아래와 같은 이유로 아키텍처에 대한 공부를 하기 어려웠군.소프트웨어 아키텍처의 역사는 과거 아키텍트들의 시도가 난잡하게 얽혀있음소프트웨어 아키텍처에 관한 자료는 대부분 역사적인 연관성을 강조함위키피디아 페이지를 읽다보면 종잡을 수 없는 약어들로 광활한 지식의 세계로 상호 참조하는 링크들을 어렵잖게 발..