서버리스 함수 활용

물리적 컴퓨터 관리에서 클라우드 기능 활용에 이르기까지 다양한 측면에서 서버리스가 극단적인 환경에서 살아가고 있습니다. 사용자의 유일한 책임은 코드이며 코드가 실행된 경우에만 비용을 지불합니다. Azure Functions는 클라우드 네이티브 애플리케이션에 서버리스 기능을 빌드하는 방법을 제공합니다.

서버리스란?

서버리스는 클라우드 컴퓨팅의 비교적 새로운 서비스 모델입니다. 서버가 선택 사항인 것은 아닙니다. 코드는 여전히 어딘가에 있는 서버에서 실행됩니다. 차이점은 애플리케이션 팀이 더 이상 서버 인프라 관리와 관련이 없다는 것입니다. 대신 클라우드 공급업체는 이 책임을 맡습니다. 개발 팀은 배관이 아닌 고객에게 비즈니스 솔루션을 제공하여 생산성을 향상합니다.

서버리스 컴퓨팅은 이벤트 트리거 상태 비지정 컨테이너를 사용하여 서비스를 호스트합니다. 필요에 따라 수요를 충족하기 위해 규모를 확장할 수 있습니다. Azure Functions와 같은 서버리스 플랫폼은 큐, 이벤트 및 스토리지와 같은 다른 Azure 서비스와 긴밀하게 통합됩니다.

서버리스로 해결되는 과제는 무엇인가요?

서버리스 플랫폼은 많은 시간과 비용이 많이 드는 문제를 해결합니다.

• 컴퓨터 및 소프트웨어 라이선스 구매
• 컴퓨터 및 해당 네트워킹, 전원 및 A/C 요구 사항의 하우징, 보안, 구성 및 유지 관리
• 운영 체제 및 소프트웨어 패치 및 업그레이드
• 애플리케이션 소프트웨어를 호스트하도록 웹 서버 또는 컴퓨터 서비스 구성
• 플랫폼 내에서 애플리케이션 소프트웨어 구성

많은 회사에서 하드웨어 인프라 문제를 지원하기 위해 대규모 예산을 할당합니다. 클라우드로 이동하면 이러한 비용을 줄일 수 있습니다. 애플리케이션을 서버리스로 전환하면 애플리케이션을 제거하는 데 도움이 될 수 있습니다.

마이크로 서비스와 서버리스 함수의 차이점은 무엇인가요?

일반적으로 마이크로 서비스는 온라인 전자 상거래 사이트의 쇼핑 카트와 같은 비즈니스 기능을 캡슐화합니다. 사용자가 쇼핑 환경을 관리할 수 있도록 하는 여러 작업을 노출합니다. 그러나 함수는 이벤트에 대한 응답으로 단일 용도 작업을 실행하는 작은 경량 코드 블록입니다. 마이크로 서비스는 일반적으로 인터페이스에서 요청에 응답하도록 생성됩니다. 요청은 HTTP Rest 또는 gRPC 기반일 수 있습니다. 서버리스 서비스는 이벤트에 응답합니다. 이벤트 기반 아키텍처는 짧은 실행 백그라운드 작업을 처리하는 데 적합합니다.

서버리스에 적합한 시나리오는 무엇인가요?

서버리스는 트리거에 대한 응답으로 호출되는 개별 짧은 실행 함수를 노출합니다. 따라서 백그라운드 작업을 처리하는 데 적합합니다.

애플리케이션은 워크플로의 단계로 전자 메일을 보내야 할 수 있습니다. 마이크로 서비스 요청의 일부로 알림을 보내는 대신 메시지 세부 정보를 큐에 배치합니다. Azure Function은 메시지를 큐에서 제거하고 비동기적으로 이메일을 보낼 수 있습니다. 이렇게 하면 마이크로 서비스의 성능과 확장성이 향상될 수 있습니다. 메일 보내기와 관련된 병목 현상을 방지하기 위해 큐 기반 부하 평준화를 구현할 수 있습니다. 또한 이 독립 실행형 서비스는 여러 애플리케이션에서 유틸리티로 다시 사용할 수 있습니다.

큐 및 토픽의 비동기 메시징은 서버리스 함수를 트리거하는 일반적인 패턴입니다. 그러나 Azure Functions는 Azure Blob Storage 변경과 같은 다른 이벤트에 의해 트리거될 수 있습니다. 이미지 업로드를 지원하는 서비스에는 이미지 크기 최적화를 담당하는 Azure Function이 있을 수 있습니다. 함수는 Azure Blob Storage에 삽입할 때 직접 트리거되어 마이크로 서비스 운영에서 복잡성을 제거할 수 있습니다.

많은 서비스에는 워크플로의 일부로 장기 실행 프로세스가 있습니다. 이러한 작업은 종종 애플리케이션과 사용자의 상호 작용의 일부로 수행됩니다. 이러한 작업은 사용자가 대기하도록 강요하여 환경에 부정적인 영향을 미칠 수 있습니다. 서버리스 컴퓨팅은 사용자 상호 작용 루프 외부에서 느린 작업을 이동하는 좋은 방법을 제공합니다. 이러한 작업은 전체 애플리케이션의 크기를 조정할 필요 없이 수요에 따라 확장할 수 있습니다.

서버리스를 피해야 하는 경우는 언제인가요?

서버리스 솔루션은 주문형으로 프로비전 및 스케일링합니다. 새 인스턴스가 호출되면 콜드 시작이 일반적인 문제입니다. 콜드 스타트는 이 인스턴스를 준비하는 데 걸리는 시간입니다. 일반적으로 이 지연은 몇 초일 수 있지만 다양한 요인에 따라 더 길어질 수 있습니다. 프로비전된 단일 인스턴스는 주기적인 요청을 받는 한 활성 상태로 유지됩니다. 그러나 서비스가 덜 자주 호출되는 경우 Azure는 메모리에서 서비스를 제거하고 다시 호출할 때 콜드 스타트가 필요할 수 있습니다. 함수가 새 인스턴스로 확장되는 경우에도 콜드 시작이 필요합니다.

그림 3-9는 콜드 시작 패턴을 보여 줍니다. 앱이 콜드일 때 필요한 추가 단계를 확인합니다.

그림 3-9. 콜드 스타트와 따뜻한 시작.

콜드 스타트를 완전히 방지하려면 소비 계획에서 전용 플랜으로 전환할 수 있습니다. 프리미엄 플랜 업그레이드를 사용하여 하나 이상의 미리 준비된 인스턴스를 구성할 수도 있습니다. 이러한 경우, 다른 인스턴스를 추가해야 할 때 그 인스턴스는 이미 준비되어 작동할 준비가 되어 있습니다. 이러한 옵션은 서버리스 컴퓨팅과 관련된 콜드 시작 문제를 완화하는 데 도움이 될 수 있습니다.

클라우드 공급자는 컴퓨팅 실행 시간 및 사용된 메모리에 따라 서버리스 요금을 청구합니다. 장기 실행 작업 또는 높은 메모리 사용 워크로드가 항상 서버리스에 가장 적합한 것은 아닙니다. 서버리스 함수는 빠르게 완료할 수 있는 작은 작업 청크를 선호합니다. 대부분의 서버리스 플랫폼은 몇 분 내에 개별 함수를 완료해야 합니다. Azure Functions는 기본적으로 최대 10분까지 구성할 수 있는 5분 제한 시간으로 설정됩니다. Azure Functions 프리미엄 플랜은 이 문제를 완화할 수 있으며, 기본값은 제한 시간을 30분으로 설정하며, 제한 시간은 제한되지 않고 더 높은 제한으로 구성할 수 있습니다. 컴퓨팅 시간은 달력 시간이 아닙니다. Azure Durable Functions 프레임워크를 사용하는 고급 함수는 며칠 동안 실행을 일시 중지할 수 있습니다. 청구는 함수가 절전 모드에서 해제되고 처리를 다시 시작할 때 실제 실행 시간을 기반으로 합니다.

마지막으로 애플리케이션 작업에 Azure Functions를 활용하면 복잡성이 더해집니다. 모듈식 느슨하게 결합된 디자인으로 애플리케이션을 먼저 설계하는 것이 좋습니다. 그런 다음 서버리스가 추가 복잡성을 정당화하는 이점이 있는지 확인합니다.