Firestore으로 확장 가능 애플리케이션 빌드

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Last reviewed 2020-05-18 UTC

이 문서에서는 Firestore를 사용하여 대규모 애플리케이션을 빌드하는 시점을 설명합니다. 이 문서에서는 대규모 애플리케이션의 데이터베이스 시스템을 담당하는 인프라 관리자를 위한 솔루션을 제공합니다. Firestore를 Google Cloud의 다른 제품과 함께 사용하면 데이터베이스 프로비저닝 및 유지보수가 간소화되므로 용량 계획 대신 앱 개발에 집중할 수 있습니다.

Firestore 기능 및 제한사항

Firestore는 모바일 및 웹 애플리케이션용으로 설계되었으며 유연한 비관계형 스키마를 갖는 계층적 트랜잭션 데이터를 저장하도록 설계되었습니다. Firestore를 데이터베이스 솔루션 후보로 고려하는 경우 사용 사례에 할당량 및 한도가 적절한지 확인해야 합니다. Firestore는 다양한 상황에서 범용성과 적응성을 발휘하지만, 특정 시나리오에서는 다른 Google Cloud 데이터베이스 제품이 더 적합할 수 있습니다. Firestore 또는 다른 솔루션을 사용할지 결정할 때는 다음 요소를 고려하세요.

스토리지

Firestore는 데이터 스토리지 양에 관계없이 호스팅할 수 있습니다. KB 단위에서 페타바이트 단위까지 어떠한 용량이라도 성능 저하 없이 동일하게 처리합니다.

실시간 업데이트

Firestore는 클라이언트가 문서를 리슨하고 쿼리를 사용하여 실시간 업데이트를 받을 수 있도록 실시간 업데이트를 제공합니다. 단일 문서의 현재 내용으로 문서 스냅샷을 즉시 만드는 콜백을 제공합니다. 문서 내용이 변경될 때마다 또 다른 호출을 통해 문서 스냅샷을 업데이트합니다.

오프라인 데이터 지속성

Firestore는 모바일 및 웹 클라이언트를 위한 완벽한 오프라인 지원을 통해 오프라인 데이터 지속성을 제공합니다. 오프라인 상태에서 데이터에 액세스하고 업데이트한 다음 다시 온라인 상태가 되면 클라우드에 변경사항을 자동으로 동기화할 수 있습니다. 기본 제공되는 오프라인 지원은 로컬 캐시를 사용하여 데이터를 제공하고 저장하므로 네트워크 지연 시간 또는 인터넷 연결 여부에 관계없이 앱이 응답성을 유지합니다.

트랜잭션

Firestore는 다중 문서 ACID 규격 트랜잭션을 지원합니다. ACID라는 용어는 원자성, 일관성, 격리성, 내구성의 줄임말입니다.

쿼리

Firestore는 전체 데이터베이스에서 strong consistency를 가지는 쿼리를 제공합니다. Firestore는 기본 색인뿐 아니라 보조 및 복합 색인을 지원하여 쿼리에서 요청한 항목의 위치를 빠르게 찾을 수 있습니다.

Firestore 쿼리는 다음과 같은 방식으로 제한됩니다.

  • Firestore는 비관계형 데이터베이스이므로 관계형 스키마 또는 SQL 시맨틱스를 사용하는 쿼리를 지원하지 않습니다. 특히 Firestore는 여러 속성에 대한 불일치 필터링 또는 서브 쿼리 결과에 따른 데이터 필터링을 지원하지 않습니다.
    • 앱에서 비수평적 규모에 SQL 지원이 필요한 경우 Cloud SQL을 사용하세요.
    • 앱에서 대규모 수평 및 전체 규모에 SQL 지원이 필요한 경우 Cloud Spanner를 사용하세요.
  • Firestore는 온라인 트랜잭션 처리(OLTP)에 최적화되어 있습니다.

보안

Firestore는 데이터를 디스크에 쓰기 전에 자동으로 모든 데이터를 암호화합니다. Firestore는 사용하는 클라이언트 라이브러리에 따라 다음과 같은 방법을 통해 강력한 액세스 관리 및 인증을 제공합니다.

자동 확장

Firestore는 다운타임 없이 자동으로 확장됩니다. 이 확장 메커니즘을 통해 Firestore는 초당 수천 개의 요청과 수백만 개의 동시 연결을 처리할 수 있습니다. 스토리지 크기와 작업 수를 기준으로 실제 사용량에 대해서만 비용을 지불합니다. 자세한 내용은 Firestore 가격 책정을 참조하세요.

Firestore 자동 확장은 다음과 같은 방식으로 제한됩니다.

  • Firestore Native 모드는 문서 업데이트 작업을 초당 최대 10,000회 쓰기 및 백만이 넘는 접속으로 확장할 수 있습니다. 앱이 이러한 쓰기 속도 제한을 초과하는 경우 초당 수백만 회로 확장되는 Datastore 모드를 사용하는 것이 좋습니다. 이러한 모드 간 차이를 자세히 알아보려면 Native 모드와 Datastore 모드 중 선택을 참조하세요.
  • Firestore는 방대한 규모의 작업을 처리할 수 있습니다. 그러나 복제 및 트랜잭션과 같은 복잡한 기능을 지원하기 위해 Firestore는 극단적 부하를 처리할 것으로 예상되는 앱의 성능을 저하시킬 수 있습니다.
    • 앱에 극도로 많은 쓰기 작업이 발생하는 경우 트랜잭션 및 보조 색인을 지원하지 않는 대신 데이터 수집 기능이 더 우수한 Cloud Bigtable을 고려해 보시기 바랍니다.
    • 게임의 플레이어 리더보드와 같이 앱에서 사용자에게 동일한 정보가 자주 표시되는 경우 클라이언트 측 캐싱을 사용하면 불필요한 서버 요청을 방지하여 부하를 줄일 수 있습니다.

지연 시간

Firestore는 리전 간 또는 영역 간 동기식 쓰기를 통해 지연 시간보다 내구성과 가용성을 우선시합니다. 앱이 데이터를 읽거나 쓸 때 10밀리초 미만의 일관된 지연 시간을 요구한다면 Redis용 Memorystore와 같은 메모리 내 데이터베이스를 사용하는 것이 좋습니다.

중복성 및 가용성

Firestore는 서로 다른 복제 메커니즘을 기반으로 하는 다음과 같은 수준의 다중 위치 중복성을 제공합니다.

  • 쓰기 지연 시간을 줄이는 것이 우선이라면 리전 복제가 가장 좋습니다. 리전 복제를 사용하면 데이터가 동일한 리전 내에 복제됩니다. 지연 시간을 최소화하려면 동일한 리전에 앱을 배치할 수 있습니다.
  • 가용성을 보장하는 것이 우선이라면 멀티 리전 복제가 가장 좋습니다. 멀티 리전 복제를 사용하면 데이터가 2개 이상의 서로 다른 리전에서 여러 영역에 복제되므로 데이터베이스가 리전의 서비스 중단에 대한 복원력이 우수합니다. 멀티 리전 복제는 가용성과 중복성을 높이지만 쓰기 지연 시간은 증가합니다. 그림 1과 같이 복제된 두 리전 사이에서 결정자 역할을 하는 감시 노드가 제3의 리전에 배포됩니다.

멀티 리전 데이터베이스의 복제 스키마

그림 1. Firestore의 멀티 리전 데이터베이스 다이어그램

클라이언트 라이브러리

모바일 및 웹 클라이언트는 Android, iOS 또는 웹 클라이언트 라이브러리를 사용하여 Firestore에 직접 액세스할 수 있습니다. 또한 Firestore는 오류 보고, 사용자 인증, 메시지 전송, 사용자 이벤트 분석 등의 기능을 제공하는 Firebase 플랫폼과 원활하게 통합합니다.

Firestore를 사용해야 하는 경우

Firestore 기능은 다음과 같이 다양한 사용 사례에 적합합니다.

  • 사용자 프로필: 사용자의 프로필을 관리하여 사용자의 이전 활동 및 환경설정을 기반으로 맞춤화된 사용자 환경을 제공합니다. Firestore의 유연한 스키마를 사용하여 사용자 프로필 구조를 개발할 수 있습니다. 예를 들어 앱의 새 기능을 지원하기 위해 새 속성을 추가할 수 있습니다. 다운타임 없이 스키마 변경이 이루어지며, 사용자 수가 증가해도 성능이 저하되지 않습니다.
  • 실시간 인벤토리: Firestore의 풍부한 중첩 객체를 사용하면 구조를 과도하게 한정하지 않고 다양한 제품의 방대한 비동질적 희소 데이터를 저장할 수 있습니다. 예를 들어 소매업체의 제품 카탈로그를 만들 수 있습니다.
  • 사용자 세션 관리: Firestore는 ACID 트랜잭션을 지원하므로 사용자는 트랜잭션이 완료될 때까지 하나 이상의 문서를 잠글 수 있습니다. 예를 들어 소매 거래용 장바구니나 행사 예약용 멀티파트 처리 양식을 만들 수 있습니다.
  • 상태 변형: Firestore의 ACID 트랜잭션을 사용하여 많은 수의 동시 사용자에게 변형을 전파할 수 있습니다. 예를 들어 게임 앱 내 모든 플레이어가 일관된 상태를 유지할 수 있습니다.
  • 지속성 쓰기 통과 캐시: Firestore의 고가용성 및 내구성에 힘입어 앱 비정상 종료 시에도 상태를 유지하고 잠재적인 데이터 손실을 방지할 수 있습니다. Firestore는 간편한 키-값 저장소와 같은 기능을 제공합니다. 그러나 Firestore에는 TTL(수명) 또는 캐시 만료 메커니즘이 기본 제공되지 않습니다.
  • 교차 기기 데이터 동기화: Firestore의 실시간 업데이트를 통해 연결된 모든 기기에서 항상 최신 상태를 표시할 수 있습니다. 예를 들어 Firestore는 여러 기기에서 연결하는 공동작업용 멀티 사용자 모바일 앱 및 앱에 일관된 상태를 제공합니다.
  • IoT 관리 및 애셋 추적: Firestore의 오프라인 데이터 지속성을 사용하면 기기에서 네트워크 연결이 끊어지는 경우에도 데이터 포인트를 기록할 수 있습니다. 예를 들어 휴대기기 및 차량의 실시간 GPS 추적을 설정할 수 있습니다.
  • 실시간 기능: Firestore의 실시간 업데이트를 통해 실시간 분석과 메시지를 설정할 수 있습니다. 대화형 시각적 대시보드와 같은 시각적 그래프와 차트를 최신 상태로 유지하고 실시간 토론 포럼과 채팅방을 설정할 수 있습니다.
  • 분산 카운터: 분산 카운터를 설정하여 게시물의 좋아요 수 또는 특정 항목의 즐겨찾기 수 등 문서 상호작용을 표시합니다.

참조 아키텍처

이 섹션에서는 다음을 포함하여 Firestore를 다른 Google Cloud 제품과 결합하는 대규모 웹 앱을 빌드하기 위한 참조 아키텍처를 제공합니다.

  • 일일 내보내기
  • 캐싱
  • 데이터 처리
  • 머신러닝을 위한 학습 모델

이러한 아키텍처는 권장사항이 아닙니다. 대신 확장 가능한 웹 앱을 빌드함에 있어 Firestore의 폭넓은 활용 방법을 강조합니다. 아키텍처를 재구성하고 조정하여 요구사항을 충족하는 자체 웹 앱을 빌드할 수 있습니다.

게임

게임 플랫폼은 플레이어 수만 명의 동시 접속을 지원합니다. 게임의 프런트엔드 서비스는 Firestore를 사용하여 계층적 환경 상태 데이터가 포함된 수십억 개의 문서를 저장합니다. 또한 Firestore에는 사용자 구성, 파티 멤버십, 길드, 친구 목록, 접속 데이터와 같은 사용자 데이터가 보관됩니다. 이 사용 사례는 다음과 같이 다른 Google Cloud 제품을 포함합니다.

  • Spanner는 전 세계 어디서든 대규모 플레이어 집단에 대한 인벤토리 또는 경기 기록을 유지할 수 있는 전역적으로 일관된 데이터베이스를 제공합니다.
  • 자주 사용되는 데이터에 대한 액세스 속도를 높이기 위해 Redis용 Memorystore에 리전 인메모리 캐시가 배포됩니다.
  • 이벤트는 Bigtable에 로깅되며, 개발자 또는 지원 담당자가 문제 해결을 위해 이벤트에 액세스할 수 있습니다.
  • 프런트엔드 및 백엔드 데이터베이스의 데이터를 정기적으로 BigQuery로 가져와서 데이터 분석 파이프라인을 실행합니다. 이러한 파이프라인은 게임 커뮤니티에 영향을 주거나 플레이어가 게임을 그만두기 전에 업데이트가 필요한 게임플레이 메커니즘을 발견하는 데 도움이 됩니다.

그림 2는 게임 아키텍처 사용 사례를 보여줍니다.

게임 아키텍처 사용 사례

그림 2. 게임 플랫폼 아키텍처 예시

사물 인터넷

대화형 웹 앱은 사물 인터넷(IoT) 기기에서 생성된 실시간 원격 분석 정보를 표시합니다. 기기는 사용자의 온도와 심박수를 정기적으로 측정하고 수집한 후 다음과 같이 데이터를 처리합니다.

  1. 각 측정값은 MQTT 및 HTTP 브리지를 통해 IoT Core에 즉시 제출됩니다.
  2. IoT Core는 각 측정값을 Pub/Sub에 개별 메시지로 게시합니다.
  3. Pub/Sub 메시지는 장기 저장을 위해 원본 메시지에서 관련 정보를 추출하여 Firestore에 결과를 저장하는 Cloud Functions를 트리거합니다.
  4. Firebase 호스팅에서 호스팅되고 Angular로 구동되는 대화형 웹 사용자 인터페이스는 Firestore에서 직접 업데이트를 리슨합니다. 각 업데이트가 웹 사용자 인터페이스에 자동으로 푸시되어 최신 정보를 실시간으로 시각화합니다.

그림 3은 이 시나리오의 원격 분석 정보 관련 데이터 파이프라인을 보여줍니다.

IoT 앱 아키텍처 사용 사례

그림 3. IoT 앱 아키텍처 예시

소매업

소매업 플랫폼은 다양한 매체를 통해 처음 구매자에게 제품 추천을 제공합니다. 웹 앱은 리퍼러, 지리학적 리전, 기기 유형과 같은 온라인 사용자에 대한 실시간 데이터 포인트를 기록한 후 수집된 데이터를 다음과 같이 Firestore에 씁니다.

  1. 새 레코드를 만들 때마다 Cloud Functions에서 사용자 데이터를 BigQuery로 복사하는 데이터 파이프라인이 트리거됩니다.
  2. Spark MLlib로 구현되고 Dataproc에 배포되는 추천 엔진은 BigQuery에 저장된 실시간 사용자 데이터와 Cloud SQL에 저장된 제품 메타데이터를 통해 학습합니다.
  3. 추천 엔진은 추천 제품에 대해 다음과 같은 예측을 제공합니다.
    • Firestore에 기록되고 온라인 사용자 기기에 자동으로 푸시되는 실시간 예측
    • 이메일 서비스를 통해 오프라인 사용자에게 전송되는 일괄 예측

그림 4는 소매 플랫폼 시나리오의 데이터 흐름을 보여줍니다.

소매 플랫폼 아키텍처 사용 사례

그림 4. 소매 플랫폼 아키텍처 예시

데이터 변경사항 실시간 캡처

앱은 전역 상태를 변경하는 실시간 사용자 입력을 받습니다. Looker Studio의 대시보드는 실시간 이벤트를 추적하여 사용자 행동과 상호작용을 더 잘 이해합니다. 사용자 작업이 상태 값을 업데이트하면 다음과 같은 이벤트가 발생합니다.

  1. Firestore는 이전 및 새 상태 값을 비롯해 BigQuery에 변경사항을 기록하는 Cloud 함수를 트리거합니다.
  2. Looker Studio 대시보드는 BigQuery의 이벤트 데이터에 대한 실시간 집계 쿼리를 실행합니다.
  3. 쿼리는 서로 다른 버킷에 집계된 이벤트 변경 비율, 시간 버킷당 고유 이벤트 유형, 이벤트 수집 지연 시간과 같은 측정항목을 생성합니다.

이 아키텍처에 대한 자세한 프레젠테이션 및 데모는 Cloud Next '19 동영상 Firestore로 멋진 앱 빌드를 참조하세요.

그림 5는 실시간 데이터 변경을 캡처하기 위한 아키텍처를 보여줍니다.

데이터 캡처 아키텍처 사용 사례

그림 5. 간단한 데이터 캡처 아키텍처 예시

공동작업 콘텐츠 수정

공동작업 콘텐츠 관리 시스템(CMS)을 사용하면 동일한 기사에서 여러 편집자가 동시에 작업할 수 있습니다. 편집자가 변경할 때마다(예: 문자 추가 또는 삭제) 편집자의 클라이언트가 변경사항을 Firestore에 직접 제출합니다.

여러 편집자가 동시에 변경사항을 제출하면 다음과 같은 해결 프로세스가 수행됩니다.

  1. Firestore의 트랜잭션은 처음 수신된 변경사항만 데이터베이스에 기록되도록 합니다. 다른 변경사항은 거부됩니다.
  2. Firestore는 업데이트된 콘텐츠를 모든 편집자에게 자동으로 보냅니다.
  3. 처음에 거부된 편집자는 업데이트된 콘텐츠에 자신의 변경사항을 다시 적용한 다음 Firestore에 변경사항을 다시 제출합니다.
  4. 모든 클라이언트의 모든 변경사항이 수락되고 데이터베이스에 기록될 때까지 동일한 충돌 해결 프로세스가 반복됩니다.

스테이징 파이프라인을 사용하면 편집자가 다음과 같이 콘텐츠를 미리 볼 수 있습니다.

  1. Cloud Scheduler에서 호스팅되는 크론 작업은 매초 Cloud 함수를 트리거합니다.
  2. 이 함수는 Firestore에서 Cloud SQL에 호스팅된 스테이징 데이터베이스로 최신 콘텐츠를 복사합니다.
  3. 편집자는 App Engine에서 호스팅되는 스테이징 서버에서 스테이징된 콘텐츠를 미리 봅니다.

콘텐츠가 작성되면 편집자가 CMS의 게시 버튼을 클릭합니다. 이 작업은 Firestore에서 최신 콘텐츠를 Cloud SQL에 호스팅된 프로덕션 데이터베이스로 복사하는 Cloud 함수를 트리거합니다. 그러면 리더는 프로덕션 웹사이트에 새로 게시된 콘텐츠를 사용할 수 있습니다. 이 아키텍처의 실제 예시를 보려면 New York Times 기사 Newsroom CMS를 위한 협업 방식의 빌드를 참조하세요.

그림 6은 공동작업 콘텐츠 수정 사용 사례에서 콘텐츠를 수정, 스테이징, 게시하기 위한 파이프라인을 보여줍니다.

콘텐츠 수정 아키텍처 사용 사례

그림 6. 공동작업 콘텐츠 수정 플랫폼 아키텍처 예시

다음 단계