GCPとSalesforceを連携する社内向けWebアプリケーションを構築した話

こんにちは! エス・エム・エス エンジニアの石塚です。

私の所属するグループでは、Google Cloud Platform(以降GCP)を用いて、社内のデータ基盤の開発を行っております。

最近はGCPに蓄積したデータを閲覧、加工し、Salesforceへ連携するWebアプリケーションをGCP上で構築しました。

今回はそのアーキテクチャと実装にあたって考慮した点、苦戦した点、GCPで構築したメリットについて、お話しようと思います。

これまでのGCP関連の記事はこちら

 

要件

今回開発しましたシステムの要件は、ざっくりと以下の通りです。

  • BigQuery上に蓄積されたデータを加工してSalesforceに登録したい
  • システムで自動連携するのではなく、担当者がデータの中身をチェックして、修正した上でSalesforceに登録したい

今までは以下の仕組みはありました。

  • Cloud Composerを使って、SalesforceのデータをBigQueryに自動連携する(関連記事)
  • あるいはBigQueryで集計したデータをSalesforceに自動連携する
  • BigQuery上のデータを集計目的でスプレッドシートやGoogleデータポータルで閲覧する(関連記事)

しかし、BigQuery上のデータを1個ずつ見ていき、それを人が更新して、Salesforceという別システムに連携する、といった仕組みは存在しませんでした。

今回はこの要件を満たすために、以下の機能のみを持つ簡易な社内Webアプリケーションを構築しました。

  • 社内ユーザがGCPのデータを閲覧、検索ができる
  • 社内ユーザがGCPのデータを編集して、それをSalesforceにデータ連携できる

作ったもの

そして、今回作成したシステムのアーキテクチャ図がこちらです。(※は苦労した点として後々紹介)

GCPの主な登場人物と実装にあたって考慮した点

App Engine

本アプリケーションのWebサーバです。Python3.7 Flaskで開発しています。App Engineで開発できる言語は複数ありますが、Cloud ComposerとCloud FunctionsがPython3系のため、WebもPythonを選択しました。

App Engineの環境はスタンダード環境です。利用者の少ない社内アプリケーションのため、トラフィックがない場合はインスタンスを0にスケールするなどの設定を行い、極力低コストでの運用をしています。

Identity-Aware Proxy

App EngineへのGoogleアカウントによる認証で利用しています。

App Engine自体はApp Engineのファイアウォールルールの設定で保護できますが、それ以上のきめ細かいアクセス制御をするために利用しています。

Cloud Composer, BigQuery, Cloud SQL

今回利用元となるデータはBigQueryに蓄積しています。

Webアプリケーションとして社内の複数のユーザにGCPのデータを公開するにあたって、BigQueryではコスト、パフォーマンスの面で不適切なため、

WebアプリケーションのデータストレージとしてはCloud SQL(MySQL)を採用し、BigQueryからMySQLへのデータ連携を、Cloud Composerでバッチ処理しています。

Cloud Functions, Cloud NAT

Salesforceに接続時にIPアドレスを固定して接続するため、Cloud NAT + Cloud Functionsを利用しています。

Cloud Functionsはサーバーレス VPC アクセスの機能を使い、VPCネットワークに接続、Salesforceにアクセスするときは、Cloud NATを経由して、IPアドレスを固定してアクセスしています。

Logging, Monitoring

App EnigneのログはLoggingで出力し、さらに後にログを解析しやすいように、BigQueryへログをエクスポートしています。

また、App Engineの稼働、及びエラーのログをMonitoringで監視し、異常時はSlackの開発チームチャンネルへ通知するようにしています。

 

苦労した点

認証周りどうしよう

アーキテクチャ図の※1の箇所になります。

ログイン認証について、今回は弊社が全社的にGoogle Workspaceを利用しているため、Googleアカウントでの認証、アクセス制御が可能なGCPのIdentity-Aware Proxyを利用しました。

アプリケーション側にログイン機能の実装をせず、アカウントのアクセス制御はGCPのコンソールからGoogleアカウント、Googleグループ単位で設定が可能です。

Identity-Aware Proxyは署名付きヘッダまたはApp EngineのUsers APIで、アプリケーション側でユーザ情報の取得ができます。

 

しかしここで難儀が……App EngineのUsers APIを使えば、少ないコード量で簡単にユーザ情報が取得できそう、そう思っていた矢先、開発時点では、App Engineスタンダード環境 Python 3ランライムではサポートされていませんでした。

利用規模的にスタンダード環境がいい……

一度Python3で開発進める方針に決めたのに後戻りは大きすぎる……

我々はUsers APIの利用を諦め、署名付きヘッダでの実装に踏み出しました。基本的にはGCPのドキュメントに従いコーディングしていけばよいのですが、Users APIよりもコード量が多くなるのと、環境によってできるできないの調査をするにあたって苦労しました。

App EngineからSalesforceにつながらない

アーキテクチャ図の※2の箇所になります。

Webアプリケーション上からSalesforceへのデータ登録する機能を実現する際、当初はApp Engine(Python)でSalesforceのREST APIを呼び出し、データ連携する想定でした。

しかしここでも問題が……

弊社のSalesforce環境は、アクセスする際にIPアドレスによる制限も行っているため、GCPからのSalesforce へ接続する際にIPアドレスを固定する必要があります。GCPから外部へのアクセスは、VPCネットワークを経由するし、Cloud NATを利用することで、IPアドレスを固定していました。しかし開発時点で、App EngineのサーバレスVPCアクセスの機能では、Salesforceなどの外部IPへのアクセスではVPCネットワークを経由してくれず、Cloud NATによるIPアドレスの固定がされないことが判明しました……。

諦めずに代替案をいろいろ調べてみた結果、Cloud Functionsのサーバーレス VPC アクセスにたどり着きました。

ドキュメントを読み進めると、Cloud Funcitonsの下り(外向き)ネットワーク設定に、

すべてのトラフィックを VPC コネクタ経由でルーティングする: 関数からの送信リクエストをすべて VPC ネットワークにルーティングします

との記載が!つまり、この設定をすれば、Cloud Functionsの関数からSalesforceへリクエストを送信するとき、VPCネットワークを経由、Cloud NATからVPCネットワークの外に出て、IPアドレスを固定した状態でSalesforceにアクセスすることができるのです。

Cloud Functionsは利用した分だけ課金されるサーバレスのFaaS(Function as a Service)と呼ばれるクラウドサービスの一つです。Cloud Functionsに単体の機能を持った関数をデプロイし、それらを組み合わせて一つのアプリケーションを構築することで、マイクロサービスアーキテクチャの構成を取ることができます。

今回のシステムの場合、基幹となるWebアプリケーションの部分をApp Engineで開発し、Salesforceへの接続部分をCloud Functionsに切り出す構築にしています。App EngineからCloud Functionsへの接続は、サービスアカウントでの認証付きHTTP接続で実現しました。

GCPで構築したメリット

今回はアプリケーションで利用する元データがBigQueryにあった、私のグループ内で主に利用しているパブリッククラウドがGCPであったため、本システムもGCPで構築しましたが、改めてGCPでシステム構築したメリットについて考えてみました。

Googleアカウント認証が楽にできる

苦労した点にも詳細を記載しました通り、弊社のようにGoogle Workspaceを利用している組織にとって、Googleアカウント認証が楽に実装できたのはメリットかなと思います。その後の権限管理もGCPのコンソール上でできるので運用も楽に感じています。

Googleスプレッドシートでシステムのログの集計ができる

ログはGCP上のLoggingに出力され、Loggingの機能でBigQueryへのログのエクスポートは最初の設定1回で簡単にできます。BigQueryに出力したログは、GoogleスプレッドシートのBigQueryコネクタを用いて閲覧できます。事業部門の人がスプレッドシートを用いて、ログからシステムの利用状況の集計ができ、システム利用の評価や実績集計などの実業務に役立てています。これもGCP、Google Workspaceの連携が容易に取れるからこそ実現したメリットだと思います。

まとめ

以上、記事のボリュームも大きくなってしまいましたが、GCPに蓄積したデータを閲覧、加工し、Salesforceへ連携するWebアプリケーションをGCP上でサクッと構築した話についてでした。

アーキテクチャ図を見ての通り、利用サービスは複数あり複雑に見られるかもしれませんが、複数サービスを組み合わせて構築することで、アプリケーションの開発スピードも上がり、クラウドサービスの特性を生かした開発・保守運用のしやすい構築にできたと思っています。(他にもCI/CD、秘匿情報管理などで利用した、紹介しきれていないサービスも利用しています!)

私のグループで開発しているGCPを中心としたデータ基盤はまだまだ発展途上なので、また紹介できる内容が出てきましたら本ブログを通じて発信していこうと思います!

Pocket
LINEで送る