Deliverooのモノリスから分散システムへの移行について

Deliverooはこの数年間、ビジネスおよびITの両面で飛躍的な成長を遂げたことにより、大規模なモノリシックアプリケーションに関わるさまざまな技術的課題に直面している。解決策は分散化だが、しかしマイクロサービスではない。先日のQCon LondonカンファレンスのプレゼンテーションでGreg Beech氏は、同社のモノリスシステムから分散システムへの移行について説明した。

Beech氏は2013年に創立されたDeleverooのリードエンジニアである。同社は当初、PostgreSQLとRedisをデータストレージに使用した、典型的なRuby on Railsモノリスとしてスタートし、データベースの拡張によって拡大するビジネスに対処していた。1年前にはHeroku上で約20台のサーバを運用していた同社では、現在は数百台のサーバが稼働している。これはHeroku上にデプロイされるアプリケーションとしては最大のもので、ピーク時には1,800コアと3TBのメモリを使用する。技術者の数も2015年の10名から、2017年には約100名に増加し、600,000ラインの有効コードからなる主要コードベースで作業を行なっている。

モノリスの採用は意図的なものだった。それにより、市場のニーズに適応するための機能追加が迅速に可能になった反面、現在では問題に直面し始めている。モノリスが現在のサイズになったことで、同社はパフォーマンスの低下やビルド時間の増加に苦慮している。２年前には７分であったビルド時間は、現在は２時間以上となり、開発速度低下の原因となっている。モノリスの大規模化は信頼性の低下も引き起こしている。ひとつの問題がすべてをダウンさせる可能性があるからだ。

解決策は分散化だ。同社はこれを、ドメインサービス、エッジサービス、UI用クライアントアプリという３クラスの12 Factorアプリケーションにモノリスを分割し、これらをイベントバスでサポートすることによって実現した。

ドメインサービス:

• ドメインの重要な部分を所有する。ドメインサービスがドメインの重要な部分を所有することにより、凝縮性(cohesively)を実現する役割を果たす。Beech氏がマイクロサービスという呼び方を好まないのは、この理由による。
• 内部の実際のREST APIをハイパーメディアで公開する。
• イベントバスとの送受信を行なう。
• 他のドメインサービスのAPIを使用可能。

エッジサービス:

• ドメインを所有しない。
• 集約されたAPIを外部に対して公開する。
• イベントバスからの受信を行なう。
• 他のエッジサービスおよびドメインサービスのAPIを使用可能。

共有データストアは存在せず、各アプリケーションが例外なく、他のアプリケーションからアクセス不可能な独自のデータストアを所持する。代わりにすべてのデータがREST APIとしてハイパーメディアで公開されている。これが真のRESTだ、とBeech氏は述べている。組込みオブジェクトではなく、エンティティへのリンクのセットとして返されるコレクションはその一例だ。RPCが許可されていないことも特記すべき点である。

エンティティが生成、更新、あるいは削除されると、ドメインサービスがイベントバス経由でイベントを送信する。このテクニックを同社ではRESN(Representational State Notification)と呼んでいる。イベントにはペイロードがなく、関連するエンティティへのリンクのみが含まれる。このようにした理由のひとつは、バスが重要データ損失の原因となることを防ぐためだ。ただし例外として、重要でない不変値オブジェクトはメッセージ内で送信される場合もある。

サービスの構築と階層化、および相互通信の方法については、極めて堅牢なガイドラインを設けているが、必要ならば単純な構成から開始して、より複雑なアーキテクチャに発展させることも可能だ、とBeech氏は述べている。このようにした理由は、自分たち自身の問題と目標から着手して、必要に応じてアーキテクチャを発展させることによって、分散アーキテクチャの経験の浅いチームでも成功できるようにすることにある。