PaaS（プラットフォーム・アズ・ア・サービス）を制するもの、デジタルを制す。デジタルビジネスの成功は、新たにサービスを作った後、改善を繰り返した先にある。この作業を支えるのが継続開発（CI）、継続デリバリー（CD）を可能にするPaaSだ。自動化やコンテナ、マネージドサービス、マイクロサービスといった最新技術の粋を集めたPaaSが今、主役に躍り出る。デジタルビジネスを生み出すPaaSの最前線に迫った。
デジタルビジネスを支えるIT基盤として、PaaS（プラットフォーム・アズ・ア・サービス）が注目を集めている。キーワードは「継続（Continuous）」だ。
システム開発は通常、要件定義からプログラムコード開発、テストを経てリリースすれば終わり。だがデジタルビジネスを担うサービスでは、利用者のフィードバックを得て迅速な改善を継続する必要がある。
継続開発（CI：Continuous Integration）と、リリースを頻繁に繰り返す継続デリバリー（CD：Continuous Delivery）を支援するPaaSを利用すれば、サービスの「高速改善」を実行できる。
パイオニアはこの点に着目してPaaSを採用した1社だ。「従来の手法で取り組んでいたら、リリース期限に間に合わなかっただろう」。商品統括部 情報サービスプラットフォームセンター 開発部 開発1課長の谷川裕史氏はこう漏らす。
谷川氏は、2017年1月に提供開始したカーナビゲーションサービス「スーパールート探索」の開発プロジェクトで中心的な役割を果たした。スーパールート探索は、次代を担う戦略サービス。同社の看板商品「サイバーナビ」のコア機能をサーバーアプリに移植し、クラウドから提供する。
開発期間はおよそ6カ月。「ルート探索のロジックを変更しながら、交通情報や地図、天気などの情報を組み合わせてテストを繰り返す。開発からリリースまでの高速化が不可欠だった」（谷川氏）。
同社はツールやサービスを組み合わせてCIやCDを支援する独自のPaaSを実現し、短期開発を可能にした（図1）。
CI／CDで開発サイクルを高速に
PaaSの中身はこうだ。コードの作成からテストまでのプロセスは、CIツール「Jenkins」や自動テストツール「PHPUnit」で自動化を進め、継続開発ができる環境を整えた。
アプリのリリースを容易にするCDを担うのがコンテナだ。サーバー環境をコンテナ「Docker」でデプロイ（配備）し、環境の違いによる再テストの手間を省いた。
コンテナは仮想OS、ミドルウエア、アプリをひとまとめで扱うので、定義ファイルをコピーすればサーバー環境を構築できる。コンテナを作って稼働検証を終えたら、その定義をコピーして作ったコンテナでもアプリは動くことが保証される。「5分もあればコピーは終わる。環境が変わってもテストの手戻りはない」（谷川氏）。本番環境への移行もコンテナをコピーすれば済む。「スーパールート探索サービスの提供開始から1カ月で、新規に3回リリースした」（同）という。
パイオニアが高速開発に成功した理由はほかにもある。動的にリソースを調達できるクラウドの特徴を生かし、インフラの見積もりを後に回してコード開発に専念したのだ。
同社の開発、運用環境は米IBMのパブリッククラウドサービス「IBM Bluemix Infrastructure（旧SoftLayer）」上に、米レッドハットのコンテナ管理ツール「Red Hat OpenShift Container Platform」を導入し整備している。
谷川氏は「新サービスで負荷を予測しづらかったこともあり、アプリを作りながらチューニングする方針を取った」と説明する。開発中に、ある探索アプリが処理性能不足に陥ったが「OpenShiftの設定を変更して、コンテナに割り当てるCPUリソースを増やすことで乗り切った」（谷川氏）。
PaaS上でアジャイル開発
CI/CDを提供するPaaSが充実し、導入企業が増えるなか、どのような手法、サービスがあるのか要注目だ。
CI/CD環境を作る手法はいくつかある。パイオニアのように各種ツールをIaaS（インフラストラクチャー・アズ・ア・サービス）に展開する、というのが一つのやり方だ。この環境でアジャイル開発を進め、サービスの改善を繰り返す。
顧客向けに独自のPaaSを提供し、アジャイル開発を支援しているのが米Pivotal Labsだ。米ゼネラル・エレクトリック（GE）や独メルセデス・ベンツ、米ブルームバーグなど1000社以上のプロジェクトでアジャイル開発を伝授しており、日本拠点もある。
Pivotal Labsでは「Circle of Code」という考えに基づき、アジャイル/リーンの開発スタイルで短期リリースを繰り返す。PaaSを利用して、アイデア出しからコード開発、テスト、フィードバックに至るプロセスを高速で回せるようにしている（図2）。
顧客はPivotal Labsのエンジニアとのペアプログラミングなどを通じて、アジャイル開発の手法や考え方を習得できる。
PaaSとして提供するツールの中で、特にアプリのデプロイや実行制御を担う「Pivotal Cloud Foundry」が高速開発に寄与するとしている。Pivotalジャパン 技術統括部 シニアソリューションアーキテクトの市村友寛氏は「Cloud Foundryを使えば、仮想マシンやコンテナ、クラウドの違いを意識せずに、アプリをデプロイできるので、アプリ開発者はコード開発に専念できる」と理由を説明する。
ベンダーPaaSなら準備不要
米アマゾン・ウェブ・サービス（AWS）、IBM、米マイクロソフト、米オラクルといった大手クラウドベンダーのPaaSを利用する選択肢もある。各社はCI/CD環境を組み込んだ形で、ベンダー側が管理する「マネージドサービス」としてPaaSを提供する。これを使えば、ユーザー自身がソフトを導入する必要はなくなる。
IBMのPaaSである「IBM Bluemix」を例に取ると、自社製ツールやオープンソースソフトウエア（OSS）を組み合わせて、CI/CDに必要な機能を包括サービスとして提供する。
IBM Bluemixで提供するイベント駆動型のコード実行サービス「OpenWhisk」を使うと、コードさえ書けばサーバーやミドルウエアを用意しなくても実行できるサーバーレスの環境を実現できる。
日本IBM クラウド事業統括 コンサルティング・アーキテクトの平山毅氏は「センサーからデータが届くたびに、OpenWhiskでNoSQLやKVSなどシンプルなデータストアに書き込めば、IoT（インターネット・オブ・シングズ）アプリを作りやすくなる」と説明する。
マネージドサービスで高速開発
AWSがマネージドサービスとして提供するPaaSを利用して、高速開発を図ったのが朝日放送（ABC）だ。同社が制作する漫才コンテストのテレビ番組「M-1グランプリ」向けの「視聴者投票システム」を、AWSのPaaSを使って3カ月で稼働させた。
「5年ぶりに復活する番組の目玉企画として、視聴者投票による敗者復活戦が持ち上がった」。朝日放送 技術局 開発部の小南英司氏は、2015年に投票システムが急きょ必要になった経緯をこう振り返る。M-1グランプリに限らず「番組の企画が固まってから、Webでの付加サービスなどが決まるので、システムは後回しになりがち」（朝日放送 技術局 開発部の高木衛氏）だ。
当初はAWSの仮想マシン「EC2」を並べて負荷分散する構成を考えていたが、システム構成をAWSの担当者に相談したところ、ストリーミングデータの処理や分析を行うマネージドサービス「Amazon Kinesis Streams」の採用を勧められた（図3）。小南氏は「最初はKinesisを利用するメリットがよく分からなかった」と打ち明ける。
Kinesisはシャードと呼ぶデータの受け口を備え、1シャード当たり1000レコードを受け取れる。シャードの数を増やせばスループットが増えるので「Kinesisをキューとして使い、アクセス負荷を調整できる」（小南氏）。
投票サイトのキャパシティは負荷テストをしながら決めていった。ピークの負荷は秒間2万件、総得票数は20万件を想定。「Kinesisに蓄積したデータをNoSQLのDynamoDBに何件ずつ渡すかを、負荷をかけながら調整した」（小南氏）。放送前日まで負荷テストを続け、直前に秒間1000件を秒間500件に変更。敗者復活戦投票を乗り切った。
内製を支援するAWS
ビルディングブロックをコンセプトに掲げるAWSは、サービスを組み合わせて素早くアプリを作る手法の普及を進めている。新サービスを矢継ぎ早に投入する一方、関連情報の公開に注力する。朝日放送のようなサービスの内製を支援するのが狙いだ。
アマゾン ウェブ サービス ジャパン 技術統括本部 本部長 技術統括責任者の岡嵜禎氏は、「90を超えるサービスをどう組み合わせるかを考える際に、AWSリファレンスアーキテクチャーが参考になる」と話す。Webアプリやバッチ処理、ログ分析など典型的なシステムのアーキテクチャーを紹介。これをベースに利用者がサービスを組み合わせられるようにしている。
AWS上に作ったシステム全体のレビューには、「AWS Well-Architected Framework」が役立つとする。「質問に答える形で、初級ユーザーが考慮漏れをチェックできる」（岡嵜氏）。現在のチェック項目は、セキュリティ、信頼性、パフォーマンス、コスト最適化、オペレーション最適化の五つだ。「コスト効率の高いリソース選択の考慮点」では、「適切なリソースタイプを選択したか」「適切な料金モデルを選択したか」「利用できるマネージドサービスはあるか」などの質問項目が並ぶ。
マイクロサービスで改変を効率化
PaaSを高速開発に生かすうえで、CI/CD環境のほかに採用の検討が望ましい技術/機能が二つある。
一つは、プログラムの改変スピードを上げる手法として注目を集めるマイクロサービスだ。従来より小さな単位に機能を分割し、プログラムに手を加えた影響を確認するリグレッションテストの範囲を小さくする（図4）。
マイクロサービスに詳しい、レッドハットサービス事業統括本部 DevOpsリード シニアアーキテクトの山田義和氏は、「リリースサイクルやリソースの割り当てを、サービス単位に分離できる点もメリット」と指摘する。従来に比べ機能の単位が小さいので、開発チームを分割し生産性を向上できるという利点もある。
こうして作ったマイクロサービスはAPI（アプリケーション・プログラミング・インタフェース）を備え、コントローラーから順番に呼び出し一連のサービスを提供する。APIを一元管理し、実行制御するのが「APIゲートウエイ」である。
「マイクロサービス化には、パフォーマンスや管理性の低下、トランザクション制御が難しくなるといったデメリットもある。APIゲートウエイはこうしたデメリットを緩和できる」。山田氏はAPIゲートウエイの役割をこう位置付ける。
主要なベンダーPaaSはAPIゲートウエイの機能を提供している。
継続的モニタリングでフィードバック
もう一つ検討したいのは継続的モニタリングだ。サービス改善の種は、利用者のフィードバックにある。「サービスをリリースした後の継続的モニタリングこそが重要」と、日本マイクロソフト クラウドプラットフォーム技術部の廣瀬一海氏は強調する。
マイクロソフトのMicrosoft Azureは継続的モニタリングのツールとして、アプリのパフォーマンスを監視する「Application Insights」や、ユーザーの行動履歴をリアルタイムに収集、分析する「Mobile Engagement」などを用意する（図5）。
これらのツールを使って、サービスの提供状況とユーザーの振る舞いを照らし合わせて、改善につなぐ。
