クラウドネイティブ| IBM

クラウドネイティブとは

クラウドネイティブでは、アプリケーションの保存場所の記述が減り、構築方法や導入方法の記述に重きが置かれます。

クラウドネイティブ・アプリケーションは、任意のクラウド環境に統合できるよう設計された、マイクロサービスと呼ばれる個別に再利用可能なコンポーネントで構成されます。
これらのマイクロサービスは、ビルディング・ブロックとして機能し、多くの場合、コンテナ内でパッケージ化されます。
マイクロサービスは、全体として連携して1つのアプリケーションを構成しますが、それぞれ個別にスケーリングし、継続的に改良し、自動化とオーケストレーションのプロセスを通じて素早く反復することができます。
個々のマイクロサービスの柔軟性により、クラウドネイティブ・アプリケーションの俊敏性と継続的な改良がさらに促進されます。

次の動画、「クラウドネイティブとは」では、Andrea Crawfordが主要な概念の一部について、その概要を説明しています。

マイクロサービスとコンテナ

マイクロサービス（またはマイクロサービス・アーキテクチャー）は、独立して導入可能な、疎結合された多数の小さなコンポーネントまたはサービスで1つのアプリケーションを構成する、アーキテクチャー・アプローチです。これらのサービス（マイクロサービスともいいます）は通常、データベースとデータ・モデルを含む独自のテクノロジー・スタックを持ち、 REST API、イベント・ストリーミング、およびメッセージ・ブローカーの組み合わせを介して相互に通信します。

マイクロサービスは、相互に影響を与えたり、エンド・ユーザーによる体験を中断したりすることなく、個別に導入したり再導入したりできるため、継続的インテグレーション/継続的デプロイメント（CI/CD）やDevOpsなど、自動化された反復デリバリーの手法に最適です。

マイクロサービスは、まったく新しいクラウドネイティブ・アプリケーションの作成だけでなく、従来型のモノリシック・アプリケーションをモダナイズするためにも使用できます。

IT部門の幹部、開発部門の幹部、および開発者を対象とした最近のIBMの調査によると、マイクロサービスのユーザーの87％が、マイクロサービスの採用は費用と労力を投じる価値があることに同意しています。

開発者はしばしば、任意の環境でコードを実行するために必要なオペレーティング・システム（OS）のすべてのライブラリーと依存関係とともに、マイクロサービスをコンテナ内にデプロイします。コンテナは、アプリケーション・ソースコード（この場合はマイクロサービス・コード）を組み合わせた軽量で稼働可能なアプリケーション・コンポーネントです。仮想マシン（VM）よりも小さく、リソース効率が良く、移植性が高いコンテナは、最新のクラウドネイティブ・アプリケーションの 事実上の 計算ユニットです。

コンテナは、パブリッククラウド、プライベートクラウドおよびオンプレミスのインフラストラクチャーなど、ハイブリッド・マルチクラウド環境全体で一貫性のある導入体験とマネジメント体験を実現することにより、マイクロサービスのメリットを増強します。しかし、クラウドネイティブ・アプリケーションの数が増えるにつれ、コンテナの数とその管理の複雑さも増します。コンテナ化されたマイクロサービスを使用しているほとんどの組織は、Kubernetesなどのコンテナ・オーケストレーション・プラットフォームも使用して、コンテナの導入と管理を大規模に自動化しています。

マイクロサービスとコンテナを使用すべき理由（英語）

メリットとデメリット

IBMのお客様は、既存のアプリケーションの改良、新しいアプリケーションの構築、ユーザー体験の向上に取り組む必要性がさらに高まっていることを認識しています。クラウドネイティブ・アプリケーションは、アプリケーションのパフォーマンス、柔軟性、拡張性を向上させることで、これらの要求に応えます。

メリット

クラウドネイティブ・アプリケーションは、アジャイル・プロセスとDevOpsプロセスにより反復的に改良されるため、従来のモノリシック・アプリケーションよりも簡単に管理できます。
個別のマイクロサービスから構成されるクラウドネイティブ・アプリケーションは、新機能と改良された機能を継続的に追加するために、段階的かつ自動的に改良できます。
利用者に負担をかけず改良作業を行えるため、ダウンタイムやエンド・ユーザー体験の中断が発生しません。
クラウドネイティブ・アプリケーションを支える柔軟性の高いインフラストラクチャーにより、規模の拡大縮小をより簡単に行えることが実証されています。
クラウドネイティブ開発のプロセスは、今日のビジネス環境で要求されるスピードとイノベーションに、より適したものになっています。

デメリット

マイクロサービスは、アプリケーションを改良するための反復的なアプローチを実現しますが、より多くの要素を管理する必要性も生じさせます。 1つの大きなアプリケーションではなく、はるかに小さな個別のサービスを管理することが必要になります。
クラウドネイティブ・アプリケーションは、DevOpsパイプラインを管理し、従来のモニタリングの構造を置き換え、マイクロサービス・アーキテクチャーを管理するために、追加のツール・セットを必要とします。
クラウドネイティブ・アプリケーションは、迅速な開発と導入を可能にしますが、そのイノベーションのペースに対応できるビジネス文化も必要とします。

アプリケーションの例

クラウドネイティブ・アプリケーションは、多くの場合、特化された複数の機能を備えています。旅行関連のWebサイトでクラウドネイティブ・アプリケーションがどのように使用される可能性があるか考えてみましょう。フライト、ホテル、車、特別プランなど、サイトで取り上げられる各トピックは、そのサイトの独自のマイクロサービスです。各マイクロサービスは、他のマイクロサービスとは独立して新機能を展開できます。特別プランや割引は、個別にスケールアウトすることもできます。この旅行サイトは全体として顧客に提示されますが、各マイクロサービスは独立したままであり、他のサービスに影響を与えることなく、必要に応じて拡大縮小または更新できます。以下は、その他のクラウドネイティブ・アプリケーションの例の一部です。

アメリカン航空社（2:50）は、厳しい気象条件が発生している間に起動される、動的な予約変更アプリケーションを構築するために、IBMと提携しました。このアプリケーションは、ユーザーにより多くの情報と改良された予約変更プロセスを提供することで、顧客体験を向上させました。
教育と研修のための分析プラットフォームを提供するXComP Analytics社（1:56）は、分析の問題を解決する必要がありましたが、IBM Cloud Garageを利用するようになってから、1つの課題を修正する過程で、6つの新製品を開発することができました。このソリューションでは、マイクロサービス・アーキテクチャーが使用され、特定の分析の問題を解決するためのIBM Watsonが組み込まれました。
UBank銀行（2:45）には、住宅ローンの提供を改善し、顧客による住宅ローン申請プロセスの完了を支援するというビジネス・ニーズがありました。この銀行のスマート・アシスタント・アプリケーションであるRoboChatは、IBM DevOpsツールチェーンを使用して構築され、そのニーズに応えることができました。 RoboChatを使用した顧客は、住宅ローンの申請完了率が15%高くなりました。
医療研究の重要な点は、患者ケアのベスト・プラクティスについて医師に助言することです。しかし、ベスト・プラクティスを発見する医療研究が、実際の医療業務に適用されるようになるには、17年かかります。 ThinkResearch社（2:06）はIBM Cloudを使用して、治療現場で最良の医療情報を提供しています。 ThinkResearch社のDevOpsチームは、IBM CloudインフラストラクチャーとマネージドKubernetesサービスを使用することで、インフラストラクチャーではなく、イノベーションと患者ケアに集中できるようになりました。

IBM Cloud Garageは、IBMのお客様に、拡張性の高い革新的なクラウドネイティブ・アプリケーションを迅速に構築するためのコンサルティングの専門知識を提供します。このサービスは、あらゆる規模の企業が実際のビジネス・ニーズを解決するアプリケーションを設計して構築できる、イノベーション・ハブを提供します。

開発の原則

新しいクラウドネイティブ・アプリケーションを作成する場合も、既存のアプリケーションをモダナイズする場合も、開発者は以下の一貫した原則に従います。

マイクロサービス・アーキテクチャーのアプローチに従う：アプリケーションを、マイクロサービスと呼ばれる単一機能の複数のサービスに細分化します。マイクロサービスは、疎結合されていますが、独立したままであるため、ダウンタイムを発生させることなく、アプリケーションを段階的、自動的、継続的に改良できます。
コンテナを利用して柔軟性と拡張性を最大化する：コンテナは、ソフトウェアとそのすべてのコードと依存関係を1つの場所にパッケージ化し、ソフトウェアをどこでも実行できるようにします。これにより、マルチクラウド環境で最大限の柔軟性と移植性を得られます。コンテナはまた、ユーザーが定義したKubernetesオーケストレーション・ポリシーによって、迅速な拡大縮小も実現します。
アジャイル手法を採用する：アジャイル手法は、作成と改良のプロセスを高速化します。開発者はユーザーのフィードバックに基づいて更新を素早く繰り返し、現行のアプリケーション・バージョンを可能な限りエンド・ユーザーの期待に沿うものにします。

ストレージ

クラウドネイティブ・アプリケーションは、多くの場合、コンテナに依存します。コンテナの魅力は、柔軟性があり、軽量で、移植性があることです。初期のコンテナ利用は、あるユーザー・セッションから次のユーザー・セッションにユーザー・データを保存する必要のないステートレス・アプリケーションに焦点を合わせる傾向がありました。

しかし、より多くのコア・ビジネス機能がクラウドに移行されるにつれ、永続ストレージの問題をクラウドネイティブ環境で対処することが必要になってきています。そのために、開発者は、クラウド・ストレージへの新しいアプローチの方法を検討する必要があります。

クラウドネイティブ・アプリケーションの開発にマイクロサービスとモジュラーのアプローチが採用されているように、クラウドネイティブ・ストレージにも新しいアプローチが必要です。クラウドネイティブ・データは、イベント・ログやシステム・ログ、リレーショナル・データベース、ドキュメント・ストアやオブジェクト・ストアなど、さまざまな場所に存在する可能性があります。

データのロケーション、保存の要求、移植性、プラットフォームの互換性、セキュリティーは、開発者がクラウドネイティブ・ストレージを計画するときに考慮しなければならない側面のほんの一部です。

クラウドネイティブ・データ・ストレージの詳細はこちら

クラウドネイティブ・アプリケーションと従来のアプリケーション

クラウドネイティブとクラウド利用可能

クラウド利用可能アプリケーションとは、従来のデータセンターに導入するために開発されたアプリケーションですが、クラウド環境でも実行できるように後で変更されたものです。一方、クラウドネイティブ・アプリケーションは、クラウドでのみ動作するように構築されています。開発者は、拡張性が高く、プラットフォームに依存しない、複数のマイクロサービスで構成されたアプリケーションとなるように、クラウドネイティブ・アプリケーションを設計します。

クラウドネイティブとクラウド対応

クラウド・コンピューティングの短い歴史の中で、「クラウド対応」の意味は何度か変わりました。当初、この用語は、インターネット上で機能するように設計されたサービスまたはソフトウェアに使用されていました。今日、この用語は、クラウド環境で動作するアプリケーション、またはクラウド環境用に再構成された従来のアプリケーションを表すために、より頻繁に使用されています。「クラウドネイティブ」という用語の歴史はさらに短く、クラウドでのみ動作し、クラウド・アーキテクチャーの特性を活用するために最初から開発されたアプリケーション、またはクラウドネイティブの原則でリファクタリングまたは再構成された既存のアプリケーションを指します。

クラウドネイティブとクラウド・ベース

クラウド・ベースのサービスまたはアプリケーションは、インターネットを介して提供されます。これは、さまざまなクラウド・オファリングに自由に適用される一般的な用語です。「クラウドネイティブ」は、より具体的な用語です。クラウドネイティブは、クラウド環境で動作するように設計されたアプリケーションを表します。この用語は、マイクロサービス、継続的インテグレーション、および継続的デリバリー（CI/CD）に依存し、任意のクラウド・プラットフォームを介して使用できるアプリケーションのことを指します。

クラウドネイティブとクラウド・ファースト

クラウド・ファーストは、組織が新しいITサービスを立ち上げたり、既存のサービスを更新したり、レガシー・テクノロジーを置き換えたりする際に、クラウド・リソースを優先的に使用することをコミットするビジネス戦略を示します。コスト削減と運用効率向上がこの戦略の主な意図になります。クラウドネイティブ・アプリケーションは、クラウド・リソースのみを使用し、クラウド・アーキテクチャーの特性のメリットを活かすように設計されているため、クラウド・ファースト戦略に適しています。