분류없음2016.01.15 07:47

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

어제 프레젠테이션용 CNA 포스팅에 이어서, 오늘은 기존의 형식의 CNA 포스팅입니다.

큰 줄기는 당연히 이번 포스팅 내용을 기준으로 만든 프레젠테이션 자료였기 떄문에 똑같지만

아주 약간 추가되어 있는 내용이라고 보시면 될 것 같습니다. 

혹시 수정이나 추가되었으면 하는 부분은 알려주시면 감사하겠습니다.


 

Cloud Native App 개요

Native App

   - 특정 플랫폼이나 Device에서 사용되도록 개발된 Application.

      최적화 환경에서 구동되기 때문에 성능적으로 Web App 비해 우수.

Web App [ Native App ]

   - 일반적인 표준 Web 기술을 사용하여  Platform이나 Device에 상관 없이 사용되도록 개발된 Application.

      표준 기술로 구현하기 때문에 멀티플랫폼, 플랫폼에 대한 이식성이 우수

 

Cloud Native

  - 클라우드 환경에 최적화 됨, 혹은 태생이 클라우드인, 클라우드 전용

 

Cloud Native App

   - 클라우드 환경에 최적화되어 서비스 되도록 개발된 Application

    - Native App이라는 명칭을 쓰지만, Cloud 환경 어디에서든 구동되기 때문에 의미상으로는 Web-App 같음.

   

 

Cloud Native App 특징

Scalable

    - 유연한 서비스 확장이 가능 (별도의 아키텍처를 변경이 없이)

    - 서비스에 대한 일시적인 확장 수요에 따라서 빠른 서비스 확장 축소가 가능

Agility

    - Application 배포 업데이트 등을 빠르게 구현 가능

    - 빠른 배포 업데이트를 위해 서비스는 독립된 하나의 작은 형태로 동작

Continuity

    - 서비스가 지속적 배포되고, 관리될 있도록 .

    - 서비스에 대한 업데이트 시에도 기존 서비스를 즉각적으로 대체 가능. (서비스 연속성)

    - 서비스 배포를 빠르고, 쉽게 구현하여 지속적인 서비스의 배포(업데이트, 오류 수정 등의 이슈) 가능.

Automation

    - 자동화를 통해서 서비스에 대한 확장 축소가 가능.

    - Applicaion 구동되기 위한 플랫폼을 손쉽게 자동으로 구축이 가능

 

 

 

 

 

Cloud Native App 이해하기 위한 특징

The twelve-factor app

서비스로 제공되는 Web-App, 혹은 SaaS(Software As A Service) 불리는 최근의 소프트웨어를 개발하기에 적합한 방법론

 

12 Factor App 더보기

 

 

Micro Service

독립적이고 매우 작은 개별 서비스들로 전체의 서비스를 구성

서비스는 다른 서비스와의 종속성을 없애며, 하나의 서비스로 구성된 Application 비해서 가벼움.

 

http://zigispace.net/884

 

Standard API

REST-API와 같은 표준화 된 방식의 API 사용하여 서비스 간의 통신

표준화 통신 방식을 사용하기 때문에, 서비스의 구현은 Polyglot Programming 같이 다양한 방향으로

  구현이 가능. (서비스 간에 통신이 특정 방식이 아니라, 표준화 되어 있기 때문)

http://zigispace.net/891

 

Immutable Infrastructure

Develoment ,QA ,Deploy 전반에 걸쳐서 항상 동일한 환경의 인프라를 제공

Provisioning Tool 혹은 특정 Script 등의 형태 등을 통해서 동적으로 동일한 인프라 환경을 빠르게 제공 가능

  , 하나의 인프라를 구축 후에 지속적인 관리 형태 방식 이외의, 동일한 인프라를 새로 만들어서 기존 인프라를 쓰고

  버릴 있는(disposable) 형태 가져갈 있음

 

Container

단일 Host의 Resource를 격리하여 다수의 시스템을 운영하게 하는 OS 레벨의 가상화

Host OS Resource 공유해서 사용하기 때문에 매우 가벼움.

특히 Docker 같은 Container 형태에서는 이미지가 Layered 형태로 관리되기 때문에 이미지 자체가 가벼움

결국 Resource 대한 효율성 가벼운 형태이기 때문에 Application 배포에 유리

 

Self-Service Infrastructure
Infrastructure-as-a-Service

구조화 된 인프라 형태를 빠르게 배포 가능

IAC (Infrastructure as Code) 코드를 실행하는 것으로 인프라 구축이 가능

 

Posted by 네떡지기
분류없음2016.01.14 13:12

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

이번 포스팅은 Cloud Native App에 관한 포스팅입니다.

이 포스팅은 2번에 걸쳐서 나눠서 올려지며, 이번에는 간단한 발표용으로 만든 프레젠테이션 이미지를 포스팅하며

이번 주말 전까지는 일반 포스팅 형식으로 같은 내용을 포스팅 할 예정입니다.

본 자료는 슬라이스쉐어로도 업로드되어 있으니, 다운로드는 아래 링크에서 받으시면 됩니다.
( 슬라이드쉐어 : http://www.slideshare.net/ssuserc08d76/cloud-native-app )


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 네떡지기

티스토리 툴바