[데이터넷] 최신 애플리케이션 소프트웨어 아키텍처에는 새로운 API의 설계 및 제공이 필요하다. 이러한 API는 데이터 및 기능을 사용해 애플리케이션 구성, 고객 대면 경험, 시스템 및 파트너 통합 요구 사항 및 기타 많은 사용 사례를 지원한다. 각 API는 구현이 필요한 인터페이스의 정의인데, 가트너에서는 이러한 API를 구현하고 지원하는 서비스에 대한 최적의 아키텍처를 선택할 수 있도록 하기 위해 결정 포인트를 정의했다. <편집자>

- 연재 순서 - 1. 제임스 루이스와 마틴 파울러의 MSA 2. 처음부터 MSA로 시작하는 것은 위험하다 3. 서비스 메시와 아키텍처 결정 포인트(이번호) 4. MSA와 애플리케이션 현대화

가트너는 2018년에 내부 아키텍처와 외부 아키텍처로 구성된 ‘마이크로서비스 아키텍처(MSA) 컴포넌트’를 발표했다. 내부 아키텍처는 마이크로서비스 시스템 및 데이터베이스 구성을 어떻게 하고, 마이크로서비스를 어떻게 API화할지 등에 대한 아키텍처이며, 일반적으로 애플리케이션 현대화를 위한 아키텍처라 할 수 있다.

이에 비해 외부 아키텍처는 외부에서 인입되는 API 요청을 어떻게 잘 서비스할 지를 정의하는 아키텍처이며, API 게이트웨이, 서비스 메시, 컨테이너 관리, 지원 서비스(Backing Services), 원격측정(Telemetry), CI/CD 자동화 등을 정의하고 있다.

서비스 메시
마이크로서비스 기반의 애플리케이션을 개발하고 서비스 메시를 구현하는데 있어 소스코드와 서비스 메시를 구현하는 코드가 얼마나 밀접하게 엮여있는지에 따라 세 가지 유형으로 분류할 수 있다.

기존에는 애플리케이션 소스코드에 서비스 메시를 위한 코드를 삽입하는 방식이었으나 최근에는 기존의 서비스와 독립적인 서비스 메시를 위한 별도의 프록시 서비스 구현 방식으로 발전하고 있다. 이러한 서비스 메시 구성 방식에 따른 차이점을 살펴보면 다음과 같다.

API 게이트웨이와 서비스 메시가 하는 일은 라우팅, 인증, 모니터링, 서비스 검색, 서비스 등록 등으로 동일하지만 외부에 노출되는 것과 작동 위치에서 차이점이 있다. API 게이트웨이의 적용 위치는 클라이언트 투 서버이고 외부 노출이 되지만, 서비스 메시의 적용 위치는 서버 투 서버로 외부 노출은 없다. 서비스 메시와 API 게이트웨이는 동작 위치, 라우팅, 핵심 기능, 장애 발생, 분석, 구현 방식 관점에서 다음과 같은 차이점이 존재한다.

컨테이너 오케스트레이션
컨테이너 오케스트레이션이란 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 기술을 말한다. 애플리케이션 운영을 위해 컨테이너를 배포하고 구성하는 것을 말하며 컨테이너 오케스트레이션 도구를 통해 수행한다. 컨테이너 오케스트레이션 도구는 컨테이너와 MSA를 규모에 따라 관리할 프레임워크를 제공한다. 컨테이너 라이프사이클 관리에 사용할 수 있는 컨테이너 오케스트레이션 도구는 다양하며, 그중 쿠버네티스, 도커 스웜, 아파치 메소스(Mesos)가 널리 사용된다.

• 쿠버네티스: 대형 규모, 세밀하고 다양한 설정 기능이 필요한 경우에 적합
  - 구글에서 오픈소스로 공개한 컨테이너 오케스트레이션 플랫폼
  - 도커와 별도의 솔루션으로 제공됐지만 CNCF 재단에 소스 이관 후 도커 엔진에 포함
  - 베어메탈, VM, 퍼블릭 클라우드 등 다양한 환경에 적용됨
  - 대규모 컨테이너 서비스 배포 및 관리에 장점
  - 다양한 생태계가 구축돼 있음

• 도커 스웜: 중소형 규모, 관리할 서버가 적고, 많은 기능이 필요하지 않은 경우에 적합
  - 도커에서 공식적으로 만든 오케스트레이션 도구
  - 여러 개의 도커 호스트를 클러스터링해 단일 가상 도커 호스트를 구성하는 단순한 구조에 효과적
  - 호스트 OS에 에이전트만 설치하면 간단하게 작동해 설정이 쉽고 에이전트를 외부에 설치하지 않음
  - 도커 명령어 및 도커 컴포즈를 그대로 사용하는 쉬운 접근 용이성

• 아파치 메소스: 초대형, 수천 개의 확장, 호스트와 랙에 대한 관리 필요시 적합
  - 대규모 클러스터 관리 플랫폼
  - 리눅스 컨트롤 그룹을 사용해 CPU, IO, 파일 시스템, 메모리 격리를 제공
  - 분산된 시스템 커널 또는 프레임워크에 컴퓨터 자원을 공급하는 클러스터 플랫폼
  - 하둡, 카프카 및 스파크와 같은 다른 오픈소스 서비스와 함께 애플리케이션을 배치해야 하는 환경에 용이

CI/CD 파이프라인
CI/CD는 반복적인 개발, 테스트, 배포 과정에 대한 자동화와 모니터링을 제공하는 도구 기반 프로세스로 애플리케이션 개발 단계를 자동화해 보다 짧은 주기로 제공하는 것을 목적으로 한다.

CI는 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 지속적으로 통합하는 것이고, CD는 지속적인 서비스 제공 또는 배포를 의미한다. CI/CD는 애플리케이션의 개발, 테스트 및 배포에 이르는 라이프 사이클에 걸쳐 자동화를 제공해 CI/CD 파이프라인이라 불리고 있다.

API·서비스 구현 아키텍처 결정 포인트
MSA에서 API를 제공하는 것은 유연한 분산 애플리케이션 및 통합의 핵심이지만, 이를 위한 다양한 아키텍처가 존재한다. 가트너는 ‘API 및 서비스 구현 아키텍처를 위한 의사결정점(Decision Point for API and Service Implementation Architecture)’을 발표하고, API 및 서비스 설계를 담당하는 애플리케이션 전문가들이 각 서비스에 가장 적합한 아키텍처를 선택할 수 있도록, 결정 포인트를 정의했다. 이를 위한 주요 관심 사항은 다음과 같다.

- 최신 애플리케이션 제공은 본질적으로 서비스 지향적이다. 최신 애플리케이션은 여러 세분화된 다양한 서비스로 구성되며 공개 또는 비공개 중재 API(mediated API)를 통해 노출된다.
- API 및 서비스를 제공하는 팀은 구현 아키텍처와 서비스 그래뉼러티(granularities)를 혼합하여 사용하고 복잡성, 기능 및 제공 비용의 균형을 유지해야 한다.
- 레스트(REST) 및 기타 스타일을 포함한 API는 기존 애플리케이션 및 데이터와의 통합이든 새로 개발된 소프트웨어든 관계없이 기본 구현 아키텍처에서 소비자를 추상화해야 한다.
- MSA는 오랫동안 확립된 서비스 지향 아키텍처(SOA) 원칙을 기반으로 하지만 항상 API 및 서비스를 위한 최상의 서비스 구현 아키텍처는 아니다.

API와 이를 구현하는 서비스는 최신 애플리케이션 제공에 매우 중요하다. 애플리케이션 서비스는 애플리케이션의 비즈니스 논리와 데이터 지속성을 분해 및 캡슐화해 소스 시스템과 소비자 간의 추상화를 제공한다.

이를 통해 애플리케이션 기능을 제공하고 레스트, 그래프QL, gRPC, 웹훅(Webhooks) 또는 아파치 카프카를 포함할 수 있는 교차 플랫폼 인터페이스를 통해 데이터에 액세스할 수 있다. 그런 다음 이러한 인터페이스를 소프트웨어 구성, 자동화 및 개발 도구와 함께 사용해 비즈니스 요구 사항을 충족할 수 있다.

그러나 서비스 지향을 위해 API 및 서비스를 빌드해서는 안 된다. 모든 경우에 API와 서비스는 가치를 제공하는 비즈니스 요구를 충족해야 한다. 서비스 구현은 다음을 포함해 다양한 시나리오를 동시에 지원할 수 있다.

- B2B 통합을 지원하기 위해 외부 API 게시(공개 또는 비공개)
- 시스템 통합, 구성 및 데이터 배포를 지원하는 내부 API 게시
- 모바일, 웹, 채팅 및 음성을 포함한 다중 경험 고객 및 직원 앱 제공
- 코드가 적거나 없는 개발 플랫폼을 사용해 전술적 애플리케이션 제공 가능
- 비즈니스 민첩성과 유연성을 지원하는 애플리케이션 현대화
- 클라우드 플랫폼으로 애플리케이션 마이그레이션 비즈니스 프로세스 관리(BPM) 및 로봇 프로세스 자동화(RPA) 통합을 통한 프로세스 자동화 및 최적화

이러한 예는 모두 비즈니스 애플리케이션, 프로세스 및 솔루션을 생성할 수 있다는 공통 목표를 가지고 있다. 컴포지션은 프로그래밍 방식으로 서비스를 호출, 소비 또는 액세스할 수 있는 인터페이스인 API를 통해 애플리케이션 서비스 및 데이터 소스에 액세스해야 한다. API가 HTTP를 사용하는 ‘웹 API’이든 다른 프로토콜과 기술을 사용하든 관계없이 API 소비자를 중심으로 설계하고 관리해야 한다.

API는 개발자와 자체 애플리케이션, 지원 및 운영이 의존할 수 있는 기술 및 운영 계약이 있는 제품 또는 플랫폼으로 관리돼야 한다. API는 이를 구현하는 서비스를 캡슐화해 서비스 소비자와 서비스 공급자의 문제를 분리해야 한다.

모든 경우에 서비스를 소비자에게 노출하는 API는 API 게이트웨이 또는 API 관리 솔루션을 사용해 적절한 정책으로 조정되고 관리돼야 한다.

특히 API 중심 접근 방식을 채택할 때 서비스 지향 아키텍처(SOA)를 구축하고 있음을 인식해야 하며, API를 제공하기 위해 서비스를 구현할 때 SOA의 다음 원칙이 여전히 적용되고 따라야 하는 것이 중요하다.

• 서비스 지향: 개별 시스템 기능을 여러 소비자가 사용할 수 있는 기술 자산으로 캡슐화

• 관심사 분리: 소프트웨어 시스템의 여러 측면을 분리해 서로 다른 속도로 변경될 수 있도록 함

• 느슨한 결합: 시스템 구성 요소 간의 종속성을 줄여 하나의 변경 사항이 다른 구성 요소에 부정적인 영향을 주지 않도록 함

애플리케이션 서비스 아키텍처 대안
서비스를 노출하는 성공적인 API를 설계하기 위한 유일한 효과적인 접근 방식은 API 소비자 중심의 인터페이스 우선 접근 방식을 취하고, API 설계와 서비스 구현 간의 느슨한 결합을 준수하는 것이다. 이 접근 방식을 사용하면 각 서비스 유형에 가장 적합한 아키텍처를 선택해 다양한 아키텍처를 사용하여 API 이면에 있는 서비스를 유연하게 구축할 수 있다. 또 API 정의와 독립적으로 서비스 구현을 변경할 수 있는 유연성도 있다.

게시된 API와 서비스 구현의 이러한 분리는 ‘중재 API’ 아키텍처 패턴을 사용해 가장 잘 구현된다. 이를 통해 서비스에서 API를 분리할 수 있을 뿐만 아니라 애플리케이션 로직에서 런타임 액세스 정책을 분리할 수도 있다.

새로운 애플리케이션 서비스를 주도하는 비즈니스 요구 사항의 다양성은 이러한 아키텍처 중 하나 이상을 사용해 서비스를 구현해야 함을 의미한다. 구현할 유사한 애플리케이션 서비스의 새 클래스 또는 클러스터가 있을 경우, 대체 아키텍처를 보여준다.

• 데이터 서비스 아키텍처: 데이터 서비스 프레임워크 또는 데이터 가상화 도구를 사용해 서비스 인터페이스를 통해 기존 데이터 제품(데이터베이스, 캐시, 데이터 웨어하우스, 데이터 레이크 또는 기타 저장소에 저장된 데이터)을 구성하고 노출

• 서비스 통합 아키텍처: 복합 서비스를 생성하기 위해 기존 서비스와 데이터를 구성, 연결 및 통합하기 위한 선언적 모델을 제공하는 통합 플랫폼을 사용. 여기에는 현대화를 향한 단계로 기존 애플리케이션을 활성화하고 캡슐화하는 서비스가 포함됨

• 스트리밍 아키텍처: 스트림 지향 모델을 사용해 하나 이상의 소스에서 이벤트 데이터를 수집 또는 노출하고 이를 하나 이상의 대상(싱크)에 배포하는 스트리밍 플랫폼 및 반응형 프로그래밍 프레임워크를 사용

• 대략적인 서비스 아키텍처: 대략적인 기능을 구현하는 새로운 서비스를 개발하고 여러 서비스를 단일 제공 단위로 묶거나 서비스를 기존 애플리케이션에 구축해 기능을 캡슐화하고 표시. 이러한 기능은 일반적으로 여러 서비스 구현을 대략적인 배포로 번들링하도록 권장하는 성숙한 애플리케이션 프레임워크 및 서버 플랫폼을 사용하는 레스트를 통해 노출됨

• MSA: 애플리케이션 기능을 긴밀한 범위의 독립적으로 개발·배포된 마이크로서비스로 분해·격리하는 새로운 서비스를 개발

서비스 구현 아키텍처를 선택할 때 최적의 결정을 내리기 위해 다양한 기능적 기준과 비기능적 기준의 균형을 맞춰야 한다. 이 결정 포인트에 대한 평가 기준은 새로운 애플리케이션 인프라 배포와 관련된 기능 요구 사항 및 제약 조건을 제외한다.

예를 들어 기준은 비용, 조달 시간 및 필요할 수 있는 새로운 애플리케이션 플랫폼 기술에 대한 배포 노력을 고려할 수 없다. 이러한 항목은 매우 다양하기 때문이다. 이러한 유형의 제약이 있는 팀은 새로운 플랫폼 기능의 이점을 누릴 수 있는 반복적인 기회가 있는지 평가하고 단기 프로젝트 수요 이외의 기능을 구현하기 위한 비즈니스 사례를 구축해야 한다.

애플리케이션 서비스에 가장 적합한 구현 아키텍처를 선택하려면 다음 기능 기준을 사용해야 한다.

- 기존 데이터 자산 노출 및/또는 결합
- 기존 애플리케이션 자산 액세스 및/또는 구성
- 복합 서비스 구현
- 무한한 데이터 및 이벤트 스트림 처리
- 제공 민첩성 지원(민첩한 CI/CD 및 데브옵스)
- 서비스 구현 속도 활성화
- 현대화된 애플리케이션 인프라 필요

[그림 5]는 설계자가 주어진 비기능적 요구 사항 집합에 대해 적절한 아키텍처를 선택할 수 있도록 의사결정 프로세스가 의사결정 흐름에 요약돼 있다.

[그림 5]의 왼쪽 상단에서부터 결정 흐름을 사용해 평가 중인 애플리케이션 서비스 요구 사항 집합에 대한 옵션을 Yes/No 결과에 따라 따라간다. 의사결정 흐름은 요구 사항 및 제약 조건에 대한 가중치를 고려하지 않지만, 각 아키텍처의 적합성에 영향을 미치는 중요한 기준을 기반으로 명확한 방향을 제공하는 것을 목표로 한다. 의사결정 흐름은 초기에 기존 자산을 활용해 결정을 내리도록 구성됐다. 이러한 흐름은 데이터 서비스 아키텍처 및 서비스 통합 아키텍처 결정으로 이어진다.

특정 프로젝트 또는 제품 제공 내에서 다양한 API 및 서비스에 적합한 아키텍처를 식별하려면 결정 포인트를 여러 번 사용하기 바란다. 마지막화가 될 다음호에서는 국내의 금융 또는 공공의 모놀리식 레거시 애플리케이션을 현대화하는 방안에 대해 함께 살펴보기로 하겠다.