클라우드 컴퓨팅 아키텍처

EJB 이전의 시스템에서는, 웹서버, 톰캣 등 서버에서 모든작업을 수행했으며, 프레임워크,패턴 같은 개념도 일반화 되지 않았습니다.

이런 아키텍처는 빠르게 개발할 수 있지만 코드의 재활용 부족, 스파게티성 코드 양산, 유지보수의 어려움 등의 단점이 있는 애플리케이션 아키텍처 입니다.

스파게티성 코드 양산이라 함은, 복잡하게 얽힌 코드를 말하며, 가독성이나, 확장성이 고려되지 않은 코드를 말합니다.

이러한 아키텍처에서 대규모 요청에 대응하기 위해서는, 서버를 여러대~수십대 분산배치하고 DNS나 L4 등으로 부하를 분산 하였습니다.

그러다 MVC 패턴을 기반으로 하는 논리적인 아키텍처가 정립 되었지만, 시스템의 안정성은 여전히 개발자의 역량에 따라 좌우되었습니다.

M. V. C 모델의 궁극적인 목적은 각각의 컴포넌트에 대해 역할을 서로 독립적으로 부여하고
또한 각각의 컴포넌트의 관계는 구연 참조가 아니라 인터페이스 참조로 설계하여 차후 새로운 요구사항에
대해 최소한의 비용으로 보다 유연하게 대처하고자 하는 목적이며 이는 객체 지향 설계방법의 기본적인 목적이기도 합니다.

MVC 패턴이란, 화면 영역인 뷰 와 비즈니스로직(프로그램의논리구조)을 처리하는 모델 영역과, 두 영역간 관계를 제어하는

컨트롤러 로 구성됩니다.

 

2000 년대 이후 웹 환경이 일반화 되면서, 대규모의 사용자 요청을 안정적으로 처리 할 수 있는 기술이 필요했습니다.
이 시기에 등장한 대표적인 분산 기술이 EJB입니다.

EJB는 재활용 가능한 포터블 J2EE 컴포넌트 입니다.

J2EE란, 매우 포괄적인 의미를 가지고 있는데, 가장 일반적인 의미는, 개발에 필요한 다양한 환경을 정의해 놓은 라이브러리 규칙이라
할수 있습니다.

컴포넌트란, 별도의 변형이나 가공없이 그 자체로써 수행 및 배포가 가능하며, 이러한 특성으로 인해 객체보다 독립적이며
재사용성 대체성 플러그가능성을 가집니다.

즉, EJB 는, 재활용 가능한  기업형 자바개발 라이브러리 스펙(규칙) 들의 컴포넌트라 생각하면 됩니다.

EJB는 대규모이고 구조가 복잡한 분산 객체 환경을 쉽게 구현하기 위해서 등장했습니다.

분산 환경이 필요한 이유는, 비즈니스 로직과 UI 로직을 서로 다른 머신 또는 프로세스로 분리시킴으로써
비즈니스 로직의 재사용성과 시스템 아키텍쳐의 유연성을 높이기 위해 등장 하였고,
이러한 분산 객체 환경의 구축을 쉽게 하려다 보니, EJB 와 같은 전용 플랫폼이 등장하게 되었습니다.

EJB가 활성화 되지 않은 이유는 분산 환경을 쉽게 구현하게 하려다 보니 RMI(Remote Method Invocation)를 사용하게 되고,
자동화를 위해 여러 로직을 실행하다 보니, 속도가 느려지고, 자원 관리가 잘 되지 않았으며,
어려운 개념에 따른 개발자의 부족이 이유라 할 수 있습니다.

EJB는 이론적으로 안정성이 높습니다.
비즈니스 로직과 UI 가 완전히 분리되어 있으므로, 각 영역에 대한 전문적인 담당자로 나누어지게 됩니다.
전문가들이 만든 코드는 일관성과 안정성을 갖게 됩니다.
둘째로, EJB는 3계층 미들티어에 위치하면서, 한정된 공유자원들을 효과적으로 관리해줍니다.
셋째로, 처리하는 머신이 2계층에 비해 1대 더 많기 때문에, 더 많은 사용자를 수용할 수 있습니다.

CBD 는 시스템 또는 소프트웨어를 구성하는 각각의 컴포넌트를 만들고 조립해 또 다른 컴포넌트나 소프트웨어를 만드는
것을 말합니다.

컴포넌트는 특정 기능 수행이 가능하도록 독립적으로 개발 된 것으로, 재사용이 가능한 소프트웨어 단위 입니다.

CBD의 등장이유는, 객체 지향 개발 방법론의 기술적 문제를 해결할 필요성이 있었으며,
객체 재사용의 어려움 및 대규모 프로젝트에서의 확장성이 떨어지는 문제를 해결해야 했습니다.

그리하여, 등장한

CBD의 장점으로는, 소프트웨어 컴포넌트를 조립해 새로운 애플리케이션을 만들 수 있어, 개발기간을 단축할 수 있습니다.

또한 독립적인 개발과 배포가 가능 해, 사용자는 품질 좋은 컴포넌트를 선택하여 사용할 수 있습니다.

컴포넌트는 캡슐화 되어 있어 로직상의 에러나 런타임 에러 등의 범위를 컴포넌트로 한정할 수 있어 유지보수가 용이합니다.

인터페이스와 구현이 분리 되어있습니다. 인터페이스는 서비스를 외부에서 접근할 수 있도록 하는 가상함수 이며
구현은 인터페이스를 상속받아 실제 서비스를 구현한 부분으로 객체 클래스와 동일합니다.

SOA는 서비스 지향적인 아키텍처입니다. 여기서 서비스란 재사용 가능한 비즈니스 프로세스를 수행하는 하나의 소프트웨어 컴퍼넌트입니다.
바로 이 서비스들이 표준 방식에 의해 서로 느슨하게 연결되어 있어 특정 구현에 얽매이지 않은 중립적인 인터페이스이므로
특정 서비스를 변경 하더라도 연결된 다른 서비스에는 영향을 전혀 끼치지 않습니다.
이는 변화에 대한 빠른 대응, 즉 “민첩성” 및 “재활용성”과 "통합성”으로 직결됩니다.

그리고 이러한 아키텍쳐 상에서 운영되는 애플리케이션을 '컴포지트 애플리케이션' 이라고 합니다.

컴포지트 애플리케이션은 기존 애플리케이션 개발 방식과는 달리, 정의된 서비스를 비즈니스 요구사항에 맞추어 조립(Composite)하여
원하는 기능을 구현합니다. 만약 기존 컴포지트 애플리케이션을 변경해야 한다면 컴포지트 애플리케이션을 구성하는 서비스 중
필요 없는 기능에 해당하는 서비스를 빼고 원하는 기능을 제공하는 서비스를 넣어서 새로운 기능을 하도록 변경할 수 있습니다.
따라서 매우 빠르게 애플리케이션을 만들어 낼 수 있습니다.

이런 점에서 SOA는 산업분야에 관계없이 모든 기업들이 추구하는 실시간 기업
실현을 위한 최적의 방법론으로서 자리매김 하고 있습니다.

S0A 의 장점으로는,  표준 인터페이스 기반과, 실시간 기업 환경 제공으로, 업무 및 환경 변화에 대한 즉시적인 대처와 유연성을 제공하며
공통 서비스 환경 제공으로, 공통 컴포넌트 형태의 서비스 재사용이 가능합니다.

SOA 의 문제점으로는,  하나의 신기술 및 유행으로 생각하는 SOA 인식의 부족이 있으며,
SOA 를 위한 미들웨어, 메시징, XML 에 대한 기술 및 엔지니어가 부족합니다.

 

 

컨테이너란, 컴포넌트가 동작하는 환경을 뜻합니다.
경량 컨테이너는, EJB가 지원하는 트랜잭션 처리, 시큐리티, 빈의 생명 주기 관리 등 컨테이너를 통해 지원할 수 있는 기능을
지원하는 아키텍처 입니다.

장점으로는 , EJB에 비해 배우기 쉬우며, 서블릿 컨테이너에서 실행되는 것이 가능하므로 이식성이 뛰어나며,
특정 인터페이스에 종속되지 않는 POSJ 기반을 사용하기 때문에 테스트가 용이합니다.
또한 AOP 지원으로 EJB 컨테이너에서 지원 가능했던 컨테이너 기능을 지원합니다.
따라서 OOP 형태로 개발하는데 제약사항이 없습니다.

단점으로는,
분산 환경을 지원하지 못하며, 아직까지 경량 컨테이너에 대한 표준이 없습니다.

NON EJB 란, EJB 를  사용하지 않는 애플리케이션의 모든 아키텍처를 통칭 합니다.
POJO 는, 오래된 방식의 간단한 자바 오브젝트라는 말로서, JEEE 등의 중량 프레임워크 들을 사용하지 않는것을 말합니다.

 

 

분산 기술이 일반화 되고, 이런 기술을 구현한 많은 오픈소스가 배포되면서,
인터넷 스케일의 데이터와 트래픽을 다루는 회사에서는 분산 기술을 이용해 시스템을 구축하는 것이 일반화 되었습니다.

EJB는, 너무 무거우며 라이센스도 비쌉니다. 시스템 연계시 자바 클라이언트만 가능하다는 약점도 있습니다.
최근에 나온 다양한 도구나 프레임워크를 이용하면, 네트워크 프로그램에 대한 이론적 배경이나, 지식 없이도
애플리케이션 서버를 쉽게 구축할 수 있으며, 안정성, 성능 등도 보장 됩니다.

하나의 애플리케이션 서버에 대해 다양한 클라이언트 프로그래밍 언어 지원 기술들도 등장하여, 쉽게 연동할 수 있습니다.

분산된 자원을 제어하려면, 분산된 자원에 대한 동기화, 락 제어, 클러스터 멤버쉽, 네이밍 서비스를 고려해야 하지만,
최근에는 분산된 자원을 제어할 수 있는 쉽고 안정적인 방법들이 소개되고 있습니다.

구글은 GFS 라는 자체 개발된 파일 시스템을 사용하고, 이런 내용을 논문으로 공개합니다.

오픈 소스 진영에서는 구글의 GFS 같은 분산 파일 시스템을 개발해 공개하고 있습니다.

데이터 관리 시스템 분야에서도 NoSQL 이라는 개념이 등장하면서, 기존의 RDBMS 가 아닌
분산된 환경에서 저렴한 비용으로 구조화된 데이터를 저장할 수 있는 솔루션이나 오픈 소스가 등장하고 있습니다.

NoSQL 이란, 관계형 데이터베이스의 정해진 스키마와 달리, 가용성과 확장성에 중점을 둔 DBMS 입니다.

 

 

클라우드 컴퓨팅의 구현적인 기술을 보면, 가상화와 분산 기술의 효과적인 사용에 있습니다.
이런 관점에서의 아키텍처적인 요구 사항은 다음과 같습니다.

탄력적 확장성.
대부분의 디바이스들이 인터넷에 접속되는 지금의 환경에서는, 서비스 계획 단계에서 정확한 용량 산정이 어렵습니다.
따라서, 갑작스런 부하의 증가에 따른 확장성 또는, 축소할 수 있어야 합니다.

고가용성
클라우드 서비스는 모든 자원이 중앙 집중 돼 있는 클라우드 서비스 내에 존재합니다.
따라서, 기존 서비스보다 훨씬 높은 가용성이 필요합니다.

자동화된 리소스 관리
클라우드 서비스는 분산 되어있는 서버나 스토리지 등을 관리하여야 하며, 이들 리소스는 수작업으로 관리하는 것은
불가능 하거나 많은 비용이 소모 되므로, 자동화된 리소스 관리가 필요합니다.

자동 복구 / 치료
고가용성을 확보하고 자동화 된 리소스 관리가 되기 위해 소프트웨어 자체적으로 복구, 치료할 수 있는 능력은
핵심 요구사항이라고 할 수 있습니다.

아키텍처의 요구사항에 맞춰 SaaS 를 위한 시스템 구성을 살펴보겠습니다.
시스템은 서브 시스템 단위별로 분산돼 있으며, 각 서브 시스템은 부하 정도에 따라 여러대의 서버 풀을 구성해 운영됩니다.
서버 풀로 운영 되기 때문에 부하 분산을 위한 로드 밸런서가 배치되었으며, 분산된 환경을 관리해주는 클러스터 관리 도구와
분산 코디네이터가 추가 되었습니다.
주요 특징은, 애플리케이션 서버, 파일 시스템, 데이터베이스, 캐시 같은 참여하는 요소들이 분산 아키텍처로 구성되어있습니다.
시스템 구성 뿐만 아니라, 프로그램 모델도 분산 아키텍처로 구성돼야 하는데, 프로그램 모델은
J2EE 분산 아키텍처와 동일한 아키텍처를 사용합니다.

( 부하를 분산하는 로드 밸런서 )
( 분산된 환경을 관리하는 클러스터 )
( 서버 풀 이란 웹 서버에 접근하여 이용자 자신이 정보를 취득하는 능동적인 형태의 기술 )

 

 

 

 

1. 애플리케이션 서버로 EJB 컨테이너가 아닌 다양한 플랫폼에서 쉽게 개발할 수 있는 쓰리프트나 에이브로 같은
오픈소스를 이용합니다.
쓰리프트나 에이브로 는, 경량 컨테이너로써,  이기종간 데이터 타입을 교환할 수 있는 체계를 제공하는 프레임워크 입니다.

2. 서브시스템의 내부는 스프링 과 경량 컨테이너를 이용할 수 있으며, 이 경우 기존에 개발된 모듈을 그대로 활용할 수 있는 장점이 있습니다.

서비스 내부 간 호출은, 쓰리프트 에이브로 등에서 지원하는 프로토콜을 이용하며

서비스 외부 간 호출은, 외부 서비스에 제공하는 API 인  JSON, REST 같은 경량의 표준 프로토콜을 이용합니다.
JSON -RPC  는 경량의 원격 호출 프로토콜을 뜻하며
REST 는,  네트워크 아키텍처 원리의 모음이란 뜻으로,  보편적인 인터페이스로  HTTP Method 가 있습니다.

분산된 서버에서 운영 중인 각 기능들을 서비스로 인식하려면, 서비스등록, 레포지토리, 룩업등, SOA 를
중심으로 운영 됩니다.

레포지토리란, 각종 정보의 저장소 를 뜻합니다.

클라우드 서비스를 위한 소프트웨어 스택

스택은 구성도 라는 뜻으로 해석 됩니다.
인프라 는, 컴퓨터와 사용자들을 연결하는데 사용되는 물리적 하드웨어를 말합니다.

클라우드 인프라는 서버, 스토리지, 데이터베이스 같은 인프라를 제공하는데
이들 인프라는 가상화 되어 인프라를 사용하는 시스템에서는 서버의 배치, 서버의 용량 등을 고려하지 않고
사용할 수있어야 합니다.

애플리케이션이 수행되는 서비스 실행 환경에서는,
외부 요청을 받아 프로그램을 수행하는 애플리케이션 서버,
특정 클라우드 데이터 스토리지/파일 시스템에 종속되지 않게 하기 위해 추상화된 매퍼와 파일 시스템 매퍼,
프로그램 개발을 쉽게 해주는 각종 프레임워크와 인터페이스용 프로토콜 등으로 구성됩니다

인프라와 서비스 운영 환경은, 관리도구와 공통 서비스 등에 의해 관리됩니다.
기본적으로 분산 환경에 대한 관리와, 배포된 서비스간 연동을 위한 서비스 레포지토리 등으로 구성되며
추가적으로, 사용현황을 측정할 수 있는 미터링 기능과, 사용량에 따른 과금 서비스 등이 필요합니다.