'아키텍처'에 해당되는 글 2건

  1. 2016.08.12 Puppet Part 3
  2. 2015.10.07 마이크로 서비스 아키텍처(MSA : Micro Service Architectures)
DevOps/Automation2016.08.12 14:42

Today key : Puppet, 퍼펫, manifest, autumation, 자동화, Architecture, 아키텍처, Catalog, 카탈로그, facts 

 

지난 번에 이은, Puppet의 3번째 포스팅입니다.

이번 포스팅은 Puppet을 조금 더 이해하기 위한 간단한 아키텍처와 동작 방식에 대한 내용입니다.

우선 짧지만, 정리하는 데로 추가로 올리거나 업데이트 할 예정입니다.

혹시 잘못되거나 수정해야 할 부분이 있으면 덧글 부탁드립니다! ^^

 


 

 

Puppet Part 3

 

Puppet Architecture 일반

   • Puppet 일반적은 master/agent(혹은 Server/Client) 구조의 Puppet Master Puppet Agent 사용.

   • Puppet Apply Application 통한 self-contained(Standalone) 구조로도 실행 가능.

 

Puppet 통한 Node 관리를 위한 2개의 Main Stage

   • Catalog 컴파일

   • Catalog 적용

 

Master/Agent 구조에서의 기본 동작

   • Agent에서는 Puppet Agent App Background 서비스 처럼 동작하고 하나 이상의 Puppet master App

       동작하는 Puppet Server 동작.

   •Agent 주기적으로(Default 30) Master에게 자신의 facts 전송하고, Catalog 요청

   •Master Catalog 생성을 위해서 컴파일 후에 Node에게 Catalog 전송

   •Agent Catalog 수신 받아서, catalog 정의된 내용과 현재의 Resource 비교하여 Catalog 내용을 적용.

   • Catalog 적용 , Agent Report Master 전송

 

 

 

 

Standalone 구조에서의 기본 동작

   •Puppet Apply 통해서 노드를 관리

   일반적으로 예약된 작업(Scheduled task)혹은 Cron Job으로 수행.

   •Master/Agent 구조와 마찬가지로 Puppet 노드 관리를 수행하기 위해서 컴파일 과정을 거치게 .

   컴파일 Catalog 통해서 Resouce들을 Catalog 내용대로 적용.

   •Catalog 적용 , Report Disk 저장

 

 


Catalog

관리하는 자원에 대해서 자원에 대해 원하는 상태(Desired state) 기술

특정 순서로 관리를 해야 하는 경우에, 리소스에 설정에 대한 종속성 정보를 제공 가능.

 노드를 설정할 (configuring), Puppet agent catalog라고 부르는 Master 서버로부터 전송 받은 document 사용.

  

Catalog Compile

• Puppet 3가지의 설정 정보의 main-sources 사용하여 catalog 컴파일 .

    Agent-provided data

        - agent catalog 받기 위해서 master에게 자신의 정보를 전송할 아래의 4가지 정보를 전송.

           1. name.  (일반적으로 certname 같다.)                     2. certficate

           3. facts                                                                                      4. environment

   External data

   Puppet manifests

        - main manifests Modules ( Puppet Forge 부터 다운, 사이트에서 직접 작성)

 

FACTS

catalog 요청 전에 Facter 사용하여 시스템의 정보를 수집.

puppet 이렇게 수집된 정보를 facts 정보라 하고, 이것은 manifest에서 사용 pre-set variables 사용.

 .

 

Posted by 네떡지기
분류없음2015.10.07 09:12

Microservice, 마이크로서비스, Cloud, MSA, Architectures, 아키텍처, Monolithic, 클라우드 :Today keys.

 

이번 포스팅은 마이크로 서비스에 대한 포스팅입니다.

'안' 개발자로서, 이런저런 자료를 찾아보며 정리해 보았습니다.

새로운 내용들을 보다보면, 역시나 IT 분야내에서는 이런 저런 다양하게 알아야 할 것들이 많다는 것을 느끼게 됩니다.

아마도 이번달까지는 관련 내용을 정리해서, 좀 더 포스팅을 하게되지 않을까 싶습니다. (혹은... 정리만.. 포스팅은 다음달?..)

 


 

 

마이크로 서비스 아키텍처(MSA : Micro Service Architectures)

 

 

 

 

 

마이크로 서비스 아키텍처란?

   독립적이고 단순한 개별 서비스들로 전체의 서비스를 구성

   단일 Application 나누어서 작은 서비스들의 조합으로 구성

   기존의 Monolithic Architecture 대비되는 개념

   2012년 ThoughtWorks James Lewis Java the Unix way라는 제목의 발표에서 언급.

     2014 3 James Lewis Martin Flowler Microservices 라는 타이틀로 패러다임을 정립한 기사 발표

 

마이크로 서비스 아키텍처의 배경

   Cloud 서비스 환경에서의 기존의 Monolithic Architectures 적용의 어려움

        - Monolithic Architectures에서는 코드의 크기가 크기 때문에 배포에 대한 부담

        - 서비스 변화의 속도에 따른 배포 주기가 짧아지는 것에 대한 부담

   갈수록 복잡해지는 비즈니스에 따른 거대한 서비스 생성

   OpenSource Internet 등으로 인해 짧아지는 기술 수명 주기

   서비스 연계성으로 인한 문제

       - 일부 서비스 부분에 변경 시에도 연계 시스템에 대한 Re-Build 필요

 

 

Micro Service Architectures vs Monolithic Architecture

 

 

 

 

마이크로 서비스 아키텍처 구성 방식

   마이크로 서비스 간에는 HTTP 기반 API 등을 통해서 통신.

 

 

 

   각 서비스는 개별 서비스로 동작하기 때문에 서로 다른 독립적인 언어로 개발 가능. (Polyglot Programming)

 

   서비스가 복잡할 경우에는 서비스 간의 연결을 직접 구성하게 경우에 복잡도가 증가하므로, 중간에 API 관리하는 서비스 오케스트레이션 계층으로서의 API Gateway를 구성 가능.

 

 

 

마이크로 서비스 아키텍처의 특징

   Decoupled : 서비스 간의 종속성 배제

   Well Defined Interface : 서비스 간의 통신을 위해서 정의된 API 필요

   Independent : 서비스 별로 독립적으로 개발 운영할 있음

   Conway's Law 적용 :  "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." / 결국 서비스의 구성 디자인은 서비스를 구현하는 조직의 모습에 기반한다.

 

 

 

 

마이크로 서비스 아키텍처의 장점/단점

     장점

         - 서비스에 대한 확장성이 좋고, 개발 배포 사이클 관리 용이

         - 서비스 파트에서 제공하는 서비스에 최적하는 방법/언어 사용 가능(Polyglot Programming)

         - 작은 서비스로 구성되기 때문에 서비스에 대한 민첩성 확보.

         - 컴포넌트와의 종속성이 배제되어 서비스 변경이 쉬움

        

    단점

         - 서비스 간의 연계성 다양한 기술 사용으로 인한 운영 테스트 복잡도 증가

         - 서비스 간의 외부 호출로 인한 성능 비용 증가(Latency)

         - 설계 시의 고려해야 사항이 많아짐

         - 서비스의 세분화됨에 따라, 서비스 간의 코디네이션(Chief Architect) 필요.

         - 배포와 운영에 자동화를 사용하지 않으면, 오히려 기존 방식보다 어려움(개별 서비스이기 때문에 수량이 많아짐)

 

 

마이크로서비스 설계시 고려사항들

    개별 서비스에 대한 기능 적합성 성능에 대한 효율성

    서비스 간의 호환성

    서비스에 대한 신뢰성 서비스 간의 통신 시의 보안

    개별 서비스에 대한 유지보수성 이식성

 

Posted by 네떡지기

티스토리 툴바