この記事では、クラウドネイティブの概念や定義を詳しくおさらいし、その潜在的な用途や影響について考察していきたいと思います。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
クラウドコンピューティングの急速な発展に伴い、クラウドネイティブの概念が生まれています。クラウドネイティブは非常に普及してきており、今年の時点でクラウドネイティブを理解していないと時代遅れと言われてしまうでしょう。
多くの人がクラウドネイティブの話をしていますが、クラウドネイティブとは何かを正確に説明している人はほとんどいません。クラウドネイティブの資料をいくつか見つけて読んでも、ほとんどの人はまだ混乱していて、クラウドネイティブの理解が不十分だと感じているかもしれません。私の場合は、ある記事が理解できない時、いつも著者の愚かさのせいにしてしまいがちです。しかし、このような考え方をすることで、自分自身の自己疑念に囚われることがなくなり、前向きな姿勢を保とうとすることができるようになりました。
クラウドネイティブを明示的に表現できない理由は、明確な定義がないことにあります。クラウドネイティブは常に発展と変化を続けているため、クラウドネイティブを定義する絶対的な権利を持つ個人や組織は存在しません。
クラウドネイティブとは？
クラウドネイティブとは、アプリケーションを構築して実行するためのアプローチのことです。クラウドネイティブとは、「クラウド」と「ネイティブ」からなる複合語で、「クラウド」という言葉は、従来のデータセンターではなく、クラウド上に存在するアプリケーションを表します。「ネイティブ」という言葉は、クラウド上で実行され、アプリケーション設計の最初の段階で弾力性と「分散」の利点を十分に活用するように設計されたアプリケーションを表しています。
クラウドネイティブの概念は、2013年にPivotalのMatt Stine氏が初めて提唱しました。クラウドネイティブが普及し始めたばかりの2015年、Matt Stineは書籍『Migrating to Cloud Native Application Architectures』の中で、クラウドネイティブアーキテクチャのいくつかの特徴を定義しました。12ファクタアプリケーション、マイクロサービス、セルフサービス型アジャイルインフラストラクチャ、APIベースのコラボレーション、アンチフラジリティです。2017年のInfoQのインタビューでは、Matt Stine氏が若干の変更を加え、クラウドネイティブアーキテクチャの6つの特徴である「モジュール性」「観察性」「デプロイ可能性」「テスト可能性」「置換可能性」「処理可能性」を示しています。Pivotalの公式サイトに掲載されているクラウドネイティブアーキテクチャに関する最新の記述では、4つの主要な特徴が示されています。DevOps、継続的デリバリー、マイクロサービス、コンテナです。
2015年には、クラウドネイティブコンピューティング財団（CNCF）が設立されました。CNCFは当初、クラウドネイティブアーキテクチャの4つの特徴である「コンテナ化されたカプセル化」「自動管理」「マイクロサービス」を定義していました。2018年、CNCFはクラウドネイティブアーキテクチャの定義を更新し、サービスメッシュと宣言型APIの2つの特徴を追加しました。
このように、個人や組織によってクラウドネイティブ・アーキテクチャの定義が異なり、同じ個人や組織であっても、異なる時点でクラウドネイティブ・アーキテクチャの定義が異なっていることがわかります。このように複雑なため、私はクラウドネイティブ・アーキテクチャを明確に理解することが難しいのです。しばらくして、覚えやすく理解しやすい定義を一つだけ選ぶというシンプルな解決策を思いつきました（私の場合は、DevOps、継続的なデリバリ、マイクロサービス、コンテナ）。
クラウドネイティブアプリケーションを一言で言うと、以下のことを満たすことが求められています。K8やDockerなどのオープンソースのスタックを利用したコンテナ化の実装、マイクロサービスアーキテクチャに基づく柔軟性と保守性の向上、アジャイルな手法の採用、継続的なイテレーションと自動化されたO&MをサポートするDevOpsの実現、クラウドプラットフォームの設備を利用した弾力的なスケーリング、動的なスケジューリング、効率的なリソース利用の最適化の実装などが求められます。
クラウドネイティブは、シンプルで高速なアプリケーション構築、簡単なデプロイメントをサポートし、必要に応じてアプリケーションを拡張することができます。クラウドネイティブ・アーキテクチャは、従来のWebフレームワークやITモデルに比べて多くのメリットがあり、デメリットはほとんどありません。クラウドネイティブアーキテクチャは、この業界における強力な秘密兵器であることは間違いありません。
クラウドの4つの要素
マイクロサービス：クラウドネイティブの概念のほぼ全ての定義にマイクロサービスが含まれています。マイクロサービスはモノリスアプリケーションとは対極にあり、サービスをどのように分割するかを定義したコンウェイの法則に基づいており、理解しやすいものではありません。実際、どんなセオリーや法則もシンプルでわかりやすくないと、セオリーや法則のように専門的には聞こえないと思います。要はシステムアーキテクチャが製品形態を決定するということです。
マイクロサービスアーキテクチャでは、機能ごとに分割された後、サービスはより強いデカップリングと凝集力を持ち、それゆえに容易になります。DDDもサービスを分割するための手法の一つだと言われています。残念ながらDDDについてはよく知りません。
コンテナ：コンテナエンジンとしてはDockerが最も広く使われています。例えば、CiscoやGoogleなどの企業のインフラで多く使われています。DockerはLXCを利用しています。コンテナはマイクロサービスを実装するための保証を提供し、アプリケーションを分離する役割を果たします。K8sはGoogleが構築したコンテナオーケストレーションシステムで、コンテナの管理やコンテナ間の負荷のバランスを取るためのものです。DockerもK8sもGo言語で開発されており、本当に良いシステムです。
DevOps：DevOpsは「開発」と「運用」の切り口の複合体であり、開発と本番の関係とは異なる関係にあります。実はDevOpsにはテストも含まれています。DevOpsは、クラウドネイティブアプリケーションの継続的なデリバリーを可能にすることを目的としたアジャイルな思考方法論、コミュニケーション文化、組織形態です。
継続的なデリバリー：継続的デリバリーは、ダウンタイムのない開発とアップデートを可能にし、従来のウォーターフォール開発モデルとは異なります。継続的なデリバリには、開発バージョンと安定版の共存が必要です。これには多くのサポートプロセスやツールが必要です。
クラウドネイティブを導入するには？
まず、クラウドネイティブはクラウドコンピューティングの成果です。クラウドネイティブは、クラウドコンピューティングの発展なしには誕生しなかったでしょう。クラウドコンピューティングがクラウドネイティブの基盤となっているのです。
仮想化技術の成熟化と分散型フレームワークの普及により、アプリケーションをクラウドに移行することはもはや不可逆的な傾向となっています。コンテナ技術、継続的デリバリー、オーケストレーションシステムなどのオープンソースのコミュニティや、マイクロサービスのような開発アイデアにも後押しされています。
クラウドコンピューティングにおけるIaaS、PaaS、SaaSの3つのレイヤーは、クラウドネイティブのための技術的な基盤と方向性を提供しています。真のクラウド化は、インフラやプラットフォームの変更だけでなく、アプリケーションの適切な変更も必要となります。アプリケーションは従来の手法を捨て、アーキテクチャ設計、開発モデル、デプロイメント、保守など、さまざまなフェーズや側面でクラウドの特性を踏まえた再設計が求められます。これにより、新たなクラウドベースのアプリケーション、つまりクラウドネイティブなアプリケーションを生み出すことが可能になります。
1、ローカルに展開される従来のアプリケーションは通常 C/C++ や Java EE で書かれていますが、クラウドネイティブ・アプリケーションは Go や Node.js などの新しいネットワーク・プログラミング言語で書かれています。
2、ローカルに配置された従来型アプリケーションは、更新中にダウンタイムが発生する可能性がありますが、クラウドネイティブアプリケーションは常に更新されているため、頻繁な変更、継続的な配信、およびブルー/グリーンデプロイメントのサポートが必要となります。
3、ローカルに展開された従来型のアプリケーションは動的なスケーリングをサポートすることができず、トラフィックのピークに対応するために冗長なリソースを必要とすることがよくあります。しかし、クラウドネイティブ・アプリケーションでは、クラウドの弾力性と自動スケーリングを利用してリソースを共有することで、コストを削減し、効率を向上させることができます。
4、ローカルに展開された従来のアプリケーションは、IP、ポート、あるいはハードコーディングなどのネットワークリソースに依存していますが、クラウドネイティブアプリケーションはネットワークやストレージの制限を受けません。
5、ローカルに展開される従来のアプリケーションは、通常、手動での展開とメンテナンスが必要です。しかし、クラウドネイティブ・アプリケーションは、自動的なデプロイとメンテナンスをサポートします。
6、ローカルに展開される従来のアプリケーションはシステムコンテキストに依存しますが、クラウドネイティブアプリケーションはシステムコンテキストではなく抽象的なインフラストラクチャに依存するため、優れた移植性を実現します。
7、ローカルに展開される従来のアプリケーションの中には、モノリス（メガリス）アプリケーションであったり、強い依存関係を持っているものがあります。しかし、マイクロサービスアーキテクチャに基づくクラウドネイティブアプリケーションは、サービスを垂直方向に分割し、より合理的なモジュールを持っています。
クラウドネイティブアプリケーションを実装するためには、新たなクラウドネイティブ開発が必要なのは明らかです。クラウドネイティブには、インフラストラクチャサービス、仮想化、コンテナ化、コンテナオーケストレーション、マイクロサービスなど、多くの側面が含まれています。幸いなことに、オープンソースのコミュニティがクラウドネイティブアプリケーションに多大な貢献をしており、多くのオープンソースのフレームワークやファシリティが直接利用できるようになっています。2013年にリリースされた後、Dockerはすぐに実際のコンテナ標準になります。2017年にリリースされたk8sは、多くのコンテナオーケストレーションシステムの中で際立っています。これらの技術は、クラウドネイティブアプリケーションの開発の敷居を大きく下げています。
クラウドネイティブの導入資料は、一見大げさに見えるかもしれませんが、この資料に記載されているメリットには全く驚きを感じます。クラウドネイティブのアーキテクチャは完璧です。これは、アプリケーションはすぐにクラウドネイティブアーキテクチャに切り替えるべきだということでしょうか。これについては実際のニーズに基づいて判断し、現在の問題が本当にビジネス開発に影響を与えているかどうか、アプリケーションを再設計する余裕があるかどうかを検討する必要があると思っています。
傾向と影響
ソフトウェア設計には、高い結束力と低い結合という2つの重要な目標があります。この2つの重要な目標はさらに、単一責任原則、オープンクローズ原則、リスコフ置換、依存性反転、インタフェース分離、最小知識など、多くの具体的な設計原則につながっています。
ソフトウェアエンジニアは常にこの2つの目標を達成し、より明確で堅牢なソフトウェアを書き、スケールアップを容易なものにしようと努力してきました。
その後、より多くのニーズが追加されていきます。ソフトウェア開発は、よりシンプルで高速なものになることが期待されています。プログラマーはより少ない行数のコードを書きたいと考えており、プロではない人もアプリケーション開発の能力を求めています。プログラミングのスキルがない人のために、より簡単なプログラミング言語が開発され、ライブラリ、コンポーネント、クラウド基盤など、より多くのプログラミング技術やアイデアが開発されています。
その結果、多くの技術は、それ自体は高度なものではあるが、実用的な価値が低いものとなっています。多くのソフトウェア技術者は、パラメータ調整技術者、APIコールの専門家、ライブラリマスター、コンポーネントの専門家という新たな役割を担っています。これは、効率的な分業と技術開発の必然的な結果です。
20年近くのインターネット技術の発展を見ていると、特定分野の技術を応用したものが主流になっていることがわかります。特に近年のクラウドコンピューティングの発展と普及により、インフラはより強固なものとなり、ビジネス展開はますます容易になり、技術的な要件も少なくなってきています。同時に、小規模な企業やチームは、パフォーマンス、負荷、セキュリティ、スケーラビリティなどの側面に関連する問題に悩まされることがなくなりました。
PCプログラミング時代の基本インフラが制御ライブラリ、インターネット時代のインフラがクラウドだとすると、AI時代のインフラはどうでしょうか。AI時代にはどのようなハイエンド技術が登場するのでしょうか。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ