서버에 기능을 추가 하려면 개발자가 개발자 노트북에서 개발을 하고 테스트까지 한 다음에 이상이 없으면 사용자가 사용할 수 있게 수정된 내용을 서버에 반영해야 한다.


빌드는 서버에 올릴 수 있는 상태로 만드는 것을 빌드(Build)라고 한다.

서버에 올려서 사용자가 사용 할 수 있게 하는 것은 배포(Deploy)라고 한다.



Build를 자동화 해야하는 이유

빌드는 하루에 한번을 할 수도 있고 안할수도 있지만 1주일, 1달로 따지면 꽤 많이 한다. 그리고 이게 1년이면 꽤 많은 시간이라고 할 수 있다.


예를들면 옛날에는 자바를 빌드 할 때 javac라는 커맨드를 직접 사용 했지만 지금은 IDEA를 쓰면 main()메소드를 실행하면 javac를 하고 java가 실행이 된다.

이렇게 반복되는 과정은 버튼 하나 또는 단축키로 자동화 시킬 필요가 있다.


왜냐하면 이 작업을 하는데도 집중력, 긴장감 등이 소모 되기 때문이다. 그리고 빌드는 시간이 꽤 걸리는 작업인데(30초 이상 걸림) 빌드를 실행 시키고 나서 빌드가 될 때까지 기다리는 시간도 모아보면 엄청 길 것이다.


개발자의 시간은 소중하기 때문에 최대한 반복작업은 자동화 할 필요가 있다.


암튼 나도 손꾸락으로 빌드를 5개월쯤 하니 자동화를 안시킬 수가 없었다. 수정하고 빌드하고 dev에 올리고 하는데 너무 시간을 많이 잡아먹기 때문이다.



Jenkins란?

위에서 이야기한 빌드를 자동화 해주는 툴이다.


Jenkins는 빌드를 자동화 시키기 위해 사용한다.



Jenkins를 안쓰게 되는 이유

이유1 세팅하기 어렵다
이유2 세팅이 잘 안된다
이유3 세팅이 힘들다

젠킨스를 쓰려면 젠킨스 서버를 띄워야 한다. 그런데 요즘은 그나마 많이 비교적 쉬워져서(비교적 쉬운거지 절대 쉽다는게 아님) 띄울만 해졌는데 전에는 너무 어려웠다.

AWS에 EC2띄우고 젠킨스 받아서 띄우면 되는데 이게 선행 지식이 많이 필요하다.

AWS에 띄울려면 VPC, Security Group, IAM등에 대해 알아야 서버가 띄워도 접근을 못ᅥᆻ하는 안타까운 일이 벌어지지 않는다.

나도 이걸 해볼려고 매년 시도는 했었는데 6년차가 된 지금에야 겨우 git pull받고 build하기까지가 너무 어려웠다.

이런 어려움에도 불구하고 젠킨스를 도입하려고 문서 찾아보고 시간쓰고 하는 이유는 손빌드가 너무 심적으로 힘들기 때문이다.

그러니 부디 자동화를 미리 해놓는게 가장 시간을 아끼는 길이다.



https://namu.live/b/live?p=5


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

데몬(Daemon)서비스  (0) 2018.11.30
Jenkins [제킨스]  (0) 2018.11.28
ZooKeeper  (0) 2018.11.21
Redis cluster  (2) 2018.11.20
DB 분류 및 종류  (0) 2018.11.20

분산 시스템을 설계 시 발생되는 문제점

- 분산된 시스템간의 정보를 어떻게 공유할것이고, 

- 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 

- 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것



=> 이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, 

Apache Zookeeper가 대표적

- Zookeeper는 자체적으로 클러스터링을 제공하며, 장애에도 데이타 유실 없이 fail over/fail back이 가능.



코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보 등을 유지하기 때문에, 

코디네이션 서비스의 장애로 인한 전체 시스템의 장애를 유발하는 경우

이중화 등을 통하여 고가용성을 제공해야 함



ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 

그런 이유로 이미 유명한 분산 솔루션에 많이 사용되고 있다. 

NoSQL의 한종류인 Apache HBase, 대용량 분산 큐 시스템인 Kafka등이 그 대표적인 사례.


분산 시스템을 코디네이션 하는 용도로 디자인이 되었기 때문에, 

- 데이타 엑세스가 빨라야 하며, 

- 자체적으로 장애에 대한 대응성을 가져야 함



Apache Zookeeper의 기능

- 디렉토리 구조기반으로 znode라는 데이타 저장 객체를 제공하고, (key-value식). 

 . 이 객체에 데이타를 넣고 빼는 기능만을 제공

 . 디렉토리 형식을 사용하기 때문에 데이타를 계층화된 구조로 저장하기 용이.




데이타 모델

- 디렉토리 구조의 각 노드에 데이타를 저장




노드는 아래와 같이 기능에 따라 몇가지 종류로 나뉘어 지는데 



Persistent Node : 노드에 데이타를 저장하면 일부러 삭제하지 않는 이상 삭제되지 않고 영구히 저장된다.


Ephemeral Node : 노드를 생성한 클라이언트의 세션이 연결되어 있을 경우만 유효하다. 즉 클라이언트 연결이 끊어지는 순간 삭제 된다. 이를 통해서 클라이언트가 연결이 되어 있는지 아닌지를 판단하는데 사용할 수 있다. (클러스터를 구성할때 클러스터내에 서버가 들어오면, 이 Ephemeral Node로 등록하면 된다.)


Sequence Node : 노드를 생성할때 자동으로 sequence 번호가 붙는 노드이다. 주로 분산락을 구현하는데 이용된다.



Watcher

Watch 기능은 ZooKeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려준다. 그리고 해당 watcher는 삭제 된다. 



출처: http://bcho.tistory.com/1016 [조대협의 블로그]

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

Jenkins [제킨스]  (0) 2018.11.28
빌드란? 그리고 Jenkins(젠킨스)란? 써야 하는 이유  (0) 2018.11.28
Redis cluster  (2) 2018.11.20
DB 분류 및 종류  (0) 2018.11.20
REDIS( REmote DIctionary Server)  (0) 2018.11.20

Redis 클러스터는 여러개의 Redis 노드들에 데이타를 자동으로 분배가 가능하도록 설치할수 있는 몇가지 방법을 제공 하며 또한 효율적인 파티션의 분활 방식을 제공
-> 어떤 노드들이 실패가 발생해서 통신을 할수 없는 경우에도 작업이 계속될 수 있는 기능

데이타들을 여러 노드에 자동으로 분배해 주는 기능
-> 일부 노드들이 실패하는 경우, 다른 클러스터들과 통신이 불가능 해도 운영을 계속할수 있는 기능

DBMS는 데이터 저장 구조와 모델을 기준으로 일반적으로 분류하는데 이 경우 RDB, ORDB, OODB, HDB, NDB
그리고 Document DB, KeyValue DB, ColumnFamily DB, Graph DB라고 분류합니다.
데이터 구조와 모델과 관계없이 File기반 DBMS와 In-Memory 기반 DBMS로 분류할 수 도 있는데 이것은
데이터 저장 방법 및 운영 방법에 따른 분류 방법이라고 말할 수 있습니다.


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

ZooKeeper  (0) 2018.11.21
Redis cluster  (2) 2018.11.20
REDIS( REmote DIctionary Server)  (0) 2018.11.20
CI/CD(Continuous Integration / Continuous Deployment)  (0) 2018.11.20
멀티테넌시(Multitenancy)  (0) 2018.11.20

Redis DB는 대표적인 KeyValue Database 제품 중에 하나이며, 

또한 Pure In-Memory DBMS(In-Memory DB는 잘못된 표현임)

Redis는 빠른 오픈 소스 인 메모리 키 값 데이터 구조 스토어임
즉, 키 값에 매핑하는 값에 다양한 데이터 타입을 매핑시키는 구조임

Redis는 다양한 인 메모리 데이터 구조 집합을 제공하므로 다양한 사용자 정의 애플리케이션을 손쉽게 생성. 
주요 Redis 사용 사례로는 캐싱, 세션 관리, pub/sub 및 순위표를 들 수 있음

Redis는 속도가 빠르고 사용이 간편하여 최고의 성능이 필요한 웹, 모바일, 게임, 광고 기술 및 IoT 애플리케이션에서 널리 사용되고 있음

순수 In-Memory 기반 DB인 Redis를 데이터 통계,집계용으로 활용함으로써 시스템 성능 개선를 위해 사용





위 Redis 아키텍처는 다음과 같은 구성요소를 가짐

1)프로세스 :
  - Redis-cli.exe        : Redis 서버에 접속하기 위해 요구되는 Client용 SW  
  - Redis-Server.exe   : Redis 서버 인스턴스를 시작할 때 사용되는 SW
  - Redis-sentinel.exe  : 복제 서버를 구축할 때 Master와 Slave 간에 Fail-Over와 Load-Balance를 담담하는 SW
  
2) 메모리  : 
  - Residence-영역    : 데이터를 처리할 떄 실제 사용되는 메모리 영역
  - Data Structure 영역: 데이터 처리시 관련 메타 정보를 저장, 관리하는 메모리 영역 

3) 파일    : 
  - dump 파일, aof 파일 : 사용자 데이터의 일부 또는 전체를 필요에 따라 디스크 상에 파일로 저장할 때 사용되는 파일


특징 (출처 : https://aws.amazon.com/)

놀라울 정도로 빠른 성능
데이터를 디스크 또는 SSD에 저장하는 대부분의 데이터베이스 관리 시스템과는 달리 모든 Redis 데이터는 서버의 주 메모리에 상주합니다. Redis와 같은 인 메모리 데이터베이스는 디스크에 액세스해야 할 필요를 없앰으로써 검색 시간으로 인한 지연을 방지하고 CPU 명령을 적게 사용하는 좀 더 간단한 알고리즘으로 데이터에 액세스할 수 있습니다. 일반적으로 작업을 실행하는 데 1밀초 미만이 소요됩니다.

인 메모리 데이터 구조
Redis를 사용하면 사용자가 다양한 데이터 유형에 매핑되는 키를 저장할 수 있습니다. 기본적인 데이터 유형은 String으로서, 텍스트 또는 이진 데이터가 이에 해당하며 최대 크기는 512MB입니다. 또한, Redis는 문자열이 추가된 순서대로 유지되는 Lists of Strings, Sets of unordered Strings, 점수에 따라 정렬되는 Sorted Sets, 필드와 값 목록을 저장하는 Hashes, 데이터 세트에서 고유한 항목을 세는 HyperLogLogs를 지원합니다. 거의 모든 유형의 데이터가 Redis를 사용하여 인 메모리에 저장될 수 있습니다.

다양성과 사용 편의성
Redis는 개발과 운영을 좀 더 쉽고 좀 더 빠르게 수행할 수 있는 여러 가지 도구를 제공합니다. Pub/Sub는 메시지를 채널에 게시하며, 채널에서 구독자에게 전달됩니다. 채팅과 메시징 시스템에 매우 적합합니다. TTL 키는 해당 기간 후에는 스스로를 삭제하는 지정된 Time To Live 값을 가질 수 있습니다. 데이터베이스를 불필요한 데이터로 채우지 않도록 하는 데 유용합니다. 원자성 카운터는 경합 상태가 일관성 없는 결과를 생성하지 않도록 합니다. Lua는 강력하지만 간단한 스크립팅 언어입니다.

복제 및 지속성
Redis는 마스터-슬레이브 아키텍처를 사용하며 비동기식 복제를 지원하여 데이터가 여러 슬레이브 서버에 복제될 수 있습니다. 이렇게 하면 주 서버에 장애가 발생하는 경우 요청이 여러 서버로 분산될 수 있으므로 향상된 읽기 성능과 복구 기능을 모두 제공할 수 있습니다.

Redis는 안정성을 제공하기 위해 특정 시점 스냅샷(Redis 데이터 세트를 디스크로 복사)과 데이터가 변경될 때마다 이를 디스크에 저장하는 Append Only File(AOF) 생성을 모두 지원합니다. 두 방법 모두 모두 장애 발생 시 Redis 데이터를 신속하게 복원할 수 있습니다.

선호하는 개발 언어 지원
Redis 개발자는 백 개가 넘는 오픈 소스 클라이언트를 사용할 수 있으며, Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, R, Go를 비롯한 다수의 언어가 지원


Redis 사용 사례(출처 : https://aws.amazon.com/)


캐싱

 

 


다른 데이터베이스 "앞"에 배치된 Redis는 성능이 뛰어난 인 메모리 캐시를 생성하여 액세스 지연 시간을 줄이고, 처리량을 늘리며, 관계형 또는 NoSQL 데이터베이스의 부담을 줄여줍니다.

 

 

 

 

 

 

 

 






Redis는 세션 관리 작업에 매우 적합합니다. Redis를 세션 키에 대한 적절한 TTL과 함께 빠른 키 값 스토어로 사용하면 간단하게 세션 정보를 관리할 수 있습니다. 세션 관리는 주로 게임, 전자 상거래 웹 사이트, 소셜 미디어 플랫폼을 비롯한 온라인 애플리케이션에 필요합니다.

Redis Sorted Set 데이터 구조를 사용하면 요소가 목록에 유지되고 점수에 따라 정렬됩니다. 이를 통해 손쉽게 동적 순위표를 생성하여 게임에서 앞서있는 사람이 누구인지 보여주거나, 좋아요를 가장 많이 받은 메시지를 게시하거나, 선두에 있는 사람이 누구인지 보여주려는 다양한 사례에 사용할 수 있습니다.

Redis는 이벤트 속도를 측정하고 필요한 경우 제한할 수 있습니다. 클라이언트의 API 키에 연결된 Redis 카운터를 사용하여 특정 기간 동안 액세스 요청의 수를 세고 한도가 초과되는 경우 조치를 취할 수 있습니다. 속도 제한기는 포럼의 게시물 수를 제한하고, 리소스 사용량을 제한하며, 스패머의 영향을 억제하는 데 주로 사용됩니다.

Redis List 데이터 구조를 사용하면 간단한 영구 대기열을 손쉽게 구현할 수 있습니다. Redis List는 자동 작업 및 차단 기능을 제공하므로 신뢰할 수 있는 메시지 브로커 또는 순환 목록이 필요한 다양한 애플리케이션에 적합합니다.

Redis에서는 패턴 매칭과 더불어 PUB/SUB 표준을 지원합니다. 따라서 Redis를 사용하여 고성능 채팅방, 실시간 코멘트 스트림 및 서버 상호 통신을 지원할 수 있습니다. 또한 PUB/SUB를 사용하여 게시된 이벤트를 기반으로 작업을 트리거할 수 있습니다.




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

Redis cluster  (2) 2018.11.20
DB 분류 및 종류  (0) 2018.11.20
CI/CD(Continuous Integration / Continuous Deployment)  (0) 2018.11.20
멀티테넌시(Multitenancy)  (0) 2018.11.20
DC/OS(Data Center Operating System)  (0) 2018.11.20

CI/CD 등장배경: 
소프트웨어가 거대해지고 복잡해지면서 팀 단위로 개발하게 되었고, 그 과정에서 분업과 협업은 필수가 되었는데, 이 분업과 협업의 과정에서 코드의 Merge 과정이 까다롭게 되었고, 테스트하는데 큰 자원이 소비되게 되었다. 이 문제를 해결하기 위해 도입된 방법론이며 개발 - 테스트 -빌드 단계에서 시간을 절약하는 효과를 발휘하게 되었다.




더 빠른 릴리스 주기는 마이크로 서비스 아키텍처를 채택하는 가장 큰 이유 

모놀리식 응용 프로그램에서 출력이 응용 프로그램 실행 파일인 단일 빌드 파이프라인이 존재

즉, 모든 개발 작업은 이 파이프라인으로 피드하게 되는데, 이는 새로운 기능의 릴리스를 지연시킬 수 있게됨.

마이크로 서비스 기본 원칙을 따르면 모든 팀이 줄을 서야 하는 불편함이 없음

즉, 서비스 "A"를 빌드하는 팀은 병합, 테스트 및 배포될 서비스 "B"의 변경 내용을 기다릴 필요 없이 언제든지 업데이트를 릴리스할 수 있음

=> CI/CD 프로세스는 이를 가능하게 만드는 데 중요

즉, 릴리스 파이프라인은 업데이트 배포의 위험이 최소화되도록 자동화되고 매우 안정적이어야 하고

매일 또는 하루에 여러 번 프로덕션에 대해 릴리스하는 경우 재발 또는 서비스 중단은 매우 드물어야 함


CI/CD에 대해 논의할 때 실제로 여러 가지 관련된 프로세스: 지속적인 통합, 지속적인 업데이트 및 지속적인 배포에 대해 논의합니다.

  • 지속적인 통합은 주 분기의 코드가 항상 프로덕션 수준이 되도록 자동화된 빌드 및 테스트 프로세스를 사용하여 코드 변경 내용이 주 분기로 자주 병합됨을 의미

  • 지속적인 업데이트는 CI 프로세스를 전달하는 코드 변경 내용이 프로덕션 환경과 유사한 환경으로 자동으로 게시되는 것을 의미

  • 지속적인 배포는 CI/CD 프로세스를 전달하는 코드 변경 내용이 프로덕션 환경으로 자동으로 배포되는 것을 의미


방식: 

CI/CD는 애플리케이션 통합과 딜리버리 단계를 자동화하고 애플리케이션 구성을 표준화한다. 개발자가 새 코드를 체크인하면, CI/CD 파이프라인이 빌드, 테스트, 데이터 마이그레이션, 애플리케이션 배포, 서비스 호출 및 기타 스크립트화된 절차에 따라 대상 환경에서 코드 변경을 실행한다. 팀은 이러한 자동화를 통해 작업 방식을 조정해서 코드를 체크인하고 더 빈번하게 애플리케이션을 통합, 테스트, 제공한다.

기대효과: 

- 빠른 개발 및 적용
- 안정적 시스템 운영
- 단위 테스트 및 테스트주도 개발 방법
- 테스트자동화 구축
- 매일 코드변경을 커밋하도록 개발자 독려


[출처] CI/CD, 서버패턴|작성자 demonic

[출처] https://docs.microsoft.com/ko-kr/azure/architecture/microservices/ci-cd


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

DB 분류 및 종류  (0) 2018.11.20
REDIS( REmote DIctionary Server)  (0) 2018.11.20
멀티테넌시(Multitenancy)  (0) 2018.11.20
DC/OS(Data Center Operating System)  (0) 2018.11.20
깃허브(GitHub)  (0) 2018.11.19

클라우드는 이미 우리 생활 깊숙이 들어와 있습니다. 파일을 저장하고, 소프트웨어를 사용하고, 동료나 친구와 협업하는 모든 일이 인터넷을 통해 클라우드를 통해 이뤄집니다. 

이처럼 인터넷에서 여러 사람이 동시에 같은 작업을 하려면 소프트웨어나 서비스를 여러 사람이 공유해서 사용할 수 있어야 합니다. 그리고 이것을 가능하게 하는 것이 바로 '멀티테넌시(Multitenancy)' 아키텍처입니다.

Image Credit: Getty Images Bank


멀티테넌시란 그 용어에서 유추할 수 있듯 여러 테넌트(tenant, 사용자)를 가진 아키텍처라는 의미입니다. 많은 사람이 같은 기능을 사용하는 웹메일 서비스가 대표적인 멀티테넌시 아키텍처 소프트웨어입니다. 여기서 중요한 것은 각 사용자가 독립적으로 이용할 수 있어야 한다는 점입니다. 웹메일에 접속했는데 모든 사용자의 메일이 하나의 메일함에서 보인다면 아무도 사용하지 않겠죠. 멀티테넌트 아키텍처 덕분에 사용자별로 데이터와 설정, 화면 구성 등 많은 속성을 개인화할 수 있게 됐고, 이 기술이 성숙하면서 비로소 클라우드도 본격 확산했다고 할 수 있습니다.

멀티테넌시의 역사와 장점
멀티테넌시 아키텍처는 다양한 기술이 진화, 통합한 결과물입니다. 먼저 1970년대의 IBM 메인프레임입니다. 당시 기업은 메인프레임 컴퓨터에서 저장공간과 프로세싱 파워를 필요한 만큼만 빌려 사용했습니다. 전체를 사용하기엔 너무 비쌌으니까요. 로그인 ID에 따라 CPU와 메모리, 저장공간 등을 개별적으로 할당해 사용하는 방식이었는데, 현재 AWS나 마이크로소프트 에저 등의 서비스 방식과 매우 비슷하죠?

이밖에 1990년대 등장한 ASP(Application Server Provider)와 웹 애플리케이션도 큰 영향을 줬습니다. 단, 전자는 아키텍처의 한계로 각 소프트웨어를 별도의 장비에서 운영해야 했고, 후자는 초기 앱의 경우 개인화에 한계가 있었습니다. 지금은 한 장비에 설치한 소프트웨어를 여러 사람이, 그것도 마치 다른 환경처럼 설정해 사용할 수 있으니 ASP와 초기 웹 애플리케이션의 진화된 형태가 현재의 멀티테넌시 아키텍처라고 할 수 있습니다.

멀티테넌시 아키텍처의 가장 큰 장점은 비용 절감입니다. IT 리소스를 유연하게 할당할 수 있어 규모의 경제성과 관리 비용 절감을 동시에 구현했습니다. 소프트웨어 라이선스 비용 측면에서도 같은 규모의 사용자를 기준으로 멀티테넌시 방식이 더 저렴한 경우가 많습니다. 새로운 버전이 나와도 장비 쪽 소프트웨어만 업데이트하면 모든 사용자가 새로운 기능을 사용할 수 있어 관리하기도 편합니다.

멀티테넌시 아키텍처의 또 다른 장점은 데이터 통합이 쉽다는 점입니다. 하나의 시스템과 소프트웨어를 여러 사용자가 공유하는 구조이므로 사용자별 데이터가 사실상 같은 데이터 스키마에 저장됩니다. 이 대규모 데이터를 분석하는 작업도 더 빠르게 편리해졌죠. 분석에 대한 수요가 커지고, 동시에 데이터의 양과 형식이 점점 다양해지면서 멀티테넌시 아키텍처의 장점이 더 두드러지고 있습니다.

장점은 곧 단점
멀티테넌시 아키텍처가 등장한 지 10년이 넘어가면서 상당한 수준까지 고도화됐습니다. 같은 소프트웨어를 사용해도 사용자 혹은 기업고객별로 메뉴 구성과 디자인 등 이른바 '룩앤필(look and feel)'을 완전히 다른 형태로 구성할 수 있습니다. 기업별 고유의 업무 절차 차이까지도 반영해 소프트웨어를 수정할 수 있고 특히 특정 기업단위 사용자 중 일부에게 특정 권한과 제한을 하는 것도 가능해졌습니다.

그럼에도 불구하고 멀티테넌시에는 몇 가지 단점이 있습니다. 예를 들어 개인화를 지원하기 위해서는 더 정교한 멀티테넌시 아키텍처를 적용해야 하는데 이를 개발하는 입장에서는 상당한 비용과 인력이 필요합니다. 업데이트 과정에서 자칫 버그나 장애가 발생하면 모든 사용자가 공통으로 장애를 겪을 수 있고, 또 일부 사용자에게 유용한 업데이트가 다른 사용자에게는 오히려 불편함을 유발할 수도 있습니다.

가장 논란이 되는 것은 보안입니다. 외부적으로는 사용자별로 다른 것처럼 보인다고 해도 결국 멀티테넌시 아키텍처 내부적으로는 단일 데이터베이스에 다양한 사용자의 데이터가 공존하게 됩니다. 따라서 사용자별 데이터가 서로 섞이지 않도록 해야 하고, 해킹이라도 발생하면 해당 장비를 사용하는 모든 사용자의 데이터가 동시에 유출되지 않도록 더 강력한 보안 체계를 갖춰야 합니다. 

출처 : 
http://www.itworld.co.kr/news/101255#csidxb6e6cb3c4bcd694a50ddabeceacbd52 

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

REDIS( REmote DIctionary Server)  (0) 2018.11.20
CI/CD(Continuous Integration / Continuous Deployment)  (0) 2018.11.20
DC/OS(Data Center Operating System)  (0) 2018.11.20
깃허브(GitHub)  (0) 2018.11.19
Git  (0) 2018.11.19

DC/OS(Data Center Operating System)는 하이브리드 및 에지 클라우드 인프라 및 플랫폼 구축이 가능하고, 이를 토대로 MSA(Micro Service Architecture), 인공지능, 빅데이터와 같은 서비스 어플리케이션을 위한 자원관리 환경 제공 및 구글의 쿠버네티스(Kubernetes)를 서비스로 제공하여 다양한 클라우드 환경을 지원하는 최고의 에지 컴퓨팅 분산처리 및 도커 오케스트레이션(Docker Orchestration) 솔루션이다. 


현대 웹개발은 모노리틱(Monolithic) 방식 대신 마이크로서비스(Microservice)를 지향하는 방식을 지향하고 있음

- 단일 웹 어플리케이션이 아닌 여러가지의 서비스가 조합된, 어떻게 보면 더 복잡한 아키텍처일 수 있지만 이러한 문제점을 단순화하기 위함

다수의 장비 및 다수의 솔루션들이 복잡하고 다양한 커뮤니케이션에 의해 서비스되는 웹서비스의 아키텍처는 기존의 시스템 아키텍처로 커버하기는 어려운 점이 많은 상황

 

모노리틱 어플리케이션 특징

 - 하나의 ear 또는 war안에 모든 내용이 들어가 있음.

 - 재사용 가능한 부분은 sharing.jar와 같이 jar영역에 대해서만 재사용 가능

 - 일년에 한두번 대규모 push 를 통한 업데이트 (못하는 경우도 많음)

 - 500k 라인 이상의 코드

 - heavyweight infrastructure

 - 수없이 많은 테스트 케이스

 - 대규모의 팀 규모

 - 많은 버그 목록

 

이러한 모노리틱 어플리케이션을 H/W 장비마다 서비스를 구성하고, 여러 사용자를 대응하기 위하여 다수의 장비를 구성하는 경우는 대응이 가능할지라도

-> 그 이상의 서버를 설정하는 것은 매우 노동집약적 힘든 중노동이 될 수 있다. 

-> 또한 이러한 환경의 가용성(HA)을 높이기 위하여 수많은 안정성 테스트 및 소스 개발.배포 등도 매우 복잡해 질 수 있다.

 

[ 빅데이터 처리를 위한 장비 아키텍처 발전사]



이러한 문제점을 해결하기 위해

-> Amazon이나 Google Cloud와 같은 인프라를 이용하거나,  

-> 관리 용이성을 위하여 Docker와 같은 container 기반의 인프라를 통한 Modern Web Application 을 개발



요구하는 기능

수많은 서버장비에 자신이 원하는 서비스 및 기능을 손쉽게 설치하고, 관리하고

- 특정 서버가 죽으면, 자동으로 해당 서비스를 다른 서버로 이동해주고,


관련 솔루션 

- Apache 오픈소스 진영에서 개발되어 가장 많은 사용자 지원을 받고 있는 Mesos DCOS




STATIC PARTITIONING to ELASTIC SHARING

DC/OS는 Data Center OS 즉 Data Center와 같이 대규모 서버 환경을 하나의 OS처럼 관리 목적으로 개발

- 여러 서버 환경을 하나의 자원처럼 관리하기 위해서는 기존의 정적 파티션 개념에 의한 고정된 자원 분배개념이 아닌 유연한 공유(Elastic sharing)에 의한 각 서버 자원의 자유로 효율적인 사용이 주요 이슈이며 이를 OS처럼 손쉽게 처리하기 위한 목적


대부분 기업 인프라는

기존(일반적인 방법) : 정해진 하드웨어 장비에 정해진 솔루션만 설치하여 이용하는 방법을 사용


정적파티션 큰 단점

  • 장애대응

  • 자원낭비

하나의 하드웨어나 솔루션에 문제가 생기면 전체시스템의 문제로 발생되고 

시스템 자원이 효과적으로 이용하기 어렵기 때문에 자원낭비가 발생합니다.


이러한 문제점을 해결하기 위하여 동적 공유를 통해 자원을 자동적으로 분배하는 기술이 필요


여러 물리적 하드웨어 장비를 커널 레벨에서 하나의 자원처럼 관리하는 클러스터링 관리자가 필요했고 이러한 역할을 하는 것이 Apache Mesos 로 개발 및 발전



[아키텍처별 자원 파티셔닝 구조도] 



Apache Mesos 특징

 

l 어플리케이션 리소스 관리 및 스케줄링

l분산시스템 커널

l10000개 노드까지 확장가능

l기본 Docker 지원

l multi-tenancy

l fault-tolerance, HA

l 확장성

   

DCOS는 커널레벨에서 분산환경을 지원하는 mesos를 좀더 매끄럽고 유연하게 마치 하나의 컴퓨터를 다루듯이 분산 Datacenter의 자원을 손쉽게 관리하고

kafka spark 등 여러 데이터 서비스를 손쉽게 설치 및 관리가 가능하도록 하는

마이크로 서비스 환경에 최적화된 운영체계임


DCOS를 쓰면 기존 장비 효율성을 4배로 향상시켜줄 수 있으며, 자동화된 스케쥴러 및 워크로드 다중 처리는 손쉽게 데이터센터 를 다룰 수 있습니다.

 

DC/OS 특징

다양한 실행환경

사내 서버들에 적용할 수 있으며, Amazon,Azure등 클라우드 환경에도 적용할 수 있음

강력한 리소스 관리

메모리,CPU,네트워크 자원에 대해 각 서버마다 작업부하를 조정할 수 있으며, 

리소스 공유를 통해 자원 활용도를  높임

가상 네트워크 오버레이

가상 IP를 컨테이너 마다 부여하고 동적으로 할당 및 조정이 가능하여 완벽한 가용성을 제공

동적분산 로드밸런싱

트래픽 과부하 상태에 따라 자동 로드 밸런싱 

자가 치유 인프라스트럭처

부하 장애시 자동 감지 자동복구 

무중단 업그래이드

전체적 서비스 중단없이 서비스 배포 및 업그래이드가 가능

UNIVERSE

DCOS의 강력한 기능으로 스마트폰의 google play 앱스토어처럼 

DCOS환경용 어플리케이션을 손쉽게 설치하고 업그레이드 할 수 있음

   

    [DCOS 환경에서 손쉽게 설치할 수 있는 각종 어플리케이션]

 

활용범위

  • 개인화 서비스 기계학습, IoT 신속한 서비스 개발 및 배포

  • 마이크로 서비스 아키텍처 웹 개발

  • 대규모 사용자 서비스 지원

  • Private/Public Cloud 혼용을 위한 Hybrid Cloud 환경 

  • 손쉬운 GPU 기반의 AI 환경 구성

  • 빅데이터 처리


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

CI/CD(Continuous Integration / Continuous Deployment)  (0) 2018.11.20
멀티테넌시(Multitenancy)  (0) 2018.11.20
깃허브(GitHub)  (0) 2018.11.19
Git  (0) 2018.11.19
Subversion  (0) 2018.11.19

깃허브는 세계 최대 오픈소스 커뮤니티로 깃(Git) 전문 호스팅 업체다. 컴퓨터 프로그램 소스를 공유하고 협업해 개발할 수 있는 버전 관리 시스템인 깃에 프로젝트 관리 지원 기능을 확장, 제공하는 웹 호스팅 서비스다. 

 2005년 개발된 분산형 버전관리 시스템(DVCS: Distributed Version Control System)을 말한다. 오픈소스 소프트웨어다. 리눅스 제작자인 리누스 토발즈(Linus Torvalds)가 오픈소스 리눅스(Linux) 커널 개발의 효율성을 높이기 위해서 개발했다.

깃을 이용하면 누가 어떤 코드를 수정했는지 기록하고 추적할 수 있다. 많은 개발자가 함께 SW를 개발할 때 유용하다. 관리자는 여러 사람 코드를 합쳐가며 완성본을 만들 수 있다. 버전관리 시스템은 깃 외에도 SVN, CVS 등 여러 가지가 있다. 하지만 깃은 수천명의 사람들이 이용해도 안정적이며 중앙 저장소에 의존하지 않아 속도도 훨씬 빠르다는 장점이 있다. 



깃허브는 많은 개발자들이 소프트웨어 소스 코드를 공유하고 협력하면서 개발할 수 있도록 지원하는 분산형 버전 관리 시스템이다. 

깃허브는 깃의 기본 기능을 포함해 프로젝트 관리에 필요한 버그 추적, 기능 요청, 작업 관리, 위키 기능 등 소프트웨어 개발에 필요한 관리 기능을 제공한다. 사용자에게 무료로 계정과 저장소를 제공하며, 서버 장애 시 데이터 복원력이 뛰어나다. 
현재 전 세계에서 오픈 소스 프로젝트 관리를 위해 가장 많이 사용되는 웹 호스팅 서비스 중 하나이다. 



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

멀티테넌시(Multitenancy)  (0) 2018.11.20
DC/OS(Data Center Operating System)  (0) 2018.11.20
Git  (0) 2018.11.19
Subversion  (0) 2018.11.19
spotfire  (0) 2018.11.07

Subversion이 중앙 서버에서 모든 소스 코드를 보관 관리하는 시스템이라면, Git는 분산 소스 버전 관리 시스템(Distributed VCS)으로서 서버를 분산시켜 구축할 수 있다.


개발 팀의 구성

• 리눅스 배포판 개발 프로젝트
• 커널, 라이브러리, 킬러 어플리케이션 등을 분야별로 분리하여 개발팀 구성
• 개발팀은 한국, 중국, 일본 회사에서 분야별로 1~2명씩의 개발자가 참여. 서버는 중국에 둠.
• 소스 버전 관리 시스템(VCS)에 올려진 소스를 패키징하여 리눅스 배포판으로 만드는 시스템이 구축 되어 있음.VCS에 잘못된 소스가 올려져 있으면 제품 품질에 곧바로 영향을 미치기 때문에 소스 관리가 중요함.


개발 팀의 구성


Git는 개발자의 시스템에 있는 복사본 디렉터리를 하나의 저장소 서버로 삼을 수 있다. 개발자는 수정 후 개발 팀장의 저장소로 수정된 소스를 푸시(Push)한다. 개발 팀장은 수정된 소스를 리뷰한 후 문제가 없다고 판단되면 바로 중앙 서버에 커밋한다. 여러 개발자가 수정한 소스를 개발 팀장의 복사본 디렉터리에 보내면 Git는 강력해진 통합(merge) 기능으로 각 소스를 통합하여 중앙 서버로 한 방에 커밋하는 기능을 제공한다.

속도 문제 또한 개선된다. SVN을 사용할 때는 중국에 위치한 SVN 서버의 네트워크 속도가 느리고, 개발자의 커밋 요구가 많을 때, 커밋를 걸어 놓고 시간을 허비했으나, Git를 도입하고 나서는 분기된 저장소를 로컬에 두었기 때문에 자연스럽게 중앙 서버의 속도에 영향을 덜 받게 된다.


깃 관련 사항


http://thrillfighter.tistory.com/560

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

DC/OS(Data Center Operating System)  (0) 2018.11.20
깃허브(GitHub)  (0) 2018.11.19
Subversion  (0) 2018.11.19
spotfire  (0) 2018.11.07
통합 멀티 무료 SQL Editor DB 관리 프로그램 DBeaver  (0) 2018.11.05

+ Recent posts