SaaS開発の落とし穴 〜監視・ログ設計編〜
はじめに：見落とされがちな監視・ログ設計
「特定の顧客だけが遅い」「データが消えたので誰がやったか調べてほしい」。SaaSの運用が始まると、こうした問い合わせにエンジニアが追われがちです。
その多くは、オンプレミスや単一環境で通用していた「標準的なログ出力」を、マルチテナント前提のSaaSにそのまま持ち込んでしまうことが原因です。全顧客の挙動が混ざり合う環境では、ログやメトリクスに「どの顧客のものか」が紐づいていないと、状況把握そのものが難しくなります。
本記事では、監視・ログ設計の「落とし穴」と対策を見ていきましょう。
① 「見えなくなる」マルチテナント監視
複数の顧客がリソースを共有するSaaSでは、「インフラが健全なら、アプリケーションも正常に動いているはず」という考え方が通用しません。
サーバーのCPUやメモリに余裕があっても、特定のテナントだけが遅延に悩まされていることは珍しくありません。全体の平均レスポンスタイムが100msでも、一部の顧客だけが5秒待たされている、という状況は「平均値」に隠れてしまうからです。
さらにSaaS特有の問題として、ノイジーネイバー（騒がしい隣人）問題があります。特定テナントの大量処理やバーストアクセスが、同じ基盤を共有する他テナントのパフォーマンスを下げてしまう現象です。
対策
システムの健康状態を顧客単位で把握するために、次の2つを設計に組み込みます。
- テナントIDの付与 : メトリクスやログに「どのテナントか」を紐づけ、監視の死角をなくす
- テナント別のリソース計測 : 消費量をテナントごとに切り出し、暴走した「隣人」に制限（スロットリング）をかけられるようにする
② 障害調査で苦労しないためのログ設計
開発中は「デバッグに役立つから」と多くのログを流しがちですが、本番では複数テナントから大量のリクエストが押し寄せます。意味の薄いログが混ざると、障害時に必要な情報を探し出せなくなります。
特に問題になりやすいのは、次のようなログです。
- スタックトレースだけで、「どのテナントの、どのユーザーか」が分からない
- プレーンテキストで、サービスをまたいだ挙動を追えない
- エンジニアしか読めず、CSや顧客が自分で確認できない
対策
調査を効率化する鍵は、ログの構造化とトレースIDです。
- 構造化ログ (JSON形式) : 「TenantID = 'A社' かつ Severity = 'Error'」といったフィルタリングを瞬時に行える
- トレースID : 一連の挙動をフロントエンドからDBまで「一本の線」として追跡できる
あわせて、CSや顧客自身でも確認できるように可視化しておくと、調査依頼のたびに開発が止まる事態を避けられます。
③ 事業継続を左右する監査ログ
区別しておきたいのが、不具合を直すためのデバッグ用ログと、サービスの正当性を示す監査ログ（操作ログ）の違いです。監査ログには、次の情報を改ざんできない形で記録する必要があります。
- いつ : タイムスタンプ
- 誰が : ユーザーID
- どのテナントで : テナントID
- どのデータに : リソース名
- 何をしたか : アクション
特に金融・医療・公共などの分野では、コンプライアンス要件として次のような対応を求められることが珍しくありません。
- SOC2などの外部認証の取得
- 操作ログの長期保存（1年〜数年）
- 特定テナントのログだけを抽出・出力できること
リリース後に「過去3ヶ月分の全操作ログを提出してほしい」と求められ、デバッグ用の不完全なログしか残っていない、という事態は避けたいところです。
対策
監査ログは、アプリケーションを作り始める前から設計に含めておきましょう。記録項目（いつ・誰が・どのテナントで・どのデータに・何を）に加えて、改ざん防止・長期保存・テナント別の抽出まで見据えておくことが大切です。
「権限設定を変更した履歴をすぐ出力できるか」「そのログが特権管理者にも消されないか」といった問いに、仕組みとして答えられる状態を目指します。
④ すべてを自前で抱える負担
これらの課題をすべて自力で解決しようとすると、共通基盤の構築にプロダクト本体と同じくらいの工数が必要になります。限られた開発リソースを基盤づくりに費やすことは、市場への参入を遅らせる要因にもなります。
対策
そこで検討したいのが、SaaS開発に特化したプラットフォームの活用です。例えば SaaSus Platform は、認証情報と「どのテナントに属するか」を紐づけて管理するため、テナントIDやユーザー属性をログに付与しやすくなります。ログの役割は次のように分かれます。
- 基盤側の操作ログ : ログイン、パスワード変更、テナント情報の変更など。SaaSus Platform が標準で自動収集します。
- アプリケーション固有のログ : 文書の削除やデータのエクスポートなど。アプリケーション側で出力しますが、SaaSus Platform がテナントID・ユーザーコンテキストを管理するため、紐付けをゼロから設計せずに済みます。
収集したログは管理画面から検索・出力できるため、「CSからの調査依頼」や「顧客へのログ提供」を、エンジニアの手を介さずに完結させることもできます。
まとめ
監視・ログ設計は事後確認の手段にとどまらず、顧客の信頼を守り、サービスの品質を支える事業の土台です。マルチテナントを前提とした監視・ログ設計には、次のような落とし穴があります。
- テナントIDが欠落した「見えない」監視
- 障害調査で苦労するログ設計
- 事業継続を左右する監査ログの不足
- 共通基盤をすべて自前で抱える負担
開発の早い段階でこれらに備え、必要に応じて SaaSus Platform のような外部基盤も活用しながら、メトリクスからアプリケーションログ、監査ログまでを顧客単位で把握できる体制を整えていきましょう。
Spread the word:
