클라우드 컴퓨팅 - FaaS, 서버리스(Serverless) 컴퓨팅

사용자 관점에서 서버 관리가 필요없는 It 인프라 아키텍처

서버 단에서 로직이나 상태를 관리하지 않고 특정 이벤트에 반응하는 함수가 실행되는 구조

 

[개념]  백엔드 서버의 구축, 운영, 관리는 클라우드에 맡기고, 기업은 비즈니스 로직 개발에만 집중하는 것

 

 

[개념] 클라우드 컴퓨팅 환경에서 손쉬운 소프트 웨어의 개발 및 배포를 지원하는 강력하고 새로운 클라우드 컴 퓨팅 패러다임

마이크로 서비스 아키텍처(Micsroservice Architecture)를 클라우드 환경에 구현한 것

 

[설계] 구현 및 배치, 실행 등 독립적인 구성이 가능한 단위로 작게 나누고, 그들 사이의 상호작용을 통 해 하나의 시스템처럼 동작하도록 설계

 

[서비스 단위] 서비스 단위는 프 로그래밍 언어로 구현이 가능한 함수(Function)의 형태로 구현 하는 것이 일반적이며, 이를 서비스 함수(Service Function)이 라 부른다.

 

[배포] 서비스 함수는 서비스의 상태를 갖지 않는 비 상태성 (Stateless)으로 이벤트 트리거(Event Trigger)를 기반으로 구현 되어, 클라우드 환경에 배포된다.

 

[서비스 제공] 클라우드 환경에 배포 된 서비스 함수들은 API 단위의 호출 및 응답을 통해 서비스를 제공한다

 

[기대효과] 서버 구축 및 관리 포인트를 제거함으 로써 서비스의 비즈니스 로직 개발에만 집중할 수 있어 개발 기 간과 비용을 단축시킨다. 또한 기존 클라우드 기반의 서비스 환 경보다 서비스 배포 및 관리가 용이하여 서버리스 기술에 대한 수요가 증가하고 있다.

 

김동민, 손재기. (2020). 서버리스 컴퓨팅 기술 동향. 한국통신학회지(정보와통신), 37(8), 39-45.

 

API 게이트웨이(API Gateway, 혹은 API Router)는 서비스 함수를 이용하려는 사용자 와 서버리스 서비스 간의 인터페이스 역할을 담당한다.

① 사용자(또는 클라이언트)는 사용하려는 서비스 함수 호출을 위한 정보를 API 게이트웨이로 전달한다.

② 호출 정보를 전달받은 API 게이트웨이는 클라우드 환경에 배포된 서비스 함수를 호출하고, 응답 결과를 기다린다.

③ 서비스 함수는 사용자로부터 전달받은 정보를 기반으로 기 능을 수행하고, 그 결과를 API 게이트웨이로 전달한다. 이 때, 서비스 함수는 필요에 따라 저장소를 이용하여 데이터 를 저장할 수도 있다.

④ API 게이트웨이는 서비스 함수로부터 전달받은 응답 결과 를 사용자에게 전달한다.

⑤ 사용자는 API 게이트웨이로부터 전달받은 응답 결과를 확인한다.

 

[장점]

•서버 관리 감소: 클라우드 서비스 제공자에 의해 제공받은 물리적인 환경을 이용하므로, 직접적인 서버 관리를 하지 않 아도 된다.

•운영비용 절감: 레거시 클라우드의 서비스와 같이 일정 기간 의 임대 비용을 과금하는 체계가 아닌, 실제 사용한 자원량 에 따른 비용이 과금되기 때문에 레거시 클라우드 서비스보 다 운영비용이 훨씬 절감된다.

•확장성: 자동화된 자원관리 도구에 의해 필요에 따라 컴퓨 팅 자원의 확장 및 축소되는 스케일 아웃 기능을 지원하므 로 서버리스 컴퓨팅은 언제나 민첩한 비즈니스 환경 변화 를 만족시킨다.

•패키징 및 배포 과정 용이: 서버리스 컴퓨팅에서 구동되는 서비스 함수들은 서버리스 운영환경에 최적화 및 규격화된 컨테이너에 패키징되어 배포된다. 이는 실제 개발하려는 비 즈니스 로직 개발에만 집중할 수 있게 하여 서비스 개발 시 간을 단축할 수 있다.

 

[단점]

비즈니스 로 직의 개발 환경과 실제 운영환경의 차이, 테스트 및 디버깅의 복 잡성, 그리고 서버리스 컴퓨팅을 위한 표준의 부재 등 일부 단점 도 있어, 조건 없는 서버리스 컴퓨팅 환경의 도입은 바람직하지 않으며, 도입 전 충분한 검토가 필요하다.

[해외 서비스]

1. AWS Lambda

2. Cloud Functions

3. Azure Functions

다른 서버리스 컴퓨팅 서비스와 달리 서비스의 상 태를 저장할 수 있는 기능인 ‘Durable Functions’을 제공하여 서비스 내부의 상태 및 검사점을 관리하여 서비스 오류시 발생 할 수 있는 문제를 해결하는 기능을 제공한다.

 

 

 

 

[서버리스 프레임워크 기술 개념도]

 

일반적인 클라우드 컴퓨팅 환경에서 상시 자원과 물리적 공간을 점유하는 비효율성을 개선하기 위해 요청이 있을 때만 필요한 해당 코드를 밀리초(ms) 단위로 실행하고, 요청이 많은 경우 그에 비례하는 자원을 할당하여 동시에 처리하는 방법으로 서버리스 서비스 플랫폼의 개념이 도입

 

다중호출 구조에서 서버리스 서비스 플랫폼의 성능저하 문제를 해결하기 위한 방법으로 사용자 요청 및 입력 데이터 처리를 위해 API 단위 응용들의 조합에 관한 프레임워크 구조를 설계

 

기술의 상세내용

- API 단위 처리를 위한 서버리스 아키텍처 설계 및 구조

- Kubernates와 gRPC를 결합한 성능 저하 없는 API 단위 응용 조합 방법

- Apache Kafka 등 이벤트 브로커 플러그인 구조 및 프로토타입

- API 단위 요청을 서비스 모듈과 연계하는 라우팅 코어

- API 요청의 상황에 따른 로드 분배기술 설계 및 코어

- API 요청의 Fast On-Demand Start를 위한 컨테이너 풀 구조 설계

- 동기/비동기 실행 구조 설계 및 코어 - OAuth2 기반의 인증 기능 설계

- API 단위 세부 권한 설정을 위한 OwnerShip 및 실행권한 설정 코어 설계

 

 

https://www.itfind.or.kr/publication/regular/weeklytrend/weekly/view.do?boardParam1=7928&boardParam2=7928

서버리스의 부상

캐노니컬의 베이커는 또한 기업들이 서버 프로비저닝에 대한 걱정 없이 애플리케이션을 구축하고 실행할 수 있는 서버리스 컴퓨팅의 인기가 2018년에도 지속될 것으로 전망했다.

 

그러나 그는 서버리스에 관심 있는 기업 고객에 대한 경고도 잊지 않았다.

 

“문제는 AWS 람다와 같은 외부 제품을 사용하면 기능을 빨리 개발할 수 있는 장점이 있지만 누구나 다 사용 준비가 된 것은 아니다. 무서버를 사용하려면 전혀 다른 사고 방식이 필요하다. 인프라 전체, 사실상 응용프로그램 자체를 제외한 모든 것을 외주 처리하는 것이나 마찬가지이기 때문이다”라고 그는 말했다.

 

쿠버네티스를 중심으로 한 통합

대담한 전망은 아닐지 모르지만 쿠버네티스(Kubernetes)는 기업 내 컨테이너 관리(orchestration) 경쟁에서 승리한 것으로 보인다. AWS가 마침내 이 오픈소스 기술을 지원하기로 11월 리인벤트(re:Invent) 회의에서 발표했기 때문이다. 이제 주요 퍼블릭 클라우드 업체는 모두 쿠버네티스를 완전히 지원한다.

 

지속적인 전달 및 컨테이너 기술에 의지하는 대기업이 늘어남에 따라 컨테이너 관리 플랫폼은 기업 클라우드 전략 내 주요 핵심으로 자리잡을 전망이다. 이에 따라 포레스터는 2018년에는 쿠버네티스 기술 인력과 시범 운영 투자할 것을 권장하면서 다음과 같이 적었다.

 

“먼저 컨테이너 관리 계획을 세워라. 무엇을 배워야 하고 누구를 교육시켜야 하며 개발 및 인프라 팀이 어떤 결과를 얻기 바라는지 파악하라.”

 

http://www.ciokorea.com/news/36806

서버리스의 부상, 쿠버네티스의 확산, AWS 약화 外··· 2018년 클라우드 트렌드 진단

서버레스 애플리케이션 취약점의 근본 이유 1

퓨어섹의 CTO인 오리 세갈(Ory Segal)은 “이번 연구 결과가 놀랍지는 않다”며 “애플리케이션 개발에 있어 보안이 완벽히 구현된 예는 찾기 힘들었다”고 말한다. “서버레스 아키텍처를 가진 애플리케이션은 ‘새로운’ 개념으로, 기존 애플리케이션 보안의 방법을 가지고는 이러한 새로운 애플리케이션들을 보호하기가 쉽지 않습니다.”

 

서버레스 애플리케이션 취약점의 근본 이유 2

서버레스 인프라, 즉 서버가 없는 인프라에서의 보안 및 안전 책임은 현재 누구에게 있을까? 즉 물리 보안, 네트워크 보안, 운영 시스템의 패치 등은 누가 해야 하는 걸까? 서버레스 인프라 제공업자에게 있는 것이 일반적이다. 애플리케이션의 소유주/개발자는 애플리케이션 자체의 로직, 코드, 데이터, 애플리케이션 층위의 환경설정에만 책임이 있다. 하지만 사고에 따라 이 둘을 명확하게 구분하기가 쉬운 게 아니라 보안 사고가 날 때 책임질 자를 결정하는 데에 혼선이 빚어질 수밖에 없다.

 

서버레스 애플리케이션 취약점의 근본 이유 3

또한 취약점이 발견되는 비율은 런타임 언어별로도 비슷했다. 즉 특정 런타임 언어에 따라 오류가 더 많이 나타나는 건 아니라는 것이다. 그렇다면 취약점이 발생하는 가장 큰 요인은 ‘인간적인 요소’가 된다. 다만 닷넷(DotNet) 런타임의 경우는 예외라고 퓨어섹은 강조한다. “닷넷의 경우는 취약점이 예외적으로 많이 발견됐습니다.”

 

서버레스 애플리케이션 취약점의 근본 이유 4

보안 업체 블랙덕의 기술 에반젤리스트인 팀 맥키(Tim Mackey)는 보안 전문 외신인 인포시큐리티(Info-Security)를 통해 “서버레스 아키텍처의 핵심 기능은 소비용 API를 구분하는 것”이라고 말한다. “API는 더 큰 애플리케이션에 통합될 목적으로 사용자에게 제공되는 기본 단위의 서비스입니다. 이런 API들을 용도에 따라 구분하는 것이 보안의 첫 단계여야 합니다.”

 

그는 그 말을 이렇게 풀어 설명한다. “예를 들면 보통의 사용자 애플리케이션의 경우, 사용자가 엉뚱한 값을 입력하지 못하도록 하는 장치를 가지고 있습니다. 즉 입력 값을 특정한 기준을 가지고 한 번 거른다는 건데, 이렇게 걸러진 데이터는 자유롭게 애플리케이션이 처리해 그 값을 최종 사용자에게 돌려줍니다. 내부에서의 이러한 데이터 처리 과정을 쪼개 API 서비스로 전환하는 것도 가능한데, 이러한 API를 리팩토링(refactoring) 하는 과정 중에 입력값을 최초로 거르게 하는 기준이나 규칙은 무시되는 것이 보통입니다.”

 

http://m.boannews.com/html/detail.html?idx=68262

서버레스 애플리케이션 및 API, 20%가 취약한 채 유통된다

NBP(Naver Business Platform)의 클라우드 서비스인 네이버 클라우드 플랫폼은 서버리스 컴퓨팅 상품 ‘Cloud Functions’ 등 신규 상품 2종을 출시했다고 2일 밝혔다.

 

‘서버리스(Serverless) 컴퓨팅’은 클라우드 컴퓨팅 실행 모델의 하나로, 클라우드 제공자가 동적으로 머신 자원의 할당을 관리하여 배치(deployed)된 서버리스 코드를 실행시키는 기술을 의미한다. 언제 어디서나 네트워크에 접근이 가능하며, 데이터 저장 및 다양한 기능을 제공해 시간과 비용을 효율적으로 관리할 수 있는 장점이 있다고 회사 측은 설명했다.

 

서버리스 컴퓨팅은 클라우드 시장에서 일어나고 있는 패러다임 전환이다. 컴퓨팅 단위의 클라우드 서비스에서 기능(Function) 단위의 서비스가 늘어나고 있는 것이다.

 

https://byline.network/2018/05/2-15/

네이버 클라우드 “람다, 나와!” …서버리스(Serverless) 컴퓨팅 서비스 개시 - Byline Network