[소프트웨어 아키텍처 101] 12. 마이크로커널 아키텍처 스타일

인상깊은 부분

보험 청구처럼 비즈니스 케이스가 복잡한 경우에도 사용이 용이하겠다

---

요약

• 마이크로커널 아키텍처(microkernel architecture) 혹은 플러그인 아키텍처(plug-in architechture)
  • 제품 기반 어플리케이션(단일 모놀리식 배포 단위로 패키징해서 다운로드 및 설치가 가능하며, 보통 고객 사이트에서 서드파티 제품으로 설치되는)에 적합
  • 비제품(nonproduct) 고객 비즈니스 어플리케이션에서도 많이 사용
  • 예시) IDE와 같은 텍스트 에디터
  • 예시) Payment Processing이 코어 시스템을 나타내는 도메인이라면, 결제 수단(신용카드, 페이팔, 선불 카드 등)이 플러그인 컴포넌트

12.1 토폴로지

마이크로커널 아키텍처 스타일은 코어 시스템과 플러그인 컴포넌트라는 두 가지 아키텍처 요소로 구성된 모놀리식 아키텍처

• 코어 시스템
  • 시스템을 실행시키는 데 필요한 최소한의 기능으로 정의
  • 규모와 복잡도에 따라 레이어드 아키텍처나 모듈러 모놀리스로 구현 가능하며, 전체 모놀리스 어플리케이션은 하나의 데이터베이스를 공유하는 것이 보통임
  • 순환 복잡도를 없애고 별도의 플러그인 컴포넌트를 통해 확장성, 유지보수성, 시험성을 가질 수 있음
• 플러그인 컴포넌트
  • 플러그인 컴포넌트란?
    • 특수한 처리, 부가 기능, 그리고 코어 시스템을 개선/확장하기 위한 커스텀 코드가 구현된 스탠드얼론 컴포넌트
    • 변동성이 매우 큰 코드를 분리하여 어플리케이션 내부의 유지보수성, 시험성을 높임.클라이언트에 종속된 코드를 각 전자 제품마다 플러그인 컴포넌트를 따로 제작 (코어에 두면 순환복잡도가 높아지기 때문)
    • 이상적인 플러그인 컴포넌트는 상호독립적이며 의존성이 없음
  • 통신 방식 (점대점 통신 or 원격 액세스)
    • 플러그인 컴포넌트와 코어 시스템은 일반적으로 점대점(point-to-point) 통신
    • 하지만 REST나 메시징 등 다른 방법으로 기능 호출하는 방법도 있음. 플러그인 컴포넌트를 개별 서비스로 구현해서 원격 액세스하는 방법은 전체 컴포넌트의 커플링이 낮아져 성과 처리량이 개선되고, 런타임 변경이 가능하다는 장점이 있음. 비동기 통신도 가능하므로 경우에 따라 전체 유저 반응성을 엄청나게 끌어올릴 수 있음
    • 하지만 위와 같은 원격 통신은 전체 확장성을 개선하는 좋은 방법 같지만, 이 토폴로지는 코어 시스템이 모놀리식이므로 여전히 단일 아키텍처 퀀텀임. 즉, 모든 요청이 무조건 코어 시스템을 거쳐 각 플러그인 서비스로 호출하는 구조
    • 개별 서비스로 구현 시 마이크로커널 아키텍처를 모놀리식이 아닌 분산 아키텍처로 바꿔야함
      • 이 경우, 대부분의 서드파티 온프렘 제품은 그렇게 구현/배포하기가 쉽지 않고 전반적으로 복잡도와 비용이 높아져 전체 배포 포톨리지가 상당히 난해해짐
      • 플러그인이 무응답이거나 작동하지 않는 경우 (특히 REST 사용 시) 요청은 완료될 수 없음 (모놀리식이었다면 이런 일은 없을 것)

12.2 레지스트리

• 플러그인 레지스트리 : 코어시스템이 어떤 플러그인을 사용할 수 있는지, 그 플러그인을 가져오려면 어떻게 해야하는 지 알기 위해 사용하는 일반적인 구현 방법 중 하나
• 플러그인 레지스트리에 담긴 정보
  • 플러그인 명칭
  • 데이터 계약
  • 플러그인에서 코어 시스템으로 접속하는 방법과 원격 액세스 프로토콜 정보

12.3 계약

• 코어 시스템과 플러그인 컴포넌트 간의 계약
  • 보통 플러그인 컴포넌트의 도메인 단위로 표준화되어 있고, 플러그인 컴포넌트가 수행하는 기능 및 입출력 데이터가 계약에 명시되어 있음
  • 일반적으로 컹 시스템이 각 플러그인별 코드를 필요로 하지 않도록 플러그인 계약과 우리가 저한 표준 계약 간의 어댑터를 만듬

12.4 실제 용례

• 이클립스 IDE, 인터넷 웹 브라우저
• 대규모 비즈니스 어플리케이션에도 적용 가능
  • ex) 보험금 청구 처리 어플리케이션
    • 대부분 아주 크고 복잡한 규칙 엔진을 이용해서 복잡한 로직을 처리하지만, 자칫 이 규칙 엔진이 진흙잡탕이 되어 규칙 하나를 변경하면 다른 규칙들이 연쇄적으로 영향을 받거나, 단순한 규칙 하나를 바꾸려해도 여러 직군이 모여 검토하는 과정을 거쳐야함
    • 이런 경우 마이크로커널 아키텍처 패턴을 활용할 수 있음
    • 관할 구역별 보험금 청구 규칙을 별도의 스탠드얼론 플러그인 컴포넌트에 보관하는 것임. 그러면 다른 시스템 파트에 영향을 주지 않고 특정 관할 구역의 규칙을 추가, 삭제, 변경할 수 있음. 그리고 관할 구역을 새로 추가하거나 기존 관할 구혁을 삭제해도 다른 시스템 파트에는 영향이 없음. 코어 시스템은 바뀔 일이 거의 없는, 청구건을 접수 받아 처리하는 표준 프로세스가 될 것임

12.5 아키텍처 특성 등급

• 마이크로커널 아키텍처도 레이어드 아키텍처처럼 단순성과 전체 비용이 주요 강점임. 반면, 고질적인 모놀리식 배포 탓에 탄력성, 내고장성, 확장성이 문제가 될 때가 많음. 퀀텀 수는 언제나 1. 레이어드 아키텍처 스타일과의 유사성은 여기까지
• 위치나 클라이언트에 따라 설정이 달라지는 문제는 이 아키텍처가 제격
• 커스터마이징, 기능 신장성에 중점을 둔 제품도 이 아키텍처가 제격

아키텍처 특성	별점	설명
분할 유형	도메인 및 기술	도메인 분할과 기술 분할이 모두 가능한 유일한 아키텍처 스타일
퀀텀 수	1	모든 요청은 코어시스템을 통해 유입되어 독립적인 플러그인 컴포넌트로 흘러가므로 퀀텀은 언제나 1
배포성	⭐️⭐️⭐️	기능을 독립적인 플러그인 컴포넌트로 분리 가능하므로 평균(별3)보다 약간 높게 매김. 잘 분할하면 변경분에 대한 테스트 범위와 배포 리스크가 줄어듬
탄력성	⭐️	모놀리식 배포탓에 탄력성 낮음
진화성	⭐️⭐️⭐️	-
내고장성	⭐️	모놀리식 배포탓에 내고장성 낮음
모듈성	⭐️⭐️⭐️	플러그인 컴포넌트를 통해 기능을 추가, 삭제, 변경할 수 있고, 덕분에 어플리케이션 개선/확장 작업이 비교적 용이해 팀 차원에서 더욱 신속하게 변경에 대응할 수 있다는 점 때문에 평균(별3)보다 조금 높게 측정
전체 비용	⭐️⭐️⭐️⭐️⭐️	굿굿!! 주요 강점
성능	⭐️⭐️⭐️	애매하지만 평균(별3)보다 약간 높게 측정 이 아키텍처는 대부분 규모가 작으며, 레이어드 아키텍처처럼 갈수록 커지지 않기 때문임. 또 아키텍처 싱크홀 안티패턴으로 고생할 필요도 없고 불필요한 기능은 해제하여 처리 흐름을 간소화할 수 있음
신뢰성	⭐️⭐️⭐️	기능을 독립적인 플러그인 컴포넌트로 분리 가능하므로 평균(별3)보다 약간 높게 매김. 잘 분할하면 변경분에 대한 테스트 범위와 배포 리스크가 줄어듬
확장성	⭐️	모놀리식 배포탓에 확장성 낮음
단순성	⭐️⭐️⭐️⭐️	굿굿!! 주요 강점
시험성	⭐️⭐️⭐️	기능을 독립적인 플러그인 컴포넌트로 분리 가능하므로 평균(별3)보다 약간 높게 매김. 잘 분할하면 변경분에 대한 테스트 범위와 배포 리스크가 줄어듬