Java용 신뢰할 수 있는 웹앱 패턴 - 패턴 적용

Azure App Service

Azure Front Door

Azure Cache for Redis

Java용 Microsoft 인증 라이브러리

이 문서에서는 신뢰할 수 있는 웹앱 패턴을 적용하는 방법을 보여 줍니다. 신뢰할 수 있는 웹앱 패턴은 클라우드로 마이그레이션할 때 웹앱을 수정(다시 배치)하는 방법을 정의하는 일련의 원칙 및 구현 기술 입니다. 클라우드에서 성공하기 위해 수행해야 하는 최소한의 코드 업데이트에 중점을 둡니다.

이 지침의 적용을 용이하게 하기 위해 배포할 수 있는 신뢰할 수 있는 웹앱 패턴의 참조 구현 이 있습니다.

참조 구현 아키텍처의 아키텍처입니다. 이 아키텍처의 Visio 파일을 다운로드합니다.

다음 지침에서는 참조 구현을 전체 예제로 사용합니다. 신뢰할 수 있는 웹앱 패턴을 적용하려면 잘 설계된 프레임워크의 핵심 요소에 맞게 조정된 다음 권장 사항을 따릅니다.

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 디자인 검토 검사 안정성 목록을 참조하세요. 신뢰할 수 있는 웹앱 패턴은 안정성을 향상시키기 위해 코드 수준에서 두 가지 주요 디자인 패턴인 재시도 패턴과 회로 차단기 패턴을 도입합니다.

다시 시도 패턴 사용

다시 시도 패턴은 일시적인 오류라는 임시 서비스 중단을 해결하며, 일반적으로 몇 초 내에 해결됩니다. 이러한 오류는 종종 클라우드 환경의 서비스 제한, 동적 부하 분산 및 네트워크 문제로 인해 발생합니다. 다시 시도 패턴을 구현하려면 실패한 요청을 다시 보내서 예외를 throw하기 전에 구성 가능한 지연 및 시도를 허용합니다.

Resilience4j를 사용하여 Java에서 재시도 패턴을 구현합니다. Resilience4j는 경량의 내결함성 라이브러리입니다. 회로 차단기, 속도 제한기, 재시도 또는 격벽 디자인 패턴을 사용하여 기능 인터페이스, 람다 식 및 메서드 참조를 향상시키는 상위 함수(데코레이터)를 제공합니다.

예: 참조 구현은 재시도 주석을 사용하여 서비스 계획 컨트롤러의 listServicePlans 메서드를 데코레이트하여 재시도 패턴을 추가합니다. 코드는 초기 호출이 실패할 경우 데이터베이스에서 서비스 계획 목록에 대한 호출을 다시 시도합니다.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

참조 구현은 최대 시도, 대기 기간 및 다시 시도해야 하는 예외를 포함하여 재시도 정책을 구성합니다. 재시도 정책은 .에서 구성됩니다 application.properties.

회로 차단기 패턴 사용

재시도 및 회로 차단기 패턴을 페어링하면 일시적 오류와 관련이 없는 서비스 중단을 처리하는 애플리케이션의 기능이 확장됩니다. 회로 차단기 패턴은 애플리케이션이 응답하지 않는 서비스에 계속 액세스하지 못하도록 합니다. 회로 차단기 패턴은 애플리케이션을 해제하고 CPU 주기를 낭비하지 않으므로 애플리케이션이 최종 사용자의 성능 무결성을 유지합니다. 자세한 내용은 Spring Circuit Breaker 및 Resilience4j 설명서를 참조하세요.

예: 참조 구현은 회로 차단기 특성으로 메서드를 데코레이팅하여 회로 차단기 패턴을 구현합니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안에 대한 디자인 검토 검사 목록을 참조하세요. 신뢰할 수 있는 웹앱 패턴은 관리 ID를 사용하여 ID 중심 보안을 구현합니다. 프라이빗 엔드포인트, 웹 애플리케이션 방화벽 및 웹앱에 대한 제한된 액세스는 안전한 수신을 제공합니다.

최소 권한 적용

보안 및 효율성을 보장하려면 사용자(사용자 ID) 및 Azure 서비스(워크로드 ID)에게 필요한 권한만 부여합니다.

사용자 ID에 권한 할당

겹치지 않고 모든 사용자 작업을 포함하는 역할 집합을 정의해야 하는 애플리케이션의 요구 사항을 평가합니다. 각 사용자를 가장 적절한 역할에 매핑합니다. 업무에 필요한 것만 액세스할 수 있는지 확인합니다.

워크로드 ID에 권한 할당

데이터베이스의 CRUD 작업 또는 비밀 액세스와 같이 작업에 중요한 권한만 부여합니다. 워크로드 ID 권한은 영구적이므로 워크로드 ID에 대한 Just-In-Time 또는 단기 권한을 제공할 수 없습니다.

RBAC(역할 기반 액세스 제어)를 선호합니다. 항상 Azure RBAC를 사용하여 권한을 할당합니다. 정밀한 제어를 제공하여 액세스가 감사 가능하고 세분화되어 있는지 확인합니다. Azure RBAC를 사용하여 서비스에서 의도한 기능을 수행하는 데 필요한 권한만 부여합니다.
Azure 서비스 수준 액세스 제어를 보완합니다. Azure RBAC가 특정 시나리오를 다루지 않는 경우 Azure 서비스 수준 액세스 정책을 보완합니다.

자세한 내용은 다음을 참조하세요.

사용자 인증 및 권한 부여 구성

인증 및 권한 부여는 웹 애플리케이션 보안의 중요한 측면입니다. 인증 은 사용자의 ID를 확인하는 프로세스입니다. 권한 부여 는 사용자가 애플리케이션 내에서 수행할 수 있는 작업을 지정합니다. 목표는 보안 상태를 약화시키지 않고 인증 및 권한 부여를 구현하는 것입니다. 이 목표를 달성하려면 Azure 애플리케이션 플랫폼(Azure 앱 Service) 및 ID 공급자(Microsoft Entra ID)의 기능을 사용해야 합니다.

사용자 인증 구성

플랫폼의 기능을 통해 사용자 인증을 사용하도록 설정하여 웹앱을 보호합니다. Azure 앱 Service는 Microsoft Entra ID와 같은 ID 공급자와의 인증을 지원하여 코드에서 인증 워크로드를 오프로드합니다.

예: 참조 구현에서는 Microsoft Entra ID를 ID 플랫폼으로 사용합니다. Microsoft Entra ID에는 기본 테넌트에서 애플리케이션 등록이 필요합니다. 애플리케이션 등록을 통해 웹앱에 액세스하는 사용자에게 기본 테넌트에 ID가 있는지 확인합니다. 다음 Terraform 코드는 앱 특정 계정 관리자 역할과 함께 Entra ID 앱 등록을 만듭니다.

resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

Key Vault는 클라이언트 구성 데이터를 안전하게 저장하고 App Service 플랫폼은 앱에 정보를 환경 변수로 노출합니다.

ID 공급자와 통합

보안 인증 및 권한 부여를 위해 웹 애플리케이션을 Microsoft Entra ID와 통합합니다. Microsoft Entra ID용 Spring Boot Starter는 쉽게 설정할 수 있는 Spring Security 및 Spring Boot를 활용하여 이 프로세스를 간소화합니다. Spring Cloud 구성 요소와 통합 기능과 함께 다양한 인증 흐름, 자동 토큰 관리 및 사용자 지정 가능한 권한 부여 정책을 제공합니다. 이렇게 하면 수동 라이브러리 또는 설정 구성 없이 Spring Boot 애플리케이션에 간단한 Microsoft Entra ID 및 OAuth 2.0 통합이 가능합니다.

예: 참조 구현에서는 Microsoft ID 플랫폼(Microsoft Entra ID)를 웹앱의 ID 공급자로 사용합니다. OAuth 2.0 인증 코드 부여를 사용하여 Microsoft Entra 계정으로 사용자를 로그인합니다. 다음 XML 코드 조각은 OAuth 2.0 인증 코드 부여 흐름의 두 가지 필수 종속성을 정의합니다. 종속성을 com.azure.spring: spring-cloud-azure-starter-active-directory 통해 Spring Boot 애플리케이션에서 Microsoft Entra 인증 및 권한 부여를 사용할 수 있습니다. 종속성은 org.springframework.boot: spring-boot-starter-oauth2-client Spring Boot 애플리케이션에서 OAuth 2.0 인증 및 권한 부여를 지원합니다.

<dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>

자세한 내용은 Spring Security용 Spring Cloud Azure 지원 참조하세요.

인증 및 권한 부여 비즈니스 규칙 구현

인증 및 권한 부여 비즈니스 규칙을 구현하려면 다양한 애플리케이션 기능 및 리소스에 대한 액세스 제어 정책 및 사용 권한을 정의해야 합니다. Spring Boot Starter for Microsoft Entra ID를 사용하도록 Spring Security를 구성해야 합니다. 이 라이브러리를 사용하면 Microsoft Entra ID와 통합할 수 있으며 사용자가 안전하게 인증되도록 할 수 있습니다. MSAL(Microsoft 인증 라이브러리)을 구성하고 사용하도록 설정하면 더 많은 보안 기능에 액세스할 수 있습니다. 이러한 기능에는 토큰 캐싱 및 자동 토큰 새로 고침이 포함됩니다.

예: 참조 구현은 Contoso Fiber의 계정 관리 시스템에서 사용자 역할 유형을 반영하는 앱 역할을 만듭니다. 역할은 권한 부여 중에 사용 권한으로 변환됩니다. CAMS에서 앱별 역할의 예로는 계정 관리자, 수준 1(L1) 지원 담당자 및 필드 서비스 담당자가 있습니다. 계정 관리자 역할에는 새 앱 사용자 및 고객을 추가할 수 있는 권한이 있습니다. 현장 서비스 담당자는 지원 티켓을 만들 수 있습니다. 특성은 PreAuthorize 특정 역할에 대한 액세스를 제한합니다.

    @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

Microsoft Entra ID와 통합하기 위해 참조 구현은 OAuth 2.0 인증 코드 부여 흐름을 사용합니다. 이 흐름을 사용하면 사용자가 Microsoft 계정으로 로그인할 수 있습니다. 다음 코드 조각에서는 인증 및 권한 부여에 Microsoft Entra ID를 사용하도록 구성하는 SecurityFilterChain 방법을 보여줍니다.

@Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

자세한 내용은 다음을 참조하세요.

서비스 인증 및 권한 부여 구성

사용자 환경의 서비스에 필요한 기능을 수행할 수 있는 권한이 있도록 서비스 인증 및 권한 부여를 구성합니다. Microsoft Entra ID의 관리 ID를 사용하여 서비스 ID의 생성 및 관리를 자동화하여 수동 자격 증명 관리를 제거합니다. 관리 ID를 사용하면 웹앱이 Azure Key Vault 및 데이터베이스와 같은 Azure 서비스에 안전하게 액세스할 수 있습니다. 또한 Azure 앱 Service에 배포하기 위한 CI/CD 파이프라인 통합을 용이하게 합니다. 그러나 하이브리드 배포 또는 레거시 시스템과 같은 시나리오에서는 온-프레미스 인증 솔루션을 계속 사용하여 마이그레이션을 간소화합니다. 시스템이 최신 ID 관리 접근 방식을 사용할 준비가 되면 관리 ID로 전환합니다. 자세한 내용은 관리 ID 모니터링을 참조 하세요.

예: 참조 구현은 데이터베이스(사용자 이름 및 암호)에 대한 온-프레미스 인증 메커니즘을 유지합니다. 따라서 참조 구현은 Key Vault에 데이터베이스 비밀을 저장합니다. 웹앱은 관리 ID(시스템 할당)를 사용하여 Key Vault에서 비밀을 검색합니다.

중앙 비밀 저장소를 사용하여 비밀 관리

애플리케이션을 클라우드로 이동하는 경우 Azure Key Vault를 사용하여 이러한 모든 비밀을 안전하게 저장합니다. 이 중앙 집중식 리포지토리는 관리 ID를 지원하지 않는 서비스에 대한 보안 스토리지, 키 회전, 액세스 감사 및 모니터링을 제공합니다. 애플리케이션 구성의 경우 Azure 앱 구성을 사용하는 것이 좋습니다.

예: 참조 구현은 Key Vault에 다음 비밀을 저장합니다. (1) PostgreSQL 데이터베이스 사용자 이름 및 암호, (2) Redis Cache 암호 및 (3) MSAL 구현과 연결된 Microsoft Entra ID의 클라이언트 암호입니다.

HTTP 요청 흐름에 Key Vault를 배치하지 마세요.

각 HTTP 요청 중에 대신 애플리케이션 시작 시 Key Vault에서 비밀을 로드합니다. Key Vault는 배포 중에 중요한 데이터를 안전하게 저장하고 검색하기 위한 것입니다. HTTP 요청 내의 고주파 액세스는 Key Vault의 처리량 기능을 초과할 수 있으므로 요청 제한 사항 및 HTTP 상태 코드 429 오류가 발생합니다. 자세한 내용은 Key Vault 트랜잭션 제한을 참조 하세요.

한 가지 방법을 사용하여 Key Vault의 비밀에 액세스

Key Vault의 비밀에 액세스하도록 웹앱을 구성하는 경우 두 가지 기본 옵션이 있습니다.

App Service 앱 설정: App Service의 앱 설정을 사용하여 비밀을 환경 변수로 직접 삽입합니다.
직접 비밀 참조: 애플리케이션 코드 내에서 비밀을 직접 참조합니다. 앱이 Key Vault와 통신할 수 있도록 Java 애플리케이션과 같은 application.properties 애플리케이션의 속성 파일에 특정 참조를 추가합니다.

이러한 방법 중 하나를 선택하고 단순성을 위해 이를 고수하고 불필요한 복잡성을 방지하는 것이 중요합니다. Key Vault를 Spring 애플리케이션과 통합하기 위해 프로세스에는 다음이 포함됩니다.

pom.xml 파일에 Azure Key Vault 비밀 종속성에 대한 Azure Spring Boot Starter를 추가합니다.
애플리케이션에서 Key Vault 엔드포인트를 구성합니다. 이 작업은 application.properties 파일을 통해 또는 환경 변수로 수행할 수 있습니다.

예: 참조 구현은 App Service에서 앱 설정을 사용하고 비밀을 삽입합니다.

프라이빗 엔드포인트 사용

지원되는 모든 Azure 서비스에 대해 모든 프로덕션 환경에서 프라이빗 엔드포인트를 사용합니다. 프라이빗 엔드포인트는 Azure 가상 네트워크와 Azure 서비스의 리소스 간에 프라이빗 연결을 제공합니다. 기본적으로 대부분의 Azure 서비스에 대한 통신은 공용 인터넷을 교차합니다. 프라이빗 엔드포인트에는 코드 변경, 앱 구성 또는 연결 문자열 필요하지 않습니다. 자세한 내용은 엔드포인트 보안에 대한 프라이빗 엔드포인트 및 모범 사례를 만드는 방법을 참조하세요.

예제: 참조 구현은 Key Vault, Azure Cache for Redis 및 Azure Database for PostgreSQL에 프라이빗 엔드포인트를 사용합니다.

웹 애플리케이션 방화벽 사용

웹앱에 대한 모든 인바운드 인터넷 트래픽은 일반적인 웹 악용으로부터 보호하기 위해 웹 애플리케이션 방화벽을 통과해야 합니다. 모든 인바운드 인터넷 트래픽이 공용 부하 분산 장치(있는 경우) 및 웹 애플리케이션 방화벽을 통과하도록 합니다. (1) Azure Front Door 프라이빗 엔드포인트를 사용하거나 (2) 헤더 값으로 X-Azure-FDID 요청을 필터링할 수 있습니다.

App Service 플랫폼 및 Java Spring은 헤더 값으로 필터링할 수 있습니다. App Service를 첫 번째 옵션으로 사용해야 합니다. 플랫폼 수준에서 필터링하면 원치 않는 요청이 코드에 도달하지 못하게 됩니다. 웹 애플리케이션 방화벽을 통과하려는 트래픽을 구성해야 합니다. 호스트 이름, 클라이언트 IP 및 기타 값을 기준으로 필터링할 수 있습니다. 자세한 내용은 원래 HTTP 호스트 이름 유지를 참조 하세요.

예: 참조 구현은 프로덕션 환경의 프라이빗 엔드포인트와 개발 환경의 X-Azure-FDID 헤더 값을 사용합니다.

데이터베이스 보안 구성

관리 데이터베이스에 대한 주 서버 수준 액세스 권한은 권한 있는 작업을 수행할 수 있는 권한을 부여합니다. 권한 있는 작업에는 데이터베이스 만들기 및 삭제, 테이블 스키마 수정 또는 사용자 권한 변경이 포함됩니다. 개발자는 데이터베이스를 기본 문제를 해결하기 위해 관리자 수준의 액세스 권한이 필요한 경우가 많습니다.

영구 관리자 권한은 사용하지 않습니다. 개발자에게 권한 있는 작업을 수행할 수 있는 Just-In-Time 액세스 권한을 부여합니다. Just-In-Time 액세스를 통해 사용자는 권한 있는 작업을 수행할 수 있는 임시 권한을 받습니다.
애플리케이션에 상승된 권한을 부여하지 마세요. 애플리케이션 ID에 대한 관리자 수준 액세스 권한을 부여하지 마세요. 데이터베이스에 대한 애플리케이션에 대한 최소 권한 액세스를 구성합니다. 버그 및 보안 위반의 폭발 반경을 제한합니다. Azure PostgreSQL 데이터베이스에 액세스하는 두 가지 기본 방법이 있습니다. Microsoft Entra 인증 또는 PostgreSQL 인증을 사용할 수 있습니다. 자세한 내용은 Azure PostgreSQL을 사용하는 JDBC를 참조 하세요.

비용 최적화

비용 최적화는 불필요한 비용과 관리 오버헤드를 줄이는 방법을 찾는 것입니다. 자세한 내용은 디자인 검토 검사 비용 최적화 목록을 참조하세요. 신뢰할 수 있는 웹앱 패턴은 비용 최적화 웹앱에 대한 권한 부여 기술, 자동 크기 조정 및 효율적인 리소스 사용을 구현합니다.

각 환경에 대한 리소스 권한 부여

Azure 서비스의 다양한 성능 계층을 이해하고 각 환경의 요구에 적합한 SKU만 사용합니다. 프로덕션 환경에는 SLA(서비스 수준 계약), 기능 및 프로덕션에 필요한 규모를 충족하는 SKU가 필요합니다. 비프로덕션 환경은 일반적으로 동일한 기능이 필요하지 않습니다. 추가 절감을 위해 컴퓨팅에 대한 Azure 개발/테스트 가격 책정 옵션, Azure Reservations 및 Azure 절감 계획을 고려합니다.

예: Azure 개발/테스트 가격 책정이 구성 요소를 포함하지 않았기 때문에 참조 구현은 Azure 개발/테스트 가격 책정을 사용하지 않습니다. Azure Database for PostgreSQL은 클라우드 단계에서 이 초기 수렴 이후 최소 1년 동안 이 데이터베이스 엔진을 유지하려는 계획에 따라 예약 인스턴스의 주요 후보입니다. 참조 구현에는 다른 SKU를 배포하는 선택적 매개 변수가 있습니다. 환경 매개 변수는 Terraform 템플릿에 개발 SKU를 선택하도록 지시합니다. 다음 코드에서는 이 환경 매개 변수를 보여 줍니다.

azd env set APP_ENVIRONMENT prod

Contoso Fiber는 개발 및 프로덕션 배포를 위해 IaC(Infrastructure-as-code) 템플릿을 사용합니다. 개발 환경은 앱 개발에 필요한 가장 저렴한 SKU를 사용하여 비용 최적화됩니다. 프로덕션 환경에서는 애플리케이션의 프로덕션 서비스 수준 목표 요구 사항을 충족하는 SKU를 사용합니다.

자동 크기 조정 사용

자동 크기 조정은 프로덕션 환경에 대한 수평 크기 조정을 자동화합니다. 성능 메트릭에 따라 자동 크기 조정 애플리케이션의 크기 조정 조건을 이해하지 못하는 경우 CPU 사용률 성능 트리거는 좋은 시작점입니다. 웹 애플리케이션의 동작에 맞게 크기 조정 트리거(CPU, RAM, 네트워크 및 디스크)를 구성하고 조정해야 합니다. 수요가 자주 변경되는 경우를 충족하기 위해 수직으로 크기를 조정하지 마세요. 비용 효율성이 떨어집니다. 자세한 내용은 Microsoft Azure의 Azure 앱 Service 및 자동 크기 조정에서 크기 조정을 참조하세요.

리소스를 효율적으로 사용

효율적인 리소스 사용에는 클라우드 리소스를 전략적으로 관리하고 할당하여 낭비 없이 조직의 요구 사항을 충족해야 합니다. 불필요한 리소스 지출 및 관리 오버헤드를 최소화합니다. 리소스 효율성을 개선하려면 다음 권장 사항을 따릅니다.

공유 서비스를 사용합니다. 특정 리소스를 중앙 집중화하고 공유하면 비용 최적화 및 관리 오버헤드가 줄어듭니다. 예를 들어 공유 네트워크 리소스를 허브 가상 네트워크에 배치합니다.
사용하지 않는 환경을 삭제합니다. 비용을 최적화하기 위해 몇 시간 후 또는 휴일 동안 비프로덕션 환경을 삭제합니다. 인프라를 코드로 사용하여 Azure 리소스 및 전체 환경을 삭제할 수 있습니다. 코드 기반 인프라 템플릿에서 삭제하려는 리소스의 선언을 제거합니다. 나중에 필요한 데이터를 백업합니다. 삭제하는 리소스에 대한 종속성을 이해합니다. 종속성이 있는 경우 해당 리소스도 업데이트하거나 제거해야 할 수 있습니다.
공동 배치 기능 여분의 용량이 있는 경우 단일 Azure 리소스에 애플리케이션 리소스 및 기능을 공동 배치합니다. 예를 들어 여러 웹앱이 단일 서버(App Service 계획)를 사용하거나 단일 캐시가 여러 데이터 형식을 지원할 수 있습니다.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성에 대한 디자인 검토 검사 목록을 참조하세요. 신뢰할 수 있는 웹앱 패턴은 인프라 배포 및 모니터링을 위한 코드로 인프라를 구현합니다.

모니터링 구성

추적 및 디버깅의 경우 요청이 실패할 때 로깅을 사용하도록 설정하여 진단해야 합니다. 애플리케이션에서 수집하는 원격 분석은 운영 요구 사항을 충족해야 합니다. 최소한 기준 메트릭에 대한 원격 분석을 수집해야 합니다. 대상 개선 사항을 적용하는 데 도움이 되는 사용자 동작에 대한 정보를 수집해야 합니다.

기준 메트릭 모니터링

워크로드는 기준 메트릭을 모니터링해야 합니다. 측정할 중요한 메트릭에는 요청 처리량, 평균 요청 기간, 오류 및 모니터링 종속성이 포함됩니다. Application Insights를 사용하여 이 원격 분석을 수집하는 것이 좋습니다.

예: 참조 구현은 Application Insights를 사용합니다. Application Insights는 App Service의 app_settings 구성의 일부로 Terraform을 통해 사용하도록 설정됩니다.

app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}

Spring Boot는 Java JVM(가상 머신), CPU, Tomcat 등과 같은 Application Insights에 여러 핵심 메트릭을 등록합니다. Application Insights는 Log4j 및 Logback과 같은 로깅 프레임워크에서 자동으로 수집합니다. 자세한 내용은 다음을 참조하세요.

Spring Boot용 Azure Monitor Application Insights 구성
구성 옵션 - Java용 Azure Monitor Application Insights - Azure Monitor
Java 애플리케이션에 Azure Monitor OpenTelemetry 사용
Spring Boot에서 Azure Monitor Application Insights 사용.

필요에 따라 사용자 지정 원격 분석 및 메트릭 만들기

Application Insights의 기준 메트릭 외에도 사용자 및 애플리케이션과의 상호 작용을 더 잘 이해할 수 있도록 사용자 지정 원격 분석을 만들어야 합니다. Application Insights를 사용하면 사용자 지정 원격 분석을 수집할 수 있으며 마이크로미터를 통해 사용자 지정 메트릭을 수집할 수도 있습니다. 목표는 애플리케이션의 성능 및 사용자 동작에 대한 심층적인 인사이트를 확보하여 보다 합리적인 의사 결정 및 개선 작업을 수행할 수 있도록 하는 것입니다.

로그 기반 메트릭 수집

로그 기반 메트릭을 추적하여 필수 애플리케이션 상태 및 메트릭에 대한 가시성을 높입니다. Application Insights에서 KQL(Kusto 쿼리 언어) 쿼리를 사용하여 데이터를 찾고 구성할 수 있습니다. 자세한 내용은 Azure 애플리케이션 Insights 로그 기반 메트릭 및 Application Insights의 로그 기반 및 사전 집계 메트릭을 참조하세요.

플랫폼 진단 사용

Azure의 진단 설정을 사용하면 수집하려는 플랫폼 로그 및 메트릭을 지정하고 저장할 위치를 지정할 수 있습니다. 플랫폼 로그는 진단 및 감사 정보를 제공하는 기본 제공 로그입니다. 대부분의 Azure 서비스에 대해 플랫폼 진단 사용하도록 설정할 수 있지만 각 서비스는 자체 로그 범주를 정의합니다. 다른 Azure 서비스에는 선택할 로그 범주가 있습니다.

지원되는 모든 서비스에 대해 진단 사용하도록 설정합니다. Azure 서비스는 플랫폼 로그를 자동으로 만들지만 서비스는 자동으로 저장하지 않습니다. 각 서비스에 대해 진단 설정을 사용하도록 설정해야 하며, 진단 지원하는 모든 Azure 서비스에 대해 사용하도록 설정해야 합니다.
애플리케이션 로그와 동일한 대상으로 진단 보냅니다. 진단 사용하도록 설정하면 수집하려는 로그와 보낼 위치를 선택합니다. 두 데이터 세트의 상관 관계를 지정할 수 있도록 플랫폼 로그를 애플리케이션 로그와 동일한 대상으로 보내야 합니다.

예: 참조 구현은 Terraform을 사용하여 지원되는 모든 서비스에서 Azure 진단 사용하도록 설정합니다. 다음 Terraform 코드는 App Service에 대한 진단 설정을 구성합니다.

# Configure Diagnostic Settings for App Service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

CI/CD 파이프라인 사용

배포를 자동화하려면 CI/CD(연속 통합/지속적인 배포) 파이프라인을 통합합니다. 이 자동화는 소스 제어에서 테스트, 스테이징 및 프로덕션을 비롯한 다양한 App Service 환경으로 직접 확장되어야 합니다. GitHub 프로젝트용 Azure DevOps 또는 GitHub Actions를 사용하는 경우 Azure Pipelines를 활용합니다.

단위 테스트를 통합합니다. App Services에 배포하기 전에 파이프라인 내에서 모든 단위 테스트(JUnit 사용)의 실행 및 전달 우선 순위를 지정합니다. SonarQube 및 JaCoCo와 같은 코드 품질 및 검사 도구를 통합하여 포괄적인 테스트 범위를 달성합니다.
Java 모의 프레임워크를 채택합니다. 외부 엔드포인트를 포함하는 테스트를 위해 Java 모의 프레임워크(Mockito, EasyMock)를 활용합니다. 이러한 프레임워크를 사용하면 시뮬레이션된 엔드포인트를 만들 수 있습니다. 실제 외부 엔드포인트를 구성하고 환경 전체에서 균일한 테스트 조건을 보장할 필요가 없습니다.
보안 검사를 수행합니다. SAST(정적 애플리케이션 보안 테스트)를 사용하여 소스 코드에서 보안 결함 및 코딩 오류를 찾습니다. 또한 SCA(소프트웨어 컴퍼지션 분석)를 수행하여 타사 라이브러리 및 구성 요소에서 보안 위험을 검사합니다. 이러한 분석을 위한 도구는 GitHub와 Azure DevOps 모두에 쉽게 통합됩니다.

프로덕션 배포 관리

프로덕션에 코드를 배포하기 위한 지침을 설정하고 모든 프로덕션 배포에 대한 승인 프로세스를 만들어야 합니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요. 신뢰할 수 있는 웹앱 패턴은 캐시 배제 패턴을 사용하여 요청이 많은 데이터의 대기 시간을 최소화합니다.

캐시 배제 패턴 사용

캐시 배제 패턴은 메모리 내 데이터 관리를 개선하는 캐싱 전략입니다. 이 패턴은 데이터 요청을 처리하고 캐시와 영구 스토리지(예: 데이터베이스) 간의 일관성을 보장하는 책임을 애플리케이션에 할당합니다. 웹앱이 데이터 요청을 받으면 먼저 캐시를 검색합니다. 데이터가 누락된 경우 데이터베이스에서 검색하고 요청에 응답하며 그에 따라 캐시를 업데이트합니다. 이 방법은 응답 시간을 단축하고 처리량을 향상시키고 더 많은 크기 조정의 필요성을 줄입니다. 또한 기본 데이터 저장소의 부하를 줄이고 중단 위험을 최소화하여 서비스 가용성을 강화합니다.

캐싱 설정

캐싱을 사용하도록 설정하려면 파일에 패키지를 종속성으로 추가 spring-boot-starter-cache 합니다 pom.xml . 패키지는 spring-boot-starter-cache 기본값으로 Redis 캐시를 구성합니다. 웹앱의 요구 사항에 맞게 파일 또는 환경 변수에서 해당 값을 application.properties 업데이트해야 합니다. 예를 들어 spring.cache.redis.time-to-live (밀리초 단위로 나타낸) 데이터가 제거되기 전에 캐시에서 다시 기본 시간을 결정합니다. 웹앱의 요구 사항을 충족하는 값을 제공해야 합니다. 마지막으로 주석을 사용하여 @Cacheable 코드에 필요한 데이터를 캐시해야 합니다.

필요한 데이터 캐시

가장 자주 액세스하는 데이터에 대한 캐싱 우선 순위를 지정합니다. 사용자 참여 및 시스템 성능을 구동하는 주요 데이터 요소를 식별합니다. 캐시 배제 패턴의 효율성을 최적화하기 위해 이러한 영역에 대한 캐싱 전략을 구현하여 대기 시간 및 데이터베이스 부하를 크게 줄입니다. Azure Monitor를 사용하여 데이터베이스의 CPU, 메모리 및 스토리지를 추적합니다. 이러한 메트릭은 더 작은 데이터베이스 SKU를 사용할 수 있는지 여부를 결정하는 데 도움이 됩니다.

캐시 데이터를 최신 상태로 유지

최신 데이터베이스 변경 내용과 동기화하도록 일반 캐시 업데이트를 예약합니다. 데이터 변동성 및 사용자 요구에 따라 최적의 새로 고침 속도를 결정합니다. 이렇게 하면 애플리케이션이 Cache-Aside 패턴을 사용하여 빠른 액세스 및 현재 정보를 모두 제공할 수 있습니다.

데이터 일관성 보장

데이터베이스 쓰기 작업 직후 캐시를 업데이트하는 메커니즘을 구현합니다. 이벤트 기반 업데이트 또는 전용 데이터 관리 클래스를 사용하여 캐시 일관성을 보장합니다. 캐시를 데이터베이스 수정과 일관되게 동기화하는 것은 캐시 배제 패턴의 핵심입니다.

예제: 다음 코드는 캐싱을 사용하도록 설정하기 위해 pom.xml 패키지를 파일에 종속성으로 추가 spring-boot-starter-cache 합니다.

<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-cache</artifactid>
</dependency>

참조 구현을 사용하면 파일에서 Redis를 application.properties 사용할 수 있습니다.

# Redis
spring.data.redis.ssl.enabled=true
spring.session.redis.namespace=spring:session

다음 코드는 .라는 getAccountDetail메서드를 정의합니다. 메서드는 지정된 사용자 이름과 연결된 사용자 설정을 검색합니다. 메서드 @Cacheable(value="account-details", key="#id") 에 주석을 getAccountDetail달고 웹앱에 캐시에 사용자 설정을 캐시하도록 지시합니다.

    @Cacheable(value="account-details", key="#id")
    public AccountDetail getAccountDetail(Long id) {
        Optional<Account> optionalAccount = accountRepository.findById(id);
        if (optionalAccount.isEmpty()) {
            throw new IllegalArgumentException("Account ID " + id + " does not exist");
        }

        Account account = optionalAccount.get();
        AccountDetail accountDetail = mapToAccountDetail(account);

        return accountDetail;
    }

데이터베이스 성능

데이터베이스 성능은 애플리케이션의 성능 및 확장성에 영향을 줄 수 있습니다. 데이터베이스의 성능을 테스트하여 최적화되었는지 확인하는 것이 중요합니다. 몇 가지 주요 고려 사항에는 올바른 클라우드 지역 선택, 연결 풀링, 캐시 배제 패턴 및 쿼리 최적화가 포함됩니다.

네트워크 홉을 테스트합니다. 애플리케이션을 클라우드로 이동하면 데이터베이스에 추가 네트워크 홉과 대기 시간이 발생할 수 있습니다. 새 클라우드 환경에서 도입하는 추가 홉을 테스트해야 합니다.
성능 기준선을 설정합니다. 클라우드의 애플리케이션 성능을 비교하려면 온-프레미스 성능 메트릭을 초기 기준으로 사용해야 합니다.
Application Insights를 사용합니다. Application Insights는 데이터베이스 쿼리 및 모든 JDBC 인터페이스에 대한 자세한 메트릭을 제공합니다. 이식된 데이터베이스가 해당 SLA를 충족하는지 확인하거나 조정해야 하는 쿼리를 찾는 데 사용해야 합니다. 보안 및 성능 문제가 발생하므로 동적 SQL을 사용하면 안 됩니다.
연결 풀을 사용합니다. JDBC 연결 풀을 사용하고 TPS(초당 트랜잭션 수) 메트릭 및 SLA에 따라 미세 조정해야 합니다. 데이터베이스 성능 모니터링 도구를 사용하여 로드 중인 데이터베이스 성능을 테스트하고 평가해야 합니다.

다음 단계

GitHub 리포지토리의 지침에 따라 참조 구현을 배포합니다. 다음 리소스를 사용하여 클라우드 모범 사례 및 마이그레이션에 대해 자세히 알아봅니다.

클라우드 모범 사례. Azure 채택 및 아키텍처 지침은 다음을 참조하세요.

클라우드 채택 프레임워크. 조직이 Azure에서 솔루션을 빌드하기 위한 전략을 준비하고 실행하는 데 도움이 되는 프레임워크입니다.
잘 설계된 프레임워크입니다. 워크로드의 품질을 개선하는 데 사용되는 기본 지침 모음입니다.

더 높은 SLO(서비스 수준 목표)가 필요한 애플리케이션은 중요 업무용 워크로드를 참조 하세요.

마이그레이션 지침입니다. 다음 도구와 리소스는 온-프레미스 리소스를 Azure로 마이그레이션하는 데 도움이 될 수 있습니다.

Azure Migrate 는 웹앱, SQL Server 및 가상 머신의 평가 및 마이그레이션을 처리하는 Azure에 대한 간소화된 마이그레이션, 현대화 및 최적화 서비스를 제공합니다.
Azure Database Migration Guides는 다양한 데이터베이스 유형에 대한 리소스와 마이그레이션 시나리오를 위해 설계된 도구를 제공합니다.
Azure 앱 Service 랜딩 존 가속기는 App Service 배포를 강화하고 크기 조정하기 위한 지침을 제공합니다.

다음을 통해 공유