[조대협 대용량 아키텍처] 대용량 서비스 레퍼런스 아키텍처

대용량 서비스 레퍼런스 아키텍처

이번에는 대용량 서비스를 하는 플랫폼에 적용되는 레퍼런스 아키텍처에 대해 알아보자.

이전에 포스팅한 MSA(Micro Service Architecture)와 같은 아키텍처들은 논리적인 아키텍처였다면, 이 아키텍처는 솔루션을 맵핑한 조금 더 구체적인 아키텍처이다.

 

아키텍처의 구조

대용량 서비스 레퍼런스 아키텍처는 사상적으로 SOA(Service Oriented  Architecture)를 기반으로 한다.

 

출처 : https://www.slideshare.net/Byungwook/4-61487454

위의 아키텍처 구조는 대용량 처리 서비스와 대부분의 온라인 서비스에서 모두 사용되는 구조이다.

시스템의 성격에 따라 구조의 변형은 조금씩 있을 수 있으나, 기본적인 형태는 유지된다.

 

또한, 기본적으로 플랫폼의 형태를 띄고 있는데, UI에 해당하는 웹 사이트, 모바일 어플리케이션들이 API를 사용하여 서버 플랫폼과 통신하여 비즈니스 로직을 처리한다.

서버에서 트랜잭션을 처리하기 위해 3가지 계층을 거치는데(Access Layer, Business Layer, Persistent Layer), 이 3가지 계층은 요청에 따른 비즈니스 로직을 처리하고 저장한다.

 

먼저 각 레이어 별 역할에 대해 자세히 설명하겠다.

 

1. Access Layer

Access Layer에서 처리하는 기능은 웹 캐시, Reverse Proxy, API Gateway, 계정 관리, 시스템 연동 등이 있디.

일반적으로 클라이언트로부터 들어오는 사용자 요청을 처음으로 받는 계층으로, 사용자 요청에 대하여 사용자 인증, 권한 인증을 수행하여 뒷단의 비즈니스 로직으로 전달하는 역할을 한다.

 

웹 캐시

제일 앞단에 위치하게 되는 계층이며, 웹에서 사용되는 정적인 자원과 자바스크립트, 이미지, HTML 등을 캐싱한다. 

이 계층이 존재하는 것만으로도 전체 시스템의 부하를 많이 줄일 수 있다. 

만약, 서비스 지역이 넓게 분포되어 있다면 CDN(Contents Delivery Network)를 이용하는데, CDN는 분산 웹 캐싱 서비스로 전 세계의 엣지 서버(웹 캐시 서버)를 분포시켜 콘텐츠의 로딩 타임을 크게 줄일 수 있다.

(이전에는 전문 CDN 업체에서 계약을 통해 시스템을 연동했지만, 요즘에는 클라우드에서 CDN서비스를 이용할 수 있다.)

 

Reverse Proxy

웹 캐시와 함께 앞단에 위치되는 Reverse Prorxy에는 대표적으로 Apache httpd, Nginx, HAProxy 등이 있다. 웹 서버의 역할과 정적 콘텐츠에 대한 서비스를 제공하며 필요시에는 HTTP 요청에 대한 인층 처리도 한다.

기본적으로 HTTP 헤더 내용을 보고 인증을 처리하는데, 인증 여부를 판단하여 요청을 뒤로 넘길지 정한다.

(위의 인증은 Reverse Proxy 계층에서도 할 수 있지만, 뒷단의 ESB 혹은 비즈니스 컴포넌트에서도 처리할 수 있다.)

 

개별 비즈니스 컴포넌트에서 인증 처리할 때는 분산형 인증 처리가 되기 때문에 하나의 비즈니스 컴포넌트에서 인정한 정보를 다른 비즈니스 컴포넌트에서 인지할 수 있어야 한다. 이 경우에 SSO(Single Sign On)라는 기술을 사용한다.

SSO는 예를들어, 네이버에 로그인 한 뒤 네이버 카페나, 네이버 블로그에 별도의 로그인 없이 인증가능 한 경우에 사용된다.

 

또한, 뒷단의 비즈니스 로직을 처리하기 위해 컴포넌트로 라우팅하는 역할을 한다. 만약 뒷단의 비즈니스 로직이 아파치 톰캣 기반의 서블릿으로 구성되어 있다면, 여러개의 톰캣 인스턴스에 요청을 밸런싱하는 역할을 한다.

 

API Gateway

API Gateway는 시스템에 따라 API Gateway 솔루션을 사용하거나, ESB(Enterprise Service Bus)를 사용할 수 있다. 

ESB는 API Gateway의 기능뿐 아니라 레거시 시스템과 다른 프로토콜을 커버할 수 있는 장점이 있으며,

API Gateway 솔루션을 사용한다면 Rest API처리에 최적화가 잘 되어 있고 ESB에 대해 군더더기가 작다는 특징이 있다.

 

보통은 여기에 사용자 패턴 분석과 API 키 발급 및 API 스펙 문서 등 부가적인 기능을 API Gateway와 함께 묶어 API 플랫폼이라고 부른다.

 

이 API Gateway가 가지는 기능을 조금 더 자세히 알아보자.

 

1. API 인증 처리와 API 키 관리

API를 사용하기 위해서는 API를 호출하는 클라이언트가 인증이 된 사용자인지 아닌지 구분하는 인증(Authemtication) 기능이 필요하다.

인증을 하는 기능으로는 API 키를 발급하거나 OAuth 기반 인증을 하는 방식이 있는데, API 플랫봄은 보통 OAuth 기반 인증을 제공한다.

 

위의 인증을 통해서 API 키를 생성하는데, 대부분의 API는 이 키를 통한 인증방식을 사용한다.(이 키를 API token이라고도 함)

API Gateway는 이 키를 발급부터 파기까지 전체 생명주기를 관리한다.

 

2. 로드 밸런싱

API Gateway는 자체적으로 API 서버들에 대한 로드 밸런싱 기능을 가진다. 뒷단에 여러개의 API 서버들이 존재할 때, 단일 엔드포인트에서 여러개의 API 서버로 부하를 분산한다.

 

3. 공통 기능 처리

API 서버들이 가지는 공통 기능(API 로그 처리, 인증 처리)을 API Gateway가 처리해줄 수 있다. 만약 API Gateway가 없는 아키텍처에서는 이러한 기능들을 API 서버에 배포해야한다. 이때, 공통 기능이 변경한다면 서버를 다시 배포해야하는 문제가 발생할 수 있다. API Gateway를 사용한다면 이러한 번거로움을 없앨 수 있으며, 변경사항 발생시에는 해당 API Gateway 부분만 재 배포하면 된다.

 

4. 다수의 엔드 포인트 제공

같은 API라도 API Gateway를 이용하면 다수의 엔드포인트(URL)로 API를 제공할 수 있다. 

쉽게 말해 API Gateway를 통해 클라이언트별로 다른 URL로 API를 제공할 수 있다.

 

이 기능에 더불어 사용하는 것이 각 엔드포엔트별로 특성을 부여할 수 있는데, 예를들어 특정 엔드포인트에 대한 IP 요청을 제한하고, Mutual SSL을 적용하고 다른 엔드포엔트에서는 HTTP에 있는 API 토큰(키)를 이용하여 인증을 진행하는 등의 설정을 엔드포인트별로  구현할 수 있다.

 

5. 개발자 포털

API를 외부로 서비프 할 때, 개발자와 소통할 수 있는 인터페이스를 개발자 포털이라고 한다. 

구글 API, 페이스북 API를 보면 API에 대한 사용 가이드를 볼 수 있는 사이트가 있는데, 이러한 사이트를 개발자 포털 사이트라고 한다.

개발자 포털이 제공하는 기능으로는 다음이 있다.

 

토큰 발급 - 개발자가 이 포털에 로그인해서 서비스를 등록하고 API 키를 발급 받을 수 있다.

API 모니터링 - 개발자가 API 사용량, 패턴 등의 통계자료를 확인 할 수 있다. 유료 API 경우 사용량에 대한 과금 지표와 연관되기에 중요할 수 있다.

API 매뉴얼 제공 - 가장 핵심적인 기능 중 하나라고, API를 사용하깅 위한 매뉴얼을 제공한다. (API 스펙, 각종 파라미터)

API 테스트 배드 제공 - 몇몇 개발자 포털에서는 API를 직접 포털에서 테스트할 수 있는 테스트 콘솔을 제공한다.

 

6. 변환 로직

다음으로 중요한 기능 중 하나인 API에 대한 변환이다. 변환을 하는 이유에는 여러가지가 있는데, 대표적으로 다음과 같다.

1. 프로토콜 변환 - HTTP 프로토콜 기반의 API를 TCP 기반의 API로 변환 할때 사용한다.

2. 메세지 변환 - JSON으로 되어있는 메세지를 XML로 변환 하거나 상호 메시지 포멧을 변환할 수 있다.

3. MEP 변환 - MEP(Message Exchange Pattern)  실제 API가 HTTP/REST가 아닌 MessageQ를 이용한 비동기 API일 경우, 요청시에 바로 반환하도록 동기형으로 변경하는 역할을 한다.

 

7. 서비스 버스

API Gateway에서 중앙 버스 개념이 없다면, 서비스 간의 연혜는 복잡한 그물 구조로 연계된다. 이렇게 되면 서로의 의존성을 파악하기 힘들어지는데, 중앙 API Gateway를 버스형태로 배치하면 통신 토폴로지를 단순화 할 수 있다.

 

8. 매시업(Mash Up)

매시업(혹은 Aggregation, Orchestration)은 여러개의 API를 묶어서 새로운 API를 만느는 기능이다. API Gateway에서 API를 만들어 그 안에서 다른 API를 호출하는 형태로 새로운 API를 만들 수 있다.

 

9. QoS 컨트롤

QoS는 Quality of Service를 말하며, API Gateway를 이용하여 API에 대한 호출을 통제하는 것을 의미한다. 예를들어 API 키별 호출 횟수를 제한하거나 특정 사용자에 대한 API 요청을 높은 우선순위로 처리하는 등의 제어가 가능하다.

 

계정 관리

거의 대부분의 서비스는 사용자 관리와 권한 인증에 대한 기능을 가지고 있다.

보통 시스템의 규모가 커지고 사용자의 종류가 많아지면 여러 시스템에서 공통된 계정체계를 사용하기 위해서 별로의 공통 컴포넌트가 필요한데, 이를 IDM(Identity Management System)이라고 한다.

 

계정관리의 주요 기능은 다음과 같다.

 

1. 사용자 관리

사용자 계정 정보와 신원에 대한 정보를 관리한다.

2. 사용자 계정 생명주기 관리

사용자 계정의 생성 부터 정지, 탈퇴까지 전반적인 생명주기를 관리한다.

3. 사용자 로그인 정보 관리

사용자의 로그인 계정과 비밀번호를 관리한다. 만약 부가적인 인증 방식을 사용한다면 인증서, 지문 정보등을 함께 저장한다.

4. 사용자 정보 관리

로그인 정보 이외의 부가적인 프로필 정보를 관리한다. 사용자의 이름, 조직, 주소, 이메일 등이 이에 해당한다.

5. 사용자 역할 관리

시스템에서 사용자가 다양한 역할(Role)을 가질 수 있다. 따라서 이에 대한 역할을 정의하고 역할과 사용자의 관계를 관리한다.

6. 계정 정보 프로비저닝

계정 정보가 변동 되었을 때, 이를 연계된 시스템에 맞게 전달해 주는 기능을 한다.

7. 접근 제어

특정 시스템에서 접근 권한에 따라 제어 수준을 정의하여 사용자 권한에 맞게 접근을 관리한다.

8. 사용자 인증 및 권한 인가 처리

사용자 인증 기능은 특정 시스템에 접근할시, 이 사용자가 맞는지를 계정과 비밀번호를 통해 체크하는 것을 인증이라고 하며, 그 사용자가 기능에 접근할 수 있는 권한이 있는지를 체크하는 것을 권한 인가라고 한다.

9. SSO

앞서 설명한, 한번의 로그인으로 다른 시스템을 사용할 수 있도록하는 Single Sign On 기능을 한다.

10. 감사와 리포팅

사용자의 접근 기록을 저장 및 조회하는 감사(Audit)와 사용자의 패턴을 분석하기 위해 각종 통계자료를 표나 그래프로 확인하는 리포팅(Reporting) 기능을 한다.

 

위의 기능들을 하는 계정 관리 모델은 시스템간의 연계에 따라 여러가지 모델로 나뉘어 질 수 있다.

개별 분산 모델 - 각각의 독립된 서비스가 다른 계정 시스템을 사용하는 경우

중양 집중형 모델 - 가장 바람직하지만 구축하기 가장 어려운 모델, 중앙 서비스가 중앙 집중화된 계정 관리 시스템을 사용하는 경우

패더레이션 모델(Federated) - 각 시스템이 별도의 계정 시스템을 사용하지만, 페더레이션을 통해 다른 계정을 연동하여 하나의 통합된 형태로 전체 시스템에 접근할 수 있는 구조

 

시스템 연동

통합 시스템(Intergration System)을 통해서 대외 시스템 연계를 하거나 대내 시스템 간의 연동을 수행 할 수 있다.

엔터 프라이즈 급에서는 EAI(Enterpise Application Intergration)이라는 아키텍처로 구현된다.

 

대외 시스템 통합은 기업 간의 거래를 정의하는데, 거래사별로 재무 명세를 전송하고 전송받거나, 협력 업체에 물품을 주문하는 등의 업무에 사용된다.

대내 시스템 통합은 내부 시스템 간의 업무를 통합하는 패턴으로 이루어 지는데, 인터넷 뱅킹에서 계좌 정보를 조회하거나 당행 계좌 간 이체를 하는 등의 실시간 거래가 많다.

 

 

출처 : https://javamaster.wordpress.com/category/architecture/eai-architecture/

위는 EAI 시스템의 아키텍처이다.

먼저 가장 기본적인 모듈인 인터페이스에 대해 살펴보자.

 

인터페이스

인터페이스 모듈은 시스템을 통합하는 부분에 대한 아키텍처이다.

 

1. Inbound(송신 시스템과 연동)

Inbound는 송신 시스템과 연동하여 요청을 받고 응답을 송신 시스템에 보내는 역할을 한다.

Inbound는 2가지의 모델로 구성된다. 

 

 - Adapter : 어뎁터는 다양한 플랫폼으로 부터 메세지를 읽어오는 진입점 역할을 한다. 주로 다른 기술의 프로토콜을 변환시키는 역할을 한다.

 - 메세지 변환 : 어댑터에 의해 요청된 메세지는 시스템 플랫폼 마다 다르다. 따라서 이런 데이터 메세지 형태를 공통적인 데이터 구조로 변환하는 역할을 한다. 

 

2. Mediation(메세지 가공)

입력된 메세지를 가공하고 중계하는 역할을 한다.

 

 - 라우팅 : 입력된 메세지를 내용에 따라 적절한 시스템으로 라우팅하는 역할을 수행한다.

 - 맵핑 : 입력된 메세지를 수신 시스템에서 요구하는 형태로 매핑하는 작업을 수행한다.

 - 메세지 교환 패턴 처리(MEP : Message Exchange Pattern) : 메세지가 들어오면 MEP 처리를 수행한다.

 

3. Outbount(수신 시스템과 연동)

처리가 끝난 메세지를 다시 시스템 플랫폼에 맞는 형태로 변환하여 수신 시스템에 전달한다. 

 

다음으로 EAI 아키텍처의 중요요소인 에러에 대한 처리이다.

 

모니터링 및 장애 관리

EAI 아키텍처에서 에러를 처리하기 위하여 모니터링과 장애를 관리하는데 다음과 같은 모듈이 있다.

 

1. 거래 로그(Audit Log)

거래 로그는 송수신 내용을 확인하여 시스템 장애 발생시 장애를 복구하는데 사용된다.

 

2. 에러 처리 로직(Error Hospital)

에러 처리 로직은 장애 감지, 장애 원인 리포팅, 장애 해결 3단계로 이루어 진다.

모든 장애데 대해 신속히 감지해야 하며, 원인을 추적할 수 있도록 리포팅이 되야하며 장애 해결을 할 수 있는 절차를 거쳐 로직을 완료한다.

 

3. 장애 처리 정책

에러 처리를 할 때 모인 장애들은 장애 처리 정책에 따라 처리되며, 4가지의 정책으로 정의된다.

 - Ignore : 메세시 실패 시 무시

 - Report : 메세지 전달 실패 시 이메일, 메신저 등을 통하여 보고

 - Retry : 메세지 전달 실패 시 지정된 시간 후에 자동으로 재시도

 - Manualhandling : 시스템 운영자에게 통보 후 실패 메세지를 운영자가 수동으로 처리 하도록 한다.

 

2. Business Layer

비즈니스 컴포넌트는 클라이언트로부터 들어온 여청을 받아 데이터베이스나 파일에서 데이터를 쓰거나 읽어 비즈니스 로직에 따라 처리한다. 

 

2.1 동기 요청 처리

동기 처리는 일반적인 처리 방식(Request/Response)으로 일반적인 REST API 서버를 말한다.

동기 처리 서버는 가장 기본적인 서버로 아케턱처 구성시에 크게 따질 사항은 많지 않지만, 다음과 같은 몇가지 고려사항을 가진다.

 

생산성의 문제

자바 플랫폼을 이용해서 단순한 REST API를 구성한다고 하여도, 비즈니스 로직 구현을 위한 스프링 프레임워크, DB 계층 구현을 위한 Mybatis or Hibernate 등의 설정, 구동을 위한 어플리케이션 서버 설정 등과 더불어 빌드 스크립트까지 작성하여야 한다.

이는 숙련된 개발자라고 하더라도 최소 몇시간의 작업시간이 소요되며 이는 생산성과 직결될 수 있다.

 

용량 문제

자바 스프링 기반의 애플리케이션은 내부적으로 스레드 풀(Thread Pool)이라는 구조를 사용한다.

스레드 풀의 구조는 클라이언트의 요청이 들어오면 미리 만들어 놓은 스레드 풀에서 스레드를 꺼내어 요청을 수행하는데, 요청을 처리할 수 있는 스레드 수의 한계가 있기 때문에 동시에 처리할 수 있는 요청 수에 한계가 있다.

또한 스레드 풀은 응답 대기 상태에서도 존재하기 대문에 요청이 없을 시에는 용량 비효율성이 발생할 수 있다.

 

하이브리드 플랫폼 활용

근래에는 위의 이슈 때문에 스크립트 기반의 플랫폼을 이용하는 경우가 많고, SNS 서비스 같은 경우에는 시스템 안정성 보다는 빠른 개발과 생산성을 추구하기에 Python 과 Node.js를 사용한다. 또한 비즈니스 로직이 복잡해진다면 자바 플랫폼과 함께 일반적인 API는 스크립트 언어로 개발하는 방식을 추구하는 경우가 많다.

 

SN 아키텍처

마지막으로 동기처리 아키텍처에서 고려해야 할 사항으로 확장성과 안정성을 보장하기위해 SN(Shared Nothing) 아키텍처가 있다.

SN 아키텍처는 시스템을 구성하는 노드들이 서로 종속성을 가지지 않고 서로 독립적으로 작동하는 구조이며, 종속성이 없기에 노드를 이론적으로 무제한 늘릴 수 있다는 장점이 있다. 또한 장애 발생시에 시스템 전체에 영향을 주지 않는데, 비즈니스 로직 상 서버들이 공유하는 정보가 없을 수는 없다. 

따라서 대안으로 다른 계층에 정보를 저장하는 형태, 예를들어 브라우저에 쿠키를 저장하거나 데이텁이스에 상태를 저정하는,로 이용할 수 있다.

 

2.2 데이터 그리드를 이용한 상태 정보 저장소

데이터 그리드란 일종의 메모리 클러스터이다. 여러개의 서버와 메모리를 연결하여 수십기가의 메모리 저장소를 만들어 이를 서버에서 사용하는 방식을 말한다.

데이터 그리드 방식은 주로 캐시나 HTTP 세션, 사용자 로그인 정보같은 상태 정보를 서버에서 공유한다.

 

데이터 그리드를 사용하는 장점에는 서버간의 클러스터링이 되어 있기에 특정 서버에서 장애가 발생하더라도 다른 서버가 그 역할을 할 수 있도록 페일 오버(Fail Over)를 하기 때문에, 고가용성을 가지고 있다.

2.3 메세지 큐를 이용한 비동기 요청 처리

앞서 설명한 동기 방식과 함께 비동기 방식도 존재한다. 차이점이 있다면 비동기 방식은 요청 시에 비즈니스 로직이 처리가 완료되지 않더라도 다음 로직을 처리하는 특징이 있다.

추가적으로, 비동기 방식에는 콜백 메세지를 이용하여 클라이언트에게 작업이 끝남을 알려줄 수 있다. 또한 비동기 방식은 대규모 작업에 유리하다.(동영상 인코딩과 같은)

 

비동기식 패턴을 구현할때는 메세지 큐라는 것을 사용하는데, 메세지 큐는 들어온 요청을 저장하는 임시 공간으로 쌓여 있는 요청 메세지는 바로 비즈니스 컴포넌트에 의해서 처리된다.

 

2.4 임시 파일 작업 공간

비동기 처리나 분산 환경에서 추가로 필요한 컴포넌트로 임시 파일 작업 공간이 있다. 임시파일 작업 공간은 직업적으로 애플리케이션 서버에 NFS로 마운트 될 수 있는 파일 시스템인데, 작업을 위한 임시 파일 저장소로 사용된다.

 

예를 들어, 업로드한 동영상에서 섬네일을 추출하고 변환 과정을 통해 아카이빙 스토리지에 저장되는 형태에서, 파일이 업로드 된 후에 이 파일은 임시 파일 작업 공간에 저장된 후, 메세지 큐에 변환 요청이 들어가면  뒷단의 변환 서버로 넘어가 처리 후에 아키이빙 스토리지에 저장된다.

 

업로드 -> 메세지 큐 -> Transform -> 아카이빙 스토리지

         - 임시 파일 작업 공간-

 

2.5 메세징 프로토콜

내부 시스템 간의 호출에서는 표준만 잘 지킨다면 바이너리 프로토콜을 사용하는 것이 성능과 용량측면에서 효율적일 수 있다.

하지만, 바이너리 메세지 포멧을 정의하고 구현하는 작업은 상당히 번거로우며, OS나 플랫폼에 따라 호환이 되지 않을 수 있다는 문제가 있다. 이러한 문제를 해결하기 위해 자바에서 RMI 와 같은 호출 프레임워크가 나왔지만 사용이 매우 복잡하다는 단점이 있다.

 

따라서 근래에 이런 바이너리 기반 통신을 지원하는 기술들이 오픈소스로 등장하였다.

 

PB(Google Protocol Buffer)

구글이 오픈소스화한 PB기술이 있다. PB는 엄밀히 말하면, 전송 규격이 아닌 객체에 대한 기술인데 이는 메세지 표준을 정의하는 기술을 말한다.

PB를 통해서 자바나 파이썬, C++ 객체를 바이너리 스트림으로 직렬화 할 수 있는데, 이 바이너리 스트림을 여러 계층(TCP, HTTP 등)을 통해 전송할 수 있다.

 

Thrift

Thrift는 구글 직원이 페이스북에 합류하여 만든 프로토콜로, 보통은 PB와 함께 많이 쓰인다. PB가 제공하는 직렬화 기술을 사용할 수 있으며, 클라이언트에서 서버의 함수를 네트워크를 통하여 호출 할 수 있다. 또한 Thrift는 다양한 언어를 지원한다.