아키텍트(Architect)

아키텍트(Architect)

소프트웨어 아키텍처를 설계하는 고급 SW 개발자.

고수준의 설계적 결정을 수행하고 소프트웨어 코딩 표준, 도구, 플랫폼을 포함한 기술 표준을 지시

종류

• Enterprise Architect (EA) Business Architecture(BA)를 포함한 전체 아키텍쳐 설계에 대한 책임을 진다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해를 바탕으로 장기적인 IT 전략 수립을 담당한다. EA의 특징중의 하나는, EA의 경우 단일 프로젝트 뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍쳐에 대한 책임을 진다. 또한 SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용한다.
• Solution Architect (SA) 특정 솔루션에 대한 아키텍쳐를 설계한다. SA의 경우 프로젝트 내에 개발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당한다.
• Technical Architect (TA) 프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계한다.
• Application Architect (AA) 애플리케이션에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다. 팀 규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고, 소규모팀인 경우에는 프로젝트 전체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당한다.
• Data Architect (DA) 프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당한다.
• Global Architect (GA) [Optional] 일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할이다. EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여해야 하고, 비지니스 전략 측면에서 접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제 아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하지 않은 경우가 있기 때문에, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술 중심의 System Architecture의 설계 하도록 한다. 프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로 보면 된다. EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키텍쳐 설계에 집중한다.

요건

• 커뮤니케이션
• 추상화 능력
• 비즈니스에 대한 이해
• 기술에 대한 이해
• 코딩 능력

아키텍처 스타일

마이크로 서비스 아키텍처(MSA)

MSA의 정의

"마이크로 서비스 아키텍처 스타일은 단일 애플리케이션을 소규모 서비스 스위트로 개발하는 방법으로, 각각 자체 프로세스에서 실행되고 경량 메커니즘, 종종 HTTP 자원 API와 통신합니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전 자동화 된 배포 기계를 통해 독립적으로 배포 할 수 있습니다."

=> 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

MSA 장점

1. 빌드 및 테스트 시간을 단축시킬 수 있다.
2. 플로글랏 아키텍처 구성이 가능하다.
3. 탄력적이고 선택적인 확장이 가능하다.
4. 하나의 서비스가 다른 서비스에 영향을 주지 않는다.

MSA의 단점

1. 성능 이슈가 있다.
2. 트랜잭션이 불편하다.
3. 관리 포인트가 늘어난다.

이벤트 기반 아키텍처(Event-driven Architecture, EDA)

분산된 시스템 간에 이벤트를 생성, 발행(publishing)하고 발행된 이벤트를 필요로하는 수신자에게 전송된다.

이벤트를 수신한 수신자가 이벤트를 처리하는 형태의 시스템 아키텍처

• Event Driven Pattern - 특정 행동이 자동으로/순서에 따라 발생하는 것이 아닌 어떤 일에 대한 반응으로 동작하는 디자인 패턴

• IO Event - 컴퓨터 회로를 구동시키기 위해 발생하는 일   ex)  마우스 클릭, 키보드 타이핑, 모바일 터치 등

• IOT 기기 등의 센서로부터 유입되는 데이터 스트리밍 기반의 동작

• 시스템의 내,외부에서 발생한 주목할 만한 상태의 변화(a significant change in state)

  주로 Event Driven 시스템은 Message Broker(Kafka, Rabbit MQ, Redis)와 결합하여, Message Driven 시스템으로 구성된다.

EDA의 구성요소

• Event generator : 시스템 내,외부의 상태 변화를 감지하여 표준화된 형식의 이벤트를 생성
• Event channel : 이벤트를 필요로 하는 시스템까지 발송
• Event processing engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있다.

Event Processing Style

• Simple event processing
  • 각각의 이벤트가 직접적으로 수행해야할 action과 매핑되어 처리 된다. 실시간으로 작업의 흐름을 처리할 때 사용되며, 이벤트 처리 시간과 비용의 손실이 적다.
• Event Stream Processing
  • 이벤트를 중요도에 따라 필터링하여 걸러진 이벤트만을 수신자에게 전송. 실시간으로 정보의 흐름을 처리할 때 사용되며, 기업에 적용될 경우 신속한 의사 결정을 가능케한다.(BAM)
• Complex event processing
  • 일상적인 이벤트의 패턴을 감지하여 더 복잡한 이벤트의 발생을 추론하는 것. 예를 들어 '주식의 등락'이라는 일상적인 이벤트의 패턴을 감지하여 '투자 적기'라는 상위의 이벤트를 추론해 낼 수 있다.

EDA를 사용하는 경우

• 여러 하위 시스템이 동일한 이벤트를 처리해야 하는 경우.
• 최소 시간 지연의 실시간 처리.
• 패턴 일치 또는 일정 기간의 집계와 같은 복합 이벤트 처리.
• 높은 볼륨 및 높은 데이터 개발속도(예: IoT).

EDA의 장점

• Decoupling - 시스템 간의 느슨한 결합이 가능 하므로 분산 시스템, Microservice 환경에서 시스템 간 의존성을 배제 할 수 있다 (시스템은 Event Channel인 Message Broker에 대한 의존성만 가진다.)
• 다른 시스템의 정보를 알 필요가 없다 - 약속된 Event message를 가지고 상호 정보를 교환한다.
• micro service 단위로 시스템을 분리하기 쉽기 때문에 확장성, 탄력성을 고려하기 쉽다.

EDA의 단점

• Broker Dependency - Event를 전송하기 위한 Message Broker에 대한 의존성이 커지기 때문에 Message Broker 장애 상황 시, 전체 장애로 이어질 수 있다.
• Transaction 단위가 격리되기 때문에 서비스 장애 발생시 retry/rollback을 고려해야 한다.
• 시스템 전체 Flow를 파악하기 어렵다. - 명확한 Flow를 보기 위해서는 시스템을 모니터링하여야 한다.
• 디버깅이 어렵다.

계층형 아키텍처(Layered Architecture)

계층형 아키텍처의 정의

특정 추상 레벨에 있는 서브태스크들끼리 서로 묶어서 하나의 그룹으로 분류하는 소프트웨어 아키텍처 스타일

하위 수준의 이슈를 상위 수준에 이슈와 분리시켜 소프트웨어의 재사용성을 높여주는 패턴

대부분의 중/대규모의 어플리케이션은 효율적인 개발 및 유지보수를 위해 계층화(layered)하여 개발하는 것이 일반적이다.

MVC패턴의 특징

• 컨트롤러와 모델과는 독립적으로 뷰를 수정할 수 있다.

• 모델 컴포너트는 뷰와 컨트롤러 컴포넌트로부터 데이터 구조와 같은 내부적인 상세한 사항을 숨긴다.

• 모델에 인터페이스를 가능한 한 사용하면, GUI 또는 J2ME와 같은 영역에서도 재사용이 가능하다.

• 컨트롤러에 모델 코드 부분을 분리하면 원격 비즈니스 컴포넌트 사용으로 옮겨가는 것이 수월하다.

  이와 같이 계층화 아키텍처는 UI의 로직과 비즈니스 로직은 어떻게 구현하고 어디에 위치시킬 것인가, 그리고 어플리케이션에 필요한 데이터 및 어플리케이션의 상태는 어떻게 유지하고 공유할 것인가 등에 대해서 정의하고 각 계층을 분할한다.

계층의 분할에 있어서, 각 계층의 역할과 각 계층을 연결하기 위해 사용할 기술 요소들과 특정 계층을 교체하거나 변경할 경우 다른 계층들에 영향을 주지 않을 정도의 유연성에 대해서 반드시 고려해야 한다.

MVC패턴을 세분화

• 프리젠테이션 계층
• 제어 계층
• 비즈니스 계층
• 모델 계층
• 퍼시스턴스 계층
• 도메인 모델 계층

계층형 아키텍처의 장점

• 계층별 연동을 한정할 수 있어 Loosely coupled 원칙을 지킬 수 있음
• 변화에 대한 영향력을 한정할 수 있어 코딩이나 테스트를 계층별로 진행할 수 있음
• 인터페이스 정의가 잘 되어 있다면 계층을 통째로 교체할 수 있음
• 모듈의 재사용성을 높여 유지보수성이나 이식성이 좋은 패턴임

계층형 아키텍처의 단점

• 계층의 원칙을 지키기 위해 각 계층을 모두 거쳐야 하므로 성능 측면에 불이익을 받을 수 있음
• 계층을 구분하기 어렵고 잘못 구분할 경우 설계 수정이 빈번히 발생할 수 있음
• 계층의 적절한 개수 및 규모를 정의하는 것이 어려움