Snowflakeで別々の開発と本番環境を実装する戦略
ソフトウェア開発の世界では、開発と本番の環境の概念は基本的なものです。開発環境は、開発者が新しい機能を作成したりバグを修正したりする空間であり、実際のライブシステム、つまり「本番」環境に影響を与えることなく、変更をテストします。この分離により、未テストまたは潜在的に不安定なコードが本番環境に到達することを防ぎ、本番環境の安定性とセキュリティを確保します。
データ管理とデータウェアハウスプラットフォーム（例：Snowflake）の世界でも、別々の環境を確立することが重要です。開発、テスト、および本番のために別々の環境を作成することで、データの実験、新しいコードのテスト、変更の実装などがリアルタイムの本番データベースに影響を与えるリスクを回避できます。Snowflakeでは、通常、各環境ごとに異なるデータベースまたはアカウントを作成することになります。
環境ごとの1つのデータベース
Snowflakeにおける環境の分離の1つのアプローチは、1つのSnowflakeアカウントを使用し、各環境ごとに1つのデータベースを作成することです。この構造に従い、開発、テスト、および本番環境ごとに、それぞれDEV_MY_DATABASE、TEST_MY_DATABASE、PROD_MY_DATABASEといったデータベースを作成します。
各環境ごとに別々のデータベースを作成することで、明確な境界が設定され、誤って間違った環境でデータを操作するリスクが減少します。また、直感的な命名規則が提供されるため、チームは簡単にデータベースを識別し切り替えることができます。
環境ごとの1つのスキーマ
別のアプローチとして、1つのデータベースに環境ごとに別々のスキーマを持つ方法があります。この場合、MY_DATABASEというデータベース内にDEV_MY_SCHEMA、TEST_MY_SCHEMA、PROD_MY_SCHEMAといったスキーマがあるかもしれません。
1つのデータベース内で各環境ごとに別々のスキーマを持つことで、データを整理してアクセスしやすくすることができます。各スキーマはデータベース内の独立した名前空間として機能し、異なる環境が干渉しないようにします。
しかしながら、このアプローチには重要な欠点があります。開発用のコードを誤って本番のスキーマで実行するリスクがあり、重大なデータの問題を引き起こす可能性があります。また、各スキーマのセキュリティを設定することは手間がかかり、エラーが発生する可能性もあります。そのため、この方法はチームがスキーマレベルでデータセキュリティを厳格に管理する経験が豊富な場合を除き、一般的には推奨されません。
スキーマの命名規則
よく考えられた命名規則は、開発者やデータアナリスト、その他のチームメンバーがスキーマの目的を一目で理解するのに役立ちます。
次のような接頭辞をスキーマ名に使用することを検討します。
- LND
新たに取り込まれたデータを保持するランディングスキーマを示す。 - RAW
データが処理や変換を行う前に最初に到着する生のステージングエリアを示す。 - INT
生データを結合してクリーンアップするためのインテグレーションエリアを示す。 - MRT
レポート作成に適した統合されクリーンアップされたデータを保持するデータマートを示す。
これらの接頭辞により、スキーマのデータライフサイクル内での役割が明確になります。これらは例ですが、データウェアハウスの一般的な慣行を反映したものであり、スキーマの命名規則を設計する際の出発点として役立ちます。
環境ごとの1つのアカウント
環境ごとの1つのアカウントを持つアプローチは、厳格な分離を維持するために非常に大規模なシステムには適していますが、重要な欠点もあります。
-
重複データの管理
各環境が完全に独立しているため、それぞれを個別に管理する必要があり、データベース管理者の作業量が増えます。アカウント間での重複データの管理はより難しくなり、一貫性や冗長性の問題が生じる可能性があります。 -
別々のログインの取り扱い
各環境ごとに別々のログインとパスワードが必要です。これにより、管理上の手間が増え、ユーザーが複数の認証情報を管理する必要があるため、開発が遅くなる可能性があります。 -
データクローン処理の課題
各環境ごとに別々のアカウントを持つ場合、アカウント間でデータを迅速にクローンすることはできません。この制約は、データを1つの環境から別の環境に移す際のデータ管理をより困難にします。 -
重複ストレージの問題
アカウント間でデータのクローンができないため、データは物理的にコピーされ、環境ごとに重複します。この重複により貴重なストレージスペースが占有されるだけでなく、データが全ての環境で正しく同期されていない場合にデータの整合性に問題が生じる可能性もあります。
参考
Ryusei Kakujo
Focusing on data science for mobility
Bench Press 100kg!