토폴로지 개요

 

Topology(위상수학() : 그리스어에서 위치를 뜻하는 토포스(topos)학문을 뜻하는 로고스(logos)로 만들어진 단어

 

요한 베네딕트 리스팅(Johann Benedict Listing, 1808~1882) 정의 : “공간 속의 점·선·면 및 위치 등에 관하여, 양이나 크기와는 별개의 형상이나, 위치 관계를 나타내는 법칙을 연구하는 학문”

 

사전적 의미 : 체계적인 분류, 위상 배치

일반적인 의미 : 물리적인 배치의 형태로 이루어진 어떤 현장의 종류를 설명
통신 
네트워크에서의 의미 : 노드들과 이에 연결된 회선들을 포함한 네트웍의 배열이나 구성을 개념적으로 표현한 것

 

그럼 통신 네트워크 측면에서 토플로지에 대해 정리하도록 하겠습니다. 

 

먼저, 네트워크란, 상호간에 정보를 교환할 수 있도록 유선, 무선을 통하여 연결된 형태를 말합니다. 

그럼 네트워크 토플로지는 컴퓨터 네트워크에 참여하는 요소(링크, 노드)들의 배치형태, 망구성 방식을 의미합니다. 

 

네트워크 토플로지는 물리적 토플로지와 논리적 토폴로지로 구분합니다. 

물리적 토플로지는 노드, 링크와 같은 네트워크를 구성하는 요소들의 배치에 의해 결정됩니다. 

 

논리적 토폴로지는 노드들 사이의 데이터 흐름에 따라 결정됩니다. 

 

 

예를 들어, 위 그림과 같이 네트워크가 물리적으로 연결되어 있고

붉은색 화살표와 같이 데이터가 순차적으로 흐른다면

물리적 토폴로지는 성형(star)이고,

논리적 토폴로지는 링형(Ring)이 됩니다. 

 

 토폴로지 종류

 

그럼 토폴로지 종류에 대해 설명드리겠습니다. 

네트워크 구성방식(Topology)에 따라 Star, Bus, Ring, Mesh, 성형, 망형, 버스형, 환형, 나무형 등이 있다.

 

Bus Topology(버스) 형(= Line (선형))

- 하나의 통신회선에 여러 컴퓨터를 연결해서 전송하는 방법으로,
- 신호와 관련이 있는 장치들만이 그들에게 주목하고, 그 외의 장치들은 그 신호를 무시
즉, 본래의 신호에 코드화되어 있는 주소와 일치하는 주소를 가진 컴퓨터만이 반응함
- 간선과 각 단말 장치와의 접속은 간단한 접속장치를 붙이는 것으로 가능
- 서로 가까운 거리의 장치들을 연결할 때 적절

 

장점

- 한개의 통신 회선에 장치가 여러대 연결되어 있는 간단한 구조
- 장치(컴퓨터)의 추가와 제거가 매우 용이
- 장치(컴퓨터)가 고장나더라도 전체 통신망에 영향을 주지 않아 신뢰성이 높음
- 가장 적은양의 케이블 사용
- 비용이 적게 듦

 

단점

- 장애가 발생 시에 발생지의 위치 추적이 어렵고

- 버스의 연결 부위나 종단 장치에 문제가 발생하면 전체 네트워크가 중단됨

즉, 단선 등 단순한 장애가 전체 네트워크에 영향을 준다.

- 한번에 한 컴퓨터만 전송할 수 있으며, 연결된 컴퓨터의 수에 따라 네트워크 성능이 좌우됨

- 거리 제약이 심함

 

 Ring Topology(링) 형

- 컴퓨터를 하나의 원을 이루도록 연결하며, 각 장치는 고유한 주소를 가지게 되며
- 케이블로 고리(loop)를 형성하고, 이 고리에는 네트워크 장비들을 설치
- 정보흐름(신호)은 단방향(시계방향)으로 원을 따라 흐르게 되고

- 개별 컴퓨터들이 리피터처럼 신호를 강화하여 다음 컴퓨터로 전송함

- 인접한 노드와 연결되어 원형을 이루는 형태임

- 각 노드는 데이터의 송수신을 제어하는 엑세스 제어논리(토큰)을 보유
- Token Passing(토큰 패싱)이라는 방법을 통해 데이터를 전송

- 장애 발견시 데이터가 왔던 경로로 되돌아감

 

 

장점

- 모든 장비에 똑같은 접속기회를 제공

- 단방향 통신으로 신호 증폭이 가능하여 거리 제약이 적음

- 네트워크 전송상의 충돌이 없고
- 노드의 숫자가 증가해도 전체적인 성능의 저하가 적음

 

단점

- 버스 방식보다 많은 양의 케이블을 사용하므로 설치비용이 비쌈

하나의 컴퓨터에 이상이 발생하면 전체 네트워크에 문제가 생긴다.

- 노드의 추가 삭제가 용이하지 않음

- 노드의 문제가 발생했을 경우에 전체 네트워크가 중단될 수 있음
즉, 장애가 복구 될 때까지 데이터가 loop를 벗어나지 못함

 

 Star Topology(성형)

- 중앙집중식 구조를 가짐
즉, 중앙에 위치한 주 노드(허브라는 중앙장치)에 연결된 케이블로 다른 노드(컴퓨터)들을 연결

- 송신 컴퓨터가 전송한 신호는 허브를 통해 네트워크의 모든 컴퓨터로 보내짐
- Point to point 방식으로 회선을 연결하며, 모든 장치들은 중앙 컴퓨터를 통해서만 데이터를 교환
- 장치가 고장나더라도 다른 장치에 영향을 주지 않음
단, 중앙 컴퓨터가 고장이 나면 전체 통신망이 멈추게 됨

 

 

장점
- 중앙에 허브를 두고 컴퓨터가 별 모양으로 연결되어 있어 설치와 재구성이 쉬움
- 장애 발견이 쉬움
- Network 관리가 쉬움
- 하나의 장애가 다른 네트워크 장비에 영향을 주지 않음

 

단점
- HUB가 고장났을때 전체 Network에 충돌이 일어남
- 많은 양의 케이블을 사용하므로 설치비용이 비쌈

 

 

 Mesh Topology(망, 그물형)

- 네트워크상의 모든 노드를 상호 연결

- 모든 지점의 장치를 서로 연결한 형태로 연결성이 높으며

- 많은 장치와의 통신양이 많을때 유리하며

- 회선에 문제가 생겼을 때 다른 경로를 이용해 데이터를 전송할 수 있음
즉, 각각의 네트워크 장비는 두 개 이상의 선로를 보유하면서 같은 네트워크에 속해있는 다른 네트워크 장비에 연결
- 통신선로의 총길이가 가장 긴 네트워크 구조
- 초기 데이타 통신 네트워크의 전형적인 형태
- 공중통신망에 많이 사용
- 컴퓨터들이 각각 1대 1로 연결되어 그물 모양을 이루며 안정적임

 

 

 

장점
- 장애에 가장 강하고 가장 안전함

- 목적지까지 여러 개의 경로가 존재하기 때문에 한곳에 장애가 생겨도 다른 경로를 통해 데이터를 전송

- 목적지까지 여러 개의 경로중 가장 빠른 경로를 이용하기 때문에 가용성과 효율성이 뛰어남

 

단점 :
- 여러 토폴리지 가운데 설치 비용이 가장 비쌈

- 네트워크 관리가 힘들다.

즉, 규모가 큰 네트워크라면 항상 관리해야 할 엄청난 양의 네트워크 회선과 장비의 상태 

 

 

 트리형 (Tree Topology)  계층형, 분산형
- 중앙 컴퓨터와 일정 지역의 단말장치까지는 하나의 통신 회선으로 연결
- 이웃하는 단말장치는 일정 지역 내에 설치된 중간 단말장치로부터 다시 연결

- 접속되는 단말기의 숫자에 맞는 통신장비 이용이 가능
- multipoint 데이터 통신망

- 분산처리시스템을 구성하는 방식

- 하나의 노드에 여러개의 노드가 트리형으로 연결되어 있는 형태

- 데이터는 양방향으로 모든 노드에 전송

- 실제 사용하는 허브의 사용 방식

 

 

 

장점

- 통신 회선수 절약과 통신선로가 짧음

- 네트워크 확장 용이

 

단점

- 상위 노드 문제시 하위 노드 모두에 영향 미침

- 중앙 지점에서 병목현상 발생 가능

- 중앙 지점 고장 발생 시 네트워크 마비

 

 전체 비교

 

장점

단점

버스

저렴하고 사용하기 편함
매체가 간단하고 믿을만함

트래픽이 많을 경우, 네트워크 속도가 떨어짐
이상발생시 원인 파악이 어려움
케이블 단선시 해당 라인에 영향이 미침

모든 컴퓨터에 대한 동등한 액세스
사용자가 많은 경우에도 성능이 우수함

컴퓨터 하나의 문제에 네트워크 전체가 다운 가능성 있음
문제의 원인을 찾기가 어려움
네트워크 재구성시 운영이 중단됨

스타

컴퓨터 교체나 추가가 용이함
감시와 관리의 집중화
컴퓨터 하나에 문제가 생겨도 전체 네트워크에 영향이 미치지 않음

중앙 장치가 다운될 경우 네트워크 전체에 문제가 발생함

 

'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

P2P((peer to peer))  (0) 2019.11.08
URI, URL 그리고 URN 이란?  (0) 2019.02.25
REST(Representational State Transfer - 작업 중  (0) 2019.02.22
VM vs container  (0) 2019.02.22
컨테이너(Container)?-정리 필요  (0) 2019.02.20

우리는 컴퓨터 네트워크 라는 개념을 접하면서 보게되는 개념이 있습니다. 

서버 기반 그리고 P2P..그리고 클라우드..

이와 같은 개념에 대해서는 들어보셨을 것이고 그림으로 표현하면 다음과 같습니다. 
(이 장에서는 서버기반과 P2P에 대한 개념에 대해서 설명하려고 합니다.)

 

 

Server Based Network는 서버 기반의 네트워크로서,

서버를 중심으로 개인용 PC 들이 서버에게서 정보 및 데이터를 받기 위해 종속되어 있는 형태입니다. 

반면에

Peer To Peer Network는 단대단 기반의 네트워크로서

개인용 PC 들이 서로가 서로에게 정보 및 데이터를 받는 형태입니다. 

즉, 개인용 PC가 서버 역할을 하는 형태라고 보시면 될 것입니다. 

 

그럼 지금부터는 Peer To Peer(이하 P2P)에 대해서 살펴보도록 하겠습니다. 

 

IT 기술적으로 peer to peer 는 Windows XP 에서의 워크그룹 설정(소프트웨어적으로 그룹화)과 같이 어떤 중앙집중적인 관리가 아니라 각 개개의 컴퓨터가 네트워크로 연결되어 있는 네트워크를 말합니다.

 

여기서 peer 는 개별 컴퓨터를 가리킵니다.

 

peer 라는 개념에 대해서 가볍게 알고 가겠습니다.

 

Peer의 영어 단어 원 뜻은

- 동료, 대등한 사람을 뜻합니다.

 

IT 측면에서의 접근 해석 해 보면, 어느 누구도 소셜 네트워크 상에서는 대등한 관계라는 것을 의미합니다.

즉, 그 사람이 무슨 일을 하든지 회사에서 상위 직급에 있든 하위 직급에 있든 동등하다는 것입니다.
* 소셜 네트워크 상에서는 익명성이라는(이름을 밝혀도 그 사람이 어떤 사람인지 밝히지 않는다면 익명이라고 보는 관점) 부분이 존중되는 세상이기 때문입니다.

 

그럼 Peer To Peer를 살펴보면

개인 컴퓨터에서 개인 컴퓨터로.

.와 같이 해석되어집니다. 

즉, 개인들이 컴퓨터나 스마트폰을 통해서 직접적으로 정보나 데이터를 받는 것으로 해석합니다. 

예를 들어서 설명하도록 하겠습니다. 

 

인터넷에서 음악을 듣고 싶을 때 어떻게 하나요.
음원 파일을 살 수 있는 앱을 이용하거나 멜론, 벅스 같은 사이트에 들어가 한 달에 얼마, 또는 한 곡에 얼마씩 돈을 지불하고 음원을 내려받는 것은 서버기반입니다.

 

그런데 내가 가지고 있는 음악 파일을 친구에게 보내주는 경우도 있겠죠. 이런 식으로 정보(음악 파일)를 개인과 개인이 정보를 주고받는 게 P2P 기반입니다.

 

여러 장단점들이 존재할 수 있습니다. 

 

장점 : 

- 고품질의 서비스를 제공받을 수 있습니다.
  : 즉, 더 많은 사용자들이 자유롭게 참여할 수 있기 때문에 안정적이고 고품질의 서비스를 제공받을 수 있습니다.
- 구축 비용이 없습니다.
   : 즉, 사람들이 알아서 서버를 자청하며 생태계를 구축하기 때문에 돈이 들어가지 않습니다.
- 보안 기능이 우수합니다.
   : 즉, 모든 컴퓨터가 서버-클라이언트 역할을 하게되고, 상대방의 컴퓨터를 감시함으로써 올바른 도출을 유도합니다. 
- 장애 복구 비용이 발생하지 않습니다.
   : 즉, 장애가 발생하여도 서비스에 지장이 크지 않거나 고가용성 혹은 내고장성의 서비스를 기본적으로 제공합니다. 

 

단점 : 

- 저작권 보호가 어렵습니다.
   : 즉, 정당한 비용 지불 없이 데이터를 거래하는 경우 컨텐츠를 만든 사람은 시간과 비용에 대한 공이 사라지게 됩니다.
- 노드들의 연결 속도에 영향을 받게 됩니다.
   : 즉, 회선이 느린 노드가 존재할 경우 전체 네트워크의 속도를 저하시킬 수 있게 됩니다.
- 데이터 사용에 어려움이 있습니다.
   : 즉, 데이터를 가지고 있는 PC가 존재하지 않거나, 개방하지 않는다면 데이터를 사용할 수 없게 됩니다.

1. URI (Uniform Resource Indicators : 통합자원 지시자).

* 대부분의 프로토콜은 URL을 참조하지만 SIP에서는 주로 URI (Uniform Resource Indicators)를 참조.

* 이것은 SIP의 이동성 측면에 기인. 즉, 특정 주소 (URI)가 단일 물리적 장치에 묶이지 않고

대신 인터넷에서 이동하고 위치를 변경할 수있는 논리적 엔터티를 의미.

* 그러나 URL과 URI라는 용어는 다른 문맥에서 거의 같은 의미로 사용.

examples :

https://www.iloveyou.com.

sip:love@fwd.love.com

mailto:help@example.com?Subject=hello!


2. URL

(Uniform Resource Locator : 통합자원 식별자)

URL은 실제의 네트웍 경로를 가리키며, 네트웍 상의 리소스 접근시에 사용된다 URL의 첫 번째 부분은 다음과 같은 프로토콜을 명시하는데, 대부분의 경우 http이며, 가끔은 ftp 혹은 mailto이며, 드물게 gopher, news, telnet, file 등을 사용합니다. 이와 같은 URL 프로토콜 부분을 scheme이라고 한다. Scheme 뒤에는 콜론(:)이 따라오며 그 뒤에 식별된 자원의 경로가 나타난다. 다음의 예는 여러 분들이 매우 익숙할 것이다.




http://www.xmlgo.net/document/editor/editor.html


이 URL은 www.xmlgo.net 이라는 이름의 인터넷 상에 있는 서버로부터 /document/editor/editor.html 이라는 파일을 검색하기 위하여 사용될 수 있는 경로(PATH)를 나타낸다. 파일 editor.html 은 /document/editor 이라는 디렉토리에 있으며, HTTP 프로토콜에 의하여 검색되야함을 명시한다. 또 다른 예로써 다음과 같은 전자메일 계정을 가리키는 URL도 있다.


mailto:someone@sungshin.ac.kr

계속해서 다양한 프로토콜에 따른 예를 들어 본다면 ,

  • file -시스템내의 파일 이름 ( file:///C:\windows\xml\test.xml )

  • ftp - ( ftp://ftp.is.co.za/rfc/rfc2141.txt )

  • news - 유즈넷 뉴스 그룹 ( news:comp.xml.xsl )

  • telnet - telnet://www.xmlgo.net

 

물론 URL을 통하여 검색될 수 있는 자원에는 제한이 있다. 컴퓨터로부터 검색가능한 형태의 자원만 검색할 수 있다. 실제의 예를 든다면 , RDF (URI상의,리소스에 관해 기술하는 규칙) : http://www.w3.org/TR/REC-rdf-syntax# SVG (2차원 그래픽,벡터형태의 그래픽, 이미지, 텍스트를 포함,을 표현하는 XML 용어집): http://www.w3c.org/XSL/Format/1.0 등이 네임스페이스로 사용된다.



3. URN

(Uniform Resource Name : 통합자원 명칭)

URN은 자원에 대하여 영속적 (persistent)이고 유일하다. 위치에 독립적인 이름을 제공하기 위하여 존재한다. 이것은 RFC 2141 (http://www.ietf.org/rfc/rfc2141.txt) 에 정의되어 있다.

iURN은 문자열 "urn" 혹은 "URN", NID (Namespace Identifier), 그리고 NSS (Namespace Specific String)로 구성되어 있으며 각 구성 엘리먼트간에 콜론(:)을 위치시킨다. NID는 URN의 형태를 나타내는데, 예를 들어 차후 XMLgo.net에서 ebXML문서의 형태로 각 회사의 정보를 기억해 두는 저장소를 URN으로 가리키고 , NSS 는 유일하고 영속적이여야 하며, 여기서는 registry1이라고 칭하였다.



urn:xmlgo:registry1



좀더 현실적인 예를 들어 본다면

한국인을 위한 URN을 만들기 위하여 한국-시민 이라고 선언할 수 있다. NSS 로는 유일한 번호, 주민등록 번호를 표현하도록 한다면 000000-0000000 이 될 것이다.



urn:한국-시민:000000-0000000

 

4. 이해를 위한 예제

지금까지의 내용을 종합해 보면, Namespace를 지정할 때 URI 로 지정한다. URI로는 현재 널리 사용하는 웹주소, URL 방식과 URN 방식이 포함 되어 있다. 일반적으로 URL을 많이 사용하나 URN도 널리 사용 될 것이다. URL에서는 도메인 주소와 거기에 위치한 물리적인 경로가 자원을 찾기 위한 중요한 정보가 되지만, URN은 자원에 부여된 고유한 이름으로 그 자원의 위치와는 무관하게 부여된 이름이다.


이를 구체적으로 예를 들면 , 인천 광역시 남구 용현동에 인하대학교가 있지만, 인하대학교는 새로운 부지로 이사를 갈 수도 있을 것이다. 인하대학교가 어디에 있는지는 URL(주소)로 표현 할 수 있지만, 인하대학교가 다른 곳으로 가더라도 URN을 가지고 그 리소스(인하대학교)을 식별할 수 있다. 이사를 가고 나서 ‘인천광역시 남구 용현동의 인하대학교’ 라는 기존의 주소를 가지고는 인하대학교를 찾을 수 없다. 하지만 인하대학교란 고유한 이름은 변함이 없을 것이다


'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

토폴로지(topology)  (0) 2019.11.12
P2P((peer to peer))  (0) 2019.11.08
REST(Representational State Transfer - 작업 중  (0) 2019.02.22
VM vs container  (0) 2019.02.22
컨테이너(Container)?-정리 필요  (0) 2019.02.20

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 이 개념은 네트워킹 문화에 널리 퍼졌다.


엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP나 WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다.



JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.



HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.

웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

CRUD Operation

Create : 생성(POST)

Read : 조회(GET)

Update : 수정(PUT)

Delete : 삭제(DELETE)

HEAD: header 정보 조회(HEAD)






'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

P2P((peer to peer))  (0) 2019.11.08
URI, URL 그리고 URN 이란?  (0) 2019.02.25
VM vs container  (0) 2019.02.22
컨테이너(Container)?-정리 필요  (0) 2019.02.20
이클립스(Eclipse)  (0) 2019.02.19

Container(컨테이너)를 이해하기 위해서는 Virtual Machine(가상머신, VM) 개념을 알고 있는것이 좋을 것 같다. 


컨테이너 개념 및 도입된 이유를 알기 위해서는 VM에 대한 특징부터 살펴보는 것이 좋을 것 같다. 

1. 개념 구성도


개념 구성도부터 살펴보도록 하겠다.



 

 

 VM 개념도

Container 개념도 




출처 : https://www.docker.com/what-docker


Virtual Machine 은 구성도는 다음과 같다. 



하드웨어 가상화

소프트웨어로 구현된 하드웨어

소프트웨어로 구현된 하드웨어 그 위에 OS를 설치하고, 그 위에 소프트웨어를 설치함으로써 무겁고 느린 단점

위 단점으로 반가상화 기술방식의 Xen이 등장하였지만, 성능문제는 해결되지 못함

예 : VMWare, VirtualBox 등



Container:

리눅스에서 하드웨어 가상화와 OS설치를 하지 않고 단순히 프로세스를 단독으로 격리시키는 기술 컨테이너라는 기술이 등장

하드웨어 및 OS 계층을 두지 않고 프로세스만 격리하므로 실제 그냥 앱을 실행하는 경우와 거의 차이가 보이지 않을 정도로 Virtual Machine 에 비해 성능문제가 해결됨

리눅스 OS에서 지원하는 기술로 LXC(Linux Container)라는 시스템 레벨의 컨테이너 기술을 제공

초기 Docker는 LXC 기술을 채용했으나, 0.9버전 이후에는 libcontainer라는 자체 컨테이너 사용

IT 관련된 업무에 관련된 사람이라면 컨테이너에 대한 애기를 한번쯤은 들어봤을 것이다. 

하지만, VM이란 용어는 흔하게 많이 접해봤을 것이다. 
좀 더 깊숙하게 들여다보면 VM과 컨테이너를 비교한 자료들이 많이 있을 것이다.

이제 IT 흐름은 컨테이너 기반의 환경이 구성되어 있다. 

컨테이너 개념을 알고가 하기 전에 컨테이너가 진정으로 의미하는 바는 무엇이며 어떻게 작동하고 왜 중요한 것일까에 대한 생각부터 해야 할 필요가 있다. 

그럼 먼저, 컨테이너를 알기 위해서는 VM 개념을 알아야 한다.

그리고 VM 개념을 알기 위해서는 OS와 Kernel 개념을 알아야 한다.


따라서, OS와 커널에 대한 개념부터 짚고 넘어가도록 하겠다.

1. OS and Kernel

대부분의 컴퓨터 및 전자 장치들은 CPU, 보조(장기) 기억 장치(디스크 드라이브, SSD), 메모리, 네트워크 카드 등과 같은 하드웨어를 기반으로 만들어져 있다.

컴퓨터 내에서 어떤 정보를 공유하기 위해서는 이러한 하드웨어간 상호작용을 해야 한다. 이러한 상호 작용을 하기 위해서는 운영체제(OS) 안에 있는 커널(kernel)이라는 것이 하드웨어간 상호 작용을 할 수 있는 다리 역할을 수행한다. 뿐만 아니라, 커널은 실행될 프로세스(프로그램)의 스케쥴링을 담당하며, 장치들을 관리(디스크나 메모리의 특정 주소를 읽거나 쓰고)하는 등 많은 일들을 수행한다. 


컴퓨터 내부의 모습>


2. 가상 머신이란.

IT 개발자 및 운영자들은 현재의 사용하고 있는 컴퓨터에서 더 많은 일들을 하고 싶어한다. 
이유는 크게 2가지로 생각해 볼 수 있다. 
지금 사용하고 있는 컴퓨터에게 명령을 내렸는데, CPU 및 여러 하드웨어들은 명령을 모두 마친 후 쉬고 있는데, 업무를 수행하고 있는 프로세스가 계속해서 일하고 있기 때문이다. 즉, 소프트웨어가 하드웨어를 따라가지 못하고 있는 상황이다. 따라서, CPU를 비롯한 다양한 하드웨어들이 쉬지 말고 계속해서 일하도록 하기 위해 하나의 컴퓨터에 여러 개의 컴퓨터를 구성해서 CPU 및 하드웨어를 여러개로 나누어서 쉬지 못하고 계속해서 일하도록 하기 위해서이다. 

또 하나는, IT 환경이 변화하고 있는 상황에서 IT 개발자 및 운영자들은 다양한 환경에서 업무를 수행해야 하는 상황이 되고 있다. 그런데, 여러개의 컴퓨터를 마련하기에는 많은 비용이 소비될 뿐만 아니라, 여러대의 컴퓨터를 가지고 이동하는 것도 어려운 현실이다. 따라서, 한대의 컴퓨터에 여러 개의 컴퓨터를 만들수 있기를 희망하고 있다. 이러한 요구사항을 만족하기 위해서 여러 개의 가상화 환경을 만들고 각각의 가상화 환경에 CPU 등 하드웨어를 여러 개로 나누어서 사용할 수 있도록 한다. 이것이 가상 머신의 개념이다. 


2.2 가상 머신 구성
그럼 한 대의 컴퓨터에 여러 대의 컴퓨터를 만들기 위해서는 가상 머신 환경을 구성해야 한다. 

가상머신도 하나의 컴퓨터를 구성하기 위한 환경이다. 
따라서, 가상머신에도 컴퓨터를 운영할 수 있는 기본 운영체제가 있어야 한다. 일반적으로 이것을 게스트 운영체제라고 한다. 실질적으로 운영되는 메인 OS는 호스트 운영체제라고 한다.

그렇다면 게스트 운영체제를 만들어야 하고, CPU 및 하드웨어들도 몇 개로 분할해야 하는데, 이러한 작업을 수행하도록 돕는 것이 하이퍼바이저(hypervisor)라고 하는 것이 수행한다. 





하이퍼바이저는 호스트 OS 위에서 동작하거나, bare metal 방식처럼 머신 하드웨어 위에서 직접적으로 동작하는 (기존 OS를 대체하는) 것입니다 . 어떤 방식이든, 하이퍼바이저를 사용한 접근법은 다수의 파트에 대한 가상화를 필요로 하기 때문에 무겁다고 여겨진다.

같은 머신에 다수의 독립적인 그룹을 구성할 필요성이 있을 때, 각각의 그룹에 대해 가상머신을 작동시키는 것은 좋은 접근법이라기엔 너무 무겁고 리소스를 낭비하게 된다.


추후에 말하겠지만, 컨테이너 방식과 비교해 볼때 
가상머신은 머신 수준의 분리를 위해 하드웨어 가상화가 필요한 반면 컨테이너는 동일한 운영체제 내의 독립된 공간에서 실행된다. 독립된 공간의 수가 증가할 수록 오버헤드의 차이가 더 명확해진다. 
예를 들면, 노트북으로 수십개의 컨테이너를 실행시킬 수 있는 반면에 
가상머신의 경우는 단 하나의 가상머신도 버거울 수 있다.


3. 발전 동향

2006년, 구글의 엔지니어들은 Linux “control groups”라는 것을 발명하였고 이를 줄여 cgroups이라 하는데, cgroups는 유저 프로세스의 리소스 사용을 분리하여 관리하는 Linux 커널의 기능을 애기한다. 

리소스 관리를 위해 프로세스의 집합인 네임스페이스(namespace)에 집어 넣을 수 있는데, 하나의 컴퓨터는 다수의 네임스페이스를 가질 수 있고, 각각은 커널에 의해 제한을 갖게 된다. 

즉, 네임스페이스 별로 CPU, RAM 등의 리소스 양을 할당받는 되는데, 이러한 이유는 프로세스가 서버를 점유하지 못하도록 제한을 두기 위한 것이다. 

Linux의 cgroups 이라는 커널 기능에서의 네임스페이스 분리 자체는 프로세스 분리(process isolation) 개념을 가지고 공유 메모리와 같은 일들을 방지한다. 

또한, 프로세스들이 독립적일수 있도록 보장해주는 기능을 가진다.

이러한 개념에서 보여지듯이 네임스페이스 내부의 프로세스는 각각의 고유한 머신으로 보여질 수 있으며, 컨테이너의 시발점이 된다고 볼 수 있다. 

Linux cgroups는 LXC (linux container)라는 기술의 기반이 되었다고 한다. 

LXC는 오늘날 컨테이너라고 불리는 것의 가장 첫 번째 구현이라고 할 수 있다.  

따라서, 여러가지로 혼합해 보면, 리눅스 기반의 cgroups와 네임스페이스 분리 기능을 사용하여 별개의 프로세스와 네트워킹 스페이스를 가진 가상 환경을 만들어내게 되었고,

이러한 기술 기반의 LXC는 독립적이고 격리된 유저 스페이스를 어느 정도 가능하게 했다.

LXC 기본 개념이 컨테이너가 되엇으며, 초기의 Docker는 LXC을 기반으로 하여 만들어졌다.

따라서, Docker는 가장 널리 사용되는 컨테이너 기술이고, 

사람들이 컨테이너라고 하면 대부분 Docker를 가르키는 이유이기도 하다.


Docker

Docker는 가장 널리 사용되는 컨테이너 기술이고, 사람들이 컨테이너라고 하면 대부분 Docker를 가르킨다. 그 이유는 Docker는 여전히 cgroups와 Linux 커널, 최근 Windows에서 제공되는 네임스페이스 기술을 기반으로 하고 있으며, Docker는 컨테이너화(containerization)의 산업 표준이 되었기 때문이기도 하다. 물론 다른 오픈소스 컨테이너 기술들(CoreOS의 rkt 등)과 직접 컨테이너 엔진을 만드는 거대 기업들(Google의 lmctfy 등)도 존재한다. 

Docker 컨테이너는 여러 image(이미지, 하나의 패키지로 묶인 바이너리)들의 레이어로 이루어져 있다. base image는 컨테이너의 운영체제를 포함하고 있고, 이 OS는 호스트의 OS와 다를 수 있다.


이 base image 위에 각각의 컨테이너 부분이 되는 다수의 이미지들이 올라가는데, 예를 들어, apt-get 의존성을 포함하는 이미지가 base image 위에 올라갈 수 있게 된다. 그 위에는 어플리케이션 바이너리 등을 포함하는 이미지가 올라갈 수 있다.

예를 들면, 두 컨테이너가 각각 레이어 a, b, c와 레이어 a, b, d로 되어 있다면 각 레이어 a, b, c, d의 하나의 복사본만을 local과 repository에 보관하면 된다. 이것이 바로 Docker의 유니온 파일 시스템(union file system)이다. 

해시로 식별되는 각 이미지는 컨테이너를 구성하는 많은 가용 레이어 이미지들 중 하나입니다. 하지만 컨테이어너는 최상위 이미지로 식별되며, 부모 이미지에 대한 참조를 가집니다. 위 그림에서 두 최상위 이미지(image 1과 image 2)는 첫 3개의 레이어를 공유하고 있습니다. image 2는 구성과 관련된 2개의 레이어를 부가 적으로 가지지만, image 1과 같은 부모 이미지를 공유하고 있습니다.

컨테이너가 부팅되면, 해당 이미지와 부모 이미지들이 저장소로부터 다운로드되고, cgorup과 네임스페이스가 만들어지며, 이미지를 사용하여 가상 환경을 생성한다. 컨테이너 내에서는, 이미지에 명시된 파일과 바이너리들은 전체 머신에서의 유일한 파일들로 나타내어 진다. 이후 컨테이너의 메인 프로세스가 실행되고 컨테이너는 alive 상태가 된다.


Docker는 copy on write, volume(컨테이너 사이에서 공유되는 파일 시스템), docker daemon(머신의 컨테이너들을 관리), 버전 관리 저장소(컨테이너를 위한 Github) 등의 기능들을 가지고 있다. 

Docker를 사용하는 실용적인 예제 관련 내용이다.

①②클라이언트는 도커 데몬이라고 불리는 프로세스에 무엇을 해야할지 알려주고, 

③이 데몬은 registry 또는 repository로부터 이미지를 가져오고

④ 이러한 이미지들은 로컬 머신에 캐시되고

⑤ 데몬에 의해서 부팅되어 컨테이너를 실행합니다


Why Containers

프로세스 분리 이외에, 컨테이너는 다른 많은 이점이 있다.

컨테이너는 스스로 독립된 유닛으로서 해당 컨테이너를 지원하는 어느 곳에서든 실행될 수 있다. 즉, 호스트 OS가 CentOS이던 Ubuntu이던 MacOS이건 심지어 Windows와 같은 UNIX 기반 OS인지 상관없으며, 컨테이너가 지정한 OS가 된다. 

또한 컨테이너는 표준화된 작업 또는 연산의 유닛 역할을 하는데, 

각 컨테이너가 하나의 웹서버, 하나의 데이터베이스 등으로 구성하게 할 수 있는데, 이렇게 하는 경우, 어플리케이션의 규모를 키우기(scale) 위해서는, 단순히 컨테이너의 수를 늘리기만 하면 된다. 

즉, 각 컨테이너에게는 일정한 리소스 설정(CPU, RAM, 스레드의 수 등)이 주어지고, 어플리케이션의 규모를 증가시키기 위해서는 개별적인 컨테이너의 리소스 설정을 변경하는 대신 단지 컨테이너의 수를 증가시키면 된다. 이는 엔지니어가 어플리케이션의 규모를 증가시키거나 축소시켜야 할 때, 훨씬 쉽게 기능을 제공하는 것과 같다.

이러한 조합법에 기반하여 컨테이너들을 마이크로 서비스 아키텍처를 구현하기 위한 훌륭한 도구로 사용할 수 있게 되는데, 예를 들어 Redis 마이크로 서비스는 하나의 마스터 컨테이너와 다수의 슬레이브 컨테이너를 사용하여 구현할 수 있다.

이러한 (마이크로) 서비스 지향적 아키텍처는 엔지니어링 팀이 어플리케이션을 개발하고 배포하는 것을 쉽게 해주는 많은 중요한 성질들을 가지고 있다.


Orchestration

Linux 컨테이너의 사용자들은 각 컨테이너에서 프로세스가 실행되는 여러 개의 가상 머신에 걸쳐 규모가 큰 어플리케이션을 배포하고자 하는 경우, 

이를 위해서 수만개의 컨테이너를 수백개의 가상 머신에 걸쳐 효과적으로 배포할 수 있어야 했고, 이 사이의 네트워킹, 파일 시스템, 리소스 등을 효과적으로 관리할 수 있어야 했다. 

오늘날의 Docker는 컨테이너 네트워킹, volume을 위한 파일 시스템, 리소스 설정 등을 정의하는 추상화를 통해서 이를 더욱 쉽게 할 수 있도록 하였다.

하지만 다음과 같은 것들을 위해 Docker 이외의 툴이 여전히 필요하다.

  • 실제로 명세(specification)을 받아들이고 컨테이너를 머신에 할당 (스케쥴링)
  • 실제로 docker를 통해 지정된 컨테이너를 해당 머신에서 실행
  • 업그레이드, 롤백, 끊임없이 변경되는 시스템의 성질에 대한 처리
  • 컨테이너 크래시와 같은 고장에 대한 대응
  • 서비스 디스커버리, VM 간 네트워킹, 클러스터에 대한 추가(ingress), 제거(egress) 등의 클러스터 리소스 생성

이들은 (일시적일 수도 있고 또는 끊임없이 변화할 수도 있는) 컨테이너들의 집합 위에 만들어진 분산 시스템의 오케스트레이션(orchestration)과 관련이 있는 문제들이고, 사람들은 이 문제들을 해결하기 위해서 정말 대단한 시스템을 구축

출처 : https://goofcode.github.io/container-101


'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

REST(Representational State Transfer - 작업 중  (0) 2019.02.22
VM vs container  (0) 2019.02.22
이클립스(Eclipse)  (0) 2019.02.19
Maven-> working  (0) 2019.02.19
스위프트(Swift)  (0) 2019.02.15

IBM 주도 자바 기반의 오픈 소스 프로젝트로 IDE(통합개발환경)의 대표적인 자바 개발 프로그램이다


프로그래밍을 하려면 코드를 작성하고, 저장하고 컴파일 및 디버깅을 도와주는 통합 개발 환경(Integrated Development Enviornment, IDE)이 필요하다. 현재 다양한 IDE가 존재하지만 자바 개발자에게 가장 사랑받는 IDE로 ‘이클립스’를 빼놓을 수 없다.


이클립스 구조. 



자바 가상머신(VM)과 이클립스 플랫폼, JDT와 플러그인으로 구성돼 있다. 

 <출처: SlideShare - Australian Nuclear Science and Technology Organisation>



 이클립스는 기본적으로 자바 개발에 최적화된 기술을 제공한다. 큰 구조는 자바 가상머신(VM) 위에 이클립스 플랫폼이 있고, 그 위에 자바 개발도구(Java Development Tools, JDT)를 제공하고 플러그인을 붙이는 형식이다. 이클립스 플랫폼은 표준 위젯 툴킷(Standard Widget Toolkit, SWT)이라는 GUI 위젯 툴킷, 코드 작성, 빌드, 리팩토링을 할 수 있는 워크벤치(Workbench) 등으로 구성된다.


이클립스는 자바를 넘어 다양한 영역으로 확장되고 있다. 

구글이 ‘이클립스 ADT (Android Development Tools)’라는 플러그인을 지원하며 이클립스는 안드로이드 개발자에게도 인기를 끌었다. 


 이클립스의 가장 최신 버전은 ‘네온(Neon)’이다. 

네온은 PHP, 자바스크립트, 도커, 사물인터넷(IoT) 등을 위한 기술을 지원해 웹, 인프라 등 다양한 산업 분야에 쓰일 수 있다. 


클라우드 IDE ‘체(Che)’는 따로 프로그램을 설치하지 않고 웹브라우저에서 바로 이클립스를 이용할 수 있는 서비스다.





'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

VM vs container  (0) 2019.02.22
컨테이너(Container)?-정리 필요  (0) 2019.02.20
Maven-> working  (0) 2019.02.19
스위프트(Swift)  (0) 2019.02.15
자바스크립트( JAVA script)  (0) 2019.02.15

아파치 메이븐(Apache Maven)은 자바용 프로젝트 관리 도구이다. 아파치 앤트의 대안으로 만들어졌다. 아파치 라이선스로 배포되는 오픈 소스 소프트웨어이다. 

'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

컨테이너(Container)?-정리 필요  (0) 2019.02.20
이클립스(Eclipse)  (0) 2019.02.19
스위프트(Swift)  (0) 2019.02.15
자바스크립트( JAVA script)  (0) 2019.02.15
정리 필요  (0) 2019.02.14

스위프트는 iOS OS X 운영체제에 최적화된 프로그래밍 언어다. 

과거 iOS OS X 앱을 개발하기 위해선 ‘오브젝티브 C’라는 언어를 이용해야 했다. 기존 C언어에 ‘오브젝티브(Objective, 객체지향)’의 성격을 섞은 언어였다.


오브젝티브 C는 iOS OS X 개발자의 주류 언어로 자리잡았다.

스위프트는 오브젝티브 C에서 C언어의 특성을 줄이고 객체지향 언어의 성격을 강화한 언어다. 

애플이 2014년 내놓은 신규 프로그래밍 언어로 기존 언어를 대체하며 빠르게 사용이 증가하고 있다. 
스위프트는 모바일 운용체계(OS) iOS와 컴퓨터용 OS OS X 개발용으로 사용할 수 있는 새 프로그래밍 언어이다. 
함수형과 객체형 언어 중간 격으로 스크립트 언어이기 때문에 컴파일이 필요 없다. 



'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

이클립스(Eclipse)  (0) 2019.02.19
Maven-> working  (0) 2019.02.19
자바스크립트( JAVA script)  (0) 2019.02.15
정리 필요  (0) 2019.02.14
프레임워크에 대한 이해  (0) 2019.02.14

자바스크립트는 1995년 미국의 넷스케이프 커뮤니케이션즈(Netscape Communications)에서 처음 개발되었다. 자바스크립트 표준은 1996년 11월부터 유럽 컴퓨터 제조업자 협회(ECMA: European Computer ManufacturersAssociation) 기술위원회 39(TC-39)에서 에크마스크립트(ECMAScript, ECMA-262)라는 이름으로 개발되었다. 최신 표준은 2017년 6월에 제정된 ECMAScript 2017이며, 2015년부터 1년에 한 번씩 새로운 버전의 ECMAScript를 공개하고 있다.


HTML 문서의 정적이고 단조로운 한계를 극복하기 위해 넷스케이프(Netscape)사가 만든 livescript가 그 이름을 달리 한 것으로서 브라우저 자체에 내장된 해석기능을 이용한 클라이언트(client) 기반의 일종의 스크립트 언어이다. 작고도 빠르기 때문에 웹문서를 동적으로 꾸밀 때 가장 널리 쓰인다.


즉, 웹 페이지에서 사용자로부터 특정 이벤트나 입력 값을 받아 동적인 처리를 목적으로 고안된 객체 기반의 스크립트 프로그래밍 언어이다. 


'정보관리기술사 도전 > 용어 정의' 카테고리의 다른 글

Maven-> working  (0) 2019.02.19
스위프트(Swift)  (0) 2019.02.15
정리 필요  (0) 2019.02.14
프레임워크에 대한 이해  (0) 2019.02.14
푸쉬(Push) Service  (0) 2018.11.30

+ Recent posts