こんにちは。
テックリードのTerukiです。
以前投稿した脱PHPプロジェクトが完了しましたという記事でSFDCの脱却するという話を書きました。
現在絶賛移行作業中なのでその話を共有できたらなと。
なぜ移行しようとしているのか
Oh my teethでは顧客管理としてSalesforceと自社のデータベースを併用しています。
24時間365日稼働するシステムにSalesforceを併用する上では下記のような課題感があります。
- 可用性
- レスポンスタイム
- 開発効率
可用性
脱PHPプロジェクトの記事でも触れていますが、Salesforceは結構可用性が厳しいです。
11月の大規模障害は大変でしたが、その後もちょこちょこと503がAPIから返ってきます。
今月も11日に数十分程度エラーが発生していました。
幸い実装していた指数バックオフによるHTTPリクエストのリトライにより業務影響はギリギリ発生しませんでしたが、通知チャンネルに警告が大量に出てきていたのでその対応が大変でした。。
レスポンスタイム
SalesforceはSOQLという独自SQLを使ってデータを取得してきますが、これはHTTPリクエストで行われるので直接データベースにTCP接続するのとではレスポンスタイムが不利です。
また、アクセストークンは定期的にリフレッシュする必要があるためトークンが失効したら新しいトークンを取得しにいかないといけません。
この処理はだいたい1秒程度かかるのでこのタイミングでは少々待たされます。
開発効率
当たり前ですが、自社のデータベースのSQLとJOINできるわけはないので一旦自社データベースで取得してきたレコードに対してSalesforceのデータを後付けしていくようなコードを書いています。
これだけで結構厳しいのですが、SalesforceへのアクセスはSOQLというSQLライクな言語で記述するのでこれもなかなかです。
SOQLもSQLインジェクションされないようなコーディングが必要ですし、文字列なのでコンパイル時にTypoに気づくこともできません
移行方針
上記問題を解決するために、Salesforceで管理していたデータをすべて自社データベースに移行することにしました。
とはいえ0、100の切り替え作業はリスクが大きすぎるので、下記の流れで移行を行っています。
- SFDCにあるオブジェクトと同じスキーマのテーブルを自社データベースに作成
- 自社データベースにデータ移行
- SFDCオブジェクトを更新する処理すべてに自社データベースも更新するように処理追加
- SFDCオブジェクトを参照する処理をすべて自社データベースを見るように変更
- SFDCオブジェクト更新処理を削除
これで比較的安全に移行作業を行うことができます。
記事執筆時点で7割程度の移行進捗ですが、残りもこの流れで対応予定です。
その他のSFDC要素
SalesforceはリッチなUIやレポート出力が非常に便利です。
ここに触れずに記事を終えるわけにはいきません。
便利ゆえにこれらを移行するのは非常に大変です。
私達はチームの技術力に物を言わせてSalesforceのUIでできることをReactで自前実装しました。
レポート出力については可能なものはLooker Studio化しています。
各部共通化されたコンポーネントをひたすら使いまわして綺麗なUIを作成しています。
社内向けなのでスクリーンショットなどは載せられないですが、最後はパワープレイです
おわりに
なんだかSalesforceネガキャン記事になってしまっている感はありますが、そもそもCRMとしての便利機能がたくさんあり、それ故に多数の企業で採用されていると思います。
そんな中、脱SFDCという大規模な開発を伴う意思決定を出来るのは、SFDCでできる機能のすべてを自前開発できるTechチームがあるからに他なりません。
私達Techチームとしては可用性という絶対に譲れない部分があるため脱SFDCを進めていますが、創業から今まで5年近く共にしてきました。
これまで頑張ってくれたことに感謝しつつ、今後は自前で頑張っていこうと思います。
あと残り少ないですが、Salesforceさんよろしくお願いします
Oh my teethについて
Oh my teethでは未来の歯科体験を創るために日々活動しています。
Techチームではより良いユーザー体験を提供するべく、Webフロントエンドからバックエンド、スマホアプリに機械学習モデルなど、さまざまなプロダクトを開発しています。
一緒に未来の歯科体験を創りませんか?興味がある方は是非こちらを確認してください。
カジュアル面談も可能なので気軽に応募してみてください!
