위키원
아키텍처
아키텍처(Architecture)는 시스템의 물리적 또는 기능적 구조를 말한다. 하드웨어 아키텍처와 소프트웨어 아키텍처가 있으며, '아키텍쳐’가 아닌 ‘아키텍처’가 올바른 표기법이다. 아키텍처를 설계하고 관리하는 사람을 아키텍트(Architect)라고 한다.
목차
개요[편집]
아키텍처는 고대 그리스어에서 건축 혹은 석공 명인(Master)을 의미하는 아키텍톤(Architecton) 이라는 용어로부터 유래되었다. 당시의 아키텍처는 건축물의 골격을 제공하는 설계도 역할을 했다. 좋은 아키텍처는 훌륭한 건축물을 탄생시켰고, 이들은 인류의 훌륭한 유산으로 남겨지고 있다. 고대의 아키텍처 개념이 화강암과 대리석으로 건축물을 짓는데 적용되었다면, 산업 시대에는 건축뿐만 아니라 첨단 과학기술을 이용하여 항공기, 자동차, 선박 등을 개발하는데 적용되어 왔다. 오늘날 디지털 정보화 시대에는 첨단 정보기술을 이용하여 정보체계, 소프트웨어 내장형 체계, 지휘 통제 통신체계 등을 구축하는데 적용되고 있다. 특히, 컴퓨터나 네트워크에서 말하는 아키텍처란, 프로세스와 전체적인 구조나 논리적 요소들 그리고 컴퓨터와 운영체계, 네트워크 및 다른 개념 간의 논리적 상호관계 등을 생각해내고 정의하는 등, 모든 곳에 적용되는 용어이다. 아키텍처는 OSI 7 계층처럼 하나의 참조 모델이 될 수도 있지만, 특정 제품의 구조를 위한 모델을 의미하거나, 특정 제품의 구조가 될 수도 있다. 또한, 아키텍처는 대상에 대한 구조뿐만 아니라, 대상 구조의 유지 관리를 위한 원칙과 지침, 그리고 향후 목표 아키텍처로 가기 위한 계획을 포함하고 있다.[1] [2] [3]
특징[편집]
아키텍처는 요구사항과 구현 사이 중요한 다리 역할을 한다. 시스템의 추상적 묘사를 통해 아키텍처는 다른 것들을 숨기고 어떤 속성들을 노출하는데 이상적으로 이런 표현은 전체 시스템을 따라갈 수 있는 가이드를 제공하며 설계자가 시스템이 어떤 중요한 요구사항을 만족시킴에 대한 근거를 제공할 수 있게 한다. 또한 명시적으로 설계를 지배하는 의도나 원리를 잡아내어 시스템의 구조와 조합에 대한 청사진을 보여준다.
시스템에 대한 가이드를 제공하는 것은 이해관계자나 개발 동료 간 의사소통에 도움을 주는 장점이 있다. 성능이나 보안, 안정성, 이용 가능성, 유지 가능성 등에 대한 만족 근거를 제공하는 것에 더 큰 목적을 가진다. 구현이라는 비용 리스크가 큰 프로세스 이전에 설계를 통해 요구사항을 달성할 수 있음을 보이는 것은 프로젝트의 리스크를 줄이는 데 큰 도움이 된다. 그리고 설계 의도와 원리에 대해 청사진을 명시적으로 보여줌으로써 만들고자 설계 목적과 방향에 대한 합의를 이룰 수 있게 된다. 이 외에도 대규모 재사용(Large-scale reuse)을 가능하게 하며 특히, 같은 도메인에서는 비슷한 아키텍처가 적용 가능하다는 점에서 아키텍처 설계를 잘하는 것이 비즈니스적으로도 이득이 되는 자산이 될 수 있게 된다. 마지막은 진화(Evolution)로, 이 부분은 생산라인(Product line)과 같이 하나의 제품을 계속해서 발전 시켜 나가거나 그 제품에 기반해 또 다른 새로운 제품을 만들어 내는 경우 설계 시 확장할 수 있는 바운더리에 대한 분석도 같이하게 되는데 그런 점에서 판단을 도울 수 있고, 그 외 기능을 확장하는 서비스의 경우에도 미리 확장 가능성을 고려해서 설계해 영향력을 판단할 수 있다.[4]
아키텍처 패턴[편집]
아키텍처 패턴(Architecture pattern)은 아키텍처를 설계할 때 반복되는 유사한 조직적인 패턴이나 설계 스타일을 뜻하며, 아키텍처 스타일(Architecture style)이라고도 한다. 아키텍처 스타일은 전체 시스템의 구조 및 설계모형을 재사용하기 위한 구체적이며 체계적인 재사용 규약이다. 모든 종류의 시스템 설계에 적용할 수 있다. 이러한 아키텍처 스타일을 중심으로 설계작업 초기에 적절한 아키텍처 스타일을 적용하여 이를 통해 시스템의 구조 및 제약조건을 분석할 수 있다. 아키텍처 스타일은 단순한 블록도(Block Diagram)를 이용하여 구조를 기술하고 이에 대한 구체적인 특징을 설명하는 것으로 표현된다. 하지만 실제 설계작업에서 사용하는 경우에는 각각의 구현상 특징별로 구체적인 방안까지 설계할 수 있어야 한다. 아키텍처 스타일은 메리 쇼(Mary Shaw)와 데이비드 갈란(David Garlan)에 의해 제안되었으며, 시스템 차원의 설계모형 재사용을 위해 많이 사용되고 있다.[5]
- 파이프와 필터(pipes & filters)
- 파이프와 필터 스타일은 각 입력데이터를 파이프 구조를 통해 일련의 컴포넌트로 전달하면서 중간마다 특정 용도로 설계된 필터 역할을 하는 컴포넌트들이 각각의 작업을 통해 데이터를 변환하여 최종적으로 출력데이터를 생산하는 구조를 갖는 것이다. 또한 데이터 처리 중에 시스템의 특성에 따라 불필요한 컴포넌트를 거치지 않거나 특별한 처리를 해야 하는 데이터에 한정적인 처리를 하는 컴포넌트를 추가하는 등의 처리가 가능하다. 따라서 복잡한 데이터 처리와 대용량의 트랜잭션을 효율적으로 처리하면서 가변적인 유연성을 유지할 수 있게 한다. 장점으로는 몇 개의 필터를 단순 합성하여 시스템의 전체적인 입력과 출력 행동을 설계 할 수 있다. 필터 컴포넌트의 수정으로 확장성 높은 유연성을 가져, 새로운 필터 컴포넌트를 추가하거나 통합하는 것이 가능하다. 또한 각 필터 간에는 컴포넌트 간 독립적인 인터페이스 구조를 통해 다양한 시스템에 적용할 수 있는 재사용성을 가진다. 응답성과 데드락 분석이 가능하며 각 필터는 독립적으로 동시 수행이 가능하여 파이프라인의 크기만큼 동시 수행을 통한 효율 증진이 가능하다. 단점으로는 요구사항의 변화에 따르는 변경과정에서 코드의 이해도를 저해하게 된다. 각각의 필터들은 일정한 메시지 스트림 형식으로 통일해야 하기에 특정 변화를 반영하기 어려울 수 있다.[6]
- 객체지향 스타일(Object-Oriented)
- 객체지향 스타일은 기능들이 각 객체로 캡슐화되어 있다. 각 컴포넌트는 객체로 구성하게 되어 있으며, 필요 시 추상 데이터 타입으로 구성할 수 있다. 객체는 각각 독립적인 수행 메커니즘을 통해 리소스의 무결성을 유지하며 함수와 프로시져의 호출에 따라 상호작용하는 과정으로 시스템의 기능을 수행한다. 먼저, 객체는 각 인터페이스에 대한 지속적인 책임을 진다. 즉, 어떤 객체들이 자신을 호출하는지 알 수 없어 인터페이스에 대한 무결성 유지 책임이 있다. 이런 이류로 종종 변화에 대한 유연성이 떨어지는 경우가 많다. 또한, 각 기능 및 데이터들은 다른 객체로부터 은닉된다. 추상화 데이터 타입과 객체 지향 시스템은 매우 좋은 가변성을 가진다. 각 객체는 독립적인 행동 유형을 가지며, 독립적으로 변경이 가능하다. 다른 시스템은 객체가 다양한 인터페이스를 갖도록 내버려 둔다. 객체지향 시스템은 많은 속성을 가지고 있다. 객체는 클라이언트로부터 그것의 표현을 숨기기 때문에 그러한 클라이언트의 영향 없이 구현을 바꾸는 것이 가능하다. 객체지향 스타일은 대부분의 신호가 하나의 객체를 위해 다른 객체와 상호작용하기 위해서 다른 객체의 식별자를 알아야 하며, 한 객체의 식별자가 언제 변하든지 간에 명시적으로 그것을 부르는 다른 모든 객체를 수정해야 한다. 모듈 지향 언어에서 변화된 모듈을 사용하는 모든 모듈의 호출 리스트를 바꾸는 것으로 변화에 대한 각 모듈의 내용을 명확히 할 수 있다.[7]
- 계층형 구조(Layered System)
- 계층형 구조는 계층적으로 조직화 되어 각 계층은 상위 계층에게 서비스를 제공하고 하위계층에 클라이언트로서 서비스를 받는다. 어떤 계층화된 시스템에서 내부 계층은 이웃한 외부 계층을 제외하고 다른 계층으로부터 숨겨진다. 또한 특정 계층에서 가상머신을 실행하게 되고 계층 간 커넥터는 어떻게 각 계층이 상호작용할 것인지를 결정하는 프로토콜에 의해 정의된다. 이러한 아키텍처 스타일로서 가장 잘 알려진 예는 계층화된 통신 프로토콜(OSI 7 계층)이다. 계층별로 추상화 수준을 나누어 구성하고 점진적인 변화를 수용할 수 있게 된다. 즉 추상화 수준이 다른 몇 개의 계층을 통해 시스템의 유연성을 증가시킨다. 각 계층은 상위 계층과 하부 계층끼리만 상호작용하기 때문에 한 계층의 함수를 바꾸면 영향을 미치는 것은 위아래 두 계층뿐이어서 시스템의 확장이 유연하다. 마지막으로 재사용성을 지원한다. 추상화 데이터 타입처럼, 같은 계층의 다른 구현은 교환할 수 있게 사용될 수 있고 이웃 한 계층에게 같은 인터페이스를 제공할 수도 있다. 시스템은 계층형 구조로 구축하기 어려운 경우가 많다. 논리적으로는 구축할 수 있더라도 성능적인 요소와 같은 물리적인 요소를 반영하여 구현하기가 어렵다. 따라서 계속된 변화를 고려하는 동안 계층형 구조를 유지하기가 어렵고 이러한 이유로 불필요한 작업이 늘어나게 된다. 이러한 문제의 해결을 위해 보통 다른 스타일과 혼용하여 사용하는 경우가 많다.[7]
- 대부분의 아키텍처 패턴
서버-클라이언트(server-client)는 클라이언트와 서버로 구성되어 있다. 클라이언트는 서버에 서비스를 요청하는 객체이며 서버는 클라이언트에 서비스를 제공하는 객체이다. 다수의 클라이언트와 하나의 서버로 이루어지는 것이 일반적이다. 서버는 클라이언트에게 서비스를 제공하며 데이터를 관리하는 역할은 한다. 이메일, 문서 공유 등 온라인 애플리케이션과 일반적인 웹프로그램 등에서 사용 예시를 찾을 수 있다. 피투피(P2P)는 피어(Peer)라고 부르는 각각의 컴포넌트 간에 서비스를 주고받는다. 피어는 클라이언트로서 각 피어에 서비스를 요청할 수 있고, 서버로서 각 피어에 서비스를 제공할 수도 있다. 즉, 피어 객체 하나가 클라이언트와 서버의 역할을 모두 수행하는 구조이다. 파일 공유 네트워크와 멀티미디어 애플리케이션 등에서 사용된다.
모델 뷰 컨트롤러(Model-View-Controller)는 모델과 뷰, 컨트롤러로 이루어진 3개의 컴포넌트는 각자의 역할을 갖고 사용자에게 서비스를 제공한다. 모델은 도메인의 기능과 자료를 저장 및 보관한다. 뷰는 사용자에게 결과를 하나 이상 표시하며 컨트롤러는 사용자로부터 입력과 상호작용을 처리한다. 기능마다 컴포넌트를 나눈 이유는 사용자 인터페이스(뷰)가 모델과 컨트롤러 보다 더욱 자주 변경되기 때문이다. 또한 자료의 저장, 제어 기능과 표현 기능을 분리하여 재사용을 증진 시킬 수 있다. 일반적인 웹 애플리케이션 설계 아키텍처로 쓰인다.
블랙보드(Blackboard)는 명확히 정의된 해결 전략이 알려지지 않은 문제에 대해 유용한 방식이다. 부분적인 해법과 대략적인 해법을 수립하기 위한 서브 시스템의 지식을 조합하는 방법이다. 블랙보드는 중앙 데이터 저장소, 지식 소스는 특수한 문제를 해결하는 독립 서브 시스템, 제어 컴포넌트는 변경을 모니터링하며 다음 동작을 결정한다. 또 한 모든 컴포넌트는 블랙 보드에 접근하여 새로운 데이터 객체를 생성 할 수 있다. 공유 데이터 구조 위에서 종합적으로 동작하는 독립적인 프로그램을 모으며 각 프로그램은 전체 중 특정한 부분을 해결하기 위해 특수화되어 있다. 제어 컴포넌트는 처리 과정을 평가하여 특수화된 프로그램을 조율한다. 음성 인식과 차량 식별 및 추적, 수중 음파 탐지기 신호 해석 등에 쓰인다.[8]
종류[편집]
컴퓨터 아키텍처[편집]
컴퓨터 아키텍처(PC architecture)는 컴퓨터 공학에서 컴퓨터 시스템의 기능(functionality), 조직(organization), 구현(implementation)을 기술하는 일련의 규칙과 방법의 집합이다. 아키텍처의 일부 정의는 특정 구현이 아닌 컴퓨터의 기능 및 프로그래밍 모델을 기술하는 것으로 정의한다. 다른 정의에서 컴퓨터 아키텍처는 명령 집합 아키텍처 설계, 마이크로 아키텍처 설계, 논리 설계 및 구현을 포함한다. 컴퓨터 구조의 첫 번째 문서는 1837년 찰스 배비지(Charles Babbage)가 고안한 해석기관으로 실제 제작되지는 않았지만, 논리적 설계는 범용 컴퓨터의 모습을 예측한 중요한 모델로 평가된다. 1936년, 불 논리 체계와 프로그래밍이 가능한 세계 최초의 기계식 컴퓨터 제트 원(Z1)을 만들 때, 콘라트 추제(Konrad Zuse)는 향후 자신의 프로젝트에 대한 두 가지 특허 출원에서 명령어와 데이터가 동일한 저장장치에 저장하는 프로그램 내장식 컴퓨터 개념을 최초로 기술하였다. 이 개념은 1945년에 컴퓨터 구조의 두 가지 중요한 발자취로 이어진다.[9]
- 마이크로 아키텍처
마이크로 아키텍처(micro architecture)는 중앙 처리 장치(CPU) 아키텍처라고도 하며 컴퓨터의 중앙 처리 장치 또는 이와 관련하여 디지털 신호 처리기의 전자 회로에 대한 설명으로 하드웨어의 운영에 대해 세세하게 기술되어 있다. 학술 모임에서는 컴퓨터 시스템이라는 용어가 쓰이지만, 컴퓨터 산업에서는 마이크로 아키텍처라는 용어가 더 자주 쓰인다. 마이크로 아키텍처와 명령어 집합 구조(ISA)는 함께 컴퓨터 아키텍처의 분야를 구성하고 있다.[10]
- 폰노이만 아키텍처
폰 노이만 구조(Von Neumann architecture)는 존 폰노이만이 제시한 컴퓨터 구조로, 프로그램 내장 방식이라고도 불린다. 이론적으로는 튜링 머신과 같은 일을 할 수 있다. 그 이전의 컴퓨터들은 스위치를 설치하고 전선을 연결하여 데이터를 전송하고 신호를 처리하는 식으로 프로그래밍하였다. 폰노이만 구조의 디지털 컴퓨터에서는 저장된 프로그램(stored-program)의 개념이 도입되었다. 이는 프로그램을 구성하는 명령어를 임의 접근이 가능한 메모리상(램)에 순차적으로 배열하고, 동시에 조건 분기를 제한 없이 허용한다는 것을 뜻한다. 폰노이만 구조에서는 같은 메모리 속에 실행 코드와 데이터가 따로 구분되지 않고 함께 섞여 있다. 이후에 나온 컴퓨터는 대부분 폰 노이만의 설계를 기본 구조로 따르고 있다.
이 구조의 장점은 컴퓨터에 다른 작업을 시키려고 할 때 하드웨어(전선)를 재배치할 필요 없이 소프트웨어(프로그램)만 교체하면 되기 때문에 범용성이 크게 향상된다는 것이다. 전선을 일일이 교체할 경우 교체 인원도 많이 필요하고 시간도 많이 잡아먹는 등 여러모로 불편함이 있지만, 폰노이만 구조를 도입하면 프로그램을 교체하는 것으로 모든 일이 끝난다. 이 편의성 때문에, 현재 거의 모든 컴퓨터는 폰노이만 구조를 따르고 있다. 단점으로는 '폰노이만 병목현상'이 있다. 메모리의 값을 읽고 쓰는 구조이기 때문에 기억장치에 병목현상이 생길 수밖에 없다. 메모리 계층 구조나 불균일 기억 장치 접근(NUMA), 기억장치 직접접근(DMA) 같은 기술이 모두 이러한 문제를 완화하기 위해 도입된 기술이다. 또한 코드를 순차적으로 실행하기 때문에 정해진 입력에 따라 정해진 값만을 출력하는 '결정적 유한 오토마타'(Deterministic finite automaton)의 한계에 묶이기 쉽다.[11]
- 하버드 아키텍처
하버드 아키텍처(Harvard architecture)는 명령어와 데이터 통로를 저장 공간과 물리적으로 분리한 컴퓨터 아키텍처를 말한다. 이 용어는 릴레이를 기반으로한 하버드 마크 I(Harvard Mark I) 이란 초기 컴퓨터에서 나온 것이다. 이러한 초기의 컴퓨터는 명령어를 펀치 테이프에, 데이터를 릴레이 래치에 저장한다. 폰 노이만 구조에서는 중앙 처리 장치는 메모리로부터 명령을 읽고, 메모리로부터 데이터를 읽고 쓰기도 한다. 명령과 데이터는 같은 신호 버스(컴퓨터)와 메모리를 사용하기 때문에 이러한 액세스하는 경우 동시에 발생할 수가 없다. 하지만 하버드 아키텍처의 컴퓨터에서는 명령을 메모리로부터 읽는 것과 데이터를 메모리로부터 읽는 것을 동시에 할 수 있다. 하버드 아키텍처의 컴퓨터는 명령의 처리를 끝내자마자 다음의 명령을 읽어 들일 수 있어서 더욱더 빠른 속도를 낼 수 있다고 말할 수 있다. 그렇지만 이러한 처리 속도를 높이려면 보다 많은 전기 회로가 필요하다.[12]
네트워크 아키텍처[편집]
네트워크 아키텍처(network architecture)는 컴퓨터 네트워크의 디자인이다. 네트워크의 물리적인 요소들과 기능 조직, 구성, 동작 원칙, 절차, 사용되는 통신 프로토콜의 사양을 위한 프레임워크이다. 전기 통신에서 네트워크 아키텍처의 사양은 통신 네트워크를 통해 전송되는 제품과 서비스의 자세한 설명, 그리고 서비스가 보상되는 세세한 속도와 지급 구조를 포함할 수도 있다. 인터넷의 네트워크 아키텍처는 네트워크의 상호 연결 네트워크나 노드를 위한 특정한 모형이 아닌, 인터넷 프로토콜 스위트의 이용 또는 특정한 유형의 하드웨어 링크의 이용을 통해 대부분 표현된다.[13]
- OSI 7 계층
OSI 7 계층(OSI 7 Layer)은 ISO에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다. 일반적으로 OSI 7 계층 모형이라고 한다. 계층으로 불리는 더 조그마한 부분들로 통신 시스템을 구분시키는 방법으로, 계층은 위의 계층으로 서비스를 제공하는 유사한 기능들의 모임이며 바로 아래의 계층으로부터 서비스를 받게 된다. 각 계층에서 인스턴스는 서비스를 위의 계층의 인스턴스에 제공하고 아래의 계층으로부터 서비스를 요청한다. 1계층인 물리 계층(Physical layer)은 실제 장치들을 연결하기 위해 필요한 전기적, 물리적 세부 사항들을 정의한다. 예를 들어, 핀들의 배치나 전압, 전선의 명세 등이 이 계층에 포함된다. 허브(리피터)가 물리 계층의 장치이다. 물리적인 정보 전달 매개체에 대한 연결의 성립과 종료, 여러 사용자 간의 통신 자원을 효율적으로 분배하는 데 관여한다. 통신 채널을 통해 전송되는 사용자 장치의 디지털 데이터를 이에 상응하는 신호들로 변환, 변조하며 이 신호들은 구리 선이나 광섬유 선을 통해 전달되는 신호들이다. 또 한 물리계층은 네트워크상에서 데이터 비트를 전송하는 계층이다. 데이터 링크 개체 간의 비트 전송을 위한 물리적 연결을 설정, 유지, 해제하기 위한 수단을 제공한다. 전송 매체는 신호 보내는 방법을 정의한다.
2계층인 데이터 링크 계층은 포인트 투 포인트(Point to Point) 간 신뢰성 있는 전송을 보장하기 위한 계층으로 순환 중복 검사(CRC) 기반의 오류 제어와 흐름 제어가 필요하다. 네트워크 위의 개체 간 데이터를 전달하고, 물리 계층에서 발생할 수 있는 오류를 찾아내고, 수정하는 데 필요한 기능적, 절차적 수단을 제공한다. 주솟값은 물리적으로 할당 받으며 이는 네트워크 카드가 만들어질 때부터 물리 주소(MAC address)가 정해져 있다는 뜻이다. 주소 체계는 계층이 없는 단일 아키텍처이다. 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다.
3계층, 네트워크 계층은 여러 개의 노드를 거칠 때마다 경로를 찾아주는 역할을 하는 계층으로 다양한 길이의 데이터를 네트워크를 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질(QoS)을 제공하기 위한 기능적, 절차적 수단을 제공한다. 네트워크 계층은 라우팅, 패킷 포워딩, 세그멘테이션(segmentation), 인터네트워킹(Internetworking) 등을 수행한다. 라우터가 이 계층에서 동작하며 스위치도 있다. 데이터를 연결하는 다른 네트워크를 통해 전달함으로써 인터넷이 가능하게 만드는 계층이다. 논리적인 주소 아키텍처, 네트워크 관리자가 직접 주소를 할당하는 아키텍처를 가진다. 4계층, 전송 계층은 양 끝단(End to end)의 사용자들이 신뢰성 있는 데이터를 주고받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다. 시퀀스 넘버 기반의 오류 제어 방식을 사용한다. 전송 계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고 연결 기반이다. 이는 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들을 다시 전송한다는 것을 뜻한다.
세션 계층은 5계층으로써 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 동시 송수신 방식(duplex), 반 이중 방식(half-duplex), 전 이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다. 이 계층은 티씨피 아이피(TCP/IP) 세션을 만들고 없애는 책임을 진다. 통신하는 사용자들을 동기화하고 오류복구 명령을 일괄적으로 다룬다. 6계층인 표현 계층은 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어 준다. 표현 계층은 수신자 장치에서 적합한 애플리케이션을 사용하여 송신자 장치로부터 온 데이터를 해석하기 위한 응용계층 데이터 부호화, 변환하고 수신자에서 압축을 풀 수 있는 방식으로 된 데이터 압축하고 전송을 위한 암호화와 복호화를 제공한다. 7계층 응용 계층은 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다. 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다. 응용 서비스의 예로, 가상 터미널 등이 있다.[14]
OSI 7 계층에 대해 자세히 보기
- 서버-클라이언트
서버-클라이언트(Server-Client System) 시스템은 클라이언트와 서버로 나누어지는 네트워크 아키텍처를 말한다. 넓은 의미로 인터넷 시스템 전체를 서버-클라이언트 시스템으로 볼 수 있지만, 일반적으로 시스템이란 웹 시스템이 나오기 전에 사용자의 컴퓨터에 클라이언트가 설치되어 화면을 처리하고, 서버 컴퓨터에서 데이터를 처리하는 시스템을 말한다. 클라이언트는 서버 시스템에 연결된 컴퓨터나 스마트폰 등 사용자 측을 말한다. 예를 들어, 컴퓨터 및 스마트폰에 설치된 웹브라우저는 클라이언트 소프트웨어의 일종이다. 사용자가 특정 웹사이트를 방문했을 때 만들어지는 쿠키(Cookie) 정보는 서버 측이 아니라 클라이언트 측에 저장된다. 서버는 통신망 상에서 다른 컴퓨터에 대하여 회선, 디스크 장치 등에 대한 접속을 제어하는 관리 소프트웨어 또는 컴퓨터를 말한다. 서버의 역할에 따라 웹서버, 와스(WAS) 서버, 데이터베이스(DB) 서버, 메일 서버, 이미지 서버, 네임 서버, 백업 서버 등이 있다. 서버의 제조사에 따라 아이비엠(IBM) 서버, 에이치피(HP) 서버, 델(Dell) 서버 등이 있다. 서버에서 처리된 정보를 클라이언트 측인 사용자에게 전달한다.[15]
소프트웨어 아키텍처[편집]
소프트웨어 아키텍처(software architecture)는 소프트웨어 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소 간의 관계를 표현하는 시스템의 구조 또는 구조체이다. 대규모 소프트웨어를 개발하려면 복잡성의 문제를 해결해야 한다. 그 방법은 개발할 소프트웨어의 전체 구조를 가장 먼저 생각한다. 그 구조를 이루는 각 구성 요소를 찾고 각 구성 요소 간의 명확한 관계를 설정하고 일정한 규칙을 따르게 만든다. 복잡하고 규모가 큰 소프트웨어를 개발하려면 전체적인 구조가 유기적으로 잘 구성되어야 한다. 또한 사용자가 만족할 만한 품질 좋은 소프트웨어를 개발하려면 요구 분석, 설계 단계에서부터 품질 특성을 고려하여 개발해야 한다. 즉 잘 정의된 전체적인 구조와 품질 좋은 소프트웨어를 만들려면 소프트웨어 아키텍처가 필요하다.[16]
- 소프트웨어 설계
아키텍처의 소프트웨어 설계는 사용자의 요구 사항에 따라 요구 분석 명세서가 만들어지면 개발팀은 이 명세서를 참조하여 설계서를 작성한 뒤 이를 기반으로 구현한다. 여기서 요구 분석 명세서를 기반으로 만든 설계서는 건축의 다양한 도면처럼 상위 설계, 하위 설계, 아키텍처 설계, 사용자 인터페이스 설계 등의 여러 가지 형태로 된 구체적인 사양서이다. 분석 단계에서는 사용자의 요구 사항을 토대로 요구 분석 명세서를 작성한다. 그런데 이 요구 분석 명세서는 하드웨어나 소프트웨어 종류는 무엇인지, 그리고 분산 시스템으로 구축하는지, 프레임워크는 네트워크 기반인지 등과 같은 사항은 고려하지 않고 독립적이다. 따라서 개념적이고 추상적인 성격이 강하다. 설계 단계에서는 분석 단계에서 고려하지 않았던 상세 내용을 충분히 반영하여 구현할 수 있는 수준으로 준비해야 한다. 분석 단계에서 파악한 비기능적 요구 사항과 제약 사항을 고려하고, 운영체제(OS), 미들웨어, 프레임워크 등의 플랫폼을 결정해야 한다. 그리고 이에 따라 구체적인 설계서를 만들어야 한다.
분석 단계에서 사용자의 요구를 무엇(what) 관점에서 바라보았다면, 설계 단계에서는 어떻게(how) 관점에서 생각한다. 즉 설계의 목적은 요구 분석 명세서를 기반으로 어떻게 구축할 것인가를 결정하는 것이다. 따라서 설계자는 여러 방법 중 다양한 제약 조건을 만족시킬 수 있는 최적의 설계안을 만드는 것이 중요하며, 설계를 평가할 수 있는 기준도 정량적으로 명시해야 한다. 좋은 설계가 되려면 요구 분석 명세서의 내용을 설계서에 모두 포함해야 한다. 또한, 유지보수가 용이하도록 추적이 가능해야 하며, 변화에 쉽게 적응할 수 있어야 한다. 그리고 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 하고 설계서는 읽기 쉽고, 이해하기 쉽게 작성해야 한다. 이런 조건을 만족하여 좋은 설계가 되려면 결국 모듈이 독립적이어야 하고, 모듈 내 요소 간의 응집력은 높게 설계되어야 하며, 모듈 간의 결합력은 낮게 설계되어야 한다.[17]
- 분할 과 정복
- 가장 세분된 작은 시스템을 개발하고, 하나씩 위로 올라가면서 완성하는 방법으로 개발하는 것을 '분할과 정복의 원리'라고 한다. 이 원리는 하나의 일을 수행할 때 작은 단위로 나누고 각 작은 단위를 하나씩 처리하여 전체 일을 끝낸다는 의미이다. 소프트웨어 개발에 분할과 정복의 원리를 적용하려면 우선 쪼개는 작업을 해야 한다. 소프트웨어를 나눌 때는 분산 시스템은 클라이언트와 서버로 분할한다. 그리고 시스템은 여러 서브 시스템으로 분할하고 서브 시스템은 하나 이상의 패키지로 분할한다. 패키지는 여러 클래스로 분할하며 클래스는 여러 메소드로 분할한다. 하지만 무작정 작게만 쪼개면 통신으로 인해 오히려 복잡도가 증가할 수 있음으로 설계자는 어느 수준으로 쪼갤지를 결정해야 한다. 즉 복잡도로 인한 증가 비용과 처리의 용이성을 고려하여 결정해야 한다.[17]
- 추상화
- 추상화는 복잡한 세부 사항을 모두 다루는 것이 거의 불가능하고 필요도 없음으로 복잡한 현상을 이해하는 과정에서 인간의 이해력을 도와주는 강력한 도구로 사용된다. 어떤 문제를 해결하기 어려운 대표적인 이유는 규모가 크고 매우 복잡하기 때문이다. 이러한 문제는 설계에서도 발생한다. 이럴 때 추상화 개념을 사용하면 문제의 핵심을 쉽게 파악할 수 있고, 문제의 본질을 쉽게 이해하는 데 도움이 된다. 객체들의 공통점을 뽑아 클래스라는 이름을 붙여놓은 것이 추상화이다. 반대로 클래스로부터 객체를 생성하는 과정을 인스턴스화(instantiation)라고 한다. 추상화하는 방법에는 프로그램 전체에 대해 알고리즘 형태로 작성하는 과정 추상화, 데이터를 모아 데이터 구조 형태로 표현한 자료 추상화, 여러 줄의 내용을 간략히 줄여서 표현한 제어 추상화가 있다. 과정 추상화는 대부분 주어진 문제에 대해 프로그래밍하기 전에 상세 부분은 생략하고 전체 흐름만 파악할 수 있는 알고리즘 형태로 작성하는 것을 과정 추상화라고 한다. 데이터 추상화는 데이터와 메소드를 클래스 형태로 캡슐화하여 숨겨놓고, 사용자에게는 꼭 필요한 기능만 사용할 수 있게 개방한 구조이다. 제어 추상화는 프로그래밍 언어에서 쓰는 제어 구조를 추상화하는 것이다.[17]
- 단계적분해 및 모듈화
- 단계적 분해는 하향식 설계에서 사용되는데, 기능을 점점 작은 단위로 나누어 점차 구체화하는 방법이다. 단계적 분해를 설명하기 위해 구조적 분석 방법에서 사용하는 자료 흐름(DFD: Data Flow Diagram)는 문제를 처음에 원 하나로 나타낸 후 단계가 낮아질수록 분해하여 작은 단위로 구체화한다. 이렇게 단계적 분해를 통해 큰 문제를 작게 구체화하여 실제 프로그램을 작성할 수 있게 된다. 소프트웨어 개발에서 모듈은 '규모가 큰 것을 여러 개로 나눈 조각' 과 '소프트웨어 구조를 이루는 기본적인 단위'라고도 말한다. 더 구체적으로는 '하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합'이라고도 말할 수 있다. 따라서 독립 프로그램도 하나의 모듈이 될 수 있고, 함수들도 하나의 모듈이 될 수 있다. 그러나 모듈이 되려면 가장 중요한 특징들이 있다. 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위(unit)이며 유일한 이름을 가져야 한다. 독립적으로 컴파일이 가능해야 하고 모듈에서 다른 모듈을 호출할 수 있다. 마지막으로 다른 프로그램에서도 모듈을 호출할 수 있다. 모듈은 완전한 독립 프로그램이고, 다양한 크기의 집합에 대해서 모듈이라고 부를 수 있다. 모듈은 다음과 같이 다양한 형태로 존재한다. '용도가 비슷한 것끼리 묶어놓은 라이브러리 함수'와 그래픽 함수 추상화된 자료, 서브루틴(subroutine), 프로시저(procedure), 객체(object), 메소드(method)이다.[17]
- 품질속성
소프트웨어 아키텍처는 이해 관계자들의 품질 요구 사항을 반영하여 품질 속성을 결정한다. 품질 속성은 사용성, 이식성, 유지보수 용이성과 같이 이해 관계자들의 요구 사항과 관심사를 반영한 것이다. 아키텍처는 이해 관계자들이 요구하는 수준만큼 품질 속성을 달성해야 하는데 이를 품질 요구 사항이라 한다. 품질 요구 사항은 시스템이 제공해야 하는 품질 속성의 수준으로, 가능하면 정확한 수치로 제시되는 것이 좋다. 시스템 품질 속성에는 가용성, 변경 용이성, 성능, 보안성, 사용성, 테스트 용이성 등이 있다. 비즈니스와 관련된 품질 속성에는 시장 적시성, 비용과 이익, 예상 시스템 수명, 목표 시장, 신규 발매 일정 또는 공개 일정, 기존 시스템과의 통합 등이 있다. 아키텍처 품질 속성에는 개념적 무결성, 정확성과 완전성, 개발 용이성 또는 구축 가능성 등이 있다. 마지막으로 이해 관계자별 품질 속성에는 크게 발주자, 사용자, 개발자로 구분할 수 있다. 발주자는 소프트웨어를 구매하는 부서로, 품질은 당연히 좋다고 가정하고 구매 가격에 관심이 있다. 반면, 사용자는 구매한 소프트웨어를 업무에 직접 활용하므로 가격보다는 얼마나 편리하며, 업무 효율을 얼마나 높여줄 수 있는가에 관심이 있다. 따라서 각자의 역할에 따라 중요하게 생각하는 품질 속성을 구분할 수 있다.[17]
- 구축절차
아키텍처 구축에서 요구 사항 분석 단계는 소프트웨어 개발의 요구 사항 분석 단계와 같다. 다만 품질 속성과 같은 비기능적인 요구 사항에 더 많은 관심을 둔다. 이 단계에서는 요구 사항 취득, 식별, 명세, 분류, 검증, 기능적 및 비기능적 요구 사항 분류 및 명세와 같은 내용을 다룬다. 분석 단계에서는 개발 프로젝트에 필요한 품질 속성을 식별하고, 식별된 품질 속성들의 우선순위를 결정한다. 또한 품질 속성 반영 방법을 개발한다. 설계 단계에서는 관점을 정의하고 이에 따라 아키텍처 스타일을 선택하여 후보 아키텍처를 도출한다. 검증 및 승인 단계에서는 아키텍처를 평가하고 상세화한 후 승인한다. 아키텍처 평가에는 요구 사항 만족도, 적합성 등을 평가하며 품질 속성 간 절충 관계를 평가한다. 아키텍처 상세화는 설계 방법과 패턴을 파악한다. 아키텍처 승인은 마지막에 이해 관계자들이 최종 승인을 한다.[16] [17]
엔터프라이즈 아키텍처[편집]
엔터프라이즈 아키텍처(Enterprise architecture)는 전사 아키텍처라고도 불리며 기업의 목표와 요구를 지원하기 위해 아이티(IT) 인프라의 각 부분이 어떻게 구성되고 작동되어야 하는가를 체계적으로 기술하는 것이다. 기업의 비즈니스 복잡도는 증대되고 있고, 업무와 아이티 기능의 분리는 무의미하게 되었다. 또한 기업이 환경 변화에 대응하기 위해 시스템을 변화시키고자 할 때, 시스템이 너무 복잡하여 어디를 어떻게 변경해야 할지 모르는 상황에 이르렀다. 따라서 건축물의 설계도처럼 기업의 전체 시스템을 쉽게 파악할 수 있는 무언가가 필요하게 되었고 엔터프라이즈 아키텍처는 기업의 이런 복잡한 시스템을 파악하기 쉽게 정리하는 것으로, 복잡한 기업 시스템을 필요한 형태로 변화시키는 것을 좀 더 쉽게 할 수 있다. 따라서 엔터프라이즈 아키텍처를 도입 함으로써 기업을 비즈니스, 데이터, 애플리케이션, 기술 등의 다양한 측면에서 분석하고 표현하여 이해하기 쉽도록 정보체계를 구축하고 이를 활용하며 아이티 투자 대비 효과를 최대화하고, 기업의 목적을 가장 잘 달성할 수 있는 방식으로 아이티 인프라를 구성하여 비즈니스와 아이티를 보다 유기적으로 연결할 수 있게 된다.
엔터프라이즈 아키텍처 관리시스템(EAMS, Enterprise Architecture Management System)은 정보기술 프레임워크 수립, 메타데이터 시스템, 품질관리시스템 등 주변 시스템과 연계를 통해 정보시스템 변경내용 및 구성체계를 실시간으로 조회 및 수정할 수 있는 엔터프라이즈 아키텍처의 관리 및 활용을 위한 구현시스템으로 구축, 관리, 활용 등의 모든 업무 프로세스 과정을 체계적으로 관리할 수 있는 시스템이다.[18]
- 프레임워크
엔터프라이즈 아키텍처를 어떻게 표현하고 운영할 것인가에 대한 전체적인 사고의 틀을 결정해야 한다. 프레임워크(frame work)는 엔터프라이즈 활동에서 얻어지는 산출물을 분류하고 조직화하며 이를 유지 관리하기 위한 전체적인 틀을 정의하며 이를 구성하는 요소에는 정책과 정보 관리 등의 3가지 영역으로 구분된다. 정책은 기업이 아키텍처를 구축하기 위해서 구축 목적과 방향을 정의해야 한다. 아키텍처의 정보를 어떻게 구성할 것이고, 수립을 통하여 기업이 달성하고자 하는 궁극적인 모습은 무엇이며, 효과적으로 관리하고 활용하기 위한 원칙은 어떤 것인지 등을 정의하는 것이다. 아키텍처 구축을 위해서는 아키텍처 산출물에 대하여 현재 상태와 목표 상태의 정보를 구축한다. 그리고 목표 아키텍처를 달성하기 위한 이행 계획을 수립한다. 아키텍처 정보를 구축하기 위해서는 정보의 영역을 구분해야 하며 이런 영역을 구분한 것을 아키텍처 도메인이라 한다. 정의된 엔터프라이즈 아키텍처 정보를 지속해서 유지 관리하고 효과적으로 활용하기 위해서는 관리 체계의 정립과 관리 시스템의 구축이 필요하다. 또한 관리 수준을 제고하기 위해서는 지속해서 평가하고 개선할 필요가 있다.[18]
- 모델
- 참조 모델 : 아키텍처 구성 요소를 식별하여 표준화한 것으로 기관이나 기업의 아키텍처를 수립할 때 참조하는 추상화된 모델이다. 참조 모델은 다양한 관점을 충족시킬 수 있도록 시스템에 대한 개념적인 모델을 추상화하고, 구성 요소를 재사용 가능한 방식으로 생성하여, 여러 기업이 사용할 수 있도록 한다. 비슷한 특성이 존재하는 산업군마다 정의된 참조 모델을 활용하도록 하며, 각 기업은 동종의 참조 모델을 참조하여 고유의 아키텍처를 구성할 수 있다. 이러한 참조 모델 중 잘 알려진 것은 국방, 공공 참조 모델이다. 정부는 아키텍처별 참조 모델로 업무 참조 모델(BRM, Business Reference Model), 데이터 참조 모델(DRM, Data Reference Model), 서비스 참조 모델(SRM, Service Reference Model), 기술 참조 모델(TRM, Technical Reference Model), 성과 참조 모델(PRM, Performance Reference Model) 등 5가지 참조 모델 정의를 추진하고 있다.[18]
- 업무 참조 모델 : 몇 개의 업무 영역으로 구분되며 각 업무 영역은 여러 개의 업무 단위로 구분되고, 각 업무 단위는 세부 업무로 구성된다. 업무 참조 모델에 정의된 업무 단위는 특정 기관에 의해 수행되는 것이라기보다는 기관이 어떤 목적으로 어떤 내용의 일을 수행하든 그 업무는 여기에 정의된 업무 단위로 묘사될 수 있다. 이는 업무 분석을 위한 공통 기준으로 활용할 수 있다. 서로 다른 기관들이 유사한 업무를 수행하고 있는지를 파악할 수 있어 유사 업무를 지원하는 시스템을 개발할 경우에 기관이 공동으로 활용할 수 있다.[19]
- 서비스 참조 모델 : 업무 수행과 목표 달성을 지원하는 서비스 요소를 분류하기 위한 기능 중심의 평가 지향적 참조 모델이다. 공공 부문의 애플리케이션 서비스에 대한 식별을 통하여 업무와 서비스의 연계 및 재사용을 촉진하고 중복 개발을 방지하기 위한 것으로, 업무 및 조직에 독립적인 표준 서비스 분류 체계다. 기관들은 이를 통해 범정부 차원의 업무 및 응용 서비스 요소를 발견할 수 있다. 서비스 참조 모델을 구축하는 목적은 응용 서비스의 재활용을 촉진하기 위한 서비스 분류 체계를 제공하며, 정부 기관 업무 지원 컴포넌트에 대한 단일화되고 통합된 분류 체계를 제공하기 위함이다. 또한 업계와 정부 간의 컴포넌트 개발, 축적, 유통의 활성화를 촉진하며, 복잡, 다양한 정부 부처 응용 서비스를 용이하게 식별할 수 있도록 할 수 있다.[19]
- 기술 참조 모델 : 업무와 서비스 구성 요소의 전달과 교환, 구축을 지원해 주는 표준, 명세, 기술 요소를 기술하기 위한 것이다. 업무를 지원하는 응용 기능을 구현하는 데 필요한 정보 기술 및 표준들을 분류하고 정의한 체계로서, 기업의 정보화 추진을 위한 전체 정보 기술을 식별하고 정의하여 관련된 기술 표준과 동향을 관리하여, 공통의 정보 기술 기반을 수립하고 기업의 정보 기술을 표준화할 수 있도록 한다. 각 기업은 이를 통하여 기술 및 응용 서비스의 재사용을 제고시키고, 업무 및 응용 서비스의 안전한 교환 및 전달을 위한 기반 환경을 구축하며, 정보 기술 간의 상호 운용성 확보를 지원하여 정보 기술 성능과 투자의 최적화를 추구하도록 지원한다. 기술 참조 모델은 특성상 다양한 산업군 및 기업에 바로 적용할 수 있기 때문에 구축하기 용이하고 기대 효과가 커서 가장 먼저 적용 가능한 영역이다. 기술 참조 모델의 수립은 시스템 구축 시 사용할 기술에 대한 표준 프로파일을 분류하는 데 활용할 수 있다. 시스템 관리 시 정보 자산을 분류하는 데 활용할 수 있고, 시스템 통합 시 정보시스템 간의 유사성을 판단하는 기준 항목으로 활용할 수 있다.[19]
- 데이터 참조 모델 : 기관 간의 공통 정보 파악과 활용을 지원하기 위한 모델이다. 기관 간의 정보 공유 및 데이터의 표준화, 재사용을 지원하기 위한 범정부 데이터 분류 및 데이터 표준화와 관리를 위한 기준과 체계를 정의한 것이다. 데이터 참조 모델 프레임워크는 데이터의 표준화, 참조, 재사용을 위하여 필요한 구성 요소와 구성 요소 간의 관계를 정의한 것으로서, 범정부 데이터 모델, 데이터 분류, 데이터 구조, 데이터 교환, 데이터 관리의 5개 요소로 구성된다.[19]
- 범정부 데이터 모델 : 범정부에서 구축 및 활용하고 있는 데이터를 식별하고 데이터 영역 간의 관계를 도식화한 것으로, 개별 기관은 범정부 데이터 모델을 참조함으로써 범정부에서 구축 및 운영되고 있는 데이터에 어떤 것이 있는지를 확인할 수 있다. 데이터 분류는 데이터에 대한 분류 기준을 정의한 것으로, 범정부 데이터 모델의 데이터들은 데이터 분류에 따라 그룹화 되고, 데이터 구조의 데이터 요소는 데이터 분류 체계에 매핑된다. 데이터 분류 체계를 활용 함으로써 좀 더 용이한 데이터 관리 및 검색을 할 수 있다. 데이터 구조는 범위 내의 모든 데이터 요소와 요소의 소유주, 표준화 항목 정의, 요소 간 관계 및 정보를 저장한다. 구축 및 활용하는 데이터 요소에 대한 표준화 항목과 가이드를 제시하고, 궁극적으로는 주요한 표준 데이터 요소를 등록하여 이를 공유 및 재사용할 수 있도록 한다. 데이터 교환은 데이터 요소의 교환을 위하여 교환 대상 정의 및 메시지 구조, 메시지 방식을 제시하고 교환 내용 을 관리할 수 있도록 한다. 데이터 교환에서 정의한 데이터 교환 패키지를 통해서 데이터 요소를 참조 및 재사용할 수 있다. 데이터 관리는 데이터 품질, 표준화, 보안 등의 유지를 위한 데이터 관리 정책 및 규칙, 프로세스, 조직 구조를 정의한다.[19]
- 프로세스
엔터프라이즈 아키텍처 프로세서는 아키텍처를 구축하고 관리하는 전체 절차에 관한 것으로 작업의 단계와 공정, 작업내용 등을 정의한다. 프로세스는 일반화되어 있는 방법론이 있지만, 엔터프라이즈 아키텍처를 도입하고자 하는 기업의 목적에 맞게 프로세스를 조정할 수 있다. 엔터프라이즈 아키텍처 프로세스는 아키텍처 프레임워크 구성 요소이기도 하며, 아키텍처 프레임워크 내의 다른 구성 요소를 정의하기 위한 모든 절차와 작업을 포함한다. 엔터프라이즈 아키텍처 프로세스는 "비전 수립, 구축, 관리와 활용" 단계로 구분할 수 있다. 비전 수립 단계에서는 기업의 아키텍처 환경을 분석하고, 이를 바탕으로 기업이 추구해야 아키텍처의 방향을 수립한다. 구축 단계에서는 아키텍처 정보를 어떻게 구성한 것인가를 정의하고, 이를 바탕으로 현행의 아키텍처와 목포 아키텍처를 구축한다. 아키텍처 관리 정의 단계에서는 아키텍처를 효과적으로 관리 및 활용하기 위한 관리 체계를 정립하고, 관리 시스템을 구축한다. 아키텍처 활용 정의 단계에서는 목표 아키텍처 달성을 위한 중장기 계획을 수립하고, 아키텍처 정보를 전반적인 아이티 관리 프로세스에 활용하도록 체계를 정의한다.[18]
람다 아키텍처[편집]
람다 아키텍처(Lambda Architecture)는 실시간 분석을 지원하는 빅데이터(Big Data) 아키텍처이다. 대량의 데이터를 실시간으로 분석하기 어려워서 배치(batch)로 미리 만든 데이터와 실시간 데이터를 혼합해서 사용하는 방식이다. 아파치 스톰 개발자인 나단 마즈(Nathan Marz)가 제안한 개념으로, 실시간 레이어와 배치 레이어를 결합하여 빅데이터의 실시간 분석을 지원하는 아키텍처를 의미한다. 예를 들면, 배치 분석을 통해 일자별로 통계를 생성하고, 당일 데이터는 별도의 실시간 통계를 유지한 다음, 이를 합쳐서 실시간 분석을 제공한다. 하둡(Hadoop) 기반으로 람다 아키텍처를 구현할 때에는 일반적으로 하둡 분산 파일 시스템(Hadoop Distributed File System)에 적재된 데이터를 맵리듀스(Map Reduce)나 하이브(Hive)로 배치 분석하고, 스톰이나 스파크 같은 스트리밍 솔루션으로 실시간 집계를 수행한 뒤, 이를 에이치 베이스(HBase)나 관계형 데이터베이스 관리 시스템(Relational dataBase Management System)에서 통합하여 실시간에 가까운 분석을 유지한다.
이와 같은 구성은 의도한 대로 실시간 빅데이터 분석을 지원하기는 하지만, 이티엘(Extraction, Transformation, Loading) 작업부터 시각화 단계에 이르기까지 독립적인 다수의 구성요소를 통합하여 개발해야 하므로 구축 및 운영에 있어서 많은 어려움이 있다. 인터넷에 연결되는 수십만 대의 사물인터넷(IOT) 센서 데이터를 실시간으로 분석할 때에는 더욱 어려움이 따른다. 실무에서는 센서 데이터에 포함된 식별자를 기준으로 원본 데이터에 다양한 메타데이터를 추가하여 분석을 수행하는 사례를 흔히 볼 수 있다. 예를 들면, 셋톱박스의 식별자를 연령, 지역, 상품명 등으로 맵핑하여 다양한 분석을 수행하게 된다. 가장 흔한 설계 오류는 아래와 같이 스트리밍 솔루션에서 로그가 수신될 때마다 관계형 데이터베이스 관리 시스템을 대상으로 매번 쿼리하는 구성이다. 아키텍처에서는 데이터베이스에 대한 메타데이터 쿼리가 네트워크 스택의 레이턴시를 포함하여 1밀리초 이내에 응답한다고 하더라도 1,000TPS를 내기 어려운 구성이 된다. 일반적으로는 실시간 스트리밍 처리와 배치 분석이 별개의 솔루션으로 구성되는데, 이렇게 다수의 컴포넌트로 구성된 아키텍처에서 가장 큰 성능의 병목은 메모리에 있는 데이터를 바이너리로 직렬화하고 네트워크 I/O를 수행하는 연동 구간에 존재한다.[20] 람다 아키텍처에 대해 자세히 보기
각주[편집]
- ↑ architecture ; 아키텍처 텀즈 - http://www.terms.co.kr/architecture.htm
- ↑ kej_0209 , 〈9.1아키텍처 개요〉, 《네이버 블로그》, 2018-07-17
- ↑ 〈전사아키텍처 개념〉, 《디비가이트넷》
- ↑ Jane Park , 〈소프트웨어 아키텍처 이론과 현실〉, 《네이버 블로그》, 2016-06-18
- ↑ 〈아키텍처 스타일(Architecture Style)〉, 《아이티랩》
- ↑ bleujin , 〈아키텍쳐 패턴 - Pipes and Filter 패턴〉, 《티스토리》, 2009-03-11
- ↑ 7.0 7.1 , 〈아키텍처 스타일(Architecture Style)〉, 《아이티랩》
- ↑ The Boxer , 〈아키텍처 패턴과 종류〉, 《티스토리》, 2018-11-10
- ↑ Computer architecture wikipedia - https://en.m.wikipedia.org/wiki/Computer_architecture
- ↑ 마이크로아키텍처 위키백과 - https://ko.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98
- ↑ 폰노이만 구조 나무위키 - https://namu.wiki/w/%ED%8F%B0%EB%85%B8%EC%9D%B4%EB%A7%8C%20%EA%B5%AC%EC%A1%B0
- ↑ 쌩혁 , 〈하버드 아키텍처 VS 폰노이만〉, 《네이버 블로그》, 2011-04-19
- ↑ 네트워크 아키텍처 위키백과 - https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98
- ↑ OSI 모형 나무위키 - https://namu.wiki/w/OSI%20%EB%AA%A8%ED%98%95
- ↑ client/server ; 클라이언트/서버 텀즈 - http://www.terms.co.kr/clientserver.htm
- ↑ 16.0 16.1 , 〈소프트웨어 아키텍처〉, 《네이버 블로그》, 2020-02-10
- ↑ 17.0 17.1 17.2 17.3 17.4 17.5 , 〈쉽게 배우는 소프트웨어 공학〉, 《네이버 책》, 2020-01-10
- ↑ 18.0 18.1 18.2 18.3 , 〈전사아키텍처 개념 〉, 《디비가이드넷》,
- ↑ 19.0 19.1 19.2 19.3 19.4 , 〈전사아키텍처 개요〉, 《티스토리》, 2018-06-12
- ↑ 〈차세대 람다 아키텍처〉, 《로그프레소》
참고자료[편집]
- 김치수 , 〈쉽게 배우는 소프트웨어 공학〉, 《네이버 책》, 2020-01-10
- 텀즈 - http://www.terms.co.kr/architecture.htm
- 네이버 지식백과 - https://terms.naver.com/entry.nhn?docId=3532950&cid=58528&categoryId=58528
- 디비가이드 공식홈페이지 - http://www.dbguide.net/db.db?cmd=view&boardUid=12720&boardConfigUid=9&boardIdx=25&boardStep=1
- Jane Park , 〈소프트웨어 아키텍처 이론과 현실〉, 《티스토리》, 2016-06-18
같이 보기[편집]
