freeeと確定申告

freeeでは個人事業主や法人向けのクラウド会計ソフトであるfreee会計¹を提供しています。freee会計は確定申告の書類作成にも利用されるため、確定申告期間（2月中旬〜3月中旬）は年間で最もアクセスが集中します。アクセス数は1月から徐々に増加し、3月中旬の提出締切直前にピークを迎えます。

この期間のトラフィックには普段と異なる以下のような特徴があり、入念に準備することが必要になります。

アクセス数の急増: 通常時の数倍規模のアクセスが短期間に集中
ユーザー層の変化: 主に個人事業主ユーザーからのアクセスが増加
ワークロードの変化: 記帳や確定申告書類作成にともない書き込み処理の割合が増加

プロジェクトの目標と体制

今回のプロジェクトでは、確定申告期間中のfreee会計において以下の2点を主要な目標としました。

重大な障害の防止: サービス利用に著しい支障をきたす、または広範囲な機能停止につながるインシデントを未然に防ぐこと
快適なユーザー体験の維持: 設定したサービスレベル目標（SLO）を達成すること

加えて、インフラコストの最適化や、将来のキャパシティプランニングに活かせる知見や仕組みを整備することも考慮しました。

プロジェクトは確定申告期間の数ヶ月前にキックオフを行い、期間終了まで継続的に取り組みました。全社横断的なサービスの信頼性向上に取り組むSREチームを全体の取りまとめ役として、freee会計本体の開発チーム、関連するマイクロサービスやコンポーネントを担当する各開発チームと連携してプロジェクトを進めました。

取り組み内容

キャパシティプランニングのための主な取り組みについて、実施した流れに沿ってご紹介します。

1. SLOとモニタリング指標の定義

まず、ユーザー体験が維持できているかを定量的に判断する基準として、確定申告期間向けのSLOを設定しました。確定申告機能を担当しているエンジニアとプロダクトマネージャーにより、ユーザーにとって特に重要となる操作（クリティカルユーザージャーニー）を特定し、それらに対するエラーレートとレイテンシの目標値を定めました。重大な障害を防ぐことと同様に、このSLOの達成が確定申告においては最優先になります。

次に、インフラやミドルウェアなどのリソース状況を評価するための観点を整理しました。freee会計は多数のマイクロサービスで構成されており、各サービスの特性はそれぞれ開発チームが最も深く理解しています。そこで、SREは全サービス共通で監視すべき最低限の指標や評価基準を提示し、各チームが自律的にリスク評価を行える体制を構築しました。

2. 定例による継続的なモニタリングと情報共有

プロジェクト期間中は、SREと確定申告関連サービスの主要開発チームが参加するミーティングを定期的に開催しました。このミーティングはプロジェクトにおける重要なコミュニケーションの場であり、主な目的は以下の通りです。

リソース状況の確認: 各チームが担当サービスの主要メトリクスを報告し、異常の兆候がないかを確認
懸念事項の共有と相談: 各チームが抱える懸念点や新たに見つかったリスクを共有し、必要な対策を検討

Slackなどの非同期なコミュニケーションパスはありましたが、定例ミーティングは強制的なチェックポイントとして機能し、潜在的なリスクの早期発見や対策漏れの防止に有効でした。定例では各チームに事前にサービスの状況を所定のフォーマットで共有してもらい、効率的に情報を集約・分析することで、申告期間中に変化し続けるトラフィック傾向に対し、早期にリスクを発見し対策に繋げられるようになりました。

3. ユースケースベースのリスク洗い出し

目標と進行体制が定まった後、具体的なリスク特定に移りました。事業成長に伴いfreeeのシステムアーキテクチャは継続的に進化・複雑化しており、単一チームや個人が全体像を完全に把握するのは困難です。そのため、やみくもに対策するのではなく、確定申告の主要ユースケースに着目し、システム内部でどのような処理が発生するか追跡することで、対応が必要な箇所を特定するアプローチをとりました。

SREと開発チームで協力し、ワークショップ形式で議論しました。例えば「申告書を出力する」というユースケースについて、ブラウザ操作から始まり、ロードバランサーへのリクエスト、アプリケーションサーバー内の処理、関連マイクロサービスの呼び出し、データベースやキャッシュへのアクセスといった一連の流れを追い、パフォーマンスのボトルネックや可用性のリスクとなり得る箇所を洗い出しました。

4. 可観測性の向上

リスク洗い出しの過程で、リクエスト処理の重要な経路上にあるコンポーネントで可観測性が不足している箇所が判明しました。これらの箇所に対し、分散トレーシングの導入や詳細なメトリクス・ログ収集の強化などを行い、問題発生時の迅速な原因究明を可能にする改善を行いました。

5. 基盤サービスの調査

またリスク分析を進める中で、認証・認可、課金といった、問題発生時の影響範囲が広い基盤サービス群に対し、SREと開発チームともに解像度が低いことがわかりました。これらのサービスのオーナーチームに協力を依頼し、アーキテクチャの概要、主要な依存関係、潜在的なリスク要因（スケーラビリティ限界、単一障害点など）を整理・共有してもらいました。

SREでは、これらの情報と確定申告期間特有のトラフィックパターンを照らし合わせ、予想されるリスクについてオーナーチームとさらに議論を重ねました。一見すると関連が薄いサービスでも、間接的な依存関係によって高負荷時にボトルネックとなりうるケースなどもあり、実際の利用状況を踏まえた調査が重要でした。

6. 外部連携APIの調査

確定申告の操作はfreee内部だけで完結せず、外部の連携サービスのAPIなど多くの外部システムを利用します。これらの外部APIには、多くの場合レートリミットなどの制限が存在します。確定申告期間のアクセス増加でこれらの制限に抵触しエラーが発生しないか事前に各APIの仕様を確認し、必要に応じて利用頻度の見直しや上限緩和などの対策を検討しました。

7. AWSバーストクレジットの網羅的調査と対策

過去にAWSリソースにおけるバーストクレジット²の枯渇が、サービス影響につながった事例がありました。その都度個別に対応はしてきましたが、サービス全体にわたる網羅的なリスク評価や恒久対策は十分でない部分がありました。

そこで今回のプロジェクトを機に、この課題に体系的に取り組みました。freeeで利用している主要なAWSサービスについて、バーストクレジットの仕様、監視方法、枯渇時の影響を改めて整理し、恒久対策（インスタンスタイプの見直しや監視の強化など）を網羅的に実施しました。

8. インフラ・ミドルウェアの調整

継続的なモニタリングやリスク調査を通じ、Kubernetesのリソース制限やデータベースのスペックやノード数など、インフラやミドルウェアの調整が必要と判断された箇所は適宜対応しました。ただし、単純なリソース増強は過剰なコストに繋がる可能性があります。そのためリソース増強の判断では、以下の観点で費用対効果を考慮しました。

ユーザーへの影響
- 例: KubernetesにおけるOOMは即時エラーになりユーザー影響がクリティカルなので優先的に対応するが、CPUのスロットリングは処理の遅延であるためSLO次第で判断
問題が顕在化してからの対応可能性
- 例: アプリケーションサーバー側のリソースは後から増強しやすいが、データベースは変更にダウンタイムが発生するため早めに対策を実施
アプリケーション側での解決可能性
- 例: 負荷が高いクエリをReaderに向けることにより、データベースのスケールアップによるコスト増加を回避

9. 問題発生時の対応計画の策定

リスク対策と並行し、万一の問題発生に備えた対応計画も策定しました。特にデータベース（Aurora MySQL）は影響が大きく、復旧作業にもトレードオフが伴うものが多いです。過去には負荷上昇時の対応方針の決定に時間を要した事例もあったため、今回は重点的に計画しました。

想定される問題のシナリオごとに具体的な初期対応（非同期ジョブワーカーの削減、Failover、Readerの切り離しなど）を定義し、各対応のSLO影響と実行条件を明確化しました。開発チームやプロダクトマネージャーなどの関係者と事前に合意形成を行うことで、問題発生時の迅速な意思決定と対応ができることを目指しました。

振り返りと今後の展望

今回のキャパシティプランニングへの取り組みにより、freee会計では確定申告期間中に重大な障害は発生せず、事前に設定したSLOも維持することができました。

freeeでは過去にも確定申告のピーク負荷に備える取り組みは行われてきましたが、今回のプロジェクトを通してキャパシティプランニングのプロセスが改めて整理され、これまで以上に体系的に進めることができました。特にプロジェクト初期のシステム構成の把握やリスク要因の調査は、効果的な対策を進める上で重要でした。

今回確立したプロセスと知見を利用し、来年以降は前年からの差分の分析や反映に重点を置くことで、より効率的にプランニングできるようにしたいと考えています。