クラウドネイティブアプリケーションとは
クラウドネイティブとは、クラウドコンピューティングモデルの利点をフル活用してアプリケーションを構築し、実行するアプローチです。クラウドはこれまで、エンタープライズデータセンターを運営するにあたっての多大な設備投資や人件費の必要性を排除し、オンデマンドかつ従量制の制約のないコンピューティング能力に置き換えることにより、事実上すべての産業で競争環境を再定義してきました。ITコストの低減は参入障壁が低くなることを意味し、市場に新しいアイデアをいかに早くもたらすかが、競争上の優位性を決める鍵となっています。だからこそソフトウェアが世界を飲み込み、新興企業はクラウドネイティブなアプローチを用いて従来の産業に変革をもたらしているのです。
そのうえ組織は、クラウドネイティブなアプリケーションやサービスを構築し運用するために、下図のようにDevOps、継続的デリバリ、マイクロサービス、およびコンテナの概念を自動化し、統合するプラットフォームを必要としています。
“Cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity.”
Joe Beda
Co-Founder, Kubernetes and Principal Engineer, VMware
Watch Joe talk about Kubernetes
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は起動とシャットダウンが遅く、アプリケーションコードをデプロイする前であっても、多大なコストがかかるためです。 |
Cloud-Native Apps and VMware
VMware チームの見解
Purpose-built for the cloud model, cloud-native applications enable smaller teams across organizations to deploy and deliver software faster. From retailers and manufacturers to healthcare and financial services organizations, IT teams are exploring cloud-native applications for greater agility.
Thoughts about Cloud-Native
Growing interest in cloud-native is prompting organizations looking to speed time to market to better understand cloud-native goals, best practices, optimal organizational structures, and the technologies fully automating application stack infrastructure layers.
Cloud-Native Blueprints for Banking
Running IT for a bank is not easy. The job requires creativity, agility, pragmatism, and grit. After all, bank IT teams must navigate generational changes from rising consumer expectations and fintech competition to regulatory compliance & security. Organizations are capitalizing on these shifts and gaining market share by becoming cloud-native.
Step-by-Step: The Journey to Cloud-Native
Modernizing an application portfolio can be challenging. Before beginning, there are four things every business on a journey to cloud-native needs to know.
How Organizations Should Think About Cloud-Native Java
Application platforms play a critical role in supporting cloud-native endeavors. Any business considering cloud-native should understand what it means and why IT staff should consider this paradigm as the way forward for an architecture strategy.