成功から転落の危機に直面した Sleeve Music。経験豊かな開発者と適切なツールの選択で新たなアイデアを創出
このポストは、5 月 14 日に投稿された Success almost ruined Sleeve Music. But savvy developers with the right tools had another idea の翻訳です。
モバイル アプリの Sleeve Music は世界中で人気を博しています。その背景には、提供元の Orange Tribes 社の経験豊かな開発者のビジョンと能力、Microsoft Azure の活用がありました。スケールの拡張が必要となったときには Azure App Service を活用し、さらに大規模なスケールを低コストで実現する必要に迫られたときには、キャッシュ機構をベースとするアーキテクチャの構想をマイクロソフトが提案しました。Azure App Service への移行も迅速で、実装作業に要した期間はわずか 1 日でした。
Orange Tribes の創設者であり CEO を務める Maarten-Jan Vermeulen 氏は、バリのビーチでの休暇を楽しんだ後に Sleeve Music のアイデアを思い付きました。しかし、開発作業はビーチで 1 日を過ごすようにのんびりとはいきません。彼が実現しようとしたソリューション、開発過程で直面した問題、そしてそれらをどのように克服したのかについてお話をうかがいました。
実現しようとしたソリューションについて教えてください。
Vermeulen 氏: 当社では、音楽を愛する皆様がどこにいるときでも 1 つの場所から自分の好きなアーティストの情報を入手したり、最新の話題をチェックしたり、新しい楽曲を見つけたりできるようにすることを目標としていました。これは、以前にはできないことでした。私たちには、音楽ファンの方が日々音楽を楽しむときにインターネットを探し回る必要がないようにしたいという思いがあり、これを実際に実現しました。情報を収集し整理する当社のキュレーション担当者は、音楽ファンのさまざまな気分に合った新しく魅力的な音楽を常に探し求めています。このアプリは、音楽ファンの方々にとって必須のものです。
開発者の視点から見て、このソリューションを実現するうえでどのような課題がありましたか。
Vermeulen 氏: まず、Facebook、Twitter、Instagram、Last.fm、SoundCloud、YouTube、Spotify などのさまざまなサイトで 12 万組ものアーティストに関する大量の最新情報を毎時間クロールする必要があるという課題に直面しました。また、各アーティストの最新情報を Windows Phone、iOS、Android で可能な限り早く表示する必要がありました。
Sleeve Music の概念実証バージョンでは、アプリが Windows Phone からすべてのソーシャル メディア プロバイダーを呼び出してアーティストの最新情報を取得するつもりでした。しかし、サードパーティの API では呼び出し許可回数の制限があるため、この手法では拡張性が確保できないことが判明しました。また、応答性を向上させるために、帯域幅の使用量とアプリのレイテンシを低減させる必要がありました。
Azure App Service を選択した理由について教えてください。
Vermeulen 氏: コスト効率が高くスケーラブルなクラウド プラットフォームに移行する必要があったのです。この移行は 2 段階で行い、まずクロール処理を Windows Phone からクラウドで実行されるバックエンドに移行し、次にユーザー ベースを iOS と Android に拡張しました。Azure App Service では、それぞれの移行作業を迅速に行うことができました。サードパーティのソーシャル ネットワーク プロバイダーにアクセスするなどのすべてのロジックは C# で記述されており、Azure のモバイル アプリ バックエンドにシームレスに適合させることができました。また、このモバイル アプリ バックエンドには、そのままの状態で使用可能な、Windows Phone、iOS、Android に対応したクロス プラットフォームのクライアントが用意されていました。Azure App Service は、まさに当社が探し求めていたものだったのです。
これまで App Service を利用してみてどうですか。
Vermeulen 氏: Azure に移行してから、当社では 10 万組のアーティストと 30 万のフィードをモニタリングしており、1,000 万件の更新情報を Azure SQL Database に取り込みました。また、Table Storage や Azure Redis Cache などのキャッシュ機構を使用し、50 万のユーザーからの 1 時間あたり最大 2 万件の呼び出しに対応しています。
モニタリング ツールを使用することでこのような課題をすばやく解決でき、また App Service をモジュール形式でセットアップすることによって、短期間で反復的にサービスを拡張できるということが明らかになりました。たとえば、Spotify をクローラーに追加する作業はわずか数日間で完了しました。App Service を利用するようになってから非常にスムーズに進んでいます。
App Service を採用しなかったら、この課題をどのようにして解決していたと思いますか。
Vermeulen 氏: おそらく、Azure または他社のサービスのいずれかを使用して、クローラー、キャッシュ、API サービスを仮想マシンでホストしていたと思います。しかし App Service を採用したからこそ、セットアップや移行、モニタリング、メンテナンス、拡張、スケーリングで必要となるリソースを削減することができました。
開発工程の中で驚くようなことはありましたか。
Vermeulen 氏: はい、非常に重大なことがありました。このアプリでは、当初 Azure の Worker ロールを使用して外部ソースのフィードや更新のスキャンと受信を行い、そのデータを Microsoft Azure SQL Database に保存していました。Azure Mobile Services では、アプリからのクエリを受け取ったらそれをデータベースに送り、必要な情報をユーザーのスマートフォンに渡していました。
すると、ユーザーが朝起きてから更新情報を見るためにアプリにログオンする時間帯に、最大で 1 時間あたり 20,000 回の API 要求が発生するという負荷がかかることがわかりました。これほどの負荷は予想しておらず、パフォーマンス レベルが低下するおそれがありました。ユーザーが一気に離れてしまうかもしれないほど重大な事態だったのです。そこへ、負荷をモニタリングしていた Azure カスタマー アドバイザリー チームから連絡があり、トラブルシューティングに関する提案を受けました。チームからは、最も頻繁にアクセスする情報を Azure Redis Cache に保存し、比較的アクセスの少ないデータを Table Storage に格納し、管理用データを Azure SQL Database で保存することで、比較的コストのかかる Azure SQL Database に対する影響を最小限に抑えることも提案してくれました。そして、この解決策が功を奏しました。
実際に App Service を利用した経験を踏まえて、他のユーザーの方にアドバイスをお願いします。
Vermeulen 氏: App Service では簡単にスケーリングが可能ですが、Azure をモバイルに実装するメリットはこの拡張性だけではありません。Table Storage や Redis などのキャッシュ機構を活用すると、SQL Database で見込まれる負荷を軽減することができます。また、使用可能なツールでソリューションをスケーリングできるかどうか、必ずテストで確認されることをおすすめします。
このソリューションによって、御社には最終的にどのような影響があったと思いますか。
Vermeulen 氏: 当初はわずかなリソースでサービスを開始しましたが、今では Sleeve Music をここまで大きく成長させることができました。その大きな支えとなったのが Azure App Service です。
Azure App Service のサンドボックス (英語) では、1 時間足らずの操作で App Service のサービスを体験することができます。Azure サブスクリプションやその他の契約は不要で、無料でご利用いただけます。ぜひお試しください。また、Azure App Service のすべての機能をお試しいただくには、Azure の無料評価版をご利用ください。