Snowflakeはマルチクラウド対応をしており、次の3つのクラウドプラットフォームのいずれかと組み合わせてデータ分析基盤を構成することが可能です。
・Amazon Web Services（以降、AWSという）
・Google Cloud Platform（以降、GCPという）
・Microsoft Azure（以降、Azureという）
※ご参考URL：https://docs.snowflake.com/ja/user-guide/intro-cloud-platforms.html

Snowflakeが日本のリージョンにはじめて対応したのがAWSの東京リージョンであったという経緯から、「Snowflake on Coud」に関する情報の多くは「Snowflake on AWS」を前提として記載されています。
＊弊社も、SnowflakeとAWSでデータ分析基盤構築する方法について、ブログ記事を公開しております。
　（SnowflakeとAWSでデータ分析基盤を構成するポイントとは？）

しかし昨今、全社のシステム基盤としてAzureを利用していて、Azureの知見を有する技術者を社内に確保している企業や、全社のコミュニケーション基盤としてMicrosoft 365を利用している企業において、「Snowflake on Azure」の選択を検討されるケースが増えています。
＊2021年10月より、SnowflakeはAzureの東日本リージョンに対応しています。

そこで本ブログ記事では、「Snowflake on Azure」にフォーカスし、SnowflakeとMicrosoft Azureの各種サービスを組み合わせてデータ基盤を構成する際のポイントについて、①データ連携 ②Azure AD連携 ③サービス間のセキュアな接続 ④Power BI連携 の４つの観点から、わかりやすく解説します。

SnowflakeとAzureでデータ分析基盤を構成するポイント①データ連携

データソースとなる各システムから「Snowflake on Azure」へデータ連携する方法を、３つご紹介します。データソースの種類 / データ量 / 連携頻度 などの要件に応じて、データ連携方法を決定しましょう。

なお、近年では、ロード時に加工をおこなう「ETL」によるデータ連携ではなく、Snowflakeの処理性能を活かし、ロード後に加工をおこなう「ELT」によるデータ連携が主流となっています。

• ETL
  ETLとは、Extract（抽出） / Transform（変換） / Load（格納） というデータ統合時に発生する各プロセスの頭文字の略称です。
  各システムに分散しているデータを「抽出」し、フォーマットもバラバラなデータを「変換」した後、加工したデータをDWHに「格納」するデータ処理方式です。
  ETLは、データベースとは異なる単体のツールとして、抽出したデータをツール上で変換します。そのため、一般的にはデータ処理の流れそのものという意味よりも、これらの処理を行うためのツールを指してETLと呼称することが多いです。
  ETLはデータの変換処理を行ってから保存するため、フォーマットの異なる大量のデータを分析に適した形式で一箇所にまとめる用途に向いていますが、直接データを保存するELTと比べるとスピード自体は決して早くありません。
• ELT
  ELTとは、Extract（抽出） / Load（格納） / Transform（変換） というデータ統合時に発生する各プロセスの頭文字の略称です。
  各システムに分散しているデータを「抽出」し、そのままの状態でメモリに「格納」した後、必要に応じてフォーマットを「変換」するデータ処理方式です。
  ELTは、データベースに保存したデータを、データベース上で直接変換します。
  ELTはデータベースが持つ機能の一つです。便宜上、ELT機能を用いて作成したデータパイプラインをELTツールと呼称することがあります。
  ELTはデータベース上でデータ変換処理を行うため、データ抽出から格納までのスピードはETLよりも早いですが、その分データベースに高い負荷がかかるため、一定水準のスループットが求められます。また、ELTは未処理のデータを丸ごとデータベースに保存するため、ETLを使用する場合よりも多くの記憶容量が必要となります。

Snowflakeは、スループットが高く、クラウドネイティブなのでメモリのスペックやデータベースの容量を柔軟に拡張できることから、「ELT」によるデータ連携が主流となっています。

①ETL/ELTツールを利用してデータを連携する

ETL/ELTツールを使って、データソースとなる各システムのDBやストレージに直接接続し、データを抽出、Snowflakeへロードします。
多くのETL/ELTツールがSnowflakeに対応しており、選択肢が非常に多くなっています。ここでは、Azureが提供している「Azure Data Factory」をご紹介します。
「Azure Data Factory」は、ETL/ELTツールとしての標準機能を取り揃えているのはもちろんのこと、「Snowflake on Azure」の場合、同じAzure間の接続となるため、非常に親和性が高いと言えます。
＊「Azure Data Factory」の利用方法については、こちらのブログで詳しく解説しておりますので、ぜひ、ご参考にしてください。

②「Azure Blob Storage」を経由し、Snowflakeのタスクを利用してデータを連携する

データソースとなる各システムから、「Azure Blob Storage」にファイル形式でデータを定期的に出力可能である場合は、Snowflakeのタスク機能を使って、「Azure Blob Storage」からの一括ロード処理をスケジュール実行することができます。

③「Azure Blob Storage」を経由して、「Snowpipe」によりデータを連携する

データソースとなる各システムから、「Azure Blob Storage」にファイル形式でデータが継続に出力される場合は、この方法を検討できます。

「Snowpipe」の起動の流れは下記のとおりです。

1. 外部システムから、データファイルがステージ（Azure Blob Storage）に出力される。
2. Azure Event GridがAzure Blob Storage上のデータ受信のイベントを検知し、Azure Storage Queへイベントメッセージを送信する。
3. Azure Storage Que のイベントメッセージがSnowpipeへ連携される。
4. Snowpipeはデータファイルをキューイングする。
5. キューイングされたデータをSnowflakeのテーブルにロードする。

ただし、「Snowpipe」はサーバーレスサービスのため、「Snowpipe」によるデータ連携で利用されるウェアハウスはSnowflakeにより自動で管理されます。そのため、コストシミュレーションが難しく、実データで検証したうえで利用の要否を決定することを推奨します。

SnowflakeとAzureでデータ分析基盤を構成するポイント②Azure AD連携

「Azure AD」を利用している企業の場合、Snowflakeと「Azure AD」を連携して利用したい、という要件が多く聞かれます。
そこで本章では、Snowflakeと「Azure AD」の連携について解説します。

「Azure AD」との連携を考えた時、２つの要件があります。
それぞれ方式や手順は異なりますが、どちらも同時に設定することが一般的です。

1. SSO（シングルサインオン）の実現
   ユーザー認証をSnowflakeから分離し、外部のサービスである「Azure AD」でおこなうことです。認証機能を一元管理できるというメリットがあります。
   SAML認証方式により、SSOを設定することができます。
   AzureポータルでSAML証明書を発行し、SnowflakeでAD登録をおこないます。
   ＊詳細な手順は、こちらのMicrosoft社のチュートリアル をご参照ください。
2. Snowflakeの「Azure AD」ユーザーとグループのプロビジョニング
   「Azure AD」上のユーザー・グループの作成/削除をSnowflakeと同期させることで、ユーザー管理を一元化することができます。
   Snowflakeにプロビジョニング用のカスタムロールを作成し、認証トークンを発行します。
   その後、Azure ポータルで認証トークン情報を設定することで、プロビジョニングが可能になります。
   ＊詳細な手順は、こちらのMicrosoft社のチュートリアル をご参照ください。

注意すべきポイントとして、どちらの連携方法にせよ、Azure ADとプライベートな接続をおこなうためにはAzureにSnowflakeアカウントが必要という制約事項があります。つまり、「Azure AD」とのSnowflake連携が要件となっている場合は、「Snowflake on Azure」の選択が推奨されるということです。

SnowflakeとAzureでデータ分析基盤を構成するポイント③セキュアな接続（Auzre Private Link活用）

SnowflakeはSaaS型であるため、パブリックインターネットを介した通信がイメージされ、セキュリティに不安を抱かれる声をよく耳にします。

しかし、Snowflakeとの接続に「Auzre Private Link」を使用することで、仮想的にプライベートな接続を実現することができます。

例えば、自社のVnet内にBIツールを搭載した仮想マシンがあり、Snowflakeへ接続する場合を考えます。
このとき、自社のVnetとSnowflakeのVnetに「Azure Private Link」を使用することで、パブリックインターネットを経由せず、BIツールとSnowflakeを仮想的にプライベート接続することができます。

＊「Azure Private Link」を使用するためには、Snowflakeは「Business Critical Edition」を選択する必要があるので、SnowflakeのEdition選択時はご注意ください。

SnowflakeとAzureでデータ分析基盤を構成するポイント④Power BI連携

Snowflakeは、TableauやQlikなどのBIツールとのネイティブ接続が可能であり、利用可能なBIツールの選択肢は非常に多いです。

全社でMicrosoft 365を利用している場合には、全社員がMicrosoftアカウントを保持していることから、近年はBIツールに「Power BI」を選択する企業も増えてきました。
また、2章で説明した「Azure AD」連携と組み合わせることで、「Power BI」経由でSnowflakeに接続する際に、利用ユーザーのアカウントで認証をおこない、Snowflake上の権限に応じたデータを参照できるように制御することができます。つまり、Snowflake上のデータに対する権限制御が、「Power BI」でも引き継がれるイメージです。

なお、Snowflakeでは、下記の権限制御が可能です。

1. データオブジェクトに対する権限制御
   ユーザーの属性によって、DB/スキーマ/テーブル/ビュー の 参照可否/編集可否 が決まる
2. 行アクセス制御
   ユーザーの属性によって、同一テーブルの参照できる行（レコード）を制御する
3. 列アクセス制御
   ユーザーの属性によって、同一テーブルの参照できる列（カラム）を制御する

Snowflakeの権限制御イメージ図

まとめ

さてここまで、SnowflakeとAzureを組み合わせてデータ分析基盤を構成する際のポイントについて、次の観点で解説して参りました。

• Snowflakeへのデータ連携におけるMicrosoft Azureサービスの活用
• Microsoft Azure環境とSnowflakeのセキュアな接続方法
• Microsoft Azure AD連携を利用したSnowflakeのアカウント管理
• Power BIとSnowflakeの接続

本ブログ記事をとおして、SnowflakeとAzureでデータ分析基盤を構成した場合の検討ポイントをご理解いただけたのではないでしょうか？

弊社は、Snowflakeの導入テンプレート「SnowBase」をご提供しております。
「SnowBase」は、弊社のクラウドベースのデータ基盤の導入に対するノウハウや実績をテンプレート化したサービスであり、AWS版/ Azure版のテンプレートをご提供しています。
データ分析基盤を、短期間 かつ 高品質に構築したい場合は、ぜひ、お気軽にお声掛けください。

◆ お問い合わせページ：https://itsol.dentsusoken.com/snowflake/inquiry/

＊本記事は、2023年10月1日時点の情報を基に作成しています。
　製品・サービスに関する詳しいお問い合わせは、電通総研のWebサイトからお問い合わせください。