다음을 통해 공유

다중 테넌트 솔루션 업데이트에 대한 고려 사항

  • 아티클

클라우드 기술의 이점 중 하나는 지속적인 개선과 발전입니다. 서비스 공급자는 솔루션에 업데이트를 적용해야 합니다. 애플리케이션 코드, Azure 인프라, 데이터베이스 스키마 또는 기타 구성 요소를 변경해야 할 수 있습니다. 환경을 업데이트하는 방법을 계획하는 것이 중요합니다. 다중 테넌트 솔루션에서는 일부 테넌트가 환경 변경을 허용하기를 꺼리거나 서비스를 업데이트할 수 있는 조건을 제한하는 요구 사항이 있을 수 있으므로 업데이트 정책에 대해 명확히 하는 것이 특히 중요합니다.

솔루션을 업데이트하는 전략을 계획할 때 다음을 수행해야 합니다.

  • 테넌트의 요구 사항을 식별합니다.
  • 서비스를 운영하기 위한 사용자 고유의 요구 사항을 명확히 합니다.
  • 사용자와 테넌트 둘 다 수락할 수 있는 잔액을 찾습니다.
  • 테넌트 및 기타 이해 관계자에게 전략을 명확하게 전달합니다.

이 문서에서는 테넌트의 소프트웨어를 업데이트하기 위해 고려할 수 있는 접근 방식과 관련된 장단분에 대한 기술 의사 결정권자를 위한 지침을 제공합니다.

고객의 요구 사항

고객은 시스템이 업데이트되는 방식에 영향을 줄 수 있는 명시적 또는 암시적 요구 사항이 있는 경우가 많습니다. 고객이 제기할 수 있는 우려 사항의 그림을 작성하려면 다음 측면을 고려하세요.

  • 기대 및 요구 사항: 고객이 솔루션을 업데이트할 수 있는 시기에 대해 가질 수 있는 모든 기대 또는 요구 사항을 파악합니다. 계약 또는 서비스 수준 계약에서 공식적으로 전달되거나 비공식적일 수 있습니다.
  • 유지 관리 기간: 고객이 서비스 정의 또는 자체 정의 유지 관리 기간을 기대하는지 여부를 이해합니다. 잠재적인 중단에 대해 사용자에게 통신해야 하거나 업데이트가 완료된 후 서비스의 중요한 측면을 테스트해야 할 수 있습니다.
  • 규정: 고객이 업데이트를 적용하기 전에 추가 승인이 필요한 규제 문제가 있는지 여부를 명확히 합니다. 예를 들어 IoT 구성 요소를 포함하는 상태 솔루션을 제공하는 경우 업데이트를 적용하기 전에 FDA(미국 식품의약국)의 승인을 받아야 할 수 있습니다.
  • 민감도: 고객이 업데이트를 적용하는 데 특히 민감하거나 저항력이 있는지 여부를 이해합니다. 만약 그렇다면, 그 이유를 이해하려고 노력하십시오. 예를 들어 실제 매장이나 소매 웹사이트를 운영하는 경우 위험이 잠재적인 이점보다 높기 때문에 Black Friday에 대한 업데이트를 방지할 수 있습니다.
  • 기록: 고객에게 영향을 주지 않고 업데이트를 성공적으로 완료한 자신의 실적을 검토합니다. 좋은 DevOps, 테스트, 배포 및 모니터링 사례를 따라 가동 중단 가능성을 줄이고 업데이트에서 발생하는 문제를 신속하게 식별할 수 있어야 합니다. 고객이 환경을 원활하게 업데이트할 수 있다는 것을 알고 있는 경우, 고객이 반대할 가능성이 적습니다.
  • 롤백: 호환성이 손상되는 변경이 있는 경우 고객이 업데이트를 롤백할지 여부와 이러한 롤백 요청을 트리거할 사용자를 고려합니다.

나의 요구 사항

또한 자신만의 관점에서 다음 질문을 고려해야 합니다.

  • 제공하려는 제어: 고객이 업데이트가 적용되는 시기를 제어하는 것이 합리적입니까? 대기업 고객이 사용하는 솔루션을 빌드하는 경우 대답은 '예'일 수 있습니다. 그러나 소비자 중심 솔루션을 빌드하는 경우 솔루션을 업그레이드하거나 운영하는 방법을 제어할 가능성은 거의 없습니다.
  • 버전: 한 번에 합리적으로 유지 관리할 수 있는 솔루션 버전은 몇 개입니까? 버그를 찾아 핫픽스를 추가해야 하는 경우 사용 중인 모든 버전에 핫픽스를 적용해야 할 수 있습니다.
  • 이전 버전의 결과: 고객이 현재 버전보다 너무 멀리 떨어지게 하는 영향은 무엇인가요? 정기적으로 새 기능을 릴리스하는 경우 이전 버전이 빠르게 사용되지 않을까요? 또한 업그레이드 전략 및 변경 유형에 따라 솔루션의 각 버전에 대해 별도의 인프라를 유지 관리해야 할 수 있습니다. 따라서 이전 버전에 대한 지원을 유지하므로 운영 및 재무 비용이 모두 발생할 수 있습니다.
  • 롤백: 배포 전략이 이전 버전으로의 롤백을 지원할 수 있나요? 이것이 바로 구현하고자 하는 그 것인가요?

참고

업데이트 또는 유지 관리를 위해 솔루션을 오프라인으로 전환해야 하는지 여부를 고려합니다. 일반적으로 중단 기간은 오래된 사례로 간주되며, 최신 DevOps 사례 및 클라우드 기술을 사용하면 업데이트 및 유지 관리 중에 가동 중지 시간을 방지할 수 있습니다. 그러나 가동 중지 시간 없이 배포하도록 설계해야 하므로 솔루션 아키텍처를 계획할 때 업데이트 프로세스를 고려해야 합니다.

업데이트 프로세스 중에 중단을 계획하지 않더라도 정기적인 유지 관리 기간을 정의하는 것이 좋습니다. 창은 특정 시간 동안 변경이 발생하는 고객과 통신하는 데 도움이 될 수 있습니다.

가동 중지 시간 배포를 구현하는 방법에 대한 자세한 내용은 버전이 지정된 서비스 업데이트를 통해 가동 중지 시간 제거를 참조 하세요.

균형 찾기

서비스 업데이트의 주기를 전적으로 테넌트의 재량에 맡기면 업데이트하지 않도록 선택할 수 있습니다. 고객이 가질 수 있는 합리적인 문제 또는 제약 조건을 고려하면서 솔루션을 업데이트할 수 있도록 하는 것이 중요합니다. 예를 들어 고객이 요일 중 가장 바쁜 날이기 때문에 금요일에 업데이트에 특히 민감하다면 솔루션에 영향을 주지 않고 월요일에 대한 업데이트를 쉽게 연기할 수 있습니까?

잘 작동할 수 있는 한 가지 방법은 아래에 설명된 방법 중 하나를 사용하여 테넌트별로 업데이트를 롤아웃하는 것입니다. 고객에게 계획된 업데이트에 대한 알림을 제공합니다. 고객이 일시적으로 옵트아웃할 수 있지만 영원히 옵트아웃할 수는 없습니다. 업데이트를 적용해야 하는 경우에 적절한 제한을 적용합니다.

또한 미리 알림을 최소화하거나 사용하지 않고 보안 패치 또는 기타 중요한 핫픽스를 배포할 수 있도록 허용하는 것이 좋습니다. 테넌트가 이러한 관행과 데이터 보호의 중요성을 이해하도록 합니다.

또 다른 방법은 테넌트가 선택한 시점에 자체 업데이트를 시작하도록 허용하는 것입니다. 다시 말하지만, 최종 기한을 제공해야 하며, 이 시점에서 업데이트를 대신 적용해야 합니다.

경고

테넌트가 자체 업데이트를 시작할 수 있도록 하는 데 주의해야 합니다. 이는 구현하기 복잡하며, 이를 전달하고 유지 관리하려면 상당한 개발 및 테스트 노력이 필요합니다.

어떤 작업을 수행하든, 특히 업데이트가 적용되기 전과 후에 테넌트 상태를 모니터링하는 프로세스가 있는지 확인합니다. 코드 또는 구성을 업데이트한 후 중요한 프로덕션 인시던트(라이브 사이트 인시던트라고도 함)가 발생하는 경우가 많습니다. 따라서 고객 신뢰를 유지하기 위해 문제를 사전에 모니터링하고 대응하는 것이 중요합니다. 모니터링에 대한 자세한 내용은 모니터링 시스템 디자인 및 만들기에 대한 권장 사항을 참조 하세요.

고객과 커뮤니케이션

명확한 커뮤니케이션은 고객의 신뢰를 구축하기 위한 핵심입니다. 새로운 기능, 버그 수정, 보안 취약성 해결, 성능 향상 등 정기적인 업데이트의 이점을 설명하는 것이 중요합니다. 최신 클라우드 호스팅 솔루션의 이점 중 하나는 기능 및 업데이트를 지속적으로 제공하는 것입니다.

다음 질문을 살펴보세요.

  • 예정된 업데이트를 고객에게 알릴까요?
  • 이 경우 옵트아웃 프로세스를 제공하여 암시적으로 사용 권한을 요청할 것이며 옵트아웃에 대한 제한은 무엇인가요?
  • 업데이트를 적용할 때 사용하는 예약된 유지 관리 기간이 있나요?
  • 중요한 보안 패치와 같은 긴급 업데이트가 있는 경우 어떻게 되나요? 이러한 상황에서 강제로 업데이트를 수행할 수 있나요?
  • 예정된 업데이트를 고객에게 사전에 알릴 수 없는 경우 소급 알림을 제공할 수 있나요? 예를 들어 적용한 업데이트 목록으로 웹 사이트의 페이지를 업데이트할 수 있나요?
  • 프로덕션 환경에서 유지 관리되는 시스템의 개별 버전은 몇 개입니까?

고객 지원 팀과 커뮤니케이션

사용자 고유의 지원 팀이 각 테넌트의 인프라에 적용된 업데이트를 완전히 파악하는 것이 중요합니다. 고객 지원 담당자는 다음 질문에 쉽게 대답할 수 있어야 합니다.

  • 최근에 테넌트의 인프라 또는 공유 구성 요소에 업데이트가 적용되었나요?
  • 이러한 업데이트의 특성은 무엇인가요?
  • 이전 버전은 무엇인가요?
  • 이 테넌트에 업데이트가 적용되는 빈도는 얼마인가요?

업데이트로 인해 고객 중 하나에 문제가 있는 경우 고객 지원 팀에 변경된 내용을 이해하는 데 필요한 정보가 있는지 확인해야 합니다.

업데이트를 지원하는 배포 전략

인프라에 업데이트를 배포하는 방법을 고려합니다. 이는 사용하는 테넌시 모델의 영향을 많이 받습니다. 업데이트를 배포하는 세 가지 일반적인 방법은 배포 스탬프, 기능 플래그 및 배포 링입니다. 이러한 접근 방식을 독립적으로 사용하거나 더 복잡한 요구 사항을 충족하기 위해 함께 결합할 수 있습니다.

모든 경우에 각 테넌트가 있는 인프라, 소프트웨어 또는 기능의 버전, 마이그레이션할 수 있는 항목 및 해당 상태와 관련된 시간 관련 데이터를 알 수 있도록 충분한 보고 및 가시성이 있는지 확인합니다.

배포 스탬프 패턴

많은 다중 테넌트 애플리케이션은 애플리케이션 및 기타 구성 요소의 여러 복사본을 배포하는 배포 스탬프 패턴에 적합합니다. 격리 요구 사항에 따라 각 테넌트에 대한 스탬프 또는 여러 테넌트의 워크로드를 실행하는 공유 스탬프를 배포할 수 있습니다.

스탬프는 테넌트 간에 격리를 제공하는 좋은 방법입니다. 또한 다른 사용자에게 영향을 주지 않고 스탬프 간에 점진적으로 업데이트를 롤아웃할 수 있으므로 업데이트 프로세스에 대한 유연성을 제공합니다.

기능 플래그

기능 플래그 를 사용하면 해당 기능을 고객 또는 테넌트 하위 집합에만 노출하면서 솔루션에 기능을 추가할 수 있습니다.

이러한 상황 중 하나가 적용되는 경우 기능 플래그를 사용하는 것이 좋습니다.

  • 업데이트를 정기적으로 배포하지만 완전히 구현될 때까지 새 기능을 표시하지 않으려고 합니다.
  • 고객이 옵트인할 때까지 동작 변경 내용을 적용하지 않으려고 합니다.

코드를 직접 작성하거나 Azure App Configuration 같은 서비스를 사용하여 애플리케이션에 기능 플래그 지원을 포함할 수 있습니다.

배포 링

배포 링을 사용하면 테넌트 또는 배포 스탬프 세트에서 업데이트를 점진적으로 배포할 수 있습니다. 각 링에 테넌트 하위 집합을 할당할 수 있습니다.

만들 링 수와 각 링이 고유한 솔루션에 대해 무엇을 의미하는지 확인할 수 있습니다. 일반적으로 조직에서는 다음 링을 사용합니다.

  • 카나리아: 카나리아 링에는 사용 가능한 한 빨리 업데이트를 받으려는 사용자 고유의 테스트 테넌트와 고객이 포함되어 있으며, 더 자주 업데이트를 받을 수 있으며, 업데이트가 다른 작업과 마찬가지로 포괄적인 유효성 검사 프로세스를 거치지 않았을 수 있습니다.
  • 얼리어답터: 얼리 어답터 링에는 약간 더 위험하지는 않지만 정기적인 업데이트를 받을 준비가 된 테넌트가 포함되어 있습니다.
  • 사용자: 대부분의 테넌트는 사용자 링에 속하며, 덜 빈번하고 테스트가 높은 업데이트를 받습니다.

API 버전

서비스에서 외부 API를 노출하는 경우 적용하는 모든 업데이트가 고객 또는 파트너가 플랫폼과 통합하는 방식에 영향을 줄 수 있음을 고려합니다. 특히 API의 주요 변경 내용을 의식해야 합니다. API 버전 관리 전략을 사용하여 API 업데이트 위험을 완화하는 것이 좋습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다중 테넌트 솔루션에서 테넌트에 요청을 매핑하는 경우를 고려합니다.