기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

AWS AppConfig 브라우저 및 모바일 사용 고려 사항

기능 플래그를 사용하면 앱 스토어 릴리스에 따르는 오버헤드, 위험 또는 경직성 없이도 웹 페이지 및 모바일 애플리케이션 환경을 즉시 업데이트할 수 있습니다. 기능 플래그를 사용하면 선택한 시점에 사용자 기반에 대한 변경 사항을 점진적으로 릴리스할 수 있습니다. 오류가 발생하는 경우, 사용자가 새 소프트웨어 버전으로 업그레이드하지 않고도 변경 사항을 즉시 롤백할 수 있습니다. 간단히 말해서, 기능 플래그는 애플리케이션에 변경 사항을 배포할 때 더 큰 제어와 유연성을 제공합니다.

다음 섹션에서는 웹 페이지 및 모바일 디바이스에서 AWS AppConfig 기능 플래그를 사용하기 위한 중요한 고려 사항을 설명합니다.

구성 데이터 및 플래그 검색

브라우저 및 모바일 사용 사례의 경우 많은 고객이 웹 또는 모바일 애플리케이션과 AWS AppConfig간에 프록시 계층을 사용하는 것을 선택합니다. 이렇게 하면 AWS AppConfig 통화 볼륨이 사용자 기반 크기와 분리되어 비용이 절감됩니다. 또한 플래그 검색 성능을 최적화하고를 사용하여 프록시를 생성하는 다중 변형 flags. AWS AppConfig recommends와 같은 기능을 지원하는 AWS AppConfig 에이전트를 활용할 AWS Lambda 수 있습니다. 플래그를에서 직접 검색하는 대신 AWS AppConfig Lambda 함수 내에서 기능 플래그를 검색하도록 Lambda 확장을 AWS AppConfig구성합니다. 함수를 작성하여 이벤트 요청의 AWS AppConfig 검색 파라미터를 수락하고 Lambda 응답에서 해당 구성 데이터를 반환합니다. Lambda 함수 URLs을 사용하여 인터넷에 프록시를 공개합니다.

프록시를 구성한 후에는 데이터를 검색하는 빈도를 고려하세요. 모바일 사용 사례에는 일반적으로 빈도 높은 폴링 간격이 필요하지 않습니다. 애플리케이션이 프록시에서 새로 고침하는 것보다 AWS AppConfig 더 자주에서 데이터를 새로 고치도록 AWS AppConfig 에이전트를 구성합니다.

인증 및 Amazon Cognito

Lambda 함수 URL은 AWS_IAM 및 NONE의 두 가지 형태로 액세스 제어를 지원합니다. Lambda 함수에서 자체 인증 및 권한 부여를 구현하려는 경우 NONE을 사용합니다. 엔드포인트를 공개적으로 노출하도록 허용하고 구성 데이터에 민감한 데이터가 포함되지 않은 경우의 사용 사례에도 권장되는 옵션은 NONE입니다. 다른 모든 사용 사례의 경우 AWS_IAM을 사용하세요.

AWS_IAM을 사용하기로 선택한 경우, Amazon Cognito에서 자격 증명을 관리해야 합니다. Amazon Cognito를 시작하려면 ID 풀을 생성해야 합니다. ID 풀을 사용하면 인증된 사용자 또는 게스트 사용자를 위해 애플리케이션에 단기 자격 증명을 제공할 수 있습니다. 사용자가 Lambda 함수에 InvokeFunctionUrl을 사용하도록 허용하는 역할을 ID 풀에 추가해야 합니다. 이렇게 하면 애플리케이션의 인스턴스가 구성 데이터를 검색하는 데 필요한 자격 증명에 액세스할 수 있습니다.

애플리케이션에서 Amazon Cognito로 작업할 때는 AWS Amplify 사용을 고려하세요. Amplify는 와의 모바일/웹 애플리케이션 상호 작용을 간소화 AWS 하고 Amazon Cognito에 대한 기본 지원을 제공합니다.

캐싱

를 사용할 때는 항상 디바이스 또는 브라우저에서 구성 데이터를 로컬로 캐싱 AWS AppConfig해야 합니다. 캐싱은 다음과 같은 이점을 제공합니다.

모바일 사용 사례의 경우 인 메모리 및 지속성 온디바이스 캐시를 구현하는 것이 좋습니다. 인 메모리 캐시에서 원하는 구성을 검색하고 필요한 경우 다시 프록시에서 가져올 수 있도록 애플리케이션을 구성합니다. 프록시에서 구성이 성공적으로 검색되면 인 메모리 캐시를 업데이트한 다음 디바이스에 구성을 유지합니다. 백그라운드 프로세스를 사용하여 캐시를 반복하고 각 구성을 새로 고칩니다. 애플리케이션 시작 후 처음으로 구성을 가져올 때 검색에 실패하면 지속성 구성으로 전환합니다(그리고 이를 사용하여 인 메모리 캐시에 시딩).

Segmentation

기능 플래그를 사용하는 경우 고객 기반 전체에 걸쳐 기능 플래그 지정 환경을 세분화하기를 원할 수도 있습니다. 이렇게 하려면 플래그 검색 직접 호출에 콘텍스트를 제공하고 제공된 콘텍스트를 기반으로 기능 플래그의 다양한 변형을 반환하도록 규칙을 구성합니다. 예를 들어 사용자에게 iOS 18.X 사용자를 위한 기능 플래그 변형, iOS 17.X 사용자를 위한 변형, 다른 모든 iOS 버전에 대한 기본 플래그가 있다고 가정해 봅시다. 변형을 사용하면 애플리케이션의 모든 iOS 버전이 동일한 환경에서 동일한 구성을 대상으로 하도록 구성할 수 있지만, 검색 호출에 제공된 콘텍스트(예: "version": "iOS18.1")에 따라 디바이스는 구성의 적절한 변형을 수신하게 됩니다.

AWS AppConfig 에이전트를 사용하여 기능 플래그를 검색하지 않도록 선택한 경우 환경을 활용하여 AWS AppConfig 간단하고 카디널리티가 낮은 세분화를 수행할 수 있습니다. 환경은 대상에 대한 논리적 배포 그룹입니다. 구성을 개발, 테스트 및 프로덕션 환경으로 세분화하는 것 외에도 디바이스 유형(태블릿 대 전화) 또는 메이저 OS 버전과 같은 모바일 특화 환경을 생성하여 고객 기반을 세분화할 수 있습니다. 환경을 분리해 사용하면 특정 고객 기반의 특정 요구 사항을 충족하기 위해 동일하거나 다른 구성 데이터 세트를 배포할 수 있습니다.

대역폭(모바일 사용 사례)

일반적으로, 각 플래그 세트의 크기를 작게 유지하는 것을 목표로 하세요. 모바일 사용 사례에는 저대역폭 제약이 수반되는 경향이 있습니다. 데이터 크기를 최소화하면 사용자 기반 전반에서 일관된 경험을 유지하는 데 도움이 됩니다. 또한 모바일 디바이스는 대역폭이 낮거나 없는 환경에서 작동하는 경우가 많기 때문에 온디바이스 캐싱이 매우 중요합니다. 구성 데이터를 검색할 수 없는 경우 치명적인 오류 없이 실패하는 애플리케이션 코드도 중요합니다.

추가 플래그 사용 사례

기능 플래그의 이점은 기능 릴리스 편의성에서 멈추지 않습니다. 장기 운영 플래그를 사용하여 애플리케이션의 운영 형태를 개선하는 것도 가능합니다. 예를 들어 이벤트 발생 중에 추가 지표를 내보내고 데이터를 디버깅하는 성능 모니터링 토글을 생성할 수 있습니다. 또는 고객 기반의 한 세그먼트에 대해 애플리케이션 새로 고침 빈도를 유지 관리하고 조정할 수도 있습니다.