クラウドネイティブ：家を購入してからオープンするまでのストーリー

[[410627]]

この記事はWeChat公式アカウント「ネット事情は煙と雲のよう」から転載したもので、著者は李宗彪です。この記事を転載する場合は、Wangshiruyanyunの公開アカウントまでご連絡ください。

クラウドネイティブ

家を購入してからオープンするまでのストーリー

クラウド ネイティブという用語はかなり前からよく使われていますが、クラウド ネイティブとは何かについては依然としてさまざまな意見があります。

正しい質問をすれば、答えの半分は得られます。クラウド ネイティブについてはしばらく忘れて、サーバー指向プログラミングの昔に「戻って」みましょう。当時のソフトウェア アーキテクチャで最もイライラさせられた機能は何でしたか?

1. クラウドネイティブの根本的な問題

もちろん、この質問 (最もイライラするソフトウェア アーキテクチャ機能は何ですか) に対する答えは人によって異なりますが、大多数の人が同意すると思われる答えが 1 つあります。それは、コンピューティングの効率的で弾力的なスケーリング (エラスティック コンピューティング) です。

あるシステムに現在 10 台のサーバーが必要で、30 分後には 15 台のサーバーが必要になるとします。どうすればいいですか？

どうすればいいですか？調達申請レポートの提出 -> サーバーの購入 -> インストールと展開 -> オンライン化。どのステップが 30 分で完了できますか?このような状況に直面すると、残念ながら横になる以外に方法はないようです。

このシーンよりもさらにイライラするのは、大変な作業の末、半月が経過し、上司が「サーバーが 10 台になったので、先ほど購入した 5 台のサーバーを返却しましょう」と言ったことです。

たとえ JD.com を恥ずかしげもなく利用したとしても、JD.com は 7 日間の無条件返品しか提供しません。半月が経過しましたが、不正行為をする人は誰ですか?

サーバー時代では、クラウド コンピューティングが登場するまで、コンピューティングの効率的で弾力的なスケーリングは解決不可能な問題であったことがわかります。

私の好きな人は偉大なヒーローです。いつか彼がスポットライトの下に現れ、金色の鎧を身にまとい、色とりどりの雲に乗って私と結婚してくれることを私は知っています。

——紫霞仙女、「中国の旅」

クラウド コンピューティングとは、まず第一に、コンピューティング リソースのプールです。第二に、哲学的な観点から言えば、それは問題の移転と変換です。

クラウドベンダーの場合、現在 10,000 台のサーバーを所有しており、それを 20,000 台に拡張したい場合、調達申請 -> 調達 -> インストールと展開 -> オンライン化という同じ一連の問題に直面し、依然として長いプロセスに直面することになります。この観点から見ると、コンピューティングの弾力的なスケーリングの問題は解決されておらず、一般ユーザーからクラウドベンダーに移行されています。

これだけであれば、クラウド コンピューティングはおそらく実際の商用アプリケーションには利用できないでしょう。量的変化は質的変化につながります。この世に道はないが、歩く人が増えれば道になる。クラウド コンピューティング ユーザーの数が増えると、さまざまなユーザー間で「微妙な」動的なバランスが実現します。つまり、コンピューティング能力の向上 (上記のシナリオではサーバーの追加など) を期待するユーザーもいれば、コンピューティング能力の削減を期待するユーザーもいます。この増加と減少により、微妙な方法で動的なバランスが実現されます。クラウド ベンダーにとっては、既存のリソースを変更することなく、各ユーザーの柔軟なスケーリング ニーズを満たすことができます。 （もちろん、リソースの合計が不足している場合は、クラウドベンダーは容量を拡張するためにサーバーを購入する必要があり、これは別の問題です。）

ある意味で、クラウド コンピューティングの本質は「シェアリング エコノミー」モデルであると言えます。一般大衆の弾力的なスケーリングのニーズを満たすのは、このような「共有」です。

「シェアリングエコノミー」モデルの全体的な方向性が決まると、残るのはクラウドコンピューティング自体の技術開発です。仮想マシン (VM) からコンテナまで、コンテナ ソリューションとエコシステムの面では、現在 docker/k8s が勝っています。

なぜクラウドコンピューティングにはこのような発展の道筋があるのでしょうか?これは、図 1 に示すように、元の質問から始まります。

図1 サーバーからdocker/k8sへ

図 1 からわかるように、表 1 に示すように、サーバーからクラウド コンピューティングへの進化はほぼ避けられません。

表1 弾性効率

仮想マシンから Docker/K8s まで、クラウド コンピューティング テクノロジーの背後にある需要ロジックは、図 2 に示すように、弾力的な効率、展開の効率、弾力的な自動化 (および他のレベルでの自動化) です。

図2 弾力的需要のマズローモデル

図 2 から、マズローの弾力的需要モデルの段階的な発展に伴い、クラウド コンピューティング テクノロジも徐々に発展し、この発展プロセスで docker/k8s が選択されたことがわかります。少なくとも今のところ、彼らは比類のないコンビであり、完璧な組み合わせであり、世界を支配しています。

なぜ docker/k8s がこの技術戦争に勝利したのか、またその技術的な詳細は何かについては、この記事ではトピックと長さの関係で詳しく説明しません。私たちが知っておく必要があるのは、docker/k8s が基本的に人々の弾力的なコンピューティングのニーズを満たすように設計されており、弾力的な需要のマズロー モデルで勝利することだけです。

そこで疑問なのが、docker/k8s はクラウド ネイティブと呼べるかどうかです。確かにそう主張する人や企業もあ​​りますが、強く反対する人や企業もあ​​ります。率直に言えば、この見解を支持するか反対するかに関わらず、多くの場合、彼らは技術的な側面ではなく、自社の商業的利益を考慮しています。

花が沢山咲いていて眩しいくらいです。商業上の利益に関わるとなると、問題は不明確になります。クラウド ネイティブの本質を見つけるには、やはり元の問題から始める必要があります。

2. クラウドネイティブの2番目の根本的な問題

エラスティックコンピューティングに加えて、最も厄介なアーキテクチャ機能は何ですか?幸せな人生はどれも同じですが、不幸な人生はどれもそれぞれに悲しいものです。 2 番目に厄介なアーキテクチャ機能についてはさまざまな答えがありますが、それが HA (高可用性) である場合は、多くの人が同意するはずです。

図3に示すように、HAはコンピューティングHAとストレージHAに分かれていることに注意してください。

図3 HAの分類

さまざまな原則に基づいて、HA には、アクティブ/アクティブ、アクティブ/スタンバイ (図 3 はこのモードを示しています)、ローカル HA、リモート HA など、さまざまな分類があります。コンポーネントの分類により、HA はコンピューティング HA とストレージ HA に分けられます。

コンピューティング HA については、docker/k8s ですでに十分に解決できます (コンピューティング コンポーネントがサービス指向/ステートレスのものに変換されている場合)。しかし、残念ながら、ストレージ HA に関しては、現時点では非常にシンプルで効果的な独自のソリューションは存在しません。

そのような解決策がないので、ストレージ HA をそのまま維持するべきでしょうか?いいえ、クラウドベンダーが推奨するソリューションは

努力せずに勝つ

シンプルで効果的な解決策がないため、クラウド ベンダーは、図 4 に示すように、「この問題について心配する必要はありません。お金をいただければ、解決をお手伝いします」と主張します。

図4: ストレージのためのHA Win-Winソリューション

ストレージはリレーショナル データベースだけを意味するわけではありません。図 4 は単なる概略図です。アプリでリレーショナル データベースを操作する必要があるとします。開発者は、リレーショナル データベース (つまり、ストレージ クラス) のデータに必要な HA について心配する必要はありません。クラウドベンダーのリレーショナル データベース サービス (Huawei Cloud の GaussDB など) を呼び出すだけで済みます。すると、その背後にあるデータの HA (データベース コンピューティング部分の HA を含む) はクラウド ベンダーによって解決され、開発者が行う必要があるのは、上司を説得してクラウド ベンダーのクラウド データベースを購入するためにお金を使うことだけです。

リレーショナル データベースではなく別の種類のデータベースの場合、またはデータベースとは何の関係もなく単なるストレージである場合は、お金を払う意思があれば、クラウド ベンダーが対応するサービスを提供します。

付け加えておきたいのは、単純なストレージ サービスとは別に、現在のクラウド ベンダーは、自社が提供する対応するサービスがすべてのユーザーのニーズを 100% 保証できるとは保証できないということです。これには、特定の問題に関する特定の分析が必要です。しかし、一般的な考え方は次のとおりです。

クラウド サービスにお金をかけながら、同時に HA の問題を解決しましょう。

クラウド ネイティブは、ユーザーが料金を支払うクラウド サービスに、BaaS (Backend as a Service) という高尚な名前を付けます。 BaaS はシナリオによって定義が異なるため、それにこだわる必要はありません。これはクラウドベンダーのレトリックとして理解できます。

建築家として、あなたのソリューションには実際にお金がかかると想像してください。どうしてまだ上司のために働けるんですか？このとき、クラウド ベンダーはあなたに小さな赤い花を贈ります。お金を使っているのではなく、BaaS なのです!

急に高級感が出てきたような？急に上品に見えませんか？上司のお金を使って、上司を驚かせましょう!

しかし、BaaS は最も印象的なものではありません。最も印象的なのは、サーバーレス ソリューションです。客観的に言えば、サーバーレスはクラウド ネイティブの属性の 1 つですが、根本ではありません。少なくとも今のところは少し混乱しています。

3. クラウドネイティブの究極的な追求

サーバーレスとは​​、実際にはサーバーが存在しないことを意味するものではありません。当社のソフトウェアはクラウド上に展開され、クラウドは最終的にサーバーによってホストされます。本当にサーバーが存在しないなら、クラウドはクラウドではなく、空気と呼ばれます。

サーバーレスとは​​、開発者がサーバーの存在を意識する必要がなく、すべてがクラウドに任されることを意味します。

サーバーレスの定義は、一般的に受け入れられている次の式で表すことができます。

サーバーレス = BaaS + FaaS

前述したように、BaaS ではユーザーがサーバーの存在を意識する必要はありません。この記事の長さとトピックのため、FaaS (Functions as a Service) のトピックについて詳しく説明することはできません。つまり、現時点で認識する必要があるのは 2 つの点だけです。

（１）サービス指向コードよりも「単純化」されている。すべての実行と弾力性はクラウドに引き渡されます（弾力性の効率はミリ秒レベルです）

（２）しかし、その適用シナリオは限られており、普遍的な解決策ではない。

客観的に言えば、サーバーレスはまさにクラウド ネイティブの究極の追求です。しかし、FaaS が万能なソリューションとは言えないからこそ、著者はサーバーレスをクラウド ネイティブの本質 (本質の 1 つ) として理解することには同意しません。そうしないと、クラウド ネイティブの概念に混乱が生じるからです。

実際、クラウド ネイティブの概念を「混乱させる」のはサーバーレスだけではありません。多くのパブリック クラウド ベンダーは、意図的か否かにかかわらず (いや、意図的です)、クラウド ネイティブの範囲を無限に拡大しています。彼らが話すのはイデオロギー（クラウド ネイティブ）ばかりですが、考えているのはビジネスだけです。ビジネスの観点から言えば、これを行うことに何の問題もないかもしれません。

張華さんはソフトウェア会社でプログラマーとして働いており、クラウド サービスに料金を支払っています。 Li Ping はクラウドベンダーでネットワークエンジニアとして働いており、クラウドサービスの運用と保守を行っています。王氏はソフトウェア会社の社長であり、自社のアーキテクチャはクラウドネイティブであると述べています。

私たち全員に明るい未来があります！

では、これらのクラウドベンダーはどのようにしてクラウド ネイティブの概念を無限に拡張するのでしょうか?家を購入してから家を借りるまでのストーリーです。

4. 家を購入してからオープンするまでのストーリー

図 5 に示すように、ソフトウェア開発モデルの進化を思い出してみましょう。

図5 家を購入してから家を借りるまでのストーリー

サーバーモデルを住宅購入モデルと比較すると理解しやすくなります。クラウド コンピューティング モデルの仮想化テクノロジには、仮想マシンとコンテナが含まれます。ここでのコンテナは、単純なコンテナ テクノロジを指します。クラウド コンピューティング モデルでは、家 (コンピューティング/ストレージおよびその他のリソース) を購入する必要はなく、レンタルできますが、家にあるその他の基本的なサービス (弾力性、HA) は自分で提供する必要があります (クラウド コンピューティング モデルもこれらの基本的なサービスを提供しようとしますが、うまく提供できません)。クラウドネイティブ モデルでは、ユーザーは家の中の基本的なサービスについて心配する必要はなく、部屋を予約するために料金を支払うだけで、残りはホテルに任せることができます。

人生において、私たちは食べ、飲み、排便し、排尿し、眠り、食べ、飲み、ギャンブルをし、売春をし、喫煙します。普通のホテルであれば、睡眠サービス（もちろん排便サービスも含む）の提供に重点を置けばよい。しかし、他の産業を支えるほど多くの人が部屋を予約したらどうなるでしょうか?それとも、他の業界がより多くの人々を客室予約に誘致することを期待しているのでしょうか?この時点で、ホテルの主な事業が何なのかはわかりません。睡眠サービスですか、ギャンブルサービスですか、それとも東莞スタイルのサービスですか？

大手メーカーが主張しているように、クラウド ネイティブにはすべてが備わっており、すべてを実行できます。例えば、あるメーカーは、図 6 に示すように、サービスのライフサイクルから始めて、そのサービスを購入する限り、あらゆる段階でクラウド ネイティブの概念が存在すると主張しています。

図6 ある工場が主張するクラウドネイティブ段階

実際、図 6 はすべての段階をカバーしていますが、「信頼性」という点のみが関係しています。しかし、この点は反論の余地がない。ランタイム向けの製品群であれば、AIなどさまざまなサービスを詰め込んで、BaaSやクラウドネイティブと呼んでいますが、図7に示すAlibaba Cloudのクラウドネイティブ製品群のように、これはやはり反論の余地がありません。

図7 Alibaba Cloudのクラウドネイティブ製品ファミリー

何か問題がありますか？問題ありません！問題は、クラウド ネイティブの本質をどうやって見つけるかということです。

5. クラウドネイティブの本質

ここまで書いてきて、書き続けるのが少し躊躇しています。これまではいくらでもくだらない話をすることができましたが、今は突然、このような深刻で奥深い話題について話さなければならなくなりました。著者は自分のレベルに限界があり、それができないことを痛感しています。しかし、ここまで来たからには、思い切って書き続けようと思います。専門家の前で自分のスキルを披露するのは恥ずかしいでしょう。

場合によっては、ソリューションの本質 (クラウド ネイティブはソリューションです) を見つけるには、それが解決する本質的な問題から始める必要があります。

著者は、クラウド ネイティブが解決する必要がある本質的な問題は次の通りであると考えています。

エラスティックコンピューティング + HA

その他の問題は、2 つの重要な問題を解決するまでの過程で遭遇する問題 (途中の問題) です。つまり、すでに遭遇した問題であるため、「偶然」解決できる場合は、それらも解決されることになります。完全性の観点から見ると、これはクラウドネイティブ ソリューションの範囲を拡大しますが、決してクラウドネイティブの本質ではありません。

例えば、「サービス検出」の問題に関しては、サービスは柔軟である必要があるため、リクエストがサービスインスタンスに正しく到達できる必要があります。それで、どうやってそこにたどり着くのでしょうか?もちろん、まずサービス検出が必要です。

たとえば、セキュリティや復元力などの問題はすべて、クラウド ネイティブの基本的な道のりで遭遇する問題です。クラウド ネイティブはこれらすべてを解決するのに役立ちます。しかし、これらはクラウド ネイティブの本質的な問題ではなく、副次的な問題であることを深く理解する必要があります。

まとめると、図 8 に示すように、クラウド ネイティブが解決する必要がある問題もマズローのモデルに準拠していると考えられます。

図8 クラウドネイティブが解決する問題のマズローモデル

ロマン・ロランは、この世に真の英雄はただ一つしかなく、それは人生の真実を知った後も人生を愛し続けることだと言いました。

クラウド ネイティブの本質的な問題とオンパスの問題を認識した上で、クラウド ネイティブがオンパス問題を解決するために行った取り組みを否定するものではありません。それは途中で起こる問題を解決します。もちろん、それはより良いことです。純粋な概念に執着するために、スプリング全体を拒絶する必要はありません。

もちろん、問題解決は双方向のプロセスであり、クラウド ネイティブも双方向のプロセスです。これは、クラウドベンダーの取り組みだけでなく、ソフトウェア開発者の取り組みも含まれます。この点については Alibaba Cloud の要約の方が優れているので、図 9 に示すように、ここで直接引用します。

図9 Alibaba Cloudのクラウドネイティブアーキテクチャ成熟モデル

図 9 の ACNA は Alibaba Cloud Native Architecting の略です。私がこの写真を直接引用する理由は、次のとおりです。

（１）クラウドネイティブの本質的な問題と経路関連の問題、そしてこれらの問題を解決する目標を非常によくカバーしている

（２）クラウドベンダーとソフトウェア開発者の共同の取り組みを意味する

もちろん、パス問題の数は無限です。技術の発展とクラウドベンダーの成長に伴い、クラウドネイティブの範囲はますます広くなり、クラウドネイティブの本質的な課題も拡大していくことがわかります。しかし、それはすべて過去のことです。

現在のテクノロジー スタックに関する限り、クラウド ネイティブの核と本質は何かと聞かれた場合、私の答えは次のとおりです。

Docker/k8s + BaaS

将来的にはdocker/k8sテクノロジースタックが置き換えられ、BaaSの範囲は無限に拡大される可能性があります。 「お金でお金が買える」限り、つまり開発効率を向上させ、開発コストを削減できる限り、すべてをクラウド ネイティブにすることができます。

したがって、クラウド ネイティブは CaaS (Cost as a Service) です。