1.ナチュラルクラウドネイティブサーバーレス
1.クラウドネイティブ時代
2013年にDocker、CNCF Foundation、K8sに代表されるコンテナテクノロジーが開発されたことで、クラウドネイティブが開発者に知られるようになりました。クラウドネイティブ時代の前には2つの段階があります。1つはIDCコンピュータールームを自分で構築することであり、もう1つは元のアプリケーションを単にクラウドに再配置することです。自作のIDCコンピュータルームでは、高可用性、高スケーラビリティ、運用および保守効率を実現することは困難です。第2段階は、IDCと比較してある程度の進歩を遂げたクラウドコンピューティングの時代ですが、それらのほとんどはまだ比較的原始的。、クラウドを有効に活用することは難しい。この段階でのリソースはほぼ無制限ですが、仮想マシンとさまざまな自作サービスに基づく方法を改善する必要があります。
クラウドネイティブ時代とは、アプリケーションが将来クラウド環境で実行されることを考慮し、クラウドサービスの柔軟性や分散型の利点など、クラウドリソースの利点を最大限に活用したアプリケーションの設計を指します。上の図に示すように、クラウドネイティブはいくつかの部分に分けることができます。
1つは、コンテナー、K8、マイクロサービス、DevOpsなどのクラウドネイティブテクノロジーです。そして、これらのテクノロジーは単なるツールです。これらのテクノロジーを真に使用するには、いくつかのベストプラクティスと組み合わせ、つまりクラウドネイティブアーキテクチャが必要です。
クラウドネイティブアーキテクチャは、クラウドネイティブテクノロジーに基づくアーキテクチャの原則とデザインパターンのコレクションです。これは、可観測性などの一連の指針です。可観測性が実行できる場合にのみ、高い可用性を含むフォローアップの柔軟性を実現できます。関連する構築とインフラストラクチャの沈下により、非ビジネスコードの除去を最大化することを望んでいます。このようなテクノロジーとアーキテクチャ設計の指導の下で、クラウドネイティブアプリケーションを設計できます。
クラウドネイティブアプリケーションは、軽量、俊敏性、高度な自動化という特徴を備えており、クラウドの利点を十分に活用し、ビジネス開発や現代のデジタルトランスフォーメーションの時代の変化によりよく適応できます。
2.サーバーレスナチュラルクラウドネイティブ
サーバーレスがクラウドにネイティブであるのはなぜですか？サーバーレスはクラウドネイティブよりも早く登場しましたが、私たちは戻ってきました。AWSは、第1世代のサーバーレス製品であるLambdaの立ち上げを主導しました。ラムダは、リクエストに応じて課金するという特徴と、クラウドネイティブなどの定義に非常に一致しています。インフラストラクチャシンクとして。Lambdaでは、サーバーを管理する必要はありません。要求に応じてサーバーをスケーリングし、高度な自動化を実現します。また、コードを関数の形式で整理し、関数はアプリケーションやアプリケーションよりも軽量です。配信速度が速くなります。ただし、このモデルの欠点は、変換のコストが高いことです。これは、多くのアプリケーションが元々巨大なモノリシックまたはマイクロサービスアプリケーションであり、機能モデルに変換することが難しいためです。
3.SAEを知る
サーバーレスのコンセプトと関連製品は、ほぼ7年間発売されています。この過程で、Docker、K8sなどのクラウドネイティブテクノロジーも成熟しています。Alibaba Cloudは、2018年にサーバーレスの別の形式であるSAE製品であるサーバーレスアプリケーションについて考え始めました。9月18日に発売され、19年に商品化され、3年になります。
SAEの機能：
- 不変のインフラストラクチャ、監視可能な自動リカバリ
K8sベースに基づいて、その背後にはミラーリングなどの不変のインフラストラクチャと、監視可能で自動のリカバリがあります。リクエストの失敗が検出されると、ストリームが自動的に切断されるか、インスタンスが再起動されます。
- 無料の操作とメンテナンス、極端な柔軟性、極端なコスト
サーバーリソースをホストすることは、ユーザーがサーバーを自分で操作および保守する必要がないと同時に、非常に柔軟で非常に費用対効果の高い機能も備えています。
- 使いやすく、0変換、統合
上の図に示すように、最上層はaPaaS製品フォームである顧客認識層です。これはアプリケーションPaaSです。3年以上の実践を経て、最終的にユーザーを本当に使いやすくし、ゼロ変換、そしてそれは多くの統合された統合を行いました。
サーバーレスの特徴とaPaaSの形式を備えたK8sをベースにした製品であるSAEは、クラウドネイティブの特徴と完全に一致しています。技術レベルでは、最下層はコンテナーK8を使用し、さまざまなDevOpsツールを含むマイクロサービスを統合します。アーキテクチャレベルでは、最下層がこれらのテクノロジーに依存しているため、ユーザーがクラウドネイティブアーキテクチャの原則に従って独自のアプリケーションプラクティスを設計し、最終的に顧客のアプリケーションがクラウドネイティブのメリットを最大化できるようにするのは非常に便利です。 。軽量で機敏で高度に自動化されたアプリケーションは、クラウドネイティブ時代への参入の障壁を大幅に軽減します。
SAE製品アーキテクチャ図
SAEはアプリケーション指向のサーバーレスPaaSです。0トランスフォーメーション、0しきい値、0コンテナファンデーションがその特徴であり、ユーザーはサーバーレス、K8、およびマイクロサービスによってもたらされる技術的なメリットを簡単に享受できます。同時に、複数のマイクロサービスフレームワーク、複数のデプロイメントチャネル（独自の製品のUIデプロイメント/クラウドエフェクト/ Jenkins /プラグインデプロイメントなどを含む）、および複数のデプロイメント方法（War / Jar /イメージデプロイメントを含む）もサポートします。など）。
最下層はIaaSリソース層であり、最上層はK8sクラスターです。これらはユーザーに対して透過的です。サーバーを自分で購入する必要はなく、K8を理解する必要もありません。次の層には2つのコアがあります。機能：1つはアプリケーションホスティング、2つ目はマイクロサービスガバナンスです。アプリケーションホスティングはアプリケーションのライフサイクルです。マイクロサービスガバナンスはサービスの検出と適切なオフラインです。これらはすべてSAEに適切に統合されています。
SAEのコア機能は、3つに要約できます。1つは0コード変換、もう1つは15秒の弾性効率、3つ目は57％のコスト削減と効率改善です。
2.SAEの設計コンセプト
1.Kubernetesベース
- 容器
K8sコンテナオーケストレーションエコロジーでは、最も基本的なのはコンテナまたはイメージです。イメージに依存することで、ユーザーは不変のインフラストラクチャを実装することに相当します。利点は、イメージをどこにでも配布およびコピーできることです。これは、移植性を実現することと同等です。 。ベンダーは拘束されています。さらに、ミラーリングに慣れていないユーザーや複雑さを感じたくないユーザーのために、War / Jarレベルのデプロイメントも提供します。これにより、ユーザーがボーナスを享受するためのしきい値が大幅に削減されます。
- エンド指向
従来の運用・保守分野では、さまざまな理由でサーバーの負荷やCPUが急に高くなるなど、解決が難しい問題が多く、現在、手動や保守の操作が多くなっています。通常、従来の分野で必要です。観察とヘルスチェックでは、自動化された操作とメンテナンスを実現するために、活性と準備を構成するだけで済みます。K8sは自動的にフローをカットし、自動的にスケジュールを変更するため、操作とメンテナンスのコストが大幅に削減されます。
- リソースホスティング
ECSマシンだけでなく、K8sも内部で管理されます。お客様は、サーバーやK8sを購入したり、K8sを運用および保守したり、K8sを理解したりする必要がないため、エントリーのしきい値と給与負担が大幅に軽減されます。
2.サーバーレス機能
- 非常に高い柔軟性
エンドツーエンドの15秒を達成しました。つまり、ポッドを15秒以内に作成し、ユーザーのアプリケーションを起動できます。柔軟性に関しては、基本的なインデックスの柔軟性（CPU、メモリなど）、ビジネスインデックスの条件の柔軟性（QPS、RTなど）、およびタイミングの柔軟性があります。弾力性指数を手動で設定した場合でも、設定する量がわからないため、しきい値や負担があります。このため、スマート弾力性も考慮し、ユーザーが弾力性指数を自動的に計算して推奨するようにしています。しきい値をさらに下げるためにユーザーにそれを。
- リーンコスト
SAEは、リソースのホスティングと運用および保守のコストを排除します。それ以前は、お客様は多数のECSサーバーを運用および保守する必要がありました。セキュリティのアップグレードとバグ修正が必要な場合、特に高密度の展開では、コストが高くなります。また、SAE課金モデルは分単位課金であり、ユーザーは無駄のないコストを十分に実現できます。たとえば、営業時間のピーク時に容量を10インスタンスに拡張し、ピーク後に2インスタンスになります。
- 言語の強化
柔軟性の分野では、ターゲットを絞った言語の機能強化をいくつか行いました。たとえば、JavaをAliの大規模なJavaアプリケーションプラクティスであるAliのJDKであるDragonwell11と組み合わせると、他のオープンソースJDKと比較してJavaアプリケーションの起動速度を40％向上させることができます。将来的には、他の言語でより多くの可能性を探求します。
3.（アプリケーション）PaaS製品フォーム
- アプリケーションホスティング
アプリケーションホスティングは、アプリケーションのリリース、再起動、拡張、グレーリリースなどを含むアプリケーションライフサイクルの管理に相当します。使用されるメンタリティは、アプリケーションまたは他のPaaSプラットフォームを使用するすべての人と同じであり、開始のしきい値は次のとおりです。とても低い。
- オールインワン統合
クラウド製品は数百を超えるため、それぞれを上手に使いたい場合は、追加料金がかかります。そのため、基本的な監視、ビジネス監視ARMS、NASストレージ、SLSログ収集など、最も一般的に使用されるクラウドサービスを統合して、ユーザーが製品を使用するためのしきい値を下げました。
さらに、ホスティングレジストリ、エレガントなオンラインとオフライン、マイクロサービスガバナンスなど、追加のマイクロサービスの機能強化を行いました。マイクロサービスの使用には通常レジストリが必要であり、SAEにはホスティングレジストリが組み込まれているため、ユーザーは再購入する必要がなく、アプリケーションを直接登録できるため、ユーザーのしきい値とコストがさらに削減されます。
SAEはこれらの機能を組み合わせて、ユーザーが従来のモノリシックアプリケーションまたはマイクロサービスアプリケーションを移行するときに基本的にゼロの変換と移行を実現し、ゼロのしきい値でこの製品の背後にある技術的な利益を享受できるようにします。
3.SAE技術アーキテクチャ
1.SAE技術アーキテクチャ図
上の図に、SAEによるユーザー向けのK8のホスティングの背後にある技術アーキテクチャを示します。ホストでは、最上位層がSAE PaaSインターフェース、2番目の層がK8sマスター（APIサーバーなどを含む）、最下層がリソースを実行するK8sの実際のホストはSAEによって完全に管理されます。ユーザーは、独自のVPCまたはネットワークセグメントでポッドリソースを作成し、接続を確立するだけで、アプリケーションの通常の操作を実現できます。
ここには2つの主要な問題があります。
1つ目は侵入防止です。たとえば、ポッドまたはコンテナはDockerなどの従来のコンテナテクノロジーを使用しています。パブリッククラウドaとbの2人のユーザーは物理マシンに実行されます。実際、セキュリティリスクは非常に高くなります。ユーザーbは非常にユーザーのコンテナに侵入してユーザー情報を取得する可能性があるため、これの核心はユーザーの能力を制限し、それが逃げるのを防ぐことです。
2つ目は、ネットワークの接続またはクラウドシステムの接続です。ユーザーがセキュリティグループ、セキュリティルール、RDSなどに簡単に接続できるように、ユーザーのネットワークシステムに接続する必要があります。これも重要な問題です。 。
2.安全な容器
これがアンチエスケープの特定の問題です。上記の表は、より広く議論されているセキュアコンテナテクノロジーです。セキュアコンテナの簡単な理解は、仮想マシンの概念です。Dockerのような従来のコンテナ化テクノロジーを使用する場合、セキュリティの保護や分離を行うことは困難であり、安全なコンテナは、コンテナの起動速度と仮想マシンのセキュリティの両方を備えた軽量の仮想マシンとして理解できます。
現在、セキュリティコンテナはセキュリティを超えています。セキュリティ分離だけでなく、パフォーマンス分離と障害分離もあります。例として障害分離を取り上げます。コンテナテクノロジとしてDockerを使用すると、カーネルの問題が発生する可能性があります。障害Dockerコンテナの使用は他のユーザーに影響を及ぼし、ホストマシン全体に影響を与える可能性があります。セキュアコンテナテクノロジを採用すれば、そのような問題は発生しません。
SAEはKataセキュアコンテナテクノロジーを使用しています。オープンソースの世界での時間と事実から、KataはrunVとClear Containerの組み合わせであり、FirecrackerやgVisorよりも成熟しています。
第4に、SAEのベストプラクティス
ベストプラクティス1：低しきい値のマイクロサービスアーキテクチャの変換
マイクロサービスに精通しているお客様は、一連のマイクロサービス技術アーキテクチャを自分で運用および保守する場合は、オープンソース、フレームワークレベルだけでなく、リソースレベル、およびレジストリ、リンクなどのフォローアップトラブルシューティングも考慮する必要があることを知っています。上の図の左側に示されているように、従来の開発モデルでは、追跡、監視、サービス管理などの機能を使用するには、ユーザーが自分でホストして操作する必要があります。
SAEでは、ユーザーはビジネスに関係のない一部の機能をSAEに引き渡すことができます。ユーザーは、マイクロサービスユーザーセンターやグループセンターなど、自分のビジネスに注意を払い、SAEのCI / CDツールであるYouと統合するだけで済みます。マイクロサービスアーキテクチャを迅速に実装できます。
ベストプラクティス2：コストを削減し、効率を高めるためのワンクリックのスタートストップ開発およびテスト環境
一部の中規模および大規模企業には複数のテスト環境があります。これらのテスト環境は通常、夜間には使用されません。ECSモードでは、これらのアプリケーションインスタンスを長期間保持する必要があり、アイドル廃棄物のコストは比較的高くなります。
また、ワンクリックの開始停止機能やスケジュールされた開始停止機能など、SAEで名前空間を組み合わせることができる場合は、テスト環境の名前空間の下にテスト環境のすべてのアプリケーションを構築してから、テストの名前を構成できます。午前8時に開始する環境。スペースのすべてのインスタンスは夕方の8時に停止され、停止後の期間は課金されないため、ユーザーはコストを最小限に抑えることができます。
計算によると、極端な場合、基本的にユーザーのハードウェアコストの2/3を節約でき、追加の運用および保守コストを支払う必要はなく、タイミングの開始ルールと停止ルールを構成するだけです。
ベストプラクティス3：正確な容量+非常に柔軟なソリューション
今年の流行の状況では、多くの学生が自宅でオンライン教育を行っており、オンライン教育業界の多くの顧客は、ビジネストラフィックの7〜8倍の増加に直面しています。彼らが元のECSアーキテクチャに基づいている場合独自の運用と保守を行うため、ユーザーは非常に短時間でアーキテクチャを構築する必要があります。アップグレードは、運用と保守のアーキテクチャのアップグレードであるだけでなく、アプリケーションアーキテクチャのアップグレードでもあります。これは、ユーザーにとって非常に大きな課題です。コストとエネルギー。
また、SAEのさまざまな統合統合と、基盤となるK8などの高度に自動化されたプラットフォームに依存している場合は、はるかに簡単になります。たとえば、PTS圧縮ツールを使用して容量レベルを評価できます。圧力測定に問題がある場合は、基本的な監視と、コールチェーン、診断レポートなどを含むアプリケーション監視を組み合わせて、ボトルネックの場所を分析できます。は、最短時間で解決できるかどうか、見つかった場合は解決が難しいボトルネックです。アプリケーションの高可用性サービスを使用して、現在の制限とダウングレードを実現し、次の理由でビジネスが崩壊しないようにすることができます。突然の洪水。
最後に、SAEは、CPUメモリ、RT、QPSなどのストレステストモデルに従って対応するエラスティック戦略を構成し、実際の使用に非常に適した効果を達成するための容量モデルがある場合に業界戦略を設定できます。低コストとアーキテクチャを実現最大アップグレード。
五数要約
デジタルトランスフォーメーションはあらゆる分野に浸透してきました。時間の経過によるものであれ、流行によるものであれ、デジタルトランスフォーメーションでは、企業はクラウドを使用してビジネスの急速な変化や高ピークと高の課題に対処する能力を備えている必要があります。トラフィックシナリオ。このプロセスは、リホスト（新しいホスティング）、リプラットフォーム（新しいプラットフォーム）、リファクター（新しいアーキテクチャ）のいくつかの段階で構成されます。アーキテクチャの変革が深まるにつれて、企業が取得できるクラウドの価値は高くなります。 、および移行と変換のコスト。それに応じて上昇します。アプリケーションが単にクラウド上でホストされている場合、クラウドの弾力性を取得することは困難であり、時間内に問題に対処することは依然として困難です。
SAEを通じて、ユーザーがサーバーレス+ K8 +マイクロサービスの価値の配当を享受し、変換、しきい値、コンテナの基盤が0になり、最終的にユーザーがビジネス上の課題に直面するのを支援できることを願っています。
著者|タオチェン（ビシャン）
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。