클라우드에서 전체 용량으로 24/7 서버 팜을 운영할 경우 비용이 천정부지로 치솟을 수 있다. 필요 없을 때 용량의 대부분을 끌 수 있다면 어떨까? 이 아이디어를 논리적으로 한 단계 더 발전시켜 보자. 서버가 필요할 때만 불러와서 해당 부하를 처리하는 데 필요한 만큼의 용량만 제공할 수 있다면 어떨까?
그래서 등장한 것이 서버리스 컴퓨팅이다. 서버리스 컴퓨팅은 클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당한 다음 그 부분에 대해서만 비용을 청구하는 클라우드 실행 모델이다.
즉, 서버리스 컴퓨팅은 사용한 만큼만 비용을 내는 온디맨드 방식의 백엔드 컴퓨팅이다. 서버리스 엔드포인트로 요청이 오면 백엔드는 이미 해당 코드를 포함하고 있는 기존 “핫” 엔드포인트를 재사용하거나, 풀에서 리소스를 할당하고 맞춤 설정하거나, 새 엔드포인트를 인스턴스화하고 맞춤 설정한다. 일반적으로 인프라는 수신되는 요청을 처리하는 데 필요한 만큼의 인스턴스를 실행하며 냉각기가 지난 후 유휴 인스턴스를 해제한다.
물론 “서버리스”는 딱 맞는 용어가 아니다. 이 모델도 서버를 사용한다. 다만 사용자가 서버를 관리할 필요가 없을 뿐이다. 서버리스 코드를 실행하는 컨테이너 또는 기타 리소스는 일반적으로 클라우드에서 실행되지만 엣지 접속 포인트에서 실행될 수도 있다.
FaaS(Function as a service, 서비스형 함수)는 다양한 서버리스 아키텍처를 보여준다. FaaS에서는 사용자가 함수의 코드를 쓰면, 인프라가 런타임 환경을 제공하고 코드를 로드해서 실행하고 런타임 라이프사이클을 제어하는 작업을 담당한다. FaaS 모듈은 웹훅, HTTP 요청, 스트림, 스토리지 버킷, 데이터베이스 및 다른 구성 요소와 통합되어 서버리스 애플리케이션을 형성할 수 있다.
서버리스 컴퓨팅의 함정
서버리스 컴퓨팅은 매력적이고 서버리스로 전환해서 클라우드 비용을 60% 이상 줄인 사례도 있지만, 몇 가지 잠재적인 문제점도 있다. 가장 일반적인 문제는 콜드 스타트(cold start)다.
요청이 들어온 시점에 가용한 “핫” 엔드포인트가 없는 경우 인프라는 새 컨테이너를 인스턴스화해서 사용자의 코드를 사용해 초기화해야 한다. 인스턴스화에는 몇 초 정도가 소요될 수 있는데, 한자릿수 ms 단위의 응답이 당연시되는 서비스에서는 상당히 긴 시간이다. 이런 콜드 스타트는 피해야 하는 현상이다. 많은 서버리스 서비스가 체인으로 연결되고 모두 콜드 상태가 되는 경우, 지연 시간은 더욱 길어질 수 있다.
콜드 스타트를 피하는 방법에는 몇 가지가 있다. keep-alive 핑을 사용하는 방법이 있지만, 이는 사용되는 실행 시간을 늘리고 따라서 비용도 늘어나게 된다. 또 다른 방법은 서버리스 인프라에서 컨테이너보다 가벼운 아키텍처를 사용하는 것이다. 세 번째 방법은 연결이 완전히 설정될 때까지 기다리지 않고 클라이언트 요청이 엔드포인트와 보안 핸드셰이크를 시작하는 즉시 런타임 프로세스를 시작하는 것이다. 또한 컨테이너를 항상 “웜” 상태로 유지해서 클라우드의 확장 구성을 언제든 통과할 수 있도록 하는 방법도 있다.
서버리스에 영향을 미칠 수 있는 두 번째 문제는 쓰로틀링(Throttling)이다. 많은 서비스는 비용 억제를 위해 사용할 수 있는 서버리스 인스턴스의 수에 제한을 둔다. 트래픽이 많은 기간 동안 인스턴스의 수가 한도에 이르면 이후 추가로 수신되는 요청에 대한 응답이 지연되거나 실패할 수도 있다. 쓰로틀링 문제를 해결하기 위해서는 DoS 공격이나 시스템의 다른 부분에 존재하는 버그로 인한 통제되지 않는 사용을 차단하면서 정상적인 피크 사용량을 소화할 수 있도록 신중하게 한도를 조정해야 한다.
서버리스 아키텍처의 세 번째 문제는 스토리지 계층이 피크 트래픽을 처리하지 못할 수 있고, 사용 가능한 인스턴스가 풍부함에도 불구하고 실행 중인 서버리스 프로세스를 백업할 수 있다는 점이다. 이 문제의 한 가지 해결 방법은 피크 시점의 데이터를 흡수한 다음 데이터베이스가 디스크에 데이터를 커밋할 수 있게 되는 즉시 데이터베이스로 넘겨주는 메모리 상주 캐시 또는 큐를 사용하는 것이다.
모니터링 및 디버깅 툴의 부재는 이러한 모든 문제를 더 악화시키고 진단을 더욱 어렵게 한다. 업체 종속성(Vendor Lock-in)은 위험 목록에 포함하지 않았는데, 앞으로 살펴보겠지만 업체 종속성은 문제보다는 타협에 가깝다.
AWS 람다 및 관련 서비스
AWS 람다(Lambda)는 FaaS 상품이다. AWS 람다가 아마존의 유일한 서버리스 제품이라고 생각할 수 있지만 그렇지 않다. AWS 람다는 현재 10여 개에 이르는 AWS 서버리스 제품 중 하나다. 또한 AWS 람다(2014)가 최초의 FaaS 서비스라고 생각할 수도 있는데, 그 전에 짐키(Zimki, 2006)와 구글 앱 엔진(2008), 그리고 파이클라우드(PiCloud, 2010)가 있었다.
AWS 람다는 파이썬, Node.js, 루비, 자바, C#, 파워셸, 구글 고로 작성된 스테이트리스(stateless) 함수 코드를 지원한다. 람다 함수는 아마존 S3로의 객체 업로드, 아마존 SNS 알림, 또는 API 동작과 같은 이벤트에 반응해서 실행된다. 람다 함수는 자동으로 500MB의 임시 스크래치 디렉터리를 받으며, 영구 상태를 위해 아마존 S3, 아마존 다이나모DB(DynamoDB) 또는 다른 인터넷 스토리지 서비스를 사용할 수 있다. 람다 함수는 아마존 리눅스에서 지원되는 모든 언어를 사용해서 프로세스를 실행하고 라이브러리를 호출할 수 있다. 람다 함수는 모든 AWS 지역에서 실행 가능하다.
언급할 만한 그 외의 AWS 서버리스 제품도 있다. 람다@엣지(Lambda@Edge)는 아마존 클라우드프론트(CloudFront) CDN 이벤트에 대응해 200개 이상의 AWS 엣지 위치에서 람다 함수를 실행할 수 있게 해준다. 아마존 다이나모DB는 빠르고 유연한 키-값 및 문서 데이터베이스 서비스로, 대규모 환경에서 일관적인 한자릿수 ms 수준의 지연을 제공한다. 아마존 키네시스(Kinesis)는 AWS에서 데이터를 스트리밍하기 위한 플랫폼이다. AWS 그린그래스(Greengrass)로 로컬의 연결된 디바이스(예를 들어 IoT용 컨트롤러)에서 람다 함수를 실행할 수도 있다.
오픈소스 AWS SAM(AWS Serverless Application Model)은 서버리스 애플리케이션 및 서비스를 모델링하고 배포할 수 있다. AWS 람다는 SAM 외에 8개의 오픈소스 및 서드파티 프레임워크를 지원한다.
AWS 서버리스 애플리케이션 리포지토리(AWS Serverless Application Repository)는 다양한 사용례를 위한 서버리스 애플리케이션과 애플리케이션 구성요소를 찾아서 재사용할 수 있게 해준다. 아마존 클라우드워치(CloudWatch)를 사용해서 서버리스 애플리케이션을 모니터링하고 AWS 엑스레이(X-Ray)를 사용해 분석 및 디버깅할 수 있다. 마지막으로, AWS 람다는 최근 람다와 모니터링, 관찰, 보안 및 거버넌스 툴을 손쉽게 통합할 수 있는 새로운 방법인 람다 익스텐션(Lambda Extension) 프리뷰를 발표했다.
마이크로소프트 애저 펑션
마이크로소프트 애저 펑션(Microsoft Azure Functions) 역시 복잡한 오케스트레이션 문제를 해결할 수 있는 이벤트 기반의 서버리스 컴퓨팅 플랫폼이다. 클라우드에서 대규모로 설정, 배포, 운영할 필요 없이 로컬에서 애저 펑션을 구축하고 디버깅할 수 있으며, 트리거와 바인딩을 사용해서 서비스를 통합할 수 있다.
C#, F#, 자바, 자바스크립트(Node.js), 파워셸 또는 파이썬으로 애저 펑션을 코딩할 수 있다. 하나의 애저 펑션 앱에서 위 언어 중 하나만 사용할 수 있다. 비주얼 스튜디오, 비주얼 스튜디오 코드(아래 스크린샷 참조), 인텔리J, 이클립스 및 애저 펑션 코어 툴에서 로컬로 애저 펑션을 개발할 수 있다. 또는 애저 포털에서 작은 애저 펑션을 직접 편집하는 것도 가능하다.
듀어러블 펑션(Durable Functions)은 애저 펑션의 확장 프로그램으로, 서버리스 컴퓨팅 환경에서 스테이트풀(stateful) 함수를 쓸 수 있게 해준다. 듀어러블 펑션을 사용하면 애저 펑션 프로그래밍 모델을 사용해 개체 함수를 작성하는 방법으로 오케스트레이터 함수와 스테이트풀 개체를 써서 스테이트풀 워크플로우를 정의할 수 있다.
트리거는 함수의 실행을 유발한다. 트리거는 함수가 어떻게 호출되는지를 정의하며, 함수에는 정확히 하나의 트리거만 있어야 한다. 트리거에는 연결된 데이터가 있으며, 이 데이터는 보통 함수의 페이로드로 제공된다.
함수 바인딩은 함수에 다른 리소스를 선언적으로 연결하는 방법이다. 바인딩은 입력 바인딩, 출력 바인딩 또는 두 가지 모두로 연결될 수 있다. 바인딩에서 오는 데이터는 함수에 매개변수로 제공된다.
구글 클라우드 펑션
구글 클라우드 펑션(Google Cloud Functions)은 확장 가능한 종량제 FaaS 플랫폼이다. 모니터링, 로깅, 디버깅 기능을 통합했고 역할 및 함수 수준에서 보안을 내장했으며, 하이브리드 클라우드와 멀티클라우드 시나리오를 위한 주요 네트워킹 기능을 제공한다. 트리거를 통해 구글 클라우드 또는 서드파티 클라우드 서비스에 연결해서 까다로운 오케스트레이션 문제를 원활하게 해결할 수 있게 해준다.
구글 클라우드 펑션은 구글 고, 자바, Node.js(아래 스크린샷 참조), 파이썬 코드를 지원한다. 클라우드 펑션은 GET, PUT, POST, DELETE, OPTIONS와 같은 일반적인 HTTP 요청 방법을 사용한 HTTP 요청과 클라우드 인프라에서 이벤트를 처리하기 위한 백그라운드 함수를 지원한다. 클라우드 펑션의 자동 테스트 및 배포를 위해 클라우드 빌드(Cloud Build) 또는 다른 CI/CD 플랫폼을 깃허브(GitHub), 비트버킷(Bitbucket), 클라우드 소스 리포지토리(Cloud Source Repositories)와 같은 소스 코드 리포지토리와 함께 사용할 수 있다. 또한 로컬 시스템에서 클라우드 펑션을 개발하고 배포할 수도 있다.
IBM 클라우드 펑션
아파치 오픈위스크(OpenWhisk)를 기반으로 하는 IBM 클라우드 펑션(IBM Cloud Functions)은 필요에 따라 실행 및 확장되는 가벼운 코드를 개발하기 위한 다중 언어 지원 서비스형 함수 프로그래밍 플랫폼이다. Node.js, 파이썬, 스위프트, PHP로 IBM 클라우드 펑션을 개발할 수 있다. IBM이 자랑하는 부분은 이벤트 트리거 작업 워크플로우 내에서 클라우드 펑션과 왓슨 API가 통합되어 애플리케이션 데이터의 인지 분석을 서버리스 워크플로우의 일부로 만들 수 있다는 것이다.
오라클 클라우드 펑션과 Fn 프로젝트
오라클 클라우드 펑션(Oracle Cloud Functions)은 개발자가 인프라를 관리하지 않고도 애플리케이션을 생성, 실행, 확장할 수 있게 해주는 서버리스 플랫폼이다. 함수는 오라클 클라우드 인프라(Oracle Cloud Infrastructure), 플랫폼 서비스 및 SaaS 애플리케이션과 통합된다. 오라클 클라우드 펑션은 오픈소스 Fn 프로젝트를 기반으로 하므로 개발자는 다른 클라우드 및 온프레미스 환경에 이식 가능한 애플리케이션을 만들 수 있다. 오라클 클라우드 펑션은 파이썬, 고, 자바, 루비, Node.js로 된 코드를 지원한다.
클라우드플레어 워커스 (Cloudflare Workers)
클라우드플레어는 DDoS 공격으로부터 웹 사이트를 보호하는 것으로 잘 알려진 엣지 네트워크이다. 클라우드플레어 워커스로 서버리스 코드를 클라우드플레어의 글로벌 엣지 네트워크에 배치할 수 있는데, 컨테이너나 가상머신보다 부하가 훨씬 적은 V8 아이솔레이트(Isolate)에서 구동하는 것이 특징이다. 클라우드플레어 워커스는 자바스크립트, 러스트, C, C++, 파이썬, 코틀린으로 작성할 수 있다.
클라우드플레어 워커스는 다른 서버리스 프레임워크와 마찬가지로 콜드 스타트 문제가 없는데, V8 아이솔레이트는 기동하는 데 5ms면 충분하다. 여기에 더해 클라우드플레이어는 첫 TLS 해드셰이크에 대응해 클라우드플레어 워커스를 기동하기 때문에 실질적인 콜드 스타트 과부하를 완전히 배제해 대부분 경우 로드 시간이 사이트 지연보다 짧다.
서버리스 프레임워크 (Serverless Framework)
서버리스 프레임워크는 로컬에서 기능 코드를 생성해 최소한 부분적이라도 FaaS에서 업체 종속성을 피하는 방법 중 하나이다. 속을 들여다보면, 서버리스 프레임워크 CLI는 AWS 람다 같은 FaaS 플램폼이나 쿠버리스 또는 Knative 같은 쿠버네티스 기반 솔루션에 코드를 배치하며, 로컬에서 테스트를 진행할 수도 있다. 한편으로는 많은 서버리스 프레임워크 템플릿이 특정 클라우드 서비스 업체나 개발 언어 전용이다.
서버리스 컴포넌트(Serverless Component)는 웹사이트나 블로그, 결제 시스템, 이미지 서비스 같은 상위 사용례에 맞춰 만들어졌다. 플러그인은 맞춤형 자바스크립트 코드로, 서버리스 프레임워크 내에서 새로운 명령어를 생성하거나 기존 명령어를 확장한다.
서버리스 프레임워크 오픈소스(Serverless Framework Open Source)는 Node.js, 파이썬, 자바, 구글 고, C#, 루비, 스위프트, 코틀린, PHP, 스칼라 등을 지원한다. 프로 버전은 서버리스 애플리케이션의 전체 라이프사이클을 관리하는 데 필요한 CI/CD, 모니터링, 트러블슈팅 관련 툴을 제공한다.
아파치 오픈위스크 (Aphache OpenWhisk)
아파치 오픈위스크는 클라우드 애플리케이션 구축용 오픈소스 서버리스 플랫폼이다. 오픈위스크는 풍부한 프로그래밍 모델을 제공해 함수로부터 서버리스 API를 생성하고 서버리스 워크플로우 안으로 함수를 구성하고 규칙과 트리거를 사용해 이벤트를 함수에 연결한다.
오픈위스크 소프트웨어 스택은 로컬에서 실행하거나 쿠버네티스 클러스터에 배치할 수도 있는데, 자체 환경은 물론, 퍼블릭 클라우스 서비스 업체의 매니지드 쿠버네티스 클라우드를 모두 지원한다. 또한 IBM 클라우드처럼 오픈위스크는 온전하게 지원하는 클라우드 서비스 업체를 이용할 수도 있다. 오픈위스크는 현재 발레리나, 구글 고, 자바, 자바스크립트, PHP, 파이썬, 루비, 러스트, 스위프트, 닷넷 코어로 작성한 코드를 지원하며, 자체 도커 컨테이너를 제공할 수도 있다.
오픈위스크 프로젝트에는 다양한 개발 툴이 포함되어 있다. 대표적인 것으로는 오픈위스크 개체를 쉽게 생성하고 실행하고 관리할 수 있는 wsk CLI, 오픈위스크 패키지와 액션, 트리너, 룰, API를 단일 명령어로 배치하고 관리할 수 있는 wskdeploy, 오픈위스크 REST API 등이 있다.
피션 (Fission)
피션은 쿠버네티스용 오픈소스 서버리스 프레임워크로, 개발자 생산성과 고성능에 중점을 두고 있다. 피션은 단지 코드만으로 운영한다. 도커와 쿠버네티스는 일반적인 운영 하에서 추상화되며, 필요한 때는 피션을 확장할 수 있다.
피션은 어떤 언어로도 확장할 수 있다. 핵심은 고우로 작성되었지만, 개발언어에 특화된 부분은 환경으로 격리되어 있다. 피션은 현재 리눅스 실행파일은 물론, Node.js, 파이썬, 루비, 구글 고, PHP, 배시의 함수를 지원한다. 피션은 가동중인 컨테이너의 풀을 유지하는데, 각 컨테이너에는 작은 동적 로더가 있다. 함수가 호출되면, 현재 가동 중인 컨테이너가 선택되어 해당 함수가 로드되는 방식이다. 피션의 빠른 속도는 바로 이 풀 덕분으로, 콜드 스타트 지연은 보통 100ms 정도이다.
Knative
구글이 만든 Knative에는 50곳 이상의 서로 다른 업체가 참여하고 있는데, 쿠버네티스 상에서 서버리스 애플리케이션을 구축하고 실행하는 핵심 구성요소를 제공한다. Knative의 구성 요소는 컨테이너 배치나 라우팅, 블루/그린 배치를 통한 트래픽 관리, 수요에 따른 자동적인 확장과 규모 산정, 구동 중인 서비스와 이벤트 생태계와의 연결 등 일상적이면서도 까다로운 작업에 중점을 두고 있다. 구글 클라우드 런(Google Cloud Run)이 Knative를 기반으로 구축된 서비스이다.
쿠버리스 (Kubeless)
쿠버리스는 오픈소스 쿠버네티스 네이티브 서버리스 프레임워크로로, 쿠버네티스 클러스터 상에 배치해 쿠버네티스 고유의 이점을 이용할 수 있도록 만들어졌다. 쿠버리스는 AWS의 람다나 애저 펑션, 구글 클라우드 펑션의 기능성 다수를 복제한다. 쿠버리스 함수는 Node.js, 파이썬, 루비, 고랭, PHP, 닷넷, 발레리나로 작성할 수 있으며, 이벤트 트리거로는 카프카 메시징 시스템과 HTTP 이벤트를 사용한다.
쿠버리스는 쿠버네티스 CRD(Kubernetes Custom Resource Definition)을 사용해 함수를 맞춤형 쿠버네티스 자원으로 생성할 수 있다. 이후 이 함수로 클러스터 내의 컨트롤러를 실행한다. 컨트롤러는 맞춤형 자원을 감시하고 요청에 따라 런타임을 실행한다. 컨트롤러는 사용자의 함수 코드를 동적으로 런타임에 투입하며, 이를 HTTP를 통해 이용할 수 있다.
OpenFaaS
OpenFaaS는 “서버리스 함수를 단순하게 만든다”는 기치를 내건 쿠버네티스용 오픈소스 서버리스 프레임워크이다. OpenFaaS는 클라우드 네이티브 기술의 이른바 ‘PLONK 스택의 한 부분이다. PLONK는 프로메테우스(모니터링 시스템과 시계열 데이터베이스), 링커드(Linkerd, 서비스 메시), OpenFaaS, NATS(보안 메시징 및 스트리밍), 쿠버네티스이다. OpenFaaS는 템플릿 스토어와 도커파일(Dockerfile)을 사용해 이벤트 중심 함수와 마이크로서비스를 쿠버네티스에 배치할 수 있다.
클라우드 서버리스 플랫폼을 선택하는 방법
이 모든 선택지에서 어떻게 하나를 고를 것인가? 거의 모든 소프트웨어 아키텍처에 대한 질문이 그렇듯이, 그때그때 다르다.
처음 시작할 때는 기존 소프트웨어 자산과 목표를 먼저 평가해야 한다. 코볼로 작성한 레거시 애플리케이션을 내부 메인프레임에서 구동하는 조직과 상당한 클라우드 소프트웨어 자산을 가진 조직은 아주 다른 경로로 가야 한다. 클라우드 자산이 많은 조직이라면, 배치 환경과 사용 중인 클라우드, 가용 지역의 목록을 만드는 것도 유용하다. 고객과 사용자의 위치, 서비스의 사용 패턴을 파악하는 것도 좋다.
예를 들어, 24/7 일정한 수주의 부하를 사용하는 애플리케이션은 서버리스 배치에 맞는 후보가 아니다. 적절한 규모의 서버나 VM, 컨테이너 클러스터가 더 저렴하고 관리하기도 쉽다. 한편으로, 불규칙한 주기에 사용 규모도 차이가 크고 중요한 동작으로 트리거되는 애플리케이션이라면, 서버리스 아키텍처에 가장 알맞은 후보가 될 것이다. 또 저지연 요구사항이 있고 전세계에서 사용하는 서비스라면, 가용 지역이나 엣지 POP가 많은 배치의 좋은 후보가 될 수 있다.
쿠버네티스 경험이 있는 기업이라면, 쿠버네티스를 배치하는 오픈소스 서버리스 플랫폼 중 하나를 고려할 수도 있다. 쿠버네티스 경험이 없는 기업은 네이티브 클라우드 FaaS 인프라에 배치하는 것이 낫다. 서버리스 프레임워크나 AWS 람다, 애저 펑션 등 오픈소스 여부는 중요하지 않다.
만약 구축 중인 서버리스 애플리케이션이 클라우드 데이터베이스나 스트리밍 서비스에 의존한다면, 내부 애플리케이션 간의 지연을 최소화하기 위해 동일한 클라우드에 배치하는 방안을 고려해야 한다. 그렇다고 프레임워크 선택 범위를 지나치게 제한하지는 않을 것이다. 예를 들어, 구글 클라우드 빅테이블 데이터 저장소를 이용하는 애플리케이션이라면, 지연을 최소화하면서도 구글 클라우드 펑션, 구글 클라우드 런뿐만 아니라 서버리스 프레임워크, 오픈위스크, 쿠버리스, OpenFaaS, 피션, Knative를 사용할 수 있다.
많은 기업의 애플리케이션이 공통적인 사용례와 같거나 비슷하다. 따라서 서버리스 플랫폼용 예제와 라이브러리도 확인할 만한 가치가 있다. 안성맞춤의 레퍼런스 아키텍처를 찾을 수도 있기 때문이다. 대부분 FaaS가 코드를 많이 작성할 것을 요구하지는 않는다. 그보다는 FaaS용 코드를 재사용하는 것이 잘 테스트하고 검증된 아키텍처의 이점도 살리고 디버깅의 수고도 피할 수 있는 방안이 될 것이다.
출처
'DevOps. > 네트워크, 보안' 카테고리의 다른 글
| 가볍고 빠른 리눅스 가상화 툴, '도커(Docker)' 따라잡기 (1) | 2023.05.08 |
|---|---|
| 도커와 도커 컨테이너의 이해 | 기업 IT 아키텍처의 심장 (1) | 2023.05.08 |
| AWS, 한국어 고객 및 기술 지원 서비스 공식 지원 (1) | 2023.05.01 |
| 서버리스 클라우드 비용 관리하기 | 7가지 체크포인트 (0) | 2023.04.27 |
| 네트워크에 침입자가 있을 때 취해야 할 조치 (0) | 2023.04.11 |
| 전력 소비량이 적은 블루투스 규격 '블루투스 LE(BLE)' (0) | 2023.04.04 |
| '망 중립성(Net Neutrality)'이란, 기본 개념과 역사 (0) | 2023.03.27 |
| '멀티테넌시 (Multitenancy)'란 | 멀티테넌시의 기본 개념과 장단점 (0) | 2023.03.20 |
