この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2020年9月8日から30日まで開催されるAWS Summit Onlineのレポートです。
本記事で取り上げるセッションは下記となります。
セッション情報
スピーカー
株式会社 LegalForce 製品開発セクション 取締役兼 CTO 時武 佑太 氏
概要
B2B SaaS ではいかにユーザーの利便性を追求した機能を搭載できるかがプロダクトの価値向上には重要であり、その中でも他サービスとの連携は有効な選択肢です。 しかし、人数の限られたスタートアップにおいて連携機能を実装するのは比較的開発コストが高く、綿密な戦略が求められます。 当セッションでは LegalForce におけるサービス連携において、サーバレスアーキテクチャを採用した理由と開発体制、アーキテクチャの詳細についてお話します。
セッションレポート
提供しているサービス
- 契約書レビューサービス LegalForce
- 契約書レビューを自然言語処理技術等を用いてサポートするプロダクト
- 契約書管理サービス Marshall
- 締結した契約書を一元管理するためのプロダクト
クラウドネイティブ時代の社内システム
- さまざまなSaaSを使って仕事をする
- 従来はPCにインストールしていたソフトウェアがSaaSに置き換わりつつある
- 複数のSaaSによるワークフローをなめらかに連携させることが大切
- SaaSのハブとなるiPaaSが注目を集めている
- サービスAからファイルをダウンロードし、サービスBにアップロードする、など
契約書のライフサイクル
- 契約ライフサイクルは4つある
- ドラフト
- レビュー
- 締結
- 管理
- ドラフト・レビュー・管理について、LegalForceのプロダクト群で置き換えることができる
- しかし、契約書の締結が網羅できていない
- ニーズは拡大傾向にある
- GMO電子印鑑Agreeとの連携を行うことにした
- 本セッションはこの部分を取り上げている
外部API連携のアーキテクチャ
技術スタック
- Ruby
- Hanami
- Python
既存サービスのアーキテクチャ
- SPAとJSON API
- APIはAWS Fargateでコンテナベースで動いている
- データベースには、Amazon Aurora MySQLを利用
スケジュール感
- 開発に使える期間は、約2ヶ月だった
開発チームの構成
- 開発チームはプロダクト毎に分かれている
- LegalForce
- エンジニア9人
- デザイナー1人
- Marshall
- エンジニア4人
- デザイナー1人
- LegalForce
- 今回のAPI連携開発では、エンジニア2人をアサインした
サーバーレスアーキテクチャの採用
- コードやインフラの構築を少ない手数で実装したい
- 拡張性や柔軟性をある程度確保したい
- サーバーレスアーキテクチャを採用するメリット
- 最小限のコードで動かせる
- 最小限のインフラ構築で動かせる
- スケーラビリティを簡単に高められる
- サーバーレスアーキテクチャのドラフト
- 既存のLegalForceやMarshallからPrivateLinkを貼り、API Gatewayにアクセスする
- 電子締結APIと後ろにあるLambdaから、電子締結APIにアクセスしている
Serverless Framewrkを導入
- サーバーレスアプリケーションの構成管理ツール
- 今後、他のメンバーが運用する場合でも、フレームワークの仕組みに乗っているのので確実にできる
AWS Lambdaの柔軟性の高さ
- ここ数年の大規模アップデートで、さらに使いやすくなった
functionの分割方針
- 1つの処理毎にfunctionを分けるのがベストプラクティス
- 分けすぎると大量にできてしまうため、管理とのトレードオフになる
- 今回は、LegalForce側APIのユースケース毎にfunctionを分ける形にした
Ruby製サーバーレス向けフレームワークの採用
- API Gatewayからのリクエスト・レスポンス部分をフレームワークに任せたい
- Jets
- Hanami API
- 社内で利用実績のある Hanami API を採用した
Hanami APIとは
- Hanamiフレームワーク
- クリーンアーキテクチャの考えで作られている新しいRubyのフレームワーク
- APIだけでなく、Viewなども実現するフルスタック
- Hanami API
- Hanamiフレームワークから、APIに必要な要素以外を除いた軽量バージョン
AWS LambdaとAmazon RDSとのつなぎ込み
- LambdaとRDSを接続するのは、アンチパターンと言われてきた
- Amazon VPCに作成できるENIの制限
- RDSインスタンスの同時接続数の制限
- 昨今のアップデートにより、これらのアンチパターンは過去のものになりつつある
VPC Lambdaにおけるネットワーク環境が大幅に改善された
- 今までは、Lambdaがスケールすると、大量のENIが生成される
- VPCのIP枯渇やパフォーマンス低下の原因になる
- AWS Hyperplaceを通したVPC接続に切り替わった
- Amazon RDS Proxyが東京リージョンでも一般公開された
- RDSインスタンスへの接続をプールできる
- 本番用途では、large以上のインスタンスクラスを使うのが無難
DBマイグレーション
- 本番DBへの接続が必要になるため、閉じた環境で実行したい
- AWS System Manager経由でコマンド発行し、AWS Cloud9から開発者が確認できる構成にした
最終的なアーキテクチャ
- 既存サービスであるLegalForceやMarshallから、PrivateLinkでAPI Gatewayに接続する
- API Gatewayの後ろにいるLambdaから、電子締結APIにアクセスする
- 既存サービス内のAmazon Auroraには、RDS Proxyを用いて接続している
- Amazon Auroraのマイグレーションを行う際は、Cloud9経由でコマンド発行している
感想
既存サービスと外部のAPIを連携するために、サーバーレスアーキテクチャを採用して実現した内容でした。 個人的には、そのようなユースケースもあるのかと気づくことができましたし、開発期間2ヶ月という短期間に実現できたのは、サーバーレスなメリットを十二分に活かせた結果だと思います。
また、Lambdaのアップデートを取り入れる点がクラウドを活用する開発ならではですね。 Lambda-RDS連携の実例を知ることができたのはとても参考になりました。特にAmazon Auroraのインスタンスによって同時接続数の上限が異なる点は良い学びでした。
18
