에지/베어메탈 시스템 및 서버를 자동으로 프로비저닝 및 구성하기 위한 권장사항

Last reviewed 2024-07-31 UTC

이 문서에서는 다음과 같이 환경 에지에서 실행되는 기기의 안정적인 자동 프로비저닝 및 구성 프로세스를 설계하고 구현하기 위한 권장사항을 제공합니다.

에지 기기, 베어메탈 시스템, 서버의 프로비저닝 및 구성 프로세스를 설계하거나 이러한 기기 유형의 프로비저닝 및 구성을 위한 권장사항을 자세히 알아보려면 이 문서를 읽어보세요.

이 문서에는 에지 및 베어메탈 시스템 및 서버를 프로비저닝 및 구성하는 데 사용할 수 있는 모든 권장사항이 나열되어 있지 않으며 성공을 보장하지 않습니다. 대신 프로비저닝 및 구성 프로세스의 잠재적 변경사항과 개선사항에 대한 토론을 촉진하는 데 도움이 됩니다.

이 문서는 Google Cloud의 IoT 아키텍처에 대한 정보를 제공하는 문서 시리즈의 일부입니다. 이 시리즈의 다른 문서에는 다음이 포함됩니다.

대규모 기기를 수동으로 프로비저닝하고 구성하면 사용자 오류가 발생하기 쉬우며 사용자 그룹의 성장에 따라 확장되지 않습니다. 예를 들어 중요 프로비저닝 또는 구성 작업을 실행하는 것을 잊거나, 부분적으로 또는 완전히 문서화되지 않은 프로세스에 의존하고 있을 수 있습니다. 완전 자동화되고 안정적인 프로비저닝 및 구성 프로세스를 통해 이러한 문제를 해결할 수 있습니다. 또한 제조업체에서 해제, 폐기에 이르기까지 각 기기의 수명 주기를 관리하는 데 도움이 됩니다.

용어

다음 용어는 기기에 자동 프로비저닝 및 구성 프로세스를 구현하고 빌드하는 방법을 이해하는 데 중요합니다.

  • 에지 기기: 처리하려는 데이터에 가까운 환경 에지에 배포하는 기기입니다.
  • 프로비저닝 프로세스: 기기 구성을 준비하기 위해 완료해야 하는 일련의 작업입니다.
  • 구성 프로세스: 특정 환경에서 작동할 준비가 된 기기를 만들기 위해 완료해야 하는 일련의 작업입니다.
  • 구성 관리: 환경 및 기기의 구성을 관리하기 위해 지속적으로 수행하는 태스크 집합입니다.
  • 기본 이미지: 회사에서 생성했거나 기기 또는 OS 제조업체에서 생성한 최소 작동 운영체제(OS) 또는 펌웨어 이미지입니다.
  • 골든 이미지: 기기용으로 만들거나 기본 이미지에서 준비하는 변경할 수 없는 OS 또는 펌웨어 이미지입니다. 골든 이미지에는 기기에서 할당된 작업을 수행하는 데 필요한 모든 데이터와 구성 정보가 포함됩니다. 다양한 골든 이미지를 준비하여 다양한 작업을 수행할 수 있습니다. 골든 이미지 유형의 동의어로는 flavor, spin, archetype이 있습니다.
  • 실버 이미지: 골든 이미지 또는 기본 이미지에 최소한의 변경사항을 적용하여 기기를 위해 준비하는 OS 또는 펌웨어 이미지입니다. 실버 이미지를 실행하는 기기는 해당 기기가 지원해야 하는 사용 사례에 따라 처음 부팅 시 프로비저닝 및 구성을 완료합니다.
  • 시드 기기: 외부 종속 항목 없이 환경을 부트스트랩하는 기기입니다.
  • 네트워크 부팅: 기기가 해당 기기에 연결된 스토리지 시스템 대신 네트워크에서 소프트웨어 및 관련 구성 정보를 가져올 수 있도록 하는 일련의 기술입니다.

목표를 설정하고 일반적인 문제를 방지하려면 다음 섹션에 설명된 프로비저닝 및 구성 권장사항을 적용하세요.

프로비저닝 및 구성 프로세스 자동화

처음 부팅하는 동안 또는 필요할 때마다 기기는 내부에 설치된 소프트웨어 이미지만 사용하여 기기를 프로비저닝하고 구성할 수 있어야 합니다.

프로비저닝 및 구성 프로세스 중에 필요한 로직이 구현되지 않도록 하려면 해당 프로세스를 조정하고 구현하는 데 필요한 기본 요소를 제공하는 도구를 사용할 수 있습니다. 예를 들어, 로컬 호스트에 대해 실행되는 Ansible, Puppet 또는 Chef와 같은 구성 관리 도구 또는 스크립팅과 함께 cloud-init 및 해당 NoCloud 데이터 소스를 사용할 수 있습니다.

안정적인 프로비저닝 및 구성 프로세스를 설계하려면 이러한 프로세스 중에 수행되는 모든 단계와 태스크가 자동화된 방식에서 유효한지 확인합니다. 예를 들어 InSpec과 같은 자동화된 규정 준수 테스트 프레임워크를 사용하여 프로비저닝 및 구성 프로세스가 예상대로 작동하는지 확인할 수 있습니다.

이 권장사항을 따르면 기기 프로비저닝 및 구성을 완료해야 할 때 단일 장애점과 수동 개입의 필요성을 없애는 데 도움이 됩니다.

특수 목적 기기 피하기

에지 기기를 설계할 때는 목적 및 특수성 측면에서 편차를 최소화하세요. 이 권장사항은 모든 에지 기기가 서로 같거나 동일한 목적을 공유해야 한다는 것을 의미하지는 않지만 가능한 동일해야 합니다. 예를 들어 지원해야 하는 워크로드 유형별로 기기 archetype을 정의할 수 있습니다. 그런 다음 해당 archetype의 속성에 따라 기기를 배포하고 관리할 수 있습니다.

이 권장사항을 따르고 있는지 확인하려면 지정된 archetype 기기에서 임의로 기기를 선택할 수 있는지 확인하고 다음을 수행합니다.

  • 동일 archetype의 다른 기기와 마찬가지로 기기를 처리합니다. 이렇게 하면 운영 효율성 향상됩니다.
  • 추가 맞춤설정 없이 동일한 archetype의 기기로 기기를 바꿉니다. 그러면 해당 archetype이 올바르게 구현되었음을 알 수 있습니다.

이 권장사항을 통해 기기 집합의 분산을 줄여 환경과 프로비저닝 및 구성 프로세스의 파편화를 줄일 수 있습니다.

시드 기기를 사용하여 환경 부트스트랩

기기를 프로비저닝 및 구성할 때 순환 종속성 문제가 발생할 수 있습니다. 기기를 직접 프로비저닝하고 구성하려면 기기에 지원 인프라가 필요하지만 여전히 프로비저닝 및 구성을 해야 하므로 해당 인프라가 제 위치에 있지 않습니다.

시드 기기를 사용해 이 문제를 해결할 수 있습니다. 시드 기기는 일시적인 특수한 목적을 가집니다. 특수한 용도를 위해 설계된 태스크를 완료한 후 기기에서 관련 원형의 동작 및 상태를 준수합니다.

예를 들어 cloud-init를 사용하여 기기를 자동으로 초기화하는 경우 다음과 같은 방법으로 cloud-init NoCloud 데이터 소스를 구성해야 할 수 있습니다.

  1. 파일 시스템을 통해 시드 기기에 NoCloud 데이터 소스 데이터를 제공합니다.

  2. 시드 기기가 네트워크를 통해 다른 기기에 NoCloud 데이터 소스 데이터를 제공하는 등의 특수 목적으로 자체 프로비저닝 및 구성을 완료할 때까지 기다립니다.

    시드 기기의 프로비저닝 및 구성 프로세스는 시드 기기의 일시적인 특수 목적을 삭제할 수 있는 조건이 충족될 때까지 기다립니다. 이러한 조건의 몇 가지 예시는 다음과 같습니다.

    • 네트워크를 통해 NoCloud 데이터 소스 데이터를 제공하는 환경에 다른 기기가 있나요?
    • 클러스터에 노드가 충분히 있나요?
    • 첫 번째 백업이 완료되었나요?
    • 재해 복구 사이트가 준비되어 있나요?

  3. 시드 기기에서 네트워크를 통해 NoCloud 데이터 소스 데이터를 다운로드하는 다른 기기를 프로비저닝하고 구성합니다. 일부 기기는 네트워크를 통해 NoCloud 데이터 소스 데이터를 제공할 수 있어야 합니다.

  4. 시드 기기의 프로비저닝 및 구성 프로세스가 다시 시작되므로 시드 기기의 특수한 목적을 삭제할 수 있는 조건이 충족됩니다. 네트워크를 통해 NoCloud 데이터 소스 데이터를 제공하는 일련의 다른 기기가 있습니다.

  5. 시드 기기의 프로비저닝 및 구성 프로세스에서 특수 목적을 삭제하므로, 시드 기기를 동일한 archetype의 다른 기기와 구분할 수 없습니다.

이 권장사항을 따르면 인프라 지원 없이 특수 목적 기기 피하기 권장사항을 위반하지 않고 환경을 부트스트랩할 수 있습니다.

기기의 스테이트풀(Stateful) 최소화

에지 기기를 설계할 때는 스테이트풀(Stateful) 정보를 최소한으로 저장해야 합니다. 에지 기기는 하드웨어 리소스가 제한되거나 까다로운 환경에 배포될 수 있습니다. 스테이트풀(Stateful) 정보가 작동하는 데 필요한 스테이트풀(Stateful) 정보를 최소화하면 이러한 기기를 동일하게 처리할 수 있으므로 프로비저닝, 구성, 백업 및 복구 프로세스가 간소화됩니다. 예를 들어 스테이트리스(Stateless) 에지 기기가 오작동하여 복구할 수 없는 경우 중단 또는 데이터 손실을 최소화하면서 동일한 archetype의 다른 기기로 교체할 수 있습니다.

이 권장사항은 데이터 손실로 인해 또는 프로세스가 너무 복잡하여 예기치 않은 문제를 방지하는 데 도움이 됩니다. 대다수의 복잡성은 다양한 이기종 기기를 지원해야 할 때 발생합니다.

OS 및 펌웨어 이미지 자동 빌드

기기를 처음 부팅할 때 비용이 많이 드는 프로비저닝 및 구성 작업을 방지하고 기기 리소스를 절약하려면 OS 및 펌웨어 이미지를 사용하기 전에 맞춤설정하세요. 예를 들어 각 기기를 처음 부팅할 때 종속 항목을 설치하는 대신 이미지에 직접 종속 항목을 설치할 수 있습니다.

기기의 OS 및 펌웨어 이미지를 준비할 때 기본 이미지부터 시작합니다. 기본 이미지를 맞춤설정할 때 다음을 수행할 수 있습니다.

  • 골든 이미지 생성. 골든 이미지에는 이미지의 모든 종속 항목이 포함되어 있으므로 기기를 처음 부팅할 때 해당 종속 항목을 설치할 필요가 없습니다. 골든 이미지를 생성하는 것은 복잡한 작업일 수 있지만 프로비저닝 및 구성 중에 기기에서 시간과 리소스를 절약할 수 있습니다.
  • 실버 이미지 생성. 골든 이미지와 달리 실버 이미지를 실행하는 기기는 처음 부팅 중에 모든 프로비저닝 및 구성 프로세스를 완료합니다. 실버 이미지를 생성하는 것은 골든 이미지를 생성하는 것보다 덜 복잡할 수 있지만 실버 이미지를 실행하는 기기는 프로비저닝 및 구성 중에 더 많은 시간과 리소스를 소비합니다.

지속적 통합 및 지속적 배포(CI/CD) 프로세스의 일부로 OS 및 펌웨어 이미지를 맞춤설정하고, 맞춤설정된 이미지를 검증한 후 기기에 자동으로 제공할 수 있습니다. Cloud Build, GitHub Actions, GitLab CI 등의 도구로 구현하는 CI/CD 프로세스 또는 Jenkins에서 다음 작업 시퀀스를 수행할 수 있습니다.

  1. 커스텀 이미지에 대한 자동 검증을 수행합니다.
  2. 기기를 가져올 수 있는 저장소에 커스텀 이미지를 게시합니다.

CI/CD 환경 및 이미지를 빌드해야 하는 OS 또는 펌웨어에서 다른 하드웨어 아키텍처를 사용하는 경우 QEMU와 같은 도구를 사용하여 이러한 아키텍처를 에뮬레이션할 수 있습니다. 예를 들어 x86_64 아키텍처에서 ARM 계열의 하드웨어 아키텍처를 에뮬레이션할 수 있습니다.

OS 또는 펌웨어 이미지를 맞춤설정하려면 에지 기기에 설치하기 전에 수정하고 테스트 환경에서 이러한 수정을 검증할 수 있어야 합니다. chroot와 같은 도구를 사용하면 명령어를 실행하기 전에 가상으로 변경할 수 있지만 루트 디렉터리를 물리적으로 변경할 수는 없습니다.

이 권장사항은 기기에 이미지를 제공하기 전에 OS 및 펌웨어 이미지를 맞춤설정하는 데 도움이 됩니다.

기기에서 실행되는 워크로드를 안정적으로 조정

기기에서 이기종 워크로드를 지원하는 경우 다음 도구를 사용하여 이러한 워크로드를 조정하고 수명 주기를 관리할 수 있습니다.

  • 워크로드 조정 시스템: Kubernetes 등의 워크로드 조정 시스템은 복잡한 조정 또는 수명 주기 관리 요구사항이 있는 워크로드에 적합합니다. 이러한 시스템은 여러 구성요소에 걸쳐 있는 워크로드에도 적합합니다. 두 경우 모두 조정 및 워크로드 수명 주기 관리 로직을 직접 구현할 필요가 없습니다. 기기의 리소스가 제한된 경우 MicroK8s, K3s 또는 에지 프로필이 설치된 Google Distributed Cloud와 같이 표준 리소스보다 리소스가 적게 필요한 경량 Kubernetes 배포를 설치할 수 있습니다.

  • init 시스템: systemd와 같은 init 시스템은 다음 특성을 가진 워크로드에 적합합니다.

    • 간단한 조정 요구사항
    • 워크로드 조정 시스템을 지원하기 위한 리소스 부족
    • 컨테이너에 배치할 수 없는 워크로드

워크로드를 조정할 시스템을 마련한 후에는 이를 사용하여 프로비저닝 및 구성 프로세스에 속하는 작업을 실행할 수도 있습니다. 예를 들어 프로비저닝 및 구성 프로세스의 일부로 구성 관리 도구를 실행해야 하는 경우 다른 워크로드와 마찬가지로 워크로드 조정 시스템을 사용할 수 있습니다.

이 권장사항을 따르면 기기에서 실행 중인 워크로드를 조정할 수 있습니다.

기기 확인, 인증 및 연결

기기를 다른 기기 또는 백엔드와 같은 외부 시스템에 연결해야 하는지 확인하려면 다음 하위 섹션의 권장사항을 고려하세요.

이 권장사항은 다음을 수행하는 데 도움이 됩니다.

  • 기기에 안전한 통신 채널을 설계합니다.
  • 기기의 보안 경계를 우회하는 잠재적 백도어를 방지합니다.
  • 공격자가 악용할 수 있는 승인되지 않은 인터페이스를 노출하지 않는지 확인합니다.

적용할 연결 방법

  • 정보를 교환하기 전에 정보를 요청하는 다른 당사자를 인증합니다.
  • 전송된 정보가 예기치 않은 채널을 통해 이동하지 않는지 확인합니다.
  • 신뢰할 수 있는 실행 환경에서 암호화 키, 인증 키, 비밀번호와 같은 보안 비밀을 처리합니다.
  • 사용하기 전에 OS 또는 펌웨어 이미지의 무결성과 신뢰성을 확인합니다.
  • 사용자가 제공한 구성의 유효성, 무결성, 신뢰성을 확인합니다.
  • 불필요한 소프트웨어를 설치하지 않고 기존에 기기에 있는 소프트웨어를 삭제하여 공격에 노출되는 영역을 제한합니다.
  • 권한이 있는 작업 및 계정의 사용을 제한합니다.
  • 해당 사례에서 물리적 조작을 방지해야 하는 경우 해당 기기 사례의 무결성을 확인합니다.

피해야 할 연결 방식

  • 암호화되지 않은 채널을 통해 민감한 정보를 전송하지 마세요.
  • 다음과 같이 액세스 권한 관리를 열어두지 마세요.
    • 승격된 권한을 사용한 가상 또는 물리적 직렬 포트 및 직렬 콘솔(누군가가 기기를 실제로 조작하는 경우에만 포트에 액세스할 수 있는 경우 포함)
    • 네트워크에서 들어오는 요청 및 권한 있는 작업을 실행할 수 있는 요청에 응답하는 엔드포인트
  • OS나 펌웨어 이미지, 구성 또는 소스 코드에 하드코딩된 사용자 인증 정보를 사용하지 마세요.
  • 공격자가 권한을 승격하는 데 필요한 정보를 수집하는 데 도움이 되는 정보를 공개하지 마세요. 예를 들어 기기의 데이터를 암호화하고 프로덕션 기기에서 불필요한 추적 및 로깅 시스템을 사용 중지해야 합니다.
  • 사용자와 워크로드가 임의의 코드를 실행하지 못하게 하세요.

기기 모니터링

환경의 안정성을 위해 수동 개입 없이 기기 상태에 대한 정보를 수집하는 것이 필수적입니다. 기기에서 필요한 모든 데이터를 자동으로 보고하는지 확인합니다. 데이터를 수집하고 모니터링하는 주된 이유는 두 가지입니다.

  • 기기가 의도한 대로 작동하는지 확인할 수 있도록 지원하기 위함입니다.
  • 문제를 사전에 파악하고 예방 유지보수를 수행합니다.

예를 들어 Cloud Monitoring으로 모니터링 측정항목과 이벤트를 수집할 수 있습니다.

문제를 조사하고 해결하려면 정상 작동 중 기기를 모니터링하는 프로세스 외에도 자세한 모니터링, 추적, 디버깅 정보와 같은 고해상도 진단 데이터를 수집하기 위한 프로세스를 설계하고 구현하는 것이 좋습니다. 고해상도 진단 데이터를 수집하여 네트워크를 통해 전송하는 것은 컴퓨팅, 데이터 스토리지, 전력 등 기기 리소스 측면에서 비용이 많이 들 수 있습니다. 이러한 이유로 필요한 경우에만 고해상도 진단 데이터를 수집하고 추가 조사가 필요한 기기에 대해서만 프로세스를 활성화하는 것이 좋습니다. 예를 들어 기기 중 하나가 의도한 대로 작동하지 않고 기기에서 보고하는 정기적인 모니터링 데이터로 문제를 충분히 진단할 수 없는 경우 문제의 원인을 조사하는 데 도움이 되는 추가 정보를 보고하도록 해당 기기에서 고해상도 데이터 수집을 사용 설정할 수 있습니다.

이 권장사항을 따르면 기기를 알 수 없는 상태로 두지 않고 기기의 성능 및 작동 방식을 결정할 수 있는 충분한 데이터를 확보할 수 있습니다.

자동 부팅 및 업그레이드 지원

프로비저닝 및 구성 프로세스를 설계할 때 기기가 자동으로 부팅될 수 있고 필요한 인프라가 있는지 확인합니다. 최초 부팅과 무선 업그레이드 전송을 모두 지원하는 자동 부팅 메커니즘을 구현하면 인프라의 유지보수 가능성이 향상됩니다. 자동 부팅을 사용하면 부팅 또는 업그레이드 시 각 기기에 수동으로 참석할 필요가 없습니다. 많은 기기에 수동으로 참석하는 경우 운영자가 작업을 누락하거나 잘못 수행하거나 그룹에 있는 모든 기기에 필요한 작업을 수행하기에 시간이 충분하지 않을 수 있으므로 오류가 발생할 수 있습니다.

또한 올바른 OS 또는 펌웨어 이미지를 부팅하기 위해 각 기기를 미리 준비할 필요가 없습니다. 예를 들어 OS 또는 펌웨어 이미지의 새 버전을 출시하고 기기가 네트워크에서 부팅 안내를 받을 때 선택할 수 있는 옵션 중 하나로 사용하도록 설정할 수 있습니다.

이 권장사항을 따르면 자동 및 무인 방식으로 기기에 대한 부팅 및 업그레이드를 수행할 수 있습니다.

복원력이 우수한 프로세스 설계 및 구현

완전 자동화된 프로비저닝 및 구성 프로세스를 사용하더라도 프로세스가 올바르게 완료되지 않아 기기가 일관되지 않은 상태가 되는 오류가 발생할 수 있습니다. 재시도 및 대체 메커니즘을 구현하여 기기에서 이러한 오류를 복구할 수 있도록 합니다. 예를 들어 기기에서 프로비저닝 및 구성 프로세스의 일부 작업을 완료하는 데 실패하면 자동으로 해당 장애로부터 복구를 시도해야 합니다. 기기가 장애에서 복구되거나 작동 상태로 돌아가면 해당 프로세스는 실패한 지점에서 실행 중인 프로세스를 재개할 수 있습니다.

이 권장사항은 복원력이 우수한 프로비저닝 및 구성 프로세스를 설계하고 구현하는 데 도움이 됩니다.

기기의 전체 수명 주기 지원

프로비저닝 및 구성 프로세스를 설계할 때는 이러한 프로세스에서 전체 기기 수명 주기를 관리할 수 있는지 확인하세요. 기기 수명 주기를 효과적으로 관리하는 방법은 기기를 비교적 오랫동안 실행해야 하는 경우에도 종료 및 폐기 계획을 포함하는 것입니다.

기기의 수명 주기를 관리하지 않으면 다음과 같은 문제가 발생할 수 있습니다.

  • 고비용 지속: 프로비저닝 및 구성 프로세스를 구현한 후 수명 주기 관리 지원을 도입하면 비용이 증가할 수 있습니다. 설계 초기에 이 지원을 계획하면 비용을 줄일 수 있습니다. 예를 들어 프로비저닝 및 구성 프로세스에서 기기의 전체 수명 주기를 지원하지 않는 경우 수명 주기의 각 단계를 올바르게 처리하기 위해 각 기기에 수동으로 개입해야 할 수 있습니다. 수동 개입에는 많은 비용이 들 수 있으며 종종 확장되지 않습니다.
  • 유연성 저하: 수명 주기 관리를 지원하지 않으면 기기를 업데이트하거나 관리하지 못할 수 있습니다. 예를 들어 기기를 안전하고 효율적으로 사용 중지하는 메커니즘이 없으면 기기 지원 종료 및 최종 폐기를 관리하는 것이 어려울 수 있습니다.

다음 단계

참여자

작성자: 마르코 페라리 | 클라우드 솔루션 설계자