SaaS 連携の作り方いろいろ (ShanonAdventCalendar2017・16日目)

このエントリーをはてなブックマークに追加

この記事は、 Shanon Advent Calendar 2017 の 16日目として投稿しています。

はじめに

ご無沙汰しております。chappie です。
最近はプロダクトマネージャーとして、自社プロダクトと他社サービスとの間を結ぶ、連携系サービスを主に担当しています。一部では「連携おじさん」と呼ばれているとかいないとか。

連携系サービス、といってしまうとちょっと大雑把すぎるので、もう少し具体的に書いてみます。
シャノンでは SHANON MARKETING PLATFORM というマーケティング用 SaaS を提供しています。 マーケティング用のシステムでは主に見込み客のデータを扱うので、同じく顧客データを扱う SFA や CRM など営業用ツールと併存することが一般的です。 この見込み客/顧客データ間の同期や、それに関連する履歴情報の交換をシステム間で行う機能が、ここでいう連携系サービスです。

さて、このような連携系サービス、いくつか作り方のパターンがあります。 実際、我々が提供するいくつかの連携系サービスもそれぞれに異なった作りをしているので、ちょっと整理してみたいと思います。

これから SaaS 間のデータ連携に何かしらのかたちで関わる方の参考になれば幸いです。

==
ちなみに本記事を書いてる途中で、CData Software さんの Advent Calendar に似た主旨のエントリーが最近投稿されたことに気づきました。あわせて参照いただくとより理解が進むかもしれません。
SaaS 連携/クラウド連携のパターン:連携の為のツールの種類は?
==

大分類:直通か中継か 

まず構成によって大きく分けると、1.直通タイプ、 2.中継タイプ の2種類に分かれます。
連携対象のシステムAとシステムBがあったとして、それぞれが直接、相手のシステムにデータ連携するのが「直通タイプ」、 間に何かしらの中継システムを介して、両者の間のデータを仲介するのが「中継タイプ」と便宜上分類します。


直通タイプ:内包型 

アプリケーション内に連携システムを作る場合です。
当然ですが、片方が自社サービスで内部実装可能である場合にのみ可能です。


自社プロダクトの機能と密接に統合できる。たとえば、変更を即座に連携したり、他の機能と連携機能を連動させることがやりやすい。よくも悪くも自社プロダクトの影響を受けやすいタイプです。

また、一方的にデータを送る片方向連携に向いている一方で、相手からのデータ反映をタイミングよく行うことは苦手です。

直通タイプ:プラットフォーム利用型 

連携対象のサービスが PaaS でもある場合、そのプラットフォーム上で動くアプリを作ることでデータ連携を実現できる可能性があります。
SFA/CRM の代表格、Salesforce は正にその典型で、シャノンの Salesforce 連携サービス「SMP for Salesforce」 は Salesforce の AppExchange アプリとして実現しています。


この場合、片方のシステム上で動作することになるので、どちらかというと直通タイプといえますが、プラットフォーム上で作るアプリは中継タイプでの連携システムに近いものになるでしょう。

こちらも、プラットフォームとして利用する側のシステムとの統合はしやすい一方、もう一方のシステムとは疎になりがちです。 また、プラットフォームの稼働状況や制限の影響を受けることになります。 (たとえば、 Salesforce の容量やジョブキューの実行性能など)

中継タイプ:インテグレーションサービス利用型 

ETL/EAI と呼ばれるシステム統合サービスを利用する場合です。
たとえば Asteria Warp Data Spider など、SaaS やオンプレのエンタープライズシステム含め、DB や Excel など各種データソースまであらゆる面での連携・統合を実現するサービスが提供されています。
データ連携自体が専門なので、一から連携システムを構築することに比べれば実装コストは大幅に小さく済ませられる可能性があります。ただし、一般的には利用料が比較的高価であったり、運用のための知識面でのサービスロックインされる制約はあります。

ちょっと毛色の異なるものとして、 ZapierBuilt.io FlowMicrosoft Flow などのタスクオートメーションサービスを利用するという手もあります。
サービスでアダプタが用意されているか自作が可能で、「システムAに新規データが入ったらシステムBにも同じデータを入れる」といった比較的単純な連携であれば選択肢となりうるでしょう。
ただし、あくまでこれらはタスク自動化という側面が強いので、本格的なデータ連携には向かないと思われます。

中継タイプ:自前システム作り込み型 

中間サーバを設置して、1から連携処理を作り込む場合です。
直接 API を呼び出すプログラムを自前で作成、あるいは CData や DataSpider などのアダプターを組み込んで連携システムを構築します。

サイボウズ社の kintone と連携するシャノンの連携サービス「kintone コネクタ」はこのタイプです。



kintone アプリを利用して連携設定を行うので、一見 kintone 上に連携システムが構築されているように見えますが、 実際は連携システムが Amazon Web Services を利用して別途構成されています。この連携システム自体、AWS Lambda を中心に構成されたなかなかおもしろい作りなのですが、今回はその詳細は割愛します。

中継タイプの利点として、連携対象システム本体の影響を直接受けにくい点や、他サービスとの連携にも拡張しやすい/既存の連携システムを利用できることが挙げられます。

また、連携先のシステムに詳しい外注先を活用できるというメリットもあります。上で紹介した SMP for Salesforce は Salesforce に詳しいブレインハーツさん、kintone コネクタ は kintone や AWS に詳しいアールスリーインスティテュートさんにそれぞれご協力いただきました。(いつもお世話になっております!)

逆に中継タイプの弱点としては、連携対象システムの外からできることしかできないという点や、中継者自身の可用性も当然担保する必要があり、特に自前で構築する場合はそれ相応のコストをかける必要があります。

おわりに

以上のように、システムの置かれた状況や目的によって、どのような仕組みでデータ連携を実現するかは異なります。

仕組みが異なれば、得意な処理やボトルネックなども異なるため、それぞれのタイプにあわせて開発時の注力ポイントや、運用上の留意点などどこに重点を置くべきか考える必要があります。実際の連携処理のレベルでの注意点などについてはまたいずれ、機会を見つけてまとめてみたいと思います。

とりあえず今回は以上です。

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...