クラウド ネイティブに関する 3 つの質問: 避けられない過去と現在は何ですか?

2013年に、有名なPaaSクラウドサービス企業PivotalのプログラマーであるMatt Stine氏が「クラウドネイティブ」という概念を提唱し、それ以来、クラウドネイティブというニッチで奥深い名前が広まりました。

[[418143]]

2年間の積み重ねを経て、2015年にCloud Native Computing Foundation（CNCF）が設立されました。Googleなどの大手企業が設立したこのベンダー中立の財団は、クラウドネイティブアプリケーションの推進と普及に欠かせない役割を果たしています。クラウド ネイティブの概念が進化し続けるにつれて、クラウド コンピューティング市場全体がこれにますます注目するようになっています。

業界では一般的に、2020 年はクラウド ネイティブ元年と見なされるべきだと考えています。多くのクラウド サービス プロバイダーは、企業向けのクラウド ネイティブ アプリケーションを反復および更新することで、弾力的なスケーリング、動的なスケジューリング、クラウド プラットフォーム ファシリティのリソース使用率の最適化などの利点を実現できると主張しています。しかし、本当にそうなのでしょうか?

直感的な観点から見ると、クラウド ネイティブは、「将来のソフトウェアはクラウド上で成長する必要がある」という概念に基づいた、クラウド プラットフォームの将来の開発パスに対する美しいビジョンです。しかし、業界の観察者として、私たちは一連の質問について考える必要があります。

• まず、クラウド ネイティブは、テクノロジー、方法論、または複数のテクノロジーを統合したシステムとして定義されるべきでしょうか?
• 次に、クラウドネイティブ改革とアップデートの原動力と理由は何でしょうか?既存のクラウド プラットフォームのクラウド ネイティブ レイアウトをどのように作成すればよいでしょうか?
• 最後に、クラウド ネイティブ レイアウトには特定の優先順位がありますか?

これらの質問について考える前に、歴史上の技術革新の出来事を振り返り、それらを現在のクラウド ネイティブの熱い市場状況との類似点として考えてみましょう。

1つ

1866年にドイツでシーメンスが発電機を製造しました。実用的な発電機は 1870 年代に登場し、電気エネルギーを機械エネルギーに変換することが現実のものとなりました。電気は機械を動かすために使用することができ、蒸気動力を補完または置き換える「新しいエネルギー」となる可能性があります。

興味深いことに、1900 年まで、米国の工場のうち電気を主なエネルギー源として使用していたのは 5% 未満であり、蒸気エネルギーと補助装置の使用にこだわることが業界の標準となっていました。工場にとって、電気時代の始まりはまだ蒸気時代に属しています。

当時の工場は、現代の工場とは全く異なり、主に蒸気エンジンで動いており、動力の伝達はすべて工場の建物よりも長い巨大な伝動軸によって行われていました。伝動シャフトシステムでは、動力を分配するメインシャフトに加えて、セカンダリシャフト、ベルト、ギアの協調動作も必要です。さらに、ハンマー、パンチ、プレスなどの機器が相互に連携して、電力システムの全体的な構成を完成させる必要があります。

このように高度に結合されたシステムでは、1 つのデバイスを稼働させる必要がある限り、動力源である蒸気エンジンを停止できないというジレンマが生じます。同時に、複雑なシステムはコストの上昇とリスクの増大ももたらします。蒸気機関は故障時にすぐに停止することができなかったため、19世紀後半には工場の製造工程で数え切れないほどの労働者が亡くなりました。

このような内外からの圧力の下、少数の工場は、よりクリーンで近代的な電気機械が市場に存在することに気付きました。彼らは高い交換コストをかけて蒸気エンジンを電気モーターに置き換えましたが、残念ながら、それに見合った利益は得られませんでした。そのため、ほとんどの工場は依然として蒸気機関の使用を主張し、1900 年には「電気時代の中の蒸気時代」として前述した状況が生まれました。

その理由は、電気モーターの利点を最大限に活用したい場合、元の蒸気エンジンを単に電気モーターに置き換えるだけでは十分ではないからです。工場側も運営上の考え方を変える必要がある。

蒸気時代では、人々は機械に仕え、機械が正常に作動している限り、労働者の資格、スキル、数量は生産効率に限られた影響しか与えませんでした。電気の時代では、その逆が当てはまりました。設備の電動化により、工場では、駆動軸周りの電力システムから、作業員の作業効率や連携能力の向上へと重点を徐々に移していきました。蒸気時代には、蒸気機関と巨大な伝動軸が動力源の中核でした。新しい電気工場では優秀な労働者が中核となります。

私たちは生産性や幸福度の大幅な向上を新しい技術の生産と応用のおかげだと考えがちですが、歴史の結論は、本当の進歩は新しい技術の誕生よりも後になって起こることが多いことを繰り返し証明しています。こうした新しいテクノロジーが既存のルールにどのような影響を与えるかについて考えるには、さらに時間が必要です。情報混乱の中で改革の真の価値をいかに見出すかが、期待を達成し、期待を超えるための基本条件です。

クラウド ネイティブの議論に戻ると、初期の「クラウド」の概念は、学界や企業から多くの注目を集めました。企業のクラウド移行の難しさを軽減し、クラウド移行プロセスを標準化するために、クラウド サービス プロバイダーは通常、直接移行 (リフト アンド シフト) 方式を採用します。このアプローチは実装コストが低く、リスクが低く、プロセスが短いため、初期のクラウド戦略の開発のための基本的な環境が提供されます。

ローカル データの正確なコピーをクラウドに移行するという基本的なロジックは、100 年以上前に電気モーターが蒸気エンジンに取って代わった方法の複製です。

この比較的単純なクラウドへの移行方法では、クラウド コンピューティングのメリットを最大限に活用できず、パブリック クラウドの使用コストはローカルに展開されたサーバーに比べて大幅に削減されていません。企業がクラウド ネイティブへの移行を求められる中、このような反復的な問題と、クラウド サービス プロバイダーが現在提供しているいわゆるソリューションは、よく見かけるようになりました。

二

クラウドネイティブ時代において、業界や企業はクラウドネイティブシステムを構築する際に、特定の優先順位に従うべきでしょうか?更新と展開を急ぐことで、企業のコスト削減と効率向上に本当に役立つのでしょうか?この質問に答えるには、クラウドネイティブの核となる利点に立ち返る必要があります。

クラウドネイティブは単語の組み合わせです。クラウドとはクラウド コンピューティングに基づいていること、ネイティブとはクラウド用に設計されていること、クラウド ネイティブとはクラウド プラットフォームの弾力性と分散性の利点を最大限に活用することを意味します。 iResearch は、クラウド ネイティブはアプリケーションを構築および実行するための技術システムおよび方法論であると考えています。クラウド ネイティブの特徴は、コンテナ化 + マイクロサービス + DevOps + 継続的デリバリーとして簡単にまとめることができます。

このことから、これを単なる技術として捉えるのは正確ではないことがわかります。単純な技術更新ではないため、蒸気エンジンを電気エンジンに単純に置き換えることは現実的ではありません。クラウド ネイティブでは、クラウド コンピューティングを基盤技術として合理的に活用した後、主要な技術から始めて、プラットフォームのクラウド ネイティブ化の論理的な手順を検討する必要があります。

クラウドネイティブ プラットフォームのレイアウトはルートレスにすることはできません。アップデートを開始する前に、企業はクラウドネイティブ プラットフォームと元のプラットフォームの違いと改善点を理解する必要があります。

産業上の利益の観点から見ると、クラウド ネイティブはクラウドの利点を大幅に解放し、クラウドの設計思想を完全に継承します。将来的には、アプリケーションはクラウド上のローカル アプリケーション開発に基づくものになり、つまり、クラウド ネイティブ アプリケーションはクラウド アーキテクチャにより適したものになります。クラウド コンピューティングは、リソースの分離、分散、高可用性など、クラウド ネイティブ アプリケーションに優れた基本サポートも提供します。クラウドコンピューティングの転換期が到来し、クラウドネイティブはビジネス成長を推進する重要な原動力となっています。

同時に、クラウドネイティブは、デジタル変革を支える重要な技術として、人工知能、ビッグデータ、エッジコンピューティング、5Gなどの新興分野で徐々に登場し、デジタルインフラを牽引する強力なエンジンとなっています。業界全体でクラウドコンピューティングが徐々に深まるにつれて、企業のクラウドネイティブ変革のプロセスはさらに加速されます。

技術的な特徴の観点から見ると、クラウドネイティブ テクノロジ アーキテクチャには、極めて高い弾力性という典型的な特徴があります。仮想マシンの分単位の弾力的な応答とは異なり、コンテナ クラウド テクノロジーに基づくクラウド ネイティブ テクノロジー アーキテクチャは、数秒、さらには数ミリ秒単位の弾力的な応答を実現できます。サービス自律障害自己修復機能。クラウドネイティブテクノロジースタック上に構築されたプラットフォームは、高度に自動化された配布スケジュールとチューニングのメカニズムを備えており、アプリケーションの障害を自動的に削除して再構築できるほか、非常に強力な自己修復機能と任意の廃棄機能を備えています。大規模な複製可能性。これにより、地域、プラットフォーム、さらにはサービス プロバイダー全体にわたる大規模なレプリケーションおよび展開機能を実現できます。

アプリケーション価値の観点から見ると、異種リソースとコンテナ技術の標準化は、異種環境のデプロイメント一貫性の問題を効果的に解決し、サービス指向および自動化開発の基盤を提供します。デジタルインフラのアップグレードと生産性の解放を加速し、ユーザーがデジタル技術を使用するための敷居を下げ、リソースの複合利用率を向上させ、研究開発業務の生産方式を変革します。組織の壁を打ち破り、R&Dと運用の間の領域横断的なコラボレーションを実現し、配信効率を向上させます。ビジネス アプリケーションの反復速度を向上させ、ビジネス イノベーションを実現します。

クラウドネイティブ テクノロジーにより、アジャイルなアプリケーション開発が可能になり、配信速度が大幅に向上し、ビジネスの試行錯誤コストが削減され、ユーザーのニーズに効率的に対応し、ユーザー エクスペリエンスが向上し、ビジネス イノベーションが加速されます。上記の点により、クラウド ネイティブ テクノロジー システムは市場で広く歓迎されるようになりました。

クラウド プラットフォームをクラウド ネイティブな方法で展開および更新する方法については、iResearch では、これらのテクノロジとコンセプトから始めることができると考えています。

コンテナ クラウド テクノロジーにより、デバッグ、開発、展開、運用、保守、移行、拡張が容易なクラウド ネイティブ アプリケーションが誕生しました。これらをクラウドの弾力性とうまく組み合わせることで、クラウドの効率と価値を最大化できます。

SaaS モデルで提供され、顧客がアクセスできるマイクロサービスであるため、独立して変更、更新、反復できます。複数のマイクロサービスが互いに干渉することはありません。全体的には、疎結合アーキテクチャです。これは、マイクロサービスの特性とコンテナ技術の利点が互いに補完し合い、コンテナ化がマイクロサービスの成長と発展の温床となっていることを示しています。

企業がクラウドネイティブ改革を進めたい場合、技術的な観点だけで始めるだけでは不十分です。企業の開発チーム、運用チーム、保守チームは、アプリケーションをより迅速かつ効率的に構築および展開するために、複数の変更を同時に行う必要があります。 DevOps の原則と文化的価値に真に従い、さまざまなアクティビティ、テクノロジー、チーム、プロセスを考慮することで、企業は最終的にウォーターフォール リリースから継続的リリースへの前向きな移行を実現できます。

三つ

最後の質問は、企業がクラウドネイティブ改革を計画している期間中、どの特定のトラックの方が優先度が高いのでしょうか? iResearch は、ハードウェア アーキテクチャの異質性が深刻で、プラットフォームの更新と柔軟な拡張に対する需要が高いため、財務トラックを最優先にすべきであると結論付けました。これには多くの理由があります。

まず、過去 20 年間にわたり、金融機関はハードウェア アーキテクチャのアップグレードと改修を何度も実施してきました。異種のハードウェア デバイスを連続して使用すると、システム内のリソースの異種性が著しく高まり、リソースの利用効率が制限されます。コンテナ クラウドは、ネットワークやデバイス全体にわたるノード管理を実現し、その強力な互換性により、金融機関は開発、テスト、生産、情報管理環境をより適切に調整できるようになります。

第二に、クラウド ネイティブは、金融業界における金融商品の取引の集中によって引き起こされる同時シナリオの不均衡を効果的に解決できます。金融機関が集中的な購入と集中的な取引の高頻度かつ高同時性のシナリオを経験することは容易に想像でき、容量拡張の問題を回避することは困難です。クラウドネイティブの柔軟な容量拡張により、金融会社の容量拡張コストを最小限に抑えながら、ピーク効果と谷効果によって引き起こされる変動に対応できます。

全体として、クラウドネイティブ システムの利点は疑う余地がありません。

基盤技術の観点から見ると、クラウド ネイティブはクラウドの設計概念を継承しており、クラウド アーキテクチャに適しています。クラウドコンピューティングが比較的成熟した今日、クラウドネイティブは、5G、人工知能、クラウドエッジエンドコラボレーションなどの新興技術と組み合わされ、デジタル変革をサポートするテクノロジーシステムの重要な基盤の1つにもなります。

アプリケーション価値の観点から見ると、ピークバレー効果の効果的な緩和、マイクロサービスエクスペリエンスの向上、統合開発運用文化の形成はすべて、金融業界におけるクラウドネイティブシステムのさらなる発展の現れとなるでしょう。