クラウドコンピューティングの開発モデル、投資モデル、運用保守モデル

著者 |王志成

この記事は主に企業の意思決定者を対象としています。私はこの主題を簡単な言葉と明確な例で表現するよう努めます。

2022年、「クラウド」はもはや流行語ではなく、水や電気と同じくらい一般的なインフラになっているようです。しかし、テクノロジーの太陽の光が世界の隅々まで照らすには程遠い。あなたもその一人ですか？

今日では、クラウドはもはや目新しいものではなく、誇大宣伝は終わり、不安も静まっています。今こそ一般企業もそれに倣うべき時だ。

シニア ソフトウェア エンジニアとして、この記事が皆さんのクラウドへの移行に役立つことを願っています。

近年、「クラウド」という言葉に関する情報が氾濫していますが、クラウドにどう到達するかについて真剣に考えたことはありますか?クラウドベースの開発および運用モデルと従来のソリューションの違いは何ですか?これらを理解しなければ、クラウドへの移行は単なる盲目的な追随になってしまいます。その価値を十分に理解することはできず、挫折に遭遇したときに、継続するか損失を抑えるかを賢明に判断することもできなくなります。

クラウドを完全に理解するには、クラウドが企業の IT モデルに与える影響をいくつかの観点から検討する必要があります。

1. 新しい開発モデル

クラウド プラットフォームの出現は開発モデルに大きな影響を与えました。テクノロジーの選択、システム アーキテクチャ、R&D 組織構造、インフラストラクチャなど、クラウド コンピューティングに備える必要があります。

マイクロサービス

クラウド アプリケーションの場合、マイクロサービスはほぼ必然的な選択です。クラウド プラットフォームの基本機能の 1 つは、コンピューティング リソース (CPU、メモリなど) を動的に割り当てることです。

アプリケーションのさまざまな部分には、さまざまなコンピューティング リソースが必要であることはわかっています。たとえば、「商品の表示」機能の使用頻度は通常、「注文の支払い」機能の使用頻度よりもはるかに高くなります。従来のアプローチを使用してすべての機能を 1 つの実行ユニット (つまりモノリシック アプリケーション) に配置する場合、これを実現する唯一の方法は全体の容量を拡張すること (複数のコピーを作成して負荷を分散する) であり、大量のコンピューティング リソースが浪費されます。マイクロサービス テクノロジーは、使用頻度の異なる機能を異なる動作単位に分割することができ、各単位はマイクロサービスと呼ばれます。たとえば、「製品を表示」機能を頻繁に使用する場合は、その機能が配置されている実行ユニットの容量を拡張するだけで済みます。使用頻度が減ったら、不要になった実行ユニットを解放し、コンピューティング リソースをリソース プールに戻すことができます。

しかし、マイクロサービスには対応する技術的準備も必要です。

マイクロサービスとアーキテクチャ

マイクロサービスを実装するために、最初に解決しなければならない問題は、システム アーキテクチャをどのように合理的に設計するかということです。 「拡張を容易にする」という目的でアーキテクチャを設計するのは自然な考えですが、それだけでは十分ではありません。 「拡張が容易」とは、アーキテクチャ設計用語では「スケーラビリティ」または「弾力性」と呼ばれます。アーキテクチャ設計では、アーキテクチャのさまざまな属性間で常に一定のトレードオフを行う必要があり、スケーラビリティも例外ではありません。アーキテクチャ内のモジュールの弾性境界を決定するための、より自然で科学的な方法を見つける必要があります。

一般的に、長期プロジェクトの場合、拡張性（つまり、新しい機能を追加する容易さ）は延性よりも高くなります。前者のコストは主にプログラマーにかかるのに対し、後者のコストは主にハードウェア プラットフォームにかかるためです。両者が矛盾する場合、スケーラビリティが、投資したリソースの量に関係なく効果がない段階に達していない限り、プログラマーの人的コストは依然として高くなります。

したがって、アーキテクチャ設計ではスケーラビリティを優先し、スケーラビリティが要件を満たすという前提でスケーラビリティのローカル最適化を行うという原則に従うことができます。たとえば、まずスケーラビリティを重視した第 1 レベル モジュールを設計し、次にこの第 1 レベル モジュールの中で弾力性要件が高い部分を見つけて、それらを第 2 レベル モジュールに個別に抽出します。

では、スケーラビリティを重視したアーキテクチャ設計を実現するにはどうすればよいでしょうか?

まず、「拡張」の起源、つまりシステムを拡張する必要がある理由を理解する必要があります。最も単純かつ直接的な答えは、「ビジネスニーズが変化したため」です。そこで、私たちは「ビジネスとそのドメイン知識の現状と発展傾向を含め、ビジネスとそのドメイン知識を完全に理解する」という前提を得ました。

では、「拡大」のコストはどこから来るのかをしっかり考える必要があるのではないでしょうか。スケーリングはなぜコストがかかるのでしょうか?技術と管理の 2 つの要素があります。

技術的な観点から見ると、ビジネス要件が変更された場合、既存のコードを調整する必要があります。この種の調整は、設計、開発、テスト、展開に必要な作業量が比較的少なくなるように、より狭い範囲に焦点を当てるのが最適です。この「より狭い範囲」は、1 つまたは少数のマイクロサービスに焦点を当てるのが最適です。もちろん、大きすぎるマイクロサービスを設計しないでください。変更が加えられたときに、無関係なコードの多くが強制的に「バインド」されることになります。

管理の観点から、ビジネス要件が変更された場合、関連する開発チームとのコミュニケーションが必要になります。開発プロセス中、これらの開発チームは互いにコミュニケーションを取る必要があり、これらのコミュニケーションには追加コストがかかります。チーム間で大量のコミュニケーションを行う必要がある場合、これらのコストは非線形に増加します。

したがって、技術的な観点と管理的な観点の両方から、ビジネス自体の本質的なアーキテクチャに沿ったアーキテクチャを取得する必要があります。このように、ビジネスの変更がローカルでのみ発生する限り、コードの調整もローカルでのみ発生し、チームへの影響もローカルでのみ発生します。

したがって、問題は「ビジネス自体の本質的なアーキテクチャをいかに正確に理解し、表現するか」という 1 つに集約されます。答えは簡単です。「専門家に任せましょう。」ドメイン エキスパートがビジネス独自のドメイン知識を特定して表現し、このドメイン知識からその固有のアーキテクチャを抽出できるようにします。

アーキテクチャ、DDD、進化型アーキテクチャ

しかし、単純な答えは複雑な行動を意味する場合がよくあります。ドメイン エキスパートは、それぞれのビジネス分野の専門家であることは確かですが、多くの場合、ビジネス分野のごく一部しか理解していません。複数のドメイン専門家の知識を統合することは大きな課題です。たとえ統合できたとしても、それをドメイン モデルを通じて正確かつ包括的に表現する方法が、より大きな課題となります。なぜなら、ビジネスの専門家は必ずしも論理的思考力が優れているわけではないからです。特別なトレーニングがなければ、大規模なドメイン知識はおろか、複雑なドメイン知識を習得して表現することは困難です。それで、もっと大きな問題があるのでしょうか?持っている！それは、このドメインモデルを長期間維持することです。

最初の 2 つの質問に対する答えは、最近人気の DDD である「ドメイン駆動設計」です。そして最後の質問の答えは「進化型アーキテクチャ」です。

「ドメイン駆動設計」の基本的な考え方は、ビジネスドメインの専門家とソフトウェア技術アーキテクトが共同でドメイン知識を整理し、開発チームのメンバーが理解しやすいドメインモデルを確立することです。進化型アーキテクチャでは、アーキテクチャは静的で変化しない製品として捉えるべきではなく、1 つのステップで達成されるべきではないことを強調しています。代わりに、アーキテクチャ上の問題を早期に発見し、アーキテクチャ上の問題の発見と修正にかかるコストを削減するために、さまざまな手段で監視および保護する必要があります。

これら 2 つのトピックは非常に広範囲にわたるため、ここでは詳細には触れません。興味のある人は自分でさらに調査することができます。

2. 新しい投資モデル

クラウド エコシステムでは、従量課金モデルが広く採用されています。このモデルでは、基本的に初期投資はほとんど必要ありません。ユーザー数が少ない場合はリソースを少なく購入し、ユーザー規模が大きくなるにつれて徐々に投資を増やしていきます。これにより、新しいビジネス アプリケーションの試用にかかるコストとリスクが削減されます。

従量課金制は通常、次の 3 つのサブモデルに分けられます。

従量課金モデル

このモデルは非常にシンプルです。使用するたびに料金が発生し、いつでも充電を停止できます。通常、時間または秒レベルの精度です (リソースの種類によって異なります)。ただし、トラフィックなどのリソースは特別です。オンデマンド課金は時間や秒ではなく、実際のトラフィックに基づいて課金されます。

ただし、リソースごとに非アクティブ化基準が異なることに注意してください。たとえば、ECS（仮想マシンに相当）を停止すると、CPU、メモリなどの課金も停止します。ただし、マウントされたクラウド ハードディスク、IP アドレス、年間および月間帯域幅などは引き続き課金されます。これらを解除するには、明示的に非アクティブ化する必要があります。

さらに、運用コストが異なるため、アベイラビリティーゾーンは課金や提供されるサービスにも大きな影響を及ぼします。一般的に、開発地域のアベイラビリティ ゾーンは高価ですが、遠隔地のアベイラビリティ ゾーンは安価です。具体的な選択は多くの要因によって決まります。必要に応じて、最初に速度テストを実行できます。

オンデマンド課金は小売モデルに似ているため、通常、単位料金が最も高く、1 か月未満の実験的なプロジェクトにのみ適しています。

年間および月間サブスクリプションモデル

これは従量課金制の卸売モデルに相当します。オンデマンド課金に基づいて、年間および月間パッケージ モデルでは追加の割引が提供されます。

ただし、年間および月間パッケージのトラフィックは、最大帯域幅レベルに基づいて月ごとおよび年ごとに課金されることに注意してください。トラフィックが非常に少ないアプリケーションの場合、この方法の実際のコストは従量課金モデルよりも高くなります。したがって、トラフィックが非常に少ないアプリケーションの場合、長期間運用する場合でも、従量課金制のトラフィック モデルを選択する必要がある場合があります。もちろん、ほとんどのアプリケーションでは、年間または月間パッケージの方がオンデマンドで支払うよりも常に安くなります。

クラウド プラットフォームでは、通常、年間および月間サブスクリプション モデルと従量課金支払いモデルは相互に変換可能であるため、初めて選択するときに躊躇する必要はありません。コストの差はそれほど大きくなく、そのためにビジネス チャンスを遅らせる価値はありません。

入札課金モデル

これはアイドルリソースオークションモデルです。スポット価格を選択した場合、入札額は実際の入札額ではなく、インスタンスを予約するために支払う最高額になります。プラットフォームは入札者を入札価格で定期的に分類し、順番にリソース使用権を割り当てます。使用権が割り当てられていないものは、プラットフォームによって自動的に解放されます。

これは不確実性を利益と交換することを意味します。したがって、適用可能なシナリオは最初の 2 つのモードとは大きく異なります。入札課金モデルは通常、緊急でない統計レポートの生成など、いつでも開始および停止できるバッチ処理タスクに使用されます。クラウドプラットフォームでは、入札課金の単価がオンデマンド課金モデルを超えないように保証しておりますので、安心してお試しいただけます。

例

Huawei CloudのECSサービスの引用を例に挙げます（2022-12-06）：

中国北部の「ウランチャブ」エリアで c7.large.2 構成 (2vCPU、4GiB のメモリ、CPU モデル Intel Ice Lake、最大帯域幅 4 Gbit/s) を選択した場合、月額パッケージの料金は 184.95 元/月、年間パッケージの料金は 2,129.50 元/年となり、425.90 元の割引に相当します。

従量課金モデルを選択した場合、料金は1時間あたり0.4238元です。月（30日基準）に換算すると、305.136元となります。つまり、オンデマンド支払いが18日を超える限り、料金は月額パッケージと同じになります。

Huawei Cloudの「北京4区」は入札課金モデルを開設し、現在の市場価格に自動的に一致する自動入札モデルをサポートしています。通常、自動入札の方がコスト効率が高いため、そうでなければユーザーはそれを選択しないでしょう。もちろん、経験を積むにつれて、サービス中断に対する許容度に基づいて独自の入札価格を設定し、「ちょうどよい」入札レベルに到達するのが最善です。

3. 新しい運用・保守モデル

クラウド プラットフォームは、サーバーやネットワークなどのインフラストラクチャの運用と保守を完了するのに役立ちます。この集中的な運用保守方法により、すべてのハードウェア運用保守作業と、ほとんどのシステム運用保守作業を削減できます。しかし、アプリケーション層の運用・保守は運用・保守担当者自身でしか行うことができません。

幸いなことに、ほとんどのクラウド プラットフォームは、アプリケーションの運用および保守プラットフォームを提供しています。例えば、Huawei Cloudは「アプリケーション管理および運用保守プラットフォームServiceStage」を提供しており、アプリケーションの開発、構築、リリース、監視、運用保守をワンストップで実現するソリューションを提供しています。運用・保守作業が重い場合は、オンデマンドでこのサービスを購入することを検討してください。

予算が限られている場合は、オープンソース ソフトウェアに基づいて自分で構築することを検討できます。一部のプラットフォーム (Huawei Cloud CCE など) ではプラグインが提供されています。例えば：

• ELK を使用してログの収集と分析をサポートします。ログを通じて、アプリケーションの動作状況を分析し、エラーの特定と診断、潜在的な脅威の特定などを行うことができます。
• Prometheus を使用して、システムとアプリケーションの運用および保守データを監視および警告し、特定の運用および保守イベントの自動処理をトリガーします。
• Grafana を使用して運用および保守の監視データを視覚化することで、関係者が運用および保守の問題を直感的に発見し、さまざまなレベルの人的介入を積極的に提供できるようになります。

これらのソフトウェアは通常組み合わせて使用​​されますが、誰かによって保守される必要があり、その完全性はまだ理想的ではなく、運用および保守データのマイニングは十分に深くありません。

アプリケーション システムがより複雑な場合、これらの一般的なアプリケーション運用および保守プラットフォームに依存することはできません。代わりに、アプリケーション システムの初期設計に固有の運用および保守要件を直接組み込む必要があります。オープンソース ソリューションの場合、高度なカスタマイズが可能になりますが、要求される技術レベルは通常高くなります。クラウド プラットフォーム ソリューションの場合、特殊な API カプセル化によりカスタマイズは通常より簡単になりますが、深さは制限されます。

4. 予想外の道

クラウド プラットフォームの重要性は、従来の開発方法やインフラストラクチャを置き換えるだけでなく、想像もできなかった多くの道を切り開くことです。例えば：

独自のデータベースを構築する代わりに、クラウド プラットフォームが提供するデータベース サービスを直接使用できます。このように、データベース自体の運用・保守もクラウドプラットフォームによって「一元化」されます。

トラフィックの変動が大きいシステムの場合、最大トラフィックに基づいてメッセージ キューを構築する必要はありません。代わりに、この容量の一部はクラウド プラットフォームによって均一に割り当てられます。

人工知能のような「新興」技術の場合、自分で構築して運用する必要はありません。代わりに、クラウド プラットフォームにインフラストラクチャの構築を任せ、アプリケーション層の開発のみを行う必要があります。アプリケーション層のコーディングを行う必要すらありません。代わりに、ビジネス エキスパートは、クラウド プラットフォームが提供する視覚化ツールを直接使用して、分析と予測を実行できます。

このモデルは PaaS (Platform as a Service) と呼ばれます。

中小企業の中には、独自のアプリケーションソフトウェアを構築せず、クラウドプラットフォームが提供するCRMなどのオンラインソフトウェアを利用し、その中でテナントを開設するだけで済むケースもあります。ただし、商業上の機密データが関係する場合は、ソフトウェア オペレーターによってデータが漏洩しないように、信頼できるプロバイダーを見つける必要があります。非専門家のユーザーがオペレーターの信頼性を判断するのは難しく、オペレーターの評判と運用実績に頼るしかありません。

ただし、中小企業の場合、非常に特殊なケースでない限り、通常、データ漏洩について早期に心配する必要はありません。一定のレベルまで成長すると、ソフトウェア プロバイダーに料金を支払ってプライベート展開を実施し、運用を完全に制御できるようになります。プライベートシステムをゼロから開発することもできます。

このモデルは SaaS (Software as a Service) と呼ばれます。

さらに、より過激な FaaS (Function as a Service) モデルもあります。このモードでは、アプリケーション開発者はデプロイメント、運用、保守などの詳細を気にする必要がなく、ビジネス ロジックのみを気にすればよいことになります。ただし、この分野の機能と方法論システムは、IaaS、SaaS、PaaS ほど成熟していません。したがって、ある程度の技術的余裕はありますが、実装には慎重な評価が必要です。

V. 結論

この記事は、クラウドがビジネスに与える影響を示すにはほど遠く、クラウドがどのような新しい興味深い方法で使用されるかを判断することすら不可能です。前のセクションで述べたように、クラウドはビジネスとテクノロジーの両面で、想像もできなかった道を示してきました。あなたは新たな道の先駆者になりませんか？待って見てみましょう！