Subscribe to the Teradata Blog

Get the latest industry news, technology trends, and data science insights each week.

ハイブリッド・クラウドでのアナリティクス – アーキテクトの視点

ハイブリッド・クラウドでのアナリティクス – アーキテクトの視点

 ハイブリッド・クラウドは今や、企業の検討事項であるだけに留まらず、テラデータのお客様、特に大企業のお客様にとっては既に現実のものとなっています。私たちが「ハイブリッド・クラウド」と言う時に何を意味するのかを理解するには、まず2つの用語を定義しておく必要があります。

  • ハイブリッド・クラウド:オンプレミスと、1つまたは複数のクラウドを組み合わせて使用する。
  • マルチクラウド:複数のクラウドを使用する。

多くの企業はハイブリッド・アーキテクチャとマルチクラウド・アーキテクチャの両方を使用しています。

ハイブリッド・クラウドやマルチクラウドについてお客様と話をすると、よく次のようなことを耳にします。

  • ワークロードに合った一番良いクラウドを利用したい。
  • 特定のクラウドに依存せず、種別を問わずに利用したい。
  • 1つのクラウド・プロバイダーのサービス提供地域では、全ての事業所がカバーできない。
  • ワークロードの中に、オンプレミスのままにしておく必要がある部分と、クラウドに移行できる部分がある。

では、自社のアナリティクスをハイブリッド・クラウド向けに設計するにはどうすればよいのか?

まずは、ハイブリッド・クラウド環境やマルチクラウド環境の長所と短所を考えてみましょう。

長所 短所
用途別にクラウドを利用可能(例:Salesforce、SAPなど) クラウド/オンプレミス間のデータの移動が遅くコストが高い
ローカル・データ・センターを活用可能 クラウドごとに異なるスタックや固有の技術が必要
特定のワークロードに合わせ最良のクラウドを選択可能 コストや課金体系が様々

特定のワークロードに合わせ低価格で利用可能

クラウドごとに異なる専門知識が必要


ハイブリッド・クラウド・アーキテクチャを計画する際に重要な点の1つは、クラウド/オンプレミス間のデータの移動です。クラウドにデータを入れる時の移動は無料ですが、クラウドからデータを出す時の移動はコストがかさむ可能性があります。さらに、クラウドの内外への通信は相当量のレイテンシーが加わります。

アナリティクス・エコシステムは、ソース (Source) で始まり、利用者 (Consuremers) で終わります。アナリティクス・エコシステムには、3つの階層があります。

  • Receive(受信):ローデータがここに送られ、標準化やクレンジングが行われる。
  • Analyze(分析):レポーティングや、モデルのトレーニングおよびスコアリングが実行される。
  • Serve(供給):利用可能な形式でデータ・プロダクトが提供される。

下図は、アナリティクス・エコシステムをこの3層に分けて示したものです。矢印はデータの流れを、矢印の太さは各層で移動するデータの量を表わしています。
Screen-Shot-2020-01-22-at-9-02-13-AM-(1).png

上図のように、クラウドとクラウドの間、またはオンプレミスとクラウドの間のデータ移動で、コスト効率が最も高いのは供給層(Serve) と利用者 (Consuremers) の間です。帯域幅利用が2番目に少ないのが分析層と供給層の間です。

以下の図では、エコシステム・アーキテクチャの2つの例を取り上げ、供給層と利用者の間でのデータ移動を説明します。

1つ目の例では、オンプレミスとSalesforceクラウドの業務系システムがソースとなっています。受信層、分析層、供給層は、すべてAWSクラウド内にあります。利用はオンプレミスで行なわれます。
Screen-Shot-2020-01-22-at-9-03-11-AM.pngクラウドへのデータの取り込みには多くの帯域幅が使われますが、これに対するクラウド・プロバイダーからの課金はありません。オンプレミスの利用者に対しては結果のみが転送されるため、アウトバウンドの帯域幅使用量はわずかです。

2つ目の例では、メインのアナリティクスはオンプレミスで実行され、ソース(Salesforceは例外)と利用者もオンプレミスです。また、メインのアナリティクス・システムでは使用できなくなった履歴データへのアクセスが必要になった場合に利用する、法規制・コンプライアンス用のシステムがクラウド内にあります。
Screen-Shot-2020-01-22-at-9-03-55-AM.png
1つ目の例のアーキテクチャと同様に、2つ目のアーキテクチャでも帯域幅使用量はクラウドからのアウトバウンドで発生しているため、コストは最小限です。

ベスト・プラクティスは以下のリストのようにまとめられます。

ベスト・プラクティス

クラウド間のデータ転送を最小限にする

  • データのエクスポートはコストが高い
  • 帯域幅は限られている

クラウド間のタイムクリティカルな依存を最小限にする

  • レイテンシーは通信を遅らせる

アプリケーションはクラウド内のas-a-serviceで利用する

  • Salesforce

  • Office 365

  • SAP Financials

定評のある大手クラウドを利用する

  • AWS

  • Azure

  • Google Cloud

すべてのクラウドやオンプレミスに同じガバナンス・ルールを適用する

  • クラウドでのシャドーITは避ける

クラウドへの接続、およびクラウド間の接続には専用接続を使用する

  • レイテンシーの削減
  • 帯域幅の保証
  • 信頼性の向上

クラウド固有のベースSaaSを利用する

  • オブジェクト・ストレージ(Amazon S3、Azure Blob)
  • メッセージング

相互運用性の高い専門的なサービスを利用する

  • データウェアハウス
  • マシンラーニングやディープラーニング

Kubernetesによりカスタム・コードをDockerイメージとしてデプロイする

  • DevOps
  • クラウドの種別を問わない相互運用


重要なのは、アナリティクス・エコシステムは複数のクラウドとオンプレミス環境で構成できますが、コアとなるアナリティクスは単一のクラウドかオンプレミス上で実行すべきだということです。つまり、データはクラウドのコンテキストに集中させ、アナリティクスには一般的なツール・チェーンを使用することが重要です。

このトピックの詳細情報は、ホワイトペーパー「De-Risking Hybrid, Multi-Cloud Analytics(ハイブリッド/マルチクラウド・アナリティクスのリスク排除)」およびウェビナー「Moving Toward a Modern Analytics Architecture(最新アナリティクス・アーキテクチャへの移行)」でご確認ください。

本ブログは抄訳となります。英語版のブログはこちら


Portrait of Tomi Schumacher

(Author):
Tomi Schumacher

Tomi Schumacher is an Eco System Architect/Principal Data Engineer with over 20 years of experience in IT. Tomi has a wide range of experiences: he worked as a consultant, architect, manager and Independent contractor both in the US and in Switzerland for various industries. He is involved in the whole project management live cycle, and he worked on backend services, various databases, web frontends and mobile apps. Tomi worked on private (VMWare) and in public clouds.

  View all posts by Tomi Schumacher

Turn your complex data and analytics into answers with Teradata Vantage.

お問い合わせ