시스템 아키텍처는 일련의 소프트웨어 퀌포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의된다.

이러한 경계는 다양한 형태로 나타난다.

경계 횡단하기

‘런타임에 경계를 횡단한다’는 의미는 경계 한쪽에 있는 기능에서 반대편 기능을 호출하여 데이터를 전달하는 일에 불과하다.

적절한 위치에서 경계를 횡단하게 하는 비결은 소스 코드 의존성 관리에 있다.

• 소스 코드 모듈 하나의 변경으로 읜존하는 다른 소스 코드 모듈을 변경하거나, 다시 컴파일해서 새로 배포해야 할 지도 모르기 때문

경계는 소스 코드 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단으로써 존재한다.

두려운 단일체

아키텍처 경계 중 가장 단순하며 흔한 형태는 물리적으로 엄격하게 구분되지 않는 형태다.

이는 앞서 언급했던 소스 수준 분리 모드로, 함수와 데이터가 단일 프로세서에서 같은 주소 공간을 공유하며 나름의 규칙에 따라 분리되어있는 상태이다.

배포 관점에서 이는 단일체(monolith)라고 불리는 단일 실행 파일이므로, 외부에서 볼 때(물리적으로) 경계가 밖으로 드러나지는 않는다.

가장 단순한 형태의 경계 횡단은 저수준 클라이언트에서 고수준 서비스로 향하는 함수 호출이다.

이 경우 런타임 의존성과 컴파일타임 의존성은 모두 저수준 컴포넌트에서 고수준 컴포넌트로 향한다.

고수준 클라이언트가 저수준 서비스를 호출해야 한다면 동적 다형성을 사용하여 제어흐름과는 반대 방향으로 의존성을 역전시킬 수 있다.

경계를 횡단할 때 의존성은 모두 고수준 컴포넌트를 향하고 있으며, 데이터 구조의 정의가 호출하는 쪽에 위치한다.

정적 링크된 모노리틱 구조의 실행 파일이라도 규칙적인 방식으로 구조를 분리하면 프로젝트를 개발, 테스트, 배포하는 작업에 큰 도움이 된다.

단일체에서 컴포넌트간 통신은 전형적인 함수 호출에 지나지 않으므로 매우 빠르고 값싸며, 이러한 이유로 소스 수준에서 결합이 분리되면 경계를 가로지르는 통신은 상당히 빈번할 수 있다.

배포형 컴포넌트

아키텍처의 경계가 물리적으로 드러날 수도 있는데 그중 가장 단순한 형태는 동적 링크 라이브러리다.

이는 배포 수준 결합 분리 모드에 해당하며 컴포넌트를 동적 링크 라이브러리 형태로 배포하면 따로 컴파일하지 않고 곧바로 사용할 수 있는 대신 바이너리와 같이 배포 가능한 형태로 전달된다.

배포 관점에서 이러한 형태는 단순히 배포 가능한 단위를 좀 더 편리한 형태로 묶으므로, 단일체와 동일하다.

• 모든 함수가 동일한 프로세서와 주소 공간에 위치하며, 컴포넌트 간 의존성을 관리하는 전략도 동일하다.

단일체와 마찬가지로 경계를 가로지르는 통신은 함수 호출에 지나지 않으므로 값싸기 때문에, 경계를 가로지르는 통신은 대체로 매우 빈번하다.

스레드

스레드는 아키텍처 경계도 아니며 배포 단위도 아니다.

단일체와 배포형 컴포넌트 모두 스레드를 활용할 수 있다.

스레드는 실행 계획과 순서를 체계화 하는 방법에 가까우며, 모든 스레드가 단 하나의 컴포넌트에 포함될 수도 있고, 분산될 수도 있다.

로컬 프로세스

로컬 프로세스는 이전 언급한 경계보다 훨씬 강한 물리적 형태를 띈다.

주로 명령행이나 그와 유사한 시스템 호출을 통해 생성되고, 동일한 프로세서 또는 하나의 멀티코어 시스템에 속한 여러 프로세서들에서 실행되지만, 독립된 주소 공간에서 실행된다.

종종 공유 메모리 파티션을 사용하기도 하지만, 일반적으로는 메모리 보호를 통해 프로세스들이 메모리를 공유하지 못하게 한다.

대개의 경우 소켓, 메일박스, 메시지 큐와 같이 운영체제에서 제공하는 통신 기능을 이용하여 서로 통신한다.

각 로컬 프로세스는 정적으로 링크된 단일체 이거나 동적으로 링크된 여러개의 컴포넌트로 구성될 수 있다.

• 정적으로 링크된 단일체
  • 여러 모노리틱 프로세스가 같은 컴포넌트들을 가지고 있을 수 있다.
  • 컴파일하고 정적 링크하는 과정에서 각 컴포넌트의 바이너리가 단일체에 물리적으로 복사되기때문
• 동적으로 링크된 배포형 컴포넌트
  • 동적으로 링크된 배포형 컴포넌트들을 서로 공유할 수 있다.

로컬 프로세스는 컴포넌트 간 의존성을 동적 다형성을 통해 관리하는 저수준 컴포넌트로 구성되므로 일종의 최상위 컴포넌트로 볼 수 있다.

로컬 프로세스 간 분리 전략은 단일체나 바이너리 컴포넌트의 경우와 동일하다.

소스 코드 의존성은 고수준 컴포넌트를 향해야하므로 로컬 프로세스에서는 고수준 프로세스의 소스 코드가 저수준 프로세스의 이름, 물리 주소, 레지스트리 조회 키를 절대로 포함해서는 안된다.

로컬 프로세스 경계를 지나는 통신에는 운영체제 호출, 데이터 마샬링, 언마샬링, 프로세스 간 문맥 교환 등이 있으며, 이들은 제법 비싼 작업이므로 통신이 너무 빈번하게 이뤄지지 않도록 신중하게 제한해야한다.

서비스

물리적인 형태를 띠는 가장 강력한 경계는 서비스다.

서비스는 프로세스로, 일반적으로 명령행 또는 그와 동등한 시스템 호출을 통해 구동된다.

서비스들은 모든 통신이 네트워크를 통해 이뤄진다고 가정하므로 자신의 물리적 위치에 구애받지 않는다.

서비스 경계를 지나는 통신은 함수 호출에 매우 느리므로 가능하다면 빈번하게 통신하는 일을 피해야 하며, 지연(latency)에 따른 문제를 고수준에서 처리할 수 있어야 한다.

이를 제외하고는 로컬 프로세스에 적용한 규칙이 서비스에 적용된다.

저수준 서비스는 반드시 고수준 서비스에 플러그인되어야하며, 고수준 서비스의 소스 코드에는 저수준 서비스를 특정 짓는 어떤 물리적인 정보(URI 등)도 절대로 포함해서는 안된다.

결론

단일체를 제외한 대다수의 시스템은 한 가지 이상의 경계 전략을 사용한다.

실제로 서비스는 상호작용하는 일련의 로컬 프로세스 퍼사드에 불과할 때가 많다.

또한 개별 서비스 또는 로컬 프로세스는 거의 언제나 소스 코드 컴포넌트로 구성된 단일체이거나, 동적으로 링크된 배포형 컴포넌트의 집합이다.

즉, 한 시스템 안에서도 통신이 빈번한 로컬 경계와 지연을 중요하게 고려해야 하는 경계가 혼합되어 있음을 의미한다.