Kubernetes 관련 신규 블로그 시리즈의 다섯 번째이자 마지막 편에 오신 것을 환영합니다!
이번 시리즈에서는 Zadara 환경에서 Kubernetes를 배포하는 방법과, 이를 AWS 호환 클라우드 환경에서 컨테이너 기반 애플리케이션을 관리하는 데 어떻게 활용할 수 있는지 살펴보았습니다.
Kubernetes를 처음 접하는 분이든, 이미 경험이 풍부한 사용자이든 관계없이, 이번 시리즈를 통해 Zadara 클라우드에서 컨테이너 애플리케이션을 효과적으로 운영하기 위한 유용한 인사이트와 모범 사례를 얻으실 수 있을 것입니다. 앞으로도 더욱 흥미로운 콘텐츠를 기대해 주세요! 이번 블로그에서는 EKS-D(EKS Distro) 솔루션의 커스터마이징(Customization) 기능에 초점을 맞춰, 운영 환경(Production-Grade)의 Kubernetes 클러스터를 구축할 때 발생하는 다양한 고객 요구사항을 어떻게 충족할 수 있는지 살펴보겠습니다.
지금까지는 자동화된 배포 워크플로우에 내장된 기본값(Default Value)을 그대로 사용하여 Kubernetes를 배포해 왔습니다. 이러한 구성은 빠른 데모나 PoC(Proof of Concept) 수준의 환경에는 적합할 수 있지만, 실제 운영(Production) 환경에 적합한 구성이라고 보기는 어렵습니다. 가장 대표적인 예가 Control Plane 구성입니다. 기본 설정은 단일 노드(Single Node)로 배포되지만, 운영 환경에서는 일반적으로 고가용성(High Availability)을 위한 3노드 구성이 권장됩니다. 이 외에도 다양한 추가 커스터마이징이 필요할 수 있습니다. EKS-D 솔루션을 사용자 환경에 맞게 구성하기 위한 첫 번째 단계는 클러스터를 배포하는 통합 래퍼 스크립트인 `apply-all.sh`가 실제로 어떤 작업을 수행하는지 이해하는 것입니다.
이 래퍼 스크립트는 워크플로우 실행을 돕기 위해 몇 가지 기본 변수만 사용하지만, 내부적으로는 두 개의 Terraform 프로젝트가 사용됩니다. 하나는 필요한 인프라 구성을 담당하고, 다른 하나는 EKS-D 배포를 담당합니다. 이 두 Terraform 프로젝트는 다양한 사용 사례와 구성 방식을 지원하기 위해 수많은 변수를 제공합니다.
전체 변수 목록은 두 프로젝트의 변수 파일, 즉 infra와 eksd 프로젝트의 변수 파일에서 확인할 수 있습니다. 우선 여기서는 그중 몇 가지 주요 변수를 살펴보겠습니다.
Server의 NLB를 외부에 공개할지 여부를 제어합니다. 기본값은 true입니다.
VPC의 CIDR을 제어합니다. 기본값은 192.168.0.0/16입니다.
초기 Control Plane 노드 수를 제어합니다. 기본값은 1이며, 고가용성 Control Plane 구성을 위해서는 3으로 설정합니다.
초기 Data Plane 노드 외에 추가로 생성할 Data Plane 노드 수를 제어합니다. 이는 ASG의 최대 크기(max-size) 인자로 사용되며, 기본값은 3입니다.
EBS CSI에서 사용할 VolumeType을 지정합니다. 기본값은 gp2입니다.
Data Plane 인스턴스 타입을 지정합니다. 기본값은 z8.large입니다.
변수의 기본값을 변경하려면 해당 프로젝트의 variables.tf 파일 안에서 값을 변경하거나, 실행 전에 Terraform 기반 환경 변수로 값을 설정해야 합니다.
예를 들면 다음과 같습니다.
환경 변수를 사용하는 방식은 파일을 직접 수정하지 않고도 배포에 영향을 줄 수 있는 간단한 방법입니다. 다만 변경한 값을 프로젝트 내부에 영구적으로 반영하지 않은 상태에서, 나중에 해당 환경 변수 없이 배포를 다시 실행하면 원래 값으로 덮어써질 수 있습니다. 이 경우 배포에 부정적인 영향을 줄 수 있으므로, 일반적으로는 변수 파일을 직접 수정하는 방식이 권장됩니다. 사용자 정의 변수의 또 다른 활용 사례는 eksd-terraform 변수들을 통해 배포 시 선택적 Add-on 설치 여부를 제어하는 것입니다.
AWS EBS CSI Driver 설치 여부를 제어합니다. 기본값은 true입니다.
AWS Load Balancer Controller 설치 여부를 제어합니다. 기본값은 true입니다.
Cluster Autoscaler 설치 여부를 제어합니다. 기본값은 true입니다.
K10 설치 여부를 제어합니다. 기본값은 false입니다.
선택적 Add-on과 달리, EKS-D 배포 과정에서는 몇 가지 필수 Add-on도 암묵적으로 설치됩니다. 예를 들어 Kubernetes용 AWS Cloud Provider 역할을 하는 CCM(Cloud Controller Manager), 그리고 EKS-D에 포함된 필수 구성 요소인 CoreDNS와 kube-proxy가 이에 해당합니다.
일부 Add-on은 EKS-D 이미지를 수정하여 제어할 수 있습니다. 이 부분은 뒤에서 더 자세히 다룹니다. 하지만 일부 구성 요소는 cloud-init 스크립트에 대한 더 깊은 수준의 변경이 필요할 수 있습니다.
마지막으로, 선택 사항은 아니지만 Terraform을 통해 관리할 수 있는 Add-on이 하나 더 있습니다. 바로 CNI(Container Network Interface)입니다. CNI는 Kubernetes의 전체 네트워킹 스택을 담당하는 핵심 구성 요소이므로, CNI 없이는 클러스터가 초기화되지 않습니다.
다만 cni_provider 변수를 사용하면 아래 지원 목록 중에서 EKS-D 클러스터에 사용할 CNI 구현체를 선택할 수 있습니다.
기본 CNI입니다. 빠르고 단순하며 안정적인 Layer 3 구현체입니다.
라우팅 및 보안 기능을 추가로 제공하는 고급 멀티레이어 CNI입니다. cilium 실험적으로 지원되는 CNI입니다. eBPF 기반의 고급 멀티레이어 CNI로, 향상된 라우팅, 보안, 관측성 기능을 제공합니다.
Cilium의 경우, Zadara는 테스트 절차상 필수 네트워킹 기능만 검증하기 때문에 실험적 지원으로 간주됩니다. 다만 배포 시 Hubble UI 관측성 기능도 함께 활성화되며, cilium CLI에서 해당 네임스페이스를 참조해 접근할 수 있습니다.
이 명령을 실행하면 hubble-ui 서비스가 로컬호스트로 포트 포워딩됩니다. 이를 통해 클러스터의 네트워크 트래픽 흐름을 모니터링할 수 있습니다.
기본값이 아닌 CNI를 사용하여 EKS-D를 배포하는 경우, 초기화 과정에서 추가적인 리소스와 패키지 다운로드가 필요할 수 있습니다. 따라서 클러스터 규모(Sizing)나 리소스 계획을 수립할 때 이러한 요소를 고려해야 합니다.
마지막으로, 이전 블로그에서 다루었던 외부 ETCD 백업 기능과 관련하여, Control Plane의 로컬 백업을 외부 Object Storage로 내보내려면 아래 변수들을 사용하는 것을 권장합니다.
backup_access_key_id 및 backup_secret_access_key
backup_region
us-east-1backup_endpoint
backup_bucket
backup_rotation
100이러한 설정을 통해 Kubernetes Control Plane의 ETCD 백업을 외부 Object Storage에 안전하게 보관할 수 있으며, 장애 발생 시 복구를 위한 백업 데이터를 중앙화하여 관리할 수 있습니다.
경우에 따라 사용자는 래퍼 스크립트를 사용하는 대신 워크플로우를 직접 실행하고자 할 수 있습니다. 또는 배포 프로젝트를 다양한 방식으로 수정해야 할 수도 있습니다. 이러한 경우 워크플로우는 아래의 두 가지 주요 단계로 나눌 수 있습니다.
첫 번째 단계는 인프라 배포(Infrastructure Deployment) 입니다. 이 단계에서는 EKS-D 배포에 필요한 사전 구성 요소들을 처리합니다. 예를 들어 Kubernetes 클러스터가 생성될 VPC와 서브넷 구성이 여기에 해당합니다. 문서에 안내된 절차에 따라 infra-terraform 프로젝트 또는 이를 변형한 구성을 실행할 수 있습니다. 다만 두 번째 Terraform 실행이 완료된 후에도 NLB IP를 별도로 확인해야 합니다. NLB IP는 zCompute 콘솔을 통해 수동으로 확인할 수도 있고, Terraform 출력값에 명시된 파라미터를 사용하여 get_loadbalancer.sh 스크립트를 실행해 확인할 수도 있습니다.
`infra-terraform` 프로젝트를 사용하지 않고 자체 인프라 토폴로지를 사용하려는 경우도 있을 수 있습니다. 예를 들어 수동으로 구성하거나, zCompute의 VPC Wizard를 사용하거나, 다른 클라우드 자동화 도구를 통해 인프라를 구성하는 경우입니다. 이 경우에는 아래 요구사항을 유의해야 합니다.
모든 Private Subnet과 Public Subnet은 AWS CCM/LBC가 이를 검색하고 사용할 수 있도록 AWS 문서 기준에 맞게 태그가 지정되어야 합니다. 이때 Private Subnet과 Public Subnet에 적용되는 태그가 서로 다르다는 점에 유의해야 합니다.
EKS-D API Server의 엔드포인트로는 외부 공개형 NLB 또는 내부용 NLB를 사용할 수 있습니다. Load Balancer를 사용하지 않으려는 경우에는 이를 생략할 수도 있습니다. 다만 EKS-D 배포 단계에서는 최소한 Load Balancer 또는 Master 인스턴스의 Private IP를 제공해야 하며, 경우에 따라 Public IP도 함께 제공해야 할 수 있습니다.
두 번째 단계는 EKS-D 배포(EKS-D Deployment) 입니다. 이 단계에서는 Control Plane 노드와 Data Plane 노드를 모두 실행하며, Control Plane VM을 EKS-D API Server의 NLB에 연결하는 작업도 포함됩니다.
문서에 안내된 절차에 따라 `eksd-terraform` 프로젝트 또는 이를 변형한 구성을 실행할 수 있습니다. 다만 Terraform 실행이 완료된 후에도 초기 `kubeconfig` 파일은 별도로 가져와야 합니다. 이 파일은 Master 노드 중 하나에서 수동으로 가져올 수도 있고, Terraform 출력값에 명시된 파라미터를 사용하여 `get_kubeconfig.sh` 스크립트를 실행해 가져올 수도 있습니다.
스크립트를 사용하지 않고 kubeconfig 파일을 수동으로 가져오려는 경우, 일반적인 인프라 토폴로지에서는 Control Plane VM에 접근하기 위해 Bastion VM을 거쳐야 합니다.
각 Master VM 내부에서는 다음 경로에서 해당 파일을 확인할 수 있습니다. /etc/kubernetes/zadara/kubeconfig 참고로 Kubernetes 1.29 이상에서는 사용자가 일반 admin 사용자가 아니라 super-admin으로 설정됩니다.
eksd-terraform 프로젝트를 사용하지 않고 EKS-D 클러스터를 직접 배포하려는 경우도 있을 수 있습니다. 예를 들어 수동으로 배포하거나, 다른 클라우드 자동화 도구를 통해 배포하는 경우입니다.
이 경우에는 아래 요구사항을 유의해야 합니다. 모든 VM에는 CCM이 해당 VM의 상태를 추적할 수 있도록 다음 형식의 태그가 지정되어야 합니다. kubernetes.io/cluster/<kubernetes-name> 해당 키에는 owned 값이 설정되어야 합니다. 수동 배포의 참고 예시는 별도의 수동 배포 가이드를 참조할 수 있으며, 추가로 필요한 Add-on 커스터마이징 항목도 함께 확인할 수 있습니다.
Zadara는 클라우드 Marketplace에서 여러 개의 사전 구성된 EKS-D 이미지를 제공하지만, 사용자는 다양한 이유로 자신만의 사용자 정의 이미지를 사용하고자 할 수 있습니다.
예를 들어 Zadara가 제공하지 않는 특정 EKS-D 버전, 가령 1.27 버전을 사용하고 싶을 수 있습니다. 또는 일부 Add-on을 수정하고 싶을 수도 있습니다. 예를 들어 모든 구성 요소를 항상 최신 버전으로 사용하지 않도록 조정하는 경우입니다. 그 외에도 보안 강화를 위해 기본 OS 이미지를 하드닝해야 하는 경우도 있을 수 있습니다.
이러한 커스터마이징은 BYOI(Bring Your Own Image) 방식으로 가능합니다. 사용자는 EKS-D Packer 프로젝트 가이드라인을 따라 이미지를 새로운 AMI로 빌드한 뒤, EKS-D 배포 시 해당 사용자 정의 AMI를 지정할 수 있습니다.
실제로 Zadara 역시 Marketplace에 제공하는 자체 EKS-D 이미지를 생성할 때 동일한 Packer 프로젝트를 사용합니다. 따라서 이 프로젝트는 항상 최신 상태로 유지됩니다.
이 프로젝트는 다음과 같은 단계로 구성됩니다.
기본적으로 모든 유틸리티와 Add-on은 최신 릴리스 버전으로 설치됩니다. 이 동작은 프로젝트 내의 Bash 스크립트 파일을 수정하여 변경할 수 있습니다.
Packer 프로젝트를 사용해 자체 이미지를 빌드하는 경우, 아래 가이드라인에 따라 `.auto.pkvars.hvl` 파라미터 파일을 작성해야 합니다.
Zadara는 보안 및 컴플라이언스 관점에서 EKS-D 이미지를 최신 Ubuntu 22.04 기반으로 구성할 것을 권장합니다. 해당 이미지는 zCompute Marketplace에서 사용할 수 있습니다. Zadara가 제공하는 사전 구성 이미지도 동일한 방식을 따르기 때문에, Packer 프로젝트 내 기존 스크립트 대부분은 Debian 계열 기준으로 작성되어 있습니다. 예를 들어 `apt`를 사용하는 방식이며, `yum` 기반 배포판과는 차이가 있습니다. 따라서 이러한 OS 계열을 사용할 경우 큰 수정 없이 사용할 수 있습니다. 실제 AMI ID는 zCompute 콘솔의 Images 패널에서 확인할 수 있습니다.
또한 Packer가 중간 VM을 생성하는 데 사용할 Debian 기반 Bastion VM을 제공해야 합니다. 예를 들어 Zadara Toolbox 또는 일반 Ubuntu VM을 사용할 수 있습니다. 이 VM에 접근할 수 있도록 라우팅 테이블과 보안 그룹 설정을 확인해야 하며, SSH 접속을 위해 22번 포트가 허용되어 있어야 합니다.
마지막으로 Packer의 중간 VM이 사용할 기존 Subnet ID를 제공해야 합니다. Bastion VM이 해당 Subnet에 접근할 수 있도록 라우팅 테이블을 확인해야 합니다. 일반적으로는 Bastion VM과 동일한 Subnet을 사용하는 것이 가장 좋습니다.
이러한 변수 파일의 예시는 아래와 같습니다.
이 예제에서는 Elastic IP(즉, Bastion VM의 Public IP)가 할당된 기존 Fedora 기반 Zadara Toolbox VM을 사용하여 데모 클라우드 환경에서 EKS-D 이미지를 빌드하고 있습니다.
빌드 과정에서는 계정의 기본 VPC와 Public Subnet에 위치한 Ubuntu 22.04 AMI를 사용합니다. 이때 Subnet의 AWS ID가 필요하다는 점에 유의해야 합니다.
가장 중요한 부분은 이번 빌드에서 EKS-D 1.29 Release 3 버전을 사용하도록 지정했다는 점입니다. 해당 버전 정보는 EKS-D GitHub 저장소에서 확인할 수 있습니다.
다만 이 GitHub 페이지는 항상 최신 릴리스 정보를 반영하므로, 향후 버전이 추가되면 현재 표시되는 내용이 변경될 수 있습니다.
`packer build .` 명령으로 이미지 빌드 프로세스를 시작하기 전에, 로컬 AWS 프로파일이 해당 zCompute 클라우드의 AWS CLI 자격 증명(Credentials)을 사용하도록 설정되어 있어야 합니다. 아래 예시에서는 이를 위해 임시(Ad-hoc) 환경 변수를 사용하고 있습니다. 즉, Packer가 zCompute 환경에 접근하여 VM을 생성하고 AMI를 빌드할 수 있도록, 올바른 AWS Access Key와 Secret Key가 설정된 AWS 프로파일을 참조해야 합니다. 예시에서는 환경 변수를 통해 해당 자격 증명을 지정한 후 Packer 빌드를 수행하는 방식을 보여줍니다.
적용한 변경 사항의 규모, 네트워크 대역폭, 그리고 VM 크기(기본값은 `z8.large`)에 따라 차이가 있을 수 있지만, 이미지 베이킹(Baking) 과정은 일반적으로 약 15~30분 정도 소요됩니다. 빌드가 완료되면 새로운 사용자 정의 AMI가 생성됩니다. 즉, Packer는 지정된 EKS-D 버전과 사용자 정의 설정을 기반으로 새로운 머신 이미지를 생성하며, 이후 해당 AMI를 사용하여 원하는 Kubernetes 클러스터를 배포할 수 있습니다.
빌드가 완료되면 생성된 새로운 AMI는 zCompute 콘솔의 Images 패널에서 확인하고 사용할 수 있습니다. 즉, Packer를 통해 생성한 사용자 정의 EKS-D 이미지는 일반적인 AMI와 동일하게 zCompute 환경에 등록되며, 이후 클러스터 배포 시 해당 AMI를 선택하여 사용할 수 있습니다. 이를 통해 조직의 요구사항에 맞게 커스터마이징된 EKS-D 환경을 반복적이고 일관된 방식으로 배포할 수 있습니다.
운영 환경(Production-grade) 수준의 배포에서 매우 중요한 요소가 하나 있습니다. 하지만 이는 현재 배포 스크립트에서 다루지 않는 부분입니다. 바로 Zadara 클라우드 내에서 신규 VM에 대한 배치 규칙(Placement Rules)*을 설정하는 기능입니다. 이를 Kubernetes의 Anti-Affinity 규칙과 유사한 개념으로 생각할 수 있습니다. 특정 태그가 지정된 VM들이 서로 다른 인프라 노드에 배치되도록 클라우드 레벨의 규칙을 생성할 수 있으며, 이는 AWS의 Placement Group과 비슷한 역할을 수행합니다. 다만 Zadara와 같은 Edge Cloud 환경에서는 약간의 차이가 있습니다.
AWS Placement Group이 가용 영역(Availability Zone) 내의 배치 방식을 제어하는 반면, Zadara의 Placement Rule은 실제 하부 물리 서버(Physical Node) 수준에서 VM 배치를 제어합니다. Control Plane VM과 같은 핵심 인스턴스들이 동일한 물리 노드에 함께 배치되는 상황을 방지하기 위해서는 이러한 기능이 매우 중요합니다. 만약 해당 물리 노드에 장애가 발생하면 여러 핵심 VM이 동시에 영향을 받을 수 있기 때문입니다. 따라서 미션 크리티컬(Mission-Critical) 워크로드의 경우, 클라우드의 내장 스케줄러가 사용자의 요구사항에 따라 VM을 배치하도록 별도의 전용 Placement Rule을 생성하는 것이 일반적으로 권장됩니다.
이러한 규칙은 다음 두 가지 방식으로 설정할 수 있습니다.
이를 통해 Kubernetes Control Plane과 같은 중요 구성 요소의 고가용성을 더욱 강화할 수 있습니다.
이 예제에서는 Soft Rule을 생성하여, Zadara 클라우드가 내 `k8s` 클러스터의 각 Control Plane VM을 서로 다른 인프라 노드에 배치하도록 설정했습니다. 즉, 클라우드 스케줄러에게 “가능한 한 각 Master 노드를 서로 다른 물리 서버에 배치하라”는 정책을 적용한 것입니다. Soft Rule이기 때문에 클라우드는 해당 규칙을 우선적으로 준수하려고 시도하지만, 인프라 자원이 부족하거나 다른 제약 조건이 있는 경우에는 예외적으로 동일한 물리 노드에 배치할 수도 있습니다. 이러한 방식은 Kubernetes Control Plane의 가용성을 향상시키면서도, 클러스터 생성이 불필요하게 실패하는 상황을 방지할 수 있는 현실적인 운영 방법입니다.
Kubernetes 클러스터를 배포하기 전에도 기존에 존재하는 태그를 사용할 수 있었고, 필요하다면 새로운 태그를 직접 생성할 수도 있었습니다.
다만 여기서 사용된 특정 태그는 모든 신규 Control Plane VM에 대해 자동으로 생성됩니다. 이 태그는 다음과 같은 규칙을 따릅니다.
즉, 클러스터 이름을 기준으로 해당 VM이 어떤 Kubernetes 클러스터에 속하는지 식별하고, 값(Value)을 통해 해당 VM이 Control Plane 노드인지 Data Plane 노드인지 구분하게 됩니다.
이러한 자동 생성 태그를 활용하면 Placement Rule을 보다 쉽게 구성할 수 있으며, 특정 Kubernetes 클러스터의 Control Plane 노드들만 대상으로 배치 정책을 적용할 수 있습니다.
참고로 여기서는 Hard Rule이 아닌 Soft Rule을 사용했습니다. 어떤 방식을 사용할지는 전적으로 사용 사례에 따라 결정할 수 있습니다. 개인적으로는 일반적인 클라우드 환경에서 수년간 운영 워크로드를 운영해 온 경험상 Hard Rule을 선호합니다. Hard Rule은 문제가 발생했을 때 빠르게 실패(Fail Fast)하고 즉시 문제를 수정할 수 있게 해주기 때문입니다. 하지만 Edge Cloud 환경에서는 상황이 다를 수 있습니다. 예를 들어 해당 클라우드가 소수의 대형 인프라 노드만으로 구성되어 있다면, Hard Rule 때문에 Master 노드를 생성하지 못하는 상황이 발생할 수 있습니다. 이러한 문제는 초기 생성 시점에 발생할 수도 있고 이후에 발생할 수도 있습니다. 또한 최종 사용자는 클라우드 내부의 물리 인프라 노드나 그 용량을 직접 확인할 수 없기 때문에, Hard Rule은 일부 상황에서는 양날의 검이 될 수 있습니다. 특히 규모가 작은 Edge Cloud 환경에서는 더욱 그렇습니다. 이러한 점을 고려하더라도, Placement Rule은 Kubernetes Control Plane VM과 같은 민감한 운영 환경 워크로드를 위한 중요한 보호 계층입니다. 다만 규칙을 생성할 때는 반드시 클러스터 수준의 태그(Cluster-Level Tag)를 기준으로 사용해야 합니다. 그렇지 않으면 동일한 규칙이 환경 내 모든 Kubernetes 클러스터의 Master 노드에 적용될 수 있습니다.
이번 블로그에서는 EKS-D 솔루션에 포함된 다양한 커스터마이징 기법과, 솔루션 내부 기능은 아니지만 Zadara 클라우드에서 운영 환경 수준의 Kubernetes 클러스터를 구축하는 데 관련된 한 가지 추가 기법을 살펴보았습니다. 항상 더 많은 지식과 깊은 이해를 쌓을 여지는 존재합니다. 하지만 이번 블로그와 Kubernetes 시리즈 전체를 통해 Zadara 클라우드에서 Kubernetes를 얼마나 쉽게 운영할 수 있는지 이해하는 데 도움이 되었기를 바랍니다. 앞으로도 더 많은 콘텐츠와 팁, 그리고 활용 방법을 확인하시려면 Zadara Examples GitHub 저장소를 계속 지켜봐 주시기 바랍니다.
운영 환경의 Kubernetes는 단순히 클러스터를 배포하는 것에서 끝나지 않습니다. 고가용성(HA), 네트워크 구성, 백업 정책, 보안 강화, VM 배치 전략(Placement Rule) 등 다양한 운영 요소가 함께 고려되어야 비로소 엔터프라이즈 수준의 플랫폼이 완성됩니다. Zadara EKS-D는 Terraform 기반 자동화, BYOI(Bring Your Own Image), 다양한 CNI 선택, Object Storage 기반 ETCD 백업, 그리고 Edge Cloud 환경에 최적화된 Placement Rule 기능을 통해 고객이 요구하는 수준의 유연성과 운영 통제권을 제공합니다. 특히 Sovereign Cloud와 Edge Cloud 수요가 증가하는 국내 시장에서는 단순한 Kubernetes 서비스보다 데이터 주권과 인프라 제어권을 확보할 수 있는 플랫폼 선택이 점점 더 중요해지고 있습니다. Zadara는 이러한 요구사항을 충족하면서도 AWS 호환성을 유지할 수 있는 현실적인 대안이 될 수 있습니다.
