WEBVTT

00:00:00.000 --> 00:00:03.420
오늘의 주제는 거의 모든 사람이 들어는 받지만 제대로 설명할 수 있는 사람은 거의 없는 주제입니다.

00:00:03.620 --> 00:00:05.760
서버리스, 서버리스, 정확히 무엇일까요?

00:00:05.920 --> 00:00:07.760
정말로 아무것도 없는 상태에서 코드가 돌아가는 것일까요?

00:00:08.020 --> 00:00:09.060
아니면 훨씬 더 큰 무언가일까요?

00:00:09.200 --> 00:00:10.340
분명히 짚고 넘어갑시다.

00:00:10.580 --> 00:00:12.340
서버리스는 서버가 없다는 뜻이 아닙니다.

00:00:12.520 --> 00:00:13.820
서버를 신경 쓸 필요가 없다는 뜻이며,

00:00:14.080 --> 00:00:16.320
이러한 차이가 소프트웨어를 구축하는 방식을 완전히 바꿔놓습니다.

00:00:16.540 --> 00:00:18.820
이번 에피소드가 끝나면 여러분은 에이저 펑션스가 실제로 무엇인지,

00:00:19.100 --> 00:00:21.640
가격 책정은 어떻게 되는지, 그리고 언제 사용해야 하는지 이해하게 될 것입니다.

00:00:21.820 --> 00:00:24.660
가장 큰 오해부터 시작해서 구성 요소별로 하나씩 파헤쳐보겠습니다.

00:00:24.660 --> 00:00:27.100
서버리스의 진짜 의미에 대해서 말이죠.

00:00:27.280 --> 00:00:29.060
몇 가지 오해를 바로 잡고 시작합시다.

00:00:29.220 --> 00:00:32.180
서버리스라는 이름은 마이크로소프트가 만든 최악의 마케팅 용어입니다.

00:00:32.400 --> 00:00:34.740
사람들이 말 그대로 서버가 전혀 없다고 생각하게 만들기 때문이죠.

00:00:34.900 --> 00:00:35.780
그건 사실이 아닙니다.

00:00:36.000 --> 00:00:37.400
서버는 존재하며 엄청나게 많이 있습니다.

00:00:37.620 --> 00:00:39.300
단지 여러분이 직접 만질 필요가 없을 뿐입니다.

00:00:39.460 --> 00:00:42.680
20년 전에는 인터넷에서 코드를 실행하려면 해야 할 일이 정말 많았습니다.

00:00:42.960 --> 00:00:45.120
가상 머신을 대여하고, 운영체제를 설치하고,

00:00:45.480 --> 00:00:47.680
웹서버를 구성한 뒤 애플리케이션을 배포해야 했죠.

00:00:47.820 --> 00:00:49.840
그러고는 매주 주말마다 보안 업데이트를 패치하고,

00:00:49.840 --> 00:00:52.000
새벽 3시에 서버가 다운되지 않도록 관리해야 했습니다.

00:00:52.280 --> 00:00:53.440
그런데 문제가 하나 있습니다.

00:00:53.720 --> 00:00:56.280
코드가 실행 중이든 아니든 서버 비용을 계속 지불해야 했다는 거죠.

00:00:56.480 --> 00:00:59.180
여러분이 잠든 사이 에도 서버는 윙윙 돌아가며 돈을 쓰고 있었습니다.

00:00:59.380 --> 00:01:01.700
서버리스는 이러한 모든 모델을 완전히 뒤집어 놓습니다.

00:01:01.920 --> 00:01:05.040
코드를 작성해서 업로드만 하면 나머지는 플랫폼이 알아서 처리합니다.

00:01:05.260 --> 00:01:08.600
운영체제, 보안 패치, 확장성, 가용성까지 말이죠.

00:01:08.800 --> 00:01:11.280
여러분은 중요한 로직을 작성하는 데만 집중하면 됩니다.

00:01:11.580 --> 00:01:15.380
식당 주방을 운영하는 것과 자판기를 사용하는 것의 차이라고 생각하면 쉽습니다.

00:01:15.380 --> 00:01:19.500
식당 주방은 상주 직원, 지속적인 재료 공급, 그리고 관리가 필요합니다.

00:01:19.680 --> 00:01:22.700
손님이 단 한 명도 오지 않아도 매일 돈이 들어갑니다.

00:01:22.920 --> 00:01:26.520
자판기는 누군가 버튼을 누르기 전까지는 구석에 가만히 있습니다.

00:01:26.880 --> 00:01:29.800
버튼을 누르면 작동해서 자기 할 일을 하고 다시 잠듭니다.

00:01:30.000 --> 00:01:32.160
실제로 작동할 때만 정기 요금을 내는 셈이죠.

00:01:32.360 --> 00:01:33.760
그게 서버리스의 핵심입니다.

00:01:33.960 --> 00:01:36.180
에이저 펑션스는 마이크로소프트의 서버리스 모델입니다.

00:01:36.380 --> 00:01:38.620
이벤트에 반응하여 작은 코드 조각들을 실행하죠.

00:01:38.820 --> 00:01:42.740
코드는 무언가가 깨울 때까지 대기 상태이다가 실행이 끝나면 다시 잠듭니다.

00:01:42.740 --> 00:01:45.120
그렇다면 그 코드는 실제로 어떻게 생겼을까요?

00:01:45.120 --> 00:01:46.740
에이저 펑션스란 무엇인가?

00:01:46.920 --> 00:01:49.600
함수란 하나의 특정 작업을 수행하는 단일 코드 조각입니다.

00:01:49.780 --> 00:01:50.620
그게 전부입니다.

00:01:50.840 --> 00:01:54.300
로그인 페이지나 데이터베이스, 20개 화면이 포함된 전체 애플리케이션이 아닙니다.

00:01:54.460 --> 00:01:56.220
단 하나의 집중된 작업일 뿐입니다.

00:01:56.420 --> 00:01:58.400
집에 있는 조명 스위치를 생각해보세요.

00:01:58.660 --> 00:02:01.220
켜져서 일을 하다가 다시 꺼지는 방식이죠.

00:02:01.460 --> 00:02:03.560
기존의 웹서버는 이와 정반대입니다.

00:02:03.840 --> 00:02:08.020
아무도 없는데도 집안의 모든 조명을 24시간 7일 내내 켜두는 것과 같습니다.

00:02:08.400 --> 00:02:11.100
에이저 펑션스는 다양한 프로그래밍 언어를 지원합니다.

00:02:11.100 --> 00:02:15.400
자바 스크립트, 파이썬, 시샵, 자바, 파워실 등 편한 것을 사용하시면 됩니다.

00:02:15.620 --> 00:02:16.980
정답은 정해져 있지 않습니다.

00:02:17.220 --> 00:02:18.640
이미 알고 있는 언어를 선택하세요.

00:02:18.860 --> 00:02:20.660
이제 흔히 혼동하는 부분을 명확히 해보죠.

00:02:20.800 --> 00:02:23.260
함수 앱, 펑션 앱은 함수, 펑션 와 같은 것이 아닙니다.

00:02:23.400 --> 00:02:24.760
함수 앱은 컨테이너와 같습니다.

00:02:25.100 --> 00:02:26.420
도구 상자라고 생각해보세요.

00:02:26.720 --> 00:02:30.020
함수 앱 하나를 만들고 그 도구 상자 안에 여러 개의 함수를 추가하는 것입니다.

00:02:30.240 --> 00:02:32.800
각 함수는 자신만의 작업을 수행하는 별도의 도구입니다.

00:02:33.020 --> 00:02:35.960
사용자 가입을 처리하는 함수, 업로드된 이미지를 처리하는 함수,

00:02:35.960 --> 00:02:38.460
야간 보고서를 보내는 함수 등을 각각 만들 수 있죠.

00:02:38.620 --> 00:02:41.080
모두 같은 도구 상자 안에 있지만 독립적으로 작동합니다.

00:02:41.260 --> 00:02:42.440
함수에 대해 한 가지 더 알아야 할 점은

00:02:42.440 --> 00:02:44.680
설계상 상태가 유지되지 않는다는 스테이틀러스 것입니다.

00:02:44.840 --> 00:02:46.940
즉, 실행 사이에 아무것도 기억하지 못한다는 뜻입니다.

00:02:47.120 --> 00:02:49.680
함수가 파일을 처리하고 종료되면 그것으로 끊입니다.

00:02:49.860 --> 00:02:52.500
다음번에 실행될 때는 지난번 기억 없이 새로 시작합니다.

00:02:52.740 --> 00:02:56.220
제약처럼 들리겠지만 사실 이것이 함수를 강력하게 만드는 특징입니다.

00:02:56.400 --> 00:02:58.400
함수는 메모리나 상태를 유지하지 않기 때문에

00:02:58.400 --> 00:03:01.600
트래픽이 급증하면 에이저가 즉시 100개의 복제본을 실행하고

00:03:01.600 --> 00:03:03.540
트래픽이 줄어들면 바로 종료할 수 있습니다.

00:03:03.740 --> 00:03:06.740
그렇게 하면 유효 서버 비용을 내지 않고도 확장성을 확보할 수 있습니다.

00:03:06.960 --> 00:03:08.060
그럼 질문이 생깁니다.

00:03:08.240 --> 00:03:10.140
함수가 무언가 깨울 때까지 아무것도 안 하고 있다면

00:03:10.140 --> 00:03:11.880
실제로 무엇이 함수를 깨우는 걸까요?

00:03:12.040 --> 00:03:13.680
그때 바로 트리거가 등장합니다.

00:03:13.860 --> 00:03:15.360
트리거는 언제를 결정합니다.

00:03:15.580 --> 00:03:17.420
모든 함수는 정확히 하나의 트리거를 가져야 하며

00:03:17.420 --> 00:03:18.540
이는 선택사항이 아닙니다.

00:03:18.700 --> 00:03:20.360
트리거는 함수를 깨우는 이벤트입니다.

00:03:20.580 --> 00:03:23.380
트리거가 없으면 코드는 아무것도 하지 않은 채 그냥 머물러 있게 됩니다.

00:03:23.620 --> 00:03:25.180
트리거를 초인종이라고 생각해보세요.

00:03:25.180 --> 00:03:26.940
함수는 집안에서 대기하고 있습니다.

00:03:27.240 --> 00:03:28.400
영원히 기다릴 수도 있죠.

00:03:28.400 --> 00:03:31.080
누군가 초인종을 누르기 전까지는 아무 일도 일어나지 않습니다.

00:03:31.260 --> 00:03:33.440
그러면 함수가 즉시 작동하여 문을 열고 할 일을 한 뒤

00:03:33.440 --> 00:03:34.860
다시 대기 상태로 돌아갑니다.

00:03:35.020 --> 00:03:37.660
초보자가 가장 자주 접하게 되는 트리거는 4가지가 있습니다.

00:03:37.980 --> 00:03:40.540
http 트리거가 가장 일반적인 시작점입니다.

00:03:40.780 --> 00:03:44.140
누군가 url을 방문하거나 api를 호출하면 함수가 실행됩니다.

00:03:44.380 --> 00:03:46.400
이런 식으로 전체 웹서버를 구축하지 않고도

00:03:46.400 --> 00:03:47.980
가벼운 api를 만들 수 있습니다.

00:03:48.240 --> 00:03:50.960
그 다음에는 일정에 따라 실행되는 타이머 트리거가 있습니다.

00:03:50.960 --> 00:03:55.160
크론 표현식을 설정하여 매시간 또는 매일 자정에 실행되도록 하면

00:03:55.160 --> 00:03:57.660
함수가 정확히 그 시간에 작동합니다.

00:03:57.660 --> 00:04:01.820
유지 보수 작업, 정리 작업 또는 야간 보고서 생성에 아주 적합하죠.

00:04:02.020 --> 00:04:05.100
블랍 트리거는 neger 스토리지의 파일이 업로드 될 때 작동합니다.

00:04:05.320 --> 00:04:08.000
누군가 특정 폴더에 pdf를 업로드 한다고 가정해봅시다.

00:04:08.180 --> 00:04:11.300
블랍 트리거가 해당 업로드를 감지하고 함수를 자동으로 실행합니다.

00:04:11.500 --> 00:04:14.940
이미지 처리, 문서 변환, 파일 검증 작업에 매우 유용합니다.

00:04:15.160 --> 00:04:17.940
그리고 q 트리거는 q의 메시지가 나타날 때 작동합니다.

00:04:17.940 --> 00:04:20.800
q는 시스템의 여러 부분을 분리하는 방법 중 하나입니다.

00:04:20.980 --> 00:04:25.200
한 서비스가 메시지를 q에 넣으면 함수가 이를 가져와 준비되는 대로 처리합니다.

00:04:25.200 --> 00:04:28.640
이는 느린 서비스 하나가 다른 모든 것을 차단하는 상황을 방지합니다.

00:04:28.840 --> 00:04:29.640
핵심은이 겁니다.

00:04:30.020 --> 00:04:33.060
트리거가 작동하면 데이터를 함수에 자동으로 전달합니다.

00:04:33.300 --> 00:04:36.220
데이터를 위해 계속 확인하거나 일이 발생했는지 직접 체크할 필요가 없습니다.

00:04:36.480 --> 00:04:39.340
트리거가 필요한 모든 것을 제공함으로 함수는 그저 처리만 하면 됩니다.

00:04:39.600 --> 00:04:42.460
트리거 없는 함수는 그저 아무것도 하지 않고 대기하는 코드일 뿐입니다.

00:04:42.640 --> 00:04:44.240
트리거는 함수에 목적을 부여합니다.

00:04:44.240 --> 00:04:46.660
즉, 트리거는 함수가 언제 실행될지 알려줍니다.

00:04:46.860 --> 00:04:48.980
그렇다면 데이터는 어디서 오고 어디로 가는 걸까요?

00:04:49.140 --> 00:04:50.760
바로 그럴 때 바인딩이 필요합니다.

00:04:50.920 --> 00:04:53.180
바인딩, 즉 데이터 입력과 출력입니다.

00:04:53.440 --> 00:04:58.360
바인딩은 추가 코드 작성 없이 어떤 데이터를 읽고 결과를 어디로 보낼지 함수에 알려주는 방식입니다.

00:04:58.600 --> 00:05:00.360
설명이 길었으니 간단히 줄여보겠습니다.

00:05:00.740 --> 00:05:01.740
두 가지 유형이 있습니다.

00:05:02.060 --> 00:05:04.020
입력 바인딩은 데이터를 함수로 가져옵니다.

00:05:04.220 --> 00:05:06.200
출력 바인딩은 데이터를 웹으로 보냅니다.

00:05:06.200 --> 00:05:11.860
바인딩이 없다면 스토리지, 계정, 데이터베이스 또는 큐화 통신할 때마다 매번 sdk 코드를 작성해야 합니다.

00:05:12.000 --> 00:05:16.580
연결 문자열을 처리하고, 제시도를 관리하고, 데이터를 직렬화하고, 응답을 역직렬화해야 하죠.

00:05:16.700 --> 00:05:19.020
파일 하나를 읽는데도 상당히 많은 상용보 코드가 필요합니다.

00:05:19.200 --> 00:05:21.100
바인딩을 사용하면 필요한 것만 선언하면 됩니다.

00:05:21.340 --> 00:05:23.460
이 블락 컨테이너에서 읽어오겠다라고 명시하는 식이죠.

00:05:23.600 --> 00:05:25.480
또는 이 큐에 쓰겠다라고 할 수도 있습니다.

00:05:25.700 --> 00:05:27.500
런타임이 나머지를 모두 알아서 처리합니다.

00:05:27.700 --> 00:05:31.260
연결을 열고 데이터를 읽어 매개 변수 형태로 함수에 전달합니다.

00:05:31.260 --> 00:05:35.000
함수가 완료되면 반한 값을 가져와 지정한 위치에 기록합니다.

00:05:35.200 --> 00:05:37.060
바인딩을 파이프라고 생각해보세요.

00:05:37.340 --> 00:05:40.460
함수를 스토리지 계정, 데이터베이스 또는 큐에 연결합니다.

00:05:40.680 --> 00:05:42.800
데이터는 그 파이프를 통해 자동으로 흐릅니다.

00:05:43.020 --> 00:05:45.300
함수는 파이프가 어떻게 작동하는지 알 필요가 없습니다.

00:05:45.600 --> 00:05:48.040
그저 들어오는 것을 받아 처리하고 나갈 것을 보내기만 하면 됩니다.

00:05:48.300 --> 00:05:49.480
구체적인 예를 들어보겠습니다.

00:05:49.840 --> 00:05:51.700
블락 입력 바인딩이 있다고 가정해봅시다.

00:05:51.860 --> 00:05:55.400
함수가 시작되면 블락 저장소에서 파일을 자동으로 읽어와 매개 변수로 전달해줍니다.

00:05:55.400 --> 00:05:57.700
따로 스토리지 sdk 코드를 작성할 필요가 없습니다.

00:05:57.940 --> 00:05:59.660
그저 데이터를 받아 처리하기만 하면 됩니다.

00:05:59.900 --> 00:06:01.800
다른 예로 큐출력 바인딩이 있습니다.

00:06:02.080 --> 00:06:04.720
함수가 작업을 처리하고 마지막에 값을 반환합니다.

00:06:07.060 --> 00:06:09.380
큐에 넣습니다. 큐 관련 코드를 직접 짤 필요가 없습니다.

00:06:09.680 --> 00:06:10.960
그저 값을 반환하기만 하면 됩니다.

00:06:11.220 --> 00:06:12.360
바인딩은 선택사항입니다.

00:06:12.600 --> 00:06:14.680
없을 수도, 하나일 수도, 여러 개일 수도 있습니다.

00:06:14.920 --> 00:06:17.220
어떤 함수는 바인딩 없이 트리거만 필요하기도 합니다.

00:06:17.400 --> 00:06:20.540
반면 다른 함수는 여러 서비스와 연결된 바인딩이 서너 개 필요할 수도 있죠.

00:06:20.740 --> 00:06:23.940
트리거와 바인딩의 조합이야말로 에이저 펑션스를 강력하게 만드는 요소입니다.

00:06:23.940 --> 00:06:27.140
여러분은 비즈니스 로직, 즉 실제 의사결정 코드만 작성하면 됩니다.

00:06:27.380 --> 00:06:29.680
모든 통합작업은 플랫폼이 알아서 처리하니까요.

00:06:29.800 --> 00:06:33.220
함수는 작고 핵심 기능에 집중하며 이해하기 쉬운 상태로 유지됩니다.

00:06:33.440 --> 00:06:34.780
이제 요금 이야기를 해보죠.

00:06:34.960 --> 00:06:37.200
대부분의 초보자는 요금 체계에 놀라곤 합니다.

00:06:37.400 --> 00:06:39.300
대다수에게 소비플랜이 기본 선택지이며,

00:06:39.640 --> 00:06:41.580
90%의 경우 이를 시작으로 삼아야 합니다.

00:06:41.800 --> 00:06:42.940
작동 방식은 이렇습니다.

00:06:43.200 --> 00:06:45.140
함수가 실제로 실행될 때만 요금을 지불합니다.

00:06:45.360 --> 00:06:47.200
유효 상태일 때는 전혀 비용이 발생하지 않죠.

00:06:47.200 --> 00:06:48.980
0원, 반 한 푼도 내지 않습니다.

00:06:49.140 --> 00:06:50.980
청구액은 두 가지 요소로 결정됩니다.

00:06:51.180 --> 00:06:54.260
첫째는 실행 횟수, 즉 함수가 몇 번 작동했는가입니다.

00:06:54.480 --> 00:06:57.400
둘째는 집 2초 단위로 측정되는 실행 시간입니다.

00:06:57.400 --> 00:07:01.080
기본적으로 함수 실행 시간과 사용된 메모리 양을 곱한 값입니다.

00:07:01.300 --> 00:07:03.060
무료 제공량이 상당히 넉넉합니다.

00:07:03.320 --> 00:07:07.020
매달 100만 회의 실행과 40만 집 2초의 사용량이 완전히 무료입니다.

00:07:07.280 --> 00:07:11.320
대부분의 소규모 프로젝트, 취미 앱, 프로토타입은 비용이 전혀 들지 않습니다.

00:07:11.560 --> 00:07:12.180
절대로요.

00:07:12.360 --> 00:07:14.940
무료 제공량을 넘어서 더라도 요금은 여전히 매우 저렴합니다.

00:07:14.940 --> 00:07:16.820
실행 100만 회당 20센트 수준입니다.

00:07:16.980 --> 00:07:17.800
오타가 아닙니다.

00:07:17.980 --> 00:07:19.520
100만 번 실행에 20센트인 거죠.

00:07:19.760 --> 00:07:22.420
스위치를 켤 때만 정기 요금을 내는 것과 같다고 생각하세요.

00:07:22.620 --> 00:07:25.140
배선이 깔려 있다고 해서 매달 기본료를 내는 것이 아닙니다.

00:07:25.340 --> 00:07:27.680
실제로 사용한 전력량에 대해서만 요금을 지불하는 방식입니다.

00:07:27.880 --> 00:07:29.060
물론 다른 플랜들도 있습니다.

00:07:29.340 --> 00:07:31.900
플렉스 소비 플랜은 더 최신이며 가상 네트워크를 지원합니다.

00:07:32.100 --> 00:07:35.220
프리미엄 플랜은 함수를 항상 활성 상태로 유지해 콜드 스타트 지연을 없애줍니다.

00:07:35.420 --> 00:07:38.380
전용 플랜은 기존 앱 서비스 플랜에서 고정된 용량을 제공합니다.

00:07:38.380 --> 00:07:41.400
하지만 시작 단계라면 거의 모든 경우에 소비 플랜이 정답입니다.

00:07:41.540 --> 00:07:43.120
다만 한 가지 주의할 점이 있습니다.

00:07:43.360 --> 00:07:46.160
무료 제공량은 같은 구동 내의 모든 함수 앱이 공유합니다.

00:07:46.360 --> 00:07:49.840
함수 앱이 10개라면 10개 모두 100만 회의 무료 실행량을 나눴습니다.

00:07:50.020 --> 00:07:52.620
그러니 여러 개를 만들기 시작한다면 이 부분을 잘 확인하세요.

00:07:52.820 --> 00:07:53.980
요금은 정말 합리적입니다.

00:07:54.260 --> 00:07:56.500
하지만 구체적인 예시를 통해 실감나게 설명해보겠습니다.

00:07:56.840 --> 00:07:58.080
실제 현장의 시나리오 조.

00:07:58.280 --> 00:08:01.140
사용자가 프로필 사진을 업로드하는 웹사이트를 운영한다고 가정해봅시다.

00:08:01.140 --> 00:08:03.760
이미지 용량이 하나당 10MB 정도로 매우 큽니다.

00:08:03.900 --> 00:08:06.060
이로 인해 몇 가지 실질적인 문제가 발생하죠.

00:08:06.240 --> 00:08:10.320
파일이 크면 저장 비용이 많이 들고 페이지를 불러올 때마다 웹사이트 속도가 느려지며

00:08:10.320 --> 00:08:12.820
사진을 기다려야 하는 사용자들은 답답함을 느낍니다.

00:08:13.040 --> 00:08:15.780
그래서 이미지를 자동으로 축소할 방법이 필요합니다.

00:08:16.020 --> 00:08:19.680
에이저 펑션스가 없다면 처음부터 백그라운드 워커를 직접 구축해야 합니다.

00:08:19.900 --> 00:08:22.960
즉, 별도의 서버를 마련하고 작업 부하를 관리할 대기열을 설정하며

00:08:22.960 --> 00:08:25.880
이 모든 과정을 처리할 코드를 직접 작성해야 한다는 뜻입니다.

00:08:25.880 --> 00:08:29.440
이미지 축소처럼 단순한 작업에 불필요하게 복잡한 과정입니다.

00:08:29.640 --> 00:08:33.180
에이저 펑션스를 사용하면 블랍 트리거 하나와 함수 하나만 있으면 충분합니다.

00:08:33.400 --> 00:08:34.820
서버를 신경 쓸 필요도 없습니다.

00:08:35.160 --> 00:08:36.980
작동 방식을 단계별로 설명해드리겠습니다.

00:08:37.300 --> 00:08:40.940
사용자가 웹사이트에 사진을 업로드하면 해당 파일이 에이저 블랍 저장소에 저장됩니다.

00:08:40.940 --> 00:08:43.740
파일이 도착하는 즉시 블랍 트리거가 자동으로 실행됩니다.

00:08:43.920 --> 00:08:45.740
함수가 활성화되어 압축 코드를 실행하고

00:08:45.740 --> 00:08:48.140
크기가 줄어든 버전을 다시 저장소에 저장합니다.

00:08:48.340 --> 00:08:50.300
이 모든 과정이 몇 초 안에 완료됩니다.

00:08:50.520 --> 00:08:52.980
전체 과정이 보이지 않는 곳에서 자동으로 처리되므로

00:08:52.980 --> 00:08:54.540
사용자는 기다릴 필요가 없습니다.

00:08:54.860 --> 00:08:55.980
일상적인 또 다른 예로

00:08:55.980 --> 00:08:58.920
서비스 가입 시 환영 이메일을 보내는 상황을 들 수 있습니다.

00:08:59.180 --> 00:09:02.120
http 트리거가 웹사이트로부터 가입 요청을 감지합니다.

00:09:02.340 --> 00:09:04.280
함수가 실행되어 사용자의 이메일 주소를 가져오고

00:09:04.280 --> 00:09:06.960
샌드그리드를 통해 환영 메시지를 발송한 뒤 작업이 끝납니다.

00:09:06.960 --> 00:09:09.180
사용자는 거의 즉시 이메일을 받게 됩니다.

00:09:09.380 --> 00:09:11.740
메일 서버를 구축하거나 전송 대기열을 관리할 필요 없이

00:09:11.740 --> 00:09:13.900
함수 하나로 작업이 깔끔하게 마무리됩니다.

00:09:14.060 --> 00:09:16.620
이런 업무가 바로 에이저 펑션스 가 설계된 목적입니다.

00:09:16.820 --> 00:09:19.060
작고 집중화된 이벤트 기반의 작업들 말이죠.

00:09:19.260 --> 00:09:21.260
거대한 애플리케이션이나 복잡한 워크플로우가 아니라

00:09:21.260 --> 00:09:24.420
외부의 이벤트에 위해 시작되어 특정 작업을 완벽하게 수행하는 것입니다.

00:09:24.600 --> 00:09:26.520
에이저 펑션스는 언제 사용해야 할까요?

00:09:26.700 --> 00:09:28.080
그렇다면 언제 함수를 사용하고

00:09:28.080 --> 00:09:29.800
언제 다른 기술을 사용해야 할까요?

00:09:29.960 --> 00:09:31.760
판단하기 위한 간단한 방법이 있습니다.

00:09:32.000 --> 00:09:33.900
해당 작업이 짧은지, 이벤트 기반인지,

00:09:33.900 --> 00:09:35.920
그리고 상태를 저장하지 않는지 자문해보세요.

00:09:36.100 --> 00:09:39.640
세 가지 모두에 예라고 답했다면 에이저 펑션스가 적합한 도구일 것입니다.

00:09:39.800 --> 00:09:41.720
우선 활용하기 좋은 사례부터 살펴보겠습니다.

00:09:42.120 --> 00:09:44.340
API와 웹북은 아주 완벽한 조합입니다.

00:09:44.600 --> 00:09:47.080
HTTP 요청에 응답하고 하나의 작업을 처리한 뒤

00:09:47.080 --> 00:09:49.360
결과를 반환하는 가벼운 엔드포인트가 필요하다면

00:09:49.360 --> 00:09:51.820
바로 그것이 HTTP 트리거의 용도입니다.

00:09:52.000 --> 00:09:54.280
파일 및 이미지 처리도 중요한 사례 중 하나입니다.

00:09:54.520 --> 00:09:56.260
파일이 저장소에 들어오면 함수가 실행되어

00:09:56.260 --> 00:09:57.900
파일을 변환하고 결과를 저장하며

00:09:57.900 --> 00:09:59.720
이 모든 과정을 서버 없이 수행합니다.

00:09:59.920 --> 00:10:02.740
매일 밤 정리 작업이나 보고서 생성 같은 예약된 작업은

00:10:02.740 --> 00:10:04.500
타이머 트리거로 아주 잘 작동합니다.

00:10:04.700 --> 00:10:07.920
ETL 파이프라인을 위한 데이터 변환 작업도 흔하게 사용됩니다.

00:10:08.120 --> 00:10:11.100
또한 함수는 서로 직접 통신하지 않는 두 서비스를 연결하는

00:10:11.100 --> 00:10:12.800
완벽한 통합 접착제 역할을 합니다.

00:10:13.080 --> 00:10:15.700
이제 함수가 적합하지 않은 경우에 대해 이야기해보겠습니다.

00:10:16.100 --> 00:10:18.140
소비 플랜, 컨섬션 플랜에서 함수는

00:10:18.140 --> 00:10:19.740
기본적으로 5분의 시간 제한이 있고

00:10:19.740 --> 00:10:21.600
구성에 따라 최대 10분까지 가능하므로

00:10:21.600 --> 00:10:23.500
장기 실행 프로세스는 문제가 됩니다.

00:10:23.760 --> 00:10:26.120
작업 시간이 그보다 길다면 다른 대안이 필요합니다.

00:10:26.120 --> 00:10:29.000
상태 저장, 스테이트풀, 애플리케이션 또한 적합하지 않습니다.

00:10:29.140 --> 00:10:31.320
함수는 실행 사이에 아무것도 기억하지 못합니다.

00:10:31.320 --> 00:10:34.220
세션 상태를 유지하거나 단계별 진행 상황을 추적해야 한다면

00:10:34.220 --> 00:10:35.620
설계 위도와 맞지 않는 것입니다.

00:10:35.800 --> 00:10:37.880
무거운 컴퓨팅 작업도 적절하지 않습니다.

00:10:38.100 --> 00:10:40.660
CPU를 몇 분 또는 몇 시간 동안 지속적으로 사용해야 한다면

00:10:40.660 --> 00:10:42.760
가상 머신이나 컨테이너가 더 나은 선택입니다.

00:10:42.940 --> 00:10:45.380
한 작업이 다른 작업에 의존하는 복잡한 워크플로는

00:10:45.380 --> 00:10:47.940
듀러블 펑션스 나 로직 앱스로 처리하는 것이 좋습니다.

00:10:48.160 --> 00:10:50.080
여기 대안들에 대한 간략한 개요가 있습니다.

00:10:50.400 --> 00:10:51.960
에이저 로직 앱스는 서비스 연결을 위한

00:10:51.960 --> 00:10:53.540
노코드, 노코드, 옵션입니다.

00:10:53.540 --> 00:10:55.180
사용자 지정 코드를 작성할 필요가 없다면

00:10:55.180 --> 00:10:57.420
로직 앱스 위 시각적 디자이너로 작업을 수행할 수 있습니다.

00:10:57.640 --> 00:10:59.700
에이저 앱 서비스는 24시간 연중 우유로 실행되는

00:10:59.700 --> 00:11:01.180
전체 웹 애플리케이션을 위한 것입니다.

00:11:01.340 --> 00:11:03.900
항상 켜져 있어야 하는 완전한 웹사이트나 API가 필요하다면

00:11:03.900 --> 00:11:04.780
이 도구가 적합합니다.

00:11:04.980 --> 00:11:07.080
에이저 컨테이너 앱스는 런타임에 대한 제어권이 강화된

00:11:07.080 --> 00:11:08.880
컨테이너와 된 마이크로 서비스를 제공합니다.

00:11:09.060 --> 00:11:11.420
그리고 에이저 가상 머신은 필요에 따라 운영체제에 대한

00:11:11.420 --> 00:11:12.620
완전한 제어권을 제공합니다.

00:11:12.860 --> 00:11:14.520
여기에 간단한 경험 법칙이 있습니다.

00:11:14.520 --> 00:11:16.620
작업을 한 문장으로 설명할 수 있다면

00:11:16.620 --> 00:11:19.020
아마도 함수에 적합한 후보일 것입니다.

00:11:19.180 --> 00:11:21.160
이미지가 업로드되면 압축하십시오.

00:11:21.320 --> 00:11:23.680
누군가 가입하면 환영 이메일을 보내십시오.

00:11:23.820 --> 00:11:25.920
매일 자정의 정리 작업을 실행하십시오.

00:11:26.060 --> 00:11:28.280
한 문장, 한 작업, 한 함수입니다.

00:11:28.500 --> 00:11:30.380
피해야 할 초보자의 흔한 실수들입니다.

00:11:30.620 --> 00:11:32.920
이제 주의해야 할 몇 가지 사항에 대해 이야기해보겠습니다.

00:11:33.260 --> 00:11:36.080
이는 초보자들이 시작할 때 거의 누구나 범하는 실수들입니다.

00:11:36.280 --> 00:11:39.300
흔한 초보자의 실수는 함수가 항상 무료라고 생각하는 것입니다.

00:11:39.300 --> 00:11:42.840
무료 제공량이 넉넉해서 100만 번이 실행이 많게 느껴질 수 있지만

00:11:42.840 --> 00:11:45.720
함수가 입소문을 타거나 봇의 공격을 받으면

00:11:45.720 --> 00:11:47.400
실행 횟수는 금방 늘어납니다.

00:11:47.400 --> 00:11:50.380
따라서 사용량을 모니터링하고 에이저에서 예산 알림을 설정하여

00:11:50.380 --> 00:11:52.260
월말의 뜻밖의 청구서를 받지 않도록 하십시오.

00:11:52.360 --> 00:11:55.040
또 다른 실수는 콜드 스타트, 콜드 스타츠를 무시하는 것입니다.

00:11:55.200 --> 00:11:57.880
유유 상태 후에 함수가 처음 실행될 때는 시간이 더 걸립니다.

00:11:58.140 --> 00:12:00.160
소비 플랜에서는 몇 초 정도 걸릴 수 있습니다.

00:12:00.380 --> 00:12:02.160
대부분의 사용 사례에서는 괜찮습니다.

00:12:02.400 --> 00:12:04.980
하지만 1mm가 중요한 지연 시간에 민감한 API를 구축 중이라면

00:12:04.980 --> 00:12:07.100
프리미엄 플랜을 고려하거나 항상 준비된 인스턴스

00:12:07.100 --> 00:12:08.980
Always Ready Instances를 활성화하십시오.

00:12:09.060 --> 00:12:11.680
그리고 너무 오래 실행되는 함수를 작성하는 문제가 있습니다.

00:12:11.680 --> 00:12:15.460
소비 플랜에는 기본 5분, 최대 10분의 시간 제한이 있습니다.

00:12:15.680 --> 00:12:19.780
함수가 파일을 처리하는데 15분이 걸리면 중간에 강제로 종료됩니다.

00:12:20.020 --> 00:12:23.200
작업을 더 작은 단위로 나누거나 다른 호스팅 플랜을 사용하세요.

00:12:23.440 --> 00:12:27.120
놓치기 쉬운 또 다른 실수는 패키지에서 실행, 배포를 사용하지 않는 것입니다.

00:12:27.340 --> 00:12:31.440
이것은 콜드 스타트를 개선하고 배포 안정성을 높이는 간단한 설정 변경입니다.

00:12:31.660 --> 00:12:34.500
개별 파일을 복사하는 대신 zip 패키지로 배포하게 됩니다.

00:12:34.740 --> 00:12:36.660
포털에서 체크박스 하나만 선택하면 됩니다.

00:12:36.920 --> 00:12:37.520
바로 하세요.

00:12:37.760 --> 00:12:40.880
인증 없이 HTTP 엔드포인트를 노출하는 것도 또 다른 함정입니다.

00:12:40.880 --> 00:12:44.580
테스트 중에 함수를 익명 상태로 두었다가 그대로 잠그는 것을 잊기 쉽습니다.

00:12:44.740 --> 00:12:46.920
처음부터 권한 부여 수준을 올바르게 설정하세요.

00:12:47.120 --> 00:12:48.740
함수 키나 관리자 키를 사용하세요.

00:12:48.940 --> 00:12:49.980
문을 열어두지 마세요.

00:12:50.180 --> 00:12:52.780
여러 함수 앱에서 스토리지 계정을 재사용하는 것도 문제입니다.

00:12:52.960 --> 00:12:54.780
개발 환경에서는 공유해도 괜찮습니다.

00:12:54.980 --> 00:12:57.940
운영 환경에서는 각 함수 앱마다 고유한 스토리지 계정을 사용해야 합니다.

00:12:58.160 --> 00:13:01.580
그렇지 않으면 한 함수의 트래픽이 다른 함수를 느리게 만드는 간섭 문제가 발생합니다.

00:13:01.800 --> 00:13:04.260
마지막으로 애플리케이션 인사이츠를 활성화하지 않는 것입니다.

00:13:04.460 --> 00:13:05.940
없으면 앞이 보이지 않는 것과 같습니다.

00:13:06.280 --> 00:13:08.360
실패, 오류 또는 성능 문제를 볼 수 없습니다.

00:13:10.880 --> 00:13:12.840
첫날부터 활성화하세요.

00:13:13.060 --> 00:13:15.580
30초면 되며 디버깅 시간을 몇 시간이나 절약해 줍니다.

00:13:15.760 --> 00:13:19.500
이 모든 것의 환급률은 함수를 잡고 집중적이며 상태비 저장으로 유지하는 것입니다.

00:13:19.660 --> 00:13:21.680
함수 하나당 작업하나 그 이상은 안 됩니다.

00:13:21.960 --> 00:13:23.140
그것이 바로 시스템입니다.

00:13:23.380 --> 00:13:27.120
에이저 펑션셋은 이벤트에 반응하여 작은 코드 조각을 실행하는 서버리스 컴퓨팅입니다.

00:13:27.300 --> 00:13:29.180
코드가 실행될 때만 비용을 지불합니다.

00:13:29.420 --> 00:13:33.040
트리거는 함수를 깨울 시점을 알려주고 바인딩은 필요한 데이터와 연결하며

00:13:33.040 --> 00:13:35.840
소비 플랜은 소규모 프로젝트에 거의 무료로 제공됩니다.

00:13:35.840 --> 00:13:40.600
지금 바로 에이저 포털에서 간단한 http 트리거 함수를 만드는 것이 가장 좋은 시작입니다.

00:13:40.780 --> 00:13:42.900
5분이면 충분하며 비용도 들지 않습니다.

00:13:43.100 --> 00:13:46.080
마이크로소프트 날리지 너게츠를 구독하여 쉬운 설명을 더 확인하고

00:13:46.080 --> 00:13:49.160
서버리스가 무엇인지 계속 묻는 사람들에게 이 영상을 공유하세요.

00:13:49.160 --> 00:13:49.820
프라오