서버리스 컴퓨팅이란 무엇인가?

서버리스 정의

서버리스 컴퓨팅은 클라우드 서비스 제공자가 관리하고 온디맨드 방식으로 사용할 수 있는 서버에서 개발자가 코드를 구축하고 실행할 수 있도록 지원하는 클라우드 컴퓨팅 모델입니다. 서버리스 컴퓨팅을 통해 개발자는 백엔드 인프라 관리에서 벗어나며 기업에는 확장 가능하고 유연한 환경이 제공됩니다. 서버리스 컴퓨팅을 사용하는 클라우드 서비스 제공자는 필요에 따라 스케일업 또는 스케일다운하여 수요를 충족하도록 인프라를 프로비저닝하고 일상적인 유지 관리, 업데이트, 패치워크 및 보안 모니터링을 수행하여 인프라를 관리합니다.

서버리스 컴퓨팅은 관련된 서버가 없다는 것을 의미하지 않습니다. 오히려 서버리스는 인프라 관리가 클라우드 서비스 제공자에게 아웃소싱되었음을 의미합니다. 이것이 서버리스 모니터링의 이점과 어려움입니다. 기업은 비즈니스 논리에 리소스를 집중할 수 있지만, 백엔드에서 발생하는 일에 대한 통제력과 가시성은 저하됩니다.

서버리스와 FaaS 비교

서비스형 함수(FaaS)는 프런트 엔드 코드 구축 및 실행에 집중하기 위해 백엔드 인프라 관리의 부하를 낮추는 컴퓨팅 서비스를 말합니다. 서버리스와 FaaS는 서로 호환되어 사용되는 경우가 많지만, 특히 FaaS는 개발자에게 제공하는 코드 실행 기능을 말합니다. 이벤트 중심 아키텍처인 FaaS는 서버리스의 하위 집합이며 서버리스가 제공하는 서비스 중 하나에 불과합니다.

서버리스 서비스에는 서버리스 스토리지 및 데이터베이스, 이벤트 스트리밍 및 메시징, API 게이트웨이도 포함됩니다.

서버리스와 BaaS 비교

서비스형 백엔드(BaaS)는 FaaS와 마찬가지로 서버리스의 하위 집합입니다. BaaS는 개발자들이 프런트 엔드에 집중할 수 있게 해주는 클라우드 컴퓨팅 모델입니다. BaaS는 사용자 인증, 푸시 알림, 클라우드 스토리지 및 데이터베이스 관리와 같은 일반적인 백엔드 작업을 위한 미리 만들어진 소프트웨어와 함께 제공됩니다.

서버리스는 FaaS 및 BaaS 양쪽 모두에서 작동합니다.

서버리스와 SaaS 비교

서비스형 소프트웨어(SaaS)는 공급자가 인터넷을 통해 사용할 수 있는 소프트웨어 애플리케이션의 라이센스를 부여하고 회사에 제공하는 컴퓨팅 서비스를 말합니다. 서버리스 컴퓨팅은 개발자들이 서버 관리에 대한 걱정 없이 애플리케이션을 구축하고 배포할 수 있도록 확장 가능하고 유연한 인프라를 제공합니다.

그렇다면, 서버리스 모니터링이란 무엇일까요?

서버리스 컴퓨팅의 이벤트 중심 아키텍처와 서드파티 인프라에도 전용 모니터링 솔루션이 필요합니다. 서버리스 모니터링 솔루션은 기업이 전체 운영에 대한 가시성을 확보하는 데 도움이 되며 서버리스 컴퓨팅 모델의 중요한 구성 요소입니다.

서버리스 아키텍처의 주요 구성 요소는 무엇인가요?

서버리스 아키텍처에는 기존의 인프라 모델과 차별화되는 몇 가지 핵심 구성 요소가 있습니다.

  • 클라우드 서비스 제공자의 역할은 다음과 같습니다.
    • 클라우드 서비스 제공자는 서버리스 환경의 핵심으로 인프라 관리를 담당합니다. 기존 아키텍처 컴퓨팅 모델에서 IT 팀은 일반적으로 서버를 실행하고 관리하는 시간과 노동 집약적인 작업을 수행해야 합니다. 서버리스의 경우 클라우드 서비스 제공자가 이러한 책임을 떠맡아 개발자의 자유를 보장합니다. 클라우드 서비스 제공자는 서버, 데이터베이스 및 스토리지를 프로비저닝합니다.
  • 이벤트 중심 프로그래밍:
    • 서버리스는 폴링이 아닌 이벤트에 의해 트리거됩니다. 서버리스 환경은 이벤트 중심 아키텍처(EDA)입니다. 이벤트는 사용자 엔드 요청과 같이 환경에서 발생하는 모든 상태 변경입니다. 이러한 이벤트는 개발자가 작업을 트리거하도록 프로그래밍한 함수를 호출합니다.
  • 트리거 기반 작업:
    • 서버리스는 이벤트에 의해 호출되는 함수에 의해 트리거될 때만 작업을 수행합니다. 따라서 서버리스는 필요한 리소스를 호출할 때만 사용합니다.
  • 비동기 프로그래밍:
    • 이벤트 중심 아키텍처와 서버리스의 상태 비저장(Stateless) 특성은 비동기 프로그래밍을 가능하게 합니다. 상태 비저장(Stateless)은 상호 작용 간에 데이터가 저장되지 않음을 의미합니다. 따라서 작업이 완료될 때까지 기다릴 필요 없이 한 번에 여러 작업을 수행할 수 있습니다. 비동기 프로그래밍의 가능성은 또한 개발자들이 새로운 코드를 작성하고 테스트할 때 유연성을 제공합니다. 배포 속도가 빨라집니다.
  • RESTful API:
    • 서버리스는 RESTful API를 사용하여 웹 서비스 간에 통신합니다. REST는 대표적인 상태 전송을 나타냅니다. API는 애플리케이션 프로그래밍 인터페이스입니다. 무상태(Stateless) 아키텍처 환경인 서버리스는 RESTful API를 사용하여 HTTP를 통해 요청한 사용자에게 클라이언트 엔드(백엔드) 리소스를 변환하거나 표시합니다.
  • DevOps(CI/CD):
    • 개발자는 서버리스를 통해 CI/CD로 DevOps에서 Ops를 제거할 수 있습니다. CI/CD는 애플리케이션 개발에 자동화를 도입합니다. CI는 지속적인 통합을 의미하며, CD는 지속적인 배포 또는 지속적인 제공을 의미합니다. 백엔드 모니터링을 클라우드 서비스 제공자에게 아웃소싱하면 개발자가 개발 파이프라인의 일부를 자동화하고 배포의 영향에 대해 걱정하는 시간을 줄일 수 있기 때문에 서버리스 환경을 통해 신속한 애플리케이션 개발에 집중할 수 있습니다.
  • 자동 확장:
    • 서버리스는 본질적으로 확장 가능합니다. 수요에 맞게 자동으로 스케일업 또는 스케일다운됩니다. 서버리스 환경은 함수가 호출될 때만 컨테이너를 스핀업하게 됩니다. 따라서 사용량 증가 또는 감소에 자동으로 대응합니다.
  • 자동화된 복구:
    • 서버리스 애플리케이션은 오류가 발생할 때 자동으로 식별하고 수정하도록 프로그래밍할 수 있습니다. 이러한 유형의 기능은 애플리케이션의 복원력을 향상시키고 가용성을 향상시킵니다.

서버리스 애플리케이션의 작동 방식

서버리스는 서비스형 백엔드(BaaS)와 서비스형 함수(FaaS)를 모두 사용하여 요청을 처리합니다. 전체 환경은 이벤트 중심이며, 이는 이벤트가 인증 또는 함수와 같은 응답을 트리거한다는 것을 의미합니다.

서버리스의 FaaS 부분은 사용자 요청 또는 이벤트와 함께 작동합니다. 요청은 API(애플리케이션 프로그래밍 인터페이스) 게이트웨이에서 처리된 다음 함수를 호출합니다. 이 함수는 데이터베이스와 통신합니다. 이 일련의 활동은 단일 애플리케이션 작업을 나타냅니다. 서버리스 환경에서는 작업이 별도의 함수로 프로그래밍되므로 애플리케이션이 모듈식입니다.

개발자는 컨테이너에 배포된 서버리스 애플리케이션 코드를 주문형으로 작성합니다. 클라우드 서비스 제공자는 실행 중인 서버에서 이 함수를 실행하거나 새 서버를 스핀업하여 이 함수를 실행합니다.

서버리스는 상태 비저장(Stateless)이므로 개발자에게 상당한 유연성을 제공하며, 이는 모든 호출이 독립적이라는 것을 의미합니다. 이전 상호작용의 데이터가 저장되지 않습니다. 서버리스는 필요한 리소스만 사용합니다. 함수가 더 이상 필요하지 않게 되면 코드가 배포된 컨테이너가 사라집니다. 이는 서버리스가 개발자에게 제공하는 유연성에 기여합니다.

서버리스 애플리케이션의 추가 고려 사항:

  • 콜드 스타트는 함수가 처음으로 호출되거나 일정 기간 동안 사용하지 않으면 발생할 수 있습니다. 이로 인해 대기 시간이 발생할 수 있습니다.
  • 클라우드 서비스 제공자는 동시에 실행할 수 있는 함수의 수를 결정합니다. 동시성 제한입니다.
  • 시간 초과는 클라우드 서비스 제공자가 함수를 종료하기 전에 해당 함수에 할당하는 시간을 나타냅니다.

서버리스 기술이 중요한 이유

서버리스 기술은 자동 확장을 지원하여 상당한 비즈니스 이점을 제공하고 개발자가 생산성을 높이고 애플리케이션을 보다 신속하게 제공할 수 있도록 하기 때문에 중요합니다. 이와 같이 비용 효율적인 기술입니다. 개발자가 운영보다는 프로덕션에 집중할 수 있도록 지원하며, 소비 기반 모델로서 물리적 서버의 실행 및 관리 비용을 절감합니다.

서버리스 기술은 10년 이상 존재해 왔습니다. 2014년, AWS는 첫 번째 FaaS인 AWS LAMBDA를 출시했습니다. Google에는 Google Cloud Functions이 있고 Microsoft에는 Azure Functions이 있습니다. 대부분의 기업이 클라우드 컴퓨팅에 의존하기 때문에 서버리스 기술은 비즈니스 운영과 동의어입니다. 따라서 클라우드 서비스 제공자의 역할이 비즈니스에 중요해짐에 따라 서버리스 기술도 중요해집니다.

서버리스 함수의 이점

서버리스 함수는 개발자와 고객 양쪽 모두에게 많은 이점을 제공합니다.

  • 비용 효율적: 클라우드 서비스 제공자는 서버리스를 소비 기반 모델로 제공하며 사용자가 사용하는 리소스와 함수에 대한 비용만 청구합니다. 서버리스의 상태 비저장(Stateless) 특성, 즉 컨테이너가 사용 중 상태가 아니면 사라지는 특성으로 인해 유휴 시간이 없습니다. 결과적으로 유휴 시간에 대한 비용을 지불하지 않습니다. 이로 인해 비용 효율성이 크게 향상됩니다.
  • 확장: 서버리스를 사용하면 이벤트 중심 아키텍처로 인해 필요에 따라 확장 및 축소할 수 있습니다. 더 많은 수요가 있는 경우 클라우드 서비스 제공자는 필요에 따라 더 많은 리소스를 스핀업하여 확장할 수 있도록 지원합니다. 고객이 성장에 집중할 수 있도록 이러한 리소스를 실행하고 관리합니다.
  • 오버헤드 감소: 서버리스 함수를 통해 클라우드 서비스 제공자는 인프라의 관리 및 모니터링을 담당합니다. 즉, 관리 비용과 인력을 클라우드 서비스 제공자에게 할당하고 리소스를 개발 및 배포에 재배포할 수 있습니다.
  • 성능 및 가용성: 이벤트 중심 환경인 서버리스는 불필요한 리소스를 사용하지 않기 때문에 성능을 향상시킵니다. 이는 또한 필요에 따라 리소스를 사용할 수 있음을 의미합니다. 클라우드 서비스 제공자를 사용하면 필요에 따라 서버와 컨테이너를 스핀업하여 필요에 따라 확장할 수 있으므로 서버나 스토리지 가용성에 대해 걱정할 필요가 없습니다.
  • 개발자 생산성: 클라우드 서비스 제공자가 DevOps의 운영 부분을 담당하기 때문에 개발자는 서버리스 함수의 이점을 누릴 수 있습니다. 이를 통해 개발자들은 코드 작성에 집중할 수 있습니다. 서버리스 환경은 개발 파이프라인에서 CI/CD 자동화를 지원하여 개발 민첩성과 생산성을 향상시킵니다.

서버리스 컴퓨팅의 어려움

비용 효율성과 개발 가속화의 분명한 이점에도 불구하고 서버리스 컴퓨팅에는 여러 가지 어려움이 있습니다. 서버리스 컴퓨팅의 단점은 다음과 같습니다.

  • 벤더 종속: 서버리스의 특성은 코드 배포를 위해 단일 클라우드 서비스 제공자를 사용한다는 것을 의미합니다. 결과적으로 개발자는 벤더가 제공하는 모델을 선택해야 합니다. 서비스 제공자는 동시성 제한과 같은 리소스 사용을 지시합니다. 이러한 이유로 인해 벤더에 종속되면 유연성이 부족해질 수 있습니다.
  • 코드 관점에서의 모니터링 및 디버깅: 클라우드 서비스 제공자가 인프라를 관리하기 때문에 운영의 백엔드를 거의 또는 전혀 파악할 수 없습니다. 따라서 전용 서버리스 모니터링 도구 없이 서버리스 환경을 모니터링하는 것은 매우 어렵습니다. 또한 서버리스 환경의 이벤트 중심 아키텍처는 버그를 식별, 다시 생성 및 수정하는 것이 어려울 수 있음을 의미합니다.
  • 대기 시간: 서버리스 환경에서 애플리케이션의 상태 비저장(Stateless) 특성으로 인해 대기 시간은 함수가 처음으로 호출되거나 오랫동안 사용되지 않은 후에 발생할 수 있습니다. 시간 초과로 인해 또는 너무 많은 함수가 동시에 실행되는 경우에도 대기 시간이 발생할 수 있습니다. 이 경우 서비스 제공자가 함수 중 하나를 삭제하여 오류가 발생할 수 있습니다. 사용자 측에서는 이로 인해 대기 시간이 발생합니다.
  • 제한된 사용자 정의 및 제어: 서버리스 서비스 제공자는 기본 인프라를 관리하므로 사용 가능한 런타임 버전, 메모리 할당 및 실행 시간 제한과 같은 사용자 정의 및 환경 제어에 제한이 있을 수 있습니다.
  • 보안 우려: 서버리스 컴퓨팅은 공격 대상을 줄이는 한편 새로운 보안 위험을 초래할 수 있습니다. 개발자는 서드파티 서비스, 함수 수준 권한 및 애플리케이션 코드의 취약성과 관련된 위험을 인식해야 합니다.
  • 상태 비저장성(Statelessness): 서버리스 함수는 상태 비저장(Stateless) 함수로, 호출 간에 데이터를 유지하지 않습니다. 이로 인해 애플리케이션 상태를 관리하기가 어려워질 수 있으므로 개발자는 상태를 유지하기 위해 외부 저장 공간 또는 데이터베이스에 의존해야 합니다.
  • 비용 예측 가능성: 서버리스 컴퓨팅은 비용 효율적일 수 있지만, 호출 횟수, 메모리 및 실행 시간과 같은 요인에 따라 비용을 예측하기가 어려울 수 있습니다. 예상치 못한 사용량 급증으로 인해 비용이 증가할 수 있습니다.
  • 기존 시스템과의 통합: 서버리스 함수를 기존 시스템 및 아키텍처와 통합하는 것은 특히 레거시 애플리케이션이나 복잡한 시스템을 다룰 때 어려울 수 있습니다.
  • 학습 곡선: 서버리스 컴퓨팅을 채택하려면, 개발자가 새로운 개념, 도구 및 모범 사례를 학습해야 하므로 개발 프로세스가 복잡해질 수 있습니다.

서버리스 컴퓨팅 사용 사례

확장성 및 관리 감소를 비롯한 서버리스 컴퓨팅의 이점은 여러 사용 사례에 적합합니다.

  • 웹 애플리케이션 개발: 서버리스 컴퓨팅은 개발자들이 빠르게 테스트할 수 있는 환경이기 때문에 웹 애플리케이션 개발에 적합합니다. 클라우드 서비스 제공자가 제공하는 소비 기반 모델은 웹 애플리케이션 개발이 서버리스에서 더 저렴하다는 것을 의미합니다. 사용하는 리소스에 대한 비용만 지불하고 인프라 관리에 시간이나 인력을 소비하지 않습니다. 이를 통해 개발자는 프런트 엔드에 집중할 수 있습니다. 데이터베이스, API 게이트웨이 및 이벤트 중심 아키텍처(EDA)와 같은 서버리스 서비스를 통해 개발자는 코드 작성만으로 웹 애플리케이션을 구축할 수 있습니다.
  • 데이터 처리 및 분석: 서버리스는 구조화된 텍스트, 오디오, 이미지 및 비디오 데이터와 잘 작동합니다. 서버리스를 사용하면 서로 다른 대규모 데이터 세트를 처리하고 분석할 수 있습니다. 기존 컴퓨팅 모델과 마찬가지로 서버리스 환경에는 다양한 데이터 세트가 분산되어 있습니다. 개발자는 애플리케이션을 작성하여 모든 비즈니스 채널에서 단일 데이터베이스로 데이터를 수집하고 처리할 수 있습니다. 서버리스 컴퓨팅은 필요한 워크로드를 처리하기 위해 수평적으로 확장할 수 있기 때문에 ETL(Extract, Transform, Load) 작업, 로그 분석 또는 데이터 검증과 같은 대용량 데이터를 처리하는 데 이상적입니다.
  • API와 마이크로서비스: 서버리스 함수를 사용하여 API 및 마이크로 서비스를 신속하게 구축하고 배포할 수 있으므로 개발자는 인프라 관리에 대한 걱정 없이 애플리케이션 로직을 작성하는 데 집중할 수 있습니다.
  • 실시간 파일 처리: 서버리스 함수는 클라우드 저장 공간 서비스에 업로드될 때 실시간으로 파일을 처리할 수 있어 이미지 크기 조정, 비디오 트랜스코딩 또는 텍스트 추출이 가능합니다.
  • 이벤트 중심 워크플로우: 서버리스 컴퓨팅은 데이터베이스 변경, IoT 장치 데이터 스트림 또는 메시지 큐의 메시지와 같은 특정 이벤트에 대응하는 이벤트 중심 워크플로우를 구축하는 데 사용할 수 있습니다.
  • 스케줄링된 작업 및 크론 작업: 서버리스 함수를 사용하여 야간 백업, 보고서 생성 또는 데이터 동기화와 같은 특정 간격으로 작업을 예약하고 실행할 수 있습니다.
  • 챗봇 및 가상 비서: 서버리스 함수를 사용하여 사용자 입력을 처리하고 응답하는 챗봇 또는 가상 비서를 생성하고 메시징 플랫폼 및 자연어 처리 서비스와 통합할 수 있습니다.
  • IoT 데이터 처리: 서버리스 컴퓨팅은 IoT 장치에서 생성된 데이터를 처리 및 분석할 수 있어 실시간 모니터링, 이상 징후 탐지 및 데이터 집계가 가능합니다.

Elastic을 통한 Observability 살펴보기

서버리스와 기존 아키텍처 비교

서버리스 아키텍처와 기존 아키텍처의 주요 차이점은 회사의 IT 팀이 물리적 서버를 실행하거나 관리하지 않는다는 점입니다. 이는 클라우드 서비스 제공자에게 오프로딩됩니다.

전통적으로, 기업은 베어메탈(BM) 서버를 사용하여 애플리케이션을 실행했습니다. 이를 위해서는 하드웨어를 조달하는 데 필요한 시간과 리소스와 하드웨어를 설치하고 전원을 공급하고 냉각하는 데 필요한 물리적 위치가 필요합니다. BM에는 랙 장착, 설치 및 하드웨어 구성이 필요합니다. 또한 IT 팀은 코드 배포를 위한 환경 구성, 운영 체제 설치, 서버 유지 관리 및 관리 등의 시간 소모적인 업무를 담당합니다.

BM 서버는 가상 머신(VM)으로 진화했습니다. 기업은 여전히 하드웨어를 설치하고 구성해야 하지만 여러 대의 컴퓨터가 동일한 하드웨어에서 실행될 수 있다는 점에서 이점을 누릴 수 있습니다. 이는 컴퓨팅 리소스가 더 잘 활용된다는 것을 의미합니다. 기술 팀은 하이퍼바이저를 통해 여러 대의 서버를 배포할 수 있으며, BM과 마찬가지로 운영 체제를 설치하고 유지 보수 및 관리를 보장해야 합니다. VM 템플릿 및 자동화 도구를 사용하여 운영 체제 설치가 자동화됩니다.

컨테이너는 VM에서 발전했습니다. 컨테이너는 애플리케이션을 특정 운영 환경에서 실행할 수 있게 해주는 코드 패키지로, 애플리케이션을 이동 가능하게 합니다. VM과 달리 컨테이너는 모두 동일한 운영 체제 및 컨테이너 런타임에서 실행되며 해당 컴퓨팅 리소스는 커널 사용자 공간에서 분할됩니다. 이를 통해 관리할 운영 체제의 수가 줄어들기 때문에 이러한 서비스의 관리가 크게 간소화됩니다. 컨테이너는 Kubernetes와 같은 플랫폼을 통해 자동화되어 컨테이너가 배포되는 곳에서 유연성을 제공하므로 필요할 때 쉽게 배치 및 폐기할 수 있습니다.

서버리스 아키텍처는 모든 인프라 관리를 클라우드 서비스 제공자에게 오프로딩했기 때문에 IT 팀이 코드 작성 및 배포에 집중할 수 있도록 지원합니다.

Elastic을 통한 서버리스 컴퓨팅의 미래

클라우드 기술이 계속 발전함에 따라 서버리스 컴퓨팅도 발전할 것입니다. 벤더들은 이미 범용 비즈니스 워크로드에 서버리스가 편리하도록 부품을 추가하여 서버리스 컴퓨팅을 개선하기 시작했습니다.

Elastic을 통한 서버리스 모니터링 살펴보기

서버리스 기술에 대한 FAQ

서버리스란 무엇인가요?

서버리스는 클라우드 서비스 제공자가 기본 인프라를 프로비저닝하고 관리하여 클라이언트가 프런트 엔드 개발에 집중할 수 있도록 하는 클라우드 컴퓨팅 모델입니다. 서버리스는 FaaS와 BaaS로 구성되어 있습니다. 두 서비스는 함께 작동하여 개발자가 코드를 신속하게 배포할 수 있는 유연한 환경을 제공합니다.

서버리스 컴퓨팅의 예는 무엇인가요?

엔드포인트의 사용자가 클라이언트의 웹사이트를 검색하고 있습니다. 이를 통해 두 가지 서버리스 함수인 BaaS 및 FaaS와 상호 작용합니다. 검색을 계속하려면 사용자가 정보를 입력합니다. 서버리스 환경의 BaaS 부분은 사용자 인증을 수행합니다. 사용자가 웹사이트를 계속 탐색하고 구매합니다. 이것은 이벤트입니다. 이 이벤트는 영수증 이메일을 보내는 함수를 호출하는 게이트웨이 API에 의해 처리됩니다. 이를 위해 클라우드 서비스 제공자는 애플리케이션 코드가 있는 컨테이너를 스핀업하여 작업을 수행합니다. 그것이 바로 FaaS입니다.

왜 서버리스라고 하나요?

서버리스는 클라우드 서비스 제공자가 클라이언트의 애플리케이션을 실행하는 데 필요한 서버를 프로비저닝하고 관리하는 클라우드 컴퓨팅 환경을 설명하는 잘못된 이름입니다. 클라이언트에는 서버가 없습니다. 클라우드 서비스 제공자의 서버를 사용하기 위해 클라우드 서비스 제공자에게 비용을 지불합니다.

서버리스 용어집

  • API 게이트웨이: 애플리케이션 프로그래밍 인터페이스(API) 게이트웨이는 요청을 읽고 백엔드 서비스로 라우팅하는 통신 링크입니다. 그런 다음 백엔드 데이터를 프런트 엔드의 사용자에게 변환합니다.
  • BaaS: 서비스형 백엔드(Backend-as-a-Service)는 구축된 소프트웨어를 사용하여 사용자 인증 또는 데이터 저장 공간과 같은 서비스를 제공하는 클라우드 컴퓨팅 모델입니다. 서버리스의 하위 집합입니다.
  • 클라우드 컴퓨팅: 클라우드 컴퓨팅은 클라우드 환경에 고유한 컴퓨팅 모델을 말합니다. 클라우드에서 발생하는 모든 유형의 컴퓨팅을 클라우드 컴퓨팅이라고 합니다.
  • 클라우드 네이티브: 클라우드 네이티브는 클라우드를 위해 특별히 구축된 모든 애플리케이션 또는 서비스를 말합니다. 클라우드 환경의 확장성과 복원력을 고려합니다.
  • 콜드 스타트: 콜드 스타트는 함수가 처음으로 호출되거나 일정 기간 동안 사용하지 않으면 발생할 수 있습니다. 클라우드 서비스 제공자가 함수를 수행하기 위해 컨테이너를 최초로 스핀업하는 것입니다.
  • 컨테이너: 컨테이너는 다양한 컴퓨팅 환경에서 일관성 있게 실행할 수 있도록 지원하는 경량 휴대용 셀프 서비스 코드 패키지입니다.
  • 이벤트 중심 아키텍처: 이벤트 중심 아키텍처는 이벤트(요청, 상태 변경, 업데이트)를 사용하여 서비스 간의 통신을 트리거하는 소프트웨어 아키텍처 모델입니다. 이벤트 중심은 프로그래밍 언어가 아닌 프로그래밍 접근 방식입니다.
  • FaaS: 서비스형 함수(Function-as-a-Service)는 이벤트 기반 클라우드 컴퓨팅 모델로, 개발자가 백엔드 인프라를 관리하지 않고도 프런트엔드를 구축하고 실행할 수 있도록 지원합니다.
  • 마이크로서비스: 마이크로서비스는 소프트웨어가 별도의 서비스로 분할되는 소프트웨어 아키텍처 모델의 한 유형입니다. 이러한 서비스는 API를 통해 통신하며 개발 유연성을 지원합니다.
  • 멀티클라우드: 멀티클라우드는 Google Cloud, AWS, Microsoft Azure와 같은 여러 클라우드를 말합니다. 대부분의 회사는 멀티 클라우드이며, 이는 여러 클라우드 서비스 제공자의 서비스를 동시에 사용한다는 것을 의미합니다. 예를 들어, 한 회사에서 이메일에는 Google Office 제품군을 사용하고 서버리스 함수에는 AWS Lambda를 사용합니다.
  • 상태 비저장(Stateless): 상태 비저장(Stateless)이란 운영을 독립적으로 처리하는 애플리케이션, 프로토콜 또는 프로세스의 컴퓨팅 특성을 말합니다. 예를 들어, 서버리스 컴퓨팅은 본질적으로 상태 비저장(Stateless)이며, 이는 호출 간에 데이터가 보관되지 않는다는 것을 의미합니다.