自分のAPIを使うことが課題になることがある。GOTO Berlinカンファレンスで、Soundcloudのエンジニアリングディレクター、Phil Calcado氏が巨大なRailsアプリケーションを管理、再構築した経験について語った。
Soundcloudは急速に成長しているが、彼は1年ほど前にリリースした新しいWebサイトの作成で経験した問題について語った。
SoundcloudはRuby on Railsアプリケーションとしてスタートしたが、6年間拡張を繰り返して、雑然とした状態になっていた。問題の大部分はそのインフラストラクチャ、MySQLとMemcachedを使った巨大なRailsモノリスにあった。
2010年、彼らは新しいプラットフォームの検討を開始した。そう考えるに至った一端は、Twitterによるアーキテクチャの再設計にあった。Soundcloudチームは、Twitterと同じように、公開APIを使ってバックエンドとおしゃべりする単一ページのJavaScriptアプリケーションを構築すればよいと考えた。最終的に、彼らは新しいWebサイトを構築することにした。バックエンドの経験は不足しているが熟練したフロントエンドJavaScript開発者たちを多数投じ、6、7ヶ月かけて、公開APIの上に新しいWebサイトを構築した。
彼らは非常に安定したアプリケーションを作ったが、リリース直前になって、Twitterと話す機会があった。彼らは新しいTwitterアーキテクチャとまったく同じ考えで、自分たちの新しいWebサイトをリリースしようとしていることを話した。ところが、Twitterの人は、新しい設計はそれほど良いアイデアではなかったことに気付いた、と答えた。実際、Twitterは後になって、大部分をサーバサイドレンダリングに戻すことに決めた。
このことでチームは興味深い状況に陥った。これは重要なインテグレーションだった。そのままリリースすべきだろうか、それともキャンセルすべきだろうか。Railsをよくわかっていたので、Railsが最初にダウンするだろうと考えて、多数のノードをセットアップした。ところが、新しい設計では1ページにつき3リクエストから100リクエスト以上必要になり、最初にダウンしたのは高可用性プロキシだった。それを修正すると、今度はmemcachedがダウンし、最終的にRailsとMySQLがダウンした。彼らはようやく基本的なアーキテクチャ問題があることに気付いた。
早い段階で気付いたのは、アプリケーション全体を書き直せないことだった。Railsを使い続けるなら、高速なAPI、できるだけ高速に多数のリクエストを処理できるAPIが必要だった。彼らは巨大なRailsアプリケーションを小さなパーツに分割し、サービスという考えを取り入れた。驚いたことに、全体のパフォーマンスは変わらなかったが、パフォーマンスのボトルネックはデータベースからHTTPへと移った。結論としては、彼らは高速なRailsを必要としたということだ。
コードを調べると、並行処理の余地がたくさんあることがわかった。Railsは並列性や並行性には適しておらず、彼らはFinagleのようなツールを使って非同期化することで、何とか並列性と並行性を得ようとした。おかげで、負荷は大幅に軽減され、非常に高速に結果を返せるようになった。
リクエストを高速にさばけるようになると、彼らはネットワークについて調べた。依然として各ページのレンダリングには大量のリクエストを必要としたので、リクエスト数を減らす方法を模索した。その結果、1リクエストで数ページ分のデータを返すカスタムAPIを用意することにした。最終的に、彼らはモバイル向け、デスクトップ向け、パートナー向けの3つの専用APIを用意した。
現在抱えている最も興味深い設計課題は、いかにしてAPIをモデル化するかだ。今のところ、開発者はきめ細かなモバイル向けAPIと、経験に基づいたデスクトップ向けAPIを好んでいる。そのため、今のところ2つの異なるバックエンドを使っている。
The GOTO Berlin Conference 2013はベルリンで初めて開催されるGOTOカンファレンスであり、420名の出席者と80名の講演者が参加する。