최근 서비스 업체들은  'MSA(마이크로서비스)'와 더 자주 '배포(Deployment)'하는 방식으로 변화하고 있는 추세다.

마이크로서비스 아키텍처로 앱을 만들면서 더욱 빠른 속도와 민첩성을 얻을 수 있게 되었고, 이러한 개발 속도의 증가는 는 이전에 비해 더 자주 '배포'가 일어날 수 밖에 없는 기반을 만들어 주었다.

 

이에 대표적인 배포 전략들에 대해 알아보겠다.

 

1. 롤링

 - 일반적으로 많이 이용되고 있는 배포 방식이다. 

 - 서버를 구 버전에서 새 버전으로 하나 씩 점진적으로 배포해 나아가는 방식이다.

 - 배포 중 서비스 중인 인스턴스의 수가 일시적으로 감소하므로 서버 처리 용량에 대한 고려가 필요하다.

2. 카나리

 - 일부 사용자 혹은 지정된 서버들에만 새 배전을 배포하여, 신 버전에 대한 검증 이후

 전체 사용자 또는 전 서버들에 새 버전을 모두 배포하는 방식이다. 

 

3. 블루-그린

  - 서비스 환경과 동일한 환경을 각각 준비해 놓은 상태에서, 

서로 다른 환경에 구 버전과 신 버전을 배포해 놓고, 이후 사용자의 트래픽을 일시에 구 버전에서 신 버전으로 변경시키는 배포 전략이다.

 

 - 빠른 롤백이 가능하고, 내부 트래픽인 경우 운영 서비스에 영향을 주지 않으면서 새버전에 대한 테스트를 진행해 볼 수 있다는 장점이 있는 반면 시스템 자원이 두 배로 필요하다.

4. A/B 테스팅

  카나리 배포 방법과 비슷한데, A/B테스팅의 초점은 신 버전에 대한 이용자의 반응을 측정 하는데에 있다. 

일부 사용자 혹은 서버들에만 신 버전을 배포하여 사용자의 반응을 보고 이후 전체 사용자나 전 서버들에 배포하는 방식이다.

 

'IT기술' 카테고리의 다른 글

마이크로서비스 아키텍처(Microservice Architecture)  (0) 2020.04.23
React 란?  (0) 2020.01.19
REST API  (0) 2020.01.19

- 모놀리식 아키텍처(Monolithic Architecture)

기존의 모놀리식 아키텍처는 모든 것을 최소 필요 사양에 맞게 
규격을 맞추어놓고 하나의 큰 시스템안에 다 때려박아 서비스를 제공하는 아키텍처다.


 서버라든지 인력 등 서비스를 제공&유지하기 위해 최소 조건으로 맞추어져 있다보니,
새로운 서비스를 도입하려고 하면 기존의 운영 인력이 아닌 프로젝트를 위한 새 인력이 필요하게 되고, 그만큼 추가 비용과 시간도 많이 소모된다.

신규 서비스를 위해 투입 된 새 인력은 구조와 로직, 리스크에 대해 파악할 시간이 필요하고, 그러다보면 새로운 서비스의 제공 시기를 놓쳐버릴 수 있다.

 

그리고 여러명의 개발자가 하나의 프로젝트 패키지에서 작업함으로써 발생하는 부작용을 받아들여야 한다.

예를들어, 백 명이 소스 커밋을 했는데 한 명의 실수로 인해 백 명의 소스를 모두 rollback 시켜야 하는 상황 같은 것을 예로 들 수 있다.

 

모놀리식 아키텍처장점은  '개발 > 테스트 > 배포 > 반영'까지가 simple하다는 것이지만, 애플리케이션 확장이 유연하지 못하고, 신규 서비스 추가시 시간과 비용 또 리스크가 많이 발생한다.

 


- 마이크로서비스 아키텍처(Microservice Architecture)

 큰 시스템을 독립적으로 서비스가 가능한 여러개의 작은 시스템으로 나누는 것. 

 각각의 영역이 독립적으로 서비스를 수행하기 때문에 개별적으로 배포가 가능하고, 리스크도 해당 영역에 한정된다.


 결과적으로 애플리케이션의 확장을 용이하게 하고, 개발 속도를 앞당겨 새로운 서비스나 기능에 대한 출시 시간을 앞당길 수 있게 해준다.

 

이커머스 의 경우, 

전시 API Server
상품 API Server
주문 API Server 등 application을 서비스 별로 분할시키는 것..

 


그럼 각각의 서비스에서 발생하는 데이터는 어떻게 처리 ?
- 여러 분산된 API서버들로부터 들어오는 요청을 한 곳으로 모아서 그것을 분석하는 새로운 영역을 만드는 방법이 있음..

 

'IT기술' 카테고리의 다른 글

배포전략 (롤링, 카나리, 블루-그린)  (0) 2021.02.25
React 란?  (0) 2020.01.19
REST API  (0) 2020.01.19

프론트 개발을 2년 넘게 하면서 얼마전 부터 자주 들리는 기술이 있다. 

바로 React라는 기술인데, 무엇인지 알아보았다.

 

React란 ?

페이스북에서 개발한 UI용 라이브러리로,
virtual DOM 개념을 이용하여 상태의 변함에 따라 선택적으로 UI를 렌더링한다.
따라서 최소한의 DOM 처리로 컴포넌트들을 업데이트 할 수 있게 해준다.

 

DOM


DOM은 Document Object Model 의 약자로 객체 모델로 구조화된 문서를 표현하는 방법이다.
XML혹은 HTML로 작성된다.
웹 브라우저는 이 DOM을 활용하여 HTML과 CSS를 적용한다. 
DOM은 트리 형태로 되어있어서, 특정 node를 찾을 수도 있고, 수정할 수도 있고, 제거하거나 원하는 곳에 삽입하는 것도 가능하다.

DOM의 치명정인 단점은 동적 UI에 최적화 되어있지 않다는 것이다. 
HTML자체가 정적인 페이지이기 때문인데, 하지만 javascript와 jQuery를 사용해서 손을 볼 수 있다. 


레이아웃을 다시 구성하는 일을 하는 것 
reflow라고 하고, 색상 변경과 같이 레이아웃과는 관계없는 일을 하는 것 repaint라고 한다. 

규모가 큰 페이지를 만들때 비효율적으로 reflow를 많이 사용하면 성능 저하를 불러올 수 있기 때문에, 적절한 reflow사용이 필요하다.
성능 개선을 위해 reflow횟수를 줄이기 위하여 코드를 최적화 해야한다.
결론은 최소한의 DOM조작으로 성능을 최적화 시켜야 한다.

 

VirtualDOM

VirtualDOM을 사용하면 실제 DOM에 접근해서 조작하는 대신에, 이를 추상화 시킨 자바스크립트 객체를 구성하여 사용한다. 
이는 마치 실제 DOM의 가벼운 사본과도 비슷하다. 


React에서 데이터가 변하여 브라우저상의 실제 DOM을 업데이트 할 때에는 다음과 같은 3가지 절차를 밟는다. 
1. 데이터가 업데이트 되면, 전체 UI를 VirtualDOM에 리렌더링 한다.
2. 이전 내용과 현재의 내용을 비교한다.
3. 바뀐 부분만 실제 DOM에 적용한다.
결국에는 컴포넌트가 업데이트 될 때, 레이아웃 계산이 한번만 이뤄진다.

 

오해

VirtualDOM을 사용한다고 무조건 빠른 것은 아니다.
가장 단순한 예를 들어 정적인 페이지를 만든다면 오히려 VirtualDOM을 사용하는 방식이 비효율 적일 수 있다. 
결국엔 적절한 곳에서 React를 사용해야 진가를 발휘하는 것이다.

 

특징

1. VirtualDOM을 사용한다. 
2. JSX: JSX는 JavaScript의 확장 문법이다.  DOM엘리먼트를 만들 때 JavaScript형식으로 작성해야 하는것을, XML과 비슷한 형태로 작성할 수 있게 해준다. 권장사항이고 필수는 아니나, 이것을 사용하지 않으면 좀 불편하다.
3. Component : React는 모두 Component에 대한 것이다. React 개발을 할 때는 모든 것을 Component로서 생각해야 한다. 


장점

1. VirtualDOM을 사용한 어플리케이션의 성능 향상.
2. 클라이언트측에서도 렌더링 될 수 있고, 서버측에서도 렌더링 될 수 있다. (이를 통해 브라우저측의 초기 렌더링 딜레이를 줄일 수 있음)
3. Component의 가독성이 매우 높고 간단해서 유지보수가 쉽다.
프레임워크가 아닌 라이브러리로서 다른 프레임워크들과 사용이 가능하다. React에선 UI만 신경쓰고, 빠져있는 부분은 본인이 좋아하는 라이브러리를 사용하여 stack을 본인 입맛대로 설정할 수 있다.


제한

어플리케이션 View레이어만 다루므로 이 외의 부분은 다른 기술을 사용해야 한다.
React버전 v15부터 IE8 이하 버전을 지원하지 않는다.

 

 

요약

React는 페이스북에서 개발한 UI용 라이브러리로,

 최소한의 DOM 조작으로 성능 최적화를 위해 virtual DOM 개념을 이용하여 상태의 변화에 따라 다르게 UI를 렌더링하며 컴포넌트를 업데이트시키는 기술이다.

 

 




React프로젝트를 시작하려면 Node.js와 NPM을 설정하고 이것저것 설정을 많이 해야한다고 한다.

여기까지 React에 대해서 알아보았다. 

출처: https://velopert.com/775

 

[React.JS] 강좌 1편 소개 및 맛보기 | VELOPERT.LOG

이 튜토리얼은 2018년에 새로운 강의로 재작성되었습니다 [새 튜토리얼 보기] React 강좌 01: 소개 및 맛보기 이 강좌에서는 React에 대한 간략한 정보와 특징에 대하여 알아보고, 간단한 예제를 통해 React를 사용해보도록 하겠습니다. 본 강좌는 ReactJS를 처음 배우는 JavaScript 개발자들을 대상으로 작성됐으며 앞으로 연재될 강좌를 수월하게 진행하려면, Javascript, HTML5, CSS에 대한 전반적인 지식이 필요합니다. 또

velopert.com

 

'IT기술' 카테고리의 다른 글

배포전략 (롤링, 카나리, 블루-그린)  (0) 2021.02.25
마이크로서비스 아키텍처(Microservice Architecture)  (0) 2020.04.23
REST API  (0) 2020.01.19

- REST

컴퓨터 시스템간 상호 운용성을 제공하는 방법 중 하나로,

HTTP통신에서 고려해야하는 개발 방법론(혹은 아키텍쳐 스타일)이다.

- 이미 REST 아키텍쳐 스타일이 잘 적용된 사례가 있다.

 전 세계의 모든 웹사이트 들이다.

 웹 사이트가 개편 되었다고 해서, 웹 브라우저를 업데이트 해야하는 경우는 드물다. 반대로 웹 브라우저가 업데이트 되었다고 해서, 웹 사이트에 접속이 안되는 경우도 드물다.

이는 전 세계의 대부분의 웹 사이트들이 REST 아키텍쳐 스타일이 잘 적용되고 있다는 반증이다.

 

- 그렇다면 왜 상호 운용성을 지켜야 하나 ?

이전 버전(하위 호환)에 대한 호환성은 유지해야 하기 때문이고, 그렇게 하지 않으면 웹이 깨진다.

- REST의 목표는 독립적인 발전이다.

 


- REST API

0. 구성

자원 : URL

행위 : HTTP Method

메서드의 종류 : GET(조회), POST(생성), PUT(수정), DELETE(삭제)

 

API 는 원격으로 다른 시스템의 메소드를 호출하는 것이고, REST API는 REST 아키텍쳐 스타일을 따르는 API를 말한다. 아키텍쳐 스타일이란 제약조건의 집합이라고 할 수 있다.

그럼 REST의 제약조건의 집합에 대해 알아보자.

 

1. client-server

client와 server는 분리되어야 한다.

 

2. stateless(무상태성)

각 요청간clinet와 server는 지속적인 연결이 되지 않으며, 상태정보를 따로 저장하지 않는다.

 

3. cacheable

캐시 처리 가능(http 통신을 기본으로 하므로 캐시 기능 또한 가지고 있음.)

 

4. uniform interface(Self-descriptive 와 HATEOAS 를 만족해야 한다는것인데,,, 도통 무슨말인지 모르겠으니 뒤에서 다시 설명한다.)

 

5. layered system (계층형 구조)

다중 계층으로 구성될 수 있고, 보안, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 들 수 있다.

 

오늘날 대부분의 REST API는 사실 REST를 잘 따르지 않고 있다.

1,2,3,5번의 경우 대부분의 HTTP API에서도 잘 지켜지고 있는 부분이지만,

REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.

- Self-descriptive

메시지만 보고 해당 API에 대해 해석이 가능해야 한다.

서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive하므로

언제나 해석이 가능해야 한다.

- HATEOAS

애플리케이션 상태의 전이(하이퍼링크를 통한 전이).

HTML같은 경우 a태그의 하이퍼링크를 통해서 전이가 가능하기 때문에 HATEOAS를 만족하나,

JSON은 만족하지 못한다.

오늘날 API가 Self-descriptive와 HATEOAS가 잘 만족되지 못하는 이유는 보통 json과 xml데이터로 응답을 하는데, 여기서오는 문제 때문이다.

 

html은 Self-descriptive와 HATEOAS가 잘 지켜진다.

html의 각 종 태그들은 그 description이 모두 정의되어 있어서 해석이 가능하며, 특정 태그의 속성을 통해 상태의 전이가 가능하지만, json과 xml은 그러지 못한다.

json의 key, value값에 대해 해당 API 전용 문서를 만들지 않는한 json데이터만 보고는 message해석이 불가능하다. xml 또한 사용자 정의 태그가 있어 특정 전용 description 없이는 자체 해석이 불가능하다.

JSON에서 Self-descriptive를 해결하는 방법.

> custom media type이나 profile link relation등으로 만족시킬 수 있다.

JSON에서 HATEOAS를 해결하는 방법.

> HTTP헤더나 본문에 링크를 담아 만족시킬 수 있다.

결론

REST를 따를 것인지는 API 를 설계하는 이들이 스스로 판단하고 결정해야 하는 것이지만,

REST를 따르겠다고 결정했다면 Self-descriptive와 HATEOAS를 만족시켜야 한다.

 

공부 출처 : http://tv.naver.com/v/2292653

 

Day1, 2-2. 그런 REST API로 괜찮은가

NAVER Engineering

tv.naver.com

 

'IT기술' 카테고리의 다른 글

배포전략 (롤링, 카나리, 블루-그린)  (0) 2021.02.25
마이크로서비스 아키텍처(Microservice Architecture)  (0) 2020.04.23
React 란?  (0) 2020.01.19

+ Recent posts