■本記事の目的
ストレージ統合を理解する。
ストレージ統合の作成単位（バケット／フォルダ）について整理する。
■前回の記事
Snowflake S3データロード：④COPY INTOによるデータロード
■概要
ストレージ統合は、
Snowflakeとクラウドストレージのセキュリティ情報を定義するオブジェクトですが、
どの単位で定義しておくべきか気になったので、記事にします。
S3バケット/フォルダとSnowflakeオブジェクトの構成に図式化します。
ストレージ統合設計については、考え方あると思いますが、いくつかご紹介します。
■構成図
AmazonS3とSnowflakeのストレージ統合および外部ステージの構成です。
※ケースとして、統合3パターンほど複合的に記載しています。
⇒各操作権限（READ／WRITE）によっては、構成を考慮したほうが良さそうです。
■ストレージ統合の構成の考え方
ストレージ統合の作成ケースのポイントとしては以下が挙げられます。
・ストレージ階層のセキュアアクセスの統合・分散
・ストレージ階層の選択的参照
・READ,WRITE操作の共通・分散
評価ポイントとしては以下が挙げられます。
・運用
・監視
・セキュリティ
過去のご要件で挙がった事例としては、以下のようなものがあります。
・AWS CloudWatchなどで監視性（ロールの操作履歴）を担保したい
・システム種類ごとのIFロード処理とロールを紐づけ、それをポリシーによって制限したい
・運用の簡易さを優先するためできるだけオブジェクトは統合したい
・ストレージのセキュリティ性を担保するため分散させたい
顧客ごとで要件は変わるため、応じてストレージ統合を構成する必要があります。
メリット、デメリットを説明する必要があると思いますので、事項でまとめます。
■マトリックス表
事項に応じて、記載しています。
選択的参照は、セキュアアクセスの分散に含まれるのでここでは集約しています。
担保したい観点を増やすほど、関係性としてはトレードオフです。
■あとがき
ストレージ統合を設計される際の参考にご利用いただけますと幸いです。
目次に戻る