Browser Render, Serverless

2021-06-01#

List#

Browser link
- preload
- preconect
- prefetch

preload#

현재 페이지에서 사용될 것이 확실한 리소스들을 preload 선언하는것이 좋다.

preload는 브라우저에게 현재 페이지에서 필요한 리소스를 빠르게 가져오게 한다.

<link rel="preload" as="script" href="super-important.js" />
<link rel="preload" as="style" href="critical.css" />

preload는 위의 코드와 같이 <link rel="preload" as="...">와 같이 사용 한다.

주의 사항#

preload를 사용할 때 주의해야 할 몇 가지 사항이 존재한다.

as 속성 사용#

as 속성을 사용하여 리소스의 유형을 브라우저에 알려줘야 합니다. 올바른 유형이 설정되어 있지 않다면 브라우저는 해당 리소스를 사용하지 않는다.

중복 리소스 참조#

preload는 브라우저가 반드시 리소스를 가져오게 한다.

따라서, 리소스를 중복 참조하면 중복된 개수만큼 리소스를 가져오기 때문에 리소스를 중복해서 참조하지 않도록 설정한다.

반드시 사용되는 리소스에만 사용#

preload는 현재 페이지에서 반드시 사용되는 리소스에만 사용해야 한다.

res_prio_timeout

<link rel="preload" as="...">를 이용하여 리소스를 가져왔지만 현재 페이지에서 3초 내로 사용되지 않는 리소스는 위의 그림과 같은 경로가 출력 된다.

필요하지 않는 것을 가져오지 않도록 주의 필요

preload를 사용하기 좋은 사례#

폰트#

사용자가 사이트의 폰트를 기다리는 시간을 감소시키고, 시스템 폰트와 선언된 포트의 충돌 해결 가능

<link
  rel="preload"
  as="font"
  crossorigin="crossorigin"
  type="font/woff2"
  href="myfont.woff2"
/>

위의 코드와 같이 폰트를 preload해서 브라우저에게 폰트가 즉시 필요하다는 것을 알려줄 수 있다.

Critical Rendering Path의 CSS와 JavaScript#

페이지 성능을 측정할 때 중요한 개념 중, Critical Rendering Path가 있다.

<link rel="preload" as="script" href="super-important.js" />`
<link rel="preload" as="style" href="critical.css" />

위의 코드와 같이 초기 렌더링에 반드시 필요한 리소스를 preload해서 렌더링 속도를 높일 수 있다.

preload 브라우저 지원 현황#

preload-support-browser

preconnect#

현재 페이지에서 외부 도메인의 리소스를 참고하는 것을 브라우저에게 알려 미리 외부 도메인과 연결을 설정할 수 있게 한다.

preconnect를 사용하면 브라우저가 사이트에 필요한 연결을 미리 예상할 수 있게 되며, 브라우저는 필요한 소켓을 미리 설정할 수 있기 때문에 DNS, TCP, TLS 왕복에 필요한 시간을 절약할 수 있게 된다.

<link rel="preconnect" href="https://example.com" />

위의 코드와 같이 preconnect를 사용가능.

주의사항#

preconnect는 외부 도메인과 연결을 구축하기 때문에 많은 CPU 시간을 차지할 수 있다.

보안 연결의 경우 더 많은 시간을 차지할 수 있으며, 10초 이내로 브라우저가 닫힌다면, 이전의 모든 연결 작업은 낭비되는 것이기 때문에 브라우저가 빨리 닫힐 수 있는 페이지에서는 preconnect를 사용하지 않는 것을 추천.

preconnect를 사용하기 좋은 사례#

정확한 경로를 알 수 없을 때#

주어진 CDN으로 부터 리소스를 가져와야 한다는 것은 알지만 정확한 경로를 모르는 상황이 발생할 수 있습니다. 예를 들면 브라우저 별로 가져와야 하는 JQuery 등의 리소스 버전이 다를 때 가져와야 할 CDN 주소는 알지만 정확한 경로는 알지 못하는 상황을 이야기할 수 있다.

이러한 경우 브라우저는 리소스를 가져오지는 않지만 서버에 미리 연결하여 연결에 필요한 시간을 절약할 수 있다.

브라우저는 파일이 필요하기 전에는 리소스를 가져오지 않지만 적어도 연결은 먼저 처리해서 리소스를 요청하고 가져오는 여러 번의 왕복을 기다리지 않아도 된다.

미디어 스트리밍#

스크립트가 로드되고 스트리밍 데이터를 처리할 준비가 될 때까지 스트리밍을 기다리는것이 효율적일 수 있다.

preconnect는 미리 연결을 하기 때문에 리소스를 가져올 준비가 되면 연결을 설정하는 것이 아니라 미리 연결된 설정에 따라 리소스를 가져와 연결을 설정하는 대기 시간을 줄 일 수 있다.

preconnect 브라우저 지원 현황#

preconnect-support-browser

prefetch#

미래에 사용될 것이라고 예상되는 리소스들을 prefetch 하는것이 좋다. (브라우저는 미래에 사용될 리소스들을 가져와 캐시에 저장한다.)

prefetch는 사용자가 다음에 할 행동을 미리 준비하는데 적합한 기능이다.

예를 들어, 결과 목록에서 첫 번째 제품 상세 페이지를 가져오거나 콘텐츠의 다음 페이지를 가져오는 것을 이야기할 수 있다.

<link rel="prefetch" href="page-2.html" />

위의 코드와 같이 prefetch를 사용할 수 있다.

주의사항#

prefetch는 재귀적으로 동작하지 않는다

<link rel="prefetch" href="page-2.html" />

위의 코드와 같이 prefetch를 사용한다면, page-2.html이라는 HTML 리소스를 가져올 수 있지만 page-2.html에서 사용되는 CSS 등의 리소스들은 가져오지 않는다.

Override 목적으로 사용하지 않는다.

prefetch는 Override, 즉 재정의 할 목적으로 사용하는건 적합하지 않다.

<html>
  <head>
    <link rel="prefetch" href="optional.css" />
    <link rel="stylesheet" href="optional.css" />
  </head>
  <body>
    Hello!
  </body>
</html>

위의 코드와 같이 prefetch를 사용할 경우

<link rel="prefetch" href="optional.css">
<link rel="stylesheet" href="optional.css">

해당 링크가 다음에 오는 stylesheet css 우선순위를 낮출 것이라고 생각할 수 있지만 그렇지 않다.

preload 경고#

res_prio_prefetch

실제로는 한 번은 가장 높은 우선순위로, 나머지 한 번은 가장 낮은 우선순위로 스타일을 2번 가져오게 된다.

렌더 차단하는 CSS를 기다려야 할 뿐만 아니라, 파일을 두 번 다운로드해야 하는 낭비가 발생하기 때문에 동일한 리소스를 여러 번 가져와야 하는 경우는 피하는 것이 좋다.

prefetch브라우저 지원 현황#

prefetch-support-browser

2021-06-07#

List#

Repaint
Reflow

Repaint(Redraw)#

Repaint는 화면에 변화가 있을 때 화면을 그리는 과정

화면의 구조가 변경되었을 때에는 Reflow 과정을 거쳐 화면 구조를 다시 계산한 후 Repaint 과정을 통해 화면을 다시 그린다.

화면의 구조가 변경되었을 때에는 Reflow와 Repaint 모두 발생

화면의 구조가 변경되지 않는 화면 변화의 경우 Repaint만 발생하는데, 예를 들면 opacity, background-color, visibility, outline 등의 스타일 변경 시에는 Repaint만 동작한다.

<html>
  <head>
    <style>
      .repaint {
        width: 100px;
        height: 100px;
        background-color: orange;
        transition-duration: 2s;
      }
      .repaint:hover {
        background-color: red;
      }
    </style>
  </head>
  <body>
    <div class="repaint"></div>
  </body>
</html>

repaint

Reflow(Layout)#

Reflow는 화면 구조(Layout)이 변경되었을 때, 뷰포트 내에서 렌더 트리의 노드의 정확한 위치와 크기를 계산하는 과정을 Reflow(혹은 Layout)이라고 한다.

<html>
  <head>
    <style>
      .reflow {
        width: 100px;
        height: 100px;
        background-color: orange;
        transition-duration: 2s;
      }
      .reflow:hover {
        width: 200px;
      }
    </style>
  </head>
  <body>
    <div class="reflow"></div>
  </body>
</html>

reflow

Reflow가 발생하는 경우#

DOM 노드의 추가, 제거
DOM 노드의 위치 변경
DOM 노드의 크기 변경(margin, padding, border, width, height 등..)
CSS3 애니메이션과 트랜지션
폰트 변경, 텍스트 내용 변경
이미지 크기 변경
offset, scrollTop, scrollLeft과 같은 계산된 스타일 정보 요청
페이지 초기 렌더링
윈도우 리사이징

성능 저하 최소화하기#

스타일을 변경할 경우 가장 하위 노드의 클래스를 변경한다.

DOM 노드의 크기 또는 위치가 변경되면 하위 노드와 상위 노드까지 영향을 미칠 수 있음

가장 하위 노드의 스타일을 변경할 경우, 전체 노드가 아닌 일부 노드로 reflow를 영향을 최소화할 수 있다.

하지만 보통 변경해야 할 노드들이 정해져 있기 때문에 적용 범위가 크지 않을 수 있다.

인라인 스타일을 사용하지 않는다.

스타일 속성을 통해 스타일을 설정하면, 리플로우가 발생한다.
엘리먼트의 클래스가 변경될 때 엘리먼트는 하나의 리플로우만 발생시킨다.
인라인 스타일은 HTML 이 다운로드될 때, 레이아웃에 영향을 미치면서 추가 리플로우를 발생시킨다.

애니메이션이 들어간 엘리먼트는 position: fixed 또는 position: absolute 로 지정한다.

absolute 또는 fixed 위치인 엘리먼트는 다른 엘리먼트의 레이아웃에 영향을 미치지 않는다. (리플로우가 아닌 리페인트가 발생하는데, 이것은 훨씬 적은 비용이 든다.)

퀄리티, 퍼포먼스의 타협점을 찾는다.

애니메이션 효과는 많은 Reflow가 발생한다.

예를 들어 10px을 이동해야 하는 애니메이션 효과가 있다고 하면, 한 번에 1px씩 움직이는 애니메이션일 경우 10번의 Reflow가 발생하지만 한 번에 2px씩 움직이는 애니메이션일 경우에는 5번의 Reflow가 발생.

따라서 퀄리티와 퍼포먼스 간의 타협점을 찾아 최적의 방법을 찾는다. (브라우저의 측정도구 활용을 반드시 해보자)

레이아웃을 위한 <table> 은 피한다.

<table> 은 점진적으로 렌더링되지 않고, 모두 불려지고 계산된 다음에서야 렌더링이 된다. 또한, 작은 변경만으로도 테이블의 다른 모든 노드에 대한 리플로우가 발생
레이아웃 용도가 아닌 데이터 표시 용도의 <table> 을 사용하더라고, table-layout: fixed 속성을 주는 것이 좋다. table-layout: fixed 를 사용하면, 열 너비가 머리글 행 내용을 기반으로 계산되기 때문

CSS 에서 Java Script 표현식을 사용하지 않는다.

IE 와 FF 는 모두 CSS 에서 Java Script 를 실행할 수 있다. IE 에서는 표현 기법과 HTC 동작 방법이 있고, FF 에서는 XBL 을 사용하는 방법이 있다. (이 방법은 CSS 에서 Java Script 를 직접 실행하지는 않지만, 그 효과는 동일하다.)
문서가 리플로우될 때마다 Java Script 표현식이 다시 계산된다.

.expression {
  width: expression(document.documentElement.clientWidth > 0 ? '1000px' : 'auto');
}

CSS 하위 셀렉터를 최소화한다.

사용하는 규칙이 적을수록 리플로우가 빠르다.
gulp-uncss, grunt-uncss 와 같은 도구로 스타일 정의 및 파일 크기를 줄인다.

<div class="reflow_box">
  <ul class="reflow_list">
    <li>
      <button type="button" class="btn">버튼</button>
    </li>

    <li></li>
    <li>
      <button type="button" class="btn">버튼</button>
    </li>

    <li></li>
  </ul>
</div>

/* 잘못된 예 */
.reflow_box .reflow_list li .btn {
  display: block;
}
/* 올바른 예 */
.reflow_list .btn {
  display: block;
}

숨겨진 엘리먼트를 변경한다.

display: none; 으로 숨겨진 엘리먼트는 변경될 때, 리페인트나 리플로우를 일으키지 않는다. 그렇기 때문에 엘리먼트를 표시하기 전에 엘리먼트를 변경한다.

Java Script 를 통해 스타일을 변경할 경우, .cssText 를 사용하거나, 클래스를 변경한다.

var el = document.getElementById('reflow-test');

el.style.padding = '8px';
el.style.width = '320px';
el.style.height = '240px';
// 3 번의 리플로우 발생

/////////
var el = document.getElementById('reflow-test');

el.style.cssText = 'padding: 8px; width: 320px; height: 240px;';
/* or */
el.className = 'changed';
// 1 번의 리플로우 발생

/**
 * Style of `changed` class
 * .changed {
 *   padding: 8px;
 *   width: 320px;
 *   height: 240px;
 * }
 */

Java Script 를 통해 리스트를 추가하는 경우, DOM Fragment 를 통해 추가한다.

3 개의 리스트를 추가하는 경우, 한 번에 하나씩 추가하면 최대 7 개의 리플로우가 발생한다.
- <ul> 이 추가될 때
- <li> 에 대해 3번
- 텍스트 노드에 대해 3번

const frag = document.createDocumentFragment();
const ul = frag.appendChild(document.createElement('ul'));

for (let i = 1; i <= 3; i++) {
  li = ul.appendChild(document.createElement('li'));
  li.textContent = `item ${i}`;
}

document.body.appendChild(frag);

캐쉬를 활용한 Reflow 최소화.

브라우저는 레이아웃 변경을 큐에 저장했다가 한 번에 실행함으로써 리플로우를 최소화하는데, offset, scrollTop 과 같은 계산된 스타일 정보를 요청할 때마다 정확한 정보를 제공하기 위해 큐를 비우고, 모든 변경을 다시 적용한다.
이를 최소화하기 위해 수치에 대한 스타일 정보를 변수에 저장하여 정보 요청 횟수를 줄임으로써 리플로우를 최소화한다.

for (let i = 0; i < len; i++) {
  el.style.top = `${el.offsetTop + 10}px`;
  el.style.left = `${el.offsetLeft + 10}px`;
}
// Bad practice

let top = el.offsetTop,
  left = el.offsetLeft,
  elStyle = el.style;

for (let i = 0; i < len; i++) {
  top += 10;
  left += 10;
  elStyle.top = `${top}px`;
  elStyle.left = `${left}px`;
}
// Good practice

브라우저 도구로 리페인트 이슈 분석하기

모든 주류 브라우저는 리플로우가 성능에 미치는 영향을 보여주는 [타임라인] 도구를 제공한다.
- IE 의 경우에는 dynaTrace AJAX Edition, Webkit Browser 의 경우에는 Google Chrome SpeedTracer 가 있다.

요약#

Repaint(Redraw)는 화면에 변화가 있을 때 화면을 그리는 과정입니다.
Reflow(Layout)는 뷰포트 내에서 렌더 트리의 노드의 정확한 위치와 크기를 계산하는 과정입니다.
Repaint가 발생하는 경우는 화면이 변경되는 모든 경우입니다.
Reflow가 발생하는 경우는 화면의 구조가 바뀌었을 경우입니다.
Reflow를 최적화하는 방법은 11가지 정도로 이야기할 수 있습니다.
스타일을 변경할 경우 가장 하위 노드의 클래스를 변경한다.
인라인 스타일을 사용하지 않는다.
애니메이션이 있는 노드는 position을 fixed 또는 absolute로 지정한다.
퀄리티, 퍼포먼스의 타협점을 찾는다.
<table> 레이아웃을 피한다.
IE의 CSS 표현식을 사용하지 않는다.
CSS 하위 선택자를 최소화한다.
숨겨진 노드의 스타일을 변경한다.
클래스를 혹은 cssText 사용하여 한 번에 스타일을 변경한다.
DOM 사용을 최소화한다.
캐시를 활용한다.

참고#

2021-06-15#

List#

Serverless

Serverless란?#

서버리스(serverless)란 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델이다.

서버리스 특징#

서버리스 모델에도 서버는 존재
애플리케이션 개발에서와 달리 추상화됨
클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리
개발자는 배포를 위해 코드를 컨테이너에 패키징만 처리

서버리스 애플리케이션은 배포되고 나면 필요에 따라 자동으로 스케일 업되거나 스케일 다운된다.

서버리스 컴퓨팅#

서버리스 컴퓨팅은 IT 인프라를 데이터 센터 혹은 클라우드에 별도 준비 없이, 필요한 기능을 함수(function) 형태로 구현하고, 자동 스케일링 방식으로 시시각각 변하는 자원 수요를 지원하며 전통적인 백엔드 대신 사용한다.

FaaS(Function as a Service)라고도 하며, 백엔드 시스템을 보이지 않는 서비스로 추상화하였기 때문에 BaaS(Backend as a Service)라고도 한다.

서버리스 컴퓨팅은 클라우드 사업자가 운영하는 가상화된 컨테이너에서 실행된다.

아래 그림은 서버리스 컴퓨팅의 작동 원리를 도식화한 것이다. 미리 필요한 기능을 서버리스에 원하는 프로그래밍 언어로 함수의 형태로 구현을 해두고, 이벤트 드리븐(event driven) 방식으로 필요에 따라 이 함수를 호출하여 사용한다.

serverless

초기의 서버리스 함수는 스크립트 형태의 언어인 Node.js만을 지원했지만 현재는 파이썬, 자바스크립트, C#, Java 등의 대표적인 객체지향 프로그래밍 언어와, 자체 개발한 라이브러리 패키지를 일반적으로 지원한다.

서버리스 함수는 또 다른 API를 호출하거나, 필요한 데이터를 데이터베이스에 저장 후 분석 작업등을 할 수 있고, 동시 트랜잭션의 순차 처리를 위한 메시지큐나, 다른 클라우드 서비스와도 연계가 된다.

BaaS#

BaaS는 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해준다.

예를 들어, 클라우드 제공업체는 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있다.

BaaS를 활용하는 경우 서버리스 기능은 일반적으로 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 통해 호출된다.

Google Firebase가 대표적인 예시이며, 클라우드 공급업체가 제공하는 서비스를 사용하게 되므로 FaaS보다는 개발이 간단해진다는 장점이 있다.

FaaS#

FaaS의 경우 개발자는 사용자가 정의한 서버 측 로직을 작성할 수 있지만, 이러한 로직은 클라우드 서비스 제공업체가 전체를 관리하는 컨테이너에서 구동된다.

주요 퍼블릭 클라우드 공급업체에서는 하나 이상의 FaaS 오퍼링을 제공한다.

대표적으로 아래의 서비스를 많이 사용한다.

Amazon Web Services의 AWS Lambda
Microsoft Azure의 Azure Functions
Google Cloud의 여러 오퍼링
IBM Cloud의 IBM Cloud Functions

서버리스에 적합한 경우#

새로운 아이디어를 빠르게 테스트해야 하는 조직#

스타트업의 경우를 보면, 시도와 실패를 반복하며 구현한 기능을 서비스에 빠르게 녹여 신속히 출시해야 시장에서 경쟁력을 갖출 수 있다.

사실 이는 스타트업에만 해당하는 일은 아니다. 부가 기능은 BaaS를 사용하고 개발자는 서비스의 핵심 기능 구현에만 집중하도록 하면 생산성을 높이고 개발 주기를 앞당길 수 있다.

또한 FaaS는 최소 기능 단위로 함수를 작성하기 때문에 코드 유지보수나 신규 기능 추가를 효율적으로 수행할 수 있다.

단기간 이벤트성 트래픽을 감당해야 하는 경우#

필요할 때 동적으로 자원을 할당받아 사용하기 때문에 급격한 트래픽 변화에 유연하게 대응할 수 있다.

비지니스 측면 장점

관리보다 개발에 집중하여 서비스 출시를 앞당김
함수 단위 로직으로 코드 유지보수나 기능 추가에 효율적
이벤트 기반 실행으로 경제적이며 유연한 대응 가능
반복적으로 타 시스템과 연계하여 비즈니스 인사이트를 도출할 때 유용

단점

장기간 지속하 작업에는 기능적/비용적으로 부적합
기존 컴퓨팅 자원 대비 고가의 서비스 비용 (동일한 가동 시간 가정)
‘콜드 스타트’를 깨기 위한 시간 필요
서비스 처리 결과에 대한 데이터 저장 필요

참고#

2021-06-22#

List#

Serverless FramekWork

Serverless Framework 란?#

Serverless라고 하면 물리(또는 가상화된) 서버를 직접 운영하지 않고 Function 기반의 서버 제작 및 운용을 얘기하나, 여기서 Serverless Framework란 그것을 쉽게 사용 할 수 있도록 도와주는 오픈 소스 프레임워크이다.

서버리스 프레임워크를 사용하면 쉽게 서버리스 아키텍쳐를 AWS의 Lambda 및 다른 클라우드 서비스에서 빌드할 수 있는 어플리케이션을 만들 수 있다.

WARNING#

보통 "Serverless Framework 알아?" 라고 하면 대부분 전자인 Serverless 자체를 떠 올리며 안다고 하는 경우가 많은데, Serverless 의 개념이나 아키텍처가 아닌 Serverless Framework 오픈 소스 자체를 아는 것이 아닌 경우가 많다.

serverless

프레임워크의 이름을 Serverless 그 자체로 쓴 것인데 그것이 신의 한수인지 몰라도 대부분 안다고 하고 실제로는 모르는 경우가 많다.
(구글에서는 다른 비슷한 Serverless 를 지원하는 프레임워크중에 항시 첫번째로 검색 된다.)

스타트업과 포춘지 500여개의 회사가 효율적인 어플리케이션 빌딩에 사용하고 있다.

이 오픈 소스가 하는 일은 AWS, Azure, GCP등 기존에 클라우드 서비스를 추상화시켜 하나로 통합하고 더 쓰기 편하고 빠르게 개발을 할 수 있게 도와준다.

출처

Cloud Service#

각각의 클라우드 서비스는 동일한 목적의 비슷한 서비스들을 제공하고 있다.

다음은 비슷한 목적의 대표적인 클라우드 서비스들을 비교하는 표이다.

구분	AWS	Azure	GCP
저장소	S3	Blob Storage	Cloud Storage
Compute	EC2	VM	Compute Engine
Functions	Lambda	Functions	Functions
API 관리	API Gateway	API Management	Cloud Endpoints
Stack 빌딩	CloudFormation	Automation	Deployment Manager

각 클라우드 서비스들의 목적과 하는 일은 비슷하지만 각 서비스 플렛폼별 설정과 사용법이 다르다.

Serverless Framework는 이런 비슷한 기능들을 추상화하여 설정을 간편화하고 내부적으로는 각 서비스 플렛폼에 맞는 설정이 자동으로 만들어지고 배포할 수 있도록 구성되어있다.

Why Serverless Framework Use?#

생산성#

AWS를 통하여 아주 기본적인 HTTP를 통한 API 하나를 구현하다고 가정해보자.

우선 코드를 완성 후 Lambda를 만들고 소스를 압축하여 Lambda에 업로드 한다.
API Gateway 를 통해 해당 Lambda 와 연결 작업하고 해당 EndPoint를 Router53을 통해 도메인과 연결한다.
각 서비스에 맞는 IAM 설정을 한다.

이 작업을 위해서는 매번 웹페이지 콘솔을 열고 해당 서비스 페이지에 접속하여 설정을 해야 하고 수정을 할 경우에도 동일한 작업을 반복해야 한다.

Serverless Framework를 사용하여 작업한 경우에는 코드 작업이 완료되면 serverless deploy 명령어로 배포한다.

해당 명령어 하나로 위에서 언급한 일련의 작업들이 자동화 되어 진행되고 수정시에도 마찬가지로 명령어 한 줄이면 업데이트를 완료할 수 있다.

종속성#

정확히는 종속성을 피하기 위해서라는 이유

AWS에도 이미 Serverless Framework 와 같은 단순한 명령줄 인터페이스인 SAM(Serverless Application Model)이 존재한다.

하지만 이는 오로지 AWS를 위함이고 Azure와 GCP에서는 사용 할 수 없습니다. 평생 한가지 플렛폼만 사용할 것이 아니라면 가급적이면 종속성을 피하는것이 좋다.

Serverless Framework를 활용하여 Cross Cloud Service 방식으로 제작을 하면 다양한 클라우드 서비스를 섞어서 사용하거나 서비스를 이전하는데 장점이 있을 수 있다.

Deploy Framework#

서버리스 애플리케이션을 개발할 때 툴 박스에서 가장 중요한 툴은 배포 프레임 워크라고 할 수 있다.

배포 프레임워크로 다양한 오픈소스 대안을 사용할 수 있습니다.

Serverless Framework
AWS SAM
AWS CDK(AWS Cloud Development Kit)
Terraform
Claudia.js
Zappa
Up
Architect

deploy-serverless

CloudFormation#

이러한 툴을 사용하여 프로비저닝을 자동화하기 전에 AWS에서 리소스를 프로비저닝하는 방법을 이해해야 한다.

예를 들어 Serverless Framework 또는 AWS SAM 을 사용하는 경우 AWS CloudFormation의 작동 방식과 프레임워크의 기능을 이해해야 하는데, 툴이 작동하는 방식을 이해하지 않고 툴에 의존하게 되면 문제가 발생했을 때 이를 해결하는 방법을 모르기 때문에 위험할 수 있다.

즉, 일단 기본 메커니즘과 작업 방식을 파악한 후에는 작업을 자동화하여 생산성을 높일 수 있는 툴을 찾는것을 추천한다.

I Like Serverless Framework#

기본 설정과 생산적인 추상화를 제공한다.
프레임워크의 기능을 확장하고 플러그인을 통한 결정에 동의하지 않는 옵션도 제공한다.

이 기능은 Serverless Framework가 AWS SAM 및 기타 다른 유사한 프레임 워크보다 뛰어난 차별점이다.

SAM을 사용할 때는 생성된 AWS CloudFormation 템플릿에서 설정 하나를 변경하기 위해 AWS CloudFormation 매크로를 생성해야 한다.

이 사용 후기에 대한 내용은 이전에 “AWS SAM + Cloudformation macros, a patch made in heaven”라는 글로 소개한 적이 있습니다.

AWS SAM + CF macros

Serverless Framework Plugin#

서버리스 프레임워크를 위한 다양한 community-driven plugins이 있다.

serverless-iam-roles-per-function#

최상의 보안을 위해서는 최소 권한 원칙을 따르고 각 기능에 대한 전용 IAM 역할을 생성해야 합니다. 이러한 역할은 가능한 최소한의 권한을 부여해야 합니다.

SAM을 사용하면 기능별 IAM 역할을 쉽게 구성할 수 있지만, Serverless Framework의 기본 동작은 공유 IAM 역할 사용입니다. 기능별 IAM을 위한 기본 제공 메커니즘을 사용하려면 serverless.yml에서 기능별 역할을 사용자 지정 AWS CloudFormation 리소스로 생성해야 합니다. 이는 공유 역할을 생성하는 구문보다 훨씬 더 장황합니다.

다행히도, 이 상황에서 사용할 수 있는 serverless-iam-roles-per-function 가 있습니다.

serverless-webpack#

Node.js 함수의 경우 번들링은 cold start time을 줄이고 배치 아티팩트의 크기를 줄이는 데 유용하다.

serverless-webpack플러그인은 sls deploy을 실행할 때마다 기능들을 번들링할 수 있습니다.

serverless-offline#

serverless-offline 플러그인은 프로젝트 폴더에서 sls offline 실행을 함으로써 로컬 버전 Amazon API Gateway 을 실행할 수 있게 한다.

이것이 기본적으로 sam local start-api명령을 통해 제공하는 AWS SAM이다.

sls invoke local를 사용해 Lambda 함수를 로컬에서 실행하고 JSON 출력을 검사하는 것이 더 쉽기 때문에 저는 이를 직접 필요로 하지는 않습니다.

또한 디버그 첨부와 디버그 단계를 통해 문제를 보다 쉽게 디버깅할 수 있습니다.

그러나 이 플러그인은 브라우저를 로컬 엔드 포인트를 가리키고 반환된 HTML이 브라우저에서 렌더링되는 방식을 볼 수 있으므로 서버 측 렌더링을 해야 할 때 유용합니다.

serverless-domain-manager#

serverless-domain-manager 플러그인을 사용하면 API의 사용자 지정 도메인 이름을 쉽게 구성할 수 있으며 플러그인은 사용자를 위해 Route53 레코드 집합도 만들 수 있다.

참고#

2021-06-29#

List#

CloudFormation
Serverless Install

AWS CloudFormation#

AWS CloudFormation Introduce YouTube

AWS 클라우드 형성 및 프로비저닝 도입과 스택을 관리하는 정보

AWS CloudFormation을 활용하면#

Infrastructure as Code를 통해 손쉬운 방법으로 관련된 AWS 및 서드 파티 리소스 모음을 모델링 가능
일관된 방식으로 간단히 프로비저닝하고, 수명 주기 전반에 걸쳐 관리
CloudFormation 템플릿에는 원하는 리소스와 종속성이 설명되어 있으므로 이를 모두 하나의 스택으로 구성하고 시작가능
리소스를 개별적으로 관리하는 대신 템플릿을 통해 전체 스택을 단일 단위로 처리하여 필요한 만큼 자주 생성 및 업데이트하고 삭제가능
스택은 여러 AWS 계정 및 AWS 리전에 걸쳐 관리 및 프로비저닝 가능

CloudFormation 템플릿 용어 및 개념#

Template#

CloudFormation 템플릿은 AWS 서비스 또는 리소스를 구성하고 배포하는 방법을 정의하는 특정 방식으로 형식이 지정된 텍스트 파일입니다.

Stacks#

스택은 단일 템플릿을 사용하여 함께 관리 할 수있는 EC2 가상 머신, S3 스토리지 및 IAM 액세스 제어와 같은 여러 AWS 리소스 모음을 지칭하기 위해 AWS에서 사용하는 용어입니다.

Formatting#

CloudFormation은 JSON 또는 YAML을 사용하여 형식이 지정된 템플릿을 지원합니다. 이들은 텍스트 파일을 구성하는 데 널리 사용되는 파일 형식입니다. 대부분의 다른 IaC 도구는 Kubernetes 와 같은 플랫폼과 마찬가지로 동일한 형식 지정 언어를 사용합니다.

Parameters#

각 배포에 고유 한 설정을 적용해야하는 경우 매개 변수를 사용하여 수행 할 수 있습니다. 매개 변수를 사용하면 CloudFormation이 런타임에 적용 할 각 배포에 대한 사용자 지정 값을 정의 할 수 있습니다.

Conditions#

조건을 설정하여 배포를 미세 조정할 수도 있습니다. 그러면 조건부 규칙을 정의하여 각 배포가 진행되는 방식을 정확하게 제어 할 수 있습니다.

Change sets#

CloudFormation을 사용하여 배포를 업데이트하려는 경우 배포를 생성하는 데 사용한 템플릿을 업데이트 할 수 있습니다. 그런 다음 변경하기 전에 업데이트 된 템플릿이 적용 할 변경 사항을 요약하는 변경 세트를 생성 할 수 있습니다.

Functions#

데이터를 CloudFormation 템플릿으로 가져 오는 방법에는 여러 가지가 있으며 매개 변수가 기본이다.

그러나 이러한 매개 변수는 배포시 알려지지 않을 수 있습니다.

CloudFormation 함수를 사용하면 CloudFormation 디자이너는 현재 CloudFormation에 배포 된 리소스 또는 AWS 계정의 외부 소스에서 데이터를 검색 할 수 있습니다.

Ref는 아래 예제와 같이 템플릿 내의 다른 리소스를 참조하는 데 광범위하게 사용됩니다. 템플릿에서 이전에 생성 된 인스턴스에 대한 EIP를 생성합니다.

"MyEIP" : {
   "Type" : "AWS::EC2::EIP",
   "Properties" : {
      "InstanceId" : { "Ref" : "MyEC2Instance" }
   }
}

AWS CloudFormation Create#

기존 템플릿을 기초로 사용
처음부터 완전히 새로운 템플릿 작성

대부분의 경우 이전 접근 방식은 특히 CloudFormation을 처음 사용하고 배포 할 간단한 구성이있는 경우 더 빠르고 편안하다.

매우 복잡한 배포가 있거나 AWS의 기존 템플릿 라이브러리에서 잘 표현되지 않는 세밀한 AWS 리소스로 작업해야하는 경우에만 처음부터 새 템플릿을 생성하는 것이 합리적이다.

cloudformation

기존 템플릿#

기존 템플릿을 배포의 기반으로 사용하려면 AWS 템플릿 컬렉션 을 검색 하여 필요에 맞는 템플릿을 찾을 수 있다.

예를 들어 EC2 인스턴스를 배포하고 이에 대한 스토리지를 구성하려는 경우 " 임시 드라이브가있는 Amazon EC2 인스턴스 "라는 템플릿 이 시작하기에 좋은 곳이다.

템플릿을 선택한 후에는 컴퓨터에 다운로드하거나 로컬 텍스트 편집기에서 편집하거나 AWS에서 CloudFormation 템플릿을 생성 및 수정하기 위해 제공하는 온라인 도구인 AWS CloudFormation Designer에서 열 수 있으며, Designer는 많은 코딩없이 배포를 쉽게 구축 할 수있는 시각화 및 끌어서 놓기 기능을 제공한다. (단순한 기능 이상을 구현해야하는 경우 일부 코드를 작성해야 함)

Auto Scaling Template

위의 템플릿은 탄성 부하 분산 부하 분산 장치 만 부하 분산 트래픽을받는 자동 스케일링 그룹을 배포한다.

아래는 CloudFormation 템플릿 디자이너의 보기이다.

CloudFormationDesign

CloudFormation 템플릿을 배포#

AWS 환경의 CloudFormation 템플릿에 정의한 리소스를 생성 할 수 있다.

AWS 콘솔 : 템플릿이 로컬 컴퓨터에 저장된 텍스트 파일 인 경우 배포하는 가장 쉬운 방법은 AWS CloudFormation 콘솔 https://console.aws.amazon.com/cloudformation 에 로그인하고 새 스택 생성을 클릭하는 것이다.
콘솔은 템플릿 이름을 지정하고 컴퓨터의 템플릿 파일을 업로드하는 단계를 안내하며, 단계를 완료하고 구성을 검토 한 후 만들기 버튼을 클릭하여 템플릿을 배포한다.
CloudFormation Designer : CloudFormation Designer 에서 템플릿을 생성하는 경우 스택 생성 버튼을 클릭하고 화면의 지시에 따라 템플릿을 적용 할 준비가되면 생성을 눌러 여기에서 직접 배포 할 수 있다.
AWS CLI : AWS CLI 도구를 사용하면 aws cloudformation deploy 명령을 사용하여 템플릿을 배포 할 수 있다.
명령 줄 인수를 사용하여 템플릿이 저장되는 위치 (일반적으로 먼저 S3에 업로드하고 CLI에서 해당 파일을 가리킴) 및 구성 할 수있는 기타 옵션을 정의한다.

Serverless Install#

확인#

AWS 계정
IAM 권한 설정 및 Access Key
AWS CLI 설치
AWS Configure

npm install -g serverless

Serverless Install

serverless install --url https://github.com/AnomalyInnovations/serverless-nodejs-starter --name notes-api

# handler: {filename}-{export}
functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

Function Test#

serverless invoke local --function hello