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

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

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

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

이 문서에서는 테넌트 소프트웨어를 업데이트하는 방법 및 관련 장단분에 대한 기술 의사 결정권자를 위한 지침을 제공합니다.

고객의 요구 사항

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

• 기대치 및 요구 사항: 고객이 솔루션을 업데이트할 수 있는 시기에 대한 기대 또는 요구 사항을 파악합니다. 이러한 기대 또는 요구 사항은 계약 또는 서비스 수준 계약에서 귀하에게 공식적으로 전달되거나 비공식적일 수 있습니다.

• 유지 관리 기간: 고객이 서비스 정의 또는 자체 정의 유지 관리 기간을 기대하는지 여부를 이해합니다. 잠재적인 중단에 대해 사용자에게 통신해야 할 수도 있습니다. 또한 업데이트가 완료된 후 서비스의 중요한 측면을 테스트해야 할 수도 있습니다.

• 규정: 고객이 업데이트를 적용하기 전에 추가 승인이 필요한 규제 문제가 있는지 여부를 명확히 합니다. 예를 들어 IoT 구성 요소가 포함된 상태 솔루션을 제공하는 경우 업데이트를 적용하기 전에 미국 식품의약국(FDA)의 승인을 받아야 할 수 있습니다.

• 민감: 고객이 업데이트를 적용하는 데 특히 민감하거나 저항력이 있는지를 이해합니다. 만약 그렇다면, 그 이유를 이해하려고 노력하십시오. 예를 들어 실제 매장이나 소매 웹사이트를 운영하는 경우 위험이 잠재적인 이점보다 높기 때문에 Black Friday에 대한 업데이트를 방지할 수 있습니다.

• 역사: 고객에게 영향을 주지 않고 업데이트를 성공적으로 완료한 자신의 실적을 검토합니다. 좋은 DevOps, 테스트, 배포 및 모니터링 사례를 따라 가동 중단 가능성을 줄이고 업데이트에서 발생하는 문제를 신속하게 식별할 수 있어야 합니다. 고객이 환경을 원활하게 업데이트할 수 있다는 것을 알고 있는 경우 해당 고객은 이의를 제기할 가능성이 적습니다.

• 롤백: 호환성이 손상되는 변경이 있는 경우, 고객이 업데이트를 롤백하고자 하는지 여부와 이러한 롤백 요청을 누가 트리거하는지를 고려합니다.

요구 사항

또한 고유한 관점에서 다음 질문을 고려해야 합니다.

• 제공하려는 제어: 고객이 업데이트가 적용되는 시기를 제어하는 것이 합리적입니까? 대기업 고객이 사용하는 솔루션을 빌드하는 경우 대답은 '예'일 수 있습니다. 그러나 소비자 중심 솔루션을 빌드하는 경우 솔루션을 업그레이드하거나 운영하는 방법을 제어할 가능성은 거의 없습니다.

• 버전: 한 번에 얼마나 많은 버전의 솔루션을 합리적으로 유지할 수 있나요? 버그 또는 보안 취약성을 발견하고 핫픽스를 적용해야 하는 경우 현재 사용 중인 모든 버전에 적용해야 할 수 있습니다.

• 이전 버전의 결과: 고객이 현재 버전보다 너무 멀리 떨어지게 하는 영향은 무엇인가요? 새 기능을 정기적으로 릴리스하는 경우 이전 버전이 빠르게 사용되지 않는가요? 또한 업그레이드 전략 및 변경 유형에 따라 솔루션의 각 버전에 대해 별도의 인프라를 유지 관리해야 할 수 있습니다. 따라서 이전 버전에 대한 지원을 유지하므로 운영 및 재무 비용이 모두 발생할 수 있습니다.

• 롤백: 배포 전략이 이전 버전으로의 롤백을 지원할 수 있나요? 이 기능을 사용하시겠습니까?

잔액 찾기

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

잘 작동할 수 있는 한 가지 방법은 배포 전략 중 하나를 사용하여 테넌트별로 업데이트를 롤아웃하는 것입니다. 계획된 업데이트에 대해 고객에게 알립니다. 고객이 일시적으로 옵트아웃할 수 있지만 영구적으로 옵트아웃하지 않도록 허용합니다. 업데이트를 적용해야 하는 경우 적절한 제한을 적용합니다.

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

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

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

고객과 통신

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

다음 질문을 살펴보세요.

• 예정된 업데이트에 대해 고객에게 알릴 수 있나요?

• 이 경우 옵트아웃 프로세스를 제공하여 암시적으로 사용 권한을 요청할 것이며 옵트아웃에 대한 제한은 무엇인가요?

• 업데이트를 적용할 때 사용하는 예약된 유지 관리 기간이 있나요?

• 중요한 보안 패치와 같은 긴급 업데이트가 있는 경우 어떻게 되나요? 이러한 상황에서 강제로 업데이트를 수행할 수 있나요?

• 예정된 업데이트에 대해 고객에게 사전에 알릴 수 없는 경우 회고 알림을 제공할 수 있나요? 예를 들어 적용한 업데이트 목록으로 웹 사이트의 페이지를 업데이트할 수 있나요?

• 프로덕션 환경에서 유지 관리되는 시스템의 개별 버전은 몇 개입니까?

고객 지원 팀과 통신

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

• 최근에 테넌트의 인프라 또는 공유 구성 요소에 업데이트가 적용되었나요?

• 이러한 업데이트의 특성은 무엇인가요?

• 이전 버전은 무엇인가요?

• 이 테넌트에 업데이트가 적용되는 빈도는 얼마인가요?

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

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

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

모든 경우에 충분한 보고 및 가시성이 있는지 확인합니다. 각 테넌트가 사용하는 인프라, 소프트웨어 또는 기능 버전, 마이그레이션할 수 있는 항목 및 해당 상태와 관련된 시간 관련 데이터를 알아야 합니다. 이 정보를 추적하는 것은 종종 컨트롤 플레인의 책임 중 하나입니다.

배포 스탬프 패턴

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

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

기능 플래그

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

다음 시나리오 중 하나가 적용되는 경우 기능 플래그를 사용하는 것이 좋습니다.

• 업데이트를 정기적으로 배포하지만 완전히 구현될 때까지 새 기능을 표시하지 않으려고 합니다.

• 고객이 옵트인할 때까지 동작 변경 내용을 적용하지 않으려고 합니다.

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

배포 단계

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

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

• 카나리아: 카나리아 링에는 사용 가능한 즉시 업데이트를 받으려는 고유한 테스트 테넌트와 고객이 포함됩니다. 카나리아 링에 있는 사람은 더 자주 업데이트를 받을 수 있다는 것을 이해해야 합니다. 이러한 업데이트는 다른 링의 업데이트처럼 포괄적인 유효성 검사 프로세스를 거치지 않았을 수 있습니다.

• 얼리어답터: 얼리 어답터 링에는 약간 더 위험하지 않지만 정기적인 업데이트를 받을 준비가 된 테넌트가 포함되어 있습니다.

• 사용자: 대부분의 테넌트는 사용자 링에 속하며, 덜 빈번하고 테스트가 높은 업데이트를 받습니다.

API 버전

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

기여자

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

대표 저자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례

기타 기여자:

• 채드 키텔 | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
• Daniel Scott-Raynsford | 파트너 기술 전략가
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

관련 리소스

• 멀티테넌트 솔루션에서 요청을 테넌트에 매핑하기