BT

SoundCloudのマイクロサービスへの移行

| 作者: Jan Stenberg フォローする 34 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2014年7月10日. 推定読書時間: 2 分 |

原文(投稿日:2014/06/29)へのリンク

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の使い方を説明するつもりだ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT