[컴] 서버리스 컴퓨팅 하기 전 알아두면 좋은 점

서버리스 컴퓨팅 도입하기전에 확인해야 할 점 / 서버리스 장단점 / serverless computing

서버리스 컴퓨팅 하기 전 알아두면 좋은 점

서버리스 컴퓨팅 serverless computing[ref. 3]

• 특정 코드 조각을 실행할 때 필요한 컴퓨팅 리소스와 스토리지를 동적으로 할당
• 그만큼에 대해서만 요금을 부과
• 서버의 프로비저닝과 유지보수를 전적으로 제공 업체가 책임.
• 서비스 제공업체가 해주는 일
• 하드웨어 프로비저닝
• 가상 머신 및 컨테이너 관리
• 애플리케이션 코드에 자주 내장되는 멀티쓰레딩 같은 작업 등

서버리스를 사용하는 것이 유리한 작업

• 특정 상황에서 동시에 많은 이벤트 요청을 처리해야 하는 애플리케이션
• IoT 디바이스에서 제한된, 또는 간헐적인 인터넷 연결로 전송되는 데이터를 처리하는 애플리케이션
• 특정 종류의 배치 프로세싱

서버리스관련 프레임워크

• "서버리스 프레임워크"(이름이 서버리스)
• 지원되는 플랫폼:  AWS 람다, 애저 펑션, 구글 클라우드 펑션, IBM 오픈위스크
• 모든 플랫폼에서 동일한 경험을 제공
• 에이펙스(Apex)
• 특정 제공업체에서 원래 사용할 수 없는 몇몇 언어를 활용하는 데 도움

지원되는 언어

• AWS 람다
• Node.js
• 자바
• 고(Go language)
• C#
• 파이썬
• 애저 함수
• 자바스크립트
• C#
• F#

트리거

•  AWS 람다
• 가장 풍부, 그중 상당수는 AWS 플랫폼 전용
• 구글 클라우드 펑션
• 일반 HTTP 요청에 의해 트리거될 수 있다. 

테스트 방법

• AWS SAM(Serverless Application Model)
• 오프라인으로 람다 코드를 테스트할 수 있는 로컬 기능을 제공
• 서버리스(Serverless) 애플리케이션 프레임워크
• 로컬에서 코드 실행이 가능한 서버리스-오프라인(serverless -offline) 플러그인

물론 서버는 여전히 사용되지만 프로비저닝과 유지보수를 전적으로 제공 업체가 책임

원문보기:
http://www.ciokorea.com/news/125655#csidx9f3a9658ad9d50ca1e597a4b956498c

장점

• 비용
  • 높은 비용 효율성
    • 서버리스 컴퓨팅 아키텍처는 태생적으로 다른 접근 방법에 비해
    • 사용하지 않을 때는 비용도 없다
  • 소비에 대한 비용만 지불
    • 서버리스 기술에서 고객은 용량이 아닌 소비에 비용을 지불
    • 부가적인 인프라와 유지보수 없이 딱 필요한 작업에 대한 비용만 내는 것
    • 서버리스 컴퓨팅이 리소스의 과도한 할당과 관련된 비용을 줄인다.
  • uptime 비용없다 : 사용한 만큼 비용을 내므로 업타임 비용이 없다
• 애플리케이션이 클라우드 내에 빠르고 값싸게 배포하고 분산이 가능
  • 애플리케이션을 작은 용도별 기능으로 분할
• IT 워크로드를 경감
• 직원들이 서버 성능 관리, 안정성, 유지보수, 보안 업무 등에 상시 매달릴 필요가 없다
• 애플리케이션 업타임을 보장하기 위한 작업을 서버리스 플랫폼에서 해준다.
• 상태 확인을 구현
• 기반 OS를 관리
• 최신 보안 패치를 적용
• 인프라에 최대 워크로드를 감당하기에 충분한 용량이 프로비저닝되도록 확인하는 일 등
• 개발자의 부담도 덜어준다.
• 개발자는 인프라 관련 문제가 아닌 자신이 작성하는 코드의 비즈니스 목표에 집중
• 코드, 특히 인프라 코드를 덜 쓴다 --> 인프라 프로비저닝은 서버리스 기술에 맡기고 더 많은 개발자를 비즈니스 기능 구축에 투입 --> 개발 속도가 빨라진다. --> 조직은 민첩성과 혁신을 개선할 수 있다.
• 개발 주기의 속도가 빨라지고, –> 제품화 기간도 개선 –> 조직은 지속적인 개선과 고객 만족에 집중

단점

• 서버리스로 인해 오히려 워크로드가 늘어나는 경우도 있다.
  • 기능을 만들고 여러 API를 연결해 비즈니스가 요구하는 작업을 수행하는 데 더 많은 일이 필요하다
• 버그 잡기
  • 표준화된 보안, 테스트, 모니터링, 구성 관리가 없는 경우 서버리스에 버그가 퍼질 수 있다.
  • 각자가 알아서 만들면, 코드가 여러가지가 돼서, 관리가 어려워 지고, 버그가 생기면 일괄적으로 수정하기 어려울 수 있다.
• 장기간 지속되는 작업에는 적합하지 않다.
  • 계산에 오랜 시간이 걸리는 작업
  • 현재 애저 펑션(Azure Functions)과 AWS 람다(AWS Lambda)는 각각 최대 10분, 15분만 실행이 가능
• 콜드 스타트(cold start) 역시 서버리스의 단점.
  • 보통 수십 밀리초 정도
  • 대다수 사용 사례에서 무시해도 되는 시간
• 벤더 종속 : 주요 서버리스 시스템이 상호 호환되지 않는다
  • AWS 람다
  • 애저 펑션
  • 구글 클라우드 펑션
  • IBM 클라우드 펑션(IBM Cloud Functions) : 오픈소스 아파치 오픈위스크 플랫폼을 기반
• 보안 측면
  • 기본적으로 서버리스는 짧은 실행 시간과 기반 호스트 OS로부터의 격리로 인해 위험이 제한된다
  • 다른 리소스에 대한 액세스 권한을 획득하기 위한 공격에서 중간 단계로 서버리스 함수가 사용될 수도 있다
    • 함수가 너무 많은 권한을 갖거나
    • 취약한 구성요소를 포함
    • 서버리스를 안전하게 구성하고, 이후 이상 현상과 악용을 모니터링해야 한다
• 자동확장으로 인한 비용
  • 전통적인 서버는 용량이 초과하면 그냥 작동을 멈추므로 부가적인 비용이 발생할 일이 없다. 그러나 서버리스는 상대적으로 제한 없이 확장이 가능하므로 주의하지 않으면 상당한 비용으로 이어질 수 있다
• 인건비 상승
  • 기술에 초점을 둔 기업에서 경비가 많이 할당되는 분야 중 하나는 개발자 채용
  • 스킬을 갖춘 적격 개발자가 적어 고용하고 보유하려면 많은 비용이 든다

서버리스 도입시 주의점

• 구현에 앞서 충분한 시간 동안 서버리스 제품에 대해 알아봐야 한다
• 최소한 롤백 프로세스는 마련해 둬야 한다.
• 현재 시스템의 성능을 측정해서 계획 중인 서버리스와 비교해 가능한 운영 및 비용 상의 이점을 알아봐야 한다.
• 서버리스에 반드시 ‘올인’해야 할 필요는 없다. 필요에 따라 적게 사용할 수도, 많이 사용할 수도 있다

서버리스 도입시 여전히 고려해야 할 점

• 여전히 애플리케이션의 효율성에 중점을 두어야 한다.
  • 자원이 자동으로 할당된다.(애플리케이션의 요청에 의하거나, 서버리스 판단에 의해)
  • 만약 애플리케이션의 자원 요청이 언제 어떻게 이루어질지를 제대로 설계하지 않으면, 서버리스 시스템은 자원을 과잉 할당할 가능성이 크고, 결국 비용은 커지고 효율은 나빠질 것.
• 여전히 관리 지점을 구축
  • 애플리케이션 안으로 향하는 API를 설계해야 하고,
  • 모니터링을 위한 외부 관리 툴로의 데이터도 설계해야 한다는 의미
  • 장기적으로 잘 관리하기 위해선 이런 인터페이스가 있어야 한다.
• 설계 단계부터 보안이 필요
  • 설계와 계획이 없는 애플리케이션은 덜 안전한 애플리케이션이 된다.
  • 데이터 유출은 흔히 개발자의 실수와 설계에서 시작.

References

1. 준비되었는가? 서버리스 컴퓨팅을 둘러싼 모든 장점과 의사 결정 - ITWorld Korea, 2020.01.17
2. IDG 블로그 | 서버리스 시스템도 설계가 중요한 이유 - ITWorld Korea, 2019.10.23
3. '이유 있는 인기'··· 서버리스 컴퓨팅의 효용 - CIO Korea, 2019-07-08