初めてのAWSデータ連携、何を考えればいいの？(全体の方針編)
こんにちは。
Airitechのシステム開発グループのピンです。
先日AWS上でシステム間のデータ連携を実現したのですが、最適な実現方法が分からずに苦労しました。
この記事では、初めてデータ連携を実施する方を対象に何を考えればいいか・どういう流れで行うべきかを自分の経験をもとに紹介したいと思います。
同じ悩みを持っている方に、役に立つことができれば嬉しいです。
■そもそもデータ連携って何？
ビジネスを長期にわたり提供していると、いろいろなサービスの追加に伴い複数のシステムが稼働していることかと思います。中には、他システムのデータが必要な機能もあります。この時システムの間でデータのやり取りが必要になるのですが、この記事では、これをデータ連携と呼びます。
(下記の画像をご参照ください。)
■なぜデータ連携の仕方を考えるのか？
連携を考えて各機能を開発することは少ないため、各データや機能がバラバラになり、上手く利用できていないことも多いと思います。
また各システムが個別にデータのやり取りを行うと、密結合になりますし、似たようなデータ連携が個別に乱立する可能性もあります。
データ連携を行う共通基盤を構築すれば、必要なデータを汎用的に連携出来るようになります。必要な時に素早く構築できるようになりますし、セキュリティを担保する方法などを全体で統一することで安全に使える基盤を用意できます。
■データ連携で決めることとは？
今回私がデータ連携を実施するにあたり検討が必要になったポイントは、以下でした。
■方針決定
・データ連携全体の方針を決める。
・セキュアにデータ連携するための管理方法を決める。
・利用するツール・ミドルウェアを決める。
■送信元/先のデータ受信/送信について
・対象データを決める。
・連携トリガーを決める。
■データ変換処理
・データをそのまま送るか・変換を行うか決める。
■セキュリティ観点について
・データへのアクセス権限をどうするか決める。
・データの暗号対象や方式を決める。
・データを操作時の証跡の出力を決める。
この記事では、上記のうち「方針決定」について検討した内容を紹介します。
また具体的な例もあったほうがわかりやすいので、以下図のDB情報の連携を例に挙げながら、考えた内容や利用したAWSサービスを共有します。ここでのDB連携の要件は以下になります。
DBより「ユーザー基本情報」と「予約情報」データを取得する。
送信先のシステムに日次でデータを連携する。
■データ連携全体の方針を決める
1. データ連携の単位(IF)を決める
送信元も送信先も複数になる可能性があります。
また連携データの種類も多岐にわたる可能性があります。
データ種別毎やシステム毎にデータ連携を別々に作るのか、まとめるのかを考える必要があります。
DB連携で考えると、送信元と送信先は一つですね。
対してデータ種別は2つあります。それぞれのデータは独立しているため、それぞれ別々に連携IFを構築することとしました。
合計4つのIFがあることがわかります。
2. 連携失敗の時の対応とその通知について
データ連携失敗時のリトライ方針などを決める必要があります。例えば連携途中でデータをロールバックし、最初から連携を再開する。何回かリトライして対応するなどが案として挙げられます。
また失敗時の通知をどうするかも決める必要があります。
DB連携では、失敗時に5分おきに3回リトライすることとしました。
また成功した場合と、3回リトライしてもダメな時に、担当者にメールで通知することとしました。
AWSではStepFunctionsを利用することで、リトライ等制御可能です。
通知もStepFunctionsからAmazon SNSをキックして出すことができます。
他にもStepFunctionsの実行結果をAmazon CloudWatchから監視して、CloudWatch経由でAmazon SNSを利用することも可能です。
■セキュアに連携するための管理方法を決める。
1. 個人情報を扱う際の方針をどうするか
個人情報の有無などで、対応方針が変わります。
個人情報がある場合、マスキング実施などを考える必要があります。
「ユーザ基本情報」には個人情報が含まれます。
ただし、今回連携先のシステムにて個人情報を含め利用が必要なことと、連携先にてセキュアに扱える仕組みがあるため、マスキングはなしとしました。
2. 連携元と連携先システムの接続情報の管理
連携元・先のシステムへの接続情報をセキュアに管理するための方針を考える必要があります。
データベースへの接続情報・システムサーバーへの接続情報を環境変数で管理し、誰も閲覧できないようにすることとしました。
■利用するツール・ミドルウェアを決める。
1. ジョブのフロー制御が必要か不要かを基に検討
データ受信から送信までに、処理フローの制御が必要な場合と不要な場合で利用ツールが異なります。正常処理では制御不要でも、エラー時のリカバリなどで必要となることがあります。
DBから受信したデータをそのまま送信した場合、エラー時には、データのリカバリーができなくなりますね。リカバリのため、受信したデータを保存し、リトライ時にはそのデータを送信します。
このエラー向け処理に、ジョブのフロー制御が必要になります。
AWSでは、AWS Step Functions を利用してジョブフローを作ることができます。エラー時のリトライや規定回数リトライに失敗した場合など制御することができます。
2. バッチで連携するのか？ストリーミングで連携するのか
リアルタイムにデータ連携が必要なのか、バッチで連携するのかによっても利用するツール・サービスが異なります。
DB連携の要件は、データを日次で連携することでした。そのためバッチでの連携を選択しました。
AWSでの利用サービスですが、以下のように送るデータの要件によって使うサービスを変える必要があります。
①DBから取り込むデータの特色に対する利用サービス
②送信先にデータを送る場合
■全体の連携方針まとめ
以上の通り、連携方針について、一通り検討を進めました。
このように各システムがデータを連携する際に、このように各システムがデータを連携する際に共通基盤を構築すると、アーキテクチャの統一などもすることができ、効率的に連携できるようになりますね。
この記事では全体の連携方針で考えるべきポイントである
・データ連携全体の方針
・セキュアに連携するための管理方法
・利用するツール・ミドルウェア
を中心に記載しました。今後の検討のヒントになるとうれしいです。
次回は送信元からのデータ受信と送信先へのデータ送信について紹介します。次回もぜひご覧ください。どうもありがとうございました。
Airitechの採用情報はこちら
ホームページ
この記事が気に入ったらサポートをしてみませんか？