스터디 ) 엔터프라이즈 애플리케이션 아키텍쳐 1장

 

 

 

새롭게 스터디를 시작하게 되어서 배운 내용을 정리한다. 

 

스터디 하는 책은 다음과 같다. 

https://product.kyobobook.co.kr/detail/S000001766248

엔터프라이즈 애플리케이션 아키텍처 패턴 | 마틴 파울러 - 교보문고

 

 

스터디 방식은 이전과 동일하게, 각자 정리를 해온 후 챕터별로 문제를 만들어서 풀어보는 시간을 가졌다. 

 

책을 보면서 느낀것은, 오래전에 작성된 책임에도 매우 내용이 현재 공부하는 내용과 비슷하면서 예전 번역의 느낌이라 한글로 이해가기가 오히려 어렵다는 것이다.

 

 

 

 

 

---

✏️ 내용 정리 

들어가며 

• 아키텍처
  • 시스템을 구성 요소로 나누는 최상위 수준의 분해
  • 번복하기 어려운 결정
  • ⇒ 시스템의 중요한 컴포넌트, 이러한 컴포넌트간의 상호 작용 방법에 관한 것
• 엔터프라이즈 애플리케이션
  • 지속적 데이터 (persistent data)를 처리
  • 기존 데이터를 손상시키지 않고 새로운 데이터를 저장하기 위해 데이터 구조가 여러번 변경될 수 있음
  • 일반적으로 여러 사람이 동시에 데이터 접근
    • 동시 사용자가 동일한 데이터에 접근할 때, 오류를 예방하기 위해 적절한 준비가 필요
  • 사용자 인터페이스 화면의 수도 많음
  • 다수의 일괄 처리 (batch processing)을 포함하는 경우가 많음
  • 단독으로 운영되는 경우가 거의 없어, 다른 엔터프라이즈 애플리케이션과 통합해야 하는 경우가 많음
  • 비즈니스 논리는 특수한 사항이 더해짐에 따라서, 비즈니스 비논리가 되는 경우가 있음
    • 논리가 시간에 따라 바뀐다는 것으로 논리를 최대한 효과적으로 구성하는 방법 밖에 없음
  • 실제로 대규모 프로젝트의 아키텍처와 프로세스를 간소화해 소규모로 만드는 것은 바람직함
• 엔터프라이즈 애플리케이션의 유형 예시
  • 절대적인 방법 조언은 적용되지 않음
  • 예시
    • B2C 온라인 소매상
      • 극히 많은 사용자를 처리
    • 임대 계약 자동화 시스템
      • 사용자가 동시 접속하는 비율은 낮지만, 비즈니스 논리 면에서는 훨씬 복잡
      • 규칙이 매우 임의적이기 때문에 까다로움
    • 소규모 기업을 위한 간단한 비용 추적 시스템
      • 부적절한 아키텍처로 인한 누적 효과가 클 수 있음
  • 아키텍처를 선택하는 것 = 시스템의 특정한 문제를 이해하고 적절한 설계를 선택
• 성능에 대한 고려
  • 먼저, 실행 가능한 상태로 만들고, 성능 측정 후 측정 데이터를 바탕으로 체계적인 최적화 절차가 필요
    • 성능 측정 시에는 반드시 전 후 성능을 따로 측정해야 함
  • 확장성 
    • 응답 시간 (response time)
      • 시스템이 외부에서 받은 요청을 처리하는데 걸리는 전체 시간
    • 응답성 (responsiveness)
      • 요청을 얼마나 신속하게 인식하는지
      • 사용자 인식에 중요한 요소
        • Ex) 상태 표시줄을 보여주면 응답 시간이 개선되지는 않지만, 사용자 인터페이스의 응답성이 개선됨
    • 대기 시간 (latency)
      • 수행할 작업의 존재 여부와 상관없이 모든 유형의 응답을 받는데 걸리는 시간
      • 원격 시스템을 사용하는 경우 요청과 응답이 네트워크를 통해 전달되는 시간때문에 시간 지연이 발생할 수 있음
    • 처리량 (throughput)
      • 일정 시간동안 얼마나 많은 일을 할 수 있는지 측정한 것
      • 일반적으로는 초당 트랜잭션(tps)이지만, 시스템에 맞는 공통 트랜잭션 집합을 선택해야 함
    • 성능 (performance)
      • 처리량이나 응답시간 중 더 중요한 항목을 의미
        • 사용자 관점에서는 응답성이 응답 시간보다 더 중요할 수 있음
    • 부하 (load)
      • 시스템이 현재 처리하고 있는 작업량
        • 현재 연결된 사용자 수로 측정 가능
    • 부하 민감도 (load sensitivity)
      • 부하에 따른 응답 시간의 변화
    • 효율 (efficiency)
      • 성능을 자원으로 나눈 것
    • 용량 (capacity)
      • 최대 유효 처리량 또는 부하
      • 절대 최댓값이거나 성능이 허용 가능한 임계값 미만으로 떨어지는 지즘
  • 확장성 (scalability)
    • 리소스(주로 하드웨어)를 추가했을 떄 성능에 미치는 영향
      • 수직 확장성 (vertical)
        • 단일 서버에 메모리와 같은 능력을 추가
      • 수평 확장성 (horizontal)
        • 서버를 더 추가
• 엔터프라이즈 시스템을 구축할 때는 용량이나 효율 보다 하드웨어 확장성에 중점을 두는 것이 유리한 경우가 많음
  • 확장성은 필요할 때 성능을 높일 수 있는 옵션을 제공
• 패턴
  • 목적과 스케치만 있으면 해당 패턴에 대한 모든 것을 알 수 있음
    • 작동원리
      • 해결책에 대한 설명
    • 사용 시점
      • 패턴을 언제 사용해야 하는가
    • 참고 자료
      • 패턴에 대한 다른 참고 자료

 

💡 문제 
Q :아래 중 엔터프라이즈 애플리케이션 아키텍처 설계 시 고려해야 할 사항에 대한 설명으로 옳지 않은 것은 무엇인가?

A. 엔터프라이즈 애플리케이션은 일반적으로 여러 사용자가 동시에 데이터를 접근하므로 동시성 제어가 중요하다.

B. 아키텍처 설계 시 효율을 최대한 우선시하고, 이후에 확장성은 하드웨어 교체로 해결하는 것이 바람직하다.

C. 시스템 성능 최적화는 실행 가능한 상태에서 측정 데이터를 바탕으로 체계적으로 수행해야 한다.

D. 확장성은 수평적 확장 방식(서버를 추가하는 방식) 외에도 수직적 확장(단일 서버 성능 증대)도 포함한다.

📍 답

정답: B

해설:B는 틀린 설명입니다. 엔터프라이즈 시스템을 설계할 때는 효율보다 확장성에 중점을 두는 것이 더 유리합니다. 효율을 우선시하는 것보다 하드웨어 리소스를 추가했을 때 성능이 어떻게 변화하는지를 고려하여, 필요한 경우 성능을 확장 가능한 방향으로 설계하는 것이 중요합니다.

 

 

 

 

 

1장. 계층화 

계층화 (layering)

• 소프트웨어 설계사가 복잡한 소프트 웨어 시스템을 분할하는데 사용하는 가장 일반적인 기법
  • 시스템을 계층으로 분할했을 때의 장점
    • 다른 계층에 대한 정보 없이 단일 계층을 하나의 일관된 계층으로 이해 가능
    • 동일한 기본 서비스를 가진 대안 구현으로 계층을 대체 가능
    • 계층간의 의존성을 최소화 가능
    • 계층은 표준화 하기 좋을 위치
    • 한번 구축한 꼐층은 여러 다른 상위 서비스에서 사용 가능
  • 단점
    • 계층은 전체가 효과적으로 캡슐화 되지 않음
      • 변경이 가해졌을 때 다른 계층에 영향을 미치는 경우가 있음
    • 계층을 추가하면 성능이 저하됨
      • 각 계층에서는 정보를 한 표현에서 다른 표현으로 변환해야 함
      • 단, 기반 기능을 캡슐화하면 성능 저하가 보상될 만큼 효율이 향상되는 경우도 있음
        • Ex) 트랜잭션을 제어하는 계층을 최적화하면 애플리케이션 전체가 빨라짐

엔터프라이즈 애플리케이션에서 계층의 발전

1. 클라이언트 - 서버 시스템

• 클라이언트에 도메인 논리를 추가하게 됨

2. 클라이언트 - 도메인 계층 - 데이터 원본 사용 계층

https://invozone.com/blog/web-application-architecture/

• 객체 지향 적

💡 Layer 와 Tier의 차이
Tier : 물리적 분리를 함축 

 

 

세 가지 주요 계층

• 프레젠테이션 (presentation)
  • 사용자와 소프트웨어 간의 상호작용 처리
  • 사용자 요청에 따른 API 처리
• 도메인 (domain logic)
  • 시스템의 핵심이 되는 논리
  • 애플리케이션이 수행해야 하는 도메인과 관련된 작업
    • 계산, 데이터 유효성 검사, 프레젠테이션에서 받은 명령을 기준으로 작업 대상이 될 데이터 원본 논리를 결정
    • 도메인도 상대적으로 구분되는 개별 영역으로 분리되는 경우가 있음
• 데이터 원본 (data source)
  • 데이터베이스, 메시징 시스템, 트랜잭션 관리자 및 다른 패키지와의 통신
    • 대부분의 엔터프라이즈 애플리케이션에서 가장 큰 데이터 원본 논리는 지속성 데이터를 저장하는 데이터 베이스

 

 

프레젠 테이션과 데이터 원본 계층은 외부 세계와 연결한다는 면에서 비슷한 점이 많음

https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

• 육각 아키텍쳐 패턴 (hexagonal architecture)
  • 모든 시스템을 외부 시스템에 대한 인터페이스에 둘러싸인 시스템으로 시각화
  • 모든 외부 요소를 근본적으로 외부 인터페이스로 나타내어 비대칭 계층화 체계와는 다른 모양의 대칭 뷰를 보여줌
• ⇒ 다른사람에게 서비스로 제공되는 인터페이스와 다른사람의 서비스를 사용하기위한 인터페이스는 구분하는 비대칭이 좋음
  • 응답과 요청 구분
• 도메인이나 데이터 원본 코드가 프레젠테이션의 코드의 서브루틴을 호출하면 안됨
  • ⇒ 동일한 기반을 유지하며서, 다른 프레젠테이션으로 손쉽게 교체하거나 수정하기가 용이 도메인과 데이터 원본은 프레젠테이션에 의존하지 않아야 함

 

계층이 실행될 위치 선택

• 논리적 계층
  • 시스템의 다른 부분 간의 결합(coupling)을 완화하기 위함
• 프레젠테이션 계층 실행
  • 원하는 사용자 인터페이스 유형에 따라 달라짐
  • 응답성이나 비연결 작업에 유리함
    • 서버에서 실행하는 경우 서버로 왕복 비용이 추가됨
  • 리치 클라이언트 프레젠테이션
    • 사용자가 직접 하기는 복잡한 작업이 있을때, 웹 GUI가 제공하는 것 이상의 기능이 필요한 경우
    • → 웹 프런트엔드를 개선해 리치 클라이언트 프레젠테이션이 필요한 경우를 줄이는 방법도 있음

💡 Rich Client
복잡한 사용자 인터페이스와 비즈니스 로직의 일부를 클라이언트(사용자 측)에서 직접 처리하는 애플리케이션 구조

• 데이터 원본
  • 거의 항상 서버에서 실행됨
    • 단, 비연결 작업을 위해 서버 기능을 고성능 클라이언트에 복제하는 경우는 비연결 클라이언트의 데이터 원본에 대한 변경을 서버와 동기화 해야 함
• 도메인 논리
  • 서버에서 실행하는 것이 유지 관리를 비용이 적음
• ⇒ 꼭 필요한 경우가 아니라면 계층을 여러개별 프로세스로 분리하지 말아야 함
  • 원격 파사드나, 데이터 전송 객체를 추가해야 할 때, 복잡하고 성능이 저하될 수 있음

 

 

 

 

 

 

 

💡 문제 
다음 중 계층화 아키텍처에 대한 설명으로 옳지 않은 것은 무엇인가?
A. 계층화를 사용하면 동일한 기본 서비스를 유지하면서 다른 구현으로 계층을 교체할 수 있다.
B. 프레젠테이션 계층이 도메인 계층의 서브루틴을 호출하는 것은 일반적인 계층화 방식에 부합한다.
C. 도메인 계층과 데이터 원본 계층은 프레젠테이션 계층에 의존하지 않아야 한다.
D. 계층 간 의존성을 줄이면 시스템 유지보수가 쉬워지고 대체가 용이하다.

📍 답 
정답: B
해설:B는 틀린 설명입니다. **계층화 원칙에 따르면, 도메인 계층이나 데이터 원본 계층은 프레젠테이션 계층에 의존해서는 안 됩니다.**프레젠테이션 계층은 도메인 계층을 호출할 수 있지만, 그 반대는 금지되어야 모듈성과 교체 가능성이 보장됩니다. 이를 통해 동일한 도메인 로직을 다양한 프레젠테이션(UI)과 결합할 수 있게 됩니다.