SW Engineering - 아키텍쳐

아키텍쳐

소프트웨어 구조를 의미한다.

• 어떤 컴포넌트가 존재하는가? 를 설계하는 것.

UML - 패키지 다이어그램

클래스 다이어 그램은 직사각형으로 표시했지만, 패키지 다이어그램은 폴더 모양으로 만든다.

• Java패키지 안에 Util패키지 않에 Data 클래스가 있는 경우.

• 또한 클래스 다이어 그램처럼 패키지간 의존관계나 연관관계를 표현할 수 있다.

아키텍처 스타일

소프트웨어 시스템을 구상하는 기본 구조적 패턴을 의미한다.

1. 계층형 아키텍쳐 (Layered)

소프트웨어의 기능을 수직으로 여러 층으로 분할

• 한 레이어에서 다른 레이어로의 상호작용을 "메시지를 교환한다"라고 한다.
• 각 층은 자기 아래층의 기능만 사용할 수 있고, 위층으로는 결과를 통지할 수 있다.
• 낮은 수준 계층의 기능을 이용해 높은 수준의 기능을 제공하는 계층을 만들 수 있다.
  ex) TCP

• Persentation Tier
  • 사용자 UI및 통신 담당
  • 정보를 표시하고 사용자로부터 정보를 수집한다.
  • 모바일 앱 클라이언트, 웹 브라우저 서버가 해당된다.
• Application Tier
  • Logic tier이라고도 함
  • Data를 가공해서 핵심 비즈니스 logic을 구현한다.
  • 앱 서버가 이에 해당한다.
• Data tier
  • Application이 처리되는 정보의 저장 및 관리

계층 - Hour glass 모델

모래시계를 닮아서 이름 붙여짐

• 어떤 물리적 연결 기술이든 IP만 구현하면 다양한 서비스(소프트웨어)를 돌릴 수 있다.

• 어떤 서비스든 IP로만 구현하면 다양한 물리적 연결 기술로 된 네트워크에서 동작하게 된다.
  
  

<계층화 장점>

• 단순화
  • 각 계층은 자기가 제공할 기능만 생각하면 된다.
  • 각 계층은 자기의 아래 계층을 다루는 법만 알면 된다.
• 문제 해결의 편의성
  • 문제가 있는 계층만 디버깅하면 된다.
  • 각 계층이 단순해 해결하기 쉽다.
• 진화의 편의성
  • 각 계층은 바로 위 계층에 알려준 "어떻게 쓰는지" 만 유지하면 된다.
  • 그 안에서는 자유롭게 개선/추가 할 수 있다.

<계층화 단점>

• 잠재적 비효율성
  • 각 계층을 넘나드는 것이 비효율적일 수 있다. -오버헤드
  • 바로 아래 계층이 아니라 아래아래 계층을 건너뛰어야 할때는 복잡해진다.
  • 어떤 계층을 건드리면 그걸 사용하는 상위 계층이 다 영향을 받는다.

2. 이벤트 기반 아키텍쳐

무언가 발생하면 처리되는 구조

• 이벤트가 발생하면 그에 반응하는 컴포넌트가 동작한다.
• 느슨한 결합을 사용한다.
• UI,게임,IOT에 자주 사용된다.

<구성 요소>

• 이벤트
• 이벤트 생산자 - producer
• 이벤트 소비자 - consumer

• queue없이 producer가 바로 consumer를 호출하는 방식
• 장점: 단순하다.
• 단점: 이벤트는 비동기기 때문에 발생 순서를 보장할 수 없다.

• queue를 통해 이벤트를 전달만 하는 형태
• 여러 컨슈머를 돌 수 있다.
• 예시: rabbit queue

• 어떤 소비자에게 전달할지에 대한 로직을 포함하는 경우

• 예시: websocket의 메시지 브로커

• broadcast : queue에 listener로 등록된 모든 소비자에게 전달된다.

• multicast : queue에 listener로 등록된 요건을 만족하는 소비자들에게 전달된다.

• Unicast : queue에 listener로 등록된 소비자중 특정 대상에게 전달된다.

• anycast : queue에 등록된 소비자중 랜덤한 하나에게 전달된다.

Producer - Consumer문제

• 생산자와 소비자는 고정된 크기의 버퍼를 통해 일을 주고받는다.
• 생산자는 버퍼가 다 찼다면 task를 더이상 추가하면 안된다.
• Consumer은 버퍼가 비었는데 task를 빼내려고 하면 안된다.
• 생산자와 소비자는 동시에 버퍼에 접근할 수 없다.

<이벤트 기반 장점>

• 캡슐화 : 이벤트 생성자와 소비자를 분리하여 캡슐화가 가능하다.
• 확장성 : 새 생산자/소비자를 추가하는 것이 손쉽다.

<이벤트 기반 단점>

• 큐, 생산자, 소비자가 너무 많이 사용될 경우 제어 흐름이 복잡해진다. (버퍼에 동시 접근이 안돼서)

---

3. MVC

MVC는 웹개발을 하면 자주 보는 구조이다. 역할을 Model,View,Control로 나눠서 관리하는 구조이다.

• Model : 데이터와 비즈니스 로직을 담당한다.
• View : 화면 레이아웃 및 UI로직을 담당한다.
• Controller : 발생하는 명령을 Model과 View로 전달한다.

Q. MVC에서 이벤트 핸들러를 사용하는 부분은?
A. Model -> View , View -> Controller

<장점>

• 확장성: M,V,C간의 느슨한 결합으로 확장성이 좋다.
• 다수의 view를 생성가능하다.
• 비동기 처리에 따른 빠른 로딩 : 초기에 model이 완전히 초기화 되지않아도 view는 기본값을 보여준다.

<단점>

• 규모가 커지게 되면 코드가 복잡해진다.

4. 파이프 & 필터

여러 단계를 거쳐 데이터를 처리하는 구조

• 필터: 입력을 가공해서 출력으로 내보내는 모듈, 반드시 출력을 거쳐야 한다.
• 파이프: 필터들을 연결한다. 단방향이다. 데이터 가공을 하지 않는다.

<장점>

• 단순성: 시스템을 일련의 입력, 출력, 변환으로 단순화 할 수 있다.
• 재사용성: 다른 응용프로그램에 필터를 재사용 할 수 있다.
• 병렬성: 병렬처리가 쉽다.

<단점>

• 자원의 낭비: 필터는 출력을 생성하기 때문에 중간에 불필요한 쓰기 작업이 생길 수 있다.
• 필터 중간에 오류가 발생하면 이를 처리하기가 어렵다.

5. 클라이언트 서버

주로 게임에서 이러한 형태를 한다. 자원을 사용하는 쪽과 보내는쪽을 확실히 구분지어 두는 것이다.

• 서버를 호스팅 해야하기 때문에 서버 비용과 망 비용이 발생하게 된다.
• 클라이언트 입장에서는 서비스를 위해 접근해야하는 IP, Port가 명확하다.

6. p2p

각각의 참여자(노드)가 동등하게 "클라이언트"의 역할도 하고 "서버"의 역할도 한다.

<장점>

• 참여자간 통신을 통해 IDC(서버, 망) 비용을 줄일 수 있다.
• 서버를 거치는 것 보다 참여자간 통신이 "빠른 경우"가 있다.
• Churn(들락날락 거림)이 적다.

<단점>

• 서비스 참여자가 특정 서비스를 위해 누구를 접근해야 하는지 모른다. -> 따라서 "상대방 찾기"과정이 필요해진다.
• 전달 횟수(Hop count)가 적다고 빠른게 아니다.

7. 마이크로 서비스 아키텍처

독립적으로 동작하는 작은 서비스 집합으로 아키텍처를 구성한다.

• 독립적이며 상호 느슨하게 연결됨 (loosely coupled)
• 각각이 독립적인 코드베이스를 가지며 개발팀도 다른 경우가 많음
• 독립적으로 배포 가능함 → 전체 서비스를 내리지 않고 업데이트 가능
• 독립적으로 DB 혹은 내부 state 를 관리함
• 마이크로서비스 끼리는 API 로 통신함 (= RESTful API) → 따라서 각각의 마이크로서비스들은 캡슐화 됨

ex) 유저인증 : Firebase사용, 유저 요청 큐 : RabbitMQ사용, 세선관리: Reddis사용 등등