Azure 앱을 빌드하기 위한 주요 개념

Azure에서 실행되도록 애플리케이션을 너무 멀리 디자인하기 전에 미리 약간의 계획을 세워야 할 수 있습니다. 시작할 때 시나리오에 가장 적합한 결정을 내리기 위해 이해해야 하는 몇 가지 기본 Azure 개념이 있습니다. 고려해야 할 사항은 다음과 같습니다.

Azure 지역

지역은 대기 시간이 정의된 경계 내에 배치되고, 지역별 짧은 대기 시간 네트워크를 통해 연결된 데이터 센터의 집합입니다. Azure는 필요할 때 지역 간 복원력을 제공하기 위해 여러 지역을 포함하여 필요한 곳에 애플리케이션을 배포할 수 있는 유연성을 제공합니다.

일반적으로 애플리케이션의 여러 구성 요소 간의 대기 시간을 최소화하기 위해 솔루션에 대한 모든 리소스가 동일한 지역에 있어야 합니다. 즉, 솔루션이 Azure 앱 Service, 데이터베이스 및 Azure Blob Storage로 구성된 경우 이러한 모든 리소스를 동일한 Azure 지역에 만들어야 합니다.

모든 지역에서 모든 Azure 서비스를 사용할 수 있는 것은 아닙니다. 지역 페이지에서 사용할 수 있는 제품은 앱에 필요한 Azure 서비스를 사용할 수 있는 지역을 찾는 데 도움이 될 수 있습니다.

Azure 리소스 그룹

Azure의 리소스 그룹은 Azure 리소스를 함께 그룹화하기 위한 논리적 컨테이너입니다. 모든 Azure 리소스는 하나의 리소스 그룹에만 속해야 합니다.

리소스 그룹은 Azure의 솔루션에 필요한 모든 Azure 리소스를 그룹화하기 위해 가장 자주 사용됩니다. 예를 들어 SQL 데이터베이스, Azure Storage 및 Azure Key Vault를 사용하는 Azure 앱 Service에 배포된 웹 애플리케이션을 예로 들어 보겠습니다. 이 솔루션에 필요한 모든 Azure 리소스를 단일 리소스 그룹에 배치하는 것이 일반적입니다.

이렇게 하면 애플리케이션을 실행하는 데 필요한 리소스와 서로 관련된 리소스를 쉽게 알 수 있습니다. 따라서 Azure에서 앱에 대한 리소스를 만드는 첫 번째 단계는 일반적으로 앱 리소스의 컨테이너 역할을 하는 리소스 그룹을 만드는 것입니다.

환경

온-프레미스를 개발한 경우 개발, 테스트 및 프로덕션 환경을 통해 코드를 승격하는 데 익숙합니다. Azure에서 별도의 환경을 만들려면 필요한 각 환경에 대해 별도의 Azure 리소스 집합을 만듭니다.

각 환경은 정확한 복사본이어야 하므로 환경에 필요한 리소스 생성을 스크립션하거나 IaC(Infrastructure as Code) 도구를 사용하여 각 환경의 구성을 선언적으로 지정하는 것이 좋습니다. 이렇게 하면 환경 만들기 프로세스가 반복 가능하고, 애플리케이션의 성능 또는 보안 테스트와 같이 요청 시 새 환경을 스핀업할 수 있습니다.

DevOps 지원

연속 통합을 사용하여 Azure에 앱을 게시하든, 새 환경에 대한 리소스를 프로비전하든, Azure는 대부분의 인기 있는 DevOps 도구와 통합됩니다. 이미 있는 도구를 사용하여 작업하고 다음과 같은 도구를 지원하여 기존 환경을 최대화할 수 있습니다.

• GitHub Actions
• Azure DevOps
• 문어 배포
• Jenkins
• Terraform
• Ansible
• Chef