Snowflakeには、データの耐障害性を確保するために、自動でストレージ冗長する仕組みがあります。
本ブログでは、この自動でストレージ冗長を行う仕組みであるマルチ アベイラビリティーゾーン（以降、マルチAZ）の概要、用途や、同じくデータの耐障害性を確保する仕組みであるレプリケーション機能との違いについて解説いたします。

Snowflakeの耐障害性の仕組みとは？

Snowflakeには、Snowflakeでデータが消失しないための仕組みとしてストレージ冗長と自動バックアップと機能について、「Snowflakeのアーキテクチャの構成要素・機能・特徴とは？（vol.13）」の中で次のように解説いたしました。

Snowflakeのアーキテクチャ①データベースストレージの特徴
5.ストレージの堅牢性とバックアップ
 Snowflakeは、データの耐障害性を確保するために、ストレージの冗長性と自動バックアップを提供します。データは複数のデータセンターに複製され、万が一の障害に備えます。

Snowflakeでは、このデータの耐障害性を確保するために、ストレージの冗長性と自動バックアップを行う仕組みとしてマルチAZを活用してデータの冗長性を確保しています。
次章では、マルチAZの概要や活用することで起こるデータの冗長性について解説いたします。

SnowflakeでマルチAZを活用したデータの冗長性とは？

Snowflakeが稼働しているAzure、AWS、GCPのパブリッククラウドサービスプロバイダーはすべてAZを提供しています。
AZ（Availability Zones、アベイラビリティゾーン、可用性ゾーン）とは、電源、冷却設備、ネットワークなどのハードウェアで分離されたインフラ設備の単位で、複数のデータセンターをまとめたもののことです。
リージョン内のアベイラビリティーゾーン間は、相関する障害を防ぐために意味のある距離として最大約 100 km離れています。

また、複数のAZを利用してシステムを構築することを「マルチAZ（ゾーン冗長）」と呼びます。
システムをAZベースで冗長化しているということであり、障害が発生した場合に、他のAZでサービスを継続できるため、システムの可用性を高めることができます。
各AZでのデータのコピーや復旧処理はクラウドサービス側で自動で行いますので、ユーザ側で設定する必要がありません。

メインのAZで障害発生時は、クラウドサービス側で自動的にメインのAZを切り替えが行われます。

例）マルチAZでのデータ冗長
データを3つのAZのストレージそれぞれに保存をしておくことで、3つのストレージのうち１つのAZが障害で稼働できなくなった場合でも、他のAZのストレージを使用することで、データの消失を防ぐことが可能

◆通常時
 

◆障害発生時

Snowflake以外のSaaS型サービスの耐障害性とは？

Snowflake以外のSaaS型サービスの耐障害性はどのようになっているかについて、他のSaaS型サービスであるSalesforceが提供している資料を用いて、データ普及や耐障害性について、解説します。

Salesforceの公式ページで障害復旧ポリシーについて次の記載があります。

顧客データの復旧
Quip ではすべてのユーザーデータの複数のオフサイトバックアップを保持しています。インクリメンタルなバックアップ (5 分以内のデータ) と日次スナップショットを保持しています。
バックアップポリシーと顧客データの入手可能性に関する詳細は、「Backup Policy」 (バックアップポリシー) を参照してください。
提供されるすべてのバックアップ (インクリメンタルまたはスナップショット) からサイト全体を復旧できます。

 障害復旧
サービス停止と障害に対応するため、以下のように、多階層のシステムを実装しています。
システムのすべてのフロントエンドには複数のレプリカがあり、単一のフロントエンドによりサイトが利用不可になることはありません。

1. すべてのデータベースは複数のインスタンスに共有されており、単一の顧客またはデータの問題により、すべての顧客でサイトの利用ができなくなることはありません (隔離など)。
2. システム上の重要な読み取りはすべて、トランザクションの一貫性がある、別のデータセンターにあるセカンダリデータベースへのフェイルオーバー読み取りです。このため単一のデータセンターでの短期的なサービング問題は、データへのアクセスには影響しません。
3. すべてのデータベースはマルチ AZ RDS データベースであり、リージョンで利用不能になったりサービス停止が発生したりした場合に自動でフェイルオーバーします。
4. 複数のアベラビリティゾーンで RDS の障害が発生し、RDS サービスのレンダリングができなくなった場合は、手動で Quip 独自のセカンダリレプリカサーバーをフェイルオーバーします。これは独立したインスタンスで、通常の RDS システムが完全にサービス停止した場合でも機能します。
5. RDS と独自の独立セカンダリインスタンスで壊滅的な障害が発生した場合は、スナップショットまたはインクリメンタルなバックアップから新たな一連のデータベースサーバーに復旧します。
6. RDS と独自の独立セカンダリインスタンスで壊滅的な障害が発生した場合は、スナップショットまたはインクリメンタルなバックアップから新たな一連のデータベースサーバーに復旧します

上記の障害復旧システムにおいて、ステップ1から5は10分以内に完了します。5つの階層すべてで障害が発生した場合、最後のステップ6は約1時間以内に完了します。

 ＊参照元：Salesforce 障害復旧ポリシー

上記のように、SalesforceでもマルチAZを活用したデータの冗長性を使用して、データ復旧や耐障害性を確保してることが分かります。

Snowflakeのレプリケーション機能との違いとは？

Snowflakeでは、耐障害性の機能として、マルチAZでのデータ冗長の機能以外にも、レプリケーション機能も挙げられます。
マルチAZでのデータ冗長とレプリケーション機能との比較を簡単にまとめたものが下表です。

 上記のようにマルチAZでのデータ冗長機能に関してはユーザが設定を行う必要がなく、Snowflakeの標準機能として提供されています。
Snowflakeを構築したリージョン内でのデータ冗長となりますが、コスト面での追加費用がいらないなどのメリットがあります。

一方で、レプリケーション機能はリージョンや他のクラウドサービスにもデータを複製することができるというメリットがありますが、複製するタイミングや複製先の設定などユーザで設定が必要であり、複製の頻度や複製先の数に比例してコストが増大することに注意が必要です。

そのため、リージョン内でのデータ冗長が問題ない場合はマルチAZによるデータ冗長機能を、コストが増加しても、他のリージョンにデータをコピーしたい場合やマルチクラウドで構築したい場合などにはレプリケーション機能を使用するのが良いでしょう。

＊Snowflakeのレプリケーション機能については、Snowflakeのレプリケーション（複製）機能とは？～レプリケーションの仕組みと活用方法～（vol.23）」でご紹介しておりますので、是非ご覧ください。

まとめ

ここまで、Snowflakeでの、マルチAZを活用したデータの耐障害性についてや、他クラウドサービスの耐障害性、Snowflakeのレプリケーション機能との違いやお勧め用途について解説してまいりました。

Snowflakeを使用するうえで、データの耐障害性や冗長についての仕組みを理解し、お客様の要件にあった、耐障害性の仕組みを構築する必要があります。

 弊社は、お客様ごとの要件（用途/予算/セキュリティレベルなど）に応じたデータ分析基盤の構築や、データ活用の実現に向けたデータマネジメント体制の整備などをご支援しております。
Snowflakeを用いたデータ活用でお悩みの際は、是非弊社までお声掛けください。

本記事は、2025年3月13日時点の情報をもとに作成しています。製品・サービスに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://itsol.dentsusoken.com/snowflake/inquiry/