오늘의 주제는 거의 모든 사람이 들어는 받지만 제대로 설명할 수 있는 사람은 거의 없는 주제입니다.서버리스, 서버리스, 정확히 무엇일까요?정말로 아무것도 없는 상태에서 코드가 돌아가는 것일까요?아니면 훨씬 더 큰 무언가일까요?분명히 짚고 넘어갑시다.서버리스는 서버가 없다는 뜻이 아닙니다.서버를 신경 쓸 필요가 없다는 뜻이며,이러한 차이가 소프트웨어를 구축하는 방식을 완전히 바꿔놓습니다.이번 에피소드가 끝나면 여러분은 에이저 펑션스가 실제로 무엇인지,가격 책정은 어떻게 되는지, 그리고 언제 사용해야 하는지 이해하게 될 것입니다.가장 큰 오해부터 시작해서 구성 요소별로 하나씩 파헤쳐보겠습니다.서버리스의 진짜 의미에 대해서 말이죠.몇 가지 오해를 바로 잡고 시작합시다.서버리스라는 이름은 마이크로소프트가 만든 최악의 마케팅 용어입니다.사람들이 말 그대로 서버가 전혀 없다고 생각하게 만들기 때문이죠.그건 사실이 아닙니다.서버는 존재하며 엄청나게 많이 있습니다.단지 여러분이 직접 만질 필요가 없을 뿐입니다. 20년 전에는 인터넷에서 코드를 실행하려면 해야 할 일이 정말 많았습니다.가상 머신을 대여하고, 운영체제를 설치하고,웹서버를 구성한 뒤 애플리케이션을 배포해야 했죠.그러고는 매주 주말마다 보안 업데이트를 패치하고,새벽 3시에 서버가 다운되지 않도록 관리해야 했습니다.그런데 문제가 하나 있습니다.코드가 실행 중이든 아니든 서버 비용을 계속 지불해야 했다는 거죠.여러분이 잠든 사이 에도 서버는 윙윙 돌아가며 돈을 쓰고 있었습니다.서버리스는 이러한 모든 모델을 완전히 뒤집어 놓습니다.코드를 작성해서 업로드만 하면 나머지는 플랫폼이 알아서 처리합니다.운영체제, 보안 패치, 확장성, 가용성까지 말이죠.여러분은 중요한 로직을 작성하는 데만 집중하면 됩니다.식당 주방을 운영하는 것과 자판기를 사용하는 것의 차이라고 생각하면 쉽습니다.

식당 주방은 상주 직원, 지속적인 재료 공급, 그리고 관리가 필요합니다.손님이 단 한 명도 오지 않아도 매일 돈이 들어갑니다.자판기는 누군가 버튼을 누르기 전까지는 구석에 가만히 있습니다.버튼을 누르면 작동해서 자기 할 일을 하고 다시 잠듭니다.실제로 작동할 때만 정기 요금을 내는 셈이죠.그게 서버리스의 핵심입니다.에이저 펑션스는 마이크로소프트의 서버리스 모델입니다.이벤트에 반응하여 작은 코드 조각들을 실행하죠.코드는 무언가가 깨울 때까지 대기 상태이다가 실행이 끝나면 다시 잠듭니다.그렇다면 그 코드는 실제로 어떻게 생겼을까요?에이저 펑션스란 무엇인가?함수란 하나의 특정 작업을 수행하는 단일 코드 조각입니다.그게 전부입니다.로그인 페이지나 데이터베이스, 20개 화면이 포함된 전체 애플리케이션이 아닙니다.단 하나의 집중된 작업일 뿐입니다.집에 있는 조명 스위치를 생각해보세요.켜져서 일을 하다가 다시 꺼지는 방식이죠.기존의 웹서버는 이와 정반대입니다.아무도 없는데도 집안의 모든 조명을 24시간 7일 내내 켜두는 것과 같습니다.에이저 펑션스는 다양한 프로그래밍 언어를 지원합니다.자바 스크립트, 파이썬, 시샵, 자바, 파워실 등 편한 것을 사용하시면 됩니다.정답은 정해져 있지 않습니다.이미 알고 있는 언어를 선택하세요.이제 흔히 혼동하는 부분을 명확히 해보죠.함수 앱, 펑션 앱은 함수, 펑션 와 같은 것이 아닙니다.함수 앱은 컨테이너와 같습니다.도구 상자라고 생각해보세요.함수 앱 하나를 만들고 그 도구 상자 안에 여러 개의 함수를 추가하는 것입니다.각 함수는 자신만의 작업을 수행하는 별도의 도구입니다.사용자 가입을 처리하는 함수, 업로드된 이미지를 처리하는 함수,야간 보고서를 보내는 함수 등을 각각 만들 수 있죠.모두 같은 도구 상자 안에 있지만 독립적으로 작동합니다.함수에 대해 한 가지 더 알아야 할 점은설계상 상태가 유지되지 않는다는 스테이틀러스 것입니다.

즉, 실행 사이에 아무것도 기억하지 못한다는 뜻입니다.함수가 파일을 처리하고 종료되면 그것으로 끊입니다.다음번에 실행될 때는 지난번 기억 없이 새로 시작합니다.제약처럼 들리겠지만 사실 이것이 함수를 강력하게 만드는 특징입니다.함수는 메모리나 상태를 유지하지 않기 때문에트래픽이 급증하면 에이저가 즉시 100개의 복제본을 실행하고트래픽이 줄어들면 바로 종료할 수 있습니다.그렇게 하면 유효 서버 비용을 내지 않고도 확장성을 확보할 수 있습니다.그럼 질문이 생깁니다.함수가 무언가 깨울 때까지 아무것도 안 하고 있다면실제로 무엇이 함수를 깨우는 걸까요?그때 바로 트리거가 등장합니다.트리거는 언제를 결정합니다.모든 함수는 정확히 하나의 트리거를 가져야 하며이는 선택사항이 아닙니다.트리거는 함수를 깨우는 이벤트입니다.트리거가 없으면 코드는 아무것도 하지 않은 채 그냥 머물러 있게 됩니다.트리거를 초인종이라고 생각해보세요.함수는 집안에서 대기하고 있습니다.영원히 기다릴 수도 있죠.누군가 초인종을 누르기 전까지는 아무 일도 일어나지 않습니다.그러면 함수가 즉시 작동하여 문을 열고 할 일을 한 뒤다시 대기 상태로 돌아갑니다.초보자가 가장 자주 접하게 되는 트리거는 4가지가 있습니다. http 트리거가 가장 일반적인 시작점입니다.누군가 url을 방문하거나 api를 호출하면 함수가 실행됩니다.이런 식으로 전체 웹서버를 구축하지 않고도가벼운 api를 만들 수 있습니다.그 다음에는 일정에 따라 실행되는 타이머 트리거가 있습니다.크론 표현식을 설정하여 매시간 또는 매일 자정에 실행되도록 하면함수가 정확히 그 시간에 작동합니다.유지 보수 작업, 정리 작업 또는 야간 보고서 생성에 아주 적합하죠.블랍 트리거는 neger 스토리지의 파일이 업로드 될 때 작동합니다.누군가 특정 폴더에 pdf를 업로드 한다고 가정해봅시다.

블랍 트리거가 해당 업로드를 감지하고 함수를 자동으로 실행합니다.이미지 처리, 문서 변환, 파일 검증 작업에 매우 유용합니다.그리고 q 트리거는 q의 메시지가 나타날 때 작동합니다. q는 시스템의 여러 부분을 분리하는 방법 중 하나입니다.한 서비스가 메시지를 q에 넣으면 함수가 이를 가져와 준비되는 대로 처리합니다.이는 느린 서비스 하나가 다른 모든 것을 차단하는 상황을 방지합니다.핵심은이 겁니다.트리거가 작동하면 데이터를 함수에 자동으로 전달합니다.데이터를 위해 계속 확인하거나 일이 발생했는지 직접 체크할 필요가 없습니다.트리거가 필요한 모든 것을 제공함으로 함수는 그저 처리만 하면 됩니다.트리거 없는 함수는 그저 아무것도 하지 않고 대기하는 코드일 뿐입니다.트리거는 함수에 목적을 부여합니다.즉, 트리거는 함수가 언제 실행될지 알려줍니다.그렇다면 데이터는 어디서 오고 어디로 가는 걸까요?바로 그럴 때 바인딩이 필요합니다.바인딩, 즉 데이터 입력과 출력입니다.바인딩은 추가 코드 작성 없이 어떤 데이터를 읽고 결과를 어디로 보낼지 함수에 알려주는 방식입니다.설명이 길었으니 간단히 줄여보겠습니다.두 가지 유형이 있습니다.입력 바인딩은 데이터를 함수로 가져옵니다.출력 바인딩은 데이터를 웹으로 보냅니다.바인딩이 없다면 스토리지, 계정, 데이터베이스 또는 큐화 통신할 때마다 매번 sdk 코드를 작성해야 합니다.연결 문자열을 처리하고, 제시도를 관리하고, 데이터를 직렬화하고, 응답을 역직렬화해야 하죠.파일 하나를 읽는데도 상당히 많은 상용보 코드가 필요합니다.바인딩을 사용하면 필요한 것만 선언하면 됩니다.이 블락 컨테이너에서 읽어오겠다라고 명시하는 식이죠.또는 이 큐에 쓰겠다라고 할 수도 있습니다.런타임이 나머지를 모두 알아서 처리합니다.연결을 열고 데이터를 읽어 매개 변수 형태로 함수에 전달합니다.

함수가 완료되면 반한 값을 가져와 지정한 위치에 기록합니다.바인딩을 파이프라고 생각해보세요.함수를 스토리지 계정, 데이터베이스 또는 큐에 연결합니다.데이터는 그 파이프를 통해 자동으로 흐릅니다.함수는 파이프가 어떻게 작동하는지 알 필요가 없습니다.그저 들어오는 것을 받아 처리하고 나갈 것을 보내기만 하면 됩니다.구체적인 예를 들어보겠습니다.블락 입력 바인딩이 있다고 가정해봅시다.함수가 시작되면 블락 저장소에서 파일을 자동으로 읽어와 매개 변수로 전달해줍니다.따로 스토리지 sdk 코드를 작성할 필요가 없습니다.그저 데이터를 받아 처리하기만 하면 됩니다.다른 예로 큐출력 바인딩이 있습니다.함수가 작업을 처리하고 마지막에 값을 반환합니다.

큐에 넣습니다. 큐 관련 코드를 직접 짤 필요가 없습니다.그저 값을 반환하기만 하면 됩니다.바인딩은 선택사항입니다.없을 수도, 하나일 수도, 여러 개일 수도 있습니다.어떤 함수는 바인딩 없이 트리거만 필요하기도 합니다.반면 다른 함수는 여러 서비스와 연결된 바인딩이 서너 개 필요할 수도 있죠.트리거와 바인딩의 조합이야말로 에이저 펑션스를 강력하게 만드는 요소입니다.여러분은 비즈니스 로직, 즉 실제 의사결정 코드만 작성하면 됩니다.모든 통합작업은 플랫폼이 알아서 처리하니까요.함수는 작고 핵심 기능에 집중하며 이해하기 쉬운 상태로 유지됩니다.이제 요금 이야기를 해보죠.대부분의 초보자는 요금 체계에 놀라곤 합니다.대다수에게 소비플랜이 기본 선택지이며, 90%의 경우 이를 시작으로 삼아야 합니다.작동 방식은 이렇습니다.함수가 실제로 실행될 때만 요금을 지불합니다.유효 상태일 때는 전혀 비용이 발생하지 않죠. 0원, 반 한 푼도 내지 않습니다.청구액은 두 가지 요소로 결정됩니다.첫째는 실행 횟수, 즉 함수가 몇 번 작동했는가입니다.둘째는 집 2초 단위로 측정되는 실행 시간입니다.기본적으로 함수 실행 시간과 사용된 메모리 양을 곱한 값입니다.무료 제공량이 상당히 넉넉합니다.매달 100만 회의 실행과 40만 집 2초의 사용량이 완전히 무료입니다.대부분의 소규모 프로젝트, 취미 앱, 프로토타입은 비용이 전혀 들지 않습니다.절대로요.무료 제공량을 넘어서 더라도 요금은 여전히 매우 저렴합니다.실행 100만 회당 20센트 수준입니다.오타가 아닙니다. 100만 번 실행에 20센트인 거죠.스위치를 켤 때만 정기 요금을 내는 것과 같다고 생각하세요.배선이 깔려 있다고 해서 매달 기본료를 내는 것이 아닙니다.실제로 사용한 전력량에 대해서만 요금을 지불하는 방식입니다.물론 다른 플랜들도 있습니다.플렉스 소비 플랜은 더 최신이며 가상 네트워크를 지원합니다.

프리미엄 플랜은 함수를 항상 활성 상태로 유지해 콜드 스타트 지연을 없애줍니다.전용 플랜은 기존 앱 서비스 플랜에서 고정된 용량을 제공합니다.하지만 시작 단계라면 거의 모든 경우에 소비 플랜이 정답입니다.다만 한 가지 주의할 점이 있습니다.무료 제공량은 같은 구동 내의 모든 함수 앱이 공유합니다.함수 앱이 10개라면 10개 모두 100만 회의 무료 실행량을 나눴습니다.그러니 여러 개를 만들기 시작한다면 이 부분을 잘 확인하세요.요금은 정말 합리적입니다.하지만 구체적인 예시를 통해 실감나게 설명해보겠습니다.실제 현장의 시나리오 조.사용자가 프로필 사진을 업로드하는 웹사이트를 운영한다고 가정해봅시다.이미지 용량이 하나당 10MB 정도로 매우 큽니다.이로 인해 몇 가지 실질적인 문제가 발생하죠.파일이 크면 저장 비용이 많이 들고 페이지를 불러올 때마다 웹사이트 속도가 느려지며사진을 기다려야 하는 사용자들은 답답함을 느낍니다.그래서 이미지를 자동으로 축소할 방법이 필요합니다.에이저 펑션스가 없다면 처음부터 백그라운드 워커를 직접 구축해야 합니다.즉, 별도의 서버를 마련하고 작업 부하를 관리할 대기열을 설정하며이 모든 과정을 처리할 코드를 직접 작성해야 한다는 뜻입니다.이미지 축소처럼 단순한 작업에 불필요하게 복잡한 과정입니다.에이저 펑션스를 사용하면 블랍 트리거 하나와 함수 하나만 있으면 충분합니다.서버를 신경 쓸 필요도 없습니다.작동 방식을 단계별로 설명해드리겠습니다.사용자가 웹사이트에 사진을 업로드하면 해당 파일이 에이저 블랍 저장소에 저장됩니다.파일이 도착하는 즉시 블랍 트리거가 자동으로 실행됩니다.함수가 활성화되어 압축 코드를 실행하고크기가 줄어든 버전을 다시 저장소에 저장합니다.이 모든 과정이 몇 초 안에 완료됩니다.전체 과정이 보이지 않는 곳에서 자동으로 처리되므로사용자는 기다릴 필요가 없습니다.

일상적인 또 다른 예로서비스 가입 시 환영 이메일을 보내는 상황을 들 수 있습니다. http 트리거가 웹사이트로부터 가입 요청을 감지합니다.함수가 실행되어 사용자의 이메일 주소를 가져오고샌드그리드를 통해 환영 메시지를 발송한 뒤 작업이 끝납니다.사용자는 거의 즉시 이메일을 받게 됩니다.메일 서버를 구축하거나 전송 대기열을 관리할 필요 없이함수 하나로 작업이 깔끔하게 마무리됩니다.이런 업무가 바로 에이저 펑션스 가 설계된 목적입니다.작고 집중화된 이벤트 기반의 작업들 말이죠.거대한 애플리케이션이나 복잡한 워크플로우가 아니라외부의 이벤트에 위해 시작되어 특정 작업을 완벽하게 수행하는 것입니다.에이저 펑션스는 언제 사용해야 할까요?그렇다면 언제 함수를 사용하고언제 다른 기술을 사용해야 할까요?판단하기 위한 간단한 방법이 있습니다.해당 작업이 짧은지, 이벤트 기반인지,그리고 상태를 저장하지 않는지 자문해보세요.세 가지 모두에 예라고 답했다면 에이저 펑션스가 적합한 도구일 것입니다.우선 활용하기 좋은 사례부터 살펴보겠습니다. API와 웹북은 아주 완벽한 조합입니다. HTTP 요청에 응답하고 하나의 작업을 처리한 뒤결과를 반환하는 가벼운 엔드포인트가 필요하다면바로 그것이 HTTP 트리거의 용도입니다.파일 및 이미지 처리도 중요한 사례 중 하나입니다.파일이 저장소에 들어오면 함수가 실행되어파일을 변환하고 결과를 저장하며이 모든 과정을 서버 없이 수행합니다.매일 밤 정리 작업이나 보고서 생성 같은 예약된 작업은타이머 트리거로 아주 잘 작동합니다. ETL 파이프라인을 위한 데이터 변환 작업도 흔하게 사용됩니다.또한 함수는 서로 직접 통신하지 않는 두 서비스를 연결하는완벽한 통합 접착제 역할을 합니다.이제 함수가 적합하지 않은 경우에 대해 이야기해보겠습니다.소비 플랜, 컨섬션 플랜에서 함수는기본적으로 5분의 시간 제한이 있고구성에 따라 최대 10분까지 가능하므로장기 실행 프로세스는 문제가 됩니다.

작업 시간이 그보다 길다면 다른 대안이 필요합니다.상태 저장, 스테이트풀, 애플리케이션 또한 적합하지 않습니다.함수는 실행 사이에 아무것도 기억하지 못합니다.세션 상태를 유지하거나 단계별 진행 상황을 추적해야 한다면설계 위도와 맞지 않는 것입니다.무거운 컴퓨팅 작업도 적절하지 않습니다. CPU를 몇 분 또는 몇 시간 동안 지속적으로 사용해야 한다면가상 머신이나 컨테이너가 더 나은 선택입니다.한 작업이 다른 작업에 의존하는 복잡한 워크플로는듀러블 펑션스 나 로직 앱스로 처리하는 것이 좋습니다.여기 대안들에 대한 간략한 개요가 있습니다.에이저 로직 앱스는 서비스 연결을 위한노코드, 노코드, 옵션입니다.사용자 지정 코드를 작성할 필요가 없다면로직 앱스 위 시각적 디자이너로 작업을 수행할 수 있습니다.에이저 앱 서비스는 24시간 연중 우유로 실행되는전체 웹 애플리케이션을 위한 것입니다.항상 켜져 있어야 하는 완전한 웹사이트나 API가 필요하다면이 도구가 적합합니다.에이저 컨테이너 앱스는 런타임에 대한 제어권이 강화된컨테이너와 된 마이크로 서비스를 제공합니다.그리고 에이저 가상 머신은 필요에 따라 운영체제에 대한완전한 제어권을 제공합니다.여기에 간단한 경험 법칙이 있습니다.작업을 한 문장으로 설명할 수 있다면아마도 함수에 적합한 후보일 것입니다.이미지가 업로드되면 압축하십시오.누군가 가입하면 환영 이메일을 보내십시오.매일 자정의 정리 작업을 실행하십시오.한 문장, 한 작업, 한 함수입니다.피해야 할 초보자의 흔한 실수들입니다.이제 주의해야 할 몇 가지 사항에 대해 이야기해보겠습니다.이는 초보자들이 시작할 때 거의 누구나 범하는 실수들입니다.흔한 초보자의 실수는 함수가 항상 무료라고 생각하는 것입니다.무료 제공량이 넉넉해서 100만 번이 실행이 많게 느껴질 수 있지만함수가 입소문을 타거나 봇의 공격을 받으면실행 횟수는 금방 늘어납니다.

따라서 사용량을 모니터링하고 에이저에서 예산 알림을 설정하여월말의 뜻밖의 청구서를 받지 않도록 하십시오.또 다른 실수는 콜드 스타트, 콜드 스타츠를 무시하는 것입니다.유유 상태 후에 함수가 처음 실행될 때는 시간이 더 걸립니다.소비 플랜에서는 몇 초 정도 걸릴 수 있습니다.대부분의 사용 사례에서는 괜찮습니다.하지만 1mm가 중요한 지연 시간에 민감한 API를 구축 중이라면프리미엄 플랜을 고려하거나 항상 준비된 인스턴스Always Ready Instances를 활성화하십시오.그리고 너무 오래 실행되는 함수를 작성하는 문제가 있습니다.소비 플랜에는 기본 5분, 최대 10분의 시간 제한이 있습니다.함수가 파일을 처리하는데 15분이 걸리면 중간에 강제로 종료됩니다.작업을 더 작은 단위로 나누거나 다른 호스팅 플랜을 사용하세요.놓치기 쉬운 또 다른 실수는 패키지에서 실행, 배포를 사용하지 않는 것입니다.이것은 콜드 스타트를 개선하고 배포 안정성을 높이는 간단한 설정 변경입니다.개별 파일을 복사하는 대신 zip 패키지로 배포하게 됩니다.포털에서 체크박스 하나만 선택하면 됩니다.바로 하세요.인증 없이 HTTP 엔드포인트를 노출하는 것도 또 다른 함정입니다.테스트 중에 함수를 익명 상태로 두었다가 그대로 잠그는 것을 잊기 쉽습니다.처음부터 권한 부여 수준을 올바르게 설정하세요.함수 키나 관리자 키를 사용하세요.문을 열어두지 마세요.여러 함수 앱에서 스토리지 계정을 재사용하는 것도 문제입니다.개발 환경에서는 공유해도 괜찮습니다.운영 환경에서는 각 함수 앱마다 고유한 스토리지 계정을 사용해야 합니다.그렇지 않으면 한 함수의 트래픽이 다른 함수를 느리게 만드는 간섭 문제가 발생합니다.마지막으로 애플리케이션 인사이츠를 활성화하지 않는 것입니다.없으면 앞이 보이지 않는 것과 같습니다.실패, 오류 또는 성능 문제를 볼 수 없습니다.

첫날부터 활성화하세요. 30초면 되며 디버깅 시간을 몇 시간이나 절약해 줍니다.이 모든 것의 환급률은 함수를 잡고 집중적이며 상태비 저장으로 유지하는 것입니다.함수 하나당 작업하나 그 이상은 안 됩니다.그것이 바로 시스템입니다.에이저 펑션셋은 이벤트에 반응하여 작은 코드 조각을 실행하는 서버리스 컴퓨팅입니다.코드가 실행될 때만 비용을 지불합니다.트리거는 함수를 깨울 시점을 알려주고 바인딩은 필요한 데이터와 연결하며소비 플랜은 소규모 프로젝트에 거의 무료로 제공됩니다.지금 바로 에이저 포털에서 간단한 http 트리거 함수를 만드는 것이 가장 좋은 시작입니다. 5분이면 충분하며 비용도 들지 않습니다.마이크로소프트 날리지 너게츠를 구독하여 쉬운 설명을 더 확인하고서버리스가 무엇인지 계속 묻는 사람들에게 이 영상을 공유하세요.프라오