• Home
• コーポレートブログ
• AWS で運用している複数の Rails アプリケーションの連携方法と機能の分離についての考察

先日、歯医者に行ったとき何やら口を開けた状態に固定する器具をつけられたのですが、顎鬚、口髭の両方が引っかかって痛かったです（結局器具はつけず）。こんにちは、吉岡です。

現在、弊社ではサービスの拡大に伴い AWS で複数のアプリケーションを運用していますが、運用する過程でさまざまな課題が発生してきました。

そんな中、先日、JAWS-UG島根支部（AWSが提供するクラウドコンピューティングを利用するコミュニティの島根支部）のイベント「JAWS-UG Shimane #12」の企画の一環として、AWS シニア サーバーレススペシャリスト ソリューションアーキテクト の下川さんにご相談させていただく機会がありました。（下川さんその節は大変ありがとうございました！！）

今回はその時頂いたアドバイスを参考にしながら、考察した内容の一部を共有します。

概要

弊社では、My Redmine という名前で Redmine を SaaS として提供しています。また、Ruby on Rails（以下Rails）を利用した独自のシステム（以下「顧客管理システム」）を開発して顧客情報や請求情報を管理しています。

ここ最近、Redmine から顧客管理システムの顧客情報や請求書関連の情報を確認できる必要性が生じました。現時点では、Redmine のプラグイン（独自開発）を利用することで一定の対応はしていますが、運用中にさまざまな課題も浮上してきました。そのため、今後の開発方針について考えることとしました。

課題

以下の課題があります。

課題 1: 負荷の高い処理によってサーバー全体に影響が発生

顧客管理システムで数百件を超える請求書（PDF）の作成を実行すると負荷が上昇し、アクセスしづらい状況が発生します。請求書（PDF）作成の機能を Rails（システム）から切り離して影響を少なくする必要があります。

課題 2: Redmine と顧客管理システムのセキュアな接続

登録情報の確認、請求書の確認、ダウンロードなどを Redmine から利用できる必要があり、そのためには顧客管理システムから情報を取得する必要があります。基本的には Redmine から顧客管理システム（Rails）側で準備した API をコールして情報を取得するのですが、よりセキュアかつ継続的に開発が進めやすい設計を考える必要があります。

現状の対応

現状では課題については、以下のような対応を行いました。

• 課題 1 のサーバーの負荷に対しては顧客管理システムはスケールアップで対応しました。（CPU,Memory の増設）
• 課題 2 のシステムの連携については図のように対応しました。
  1. 顧客管理システム側で連携用の API（API Gateway） を準備し、契約者の情報を取得、請求情報の取得ができるようにした。接続の認証に関してはそれぞれのシステムが AWS 上で動いているので、IAM ロールを利用して認証を行うようにした。
  2. 請求書データ（PDF）を S3 にアップロードする機能を API に追加した。（顧客管理システムからアクセス）
  3. 請求書データ（PDF）を S3 からダウンロードする機能を API に追加した。（Redmine からアクセス）

まず、機能としては条件を満たし運用もできているのですが、この構成ではプロダクト同士の依存関係も大きく、開発が進むにつれてさらに複雑になることが予想されます（つまり開発速度が低下する可能性が大きい）。また、負荷の高い処理については根本的な対応をしていないので、解決する必要があります。

今後の方針

課題と現状の対応に対して、今後どのようにアーキテクチャに修正を加えていくか考察してみます。大きく二つのアーキテクチャを考えそれぞれのメリット、デメリットを考えてみました。

案１

• 機能の分割を意識して、DB を分割し、請求関連の情報は全て API 経由でデータにアクセスする。（登録、更新、削除）
• 請求書関連情報は新しい API に切り離し、顧客情報は新しい DB に同期される。これにより Redmine からは顧客管理システムの API にアクセスすることは完全になくなる。

1. 契約情報の取得、請求情報の取得
2. 請求情報の作成・更新
3. 請求書のダウンロード

メリット

• 請求書関連の機能を完全に切り離すことができるので、それぞれの開発プロダクトへの影響を最小限に抑え、開発を進めることができる。
  • 独立したプロダクトとして開発が進められため、開発の進捗が早くなる。
• AWS のサーバーレスを利用することで、運用コストを抑えることができる。

デメリット

• Rails の機能分割をするので、開発コストがかかる。
• 顧客情報をそれぞれのシステムで更新処理を行う必要がある。（データの整合性を保つための仕組みが必要になる。）

案２

• データの管理は顧客管理システムに集める。分割しない。
• Redmine からは API Gateway を参照するだけ（プロキシー）

1. 契約情報の取得、請求情報の取得
2. 請求情報の請求書の生成とアップロード（Rails から Stepfunctions をコール）
3. 請求書のダウンロード

メリット

• 顧客情報の更新処理を一元化できるので、データの整合性を保つための仕組みが不要になる。
• Rails の機能分割をする必要がないので、開発コストを抑えれる。
• 一部機能を AWS のサーバーレスを利用することで、運用コストを抑えることができる。

デメリット

• 請求書関連の機能を切り離すことができないので、Rails の肥大化し、影響範囲が大きくなる。
• 新たにメンバーが入った場合、顧客管理システムを把握するコストが上がる。
• デプロイのコストは変わらない。（場合によっては増える）

結論

それぞれメリット、デメリットを比較し検討しましたが、今回は弊社の開発体制なども考慮して、案2を選択しました。

• 案1を選択した場合、メリットとして考えられる、開発速度の向上が見込めない。
• また、Rails の機能分割にかかるコストが大きく、開発の進捗が遅くなる可能性がある。

という点を考慮して、案2のほうが得られる恩恵が大きいと判断しました。

※ 前提条件として、弊社では基本的には現時点では少人数で開発を行なっており、各人がプロダクトに対してある程度理解している状況です。

まとめ

最後にイベントの企画内で頂いたアドバイスも少し触れたいと思います。アドバイスをいただくまでは、パブリッククラウドを利用する場合、モノリスなアプリケーションはなるべく機能を分割するほうがうまく運用ができるという考えでしたが 「必ずしもモノリスな WEB アプリケーションを分割する必要はない」というお話しをお聞きして、非常に参考になりました。また、観点として「分割することによって結果として開発速度（アジリティ）が上がるかが大事」というようなお話しもいただきました。

今回、上記アドバイスをいただいたことで、意思決定が非常にしやすくなりました。また今後、何かのタイミングで開発方針を変更することも考えられますが、現時点ではこの判断が最適だと考えています。

注）自分の解釈が含まれており、実際の発言とは異なる可能性があります。

【スタッフ募集中】
弊社ではAWSを活用したソリューションの企画・設計・構築・運用や、Ruby on Rails・JavaScriptフレームワークなどを使用したアプリケーション開発を行うスタッフを募集しています。採用情報の詳細
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。

---