콘솔로 이동

Cloud Firestore 권장사항

Cloud Firestore를 사용하는 애플리케이션을 빌드할 때 여기에 나열된 권장사항을 빠른 참조로 활용하세요.

문서 ID

  • 문서 ID에 ... 부호를 사용하지 않습니다.
  • 문서 ID에 슬래시(/)를 사용하지 않습니다.
  • 다음과 같이 단조롭게 증가하는 문서 ID를 사용하지 않습니다.

    • Customer1, Customer2, Customer3, ...
    • Product 1, Product 2, Product 3, ...

    이러한 순차 ID를 사용하면 지연에 영향을 미치는 부하 집중이 발생할 수 있습니다.

필드 이름

  • 다음과 같은 문자는 추가 이스케이프 처리가 필요하기 때문에 필드 이름에 사용하지 않습니다.

    • . 마침표
    • [ 왼쪽 대괄호
    • ] 오른쪽 대괄호
    • * 별표
    • ` 역따옴표

색인

  • 색인을 지나치게 많이 사용하지 않습니다. 색인을 과도하게 사용하면 쓰기 지연 시간이 증가할 수 있으며 색인 항목의 저장소 비용도 증가합니다.

  • 타임스탬프와 같이 값이 단조롭게 증가하는 색인 생성 필드의 경우 부하 집중이 발생하여 읽기 및 쓰기 속도가 높은 애플리케이션에 지연을 초래할 수 있습니다.

색인 예외

대부분의 앱에서는 자동 색인 생성 및 오류 메시지 링크를 사용하여 색인을 관리할 수 있습니다. 하지만 다음과 같은 경우에는 단일 필드 예외를 추가할 수 있습니다.

케이스 설명
큰 문자열 필드

쿼리에 사용하지 않는 긴 문자열 값이 포함된 문자열 필드가 있는 경우 색인 생성에서 해당 필드를 제외하여 저장소 비용을 줄일 수 있습니다.

순차 값이 있는 문서를 포함하는 컬렉션에 대한 높은 쓰기 속도

컬렉션의 문서 사이에 타임스탬프처럼 순차적으로 증가하거나 감소하는 필드의 색인을 생성하는 경우 컬렉션에 대한 최대 쓰기 속도는 초당 500회입니다. 순차 값이 있는 필드를 기준으로 쿼리하지 않는 경우 색인 생성에서 이 필드를 제외하여 이 한도를 우회할 수 있습니다.

예를 들어 쓰기 속도가 높은 IoT 사용 사례에서 타임스탬프 필드가 있는 문서가 포함된 컬렉션은 초당 500회 한도에 근접할 수 있습니다.

큰 배열 또는 맵 필드

큰 배열 또는 맵 필드는 문서당 색인 한도인 20,000개에 근접할 수 있습니다. 큰 배열 또는 맵 필드를 기준으로 쿼리하지 않는 경우 색인 생성에서 큰 배열 또는 맵 필드를 제외해야 합니다.

읽기 및 쓰기 작업

  • 문서 쓰기 속도가 초당 1회를 넘지 않도록 유의하세요. 자세한 내용은 단일 문서 업데이트를 참조하세요.

  • 쓰기 및 삭제 시 단일 작업 대신 일괄 작업을 사용하세요. 일괄 작업은 단일 작업과 동일한 오버헤드로 여러 작업을 수행하기 때문에 보다 효율적입니다.

  • 해당되는 경우 동기식 호출 대신 비동기식 호출을 사용하세요. 비동기식 호출은 지연 영향을 최소화합니다. 예를 들어 응답을 렌더링하기 전에 문서 조회 결과와 쿼리 결과를 필요로 하는 애플리케이션을 생각해 보세요. 조회 및 쿼리에 데이터 종속성이 없다면 쿼리를 실행하기 전에 조회가 완료될 때까지 동기식으로 대기할 필요가 없습니다.

  • 오프셋 대신 커서를 사용하세요. 오프셋을 사용하면 건너뛴 문서가 애플리케이션에 반환되지는 않지만 내부적으로는 계속 검색됩니다. 건너뛴 문서는 쿼리의 지연 시간에 영향을 미치며 검색에 필요한 읽기 작업에 해당되는 비용이 애플리케이션에 청구됩니다.

규모 확장을 위한 설계

다음 권장사항에서는 경합 문제가 발생하는 상황을 피하는 방법에 대해 설명합니다.

단일 문서 업데이트

한 문서를 초당 2회 이상 업데이트하면 안됩니다. 문서를 너무 빨리 업데이트할 경우 애플리케이션에 지연 시간, 시간 제한, 기타 오류가 늘어나는 등 경합이 발생합니다.

좁은 문서 범위에 대한 높은 읽기, 쓰기, 삭제 속도

사전순으로 가까운 문서 또는 애플리케이션에 대한 읽기 또는 쓰기 속도가 높아지면 경합 오류가 발생합니다. 이러한 문제를 부하 집중이라고 부르며 다음 중 하나라도 해당할 경우 애플리케이션에 부하 집중이 발생할 수 있습니다.

  • 매우 높은 속도로 신규 문서를 생성하면서 단조 증가하는 자체 ID를 할당하는 경우

    Cloud Firestore에서는 분산형 알고리즘을 사용해 문서 ID를 할당합니다. 자동 문서 ID를 사용하여 새 문서를 생성하면 쓰기 작업에 부하 집중이 발생하지 않습니다.

  • 문서가 얼마 없는 컬렉션에서 매우 빠른 속도로 신규 문서를 생성하는 경우

  • 타임스탬프와 같이 단조롭게 증가하는 필드를 사용하는 신규 문서를 매우 빠른 속도로 생성하는 경우

  • 컬렉션에서 문서를 빠른 속도로 삭제하는 경우

  • 트래픽의 점진적 증가 없이 매우 빠른 속도로 데이터베이스에 쓰기 작업을 수행하는 경우

트래픽 늘리기

새 컬렉션 또는 사전순으로 가까운 문서에 대한 트래픽을 점진적으로 늘려 Cloud Firestore에서 트래픽 증가에 맞춰 문서를 준비할 충분한 시간을 제공해야 합니다. 새 컬렉션인 경우에는 최대 작업 수를 초당 500개로 제한하고 5분마다 50%씩 트래픽을 늘리는 것이 좋습니다. 예를 들어 이 증가 일정을 사용해 90분 후 읽기 트래픽을 초당 작업 수 74만 개로 늘릴 수 있습니다. 쓰기 트래픽도 마찬가지로 늘릴 수 있지만 Cloud Firestore 표준 한도에 유의하세요. 작업이 키 범위 전반에 걸쳐 비교적 균등하게 분산되도록 만드세요. 이를 '500/50/5' 법칙이라고 부릅니다.

새 컬렉션으로 트래픽 이전

점진적인 증가는 컬렉션 간에 앱 트래픽을 이전할 때 특히 중요합니다. 이 같은 이전은 기존 컬렉션에서 읽기 작업을 수행하면 간단하게 처리할 수 있습니다. 문서가 존재하지 않을 경우 새 컬렉션에서 읽어옵니다. 하지만 이 경우 새 컬렉션의 사전순으로 가까운 문서에 대한 트래픽이 갑자기 증가할 수 있습니다. Cloud Firestore에서 특히 포함된 문서가 적을 경우 트래픽 증가에 맞춰 새 컬렉션을 효율적으로 준비하지 못할 수 있습니다.

동일 컬렉션에 포함된 여러 문서의 문서 ID를 변경할 경우에도 유사한 문제가 발생할 수 있습니다.

새 컬렉션으로 트래픽을 이전할 때 가장 좋은 전략은 데이터 모델에 따라 달라집니다. 아래에서는 병렬 읽기로 알려진 예제 전략을 소개합니다. 이 전략이 내 데이터에 효과가 있는지 여부는 스스로 판단해야 합니다. 이전 도중 병렬 작업이 비용에 미치는 영향을 중요하게 고려하세요.

병렬 읽기

트래픽을 새 컬렉션으로 이전할 때 병렬 읽기를 구현하려면 먼저 기존 컬렉션에서 읽기 작업을 수행합니다. 문서가 누락되어 있다면 새 컬렉션에서 읽어옵니다. 부재 문서 읽기 속도가 높으면 부하 집중으로 이어질 수 있으므로 점차적으로 로드를 늘려야 합니다. 기존 문서를 새 컬렉션에 복사한 후 기존 문서를 삭제하는 전략이 바람직합니다. Cloud Firestore에서 새 컬렉션에 대한 트래픽을 처리할 수 있도록 병렬 읽기를 점진적으로 증가시키세요.

새 컬렉션에 대한 읽기 또는 쓰기를 점차적으로 늘릴 때는 사용자 ID의 확정 해시를 사용해 새 문서에 쓰기 작업을 시도하는 임의 비율의 사용자를 선택하는 전략을 사용하면 됩니다. 사용자 ID 해시의 결과가 함수 또는 사용자 행동에 의해 왜곡되지 않았는지 확인하세요.

한편 기존 문서의 모든 데이터를 새 컬렉션에 복사하는 일괄 작업을 실행합니다. 일괄 작업 수행 시 부하 집중을 방지하려면 연속 문서 ID에 쓰기 작업을 수행하면 안 됩니다. 일괄 작업이 완료되면 새 컬렉션에서만 읽기가 가능해집니다.

이 전략을 개선하려면 사용자를 한 번에 소량 배치씩 이전하면 됩니다. 사용자 문서에 해당 사용자의 이전 상태를 추적하는 필드를 추가하고, 사용자 ID의 해시에 근거하여 이전할 사용자 배치를 선택하세요. 일괄 작업을 사용해 해당 사용자 배치의 문서를 이전하고 이전 도중에 사용자에 병렬 읽기를 사용합니다.

이전이 진행되는 동안 기존 및 신규 항목 모두에 이중 쓰기를 수행하지 않으면 롤백을 쉽게 수행할 수 없으며, Cloud Firestore 비용이 증가하는 원인이 됩니다.

무단 액세스 방지

Cloud Firestore 보안 규칙을 사용하여 데이터베이스에 대한 무단 작업을 방지하세요. 예를 들어 규칙을 사용하면 악의적인 사용자가 전체 데이터베이스를 반복적으로 다운로드하는 상황을 피할 수 있습니다.

Cloud Firestore 보안 규칙 사용에 대해 자세히 알아보세요.