クラウドネイティブアプリケーションとは
クラウドネイティブとは、クラウドコンピューティングモデルの利点をフル活用してアプリケーションを構築し、実行するアプローチです。クラウドはこれまで、エンタープライズデータセンターを運営するにあたっての多大な設備投資や人件費の必要性を排除し、オンデマンドかつ従量制の制約のないコンピューティング能力に置き換えることにより、事実上すべての産業で競争環境を再定義してきました。ITコストの低減は参入障壁が低くなることを意味し、市場に新しいアイデアをいかに早くもたらすかが、競争上の優位性を決める鍵となっています。だからこそソフトウェアが世界を飲み込み、新興企業はクラウドネイティブなアプローチを用いて従来の産業に変革をもたらしているのです。
そのうえ組織は、クラウドネイティブなアプリケーションやサービスを構築し運用するために、下図のようにDevOps、継続的デリバリ、マイクロサービス、およびコンテナの概念を自動化し、統合するプラットフォームを必要としています。
DevOpsとは、ソフトウェアのデリバリとインフラストラクチャの変更のプロセスを自動化することを目標に、ソフトウェア開発者とIT運用担当者とがコラボレーションすることを意味します。これにより、ソフトウェアの構築、テスト、リリースが迅速に、頻繁に、かつ確実に行われる文化と環境がつくられます。
継続的なデリバリとは、アプリケーションに変更が生じるごとに、準備ができ次第リリースすることを意味します。他の変更が生じてから1つのリリースにまとめたり、メンテナンス期間といったイベントを待ったりすることはありません。継続的なデリバリにより、リリース活動がありふれた定時性のあるものになるため、組織はアプリケーションがビジネスプロセスや企業の競争力にとって不可欠な一部となるまで、低リスクで頻繁にデリバリを行い、エンドユーザーからのフィードバックをより速く得ることができます。
マイクロサービスとは、小さなサービスの集まりとしてアプリケーションを開発するアーキテクチャ手法です。各サービスはビジネス機能を実装し、独自のプロセス内で動作し、HTTP APIを介して通信します。各マイクロサービスは、たいていは自動化システムの一部として、アプリケーション内の他のサービスに依存せずにデプロイ、アップグレード、規模の変更、再起動が可能であるため、最終顧客に影響を及ぼすことなく、稼働中のアプリケーションを頻繁にアップデートできます。
コンテナは、標準的な仮想マシン（VM）と比較して、効率性とスピードの両方を提供します。オペレーティングシステム（OS）レベルの仮想化を通じて、1つのOSインスタンスは1つまたは複数の分離されたコンテナの間で動的に分配されます。各コンテナは、固有の書き込み可能ファイルシステムとリソースクオータを持ちます。コンテナの作成や破棄のためのコストが低減されるほか、1つのVMにおける記憶密度が高いため、個々のマイクロサービスのデプロイにとって理想的なコンピューティング手段と言えます。
「私たちが学んだことの1つは、市場への投入が迅速にできなければ、どのようにうまく設計し、構築し、デプロイし、人員を訓練しようとも、確実に市場は移り変わってしまうため、タイミングがちょっと遅かったという理由だけで、いまいちな結果になってしまうということです。」
James McGlennon
リバティ・ミューチュアル・インシュアランス・グループ、代表取締役副社長兼CIO
クラウドネイティブアプリケーションが重要である理由
クラウドネイティブアプリケーションは、クラウドモデル専用に構築されています。これらのアプリケーションは、小規模な機能別専門チームによって短いサイクルで構築され、プラットフォームに展開されることで、スケールアウトとハードウェアの分離を容易にし、組織に優れたアジリティ、弾力性、およびクラウド全体での可搬性を提供します。
競争上の優位性をもたらすクラウド
クラウドネイティブとは、クラウドの目標を、ITのコスト削減からビジネスの成長へと切り替えることを意味します。ソフトウェアの時代においては、顧客のニーズに合わせて迅速にアプリケーションを構築し、納品できる企業が業界を支配します。いったん納品されると、アプリケーションは常時接続の、規模を弾力的に変えられるサービスとして動作する必要があります。
柔軟性
企業は、どのクラウド上でも修正なしに動作するアプリケーションを構築できます。チームは、ビジネスの優先事項やクラウド料金の最適化のため、さまざまなクラウドベンダーやプライベートクラウド間でアプリケーションを移行または分配する能力を維持できます。
開発者に最高の仕事をさせることができる
クラウドネイティブアプリケーションを採用しているチームは、多様なクラウドインフラストラクチャ全体での実行と規模変更のためのコードを書くコストから開発者を開放し、顧客に価値を与えるコードに集中できます。標準化された開発者スタックに関する12 Factor Appはサービスの一連の標準を求めたもので、アプリケーションが基盤となるクラウドネイティブプラットフォームのすべての利点を活用できるようにするために開発者が守るべき標準の「規約」を提供しています。
運用とビジネスを連携させる
IT運用を自動化することで、企業はリーンへの変革を行い、ビジネスの優先事項を促進することに集中できます。スタッフはルーチンで日常的な管理タスクのプロセス向上に集中し、人的エラーに起因するリスクを排除できます。スタックのすべてのレベルにおいてパッチやアップグレードを稼働中に自動適用することで、ダウンタイムがなくなり、運用エキスパートの「熟練の勘」といったような技術は不要となります。
大きな違い：クラウドネイティブアプリケーションと従来のエンタープライズアプリケーションとの比較
|
クラウドネイティブアプリケーション
|
従来のエンタープライズアプリケーション
|
|---|---|
| 予測可能。 クラウドネイティブアプリケーションは、予測可能な行動を通じて弾力性を最大化するために設計されたフレームワークまたは「規約」に準拠している。クラウドプラットフォーム内で使用されている高度に自動化されたコンテナ駆動のインフラストラクチャは、ソフトウェアの記述を加速する。そのような「規約」の良い例は、「Twelve-Factor App（アプリケーションの12の要素）」として初めて文書化された12の原則によって示されています。 | 予測不可能。 従来のアプリケーションは、アーキテクチャまたは開発の方法に起因して、クラウドネイティブプラットフォーム上で実行することで得られるメリットのすべてを実現できません。この種のアプリケーションはしばしば構築に時間がかかり、大きなバッチでリリースされ、規模の拡大縮小が段階的でのみ可能で、単一障害点がより多くあります。 |
| OS抽象化。 クラウドネイティブアプリケーションアーキテクチャを用いる場合、開発者は基盤のインフラストラクチャの依存関係を無視するための手段としてプラットフォームを使用し、アプリケーションのシンプルな移行や規模の変更を可能にする必要があります。抽象化の手段として最も効率的なものはVMware Tanzu などの形式化されたプラットフォームです。このプラットフォームは、Google Cloud Platform（GCP）、Microsoft Azure、またはAmazon Web Services（AWS）といったクラウドベースのインフラストラクチャ上での運用に理想的です。 | OS依存。従来のアプリケーションアーキテクチャは、アプリケーションと、基盤となるOSハードウェア、ストレージ、およびバックエンドサービスとの間で緊密な依存性を構築することを可能にしていました。これらの依存性は、新しいインフラストラクチャ全体でアプリケーションの移行や規模の変更を複雑でリスクの高いものにするほか、クラウドモデルに対して不利に作用します。 |
| 適正サイズの容量。 クラウドネイティブアプリケーションプラットフォームは、インフラストラクチャのプロビジョニングと構成を自動化し、デプロイ時にアプリケーションの現状でのニーズに応じて、リソースの動的な割り当てや再割り当てを行います。クラウドネイティブランタイム上での構築により、需要に合わせた規模の変更、リソース利用状況、利用可能なリソース全体での調整、ダウンタイムを最小化する障害復旧を含め、アプリケーションライフサイクル管理が最適化されます。 | オーバーサイズの容量。 従来のIT設計は、あるアプリケーション専用の、カスタムインフラストラクチャソリューション（「雪の結晶」）型の設計で、そのことがアプリケーションのデプロイの遅れにつながっていました。ソリューションの容量はしばしば、最悪のケースの容量予測に基づいて過剰に大きく設けられており、需要に合わせて規模をさらに拡大する余地が少ない。 |
| 連携。クラウドネイティブは、人、プロセス、およびツールを連携させるDevOpsをサポートし、開発者と運用担当者間の緊密な連携を実現するとともに、完成したアプリケーションコードを実稼働環境に迅速かつ円滑に移行させることを可能にします。 | サイロ型。 従来のITは、完成されたアプリケーションコードが開発者から運用担当者へと「壁越しに」引き継がれ、その後、実稼働環境で実行されていた。組織的な優先事項は顧客の価値よりも高く位置づけられ、結果として内部衝突、デリバリの遅れや妥協、スタッフの士気の低下が生じていた。 |
| 継続的デリバリ。 ITチームは、個々のソフトウェアアップデートの準備ができ次第、逐次リリースする。ソフトウェアをリリースする組織は、より頻繁にフィードバックを得られるので、顧客にニーズにより効果的に対応できます。継続的デリバリは、テスト駆動の開発や継続的インテグレーションといった他の関連アプローチを併用することで最大の効果を発揮します。 | ウォーターフォール型の開発。 ITチームはソフトウェアを定期的にリリースする。通常その間隔は数週間または数か月もあいている。コードはリリース時に組み込まれるが、リリースの構成要素の多くが以前から準備できていて、互いのコードは上辺だけのリリース目的以外に関連性がありません。顧客にとって必要な機能は後回しにされるので、企業は競争力を高め、顧客を獲得し、収益を向上させる機会を失います。 |
| 独立性。マイクロサービスアーキテクチャは、アプリケーションを小さく、ゆるく連結され、独立したオペレーティングサービスへと分解します。これらのサービスは、小規模で独立した開発チームに割り当てられ、他のサービスに影響を及ぼすことなく、頻繁かつ自律的にアップデート、規模の変更、フェイルオーバー/再起動できます。 | 依存的。 モノリシックアーキテクチャは、多くの異なるサービスを1つのデプロイパッケージにバンドルすることで、サービス間で不要な依存関係を生じさせ、開発とデプロイとの間のアジリティが損なわれる結果となっています。 |
| 自動化された拡張性。大規模なインフラストラクチャ自動化により、人的エラーによるダウンタイムがない。コンピュータの自動化にも人的エラーが発生せず、どの規模のシステムにも一貫して同じルールセットが適用されます。またクラウドネイティブは、従来の仮想化指向の編成上に構築された、臨機応変の自動化を超えた存在です。完全なクラウドネイティブアーキテクチャには、チームの代わりに機能する自動化機能や調整機能が含まれており、チームはカスタムレシピとして自動化のための書き込みをする必要がない。すなわち自動化により、アプリケーションを簡単に構築、実行、管理できます。 | 手動での規模の変更。 運用担当者がサーバー、ネットワーク、およびストレージ構成を手動で作り上げ、管理するなどといった、手動インフラストラクチャです。大規模になると複雑度が上がるので、運用担当者は問題の診断に時間がかかり、正しい実装に失敗しやすくなる。手動で作成された自動化レシピは、インフラストラクチャの中に人的エラーをハードコーディングさせる恐れがあります。 |
| 迅速な復旧。 コンテナランタイムとコンテナオーケストレーション機能は、VM上に構築された動的で高密度な仮想オーバーレイを提供します。これはマイクロサービスのホスティングに理想的です。オーケストレーション機能はVMのクラスタ全体でコンテナの配置を動的に管理し、障害発生時に弾力的な規模の変更や、復旧/再起動を行います。 | 復旧が遅い。 VMベースのインフラストラクチャは、マイクロサービスベースのアプリケーションにとって時間がかかり、非効率的な基盤です。なぜなら、個々のVMは起動とシャットダウンが遅く、アプリケーションコードをデプロイする前であっても、多大なコストがかかるためです。 |
クラウドネイティブアプリケーションを検討する際の 考慮事項
運用はクラウドネイティブな世界で進化していく
運用チームは現状維持から脱却し、プロセスの改善と自動化の推進者となり、ビジネスに直接的な価値を提供します。クラウドネイティブプラットフォームは、アプリケーションを1日目にリリースし、2日目には運用を開始することを可能にするほか、以前には手動介入が必要だった問題の監視や修正も自動化できます。
作業負荷を優先順位付けする必要がある
すべての作業負荷が、クラウドネイティブへの転換に適しているわけではありません。従来の作業負荷や未開拓の作業負荷について、ビジネスやITのプロフェッショナルが協力し合いながら優先順位をつけ、各ケースがクラウドネイティブな方向性に進んだ場合の技術的実現可能性、戦略的重要性、その結果としてのROIなどを見極める必要があります。この評価を支援するため、新規開発に加え、さまざまな再プラットフォームパターンが提供されています。
開発者は規約に沿ってコードを作成する必要がある
クラウドネイティブプラットフォームの利点を享受するには、開発者は、12の要素からなる原則や標準化されたプラットフォームやサービスを理解するため、より多くの訓練が必要になるかもしれません。自由裁量だったかつてのコード化作業から変化することになるかもしれませんが、クラウドネイティブプラットフォームによってもたらされる利点により、抵抗は緩和されるはずです。
必要なプラットフォームを構築するか、購入するか
多くのチームは、オープンソースの自動化技術とコンテナ技術の組み合わせから、独自のプラットフォームを構築することを検討しています。しかしながら程なくして、思っていたよりも多くの構成要素が必要であることに彼らは気づきます。これらのすべては連携するように設計されていないので、アプリケーション構築の実際の作業への着手が遅れてしまうことでしょう。それに加えて、プラットフォームがいったん稼働したら、チームはそれを保守する必要があります。こうした経験を、VMware Tanzuのような実績ある統合型のプラットフォームと比較してみてください。1日目から、チームはビジネスを推進するアプリケーションの構築に集中することができ、運用やインフラストラクチャへのプラットフォームの対応能力にも確信を持つことができます。
独力でやる必要がない
たとえばPivotal Labsと協働するなど、集中訓練を通じて学習することで、継続的デリバリといったアジャイルな製品開発プラクティスを完全に身に着け、新たな開発習慣を確固たるものにすることができます。このモデルに関する情報は豊富に提供されているので、それらを活用して試してみてください。組織のアジャイル化が十分ではないと感じているチームは75パーセントに上るそうですが、そうしたチームにとっては、新しいことを試すチャンスです。