こんにちは、認証認可基盤・課金基盤のエンジニアリングマネージャーを務めている muraと申します。直近2年間は、今回お話しするfreeeの認証認可基盤のマイクロサービス化のプロジェクトにバックエンドエンジニア、エンジニアリングマネージャーとして携わってました。最近はfreeeが利用する課金基盤のエンジニアリングマネージャーも兼務するようになり、本格的にマネージャーの道を歩み始めたところになります。
本日は、私が2年間携わってきた「認証認可基盤のマイクロサービス化」のプロジェクトについてお話しします。このプロジェクトは私が入社するより前の2019年から進められてきたプロジェクトで、2022年6月末に移行に一区切りがついたものになります。プロジェクトの始まった経緯や実際の移行作業に加えて、4年間という長期間のプロジェクトへの振り返りについてお話させて頂ければと思います。
freeeの認証認可基盤の成り立ち
freeeは2012年に会計アプリケーションの提供からスタートしました。アプリケーションを提供するにあたり、ユーザ・事業所の管理、パスワードでのログイン、会計でのユーザの持つ権限の管理機能などの実装がされていきました。数年すると、freeeではユーザ価値の拡大のために人事労務のアプリケーションの開発に着手するようになりました。こういった複数のアプリケーションを1つのIDで利用できるようにするために整備されたのが freeeアカウント管理、および旧認証認可基盤です。以下に当時のアーキテクチャ構成を示します。
認証認可まわりは以下の責務に分かれていました
- freeeアカウント管理
- 各プロダクトのパスワード認証・OAuth2認証画面などの提供
- ユーザ・事業所共通情報の設定画面
- 認証認可基盤
- ユーザ・事業所の情報のRead/Write機能の提供
- 認証情報や権限情報のRead/Write機能の提供
- freee認証ライブラリ
- 各プロダクトから認証認可基盤へのアクセス用ライブラリ
- 認証セッション情報のRead/Write機能の提供
この機構が実装されたことにより、freeeでは1度認証すれば複数のプロダクトが利用できる仕組みを整えることができました。
旧アーキテクチャの課題と新基盤プロジェクトの発足
このアーキテクチャでは5年ほど運用されていきましたが、運用年数が経過するにつれて多くの問題が顕在化するようになりました。特に大きく問題になっていたのがfreee会計DBの高負荷問題です。
旧来は、各プロダクトでユーザ・事業所および認証認可の情報を参照・更新する際には、認証認可基盤を介してfreee会計DBにアクセスする形となっており、プロダクト数や機能の開発に応じてリクエスト数が増大する問題が生じていました。また、freeeは会計を中心としたプロダクトが多く存在するため、会計DBが高負荷の状態となることによるfreeeの全面ダウンへのリスクも高い状況となっていました。
データベースに関しては、AWS RDSのスケールアップによる対応を進めていったものの、freeeの利用数の増大に耐えきれないことが早い段階で分かっていました。負荷の対策として、MySQL から Aurora への移行 に加えて、シャーディングによるスケールアウトの検討がなされていきました。
そのほかにも、以下のような問題を抱えていました
- 認証認可のデータモデルの技術的な負債
- 必要なデータを継ぎ足しで追加したため取り回しのしづらい状況にあった
- 会計のデータに強く依存するために改善がしづらい状況になった
- freee認証ライブラリに関する問題
- 認証認可機能の改善に伴い多くのプロダクトに更新をかける必要があった
- 利用するプログラミング言語の増加に伴ってライブラリのサポートが困難な状況にあった
上記を踏まえて、新認証認可基盤への移行プロジェクトが2019年にスタートし、主に以下の要素が盛り込まれる運びとなりました。
ユーザ・事業所・認証認可を管理するテーブルのシャーディングとデータモデルの改修 gRPC / protocol buffer を利用したアクセスライブラリの自動生成 新しい認証セッションによるセッションの一元的な管理
以下に現状のアーキテクチャ構成を示します。
新認証認可基盤への移行
認証認可基盤が担保しているユーザ・事業所情報の管理および認証認可の機能はfreeeにとっては欠かせない機能であり、問題があればfreeeの全面ダウンに繋がるサービスになります。freeeがダウンすることなく新しい基盤に移行するために、以下の手順を踏まえて移行することになりました。
会計DB と 新認証認可DB の自動同期機構の実装 新旧基盤それぞれでデータ/セッションの読み書きを実施した上での差分の確認とエラーの修正 旧基盤からのデータ/セッションReadを停止
まず始めに新DBの作成と旧DBとの同期機構に着手しました。新DBではデータモデルにおける技術的な負債を解消するために対応する新しいテーブルを設計・構築しました。同期機構は旧DBが高負荷になることを避けるために、旧認証認可基盤およびfreee会計からのActiveRecordによるafter_save/after_commitをhookとして新認証認可基盤へと更新処理を通知し、データを同期する機構を実装しました。
次に、新認証認可基盤の機能開発を進めつつ、各プロダクトから新旧基盤へのRead/Writeに差分がないことを確認する機構の実装に着手しました。ここでは認証ライブラリからの呼び出しを起点として、新旧基盤からのReadをしてライブラリ内のメソッドで差分を比較します。基本は新基盤の結果を返しますが、差分があればエラー検知SaaSであるbugsnagに通知して旧基盤の結果を返します。開発者はエラーを見て問題を調査し、徐々に新旧基盤の処理の差分を埋めていくことで、移行時にユーザ影響がないようにしていきました。認証セッションについても同様の仕組みを実装することで対応しています。
また、データのWriteについては旧基盤を起点として新旧DBへのWriteの差分をチェックしています。Readは新基盤への負荷を踏まえてプロダクト毎に有効状態を管理したいことに対して、WriteはDBのAuto IncrementによるIDの発番を新DBに移すことを踏まえて一元的に切り替えられるようにするため、実装箇所を変える必要が出てきました。
データ/セッション共にRead結果に差分がなければ、プロダクト毎にチェック機構を停止して新基盤からのReadに切り替えて行きます。最後のWriteの処理については、Writeの順序を新旧基盤で交換した上で、旧DBからID の Auto Incrementを外し、新DBにID の Auto Increment を付ける必要があり、これをメンテナンスで実施しました。これにて移行はほぼ完了となり、あとは旧基盤の機能を停止していく流れとなります。
それぞれの機能のOn/Offに関してはユーザに影響がないようにリスクの洗い出し、QAの実施などを事細かに実施しました。関連するチームも各種プロダクトチームのみならず、データ分析基盤を管理するチーム、インフラを担当するSREなど多くのチームと協力体制を組みながら実施を進めていきました。QAも14プロダクト、633テストケースとfreee内でも最大のQAとなりました。
そして2022年6月に4年弱越しの移行を達成しました。すでに現状のfreeeは新認証認可基盤をベースとして動いており、特に大きな影響もなく稼働している状況となります。
プロジェクトの振り返り
移行プロジェクトの手順自体は上記の通りですが、実際には4年間かかりました。この主な要因としては以下が挙げられます。
- 新旧基盤のRead/Writeの挙動の違いを修正するのが非常に困難だった
- 旧DBに含まれる古いデータによって新基盤でバグが大量に発生した
- 開発工数の見積もりが不足しており延期が多発した
挙動の違いについては新基盤でのデータモデルの改修が大きく影響しました。新基盤ではDDD(ドメイン駆動設計)を活用してドメインモデルとしてあるべきインターフェースを実装する方針が採られていたので旧基盤との挙動の違いが大量に発生しました。また、freeeではユーザ・事業所のデータモデルが少し難しく、権限の付与や所属管理の機能を新基盤で模倣することが困難であり、挙動を合わせる工数が増大しました。
加えて、freeeの開発初期に入ったデータによるバグも多く発生しました。開発初期はリリースが優先となりvalidationが不十分な点が多かったのか、現状では入ることが想定されないデータがあります。旧基盤はそのような不正データをすり抜けるような処理が含まれていましたが、新基盤では担保できずエラーになるケースが後を絶たない状況となっていました。
以上のようにエラーの対応の件数が増加したことに加えて新基盤の対象範囲が広く必要となる機能の開発工数の再見積を行うケースが多く、最終的には4年弱の月日がかかることとなりました。
今回のプロジェクトは良い面もあります。まず、今回の大規模な改修を乗り越えたことで新しい機能の開発に着手できるようになりました。今までユーザに対して不便をかけていた面も多々あるものの改善が出来ないことに煮え切らないケースが多くありましたが、今回のデータモデルの改修や負荷軽減を通じて新規機能の開発着手に取り組めるようになっています。
しかし、完了までに時間がかかったことを踏まえるとこれを良しとするのはよくありません。プロジェクトの改善策としては以下が挙げられます。
- 細かくリリースをできるような開発計画を組むべき
- 旧機能のリファクタはマイクロサービス化の前に着手すべし
今回のプロジェクトはデータモデルの変更、新基盤の開発、認証セッションの移行など様々な要素を1回で完遂するプロジェクトでした。そのため、開発工数の見積もりが困難となり延期が増えるなど開発メンバーの精神が摩耗する状態となっていました。また、リリース回数が少ないために振り返りの頻度も多くなく、改善施策が出しづらい状況になったことも課題として上がっています。将来的なプロジェクトでは、対象となるテーブル数を最初は少なくする、移行するにも短期的なゴールを持つことが重要であると感じています。
また、マイクロサービス化の前に古いロジックを先にリファクタすることも重要です。古いロジックは意図しない挙動を前提としているケースが多々あり、切り出した先で模倣するのが大変困難なケースが多くあります。そのため、まずは現状を整理して簡単な処理にリファクタした上で、マイクロサービス化することが大事になってくると思います。 さいごに 認証認可基盤のマイクロサービス化という大きなプロジェクトは完了しました。しかし、認証認可基盤のチームはここで満足せずこれを礎に新しい機能の開発に着手し、ユーザにとって価値のある機能を提供できるよう努力していきます。
この記事では詳細に言及できなかったところもありますが、後日 freee Tech Night の 「これってもしかして……認証基盤が入れ替わってる〜？」でもお話させて頂こうと思っています。是非ご参加頂ければと思います。
最後に、freeeの認証認可基盤・課金基盤では一緒に働く仲間を募集しています。ご興味のある方は是非ご応募ください。 人材募集（求人一覧）
