n-tier에 해당되는 글 1건

2011.03.08.Tues 아키텍처 발전역사

방법론로그/OOAD 2011. 3. 8. 23:30




소프트웨어 아키텍처는 연결되는 노드(컴퓨터)의 구성,  그로 인한 데이터 보안성과 공유성, 그리고 
데이터와 (처리)절차의 관점에서 바라보면 그 흐름을 쉽게 이해할 수 있다. 이 점에 초점을 맞추어 아키텍처의
발전역사를 알아보자. 


1. standalone
가장 초기의 SW 아키텍처로  독립적인 머신 단일머신에서 동작하는 형태이다.  
하나의 컴퓨터에 (프로그램의) 절차와 데이터가 모두 존재한다.
 


단일머신에 데이터가 존재하기 때문에 보안적으로 안전하지만, 해당 PC 사용자만이 데이터를 사용할 수 있다. 
즉 데이터의 공유성이 좋지 않다.  공유성 문제를 해결하기 위해 2-Tier 아키텍처가 등장하게 된다. 



2.  2-Tier
절차를 가지는 노드와 데이터를 가지는 노드가 분리되어 네트웍으로 연결된 아키텍처이다.
다수의 공유가 가능하게 되었지만,  다수의 사람들이 동일한 데이터에 접근하여 수정하여 되면, 데이터가 망가지게 된다. 
그래서 DataBase를 관리하는 시스템인 DBMS(DataBase Management System)을 두어,  동시 사용자들간에도 데이터를 이상없이
(무결성) 다룰 수 있도록 한다.  (Data+Base는 Data를 저장하고 있는 기지라는 의미를 갖는다. )
 



공유성 문제는 해결이 되었지만,  처리절차의  변경 요구사항이 생겼을 때,  모든 클라이언트 모두를 업데이트 해주어야 한다. 
유지보수의 관점에서는 엄청난 비용이 드는 문제점이다. 문제의 원인은  변경의 대상이 되는  절차가 모두 클라이언트 내에 
존재하기 때문이다. (비지니스 로직을 포함하는 이런형태의 클라이언트를 Fat 클라이언트라 한다.)
이 문제를 어떻게 해결하였을까? 다음 세대의 아키텍처를 알아보자.  



3. 2-Tier + Procedure
처리절차(비지니스 로직)를 Database에  포함시키도록 하여 유지보수 문제를 해결하였다.  처리절차를 다루는 요소를 
Procedure 라고 하며,  대부분의 현대 DBMS 에 지원하고 있다.  클라이언트는 처리로직을 가지고 있지 않으며, 단지 
Database에 접근하기 위한 인터페이스로서만 동작하게 되며 이런 형태를 Thin 클라이언트라 한다. 
(초창기 데이터베이스 시장은 Informix가 선점하고 있었으나,  Oracle 이 Procedure를 통해 시장 주도권을 장악할 수 있었다.)


유지보수의 문제를 멋지게 해결해주었지만, 그에 따른 문제가 발생하였다. 인터넷의 등장 그리고  클라이언트 PC 의 급증으로
절차와 데이터가 함께 있는  형태는 장점이자 시스템의 속도를  너무 느리게 하는 단점으로 작용하였다.  이 문제를  어떻게 
어떻게 해결하였을까? 다음세대의 아키텍처를 알아보자.  




4. 3-Tier
결합되어 있는 처리절차를 다시 분리하여, 처리절차를 전담하는 AS(Application Server)에 할당하여 구성한 아키텍처 형태이다. 
이후에는 다수의 AS 노드와  DataBase 노드를  클러스터링하여 병렬시스템으로 구축한 소위 N-Tier 아키텍처가 유지된다. 





5. 아키텍처의 발전역사
지금까지 알아본 아키텍처의 발전역사를 전체흐름은 아래 그림과 같다. 



(처리)절차와 데이터의 관점으로 보았을 때,   아키텍처 발전의 역사는 정반합의 연속임을 알 수 있다.  
(정반합이란 헤겔의 변증법을 도식화한 논리전개 방식의 하나) 

절차와 데이터가 한데 모여 있었던 standalone에서는 데이터 공유문제를 해결하기 위해 데이터와 절차를 2-tier구조로 
분리하여 해결하였다. 하지만 공유의 문제는 해결했지만,  유지보수성 문제가 발생하였다.  해결책으로 분리된 절차를
데이터베이스의 Procedure 형태로 결합하여 해결하였다. 하지만, 인터넷의 등장과 수많은 사용자들의 발생으로  데이터와 
절차의 결합은 다시 성능의 문제를 가져왔고, 절차를 AS(Application Server)로 분리하여 이 문제를 해결하였다. 
이상과 같이 아키텍처의 역사를 절차와 데이터의 관점에서 정반합의 연속으로 바라보면 이해하기 쉬워진다. 












컴퓨터의 신호전달 과정 
그 옛날 정보전달을 위해 사용되었던 봉화 => 불꽃 연기의 피어오름의 유무를 통해 정보전달 하였다. 
이때 불꽃이 어디서 피어오르는지(불꽃의 위치), 불꽃의 개수, 불꽃의 순서가 중요한 의미를 가지게 된다.  
(이진수를 사용한 정보전달의 시초) 




컴퓨터 내외부에서 일어나는 모든 정보전달은 전기를 통해서 일어난다.  키보드 자판을 두드려서  일어난 신호는 
전선을 통해 컴퓨터에 전달이 되며, ADC(Analog Digital Converter)에 의해 디지털 신호로 변경된다.  이 데이터는 
메모리 공간에 저장이 되며, 두뇌가 되는 CPU에 의해 해석이 된다. 
출력은 CPU에 의해 출력정보가 메모리에 저장이 되며, 이 정보가 Driver를 통해 아날로그 신호로 변환되고,  다시 전선을
통해 모니터로 전달이 된다. (모니터에선 다시 디지털로 변경하여 최종출력을 할것이다.)

메모리에 대한 접근은 반드시 OS를 통해서 이루어진다. 사용자는 직접적으로 메모리에 접근할 수 없다. 



HAL과 Driver
Driver는 HAL(Hardware Abstract Layer)의 구현체이다. 동일한 운영체제가 다양한 머신에서 동작하기 위해서는 각각의 머신을
제어할 수 있는 정보를 알고 있어야 한다. 하지만 수많은 하드웨어 정보를 운영체제가 포함하기에는 정보량이 너무 많아지게
된다.  그래서 HAL이라는 추상화 계층을 두어 운영체제는 특정 하드웨어에 종속적이지 않는 명령으로 하드웨어와 통신하려
한다.  각 하드웨어 제조사들이 제공하는  HW 제어정보를 담은 Driver는 이  HAL 계층에 결합 되어 실제적으로 하드웨어를
제어하는 나머지 퍼즐조각으로서 기능한다.   kenerl 입장에서는 HAL로 인해  어떤 하드웨어를 사용하는지 모르고도, 미리
정해진 표준화된 규칙을 통해 하드웨어를 제어할 수 있게된다. 
ex) 누가 일을 하는지에 상관없이 일을 할수 있게된다. 




API(Application Programming Interface) 
무엇인가 컴퓨터의 기능을 사용하기 위해서는 반드시 OS를 거쳐야 한다. 그리고 기능들은 각각 일련의 절차들로
구성되어 있다.  OS의 기능을 사용할 수 있도록, 절차들을 묶어내어 제공하는 것이 API이다. 
ex) 일이 어떤  절차로 구성되어 있는지 상관없이 그 일을 할 수 있게된다. 

※ 추상과 인터페이스는 프로그래밍에서 중요한 의미를 갖는다. 추상과 인터페이스가 무엇이며, 이들이 어떻게 
다르며 어떤경우에 사용되는지를 잘 알아두자. 



알고리즘 vs  자료구조
알고리즘과 자료구조는 어떻게 다른가? 
알고리즘이란 문제를 해결하는 절차이다. 문제를 다루다 보면 데이터를 다루게 다루게 되며, 이 데이터를 어떻게 
정리하느냐에 따라 문제해결을 빨리 할 수도, 느리게 할 수도 있다. 즉 자료구조란 문제를 빨리 해결하기 위해 데이터를
정리하는 방법이라 할 수 있다. 데이터란 절차 안에서만 그 의미를 갖기 때문에 절차로서의 알고리즘과 데이터로서의
자료구조는 뗄수야 뗄수 없는 관계에 있다. 






'방법론로그 > OOAD' 카테고리의 다른 글

방법론(methodology)  (0) 2011.04.12
2011.03.08.Tues 아키텍처 발전역사  (0) 2011.03.08
[OOAD] 요구사항 수집부터 분석까지  (0) 2010.12.13
[OOAD] 아키텍처, IA , 화면기준안, 스토리보드  (1) 2010.12.13
, , , , , , , , , , ,
트랙백 0개 , 댓글 0개
1

티스토리툴바