lightweight architecture in web application

Lightweight Architecture

In

Web Application

안세원안세원안세원안세원([email protected])([email protected])([email protected])([email protected])

Lightweight Architecture in Web Application

Executive Summary

현대 기업 환경에서 효과적인 web service와 web application 구축은 기업

의 비즈니스적인 목표를 달성하는데 매우 중요한 위치를 차지하고 있다. 그

러나 기존의 3-Tier 형태의 framework를 도입할 경우, 개발과 유지보수,

그리고 장비도입에 투입되는 높은 비용으로 인해 이러한 비즈니스 목표의

달성에 어려움이 있었다. 이러한 문제점의 해결방안의 하나로 복수의 저가

장비의 clustering을 이용한 2-Tier 형태의 lightweight architecture가 제

안되었고, 이를 통해 기업은 효과적으로 자신의 business 역량을 증진시킬

수 있다.


목차

1. 기술 상황 분석.....................................................................5

2. Scope................................................................................5

3. 용어설명.............................................................................5

4. 자료 조사 ...........................................................................6

5. Technical Findings.................................................................7

5.1. Lightweight Architecture의 정의..........................................7

5.2. Lightweight Architecture 관련 기술 및 제품 ......................... 10

5.2.1. LAMP ............................................................... 11

5.2.2. Spring .............................................................. 12

5.2.3. Hibernate .......................................................... 13

5.2.4. Tomcat............................................................. 14

5.2.5. Ruby on rails ...................................................... 15

6. Lightweight Architecture 적용 사례 분석..................................... 16

6.1. WEB 2.0 시대의 신생 기업들 .......................................... 16

6.2. Reuters – 거대 뉴스, 정보 제공 사업자 .............................. 18

7. 결론 ................................................................................ 19

8. 참고문헌........................................................................... 20

9. 참고자료........................................................................... 21

9.1. 기타 lightweight J2EE application..................................... 21

9.2. Dependency Injection 추가설명........................................ 21


그림 목차

그림 1 Lightweight Architecture Overview.....................................7

그림 2 3-Tier layout..............................................................7

그림 3 2-Tier layout..............................................................8

그림 4 WEB 2.0 환경의 성공적인 시스템 개요............................ 10

그림 6 Local EJB architecture presenting................................... 12

그림 7 Lightweight J2EE architecture........................................ 13

그림 8 Hibernate Architecture ................................................ 14

그림 9 Rails process flow .................................................... 16

그림 10 FlickR system architecture .......................................... 17

그림 11 Reuters 시스템의 분산 노드 구조 ................................. 18


-5/22- 안세원

2006-07-22

1. 기술기술기술기술 상황상황상황상황 분석분석분석분석

Web 환경의 도입으로 기업들은 기존의 Client/Server 환경에서의 client 환

경 종속성과 배포의 어려움, 그리고 유지보수에 들어가는 높은 비용 등의 많

은 문제점들을 해결할 수 있었다. Web application/web service 기술은 이러

한 web 환경의 장점을 극대화하여 더욱 기민하고 효율적인, 그리고 강력한

business enabler로서 역할을 수행하기 위해 발전되어 왔다. 그 결과로

J2EE, CORBA, SOAP, .NET, SOA, AOP 와 같은 다양한 표준안, platform,

기술 및 각종 vendor들의 제품이 등장하게 되었다.

시장과 기술이 점차로 성숙됨에 따라 이러한 다양한 기술에 대해 검토 및

비판, 개선이 이루어지고 있다. 이 중 많은 시스템의 근간을 이루고 있는 3-

Tier architecture의 단점에 대한 개선책으로 lightweight architecture가 제

안되었고, 이에 대한 활발한 논의 및 기술개발이 이루어지고 있다.

2. Scope

먼저 lightweight architecture의 개념을 hardware 적 측면 과 software적

측면에서 대해서 알아본다. 이후 lightweight architecture를 이루는 대표적

인 framework들을 기술적인 측면에서 소개한다. 마지막으로 기업에서의 적

용사례를 통해 실제 적용 형태에 대해 알아본다.

3. 용어설명용어설명용어설명용어설명

MMMMashashashash----up:up:up:up: 하나 이상의 source를 통해 새로운 콘텐트를 생산해 내는 web

site 혹은 web application

ScaleScaleScaleScale----up:up:up:up: Vertical Scaling이라고도 불린다. 단일의 높은 성능의 server를

통해 연산을 수행하는 환경에서, 높은 처리용량을 확보하기 위해 server 자

체의 기능을 확장함을 의미한다. 주로 고가의 서버가 투입되므로 높은 비용

이 소요되며, 개별 시스템의 한계로 인한 기능확장의 제한이 있다[1].

ScaleScaleScaleScale----out:out:out:out: Horizontal Scaling이라고도 불린다. 연산과 data의 workload

를 load balancing을 통해 복수의 저가 장비로 분산처리를 한다. 투입장비의

수를 조절하여 수행능력을 늘이거나 줄이는 것이 가능하다[1].

LAMP:LAMP:LAMP:LAMP: Linux OS, Apache web server, MySQL DBMS 와 함께

PHP/Perl/Python등의 script 언어를 통해 구현한 web application system

을 뜻한다.

POJO:POJO:POJO:POJO: Pure Old Java Object. 일반적인 java object를 뜻하고, J2EE 환경에

서는 주로 EJB의 대응개념으로 쓰인다. EJB가 EJB Container와 같은 특수


-6/22- 안세원

2006-07-22

환경에서의 동작을 고려하여 작성된다면, POJO는 일반적인 java object로서

범용적인 용도로서의 사용을 고려하여 작성된다. 그러나 container의

transaction, security 와 같은 기능을 사용하기 위해서는 AOP 혹은

container가 제공하는 class의 상속과 같은 부가적인 지원이 필요하다.

IoCIoCIoCIoC (Inversion of Control):::: 객체의 lifecycle 및 구동을 container level에

서 담당하는 것을 뜻한다. 이를 통해 source code에서 container 종속적인

code를 분리해 낼 수 있다. 이를 구현하는 방법에는 Dependency Injection

과 Dependency Lookup이 있다[2].

Dependency Injection: Dependency Injection: Dependency Injection: Dependency Injection: 개별 object이 자신이 의존하는 resource와

collaborator에 대한 lookup을 외부 container를 통해 얻어온다. 대상

object는 특별한 interface나 class의 상속이 필요하지 않기 때문에

framework과 관계없이 동작할 수 있다[2].

O/R O/R O/R O/R Mapping: Mapping: Mapping: Mapping: OO language의 객체와 RDBMS로 대표되는 persistent

layer간의 mapping을 의미한다. 주로 table 이 class, 각 row가 instance로

mapping된다. O/R mapping을 통해 RDB와 application 간의 자료교환의 용

이성 및 향상된 transaction 관리, 성능향상을 기대할 수 있다.

AJAX:AJAX:AJAX:AJAX: Asynchronous Java Script and Xml. Web page 상에서 java script와

XML을 통해 server와 동적으로 비동기 방식 메시지 교환을 하는 작업을 의

미한다.

MVC:MVC:MVC:MVC: Model / View / Controller.

AOPAOPAOPAOP:::: Aspect Oriented Programming.

4. 자료자료자료자료 조사조사조사조사

Lightweight architecture 개념 및 사례조사를 위해 ZDNet, InfoWorld,

Linux World 등의 대형 커뮤니티, 뉴스 사이트의 문헌을 조사하였다.

기술 자료를 위해 J2EE without EJB등의 관련 도서와 Spring Framework,

PHP등의 각각의 기술 커뮤니티 사이트의 문헌을 조사하였다.

각각의 기술과 관련된 기업의 사이트를 통해 시장 동향 정보를 수집하였다.


-7/22- 안세원

2006-07-22

5. Technical Findings

5.1. Lightweight Architecture의 정의

그림그림그림그림 1111 Lightweight Architecture Overview Lightweight Architecture Overview Lightweight Architecture Overview Lightweight Architecture Overview ( ( ( (http://www.activegrid.comhttp://www.activegrid.comhttp://www.activegrid.comhttp://www.activegrid.com))))

[그림1]은 개괄적인 lightweight architecture의 특징을 보여주고 있다. 고가

의 장비로 이루어진 소수의 서버에서 다양한 업무를 수행하는 3-Tier 개념

에서, 저가의 일반적인 PC장비를 통해 비교적 간단한 업무를 수행하는 2-

Tier 개념을 도입하되, 이를 cluster화 하여 충분한 부하를 견딜 수 있도록

한다[3]. 이를 좀 더 자세히 살펴보기 위해 hardware적인 측면과 software

적인 측면으로 나누어 생각할 수 있다. 그러나 두 부분은 서로 구분되는 것

이 아닌, 상호적인 연관관계를 가지고 있다.

- Hardware적 측면에서의 Lightweight Architecture

기존의 전형적인 web application /service 시스템은 [그림2]와 같은 3-

Tier구조를 가지고 있었다.

그림그림그림그림 2222 3 3 3 3----Tier layoutTier layoutTier layoutTier layout


-8/22- 안세원

2006-07-22

Web Server Tier는 html, image와 같은 static content를 저장하고, 사

용자에게 content를 전송한다. 일반적으로 저가 server들의 cluster로 구

성하고, Apache와 같은 web(HTTP) server application으로 구동된다.

Application Server Tier는 JSP등을 통해 dynamic content를 생성하고,

이를 Web Server Tier로 전송한다. IBM, SUN과 같은 대형 vendor들의

고가 장비에, WebLogic 과 같은 중-고가의 server application으로 구동

된다. Data Tier는 주로 RDBMS가 해당되고, content를 생성하기 위한

data를 제공한다. Application Server Tier와 마찬가지로 대부분 고가의

장비를 사용한다.

3-Tier 구조의 경우 Application Tier에 도입되는 대당 장비의 비용이

높기 때문에, 주로 scale-up 전략이 도입된다. 아울러 높은 server

application license 비용도 scale-up 전략을 도입하게 하는 요소이다.

그러나 scale-up 전략 도입 시 정확한 부하 예측을 통한 장비 도입 계획

을 수립하지 못할 경우, 과잉 장비는 기업의 추가지출로 연결되고, 부족

장비는 서비스 품질 저하로 이어질 수 있다. 이러한 정교한 예측은 매우

어렵기 때문에, 기업으로서는 장비 구매에 대한 위험성을 동반하게 된다.

그림그림그림그림 3333 2 2 2 2----Tier layoutTier layoutTier layoutTier layout

이러한 문제를 극복하기 위해 위의 [그림3]과 같은 형태의 Web Server

Tier와 Application Server Tier를 통합한 2-Tier 구조가 대안으로 제시

되었다. 중저가 PC의 성능향상 및 2-Tier 구조에 적절한 application 및

framework의 등장으로 이러한 2-Tier 구조가 가능하게 되었다. 이를 통

해 기업은 고가 서버 도입에 따른 구매비용에 대한 부담을 덜 수 있고,

부하 집중 시 scale-out 전략에 의해 신속하게 지원 서버를 확충 할 수

있다. 또한 좀 더 가볍고 단순한 framework의 도입으로 개발의 생산성

및 관리비용을 줄일 수 있다.


-9/22- 안세원

2006-07-22

- Software적 측면에서의 Lightweight Architecture

비즈니스 환경이 점차 복잡화 함에 따라, 비즈니스 로직도 복잡하게 되

었고, 이것은 개발비용의 증가와 직접적으로 연결되었다. 따라서

Amazon.com과 같은 기업들은 복잡한 비즈니스 로직을 분산하여 처리함

으로써 복잡도를 낮추기 위한 노력을 했고, SOA 및 web service와 같은

개념 및 기술이 도입되었다. 이러한 노력에 힘입어, 개별 서버는 각각의

service로 분산된 업무의 처리에만 집중할 수 있게 되었고, 이것은 더

이상 하나의 서버가 전체 비즈니스 로직을 일괄적으로 처리할 능력을 가

지지 않아도 됨을 의미한다. 이것은 자연스럽게 3-Tier의 거대한 중앙

Application server가 독립된 service를 수행하는 작은 server로 분산되

는 상황으로 연결되었다. 각각의 server의 application은 J2EE + EJB와

같은 복잡한 framework 에서 높은 개발 생산성 과 낮은 소유비용을 가

지는 PHP, ruby on rails, 혹은 Struts, Spring등의 보다 가벼운 J2EE

framework으로 이전할 수 있게 되었다. 또한 개별 service에 가장 알맞

은 framework를 선택하여 적용할 수 있으므로, 이를 통해 전체적인 개

발 생산성을 더욱 높일 수 있다.

위에서 살펴 본 바와 같이, lightweight architecture는 전통적인 3-Tier 에

비해 많은 장점을 가지고 있다. 현재 이슈가 되고 있는 Web 2.0 환경에서는

이러한 lightweight architecture의 장점을 더욱 극대화 할 수 있다.

[그림4]는 Web 2.0 환경에서의 효과적인 서비스 제공을 위한 시스템을 보

여주고 있다. Web 2.0 환경에서는 기존 거대 portal 위주의 web application

에서 고품질의 특징적인 service로 application의 경향이 바뀌었다. 또한

Mash-up을 통해 다른 service들과의 연결에 따른 높은 traffic 부하를 처리

하기 위해 높은 확장성이 필요하게 되었다. 특정화된 business logic을 안정

적으로 제공하고, time-to-market을 달성하는 것이야 말로 대다수의 Web

service 기업들이 lightweight architecture를 선택하는 이유이다.


-10/22- 안세원

2006-07-22

그림그림그림그림 4444 WEB 2.0 WEB 2.0 WEB 2.0 WEB 2.0 환경의환경의환경의환경의 성공적인성공적인성공적인성공적인 시스템시스템시스템시스템 개요개요개요개요 ( ( ( (http://blogs.zdnet.com/Hinchcliffe/?p=54http://blogs.zdnet.com/Hinchcliffe/?p=54http://blogs.zdnet.com/Hinchcliffe/?p=54http://blogs.zdnet.com/Hinchcliffe/?p=54))))

lightweight lightweight lightweight lightweight architecturearchitecturearchitecturearchitecture가가가가 도입도입도입도입을을을을 통해통해통해통해 business goal business goal business goal business goal 달성달성달성달성

5.2. Lightweight Architecture 관련 기술 및 제품

실제적인 Lightweight Architecture와 관련된 대표적인 platform들은 다음

과 같다[4].

1. LAMP: Friendster, Facebook, Flickr 등의 많은 Web 2.0 기업들이

적용하고 있는 대표적인 open source framework 이다. 이미 형성된

넓은 사용자층과 함께 IBM, Oracle 과 같은 vendor의 지원으로 앞으

로도 계속적인 성장이 예측된다.

2. Open Source Java: 기존 EJB 기반의 J2EE 환경에 대한 대안으로 제

시된, lightweight한 J2EE 환경을 이야기한다. Tomcat WAS 와

Spring, 그리고 Hibernate와 같은 open source project를 통해 web

application을 구성한다. E*TRADE와 EBay와 같은 서비스 업체,

CERN과 같은 기관, 금융권들이 open source java를 통해 구동되고

있다.

3. Ruby on Rails: 빠르게 확산되고 있는 framework이고, 손쉽게 AJAX

application을 만들 수 있다. 그러나 아직 대규모 site에서의 안정성이

검증되지 않았기 때문에, enterprise 환경에서 적용하기는 시기상조로


-11/22- 안세원

2006-07-22

판단된다. 그러나 현재 많은 관심을 받고 있고, 기능도 빠르게 추가되

고 있으므로 조만간 enterprise 환경에 도입될 것으로 기대된다.

4. Skinny .Net: Schwab, JetBlue과 같은 회사들은 .Net framework의

특정 요소들을 선별 적용하여 lightweight한 framework으로 사용하

고 있다. .Net framework는 훌륭한 IDE와 XML 환경 및 높은 생산성

을 갖추고 있다. 그러나 비록 Windows OS가 저가 machine에서 가동

이 가능하지만, 대형 cluster나 grid에 적용하는 문제에 대해서는 아

직 논란의 여지가 있는 실정이다.

위의 platform 중 대표적인 LAMP와 open source java, Ruby on Rails에 대

해 자세히 알아본다

5.2.1. LAMP

LAMP는 대표적인 open source product의 조합을 일컫는 용어이다. OS로는

Linux를 사용하고, web server로 Apache를, application script로

PHP/Perl/Python을 사용하고, DBMS로는 MySQL를 사용한다. 위의 4가지

서로 다른 application의 조합으로 전체적인 하나의 서비스를 구현할 수 있

다. LAMP는 모두 open source이므로, 구현에 따르는 license 비용이 전혀,

혹은 아주 적게 든다.

Linux는 이미 기업용 시장에 널리 사용되고 있고, 빠르게 Unix를 대체하고

있다. Redhat과 같이 기업용으로 특화된 Linux뿐 아니라 일반적인 Linux 배

포판도 이미 수많은 기업에 도입된 상태이다.

Apache는 대표적인 HTTP server이다. 이미 오랜 시간 동안 기업용 HTTP

server로 사용되어 왔다. 2005년도의 Netcraft 의 통계결과를 통해 전체 가

동중인 Web Server의 70% 이상이 Apache를 사용하고 있다는 것을 알 수

있다. 이러한 결과를 통해 우리는 Apache HTTP server가 뛰어난 안정성

및 성능을 가지고 있음을 알 수 있다.

MySQL은 계속적인 버전업을 통한 기능 및 안정성 향상과, 저렴한 license

를 통한 scale-out 환경에서의 유리함을 통해 기업용 Database 시장에서

큰 비중을 차지하고 있다. 2005년 Evans Data의 survey를 통해 MySQL이

현재 사용중인 DBMS 중 33.7%를 차지하고 있음을 알 수 있다.

Dynamic content를 생성하는 부분은 Perl, Python, PHP의 script 언어들이

다. 이들 중 가장 web 개발에 적합하고 많이 사용되는 언어는 PHP이다.

PHP는 개발 생산성이 높고, stateless한 특징을 통해 scale-out에 용이하다.

비록 Object orient적인 특성이 없고, 소스코드의 가독성과 유지보수의 문제

가 지적되었으나, PHP 5 버전의 도입과 함께 OOP로 변화하였고 계속적인


-12/22- 안세원

2006-07-22

성능 및 언어 개선으로 이러한 문제는 점차 해결될 것이다.

5.2.2. Spring

Dependency Injection을 통한 IoC, AOP등의 최신 programming 경향을 반

영하여 EJB가 제공하는 다양한 기능을 제공하고 있어, J2EE환경에서 EJB의

대안으로 가장 주목되는 framework이다

그림그림그림그림 5555 Local EJB architectureLocal EJB architectureLocal EJB architectureLocal EJB architecture[[[[5555]]]]

[그림6]은 local EJB architecture를 보여주고 있다. EJB container와 그 내

부의 Session EJB, Entity EJB 를 통해 business logic을 수행한다. 이에 반

해 [그림7]의 lightweight J2EE architecture는 DBMS와 O/R mapping 을

통해 자료를 교환하고, 일반 business logic은 POJO를 통해 구현한다. 이러

한 POJO object의 lookup 및 실행은 container가 수행하고, 이 과정에서

IoC, AOP의 container 특징적인 기능이 추가된다.

[그림7]을 Spring에 적용한다면, Hibernate 또는 JDO와의 integration이

O/R Mapping layer에 해당한다. POJO를 business object로 사용하고, 이를

가능케 하기 위해 IoC를 이용한다. UI Tier에서는 일반적인 JSP를 사용하고

있다.


-13/22- 안세원

2006-07-22

그림그림그림그림 6666 Lightweight J2EE architecture Lightweight J2EE architecture Lightweight J2EE architecture Lightweight J2EE architecture[[[[5555]]]]

Spring의 다른 장점은 proxy-based AOP를 통한 AOP 지원이다[6]. Target

object에 대한 proxy를 통해 대상 aspect를 찾아내어 이를 수행한다. 이를

통해 transaction, security등의 공통적인 issue를 source code에서 분리하

여 일괄적으로 관리할 수 있고, source code는 business logic 자체에 집중

할 수 있다.

EJB 대체제적인 성격을 통해 Spring은 Bank of America, 프랑스의 web 기

반 세무신고 system 같은 mission critical 한 system에 적용될 수 있었고,

앞으로도 많은 부분에서 EJB를 대체할 수 있을 것으로 전망된다.

5.2.3. Hibernate

Hibernate는 JBoss가 지원하는 open source project로서, Java의 O/R

mapping의 대표적인 application이다. 기존 JDBC를 통한 RDB와

application 사이의 data 전송 시, 서로간의 data type이 다르기 때문에 많은

작업이 필요하였으나, O/R mapping tool을 이용함으로써 이러한 반복작업을

줄일 수 있다. 이를 통해 생산성을 향상시키고, DB vendor에 독립적인

application 개발이 가능하다. Hibernate는 기존 J2EE architecture와의

integration이 가능하고, 새로 발표된 EJB 3.0을 지원한다. 또한, web 기반

환경이 아닌 일반적인 JDBC 관련 application에 범용적으로 적용할 수 있다.


-14/22- 안세원

2006-07-22

그림그림그림그림 7777 Hibernate Hibernate Hibernate Hibernate ArchitectureArchitectureArchitectureArchitecture[[[[7777]]]]

[그림8]은 Database를 사용하는 일반적인 Application Architecture 중에

Hibernate Architecture의 diagram을 보여준다.

Application의 객체들은 그 lifecycle에 따라 transient object와 persistent

object로 나뉘고, 이들 중 persistent object는 외부 DBMS나 file system을

통해 저장되고 불려질 수 있어야 한다.

이를 위해 Hibernate는 RDB와의 connection은 JTA, JNDI, JDBC 를 사용

하고, 객체와의 mapping 및 session 관리를 수행한다. Session 관리를 위해

JDBC, JTA등의 기본적인 transaction을 추상화 한 연관 작업의 최소단위를

나타내는 transaction과, 좀 더 긴 작업단위인 session을 가지고 있다.

Hibernate는 XML을 통해 OR mapping table을 정의한다. 이런 XML문서는

수동, 혹은 third party에서 제공하는 XDoclet등의 도구를 이용하여 보다 효

율적으로 작성할 수 있다.

5.2.4. Tomcat

Tomcat은 Apache software foundation에서 만든 java servlet container이

다. Tomcat은 최신의 JSP와 Servlet spec을 준수하고 있고, 현재는 Servlet

2.4, JSP 2.0을 지원하는 5.5 버전이 배포되고 있다. Open source servlet

container의 de facto 표준이라고 할 수 있다.

Version 5 의 tomcat은 자체적으로 clustering과 load balancing 지원 기능


-15/22- 안세원

2006-07-22

을 포함하고 있으므로, tomcat을 이용한 clustering을 더욱 손쉽게 구현할

수 있다. Cluster간 상호 통신은 IP multicast를 이용한다. 또한 farming을

통해 Cluster 내부의 application deploy를 지원한다. Load balancing은

Apache를 이용하거나, 자체적인 balancer web application을 통해 수행한다.

5.2.5. Ruby on Rails

Ruby는 OOP를 지원하는 scripting 언어이다. 대부분의 OS 상에서 구동이

가능하고, 높은 생산성으로 인해 빠르게 사용자층을 확대해 가고 있다. Ruby

가 장점으로 내세우는 점은 다음과 같다.

- Eiffel과 Ada에 부분적으로 영향을 받은 단순한 문법

- Java, Python과 같은 exception handling

- Full, pure OOL.

- Closure 개념

Rails는 Ruby를 기반으로 만들어진 web application framework 이다. MVC

model에 기반을 두고 있고, Ruby의 언어적 특성을 이용하여 빠른 web

application 개발에 중점을 두고 있다. 자동화된 template을 이용하여 code

generation을 해 주므로, 실제 개발자가 작성해야 할 code의 많은 부분을

줄여준다.

Rails의 주요 디자인 개념은 DRY와 convention over configuration이다.

DRY는 Don’t repeat yourself를 의미하고, code의 중복을 최소화하라는 의

미이다. Convention over configuration은 프로그래머는 일반적이지 않은 부

분에 대해서만 configuration 처리를 하고, 그렇지 않은 부분에 대해서는 굳

이 configuration을 설정하지 않아도 된다는 의미이다.

Rails를 구성하는 요소는 다음과 같다[8].

- Active Record: Model을 담당함과 동시에, Rails의 O/R Mapping layer

로 동작한다. DB Table에 대응되는 class를 생성하고, DB row에 해당

하는 instance를 만든다

- Action Pack: MVC모델의 view 와 controller를 담당한다.

View는 static HTML과 ERb(Embedded ruby)로 이루어진 ruby

snippet으로 작성하거나, builder-style view로 작성할 수 있다.

Controller는 특정 request를 내부의 action에 mapping한다. 부가적으

로 caching, session 관리 및 helper module 제공을 통해 view

template의 기능을 확장시킨다.

- Prototype: web page상에서의 다양한 동적 효과를 위한 DHTML


-16/22- 안세원

2006-07-22

component이다.

- Action Mailer: e-mail 처리를 위한 component이다.

- Action Web Service: SOAP, XML-RPC, WSDL등의 web service를 지

원하기 위한 component이다.

[그림9]는 Rails에 request가 요청되었을 때의 처리 flow를 보여준다.

그림그림그림그림 8888 Rails process flow Rails process flow Rails process flow Rails process flow [[[[8888]]]]

HTTP request가 Rails에 요청되었을 경우, 이를 Store Controller가 해석하

여 해당 로직을 수행한다. 이는 Rails의 Action Pack이 담당한다. 이 과정에

서, RDB를 통해 정보를 가져와야 할 경우, Active Record를 통해 O/R

mapping을 수행한다. 작업 후 화면 표시를 위해 다시 Store가 View에 연결

을 하고, 화면을 구성하여 사용자의 browser에 이를 표시하게 된다. E-mail

처리가 필요할 경우 Action Mailer, web service interface 제공이 필요할

경우 Action Web Service를 적용하여 원하는 작업을 처리할 수 있다.

Rails는 Apache나 lighthttpd 상에서 fast cgi로 동작한다.

6. Lightweight Architecture 적용적용적용적용 사례사례사례사례 분석분석분석분석

6.1. WEB 2.0 시대의 신생 기업들

2005년에 나타난 WEB 2.0은 web service 업계에서의 중요한 화두가 되어

왔다. WEB 2.0이 가져온 새로운 경향들 중, mash-up service 제공 기업들

은 lightweight architecture를 도입하여 빠른 고객 대응 및 관리비용 절감에

성공했다. 또한 lightweight architecture를 통한 적은 starting cost는 이러

한 회사들이 탄생하는 토대가 되었다. 이러한 점에서 lightweight

architecture는 그들의 비즈니스에서 중요한 부분을 차지하고 있다고 할 수

있다.

- FlickR ( http://www.flickr.com )


-17/22- 안세원

2006-07-22

FlickR은 가장 성공적인 사진 공유 사이트이다. 2005년 2월의 통계에서

당시 270,000명의 등록 사용자와 4백만 장의 사진을 보유하고 있었고,

이후로도 가파른 성장을 하였고, yahoo에 M&A 되었다.

FlickR의 서비스에서 가장 큰 문제는 scaling이다. 그래서 FlickR은 PHP,

MySQL을 사용한 scale-out 전략을 사용하였다. PHP의 stateless한 특

징을 이용하고, 모든 정보를 DB에 저장함으로써 효과적인 scale-out 전

략을 도입할 수 있었다. [그림10]의 FlickR architecture 에서 PHP가

FlickR의 전체 architecture의 많은 부분에 사용되고 있음을 알 수 있다.

그림그림그림그림 9999 FlickR system architecture FlickR system architecture FlickR system architecture FlickR system architecture ----검은검은검은검은 박스가박스가박스가박스가 PHP PHP PHP PHP가가가가 사용된사용된사용된사용된 부분부분부분부분[[[[9999]]]]

- Friendster( http://www.friendster.com )

Friendster는 2003년 3월에 운영되기 시작한 커뮤니티 사이트이다. 3천

만 명이 넘는 회원을 보유하고, 2005년 일당 page view가 6천만에 이르

는 거대 사이트가 되었다. 그러나 규모의 급성장에 따른 속도문제로 인

해 서비스의 질이 떨어지게 되었다. 그래서 이를 해결하기 위해 기존의

Java 환경을 대체하여 LAMP 기반으로 이전을 하기로 결정했다. PHP를

선택한 가장 큰 이유는 scale-out의 용이성 때문이었다.

기존의 system은 Tomcat 서버 기반의 Java 시스템이었고, 보다 큰 문

제는 내부적인 architecture의 문제에 기반하고 있었다. 그들은

architecture를 변경을 통해 LAMP 기반의 새로운 system으로 이전함으

로써 고객에게 보다 안정적인 서비스를 할 수 있었다[10].

위의 두 기업의 예를 통해, lightweight architecture를 통한 scale-out

전략이 높은 traffic의 사이트에 효과적으로 적용 될 수 있음을 알 수 있

다.


-18/22- 안세원

2006-07-22

6.2. Reuters – 거대 뉴스, 정보 제공 사업자

Reuters는 1851년 설립된 뉴스, 기술적인 솔루션, 경제 정보 등을 전세계적

으로 제공하는 정보 제공 사업자이다. 비록 Reuters가 일반 대중에게 뉴스

제공업체로 알려져 있지만, 실제로 그들의 수익의 90% 이상은 금융 서비스

업체들로부터 들어오고 있다. 따라서 Reuters가 그들의 수익을 증가시키기

위해서는 전세계 445,000명에 이르는 금융전문가들에게 어떻게 그들의 정보

를 신속하고 정확하게 전달하는가에 달려있다.

이러한 그들의 목표를 위해, Reuters는 Microsoft사의 Windows 2003 와.

NET framework 기반의 lightweight architecture를 도입하였다[11]. [그림

11]에서 각 분산 노드는 data의 전달 및 외부 서비스와의 integration을 수

행할 수 있다. 이때의 integration은 web service를 통하여 수행하고, 각각

의 분산노드는 Windows Server 와 IIS로 운영된다.

그림그림그림그림 10101010 Reuters Reuters Reuters Reuters 시스템의시스템의시스템의시스템의 분산분산분산분산 노드노드노드노드 구조구조구조구조[[[[11111111]]]]

기존의 대형 UNIX 시스템에서 Windows Server의 분산 노드 구조로 이행함

으로써, Reuters는 유지보수 비용, 개발 및 서비스 integration에서의 이득을

확보할 수 있었고, 이러한 구조 변경을 통해 더 좋은 사업 기회를 얻을 수

있었다.

Any Distribution Node

IIS 6.0

Input

Cache Manager

Output

Windows Server 2003

ROSI

API

Microsoft .NET

Framework

Value

Added

Service

Web Service

Presentation


-19/22- 안세원

2006-07-22

7. 결론결론결론결론

Lightweight architecture를 통해 고가의 server machine이 아닌 저가의 일

반 컴퓨터의 clustering을 통해 enterprise급의 서비스를 제공할 수 있다.

각각의 node PC에 LAMP나 open source Java등의 framework를 적용하여

이들을 cluster로 연결하여 전체적인 서비스를 구성한다. 이렇게 저가 컴퓨

터를 이용하여 cluster를 구성함으로써, 기업은 서버의 부하에 신속하게 대

처할 수 있고, 대형 서버의 구입비 및 유지비, 그리고 고가의 server

application에 대한 license 비용을 줄 일 수 있다.

이러한 architecture는 그 우수성이나 성능은 입증되었지만, 선뜻 기업 환경

에 적용하기에는 환경적인 어려움이 따르는 것이 사실이다. 그러나 최근의

성공사례나, 대형 vendor들의 적극적인 Support(BEA의 Spring 지원, IBM

의 PHP 지원, Accenture의 Spring 컨설팅)를 통해, 이들이 enterprise규모

의 업무 수행에 있어서 충분히 경쟁력이 있음을 알 수 있다.

기존 대형시스템 의존적인 환경에서는 하나의 application server에 모든

service를 갖추고 있었다. 이에 따른 application 자체의 복잡성 및 개발의

어려움은 service 자체가 점차로 고도화 하고 있는 현재의 기업시스템에서

의 가장 큰 문제점으로 지목할 수 있다. 이러한 문제를 해결하기 위해 SOA

등의 개념을 통해 집중적인 서비스를 분산시키는 것이 기업 시스템의 화두

이고, 이러한 분산적인 service 환경에서 lightweight architecture의 도입이

더 큰 설득력을 갖고 있음은 명확한 사실이다.


-20/22- 안세원

2006-07-22

8. 참고문헌참고문헌참고문헌참고문헌

[1] MySQL, Guide to Cost-effective Database Scale-Out using MySQL,

http://www.mysql.com/why-mysql/mysql_power.html

[2] Johnson R, Hoeller J, Expert One-on-One J2EE Development without

EJB. 2004, Indianapolis: Wiley Publishing Inc

[3]Peter Yared, Lightweight architecture, ZDNet

http://news.zdnet.com/2036-2_22-6048210.html

[4] InfoWorld, Google, Amazon, and Yahoo! point enterprise developers

towards "lightweight" architecture,

http://weblog.infoworld.com/openresource/archives/2006/01/google_ama

zon_a.html

[5] John Arthur, Shiva Azadegan, Spring Framework for rapid open

source J2EE Web Application Development: A case study, IEEE

Computer Society

[6] Rod Johnson, Juergen Hoeller, The Spring Framework: Introduction

to Lightweight J2EE™ Architecture, JavaOne conference

[7] Hibernate Reference,

http://www.hibernate.org/hib_docs/v3/reference/ko/html_single/

[8] Dave Thomas, David Heinemeier Hansson, Agile Web Development

With Rails, The Pragmatic Programmers, 2005

[9] Cal Henderson, Flickr and PHP,

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf

[10]Cathleen Moore , Friendster adopts open source , LinuxWorld

http://www.linuxworld.com.au/index.php/id;1007522249;fp;4;fpid;4

[11] Microsoft, Reuters Lightweight Architecture Improves

Manageability and Expands Market Reach,

http://download.microsoft.com/download/5/d/1/5d14fee4-1b42-4e7f-

b72d-749ea396e38d/cs_reuters_en.pdf

[12]IBM, Secrets of lightweight development success

http://www-

128.ibm.com/developerworks/views/opensource/libraryview.jsp?search_b

y=secrets+of+lightweight+development+success


-21/22- 안세원

2006-07-22

9. 참고자료참고자료참고자료참고자료

9.1. 기타 lightweight J2EE application

본문에서 다루지 않은 대표적인 lightweight J2EE application/framework는

아래와 같다.

- JDO 구현체: Hibernate와 같은 O/R mapping을 위한 JDO spec의 구현

체로, 대표적으로 Kodo JDO를 이야기 할 수 있다. BEA로 합병되어

WebLogic 9.5의 일부분으로서 제공된다.

- PicoContainer: Spring과 같은 IoC 구현 container이다. DI를 통해 객

체 생성 및 연관성 관리를 수행한다.

- HiveMind: Spring과 같은 IoC 구현 container이다. Microkernel과 이

를 통해 POJO를 이용하여 logic을 수행하는 Servce로 구성되어 있다.

- Struts: web application에 MVC를 구현하기 위한 framework. 현재 가

장 널리 쓰이는 경량형 framework이나, Spring으로 빠르게 대체되고

있는 추세이다.

9.2. Dependency Injection 추가설명

Spring, HiveMind 와 같은, 최신 container의 장점으로 부각되는

dependency injection에 대한 추가설명을 theserverside.com 의 A

beginners guide to Dependency Injection에서 발췌, 해석하였다. 원문은

http://www.theserverside.com/tt/articles/article.tss?l=IOCBeginners 에서

읽을 수 있다.

Software components (Clients)는 그들의 목표 달성을 위해, 종종 연관

component (Services) 묶음의 일부로 동작하기도 한다. 많은 경우, 이러한

component들은 “어떤” component와 통신하고, “어디에” 이러한 component

를 위치시키고, “어떻게” 그들과 통신할 지 알아야 한다. 이러한 Service가

변화될 때, 이러한 변경들은 많은 client들의 source code 단의 변경을 요구

하기도 한다.

Code를 구조화 하는 방법 중 하나는 client들이 그들의 logic의 일부로서 이

러한 service를 위치시키고, service를 생성하는 logic을 포함하는 것이다.

다른 방법으로는 client들은 자신의 service 의존성만을 선언한 후, 다른 “외

부” code로 하여금 service를 위치시키고 생성하는 로직을 선언하고, client

가 필요로 할 때 적절한service를 제공하도록 하는 것이다. 후자의 방법에서


-22/22- 안세원

2006-07-22

는, 일반적으로 외부 의존 요인을 위치시키는 방법이 바뀌어도 client code

가 바뀔 필요가 없다. 이런 종류의 구현을 Dependency Injection이라고 하

며, 이때 필요한 “외부” 코드는 수동으로 작성되거나 DI 지원 framework를

통해서 지원된다.

수년 전부터 interface와 implementation을 분리시키려는 움직임이 있었다.

비록 Factory pattern을 통해 객체 생성에 대한 복잡성은 감출 수 있었지만,

service를 “위치”시키는 내용은 client에 남아있었다. 더욱이 어떤 경우에는

다양한 service 간의 의존관계에 대해 고려해야 했고, 이는 component들의

생성 순서와 life cycle 관리에 어려움을 초래했다.

Dependency Injection은 우리가 작성하는 software가 의존관계를 정의하고,

container 혹은 framework를 통해 service 생성, 순차적 배열, 에 따르는

복잡성을 없애게 했으며, 필요한 경우에 client에 service를 제공하도록 했

다.

lightweight architecture in web application

Documents