SoundCloudがマイクロサービス型の設計に移行したのは、チームが新しい機能を素早く実装できるようになるために致命的に重要だった。Phil Calçado氏は3連続のブログ記事でそう書いている。この記事では彼らのモノリステックなシステムからの移行についての経験が書かれている。
SoundCloudはオンラインの音楽配信プラットフォームであり、Phil氏はエンジニアリング部門のディレクターを務めている。このサービスは単一のRuby on Railsアプリケーションであったが、拡張性の問題を解決しないまま、パッチを当て続けた結果、彼らは、サービス構築の方法を根本から変えるという決断をした。まず、設計の変更から行った。マイクロサービス型の設計に移行することに決めたのだ。大規模なリファクタリングで痛い目を見ていたので、彼らは古いシステムに新しいものを追加せずに、新しい機能をマイクロサービスとして、実装した。
すぐに見つかった問題は、古いシステムに大量のロジックが残っているので、新しいサービスのほとんどはその古いシステムと通信をしなければならなかったことだ。パブリックAPIと内部の新しいAPIを利用することでこの問題を解決した。内部のAPIは新しいマイクロサービスが古いシステムと密結合にならないようにするのにも役に立った。
設計上の変更がなされた後、次の挑戦は古いシステムから機能を抽出することだった。ドメイン駆動設計(DDD)の概念である境界付きコンテキストを使って、機能セットを定義し、大規模なリファクタリングを避けるため、新しいマイクロサービスは完全にロジックの移行が終わるまで、古いシステムを使い続ける必要があった。移行の間、新しいサービスは古いデータベースにアクセスしていた。つまりサービスが完全な機能を持つまで読み取りパスだけを実装できたということだ。これらの原則を適用ことで、チームは古いシステムから既存の機能を抽出し新しいマイクロサービスに移植できた。
彼ら自身の好みにしたがって、JVMプラットフォームを使い続け、異なる言語も利用可能にした。RPC、弾力性、並列性の要件に見合うフレームワークを探した結果、Finagleを使うことになった。Finagleはプロトコルに依存しないRPCシステムだ。
新しいマイクロサービスの設計は短いフィードバックサイクルで運用に耐えうる機能を開発するために極めて重要な役割を担った、とPhil氏は自身の経験を踏まえて言う。
Phil氏は、このブログ記事シリーズで単一のRESTfulなAPIから最適化されたバックエンドへ移行するためのScalaとFinagleの使い方を説明するつもりだ。