「勝てるITサービス」に欠かせない、開発・運用基盤の3要件とは？：IoT、FinTech時代、自社の市場を奪われないために

テクノロジの力で新たな価値を創出したITサービスが、企業収益・ブランドを左右するほどのインパクトを持つようになって久しい。例えば「Uber」や「Airbnb」のように、既存ビジネスモデルを変え、業界構造の破壊すら引き起こすケースも現れ始めている。こうしたデジタルトランスフォーメーションが日本でも急速に進む中、ITサービス開発競争を勝ち残るためにはどのような開発・運用基盤が必要なのだろうか。その回答として「コンテナ戦略」を打ち出すレッドハットに話を聞いた。

[PR/＠IT]

デジタルトランスフォーメーションに欠かせないコンテナ技術

　IoT、FinTechトレンドの本格化が象徴するように、ビジネス／サービスをデジタル化して新しい価値を創出する“デジタルトランスフォーメーション”が国内でも活発化している。特に昨今は製造、金融のみならず、流通・小売り、交通、不動産、農業など、あらゆる業種で取り組みが進み、「従来は考えられなかったようなITサービス」が次々と生まれては受け入れられている。

　何より重要なのは、これを受けて既存の業界構造が破壊されつつあることだろう。例えば、タクシー業界における「Uber」、旅行業界における「Airbnb」のように、テクノロジの力で創出した新たなサービス価値が、従来のビジネスプロセスや商流を変え、各業界における既存のプレーヤーを脅かしている。国内でもデジタルトランスフォーメーションが急速に進む今、テクノロジを使いこなして新たな価値を創出する“ITサービス開発競争”に勝てるか否かは、市場競争を生き残る前提条件となりつつあるのだ。

　だが、競争が激しくニーズの変化が速い中で、顧客に支持されるITサービスを開発するのは決して簡単なことではない。そうした中でも、着実に顧客をつかみ、収益を上げ続けるためには何がカギになるのだろうか？ デジタルトランスフォーメーションに向けた企業の取り組みを支援しているレッドハット プロダクト・ソリューション本部 本部長の岡下浩明氏は次のように話す。

レッドハット プロダクト・ソリューション本部 本部長 岡下浩明氏

　「経営環境変化が速い中では、新しいビジネスアイデアを素早く形にする、ニーズの変化に応じてすぐに改善するといった『スピード』が差別化の要件となります。しかし従来のシステム開発・運用スタイルでは、そうしたスピード、柔軟性を担保することは難しいのが現実です」（岡下氏）

　例えば、ウォーターフォール型開発の場合、要件を定義してから半年〜1年以上かけてサービスを開発・リリースする。だがニーズの変化が激しい中では、半年〜1年後にはニーズが変化してしまう。またニーズが多様化し、“これまでになかった利便性”が求められている中では、最初から要件を明確に定義することも難しい。

　リリース後にも問題がある。リリース時にはサービスが受け入れられたとしても、その後もニーズの変化に応じて、機能追加・変更などサービス改善し続けなければ、他のサービスに顧客を奪われてしまう。例えば、ITサービスの主戦場となるモバイルアプリにおいて、「使いにくい」「不便だ」と感じた際、その場でアプリを削除した経験は誰しもあるはずだ。細かな設定変更でも数日かかってしまうような従来型の開発・運用方法では、ニーズの変化に追従できず、撤退を余儀なくされてしまうのだ。

　「ITサービス競争では、『いち早くローンチしたサービスが勝つ』といわれています。着想したアイデアを実装する時間が短いほど、競合を制する優位性が得られます。逆に、時間がかかるほどアイデアの価値は失われていきます。いかに早くアイデアをサービスに変えてデプロイできるか、サービスに対する市場の反応を受けて、いかに早く改善を重ねていけるか――すなわち、DevOpsのアプローチが競争を勝ち抜く大きなカギとなるのです」（岡下氏）

従来型の開発・運用スタイル、3つの課題

　では従来型の開発・運用スタイルには、今求められているスピード、柔軟性に応える上で、具体的にどのような問題があるのだろうか。岡下氏は大きく3つの問題を指摘する。

　1つは、本番環境へのデプロイに時間がかかること。開発環境とは構成が異なるために多大な確認作業が発生し、それがスピードと柔軟性を削ぐことになる。

　2つ目は、アプリケーションのアーキテクチャがモノリシックであったり、モジュールの単位が大き過ぎたりするため、些細な修正でもその影響が広範囲に及び、改修・改善のスピードが遅くなってしまうこと。

　3つ目は、アプリケーションが環境にロックインされてしまうこと。アプリケーションが特定の環境に依存しているため、例えばオンプレミスからパブリッククラウドに移すためには改修が必要になるなど、迅速な移行が難しい。トラフィックの増減が激しくなりがちなITサービスを効率的に運用するためには、状況に応じて最適な環境で稼働させることが大きなポイントとなる。だがアプリケーションのポータビリティの乏しさが、これを阻害してしまうのだ。

レッドハット プロダクト・ソリューション本部 ミドルウェア シニアビジネスデベロップメントマネージャー 中澤陽彦氏

　では、こうした問題を解決するためには、具体的にどのようなアプローチが必要なのだろうか？ そこでレッドハットが提案するのが、「ITサービス開発・運用の基盤としてコンテナ技術を活用する」ことだ。レッドハット プロダクト・ソリューション本部 ミドルウェア シニアビジネスデベロップメントマネージャー 中澤陽彦氏は次のように話す。

　「サービス開発・運用のスピードアップのためには、開発スタイルの変更だけでは難しいと考えます。開発のスピードアップなら、CI（継続的インテグレーション）によるビルド、テストの自動化により実現できます。しかし前述のように、問題は開発環境と本番環境が異なるため、デプロイするまでに多大な確認作業を要するなど、デプロイがスピードを阻む足かせとなっていることです。サービスの着想を素早く形に変え、スピーディに市場に届けるためには、ボトルネックを排除し、開発からテスト、デプロイ、運用に至る一連のパイプラインを仕組み化することが不可欠です。そうした“仕組み”の軸となるのがコンテナ技術なのです」（中澤氏）

コンテナ技術は「デプロイと運用の再発明」。ITサービス競争に負けない「仕組み」とは

　この考え方を機能として実装したのが、レッドハットが9月に発表したコンテナアプリケーションプラットフォーム「Red Hat OpenShift Container Platform」だ。これは、物理、仮想、クラウドなどのさまざまな環境で迅速なアプリケーション開発・デプロイを支援するPaaS製品「Red Hat OpenShift Enterprise」の名称をリブランドしたもので、「コンテナ技術を軸に、企業のデジタルトランスフォーメーションを支えていく」というレッドハットのメッセージを込めているという。

　では具体的に、コンテナ技術は従来型システム開発における3つの課題を、どう解決するのだろうか？

　周知の通り、コンテナ技術とはアプリケーションをパッケージ化することで、「ホストOS上の他のプロセスから隔離されたアプリケーション実行環境」を構築する技術だ。その最大の特長は、「コンテナに詰め込んだアプリケーションを、そのまま別のホストOS上へデプロイできること」にある。これが1つ目の問題、「開発環境とは異なる環境へのデプロイ」の問題を解決する。

　「つまり、開発者はさまざまな環境でアプリケーションを開発した後、コンテナ技術でパッケージ化してしまうことで、開発環境とは構成が異なる本番環境にそのままデプロイできるようになるのです。一方、運用管理者にとっては、アプリケーションの種類や開発環境などにかかわらず、統一された手法でコンテナアプリケーションを管理できるようになります。すなわち、コンテナ技術は、これまで手法やプロセスが標準化されておらず、手作業中心だったアプリケーションのデプロイと運用に統一手法を提供することになるのです。いわば、コンテナ技術は“デプロイと運用の再発明”であり、企業のデジタルトランスフォーメーションを大きく推進する力を持っていると考えます」（岡下氏）

図1　コンテナ技術を使えば、開発環境を問わず、コンテナに詰め込んだアプリケーションを、そのまま本番環境のホストOS上へデプロイできる。運用担当者はアプリケーションの種類を問わず、統一された手法でコンテナを管理できる

　現在、コンテナ技術のスタンダードになりつつあるのは「Docker」だ。OpenShift Container Platformは、このDockerと、Googleとレッドハットが主に開発に参加しているオープンソースソフトウェア（以下、OSS）のコンテナオーケストレーションフレームワークである「Kubernetes」が実装されており、任意の設定に応じて、デプロイと運用をセキュアに自動化することができる。

　「例えばOpenShift Container Platformでは、Jenkinsなどによる継続的インテグレーション、コンテナイメージの作成、リポジトリへの登録、本番環境へのデプロイまでを1クリックで行うこともできます。開発者はどうコンテナ化するかを知らなくてもいい。運用担当者はコンテナの中身を知らなくてもいい。コンテナ技術によって『異なる環境へのデプロイ』というボトルネックを取り除き、開発からデプロイまでの一連の流れをOpenShift Container Platformによって仕組み化することで、ITサービスのデリバリを大幅に加速することができるのです」(中澤氏)

図2　 OpenShift Container Platformでコンテナ管理を自動化することで、開発からデプロイに至るまでのスピードが大幅に向上する。その後の運用管理効率も高まる

　2つ目の問題、「アーキテクチャやモジュールの粒度が大き過ぎて改修に時間がかかる」問題にはマイクロサービス化が寄与する。周知の通り、マイクロサービスは「単一の機能を持つサービスを組み合わせて1つのシステムを作る」手法だ。そうした単機能のサービスをコンテナで管理すれば、サービス単位での可搬性や運用性が高まり、マイクロサービス化に大いに寄与する。サービスの修正もコンテナ単位で行えるため、改修・改善も影響範囲を最小限に抑えながら迅速に行える。

　3つ目のロックインの問題もコンテナで対応できる。パッケージ化されたコンテナは、ホストOSを問わずにデプロイ・運用できる。サーバー仮想化やクラウドの場合、ハイパーバイザーやホストOSの種類に縛られてしまう。例えば、社内の「VMware vSphere」上で稼働させている仮想マシンを、“そのまま”「Amazon Web Services」や「Microsoft Azure」上に自動的にデプロイするといったことは現状ではまずできない。デプロイの方法も仮想環境やクラウド環境ごとに異なるため、開発者、運用者はそれぞれの知識とノウハウが求められる。

　しかし、標準コンテナに対応したホストOS環境であれば、ローカルの開発環境であれ、仮想環境であれ、クラウド環境であれ、同一のコンテナイメージを、同一の手法で、そのままデプロイして運用できる。デプロイは数分で行える他、スケールアウトの自動化、リソース割当の自動化なども容易に行える。すなわち、「最初はパブリッククラウド上でサービスをスモールスタートし、顧客数が増えてきたらオンプレミスに移して本格展開する」、あるいは「クラウド上でサービスを運用し、トラフィック増減に合わせて最適なリソースを自動的に割り当てる」など、ITサービスの発展・安定運用に不可欠な“適材適所のインフラ選択”を大いに支援する格好だ。

図3　コンテナによってマイクロサービス化することでサービスの改善・改修が迅速に行える他、アプリケーションの環境依存を回避できることでロックインも防げる。OpenShift Container Platformは、そうしたコンテナを使った一連のデプロイパイプラインを仕組み化する

　デジタルトランスフォーメーションが進んでいる海外では、OpenShift Container Platform（Red Hat OpenShift Enterprise）に多数の事例があるという。例えばブラジルのホスティング会社、UOL HOSTでは、JavaやPHP、Rubyなど、異なる環境で構築した約5万個もの既存アプリをコンテナ化し、そのままクラウド上に移行した。その後も、デプロイ・運用手順の統一化を果たしたことにより、サービス提供を大幅に高速化したという。米国の分析ツールベンダー、FICOでは、自社パッケージ製品をコンテナ化。これをマルチテナントのSaaSとして配布するモデルを構築し、ユーザー企業へのパッケージ製品導入期間を数カ月から数日に短縮した。

　マイクロサービス化した事例としては、スペインに本拠を置く旅行業者向けソリューションプロバイダー、Amadeusの事例がある。同社では、新しい顧客向けサービスを提供するに当たり、モノリシックなアーキテクチャだった既存のJava EEアプリケーションを、コンテナ技術を使ってマイクロサービス化。各コンテナを3つの地域のデータセンターにレプリケートしており、各顧客が必要な機能を、常に最適なパフォーマンスで利用できる仕組みとした。

　「Amadeusの場合、コンテナが適切なデータセンターに自動的にデプロイされるなど、インフラ管理を全て自動化しています。既存環境からのコード修正率は0.01%で、アプリケーションの処理能力は50倍に、更新は14分で済むそうです」(中澤氏)

コンテナ活用における「レッドハットならではの価値」とは？

　ただ、コンテナ技術に関しては、Dockerを中心に、すでに複数社からサポートサービスやソリューションが提供されている。そうした中でも、レッドハットがコンテナを軸とした戦略を打ち出した理由について、岡下氏は次のように語る。

「コンテナ技術を核に、企業の取り組みを包括的にバックアップします。まずはコンテナ技術を実際に使ってみてはいかがでしょうか。その利便性をあらためて理解できるはずです」と、デジタルトランスフォーメーションに向けてエールを送る岡下氏と中澤氏

　「ITサービス競争に勝つためには、ビジネス価値を創出するまでのリードタイムを短縮するDevOpsの取り組みと、それを支えるコンテナ技術が不可欠となります。しかし、これは単にコンテナ技術を導入すれば済むという話ではありません。どのようにコンテナ技術を使えば企業ITにバリューが出せるのか――例えば、DevOpsはどう実践するのか、どのような考え方でサービスの粒度を細かくすべきなのか、ロックインはどう防ぐのか、といった知見、ノウハウを提供できる他、多くの企業に浸透している『JBoss Middleware』製品や『Red Hat Gluster Storage』をコンテナ化しており、Red Hat OpenShift Container Platform上で提供可能としています。エンタープライズITとオープンソースへの貢献を続けてきたレッドハットだからこそ、システム開発・運用のモダナイゼーションを、ノウハウ、手段の両面から支援できる点が数多くあるのです。コンテナ“プラットフォーム”という観点でコンテナ技術の活用を“総合的に支援”することで、利用者のすそ野を広げていきたいと考えています」

　実際、同社はDevOps実現に向けて、段階的にその実践を支援する「DevOpsディスカバリーワークショップ」も用意。パートナー企業と連携した「OpenShiftサポートサービス」も提供していく。また2016年6月には、利便性の高いITサービスを開発する上で不可欠となるAPIマネジメントのツールベンダー、3scaleを買収してラインアップに加えるなど、デジタルトランスフォーメーションに必要な要素をそろえ、企業の取り組みを総合的に支援する体制を整えている。

図4　レッドハットのコンテナポートフォリオ。デジタルトランスフォーメーションに向けて、企業のシステム開発・運用スタイルのモダナイゼーションを、知見と手段の両面から包括的にバックアップする《クリックで拡大》

　「従来型ITシステムの課題を知り抜いた上で、デジタルトランスフォーメーションに向けた取り組みを包括的に支援できることがレッドハットの大きな強みです。ITサービスが収益・ブランドを左右する重要な顧客接点となっている今、コンテナ技術普及の“先導役”として、少しでも多くの企業に寄与していきたいと考えています」（岡下氏）