ニュース
» 2015年06月04日 10時00分 UPDATE

Computer Weekly:タクシー配車サービスHailoがアプリ開発で犯した失敗

2タップでタクシーを呼び出せると話題の配車サービスHailo。英国だけでなく日本でもサービスを展開している同社は、アプリ開発に際して大きなミスを犯していた。同社がマイクロサービスを採用するに至った理由とは何か?

[Cliff Saran,Computer Weekly]
Computer Weekly

 英Hailoでプラットフォームオートメーション部門を率いるボヤン・ディミトロフ氏は、ソフトウェア開発のニーズは、近代社会の需要に後れを取らないように変化していくものと考えている。

Computer Weekly日本語版 6月3日号無料ダウンロード

16876.gif

本記事は、プレミアムコンテンツ「Computer Weekly日本語版 6月3日号」(PDF)掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

なお、同コンテンツのEPUB版およびKindle(MOBI)版も提供しています。


 ディミトロフ氏はロンドンで行われたAmazon Web Services(AWS) Summitで、Hailoのタクシー配車アプリがAWSをどのように使用しているかについてのプレゼンテーションを終えた後、Computer Weeklyのインタビューに応じてこのように語った。

 Hailoにとって重要な点は、このバックエンドアプリケーションが従来のエンタープライズソフトウェアとは根本的に異なる方法で開発されていることだ。

 ソフトウェアを開発する際、マイクロサービスとDevOpsアプローチとを組み合わせることによって、Hailoサービスに絶えず新機能をリリースできるようになる。多くのタクシーアプリが競合する現状では、この姿勢が重要性を増すという。

 このアプローチは、数年前は全く耳にしなかった。米Googleや米Facebookは別にして、競合他社に一歩先んじ、ソフトウェアに機能やサービスを絶えず追加するためのリソースを確保している企業はほとんどなかった。CEOがこのイノベーションを強く望んだとしても、そのために必要な容赦のないペースに付いて行けるIT部門はほんの一握りにすぎない。

 かつて、銀行のバックエンドシステムなどの従来型企業アプリケーションは、巨大なモノリシックソフトウェアとして開発されていた。このようなアプローチは大企業には適していたかもしれないが、ディミトロフ氏によれば、これには常に特有の問題があったという。

 「銀行アプリケーションのロジックはかなり明快だ。だが、企業アプリケーションの課題は、アプリケーションの規模が非常に大きく、週単位のリリースサイクルでチームが分担して作業を行う必要があることだ」と同氏は話す。

 ディミトロフ氏によれば、ソフトウェアは数カ月置きにしかリリースできないため、巨大なモノリシックアプリケーションではビジネスに深刻な支障を来たす。「銀行業務にはあまりないことだが、新規事業では可能な限り迅速に機能を追加することが求められる」と同氏は語る。

 2011年にHailoのタクシーアプリビジネスが始まったとき、同社は従来通りのソフトウェア開発チームを編成した。だが、ディミトロフ氏によればこれが同社のビジネスを妨げたという。「開発速度が上がらなかった。チームの誰もが同じコードベースで作業するため、新機能の追加が困難だった」と同氏は話す。

 そこでHailoでは、巨大なモノリシックアプリケーションのプログラミングを行うのではなく、ソフトウェアを細かいチャンク(塊)に分割した。業界ではこれを「マイクロサービス」と呼ぶようになった。分割後の各チャンクに、それぞれソフトウェアエンジニアと品質保証テスト担当者を含めたチームが割り当てられた。

 「顧客登録サービスや、タクシーの到着時間を顧客に伝えるサービスなど、個別のコンポーネントに人員を割り振った」とディミトロフ氏は話す。

マイクロサービスへの取り組み

 ディミトロフ氏によれば、Hailoを構成するコンポーネントは、コーディング作業という点では比較的単純なものだという。これらの小さいコンポーネントを個別にスケーリングし、コンポーネント独自のソフトウェア開発ライフサイクルを割り当てる」と同氏は話す。つまり、1日数回でも、数週間に1回でも、各コンポーネントが独自のペースで製品にリリースされる。

 Hailoがソフトウェア開発に取り入れたアプローチの本質は、それぞれのソフトウェアチームが、開発、リリース、更新、最終的には廃棄に至るまで、コンポーネントのライフサイクル全てを担当していることだ。

 「コンポーネントとは、チームが所有権を持つ小さなビルディングブロックだ。問題があれば、そのチームが解決することになる」とディミトロフ氏は話す。

 従来型のモノリシックアプリケーションでは、問題となっている個々のコードを特定するのが難しかった。だが、このアプローチによって品質の管理が圧倒的に楽になったという。

開発から運用へ

 Hailoのアーキテクチャダイアグラムには、複雑に相互接続される大量のコンポーネントがある。ディミトロフ氏は、このような複雑さの塊は自動化しなければ管理が追い付かないと話す。

 「当社の開発者が自身の担当するコンポーネントを準備する。このコンポーネントの実行に必要なサービスの配置やトラフィックのルーティングはシステムが行い、さらに開発者が新しいサービスにルーティングされるトラフィックの量を制御できるように開発者にフィードバックを提供するのもシステムの役割だ」と同氏は言う。その結果、ビルドした要素が全て機能するかどうか、開発チームが確認できるようになる。

 「当社では、開発したサービスをできるだけ早く運用することが重要なので、テスト、Hailoアプリケーションの起動、構成要素となる全コンポーネントの統合テストを自動化している」と同氏は話す。

 従来型のソフトウェア開発チームがDevOpsで直面する課題の1つは、継続的な開発とリリースに、テストと品質管理をどのように組み込むかということだ。

 Hailoは、南太平洋のある島を想定してロボット顧客を生成するシステムを使用している。「普通なら、走り回るタクシーとそれを呼び止めようとする人々がいる」と同氏は話す。「システムが機能し、人々がタクシーに乗車できれば、システムのコンポーネントが機能していることが分かる」。だが、タクシーを拾えない人がいるなど、システムが機能しないことがあれば、シミュレーションにより問題が起きていることが示される。

 ディミトロフ氏は、Hailoは今後、開発者がステージング段階を踏まないまま、開発中のコンポーネントをそのまま製品に送り込めるシステムも作成する予定だと話す。「運用環境に直接展開し、運用システム上で直接テストできるようにする」と同氏は言う。

 実際に、新しいソフトウェアコンポーネントと既存のコンポーネントがサイドバイサイドで動作し、開発者は新しいサービスのパフォーマンスを比較できる。「当社の顧客は、このテストを全く意識する必要はない。製品が機能するかどうかを検証し、機能しなければシステムがこれを動作させない」とディミトロフ氏は話す。

マイクロサービスのテスト

 Hailoでは、比較用に顧客の20%をリダイレクトすることで、1つのマイクロサービスの新機能を比較的簡単にテストできる。だが、時には一度に5つ以上のマイクロサービスに変更を加える必要がある。この場合、問題が発生するとどのマイクロサービスが失敗しているかをテストするのは途方もなく困難になると、ディミトリフ氏は話す。

 マイクロサービスアーキテクチャで深刻な課題の1つは、サービスの一部が外部から提供されているため、Hailoが直接制御できない点にある。では、同社がエンドツーエンドに制御できないとすると、どのようにサービスの品質を維持するのだろう。

 「アプリケーションのサービスはそれぞれ切り離され、特に重要なサービスを特定でき、優先順位を付けることができる」と同氏は話す。

 「外部サービスは無条件に当社のアップタイムに貢献する。当社は製品に冗長性を組み込み、障害に耐え得るシステムにしているため、コンポーネントの1つがダウンしても、機能が止まることはない。ソフトウェアスタックの全てにフォールバックメカニズムがある」と同氏は話す。

 万一バックエンドのHailoシステムに問題がある場合は、スマートフォンのクライアントアプリにさえ、優れたカスタマーエクスペリエンスを確保するための調整システムが組み込まれている。

 HailoのタクシーアプリはAWSバックエンドを使用する。同社のソフトウェア開発に対するアプローチは、バックエンドコンポーネントを個別にアップデートできるようにしている。各コンポーネントを個別にスケーリングでき、Hailoサービスを構成する高度な分散型システムの一部として機能する。

 ディミトロフ氏は、ソフトウェア開発の未来について次のように語る。

 「今の世の中は迅速な実行力が求められている。コンポーネントを切り離すことは、十分な速さでソフトウェアをリリースできない負荷の高い運営プロセスを克服する唯一の方法だ」

Computer Weekly日本語版 F1特集号(転載・再配布フリー)も公開中!

0514_120.jpg

あまり報じられることのない、F1の世界で活用されているIT事情を事例やインタビューを通して紹介。ロータス、マクラーレン、メルセデス、ケータハムのクラウド、ビッグデータ、ファイル共有戦略とは?

※本PDFは、TechTargetジャパン会員でなくても無料でダウンロードできます。


Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -