후니훈의 모바일 세상

출저: http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040201&docId=69965713

문제점:

java.lang.UnsupportedClassVersionError: com/enki/loves/servlet/DownloadServlet : Unsupported major.minor version 51.0 
(unable to load class com.enki.loves.servlet.DownloadServlet) 

war파일 실행했는데 위에 처럼 에러 발생했습니다. 

javacomplier 버전 문제로 파악되었지만 같은 버전을 사용하고 있습니다. 
이클립스 컴파일버전 -> 1.7.0 
jdk path 설정 - > 1.7.0 

해결:

환경변수 셋팅을 잘 해야 한다. JRE_HOME 부분이 문제였음.

TOMCAT_HOME  =   C:\jdk\jdk1.7.0_21

path  =   C:\jdk\jdk1.7.0_21\bin

JAVA_HOME = C:\jdk\jdk1.7.0_21

JRE_HOME = C:\jdk\jdk1.7.0_21

문제점: 

회사에서 Tomcat 컨테이너를 이용해 서버를 하나 만들었다. 내부 IP만 연결되어 폰에서는 불가능하고,

에뮬레이터에서 접속을 해야만 했다.

그런데 웹브라우저에  http://localhost:8080 입력하면 페이지를 찾을 수 없다고 나온다.

해결방법: 

http://192.0.0.88:8080 접속하면 서버에 연결 된다.

클러스터링(Clustering)이란 복수개의 장비를 묶어서 마치 이것이 하나의 거대한 장비처럼 인식되도록 하거나 동작하도록 만들어진 전산 환경을 일컷는 말이다.  클러스터링 환경에서는 따라서 특정 장비에 문제가 생기거나 특정 장비에서 실행중인 어플리케이션에 문제가 발생하더라도 해당 장비의 문제로 국한시키고 이것이 특정 서비스 혹은 기능 전체에 영향을 미치지 않도록 제어가 가능하기 때문에 대규모 시스템 혹은 안정적인 기능의 수행이 필요한 대부분의 시스템들에 채용되고 있다.

일반적인 클러스터링 구현

클러스터링을 구현하는 방법은 기본적으로 가상 IP(Virtual IP)를 기반한다.  서비스를 제공하는 실제 장비는 물리적인 IP를 갖고, 이 앞단에 가상 IP를 갖는 장비를 두고 이 장비에서 실제 장비로 데이터 처리를 혹은 요청을 중계하는 방식을 갖는다.  따라서 서비스를 위해 외부에 공개된 네트워크 접속 정보는 가상화된 IP에 근거한 정보가 제공되며 내부 시스템은 철저하게 가려져있는게 일반적인 원칙이다.

통상 이와 같이 가상 IP를 가지고 이를 각각의 물리적인 장비에 외부에서 요청된 처리를 중계해주는 역할을 스위치 장비에서 처리를 해주며 이 장비는 일반적인 허브등과는 차별화된 기능을 수행한다. (따라서 고가이며 이에 대한 범용적인 처리를 위한 대규모 장비들이 데이터센터등에 위치한다.)  스위치 이외에 일반적인 장비를 이용해서 소프트웨어적인 기법으로 이를 구현할 수도 있으며 특정한 목적이 필요한 경우에는 S/W적인 기법을 이용한 스위치 장비를 사용하기도 한다.


상태에 따른 클러스터링의 종류

기본적인 클러스터링은 위에서 언급한 바와 같이 가상 IP를 통해 들어온 요청을 물리적인 장비로 분기시켜주는 기능을 수행한다.  내부적으로 각각의 요청간에 특정 정보를 관리해야 하는 경우에 따라 클러스터링 모델에 차이가 있을 수 있다.

예를 들어 웹 서버에 대한 클러스터링의 경우에는 해당 사용자에 대한 세션 정보의 공유가 필요하며 이 정보는 통상 쿠키(Cookie)를 통해 이루어지므로 클러스터링을 위해 기반된 어플리케이션이 특정한 기능을 별도로 수행할 필요없이 해당 쿠키 정보를 엑세스 할 수 있으면 된다.

반면에 대규모 DBMS 시스템의 경우에는 각 요청단에서 이루어진 Transaction에 대한 상태 정보와 해당 데이터를 DBMS에 Commit 시킬지 Rollback시킬지 여부에 대한 정보 관리가 필요하다.  또한 개별 Transaction에 한 서버에서만 이루어지는 것이 아니라 복수 서버에서 나누어 처리되기 때문에 한 서버에서 Rollback을 수행했을 때 다른 서버에서 이루어진 Transaction도 마찬가지로 복구 처리가 이루어져야 한다.

이 경우에는 개별 장비단에서 동작하는 어플리케이션들이 상호 긴밀하게 사용자에 대한 인지와 해당 사용자에 의해 이루어진 각각의 요청 업무에 해당 상태 및 이력들을 보관하고 있어야 하기 때문에 단순한 구조가 아닌 복잡한 S/W Architecture 및 정보 교환 모델을 요구한다.

따라서 이와 같은 복잡한 상태 정보의 Sharing을 가능하게 해주는 기능을 해당 소프트웨어가 탑재하고 있는냐 없느냐에 따라서 해당 소프트웨어의 가격이 결정된다.  (통상 이런 클러스터링 기능이 탑재된 제품의 가격은 억대다.)

Active/Active 모델과 Active/Standby 모델

이러한 클러스터링 기술을 기반으로 안정적인 시스템 운용 모델을 가져가는 데표적인 형태가 바로 Active/Active 모델과 Active/Standby 모델로 구분되는 운용 모델이다.

Active/Active 모델은 두 대의 장비를 서로 서비스에 운용하면서 두 장비에 있는 어플리케이션이 서로 상태 정보를 공유함으로써 장비의 활용성을 높이고 높은 Throughput을 낼 수 있는 구조를 나타낸다.  통상 오라클이나 J2EE 엔진등이 이런 기반 기술을 지원한다.

Active/Standby 모델은 실제 서비스는 한 장비에서 운용하고 다른 한대는 장애 대비용 시스템으로 사용한다.  만약 한 장비에서 하드웨어 혹은 소프트웨어적인 결함이 발생되면 해당 장비의 기능이 통채로 대기중인 장비로 이전되며 대기중인 장비에서 기능 수행을 위한 어플리케이션이 실행된다.  ( 이 상황에서 장애 장비에서 실행중인 데이터 처리가 유실될 수 있다.) 

Active/Standby 모델은 어플리케이션 자체가 이중화 방식을 지원하지 못하는 경우에 사용되며 이 경우에도 데이터 처리를 넘겨주는 S/W가 필요하다.  이를 위한 기반 S/W는 통상 OS 수준에서 제공되며 많이 알려진 제품으로는 HP의 MC/SG(MC Service Guide)다.

출저: 클러스터링 환경

http://kwon37xi.egloos.com/4747016

http://www.slipp.net/wiki/pages/viewpage.action?pageId=11632748

http://toby.epril.com/?p=368

플랫폼의 핵심 기능중 하나가 Open API이다. 해당 기능을 이용하려면 인증(Authetication)하고 권한 부여(Authorization)할 수 있는 약속을(프로토콜) 새롭게 만들어야 했고 그 결과물이 OAuth이다. 초기 1.0에서 보안결함을 해결한 1.0a 와 최신 2.0 버전을 가장 많이 사용을 하고 있다. 

개념

예전의 OpenID방식은 인증(로그인)만을 처리하는 것이고, RESTful Open API 호출시 권한 체크를 하지 않으므로 이에 대한 권한체크도 필요하다. OAuth는 두개의 역할을 다 수행한다 

  - 인증 : 우리가 흔히 사용하는 Login시 ID/Password 를 통하여 인증을 받는다 - Request_Token

  - 권한 : 권한이 있는 기능만을 호출할 수 있다 - Access_Token

버전

  - v1.0 : 보안 결함 발견 v1.0a가 IETF 표준 프로토콜, 웹만 인증 가능

  - v2.0 : v1.0의 key_signature 복잡함등의 제거, 웹뿐만 아니라 애플리케이션도 인증 가능 

V1.0 

  - User : 특정 서비스에 사용하는 유저 예) Smart Visualization 사용자

    Consumer : 특정 서비스이면서 OAuth 제공자(서비스 제공자)에게 인증과 권한을 요청 예) Smart Visualization

    Service Provider : OAuth 제공자 예) 트위터

  - Request Token 으로 인증을 처리하고 Access Token으로 권한

  - 장점

  - 총정리

V2.0 

  - 3가지 종류 존재 : bearer token 방식 사용. 나머지 두가지는 계속 수정중 

  - 간단해 졌고, 더 많은 인증 방법을 제공, 대형 서비스로 확장을 지원한다 

사용하기 

  - 다양한 언어별 라이브러리 존재 

<참조>

  - OAuth v2.0 만능 도구상자 (KTH)

  - OAuth v1.0와 춤을 (NHN)

출저: http://mobicon.tistory.com/category/Protocols/OAuth