SoundCloudは最近、Stranglerパターンを使った、モノリシックコードベースから本格的なBackend For Frontend(BFF)への8年間の移行の過程を完了したことを発表した。BFFはSoundCloudによって先駆けとして開発され、使われているアーキテクチャパターンである。
この発表では、移行を成功させるためのSoundCloudチームがとった手順、移行の過程から学んだこと、Stranglerパターンの利点とリスクについて分析している。
SoundCloudがStranglerパターンを採用する動機は、2014年にさかのぼる。それは、ユーザトラフィックを提供するために複数のマイクロサービスと連携するときにRailsアプリケーションがうまく機能しないことに気付いたときである。そこで、パブリックAPI Strangler BFFが導入された。そこでは必要なときに追加でサービスを呼び出すことで、パブリックAPIの応答をインターセプトし、拡張することができる。
BFF Stranglerパターンアーキテクチャ図 - 出典: BFF @ SoundCloud
このStranglerパターンを採用した動機は、パブリックAPIモノリスのない将来の計画ではなく、差し迫ったニーズであった。その結果、Soundcloudチームは、Stranglerと元のモノリスの両方をほとんどメンテナンスせずにマイクロサービスAPIの開発を続けた。その結果、時間の経過とともに多数の望まない問題、コードの重複、一貫性のないAPIの動作、セキュリティリスクが発生した。この状況に対処するために、SoundCloudチームは2020年1月にStranglerの本格的なBFFへの移行を開始した。
BFFパブリックAPIの進化 - 出典: SoundCloud Developer Blog
すべての移行作業の範囲を理解するために、SoundCloudチームはどのエンドポイントがまだ使用されているかを理解するためのテレメトリを追加した。次に、Stranglerコードベースですべての既知のパブリックAPIルートを明示的に宣言した。宣言されていないルートについては、パブリックAPIを呼び出すためのフォールバックが追加された。さらに、SoundCloudチームがすべてのルートを特定したと確信すると、フォールバックは削除された。使用されておらず、開発者ポータルに文書化されていないルートはすべて削除される。最後に、移植する必要のあるすべてのエンドポイントがわかるため、パブリックAPIの代わりに既存のマイクロサービスを呼び出すために、それぞれのエンドポイントが移行される。
SoundCloudチームは、移植された実装をパブリックAPIにプロキシする古いコードと一緒にデプロイしている。これは、パブリックAPIに対する望まない大きな変更を減らし、回避するためである。入力されるリクエストに対して、古いコード(プロキシを使用)と新しいコードの両方のコードパスが実行される。プロキシからパブリックAPIへの呼び出しに対する応答は、呼び出し元に返される。同時に、プロキシと新しいコードの応答が一貫性の観点で比較される。古いコードと新しいコードの応答が一致しない場合、テレメトリイベントがトリガーされ、開発者による検査のためにその差がログに記録される。その後、開発者は、新しいコードが元の機能と合致していることを確信するまで、移植された実装に変更を加える必要があることがある。この時点で、プロキシを削除することができ、移植された方の応答が返される。
Stranglerは本格的なBFFになり、パブリックAPIのコードベース全体が削除された。その結果、SoundCloudには、ほとんどのエンジニアが貢献できるコードベースがある。それは、プロジェクトスコープに悪影響を与えず、マイクロサービスアーキテクチャに適合し、データの一貫性とセキュリティの確保に役立つ。
Stranglerパターンは重大なリスクが伴うものであった。SoundCloudチームは、メンテナンスとパブリックAPIの計画がほとんどなく、長い休止期間に苦しんでいた。そのため、コードベースが不健全になり、セキュリティリスクが高まり、機能開発が複雑になっていた。最終的に、Stranglerパターンを採用するかどうかを決定するときは、ビジネスに対するそのような混乱が、この取り組みの最終的な利点を上回るかどうかを検討すべきである。