LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

LIFULL HOME'S 注文住宅 APIリプレイスにて期待する効果が得られず再設計した話

こんにちは。エンジニアの加藤です。 普段はLIFULL HOME'Sの注文住宅領域にてエンジニアチームのマネジメントを担当しております。

LIFULL HOME'Sでは日々新機能の開発や機能改修を重ねておりますが、一方でレガシーコードや技術的負債も少なからず抱えており、開発速度低下や開発の幅を狭める一因となっております。

そのような状況の下、ここ数年、機能開発と同様に技術的負債の解消への取り組みにも注力し、注文住宅領域においてもシステム基盤刷新プロジェクトとして、開発効率向上やビジネス成長に耐えうる基盤づくりに取り組んでおります。

今回はそのシステム基盤刷新プロジェクトの一部であるAPIリプレイスを経て学んだ、当初の期待とそれに対するギャップ、そしてそれを踏まえた改善をお伝えしたいと思います。

システム基盤刷新プロジェクトの初期設計

システム基盤刷新プロジェクトでは最終的にはLIFULL HOME'S 注文住宅を構成するそれぞれのシステムのリプレイスを図るものとなっておりますが、領域毎フェーズを分けて実施をしております。

その中でまずは以下のように全体的なシステム設計を行った上、リプレイスに取り組みました。

f:id:LIFULL-katoyut:20200927235128p:plain

LIFULL HOME'S 注文住宅には大きく分けて3つのシステムによって構成されております。

一つ目はエンドユーザ向けシステム(以降、web)、二つ目にハウスメーカーや工務店などクライアントへ向けた管理システム(以降、manager)、そして社内用管理システム(以降、client manger)となります。

マイクロサービス化を想定し、それぞれのシステムに対しフロントエンド層とそれに対応するBFF層を構成し、将来的に複数の機能別サービスに対応するAPIを呼び出す可能性を考慮した設計を行いました。

当初の設計時の期待としては以下となります。

期待

  • 機能毎のサービスが増えた際、それらの呼び出しはBFF層で吸収しフロントエンド層をシンプルにする
  • それぞれのAPIにて依存関係や関心の分離を図る
    • BFFは各システムのビジネスロジックや業務ルールに関心を持つ
    • BFFはデータの取得先やDBには関心を持たない
    • db-apiは意味のあるまとまりでDBからデータを取得・更新する
    • db-apiは各システムのビジネスロジックや業務ルールに関心を持たない
  • db-apiの各エンドポイントは特定のシステムによらない設計とし、複数BFFから呼び出し可能とする
    • 同様の処理を各システムにて重複実装することを防ぎ、開発の効率化を図る

APIリプレイスを進めて見えてきたギャップ

上記設計に基づき、まずはdb-apiとclient manager-apiのリプレイスを実施致しました。

しかし、開発・運用フェーズを経ることで、徐々に期待に対しての以下のようなギャップが生じました。

ギャップ

  • 機能毎独立したサービス(API)の必要性がない
  • API開発のコストが増加
  • リリースの複雑性が生じた

一つ目のギャップはマイクロサービス化についてです。

設計当初、将来的には機能毎マイクロサービス化とし、APIを切り出すことを考慮してシステム設計を行っておりました。 しかし、注文住宅領域においてのサービス規模や少人数での開発体制を踏まえると、各機能別にチームを構成し開発を行う必要性が薄く、効率的でないという結論に至りました。

二つ目はdb-apiの再利用性や関心の分離についてです。

理想としてはdb-apiは各システムに依存せず、汎用的で複数BFFから利用可能なエンドポイントを構成するAPIとして期待をしておりました。 しかし、トランザクション等を考慮するとシステムの業務ルールに依存したエンドポイントとする必要性が生じ、汎用的なエンドポイント設計の困難さを感じました。 その結果、各システムに依存するエンドポイントが量産されることが予想され、開発コスト増大の懸念が高まりました。

また、取得処理がメインなweb、更新処理がメインなmanageの双方から利用されるAPIである性質上、ReadモデルとWriteモデルは別々で作成した方がメンテナンスしやすいというDDD的な思想のアンチパターンにも陥っており、開発する上で考慮する観点が増え、こちらも開発コストが増加する一因となっておりました。

三つ目は機能改修時のリリースの複雑性についてです。

機能改修の際は、フロントエンド層、BFF層、db-apiそれぞれに対し開発を行い、リリースの順序によりシステムの整合性を保つ必要がありました。 そのため、リリース時のシステム間での互換性の担保など考慮する部分が増え、結果として開発の複雑性の増大にも繋がりました。

ギャップを踏まえた改善

続くリプレイス対象のシステムとしてweb-apiが控えておりましたが、上記のギャップを踏まえ、当初のシステム設計を見直すこととしました。

その際、見直したポイントとしては以下となります。

見直したポイント

  • 基本的に機能毎のAPI開発を考慮しない
  • db-apiからのデータ取得をやめ、DBから直接データを取得
  • 三層スキーマアーキテクチャにて、業務ルールをViewに集約

f:id:LIFULL-katoyut:20200928005854p:plain

新たな設計では、db-apiの廃止や各BFF間でのエンドポイントの再利用性などを排除した代わりに、影響範囲を一つのシステムに限定する構成としました。

また、APIからのデータ取得部分においても一部変更を加えております。

DBに三層スキーマアーキテクチャを導入することで、単一データベースでの簡易的なCQRSを可能な設計としました。 その上で、webでの利用に特化して条件を絞ったViewを作成し、参照することでAPIにて発行するSQLをシンプルにする期待を見込んでおります。

改善点

新たな設計に基づきweb-apiを構築することにより、以下のようなメリットを享受することができました。

  • 開発対象のAPIが一つとなり開発工数が削減
  • 影響するシステムが限定されることで開発効率が向上
  • Viewにロジックを集約することでAPIのデータ取得ロジックが簡略化され開発コストが低下

まとめ

今回のAPIリプレイスを通じ、結果に対しての振り返りを行い、課題を受け入れ改善することの重要性を学びました。

一度決めたことを変えることはなかなかエネルギーが必要なことではありますが、状況に柔軟に対応しつつ、強い意志を持って変えること、そしてやり遂げることができるチームが強い組織であると考えております。

今回の学びを活かし、今後も技術的負債の解消に向け取り組んで参りたいと思います。