AWSデータ連携を学ぶ！王道パターンと検討ポイント

こんにちは。データ連携製品を担当しております、荒井大輔です。

アマゾン ウェブ サービス（以下、AWS）のような「IaaS/PaaS」やSalesforce・Box・kintoneをはじめとする「SaaS」が、企業の大小を問わず当たり前に利用されるようになってから、かなりの年月が経ちました。
しかし、今なお「AWSへのデータ連携に悩んでいる」という方が多いのも事実です。
そこで、本コラムでは、AWSとオンプレミスのデータ連携における「検討ステップ」や「王道パターン」についてお伝えしたいと思います。

システムのクラウドリフト傾向は現在も加速しており、AWSとオンプレミス上のシステムが完全に分断されているケースは無くなってきました。

システムのロケーションが分かれることによるよくある課題は、「ネットワークの転送速度」や「データの配置」です。
これらの課題のために、データ連携が業務上のボトルネックになるケースは少なからず発生します。

つまり、AWSをうまく活用するためには、データ連携に関する検討が非常に重要になります。
システムのクラウドリフトを考える時点で、データ連携に関する検討を始めておくことをおすすめします。

データ連携は、以下のようなステップに分けて検討できます。

まずは「インフラレイヤ－の構築」について確認してみましょう。

ボトルネックになりやすく、かつ、構築後の変更が難しいのが「インフラレイヤーの構築」です。
その中でも、「ストレージサービス」と「ネットワークサービス」については、データ連携との関わりが強いため、特に注意が必要です。

まずは、AWSが提供する主なストレージサービスを確認してみましょう。

これらのストレージサービスは、データ連携の手段に応じて、大きく以下の2つに分けられます。

▼ファイルストレージ / ブロックストレージ

　これらのストレージサービスへのデータ連携は、通常のオンプレミス環境での連携と変わりません。
　ただし、ネットワークの影響を受けないことが前提です。

▼オブジェクトストレージ

　データの抽出～加工については、オンプレミス環境と同じです。
　ただし、オブジェクトストレージ（Amazon S3）へのデータの配置は、API経由（もしくは画面操作）で行う必要があるので注意が必要です。

次は、オンプレミスとの接続を行うネットワークサービスを確認してみましょう。

一般的に「オンプレミス内のデータ連携」より「オンプレミス・クラウドをまたがるデータ連携」の方がパフォーマンスが向上することはありません。
オンプレミス間のデータ連携で使用するネットワークがよほど老朽化していない限り、ネットワークのロケーションが離れることによるオーバーヘッドが高くなることで、従来通りのパフォーマンスを発揮することは難しくなります。

パフォーマンスを高くするためには閉域網／専用線接続となり、どうしてもコストが高くなってしまいます。
しかし、必要なスループットを確保するために、ぜひ十分な検討をお願いしたいと思います。


このように、クラウドリフト時のデータ連携基盤の設計では、ストレージやネットワークのパフォーマンスが鍵を握ることが多いです。
まずは 「データ連携を意識したAWSサービスを選定する」 ようにしましょう。

「ミドルレイヤーの構築」に関しては本コラムでは語りつくせそうにないため、今回は「オンプレミスやSaaSからAWSにデータを連携する」場合を想定して、よくある3つのパターンに絞って見ていきます。

オンプレミス－クラウド間のデータ連携の最もシンプルな方法は「ファイル連携」です。
データの加工が済んでいるか、加工が不要なファイルデータを、AWS上に配置できれば良い場合です。

▼ユースケース

・センサーやデバイスデータなどの各種ログや、データベースのバックアップデータなどを安価なAmazon S3に配置したい
・前工程で出力されたデータの授受を、外部会社が管理するAmazon S3を介して行いたい

▼実装時の留意点

　ファイル連携においては、連携先のストレージサービスとのファイルの授受を どのようなネットワーク経路で、
　どのような手段で行うか を検討する必要があります。

・APIの実装
　オブジェクトストレージであるAmazon S3との連携ではAPIを介する必要があり、
　API連携処理を内製化する場合にはメンテナンス性も考慮した実装が必要

・ログなどの管理
　実行履歴やログの管理をどのように行うかなど、管理面での考慮が必要

・ネットワークの圧迫
　ファイル転送によりネットワークが圧迫され、他の業務に影響が出ることがないよう、
　十分な帯域を確保したデータ連携が必要

複数システムとの連携が必要で、かつ、データの加工が必要な場合です。

▼ユースケース

・オンプレミス、AWS、他クラウド環境、SaaS等の各種システムをデータ連携でつなぐことでサイロ化を防ぎたい
・AWS上に構築された基幹システムと、SaaSの業務システム間でマスタデータの連携をしたい

▼実装時の留意点

　クラウドリフトに合わせたシステムの更改、SaaSの利用促進など、現在はビジネスの変化のスピードが速くなってきています。
　従来のような連携プログラムや、データベースの機能を用いた密結合な仕組みでは、 システム改修が追い付かない こともあるでしょう。

・連携するシステムごとの対応
　システムごとに様々なAPIへの対応が必要

・システム変更に伴う対応
　システム変更に迅速に対応するため、データ連携時の加工／変換処理を、多くの人が短時間で対応できるような仕組みが必要

データレイク構築時に発生する大量データのバッチ処理（ETL処理）を実現したい場合です。

▼ユースケース

・各種データソースからのデータ収集
・収集済みデータに対してのクレンジング、マスキングなどの最低限の加工処理
・フォーマット変換、集計、結合などの活用しやすい形式への加工処理

▼実装時の留意点

　企業内外の様々なデータを蓄積し、ビッグデータをビジネスに活用したいというニーズは増え続けています。
　また、蓄積するだけでなく、活用に向けた一次加工・二次加工を行う必要もあり、 データレイク上でのバッチ処理 が求められています。

・生データの加工
　DWHへのデータ格納時には、生データの正規化が必要
　データレイクへのデータ格納時には、用途に合わせて集計・変換・マージなどの加工が必要
　（データレイクを直接参照するBIツールを使う場合、BIツール側でデータ加工をすることもあるが、
　　ユーザー側の負荷軽減のために加工済みのデータを準備しておきたい）

・大量データの加工処理の高速化
　データ活用ニーズの追加や変更に合わせて、大量データの迅速なデータ加工/データ提供が必要
　データ加工処理のメンテナンスが簡単で、データの特性に合わせた高速処理ができる手段の検討が必要

これまでに紹介した通り、AWSとのデータ連携は多方面で求められています。

もちろん、AWSでもデータ連携を行うサービスが提供されていますが、活用するには、

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
・多くのサービスの中から、目的に適したサービスを選定するスキル
・コーディングなどの高度なスキルセットを有する人材の育成や確保
・AWS以外のクラウドサービスやオンプレミスとの連携

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
などが必要で、なかなかうまく進められないことも多いです。

さらに、AWSに限らず 「企業全体のデータ連携基盤」としての成長性を持ち、
より汎用的なスキルセットで利用できる仕組み が求められていると考えています。

そこでおすすめしたいのが「適材適所なデータ連携ツールの活用」です。
前述の3つの王道パターンごとに、弊社のお客様事例をもとに、どのようなデータ連携ツールが向いているのかを見ていきます。

ある製造業様では、IoT機器で生成される稼働実績データをパートナー企業へ提供するためにAmazon S3に格納しています。
稼働実績データはオンプレミスにある一時保管データベースに格納されており、日次バッチでAmazon S3に転送する仕組みが必要とされました。

▼課題

・AWSに対する知識が少ないが、短期での構築が必要なため、AWSサービスの習得から始めるとなると間に合わない
・AWS CLIを使った連携を検討するも、運用時の実行履歴管理に課題があったため、見送り

▼おすすめのデータ連携ツール

　ファイル転送ツールのデファクト「 HULFT（ハルフト） 」がおすすめ！
　容易な開発、実行ログの管理、「安心・安全・確実」なファイル転送が可能です。

▼HULFTを導入した効果

・APIの実装もGUI設定のみで、スピーディにAmazon S3への連携ができた
・Amazon S3への実行ログ管理は、HULFT上のログとして管理することで運用負荷の低減ができた

ある小売業様では、様々な販売チャネルの情報を連携して得られた情報を、マーケティングに活かすためのデータ連携が必要でした。

▼課題

・活用すべきデータソースとデータ量が増加した
・システムがクラウドとオンプレミスに分散していた
・データ連携処理の開発がスクラッチ開発で属人化しており、利用するツールも統一されていなかった

▼おすすめのデータ連携ツール

　異なるシステムをつなぐEAIツール「 DataSpider Servista（データスパイダー サービスタ） 」がおすすめ！
　様々なアプリケーションインターフェースに対するAPIを持ち、ノーコード開発が可能です。

▼DataSpider Servistaを導入した効果

・クラウドとオンプレミスに分散している各システムを、豊富なアダプタで連携できた
・システムごとの個別開発を行う必要がなく、ノーコードでデータ連携を実現できた
・開発ツールを統一することで、開発の標準化を推進できた

ある製造業様では、Amazon S3でデータレイクの構築をしています。
データ利用者へデータ提供するために、データウェアハウスやAmazon S3をSQLで参照するサービス「Amazon Athena 」の実装が予定されていました。

▼課題

・データ連携は内製する予定だったが、言語開発可能なメンバーが限られ、要員の確保が困難だった
・言語開発可能なメンバーも、基幹システムの開発フレームワーク以外の経験がなく、他業務も抱えつつ新たな技術を習得するのが困難だった
・データレイクには生データの蓄積だけでなく、データの活用に向けた正規化や集計が必要であり、
　データ加工処理をどのように実装するかが課題に挙がっていた

▼おすすめのデータ連携ツール

　超高速ETLツール「 Precisely Connect（プレサイスリー コネクト） 」がおすすめ！
　独自の自動チューニング機構による大量データの加工や集計、ノーコード開発が可能です。

▼Precisely Connectを導入した効果

・ノーコード開発ができるためアサインの幅が広がり、これまで以上の規模／スピード感で対応ができるようになった
・基幹システムの開発者は、Precisely Connectのステップツリー形式の開発が従来の開発スタイルに親しく、技術習得にかかる期間を大幅に短縮できた

このように、オンプレミスとAWSのデータ連携における課題は、最適なデータ連携ツールを使うことで解決できることが多いです。

本コラムでは、AWSとのデータ連携に関して王道の3パターンをご紹介しました。
事例に関してはあくまで一例を挙げただけで、これが唯一の正解ではありません。目的や課題に合わせて、複数の手段を持っておくことも大切です。

アシストには「お客様の目的や課題に沿った最適な手段をご提案したい」という思いがあります。
データ連携についてお悩みの方は、お気軽にご相談ください。貴社にとって最適な手段を提案できるよう尽力いたします。