ユーザー事例


 カーエレクトロニクス事業の大手であるパイオニアは、カーナビゲーション車載機で操作したルート探索をクラウド上で実行するサービス「スーパールート探索」の提供を、他社にさきがけて2017年1月下旬に開始。実行環境としてRed Hat OpenShift Container Platform(以下OpenShift)を採用し、ルート探索をコンテナで実行する。OpenShift採用の背景とメリット、その導入過程について話を聞いた。

宮本 一宏 氏

パイオニア株式会社 商品統括部
情報サービスプラットフォームセンター
開発部 部長
宮本 一宏

谷川 裕史 氏

パイオニア株式会社 商品統括部
情報サービスプラットフォームセンター
開発部 開発1課 課長
谷川 裕史

菱木 竜也 氏

日本情報通信株式会社
ソリューションビジネス本部
クラウド・テクニカルセールス部
担当課長
菱木 竜也

常田 秀明 氏

日本情報通信株式会社
ソリューションビジネス本部
クラウド・テクニカルセールス部
先進テクノロジーグループ
常田 秀明

 

背景

カーナビのルート探索をクラウド上で実行

 パイオニアでは2017年1月下旬、カーナビ車載機「サイバーナビ」の最新機種を対象に、ルート探索をクラウド上で実行する「スーパールート探索」のサービスを開始した。これまで車載機上で処理していたルート探索を、車載機からインターネット経由でクラウドサービスにアクセスして実行するもので、初の試みとなる。サイバーナビの最新機種であればソフトウェアアップデートで利用が可能だ。
 このサービスにより、より複雑なルート計算や最新の状況に応じた最適なルート探索ができるようになる。たとえば、時間優先や料金優先など、条件に応じたさまざまなルートを提案したり、有料道路で、利用時間帯や時期に応じた料金割引を考慮したり、さらにはETC 2.0の割引への対応など、サーバー側でパラメータを変えるだけで対応できる。
 このクラウド化には、同社の情報サービスプラットフォームセンターの開発部が取り組んだ。パイオニア株式会社 商品統括部 情報サービスプラットフォームセンター 開発部 開発1課 課長の谷川裕史氏は、「現在のカーナビでは、渋滞の計算など計算処理がどんどん大きくなり、車載器での処理の限界に達しています。今後、さらに処理が増えると、通信時間をかけたとしてもサーバーで処理したほうが断然速くなります」とクラウド化の意義を説明した。

課題

環境依存の大きいプログラムをサービス化

 サーバー版のルート検索は、車載機で動いていたプログラムをベースに開発した。もともと組み込みシステムで動いていたため、C言語による膨大なソースコードからなり、ライブラリなどの動作環境に依存する部分が大きい。そのため、サービスとしてスケールアウトする場合や、開発のために複数の動作環境を用意する場合、あるいは検証環境や本番環境を用意する場合など、動作環境を再現するのが難しく、うまく動かないケースに遭遇する可能性が高い。
 パイオニアでは、この課題を克服するために、コンテナ技術のDockerを選んだ。コンテナは、1つのLinuxインスタンスの中で複数の隔離した動作環境を作る技術であり、特定のアプリケーションとその必要な環境を隔離したパッケージにして動作させるといった用途に使われている。

システム要件

問合せからわずか1カ月で構成を決定
4カ月後にサービスイン

 情報サービスプラットフォームセンターは、カーナビの情報サービス部門として発足した部署だ。それまで部門ごとで各地に散らばっていたカーナビの情報サービスやWebサーバー、顧客情報などのサーバーを1カ所に集約し、以後、カーナビ関連のサーバーやサービスを一括で担当している。
 1990年代末に始まったカーナビ向けの通信サービスは、当初は天気予報などの情報を配信するものだった。大きな転換点となったのが、2007年に開始した双方向通信によるスマートループだ。スマートループでは、たとえばカーナビから走行履歴を集めて渋滞情報を作成し、カーナビに送信するといったことができる。2013年には、スマートループアイにより前方風景の写真を収集し閲覧する等の機能も加わった。
 スーパールート探索も、こうしたカーナビの双方向通信化の流れにある。同社 商品統括部 情報サービスプラットフォームセンター 開発部 部長の宮本一宏氏は「われわれの部門のサーバーを使ったサービスが、かなり増えてきています。ちょうどデータセンター統合の作業が一段落ついて開発に専念できるようになったタイミングで、新しいサービスに着手しました」と語る。
 スーパールート探索は、2015年春に構想がスタート。試作を繰り返して、同年夏には形が見えてきた。サーバーを使ったサービスが成り立つかどうかを検証しながら、2015年末には具体化し、2016年初頭に企画が提出された。
 実作業では、パイオニアはアプリケーション開発に専念し、プラットフォームの構築と運用はNI+Cが担当した。
 パイオニアで先行して開発が進められ、そろそろインフラ設計の必要があるという段階(2016年8月上旬)でNI+Cに相談。8月下旬には、NI+Cとレッドハットが同社を訪問した。9月初旬には、構成や構築の範囲、スケジュールを決定するという、未だかつてないスピード展開で構築が進み、2017年1月下旬にサービスインを迎えた。
システムイメージ図

OpenShiftを選んだ決め手

プラットフォームとしての完成度と信頼できるサポートで選択

 コンテナ技術に着目し、情報収集をしていたパイオニアは、スーパールート探索の開発でもコンテナを利用する想定で開発を進めていた。NI+C ソリューションビジネス本部 クラウド・テクニカルセールス部 先進テクノロジーグループ クラウドエバンジェリストの常田秀明氏を招いて、コンテナに関する社内勉強会を開催するなど、社内でコンテナ技術の浸透を進めた。
 言うまでもなく、コンテナ技術を利用してアプリケーションが動くだけではなく、運用も重要だ。そこでコンテナプラットフォームとして、レッドハットのOpenShiftを採用した。さらに、サーバーインフラとしては、IBMのIaaSであるIBM Bluemix Infrastructure(旧IBM SoftLayer、以下Bluemix IaaS)のベアメタル(物理)サーバーを採用し、その上でOpenShiftを動作させた。
 検討段階では、OpenShiftのほかにも、Docker純正の管理ツールや、OpenShiftの重要なコンポーネントとなっているKubernetesをベースに構築することも考えた。しかし、当時のDocker純正製品は有用な機能が少なく、またKubernetesは独自でプラットフォームを作り込む必要があるため、必要な機能の揃ったOpenShiftの採用を決定。カーナビという24時間365日の動作を求められるサービスであることから、レッドハットの実績あるサポートも決め手となった。

OpenShiftを導入したメリット1

クラウドプラットフォームの機能に縛られないサービスが可能

 他のコンテナプラットフォームと比較してOpenShiftを選んだ主なポイントを2点、NI+Cのソリューションビジネス本部 クラウド・テクニカルセールス部担当課長の菱木竜也氏は以下のように説明する。
 1つは、OpenShiftの方が、他に比べて自由度があるという点だ。検討時にはクラウド事業者のコンテナプラットフォームも比較したが、クラウドサービスでは機能を最大限に活用するとクラウドロックインされてしまう傾向がある点が課題となった。「たとえば、サービスを動かすうえでログの機能がどこまであるか、またアプリケーションを動かす際のサービスの正常性をどう担保するかなど、OpenShiftのほうが勝っていると判断しました」(菱木氏)。

OpenShiftを導入したメリット2

好都合なBluemix IaaSのベアメタルサーバーとの組み合わせ

 もう1つは、OpenShiftを動かすインフラとしての、Bluemix IaaSのベアメタルサーバーとの組み合わせだ。もともと大きなリソースが必要なサービスであることから、オンプレミスではなくクラウドを使うことを前提としていた。ただしコンテナを使うので、サーバーインスタンスごとの柔軟性はさほど求められない。
 そのなかで、パフォーマンスとコストの兼ね合いから、Bluemix IaaSのベアメタルサーバーとOpenShiftの組み合せを選択。ルート探索の性質上、CPUパワーは必要だがメモリはそれほど必要ではないというアンバランスな構成のため、他のIaaSでは相応しいサービスメニューを持ち合わせていなかった。それに対して、Bluemix IaaSのベアメタルサーバーでは、CPUとメモリの組み合わせの柔軟な選択が可能だった。使用開始時のノードサーバーは最少台数に抑え、将来的には柔軟に拡張できる構成とし、さらにOpenShiftのソケット課金を選ぶことで、サブスクリプションコストも節減できた。

OpenShiftを導入したメリット3

将来ユーザー数や機種が増えたときも対応がしやすい

 スーパールート探索は当面、サイバーナビの最新機種が対象となり、台数としては数千台の規模を想定している。これまでも、サイバーナビの新機種は10万台程出荷され、そのうち通信サービスに登録される数は半数弱だという。
 ただし、新発売の機種のサービスであれば売上に準じて利用が伸びていくが、スーパールート探索の場合は、発売済である最新モデルのソフトウェアをアップデートして対応するため、当初から数千台〜数万台のアクセスが集中する可能性があることに留意した。
 スーパールート探索は将来、他機種へも展開していく予定だ。1機種であればある程度ユーザー数を想定できるが、機種が増えると予測が難しくなる。また、カーナビのソフトやデータをサービス化する形のため、機種が増えればコンテナの数も増える。
 「ユーザー数とコンテナの数が増えていくことを想定したとき、OpenShiftであれば構築が楽になります」と谷川氏。コンテナの割り当てやスケジューリングをスケーラブルかつ容易に管理できることで、OpenShiftが威力を発揮するだろう。

今後の展望/レッドハットへの期待

安定した品質とサポートに期待

 構築は実に早いスケジュールで進んだ。「やることは決まっていたので、スピード感をもって取り組みました。サポートについてもまったく問題ありませんでした」と谷川氏は言う。
 サポート面については、菱木氏も次のように語る。「レッドハットのOpenShiftであれば、サポートや品質に安心感が持てる点は大きな選定理由のひとつでした。レッドハットには実際にエンジニアとして入ってもらい、全面的な支援を受けました。レッドハットを選んでよかったと思います」。
 スーパールート探索はまだ始まったばかりで、今後も発展していく。「より良いものに進化させていきたいですね。また、スーパールート探索以外もコンテナ化ができないかを検討しています」(谷川氏)。「可能性としては、スマートフォン向けなど他のWebサービスへの展開も考えられます。他社のカーナビで採用してもらうという可能性も、ありえなくはないと思っています」(宮本氏)。
 今後、開発から運用フェーズへと進むにあたっては、安定した運用が鍵となる。「そのためにも、レッドハットには引き続きのサポートをお願いしたい」と谷川氏は期待する。また常田氏も「ディストリビューターとして、これからも安定したコンテナプラットフォームの提供を期待しています。まだまだ機能を使いきっていないので、最新技術や最新情報もぜひ積極的に共有してほしいと思います」と語った。
 コンテナという新しい技術で信頼できるサービスを動かすためにも、レッドハットの製品とサポートへの期待は大きい。


関連リンク

パイオニア株式会社
日本情報通信株式会社
Red Hat OpenShift
Red Hat OpenShift Container Platform(英語)