アプリのクラウドネイティブ化とは何か：Computer Weekly製品導入ガイド
クラウドネイティブアプリケーションは、組織のニーズに合わせたより動的なサポートを実現する。では、クラウドネイティブとは何だろうか。
CRMやERPは、組織が必要とする特定の作業を行うために開発されたエンタープライズアプリケーションだ。問題は、そうしたアプリケーションが肥大化して環境の「保有と支配」を確立しようとする中で、機動力を高めていこうとする企業にそぐわなくなった点にある。
関連記事
- コードを書き換えずにメインフレームアプリを移行する“リホスト”のススメ
- x86やクラウドよりもLinuxメインフレームを選ぶべき理由
- モバイルアプリに注力するスターバックス、POS端末はDOSベースだった
- モバイル向けメインフレーム!? でまだまだ生きるメインフレーム
- デジタルワークプレースに対応したPCの展開
世界は今、動的な複合アプリケーションに目を向け始めている。全てをこなす単一のアプリケーションを追い求めるのではなく、リアルタイムで組み合わせて、特定の期間にビジネスプロセスを支援できる機能スタブを構築する方法が求められるようになった。
インテリジェントなFAQシステム
一例として、見込み客が顧客となって商品を注文し、代金を払うまでの単純な手段を見てみよう。これを支える多数の技術がサードパーティーサービスを通じて十分に提供されている。見込み客が抱く疑問は、TransversalのインテリジェントFAQ（よくある質問）システムで対応できる。同アプリケーションが代金を集計して処理することはないが、WorldpayやPayPalのようなサードパーティー決済処理システムを使えばよい。
次の数十億ドル企業が、メジャーな新アプリケーションの背後で生まれる公算は小さい。デキるデベロッパーはカネを追い、クラウドでホスティングできて、大量の顧客による少額決済ができたり、月額料金を継続的に払ったりできる機能的なサービスを構築している。もはや、少量で利幅の大きいモデルではなく、量が多くて利幅の小さいモデルになった。
このアプローチは組織の内部にも当てはまる。必要に応じて周辺の別々のシステムを呼び出すことができ、もっと優れた機能が登場すれば接続したり接続を解除したりでき、簡単に最適化でき、アップデートやアップグレードの際にはそれに依存するハードコーディングされた上り下りのシステムを変更せずに済む機能の構築が求められる。
多面的な問題
奇妙なことに、そうしたイノベーションの主力分野はタブレットやスマートフォン経由だった。小さくて機能的なアプリを低コストで簡単に利用できることから、ユーザーは職場の中でも同じアプローチを求めるようになった。だが、そうしたアプリの大部分は単一の機能しかなく、それを組み合わせて多面的な問題を解決することはまだ難しい。
ここではIoT（モノのインターネット）を通じたホームオートメーションがニーズをかき立てている。「IFTTT」（if this, then that）プログラミングのような機能の利用が拡大し、「Amazon Alexa」や「Google Assistant」のように単一のフロントエンドで複数の異なる機器を連携させる家庭用ハブの利用も拡大している。開発者がクラウドネイティブになるために使える技術は多数ある。われわれは今、API経済の時代にいる。どんなサービスであれ、提供されるサービスの機能に対し、共通する標準の手段を通じて他者がアクセスできるよう、オープンなAPIが必須とされる。
Webベースサービスにおけるその好例として、RESTful（Representational State Transfer）アプローチの採用が挙げられる。RESTfulとはステートレスで運用できる呼び出しと応答の原則の集合を指す。RESTfulは拡張可能なインタフェースであることを通して、安定性と未来への耐性を実現しながら、パフォーマンスを最適化できる。
アップグレードの容易さ
どんな機能もサービスも、簡単にアップデートできるように開発する必要がある。カスケードあるいはウオーターフォールプロジェクトの方式で機能を構築するアプローチでは、ビジネスのニーズに対する十分な対応はできない。それよりも、秩序立ってコントロールされたDevOpsのアプローチを採用し、「Jenkins」や「Puppet」や「Chef」のようなオープンソースツールを使い、恐らくはCA Automicのようなアプリケーションリリース自動化システムを組み合わせた方がずっといい。
継続的な開発とデリバリー、デプロイという3つの「CD」の狙いは、ビジネスやユーザーの要求に応える新機能を、数カ月から数年ではなく、数日から数週間以内に提供することにある。
その機能は、それを下支えするリソースから確実に切り離さなければならない。例えば、必要とするCPUの量や、特定の種類のストレージサブシステムに深く依存する新機能の開発は時間の無駄になる。クラウドならばこうした全てを切り離すことができ、機能の全般的な拡張性も、コードによる制限を受けなくなる。ただ、管理者がクラウド内で特定の期間に使いたいと思うリソースの量によってのみ制約される。
プロビジョニングの容易さ
コンパイルされ、プラットフォームに直接プロビジョニングされたコードの利用は私たちにとって今も健在だが、未来は「Docker」や「rkt」「LXD」のような何らかの形のコンテナ化を指し示している。コードをコンテナの中に置くことで、ソフトウェアと物理プラットフォームの間の依存関係が従来よりも縮小され、機能を幅広いプラットフォームに届けやすくなる。「Kubernetes」や「JuJu」のようなシステムは、コンテナの適切な管理を支援する。
それぞれのサービスはメタデータとコンテキストで完全に定義する。そうしたコンテナの内容は、いずれ単一機能のサービス（マイクロサービス）へと縮小される公算が大きい。そうしたマイクロサービスは全て、それが何のためにあるのかを他者が把握できるよう、十分なメタデータを提供しなければならない。
開発ポータルではマイクロサービスを参照できる必要があり、個々のどんな開発者にも使えるようにしなければならない。従って、それが自動的に実現するよう、十分な情報が必要とされる。だが、メタデータのプロビジョニングのために重点を絞るべきはそれだけではない。緩い組み合わせで高性能を発揮するリアルタイム複合アプリケーションの未来は、メタデータとコンテキスト上で予測され、それを使って完全に自動化され、調和が保たれた方法でマイクロサービスを簡単に組み立てることができる。
クラウドネイティブの復号アプリケーションをこの方法で動的に構築できるようにするためには、全ての組み合わせを担うオーケストレーションシステムが機能の内容と使い方を理解できる必要が生じる。EnterpriseWebのような先端のシステムは、それを理解して、ディープなエンドツーエンドの自動化に求められるインテグレーションとオーケストレーションの定義および構築を可能にするメタデータを作成する。他のシステムでは、インテグレーションを適用するために必要な情報を提供する、標準化されたデータのセットが必要になるかもしれない。
車輪を発明しない
カレンダーのような機能を網羅するサービスは、既に豊富に出回っている。うるう年が来た途端に不具合が起きるようなものを自力で開発するよりも、そうした既存のサービスを利用した方がいい。パブリッククラウド製品として提供されている有料サポート付きのサービスに加えて、サポートされたサイトやコミュニティーグループで提供されている個別のコードの両方を検討したい。そうしたサイトでは一般的に、他のユーザーのフィードバックが掲載され、コードの良しあしや、必要な作業がこなせるかどうかを判断できる。こうした方法で事前に準備されたコードを利用すれば、コーディングにかける時間を大幅に短縮できるだけでなく、エラーの発見やその先の管理の手間も省くことができる。
自前のデータセンターを持つ既存のビジネスの中で運用している場合（あるいはコロケーション施設を使っている場合）、利用可能な手持ちのサービスに目を向けることを忘れてはいけない。クラウドネイティブアプリを最初から構築するためには、コーディングおよび結果として生じる全般的な環境の構成において、違うアプローチが必要になる。だが多くのサービスは、既存のエンタープライズアプリに隠れて既に存在しているかもしれない。
その秘訣（ひけつ）は、メインアプリケーションの一枚岩の中から特定の機能を抽出し、それを他のシステムで利用できる呼び出し可能な機能として提供することにある。ここでもまた、EnterpriseWebやCA Automicといった企業のサービスでは、個々のデータや機能を引き出して、オープン性や反応性がはるかに高いクラウドベースプラットフォームで利用できる場面を特定できる。
全般的に、クラウドネイティブアプリ開発へ移行するためには、開発、テスト、運用システムに対する組織のIT部門の見方を根本から変革する必要がある。鍵を握るのは小さく考える思考だ。コンテナ化されたマイクロサービスを出発点として、インテリジェントなオーケストレーションや自動化のシステムを組み合わせ、ビジネスニーズの動的なサポートを実現できるサービスとアプリケーションのポートフォリオを提供することが望ましい。
Copyright © ITmedia, Inc. All Rights Reserved.