대용량 아키텍처와 성능 튜닝: 아키텍처 설계 방법

1. 소프트웨어 아키텍처의 설계

소프트웨어의 아키텍처는 비즈니스 요구사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 것으로, 현재의 요구사항뿐만 아니라 변화하는 요구사항에도 대응할 수 있도록 확장가능한 형태로 설계되어야 한다.

이러한 아키텍처를 설계하기 위한 큰 흐름은 다음과 같다.

1. 비즈니스 요구사항을 기반으로 한 비즈니스 아키텍처

2. 설계 원칙 정의

3. 시스템 아키텍처

흐름의 각 단계별 설계 절차를 차례로 알아보자.

비즈니스 아키텍처

기술적인 내용보다는 비즈니스 관점에서 바라본 시스템의 내용이다.
비즈니스 아키텍처를 통해 엔지니어가 전체 시스템의 사상이나 설계 배경에 대해 이해할 수 있도록 한다.

비즈니스 아키텍처는 다음과 같이 구성된다.

1. 개요
   서비스에 대한 기능과 배경을 서술한 요약 자료

2. 시장 현황 분석
   필수는 아니지만 시장 현황 분석을 통해 경쟁 제품에 대한 인사이트를 부여함으로서 시장 차별화 전략을 고려하게 하고, 서비스 트렌드를 반영하는데 도움을 줄 수 있다.

3. 주요 기능 정의
   시스템의 주요 기능을 10~20개 정도의 기능으로 정리한다.
   사용자와 시스템 간의 상호작용을 정의하는 것으로 표현

4. 도메인 모델
   사용자, 서비스 컴포넌트, 권한, 역할같은 개념과 관계를 도식화한 것
   도메인 모델을 통해 UX시나리오나 데이터 모델링을 정의할 때도 사용되므로 중요.

5. 전체 아키텍처
   전체 시스템에 대한 개략적인 아키텍처를 통해 전체 구조를 전달하고, 각자가 어느 부분에 참여하는지 알 수 있도록 한다.

6. 비즈니스 로드맵
   서비스에 대한 장기적인 일정을 서술하며, 출시 일정, 주요 키워드를 명시.
   로드맵 작성시에는 제품의 출시 일정과 버전별 릴리스 계획이 정교하게 포함되어야 한다.

설계 원칙

비즈니스의 요구사항에 의해 시스템의 설계 원칙이 세워진다.
아키텍처를 변경해야 할 상황이 발생할 때 판단 기준이 되는 것이 설계 원칙.

시스템 아키텍처

시스템 아키텍처는 애플리케이션, 테크니컬, 데이터의 3가지 관점에서 정의한다.

• 애플리케이션 아키텍처
  애플리케이션 아키텍처는 다시 3가지 관점에서 디자인할 수 있다.

  • 정적 아키텍처
    시스템을 구성하는 컴포넌트를 계층별로 표현.
    컴포넌트를 break down하여 0~3레벨까지 설계.
    레벨 0은 일반적인 계층으로 SOA, 3-Tier Client Server와 같은 스타일에 따라 구조가 비슷하게 나온다.
    보통 레벨 1,2에서 개발 유닛으로 분리될 수 있고, 계층을 통해 개발 진척도를 가시화할 수 있다.

  • 동적 아키텍처
    정적 아키텍처에서 컴포넌트의 종류와 구조를 파악했으면, 주요 시나리오에 대해 각 시나리오를 처리하기 위한 흐름을 표시하는 것이 동적 아키텍처이다.
    경우에 따라서는 컴포넌트뿐만 아니라 하드웨어나 네트워크에 대한 구성, 소프트웨어의 솔루션을 참고사항으로 표현할 수 있다.

  • 인터페이스 설계
    각 컴포넌트가 통신하는 방법을 정의.
    프로토콜은 REST, SOAP 등의 통신 프로토콜을 뜻한다.
    메시지 포맷은 프로토콜에 실려서 전송되는 메시지에 대한 포맷을 정의한다. API 명세서처럼 요청/응답이 모두 필요하다.
    메시지 교환 패턴은 메시지를 호출하는 방법으로 동기식과 비동기식이 있다.

    인터페이스 설계는 RPC 형태의 함수 호출뿐만 아니라 FILE 인터페이스, 테이블 인터페이스 등 여러 방식이 있으므로 유연하게 설계해야 한다.

• 테크니컬 아키텍처
  개발한 애플리케이션을 배포할 솔루션과 하드웨어에 대한 구조를 정의한다.

  • 하드웨어 배포 아키텍처
    각각의 컴포넌트, 서버 랙, 서버, 네트워크 장비, 스토리지에 대한 디자인을 정의한다.
  • 솔루션 배포 아키텍처
    솔루션은 애플리케이션이 작동하기 위한 미들웨어.
    클러스터링 기능이나 고가용성(HA)와 같은 기능을 제공하는 솔루션은 더 많은 특성을 요구한다.

• 데이터 아키텍처
  시스템에서 저장하고 다루는 정보에 대한 정의와 관리 구조에 대한 아키텍처.

  • 데이터 모델링
    시스템에서 다루는 정보를 구성하는 개체(Entity)와 개체들 간의 관계를 정의.
    개념 모델링 -> 논리 모델링 -> 상세(물리) 모델링의 단계를 거친다.
  • 데이터 저장소
    RDBMS에 들어가는 데이터뿐만 아니라 파일, 메타데이터 등의 모든 형태를 정의.
    데이터 특성에 맞는 저장소를 선택해야 한다.
  • 애플리케이션 컴포넌트와 맵핑
    데이터를 사용하는 애플리케이션 컴포넌트와의 관계 정의.
    각 데이터 개체가 단일 애플리케이션에 의해 다루어지도록 설계.
  • 데이터 관리 프로세스
    데이터 관리 정책을 정한다.
    보안, 생명주기, 공유와 통합, 분석과 리포팅에 대한 정책을 정한다.

아키텍처 결정 프로세스

문제를 해결하는 다양한 아키텍처 옵션 중 선택이 필요할 때 의사결정을 하는 프로세스가 아키텍처 결정(AD) 프로세스이다.

AD프로세스는 생성, 할당, 에스컬레이션, 해결의 과정을 거쳐 결정된다.

아키텍트의 역할과 종류

아키텍트는 시스템과도 연관이 있지만, 더 중요한 역할은 비즈니스와 기술 조직간의 소통 창구 역할이다.
따라서 아키텍처를 설계할 때도 단순히 기술 자체만이 아니라 비즈니스, 자원과 같은 변수를 고려해야 한다.

아키텍트의 종류는 다음과 같다.

• 엔터프라이즈 아키텍트(EA)
  비즈니스 아키텍처를 포함한 전체 아키텍처 설계의 책임을 진다.
  단일 프로젝트뿐만 아니라 앞으로의 프로젝트에 대한 아키텍처도 책임진다.

• 솔루션 아키텍트
  특정 솔루션에 대한 아키텍처 설계

• 테크니컬 아키텍트
  시스템에 대한 하드웨어 및 네트워크 아키텍처 설계

• 애플리케이션 아키텍트
  애플리케이션에 대한 표준 가이드 및 아키텍처 구조 담당.

• 데이터 아키텍트
  데이터 아키텍처 설계

• 글로벌 아키텍처
  필수는 아니지만 EA가 비즈니스 전략 측면에 더 집중하게 될 경우 실제 아키텍처 설계에 참여하기가 어렵다. 이 때 글로벌 아키텍처가 기술 위주의 설계에 집중하게 된다.