「DX実現の第一歩！クラウド技術を活かしたデータ分析、成功のヒント」の第2回を開催しました #SnowflakeDB

さがらです。

11/11にSnowflake株式会社との共同ウェビナー「DX実現の第一歩！クラウド技術を活かしたデータ分析、成功のヒント」の第2回を開催し、SnowflakeとTableauを組合わせ、簡単にデータ分析基盤を構築できることを説明しました。

※こちらのウェビナーは計4回のシリーズ構成で、12/9にも4回目を開催しますので是非ご参加ください！

登壇資料

本ウェビナーのゴール：クラウドに関する不安を払拭します

1回目のウェビナーでは、SnowflakeとTableauを組み合わせた専門知識不要のデータ分析基盤をご紹介したのですが、「Snowflakeってクラウドですよね…？」と不安になる方も多いのではないでしょうか。

社外の環境にデータを置くことに抵抗感を覚える方も多いと思います。

しかし下記のスライドのように、Snowflakeはすでに全世界で4990社を超える企業に導入されているのです。

一方で、Snowflakeなどクラウドを使っている企業でのデータ漏洩、そんなに聞いたこと無いと思います。 むしろ、オンプレミスのサーバーを使っている企業でのデータ漏洩を聞いたことがある方も多いのではないでしょうか。

つまり、オンプレミスだろうとクラウドだろうと、やることをやっていなければデータは漏洩するのです。

加えて、クラウドを導入すると、下記スライドのようなメリットを得る事ができます。

しかし、そうは言っても「クラウドが安全という証拠がないと社内での稟議が通らないんだよな…」という方が多いと思います。

そこでこのウェビナーでは、クラウドに関するよくある不安4種をベースに、それぞれの不安を解消するための情報を交え説明をしました。

不安その１：セキュリティ

まず1つ目は、クラウドの不安といえばの第一声としてあがりがちな「セキュリティ」についてです。

データセンター

まずクラウドを使うに当たって、データを置くことになるデータセンターがどんな所なのか、知らない方も多いのではないでしょうか。

SnowflakeはAWS・GCP・Azure、任意のパブリッククラウドを選択してホスティングされるSaaSの製品ですので、AWSを例に説明します。

下記スライドのように、AWSのデータセンターは4つのレイヤーで構成され、セキュリティを確保しています。

• 防御レイヤー：物理的にデータセンターへの侵入を防ぐレイヤーです。データセンターでの作業に関わる人はが必要な時だけ入場可能で、AWSの社員であっても、定期的に入場許可の確認をしているようです。

• インフラストラクチャレイヤー：データセンターを担う電源装置や通信装置などです。こちらも基本的に許可を得ないと入場できないようなアクセス管理をしており、万が一電源がダウンしてもリカバリできるように冗長性をもった構成になっているようです。

• データレイヤー：実際に顧客のデータを保持したりシステムが動作するためのサーバーがあるレイヤーですね。物理的なアクセスはもちろん、ネットワークを介したアクセスに関しても追跡管理を行う仕様となっているようで、不正アクセスを守る仕組みが出来ています。

• 環境レイヤー：データセンターが立つ立地や、洪水などの自然災害を考慮するレイヤーです。AWSではアベイラビリティーゾーンという考えがあり、ユーザーがAWSを使用する時はアベイラビリティーゾーンを選択するのですが、1つ以上の相互に独立したデータセンターで構成されています。そのため、仮に１つのデータセンターが落ちたとしても、別のデータセンターですぐにリカバリができる構成が取られています。

オンプレミスとクラウドでの比較

次は、オンプレミスとクラウドでのセキュリティに関して考慮しなければならないことについてです。

情報漏えいの原因は大きく下記の4つに分類されると思いますので、この4つをベースに比較表を作ってみました。

• ネットワークの設定ミス
• パスワード管理の甘さ
• サーバーやソフトの脆弱性
• ウイルス感染

また、どのクラウドのサービスを使う上でも共通の考えとなる、「責任共有モデル」という考え方を聞いたことが在る方も多いのではないでしょうか。 SnowflakeのようなSaaSにおける管理と責任を共有する範囲は下記スライドのようになるのですが、見るところはデータと一部のアプリケーションの設定だけです。

このことからも、クラウドサービスを使えば考慮しなければいけない範囲が少なく、情報漏えいのリスクが減ることがわかるのではないでしょうか。

サービスの提供元によるデータ閲覧

また、「クラウドサービスを使うと、データの提供元に見られてしまうのでは…？」という不安を感じる方も多いと思います。

下記スライドはSnowflakeでの例ですが、皆様のデータへのアクセスはせず、Snowflakeというプラットフォームのメンテナンスを行うだけですので、データを提供元に見られる心配もございません。

コスト

2つ目は、コストに関する説明となります。

想定していない額の請求が来るのでは？

クラウドサービスを使うと、意図せぬ形で使いすぎてしまい高額請求に陥ることがある…そんな不安を感じる方もいるのではないでしょうか。

Snowflakeでは、稼働している間課金対象となるウェアハウスの自動停止であったり、リソースモニターという仕組みで閾値を超えたら管理者へ通知やウェアハウスの自動停止をする、という仕組みが用意されています。

また、想定していない金額の請求が来ないか心配する余り、一番小さいXSのウェアハウスだけで処理をすれば良いと考える方もいるかもしれませんが、Snowflakeのウェアハウスの課金体系は「稼働している時間だけ」ですので、スペックの良いウェアハウスを使って、パパっと処理を終わらせるということが最適になるケースもあります。

下記スライドは、XSからLのウェアハウスに変更した時、コストはそこまで変わらず、処理速度は8倍になった、という例となりますので是非ご覧ください。ウェアハウスのサイズは臨機応変に考えることがポイントです。

障害対応

3つ目は、障害対応に関する説明となります。

いつ障害が発生して止まるか不安

まず「障害」と聞いて、クラウドプロバイダーのリージョン全落ちで何もできない、そんなことを想像されてはいないでしょうか？ 実際にクラウドサービスの障害では、サービス全体がとまるというより、一部の機能レベルでの影響を「障害」と呼んでおります。

クラウドサービスの障害対応に関する各種用語を抑えておくと、各サービスのSLAを読んだ時に理解がスムーズになると思いますので、是非ご一読ください。

障害に備えたSnowflakeのアーキテクチャ

ここで、Snowflakeがどのように障害対策を行っているかを見ておきます。

まず、全アカウントに対して3つのアベイラビリティゾーンにまたがって展開されているということです。 もちろんユーザー側は特に意識することなくSnowflake側が行ってくれるので、ユーザーは何もせずとも堅牢な冗長性が確保されているのです。

またSnowflakeの特徴として、マルチクラウドを用いたクロスクラウドレプリケーションにも対応しています。

基盤運用スキル

最後4つ目に技術面として、基盤運用スキルについて見ていきます。

必要なパフォーマンスが出せるのか

まず、「クラウドを使って必要なパフォーマンスが出せるのか」を心配される方も多いと思うのですが、正直、事前にどれだけのリソースが必要になるか予想できないのが昨今の状況です。

具体例をあげると、

• アプリケーション・サーバー
  • ニーズの変化による急激なアクセス増減
• データ分析
  • 分析対象のデータは良も種類も日々増える
  • いつクエリが多く発行されるかも不確定

そのため、柔軟にスケーリングできるSnowflakeのようなクラウドのサービスを使っていることで、いつどんな状況にも柔軟に対応し、パフォーマンスを発揮できるのではないでしょうか。

運用していくための知識がなく不安

これまでにSnowflakeのようなデータに関わる製品を使ったことが無い方にとっては、いきなりSnowflakeのような製品を使いこなす自信がないという方も多いのではないでしょうか。

Snowflakeは日本語でも公式Docを提供していますし、弊社でもこのDebelopersIOを通して多くの情報を記事にして公開しています。

また、Snowflake導入後にスムーズに運用して頂くための技術支援をプロフェッショナルサービスという形で提供しておりますので、こういった技術支援も併せてご検討頂けると良いかと思います。

最後に

クラウドにこれまで馴染みがない場合、何かと不安を覚えるのは当然のことだと思います。 本ブログや登壇を通して、少しでも皆様の不安解消に繋がるととても嬉しいです。