클라우드 컴퓨팅 아키텍처

아키텍처의 변화 VIEW Controller Model MVC 구조 ※ EJB 이전 시스템 처리가 모두 서버단에서 수행되는 스크립트 방식 단점 : 코드의 재활용 부족, 스파게티성 코드 양산, 유지보수의 어려움 등 대응책 : 서버 증설, 부하 분산(DNS,L4) 이후 MVC 패턴을 기반으로 하는 논리적인 아키텍처가 정립 되었음. 시스템의 안정성은 여전히 개발자들의 몫 MVC의 궁극적인 목적 컴포넌트 역할을 서로 독립적으로 부여. 컴포넌트 관계 인터페이스 참조로 설계 = 새로운 요구사항 유연하게 대처 가능 ! VIEW 모델에 대한 랜더링 사용자 인터페이스 제공 JSP/Servlet Controller 사용자 요구 처리 모델에 대한 변경 JSP/Servlet/ SessionBean 사용자 행위 전달 뷰의 선택 Model 실세계 데이터 모델링 뷰의 상태조회 응답 컨트롤러의 상태변경 반영 자바객체/EntityBean 상태 조회 상태 변경 MVC 구조 Model – View – Controller 개발 패턴에 기반한다. 연산과 처리를 담당하는 프로그램의 논리 구조에서 사용자에게 제공하는 표현부분을 분리하는 소프트웨어 접근 방법론이다. 사용자 인터페이스와 비즈니스 로직 에 서로 영향 없이 쉽게 고칠수 있는 애플리케이션을 만들 수 있음

아키텍처의 변화 EJB에 대한 장점 ※ 분산 아키텍처의 출현 이론적으로 높은 안전성 3계층 미들티어에 위치하면서, 한정된 공유자원들을 효과적으로 관리해줌 Web + EJB + DB , 3계층 화 ! ※ 분산 아키텍처의 출현 2000 년대 이후, 등장한 대표적인 분산 기술 EJB (Enterprise Java Bean) EJB는, 재활용 가능한 포터블 J2EE 컴포넌트입니다. J2EE ( Java 2 Enterprise Edition ) 웹 애플리케이션 관련 기술 등으로 자바 개발을 할 수 있는 라이브러리스펙 EJB는 대규모이고 구조가 복잡한 분산 객체 환경을 보다 쉽게 구현하기 위해서 등장 하였습니다. 분산 환경이 필요한 이유는? 비즈니스 로직과 UI 로직을 서로 다른 머신으로 분리시킴으로써 비즈니스 로직의 재사용성과 시스템 아키텍쳐의 유연성을 높이기 위해서 등장. EJB가 활성화 되지 않은 이유 UI 와 비즈니스 로직 컴포넌트간의 RMI 통신 자동화를 위한 여러 로직의 실행에 따른 무게감 어려운 개념에 따른 개발자 부족 web EJB DB

CBD ※ CBD (Component Based Development ) 시스템 또는 소프트웨어를 구성하는 각각의 컴포넌트를 만들고 조립해 또 다른 컴포넌트나 소프트웨어를 만드는 것을 말한다. 컴포넌트란, 특정 기능 수행이 가능하도록 독립적으로 개발된 것으로, 재사용이 가능한 소프트웨어 단위 CBD 의 등장배경 1, 객체지향 개발 방법론의 기술적 문제의 해결 필요 2. 객체 재사용의 어려움 및 확장성 3. S/W 위기 극복과 업무, 기술 및 E-Biz 조직의 변화 CBD 의 장점 및 특징 1. 개발 기간의 단축 과 재사용 가능 2. 독립적인 개발과 배포가 가능 3. 유지 보수가 용이 하다. 4. 인터페이스와 구현(Implementation) 의 분리

SOA ※ SOA ( Service Oriented Architecture ) : 서비스 지향 아키텍처 서비스라 불리는 분할 된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션 으로 만드는 아키텍처를 말한다. 서비스란, 반복 사용이 가능한 비즈니스 기능 서비스 지향 이란, 서비스를 서로 통합하여 비즈니스 요구사항을 충족하는 방식을 말합니다. 컴포지트 애플리케이션 이란, 정의된 서비스를 비즈니스 요구사항에 맞추어 조립(Composite)하여 원하는 기능을 구현합니다. SOA 장점 1. 중립적인 인터페이스 2. 공통 서비스 환경 제공 3. 실시간 기업 실현을 위한 최적의 방법론 SOA 문제점 1. SOA 인식의 부족 2. IT 환경 성숙도 부족 3. 사례 부족

SOA 와 CBD 방법론 연관성

프레임워크와 경량 컨테이너 ※ 경량 컨테이너 (Lightweight) 컨테이너란, 컴포넌트가 동작하는 환경을 뜻함. 경량 컨테이너는, EJB 아키텍처가 가지는 장점을 모두 수용하며, NON EJB의 장점까지 모두 수용함. 경량 컨테이너 장점 1. EJB에 비해 배우기 쉬우며, 빈을 설정하는 방법도 쉬움 2. 특정 인터페이스에 종속되지 않은 POJO를 기반으로 함 3. AOP 지원으로 EJB 컨테이너 기능 지원이 가능함 4. OOP 형태로 개발하는데 제약사항이 없다. 경량 컨테이너의 단점 1. 분산환경을 지원하지 못한다. 단,웹서비스 등으로 극복은 가능함. 2. 아직까지 경량 컨테이너에 대한 표준이 없다. NON EJB : EJB를 사용하지 않는 모든 아키텍처 통칭 POJO : (Plain Old Java Object) 오래된 자바를 뜻함 AOP : ( Aspect Oriented Programing) 관점지향 프로그래밍

클라우드 서비스를 위한 아키텍처 ※ 분산 기술의 발전 일반화된 분산기술 인터넷 스케일의 데이터와 트래픽을 다루는 회사에서는 ※ 분산 기술의 발전 일반화된 분산기술 인터넷 스케일의 데이터와 트래픽을 다루는 회사에서는 분산 기술을 이용해 시스템을 구축하는 것이 일반화 됨 애플리케이션 서버 자체를 구축할 수 있는 프레임워크 EJB는 너무 무거우며 라이센스도 비쌈. 시스템 연계시 자바 클라이언트만 가능한 약점이 있음. 최근에 나온 다양한 도구나 프레임워크를 이용하면 네트워크 프로그램에 대한 이론적 배경이나 지식 없이도 애플리케이션 서버를 쉽게 구축 할 수 있으며, 안정성, 성능 등도 보장 됨 멀티프로그래밍 언어 지원 하나의 애플리케이션 서버에 대해 다양한 클라이언트 프로그래밍 언어 지원 기술 등장 분산된 환경을 제어할 수 있는 기술 등장 분산된 자원에 대한 동기화, 락 제어, 클러스터 멤버쉽, 네이밍 서비스 고려해야 하지만, 최근에는 분산된 자원을 제어할 수 있는 쉽고 안정적인 방법들이 소개되고 있음 분산 스토리지(파일시스템, 데이터 관리 시스템) 구글은 GFS(Google File System) 라는 자체 개발된 파일 시스템 사용. 이런 내용을 논문으로 공개함 오픈 소스 진영에서는 구글의 GFS 같은 분산 파일 시스템을 개발해 공개. 이미 많은 사이트에서 사용 중 데이터 관리 시스템 분야에서도 NoSQL 이라는 개념이 등장하면서, 기존의 RDBMS가 아닌 분산된 환경에서 저렴한 비용으로 구조화된 데이터를 저장할 수 있는 솔루션이나 오픈 소스가 등장 하고 있다. NoSQL : RDBMS ( 관계형 데이터베이스 ) 의 정해진 스키마와 달리, 가용성과 확장성에 중점을 둔 DBMS 입니다.

클라우드 서비스를 위한 아키텍처 ※ 아키텍처 SaaS를 위한 시스템 구성 클라우드 컴퓨팅의 구현적인 기술을 보면, ※ 아키텍처 클라우드 컴퓨팅의 구현적인 기술을 보면, 가상화와 분산 기술의 효과적인 사용에 있다. 이런 관점에서 아키텍처적인 요구 사항은 다음과 같다 효과적인 사용에 대한 관점에서 아키텍처 요구사항 1. 탄력적 확장성 ▶ 초기 계획 대비 시스템 리소스 에 대한 확장성 2. 고가용성 ▶ 중앙 집중화에 의한, 안정성 3. 자동화된 리소스 관리 ▶ 클라우드 서비스는 분산 되어있는 서버의 리소스를 관리하여야 함. 이러한 리소스에 대한 자동관리 필요 4. 자동 복구 / 치료 ▶ 고가용성을 확보 하고, 자동화 된 리소스 관리가 되기 위해 소프트웨어 자체적으로 복구, 치료 할 수 있는 능력은 핵심적 요구사항 DNS 관계형 데이터베이스 로드밸런서 웹 서버군 캐시 클러스터 로드밸런서 로드밸런서 로드밸런서 캐시 애플리케이션 서버군 캐시 애플리케이션 서버군 캐시 애플리케이션 서버군 분산 데이터 시스템 검색 분산 코디네이터 부하 분산을 위한 로드 밸런싱 서버의 부하 줄이기 위한 캐시 서비스 이용 분산된 환경을 관리해주는 클러스터 관리

클라우드 서비스를 위한 아키텍처 웹 서버 SaaS를 위한 프로그램 모델 아키텍처 애플리케이션 서버(A 서브기능) Session Façade (class) Model (Class) Model (Class) Controller (Class) Model (Class) Business Delegate (class) View (JSP) View (JSP) View (JSP) 애플리케이션 서버(B 서브기능) Session Façade (class) Model (Class) Model (Class) Model (Class) Delegate : 메소드를 대신 호출을 받아서 알맞은 애플리케이션 메소드를 호출해주는 기능을 수행함.

클라우드 서비스를 위한 아키텍처 ※ 아키텍처 ※ 클라우드 서비스를 위한 소프트웨어 스택 기존 JE22 아키텍처와의 차이점 ※ 아키텍처 기존 JE22 아키텍처와의 차이점 1. 애플리케이션 서버로 EJB 컨테이너가 아닌 쓰리프트(thrift)나 에이브로(Avro)같은 오픈소스 이용 2. 서브 시스템의 내부는 스프링(Spring) 과 경량 컨테이너를 이용할 수 있음 3. 서비스 내부 간 호출은 쓰리프트,에이브로 등에서 지원하는 프로토콜 이용 4. 서비스 외부 호출은, 외부 서비스에 제공하는 API 인 JSON,REST같은 경량의 표준 프로토콜 이용 5. 분산된 서버에서 운영 중인 각 기능들을 서비스로 인식하려면 서비스 등록, 레포지토리, 룩업 등 SOA 를 중심으로 운영 ※ 클라우드 서비스를 위한 소프트웨어 스택 클라우드 인프라 서버 가상화와 분산 파일 시스템, 분산 데이터 관리 시스템 등에 대한 기술이 필요함 애플리케이션이 수행되는 서비스 실행 환경 1. 애플리케이션 서버 2. 추상화 된 데이터 매퍼와 파일 시스템 매퍼 3. 프레임워크와 인터페이스용 프로토콜 관리도구와 공통 서비스 1.분산환경에 대한 관리. 2. 서비스 레포지토리 3. 미터링 기능과 사용량에 따른 과금 서비스

클라우드 서비스의 단계별 진화 웹 / 애플리케이션 서버 DB ※ 단계별 진화 0단계 : 웹 애플리케이션 ※ 단계별 진화 0단계 : 웹 애플리케이션 웹 서버 내에서 대부분의 기능을 수행하며, 시스템 아키텍처도 기능에 따라 모듈 별로 분리된 상태 모듈 간 호출은 하나의 프로세스 내부에서의 호출. 데이터는 하나의 데이터베이스 서버에 저장 됨. 브라우저 HTTP 웹 / 애플리케이션 서버 Servlet Class DB

클라우드 서비스의 단계별 진화 DB Façade 패턴 ※ 단계별 진화 1단계 : Façade 패턴 적용 ※ 단계별 진화 1단계 : Façade 패턴 적용 비즈니스 로직은 모듈로 분리돼 있으며, 모듈 간 호출은 Façade 패턴을 적용함. Façade 에서는 자신의 모듈에 있는 기능을 대행함. 브라우저 HTTP 웹 / 애플리케이션 서버 Servlet Facade Class DB Façade 패턴

클라우드 서비스의 단계별 진화 Façade 패턴 적용 예 ※ 단계별 진화 1단계 : Façade 패턴 적용 예 ※ 단계별 진화 1단계 : Façade 패턴 적용 예 클라이언트는 대표 클래스인 DBHandler 를 이용하여, 내부 클래스를 다루지 않고 원하는 기능을 처리할 수 있도록 설계. Façade 패턴 적용 예

클라우드 서비스의 단계별 진화 DB ※ 단계별 진화 2단계 : 여러 서버로 확장 ※ 단계별 진화 2단계 : 여러 서버로 확장 서비스 사용자가 많아져 시스템에 부하가 증가하면 서버를 확장한다. 서버 확장은 각 모듈별로 다른 서버에 두고 모듈간 호출은 원격 호출로 처리한다. 원격호출은 RPC, HTTP, 웹 서비스 같은 프로토콜을 이용함. 브라우저 HTTP 웹 서버 Servlet Class Facade DB

클라우드 서비스의 단계별 진화 중앙집중 DB ※ 단계별 진화 3단계 : 서비스 풀 구성 ※ 단계별 진화 3단계 : 서비스 풀 구성 서브 기능별로 여러 대의 서버를 구성하는 서비스 풀 을 구성한다. 서비스 풀 을 구성함으로써 서비스 부하에 따른 대처가 용이해진다. 부하가 증가하면, 서비스 풀에 서버를 추가로 투입 하고, 로드밸런서 설정만 변경하면 된다. 웹서버군 브라우저 HTTP 로드 밸런서 중앙집중 DB 애플리케이션 서버군 로드 밸런서 애플리케이션 서버군 로드 밸런서 서비스 풀

클라우드 서비스의 단계별 진화 DB DB DB ※ 단계별 진화 4단계 : 데이터 분산 저장 ※ 단계별 진화 4단계 : 데이터 분산 저장 비즈니스 로직 처리를 위한 계층이 확장되면, 데이터베이스 서버에 부하가 집중된다. 또한 서비스의 사용이 늘어남에 따라 저장해야 하는 데이터도 많아진다. 웹서버군 로드 밸런서 분산 데이터 시스템 브라우저 HTTP DB DB DB 애플리케이션 서버군 로드 밸런서 애플리케이션 서버군 로드 밸런서

클라우드 서비스의 단계별 진화 DB DB DB ※ 단계별 진화 5단계 : 캐시 계층 추가 ※ 단계별 진화 5단계 : 캐시 계층 추가 데이터 읽기가 빈번하게 발생하는 서비스인 경우, 캐시 계층을 추가하여, 부하 감소 및, 응답시간 단축 ※ 실제 데이터의 변경사항을 캐시에 반영하는 방법 캐시에 타임아웃 설정 이벤트 메시지를 통한 캐시 데이터 변경 웹서버군 로드 밸런서 브라우저 HTTP DB DB DB 애플리케이션 서버군 로드 밸런서 캐시 분산 데이터 시스템 캐시 애플리케이션 서버군 로드 밸런서

클라우드 서비스의 단계별 진화 DB DB DB ※ 단계별 진화 6단계 : 외부 노출 서비스 선택 ※ 단계별 진화 6단계 : 외부 노출 서비스 선택 다른 서비스와의 연동이나, 매쉬업 서비스 제공을 위해 API 를 외부에 제공한다. 서비스를 외부에 공개하려면 공개할 서비스에 대한 보안, SLA 수준, 요금 정책 등을 수립해야 한다. 공개 대상 서비스 선택 웹서버군 로드 밸런서 브라우저 HTTP DB DB DB 애플리케이션 서버군 로드 밸런서 캐시 분산 데이터 시스템 캐시 애플리케이션 서버군 로드 밸런서

클라우드 서비스의 단계별 진화 DB ※ 단계별 진화 7단계 : 서비스 게이트웨이 구축 ※ 단계별 진화 7단계 : 서비스 게이트웨이 구축 공개할 API 가 결정 됐으면, 6단계에서 정의된 보안, SLA, 요금, 사용정보 트래킹 등의 기능을 갖고 있는 게이트웨이를 구축한다. 게이트웨이 서버는 표준화된 프로토콜을 제공한다. 웹서버군 로드 밸런서 브라우저 HTTP DB 분산 데이터 시스템 캐시 서비스 게이트 웨이 외부 서비스 애플리케이션 서버군 로드 밸런서 애플리케이션 서버군 로드 밸런서 외부 서비스 외부 서비스 캐시

클라우드 서비스의 단계별 진화 DB ※ 단계별 진화 8단계 : 외부 게이트웨이 구축 ※ 단계별 진화 8단계 : 외부 게이트웨이 구축 외부에 있는 다른 서비스의 API 를 이용할 때는 외부 서비스로 접속하는 게이트웨이 서버를 이용해 다른 서비스의 API 를 이용하게 한다. 이렇게 함으로써 서비스의 API 가 변경되더라도 유연하게 대응이 가능하다. 외부 서비스 게이트 웨이 외부 서비스 웹서버군 로드 밸런서 브라우저 HTTP 외부 서비스 외부 서비스 캐시 DB 분산 데이터 시스템 서비스 게이트 웨이 외부 서비스 애플리케이션 서버군 로드 밸런서 애플리케이션 서버군 로드 밸런서 외부 서비스 외부 서비스 캐시

클라우드 서비스의 단계별 진화 ※ 단계별 진화 9단계 : 서비스 버전 관리 기능 추가 ※ 단계별 진화 9단계 : 서비스 버전 관리 기능 추가 인터페이스 업데이트로 버전이 변경 되었을 경우, 이를 사용하던 외부 서비스에 문제가 발생할 수 있기 때문에 기존 인터페이스 업데이트를 일정 기간 유지 해야 한다. 이 경우 버전에 따라 서버에서 분기 되는 버전 라우터라고 하는 계층을 추가해 적절한 서버로의 호출을 가능하게 한다. 1.X 대 버전은 상호 호환 클라이언트 버전 1.1 버전 1.3 버전 2.2 클라이언트 버전 2.2 버전 라우터 버전 3.5 클라이언트 버전 3.0

클라우드 서비스의 단계별 진화 ※ 단계별 진화 10단계 : 클라우드 컴퓨팅 서비스 활용

클라우드 컴퓨팅 아키텍처 The End