Watch demos on how to build & run AI-powered apps with Firebase at Demo Day '24. Watch now.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

App Hosting 백엔드 구성 및 관리

App Hosting는 사용 편의성과 유지보수 용이성을 위해 설계되었으며 기본 설정은 대부분의 사용 사례에 최적화되어 있습니다. 동시에 App Hosting는 특정 요구사항에 맞게 백엔드를 관리하고 구성할 수 있는 도구를 제공합니다. 이 가이드에서는 이러한 도구와 프로세스를 설명합니다.

백엔드 구성

환경 변수와 같은 고급 구성이나 동시 실행, CPU, 메모리 한도와 같은 런타임 설정의 경우 앱의 루트 디렉터리에서 apphosting.yaml 파일을 만들고 수정해야 합니다. 또한 이 파일은 Cloud Secret Manager로 관리되는 보안 비밀에 대한 참조를 지원하므로 소스 제어에 안전하게 체크인할 수 있습니다.

apphosting.yaml를 만들려면 다음 명령어를 실행합니다.

firebase init apphosting

이렇게 하면 예시 (주석 처리된) 구성이 포함된 기본 시작 apphosting.yaml 파일이 생성됩니다. 수정 후 일반적인 apphosting.yaml 파일은 백엔드의 Cloud Run 서비스 설정, 일부 환경 변수, Cloud Secret Manager에서 관리하는 보안 비밀 참조와 함께 다음과 같이 표시될 수 있습니다.

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

이 가이드의 나머지 부분에서는 이러한 설정 예시와 관련된 자세한 정보와 맥락을 제공합니다.

Cloud Run 서비스 설정 구성

apphosting.yaml 설정을 사용하면 Cloud Run 서비스가 프로비저닝되는 방식을 구성할 수 있습니다. Cloud Run 서비스에 사용할 수 있는 설정은 runConfig 객체에 제공됩니다.

cpu – 각 게재 인스턴스에 사용되는 CPU 수입니다 (기본값 0).
memoryMiB – 각 게재 인스턴스에 할당된 메모리 양(MiB, 기본값 512)
maxInstances – 한 번에 실행할 수 있는 최대 컨테이너 수입니다 (기본값은 100이며 할당량으로 관리됨).
minInstances – 항상 연결 상태를 유지할 컨테이너 수입니다 (기본값: 0).
concurrency: 각 게재 인스턴스가 수신할 수 있는 최대 요청 수입니다 (기본값: 80).

cpu와 memoryMiB 간의 중요한 관계에 유의하세요. 메모리는 128~32, 768 사이의 정수 값으로 설정할 수 있지만 메모리 한도를 늘리려면 CPU 한도를 늘려야 할 수 있습니다.

4GiB를 초과하는 경우 CPU가 2개 이상 필요합니다.
8GiB를 초과하는 경우 CPU가 4개 이상 필요합니다.
16GiB를 초과하는 경우 CPU가 6개 이상 필요합니다.
24GiB를 초과하는 경우 CPU가 8개 이상 필요합니다.

마찬가지로 cpu 값은 동시 실행 설정에 영향을 미칩니다. CPU 값을 1보다 작게 설정하면 동시 실행을 1로 설정해야 하며 CPU는 요청 처리 중에만 할당됩니다.

빌드 환경 구성

경우에 따라 서드 파티 API 키 또는 조정 가능한 설정과 같은 빌드 프로세스에 추가 구성이 필요할 수 있습니다. App Hosting는 apphosting.yaml에서 환경 구성을 제공하여 프로젝트에 이러한 유형의 데이터를 저장하고 검색할 수 있도록 지원합니다.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app

Next.js 앱의 경우 환경 변수가 포함된 dotenv 파일도 App Hosting에서 작동합니다. 모든 프레임워크에서 세분화된 환경 변수 제어를 위해 apphosting.yaml를 사용하는 것이 좋습니다.

apphosting.yaml에서 availability 속성을 사용하여 환경 변수에 액세스할 수 있는 프로세스를 지정할 수 있습니다. 환경 변수를 빌드 환경에서만 사용할 수 있도록 제한하거나 런타임 환경에서만 사용할 수 있도록 제한할 수 있습니다. 기본적으로 둘 다 사용할 수 있습니다.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

Next.js 앱의 경우 dotenv 파일에서와 동일한 방식으로 NEXT_PUBLIC_ 접두사를 사용하여 브라우저에서 변수에 액세스할 수 있습니다.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

유효한 변수 키는 A~Z 문자 또는 밑줄로 구성됩니다. 일부 환경 변수 키는 내부에서 사용하도록 예약되어 있습니다. 구성 파일에는 다음 키를 사용하지 마세요.

X_FIREBASE_로 시작하는 모든 변수
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION

보안 비밀 매개변수 저장 및 액세스

API 키와 같은 민감한 정보는 보안 비밀로 저장해야 합니다. apphosting.yaml에서 보안 비밀을 참조하여 민감한 정보를 소스 제어에 확인하지 않을 수 있습니다.

secret 유형의 매개변수는 Cloud Secret Manager에 값이 저장된 문자열 매개변수를 나타냅니다. 보안 비밀 매개변수는 값을 직접 파생하는 대신 Cloud Secret Manager의 존재 여부를 확인하고 출시 중에 값을 로드합니다.

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager의 보안 비밀에는 여러 버전이 있을 수 있습니다. 기본적으로 라이브 백엔드에서 사용할 수 있는 보안 비밀 매개변수의 값은 백엔드가 빌드될 때 사용 가능한 최신 보안 비밀 버전에 고정됩니다. 매개변수의 버전 관리 및 수명 주기 관리에 관한 요구사항이 있는 경우 Cloud Secret Manager를 사용하여 특정 버전에 고정할 수 있습니다. 예를 들어 버전 5에 고정하려면 다음을 실행합니다.

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

CLI 명령어 firebase apphosting:secrets:set를 사용하여 보안 비밀을 만들 수 있으며 필요한 권한을 추가하라는 메시지가 표시됩니다. 이 흐름을 사용하면 apphosting.yaml에 보안 비밀 참조를 자동으로 추가할 수 있습니다.

Cloud Secret Manager의 모든 기능을 사용하려면 대신 Cloud Secret Manager 콘솔을 사용하세요. 이 경우 CLI 명령어 firebase apphosting:secrets:grantaccess를 사용하여 App Hosting 백엔드에 권한을 부여해야 합니다.

Firebase 인증 상태 동기화

Firebase 인증을 사용하는 앱은 클라이언트와 서버 간에 인증 상태를 동기화하는 데 도움이 되도록 Firebase 웹 SDK를 사용하는 것이 좋습니다. 이는 서비스 워커로 FirebaseServerApp를 구현하여 쉽게 할 수 있습니다. 기본 작업 흐름은 다음과 같습니다.

서버에 대한 요청 시 앱에 적절한 헤더를 추가하는 서비스 워커를 구현합니다.
서버의 요청에서 헤더를 가져와 FirebaseServerApp를 사용하여 인증 사용자로 변환합니다.

백엔드 관리

App Hosting 백엔드의 기본 관리를 위한 명령어는 Firebase CLI에 제공됩니다. 일부 작업은 Firebase 콘솔에서도 사용할 수 있습니다. 이 섹션에서는 백엔드 생성 및 삭제를 비롯한 몇 가지 일반적인 관리 작업을 설명합니다.

백엔드 만들기

App Hosting 백엔드는 App Hosting가 웹 앱을 빌드하고 실행하기 위해 만드는 관리 리소스 모음입니다. 모든 프로젝트 소유자는 Firebase 콘솔 또는 Firebase CLI를 사용하여 프로젝트의 첫 번째 App Hosting 백엔드를 만들 수 있습니다. 이 초기 설정 후 App Hosting 관리자는 추가 백엔드를 만들고 관리할 수도 있습니다. 자세한 내용은 Firebase App Hosting IAM 역할을 참고하세요.

Firebase Console: 빌드 메뉴에서 앱 호스팅을 선택한 다음 시작하기를 선택합니다.

CLI: (버전 13.15.4 이상) 백엔드를 만들려면 로컬 프로젝트 디렉터리의 루트에서 다음 명령어를 실행하고 projectID 및 기본 region을 인수로 제공합니다.

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

콘솔과 CLI 모두에서 메시지에 따라 백엔드에 이름을 할당하고, GitHub 연결을 설정하고, 다음과 같은 기본 배포 설정을 구성합니다.

앱의 루트 디렉터리를 설정합니다 (기본값: /).

일반적으로 package.json 파일이 있는 폴더입니다.

실시간 브랜치 설정

이는 라이브 URL에 배포되는 GitHub 저장소의 브랜치입니다. 종종 기능 브랜치 또는 개발 브랜치가 병합되는 브랜치입니다.
자동 출시 수락 또는 거부하기

자동 출시는 기본적으로 사용 설정되어 있습니다. 백엔드 생성이 완료되면 앱을 App Hosting에 즉시 배포하도록 선택할 수 있습니다.

백엔드 삭제

백엔드를 완전히 삭제하려면 먼저 Firebase CLI를 사용한 다음 관련 애셋을 수동으로 삭제합니다. 이때 다른 백엔드나 Firebase 프로젝트의 다른 측면에서 사용할 수 있는 리소스는 삭제하지 않도록 주의하세요.

다음 명령어를 실행하여 App Hosting 백엔드를 삭제합니다. 이렇게 하면 백엔드의 모든 도메인이 사용 중지되고 연결된 Cloud Run 서비스가 삭제됩니다.
```
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
```
(선택사항) Artifact Registry의 Google Cloud 콘솔 탭에서 'firebaseapphosting-images'의 백엔드 이미지를 삭제합니다.
Cloud Secret Manager에서 보안 비밀 이름에 'apphosting'이 포함된 보안 비밀을 삭제합니다. 이러한 보안 비밀이 다른 백엔드 또는 Firebase 프로젝트의 다른 측면에서 사용되지 않도록 각별히 주의합니다.