はじめに
株式会社Omiaiでテックリードを務める渡邊です。これまでデータベースやインフラのリアーキテクトについてお話ししてきましたが、今回はAPIのリアーキテクトについて詳しくお話しします。
APIは外部や内部システムとつながるインターフェースであるため、リアーキテクトにおいては様々な領域の課題とも絡み合っている重要な技術領域です。
Omiaiは2012年のサービス開始から10年以上、多くのユーザーに愛され続けているマッチングアプリです。この長期間の運営とサービス成長の中で浮上したAPIの技術的な課題と、その改善、そしてそこから得た教訓を紹介します。
OmiaiのAPIが抱えていた4つの技術的課題
APIの領域では、10年以上の運営を通じたサービス成長に伴い、4つの技術的な改善点が明確になっていました。
1. 過度な共通化による複雑性の増大
開発効率向上を目指した過度な共通化が保守性を悪化させていました。ある1機能のAPIを修正をすることによって全く関係ない機能へも影響が発生してしまうこともあり、機能修正や機能追加において影響範囲の調査に膨大な工数がかかっていました。
2. 独自フレームワークによるコスト増加
2010年頃に構築したAPIシステムは、リクエスト・レスポンス処理を独自実装していました。当時としては一般的な選択でしたが、メンバーの増員などに伴い、複雑な仕様を理解するためのオンボーディングコストの増加など課題点が見えてきました。
3. 画面とAPIの密結合からの脱却
急成長に対応する中で、APIがクライアント側（画面）を過度に考慮した密結合な設計になっていました。フロントエンドの小さな修正でも、APIやデータベースまで修正が必要になる状況が発生していました。画面で1項目を追加するためにAPI、DBにまで影響範囲が広がってしまい開発速度に大きな影響が出ていました。
4. 言語混在による運用効率の悪化
元々APIはPHPで開発をしていたのですが、2015年前後にJavaへのリプレイスプロジェクトを進めていました。しかし、コストや期間の影響でこのリプレイスプロジェクトは途中でクローズし、結果的にPHPとJavaの2つの技術スタックが混在することになりました。このため、機能修正時には必ず両方の言語に精通したエンジニアが必要になる状況になってしまいました。社内でPHPに精通したエンジニアが減少していたため、緊急対応時の迅速な対応が困難になっていました。
プロダクトへの具体的な影響
これらの課題があり、特に「1. 過度な共通化による複雑性の増大 」の影響が甚大で、機能リリースのたびに影響範囲の確認漏れが起こってしまうことが多々ありました。問題発生時にはデータパッチを手動で適用しリカバリを行っていたのですが、この作業が毎回2〜3時間発生していました。
2024年に実施した大リアーキテクトでは、リカバリや影響調査の工数削減を行い、機能提供の速度を上げるために、過度な共通化の改善と、併せてPHPとJavaの言語混在問題についての改善に注力して取り組みました。
リアーキテクトの第一歩は「設計原則の確立」
リアーキテクトで最も重視したのは、凝集度が高く、結合度が低いAPI設計の実現です。
従来は複数のドメイン領域にまたがる処理が1つのAPIに含まれてしまっていました。例えば、プロフィール取得APIの中で有料会員の確認処理が行われるなど、本来分離すべき処理が密結合してしまっていました。これを「1つの機能を1つのAPIに」という明確な原則に基づいて再設計しました。
結果として、APIの数は約2倍に増えてしまったのですが、RESTfulな設計原則に従った構造に変更することができました。現在提供しているAPIはそれぞれが明確な責務を持つ設計にすることができています。
私が常に意識しているのは、システムはプロダクトの道具であるということです。手段が目的になることは避けたいと考えています。
そのためリアーキテクトでは、将来性、修正容易性、テストビリティを最優先に考えた設計を徹底しました。例えば同じコードがあるから共通化するなどの短期的なコード削減よりも、長期的な保守性を重視する判断により、開発チーム全体の生産性向上につながりました。
設計においては、オブジェクト指向の基本原則、特に依存逆転の法則を意識しています。修正に対して閉じられた設計を心がけることで、長期的な保守性を確保するようにしています。
リアーキテクトのフローと改善の詳細
リアーキテクトでは、まずプロダクトの概念設計（ドメイン設計）を行い、ドメインの重要度が高いところから段階的に改善していきました。
- 検索機能：ユーザー体験の中核
- プロフィール機能：基本的なユーザー情報管理
- メッセージ機能：コミュニケーションの基盤
- いいね機能：マッチングアプリの核となる機能
各ドメインに対してAPIを適切に紐づけ、「このAPIはこのドメインだからこういう処理にしよう」という形で、泥臭くも着実に進めていきました。
言語統一プロジェクトの実行
PHP：Java = 8：2の混在状態から、3ヶ月という短期間でJavaに統一しました。
- プロジェクト期間：3ヶ月
- 実装期間：2ヶ月
- 方法：段階的な機能移行
この統一により、機能修正時に複数言語対応のエンジニアが必要だった状況から、効率的な開発体制を構築することができました。
Feature Flagを活用した安全な移行戦略
リプレイスの際は、Omiaiを利用する1,000万人以上のユーザーへの影響を最小限に抑えるため、以下の安全対策を実施しました。
新旧システムの並行運用
新旧両方のコードを同時にリリースし、Feature Flagで段階的に切り替える方式を採用。データベースの値を書き換えるだけで即座に旧システムに戻せる体制を整備し、安全にリアーキテクチャのリリースを進めました。
迅速な問題発見と対応体制
- ログ出力の強化による問題の早期発見
- 新コードリリースから約1ヶ月の検証期間を経て、問題がないことを確認してから旧コードを削除
慎重なアプローチにより、サービスを停止することなく大規模な技術改善を実現できました。
リアーキテクトがもたらした成果
リアーキテクト完了後の具体的な成果は下記のとおりです。
- 開発期間の短縮：2ヶ月→3週間〜1ヶ月（約2倍の効率向上）
- バグ発生率の激減：頻繁に発生していたバグがほぼ解消
- 手動作業の削減：データパッチ作業が不要になり、手作業運用工数の削減
開発期間の短縮について、従来は開発時間の半分を影響範囲調査に費やしていましたが、これが大幅に削減され、エンジニアはより価値の高い開発に集中できるようになりました。
経験から学んだ「共通化の罠」という教訓
リアーキテクトがもたらしたのは開発環境の向上だけではありませんでした。チーム開発における教訓も、今後の開発にとって大きなプラスになると考えています。
多くの開発チームが陥りがちな問題である「共通化の罠」を、Omiaiでも身を持って経験しました。当初、開発者たちは自分たちが書くソースコードを減らしたいという動機で共通化を進めました。
しかし、これは目先の工数削減にしかならず、結果的に修正時のコストが大幅に増大しました。一つの共通化されたモジュールを修正すると、予期せぬ場所でバグが発生し、その調査だけで膨大な時間を要するようになってしまいました。
現在、Omiaiでは下記2点を共通化の判断基準として大事にしています。
- プロダクトの概念的一致を確認
表面的に似ている処理でも、プロダクト的な意味や将来的な発展方向が異なる場合は、無理に共通化しない方が良いと考えています。システム的には同じでも、ビジネス的な概念が異なるものは独立して管理した方が責務が分離されて修正、拡張も容易になります。 - 進化速度を考慮した判断
特にビジネスモデルのコアドメインで変化が激しい領域では、性急な共通化よりも、まずは各機能を独立して開発し、十分に成熟してから共通化を検討するアプローチを取った方がよいと考えています。
真に価値のある共通化とは、修正、拡張を楽にするための共通化です。パラメータの適切なカプセル化やオブジェクト指向の原則を守り、拡張に対して開かれ、修正に対して閉じられた設計を意識できると良いと考えています。
おわりに
APIの大規模リアーキテクトは一旦完了しましたが、まだまだ課題は残っています。
標準フレームワークへの移行
現在は独自フレームワークを採用していますが、Spring Bootなどの業界標準フレームワークへの移行を検討しています。ただし、これはそこまで優先度が高い課題と位置づけておらず、プロダクトとシステムで共通の課題を解決してから取り組む予定です。
API設計のさらなる改善
画面とAPIの完全な分離を進め、RESTful APIの徹底により、フロントエンドが必要に応じて適切なAPIを呼び出す体制を構築していきます。不要なAPIの削除やBFFアーキテクチャの導入なども検討しています。
APIリアーキテクトは、技術的な改善だけでなく、組織としての問題解決能力を大きく向上させる機会となりました。2015年の失敗を乗り越え、明確な目的と戦略的なアプローチで臨んだ今回のリアーキテクトは、大きな成果を生めたと考えています。
重要なのは、完璧を目指すことではなく、現状よりも良い状態を継続的に作り続けることだと思っています。技術的な課題に正面から向き合い、チーム一丸となって解決していくプロセスは、非常にやりがいのある経験でした。
現在のOmiaiの技術組織は、このような挑戦を通じて大きく成長し、さらなる技術的課題に取り組めています。同じような技術的挑戦に興味のあるエンジニアの方々と、一緒に働ける日を楽しみにしています。
Discussion