How can SMEs effectively respond to the elastic change demand of computing resources?
コンピューティングステージの発展の歴史
古代
大昔、コンピューターは極めて希少なリソースでした。ある大学の教授から聞いた話ですが、当初は大学のコンピューター学科にコンピューターが 1 台しかなかったそうです。コンピューターは非常に希少で、お金があっても簡単に手に入るものではありませんでした。
この時代を、私はコンピューティングリソースの「古代」と呼びたいと思います。その特徴はずばり希少性です。
中世
私は大学を卒業した後、ある大手国有商業銀行に入行し、情報技術の業務に従事しました。初めてサーバー室に入ったとき、ずらりと並ぶサーバーの列に圧倒されました。サーバーのランプがちらちらと点滅するのを見て、これらが数十億、数百億、数兆規模の資金の流れを支えているのだと想像しました。
それらのサーバーは巨大で、強力で、安定していました。しかし、非常に高価でした。購入費用が高いだけでなく、これらの大型サーバーを正常に稼働させるためには、サーバー室や運用保守スタッフのコストもかさみます。大企業ならともかく、中小企業には手が届きません。
この時代を、私はコンピューティングリソースの「中世」と呼びたいと思います。その特徴はずばり高コストです。
近代
2018 年に民間企業に入社すると、ほとんどの企業が ECS を使っていることがわかりました。ECS の利点は、デプロイするプログラムのアクセスが多く、高い同時実行数と大量のデータを処理する場合は、高スペックで高価格な構成を購入でき、プログラムがシンプルでアクセスが少ない場合は、低スペックで低価格な構成を選べることです。
さらに、時間の経過とともにアクセスが大幅に増加した場合、費用をかけて構成をスペックアップすることもできます。また、ECS を使えば専用データセンターを構築する必要がなく、ハードウェアルーターやファイアウォールを購入する必要もないため、コスト面でも手頃です。こうして中堅・中小企業は ECS を積極的に導入するようになりました。在職中、私は数十台の ECS サーバーを管理し、毎年数台ずつ追加していました。
この時代を、私はコンピューティングリソースの「近代」と呼びたいと思います。その特徴は高いコストパフォーマンスです。
現代
実は、業務を進める中でずっと気づいていたことがあります。それは、コンピューティングリソースへの需要は時間的・空間的に不均衡だということです。
たとえば、学校の決済システムを開発した場合、普段はほとんどアクセスがありません。しかし学校から請求書が送付される時期になると、システムへのアクセスが殺到します。それでもサーバーを購入する際は、最大トラフィックに対応できるスペックを購入しなければなりません。普段の余剰コンピューティング能力は無駄になっているのではないでしょうか。
もし、需要に応じてコンピューティング能力を柔軟に伸縮できる方法があれば、ユーザーは実際のコンピューティング使用量に応じて課金されるだけで済みます。それは大きな進歩と言えるでしょう。
さらに、社会発展の観点や人類運命共同体の視点から見ても、社会リソースを大幅に節約し、生産性を向上させることができます。不勉強ながら、このアイデアはずっと持っていましたが、クラウドコンピューティングの分野で既に実現されている技術だとは知りませんでした。Serverless はその代表的なコンピューティング技術の一つであり、すでに私たちの身近に存在しています。
この時代を、私はコンピューティングリソースの「現代」と呼びたいと思います。その特徴は、きめ細やかさと調和です。
Serverless の概念
文字通り、Server はサーバー、less は無いということで、サーバーがないことを意味します。サーバーレスコンピューティングとは、プログラムを個々のサーバーにデプロイするのではなく、クラウド (Alibaba Cloud など) に直接預け、クラウドがコンピューティングリソースの連携とエラスティックコンピューティングを担う仕組みです。
では、Alibaba Cloud のサーバーレス機能を使って実際に体験してみましょう。
クイック体験
プロダクト入口
Alibaba Cloud には多くのプロダクトがあります。まず、Function Compute の場所を説明します。
アプリケーションの作成
Function Compute のプロダクトページに入ったら、最初にアプリケーションを作成する必要があります。アプリケーションはバックグラウンドサービスやバックグラウンドプロジェクトと理解できます。
Alibaba Cloud には SpringBoot、Django、Flask などの組み込みアプリケーションテンプレートが多数用意されており、非常に便利で強力です。ここでは使い慣れた SpringBoot を選択します。
アプリケーションのデプロイ設定
次の図に示すように、Gitee のコードリポジトリを通じてアプリケーションコードをデプロイするように設定します。これはわかりやすい仕組みです。アプリケーションを Gitee のコードリポジトリに直接関連付けます。アプリケーションをデプロイする場合は、まずコードを Gitee にプッシュします。
注意:上記の図の赤線のリンクをクリックし、Gitee にログインして、Gitee のコードと Alibaba Cloud サービスのバインドと権限付与を完了させてください。
作成をクリックすると、次のウィンドウがポップアップします。作成が完了するまでお待ちください。
コードの記述
上記のプロジェクトを作成する際、Gitee のコードリポジトリ名を [start-spring-boot-jc] と指定しました。このリポジトリをローカルにクローンします。プロジェクトのコード構造は次のとおりです。
pom.xml 設定ファイルを開きます。おなじみの構成です。純粋な SpringBoot プロジェクトで、バージョンは 2.1.8 です。Alibaba Cloud の開発者がこのバージョンを選んだということは、十分に安定していて優れているはずです。
次に起動クラスを見ます。welcome がアプリケーションのデフォルトのエントリーポイントだと簡単に推測できます。
さあ、Java フルスタックプログラマーとして、何も変更せずにいられるでしょうか。
コードのデプロイ
コードをリポジトリにプッシュし、赤線の部分をクリックしてアプリケーション詳細に入ります。
デプロイ履歴を見ると、なんと既に自動デプロイされていました。どうやってわかったかというと、タイムスタンプを見ればわかります。Alibaba Cloud はコードの更新を自動的に検出し、自動的にデプロイをトリガーしているということです。これは素晴らしいですね。
アクセステスト
アプリケーション詳細ページの上部にあるドメイン名をクリックしてアクセスします。
次のページインターフェイスが表示されたら完了です。
よくある使用上の問題の分析
独自のビジネスロジックを開発するには
SpringBoot に慣れていれば、この問題は非常に簡単です。
pom.xml に依存関係を設定し、サービスクラスを記述して、最後に welcome メソッドからカプセル化されたサービスクラスを呼び出します。実行結果はウェブページに表示できます。もちろん、ウェブページなしでバックグラウンドの計算結果を表示することもできます。
正式なドメイン名を設定するには
プロジェクトを本番環境で公開する際は、正式なドメイン名を使いたいことが多いです。Function Compute のホームページに入り、ドメイン名管理メニューをクリックしてから、ユーザー定義ドメイン名の追加をクリックします。
次の図に示すように、ドメイン名をアプリケーション内の関数に関連付けることができます。
インスタンスタイプと環境構成
サービス管理 - 関数管理の赤丸で囲まれた構成ボタンをクリックします。
次の図に示すように、インスタンスタイプや環境情報 (メモリ、同時実行数、インスタンスタイプなど) を設定できます。
メモリは関数実行の最大メモリを指し、同時実行数は関数が同時に処理できるリクエスト数を指します。
インスタンスタイプの選択方法
インスタンスタイプは 3 種類あります。以下は Alibaba Cloud の公式説明です。わかりやすく書かれているので、ここでは詳しく説明しません。
エラスティックインスタンス:Function Compute の基本インスタンスで、主にアクティビティ、大規模プロモーション、レッドパケットなどの突発的なトラフィックシナリオに適しています。
パフォーマンスインスタンス:より高いリソース上限を持つ大規模インスタンスで、主に音声・動画処理、AI モデリング、エンタープライズ Java アプリケーションなどのコンピューティング集約的なシナリオに適しています。パフォーマンスインスタンスを選択すると、関数はより高いコンピューティング能力を持つインスタンスで実行されます。
GPU インスタンス (パブリックテスト中):Turing アーキテクチャベースの GPU インスタンスで、主に音声・動画、AI 人工知能、画像処理などのシナリオに適しています。異なるシナリオに応じて、異なるビジネス負荷を GPU ハードウェアにオフロードすることで、ビジネス処理の効率を大幅に向上させます。
監視とログの確認方法
アプリケーション詳細には、関連する基盤サービスと関数が表示されます。次の図のようになります。
関数をクリックすると、さまざまな情報を確認できます。次の図に示すように、モニタリング指標を簡単に確認できます。
次の図はログ情報を示しています。
エラスティック管理の実行方法
関数の詳細ページで、エラスティック管理 - ルールの作成をクリックし、ルールを設定して関数のエラスティック管理を実行します。
次の図に示すように、時間または指標に基づいてインスタンス数を動的に調整できます。
まとめ
上記の説明から、Serverless の関数コンピューティングは新しい形態のコンピューティングとして、コンピューティングリソースの弾力的な変化のシナリオに、より効果的に対応できることがわかります。
マクロな視点から見ると、異なる企業やサービスのコンピューティングリソース需要は時間的・空間的に不均衡です。クラウドコンピューティングベンダーはリソースを動的にスケジューリングすることでコンピューティング能力の合理的な配分を実現し、大量のアイドルリソースを節約して、コスト削減につなげることができます。
さらに広い視野で見ると、人類運命共同体の理念が一定の水準まで発展すれば、世界中のクラウドコンピューティングメーカーが基盤となるコンピューティング能力を共有できるようになります。ある国や地域のコンピューティングリソースが突発的なイベントに対応できない場合、他の国や地域のクラウドプロバイダーから一時的にコンピューティング能力を調達できます。もちろん、適切な費用の支払いが必要です。
Serverless の研究開発は国と人々に利益をもたらすものです。未来は明るく、私たちは常に希望に満ちています。クラウドの上で舞い踊り、世界と共に明るい年月を歩んでいきましょう。
古代
大昔、コンピューターは極めて希少なリソースでした。ある大学の教授から聞いた話ですが、当初は大学のコンピューター学科にコンピューターが 1 台しかなかったそうです。コンピューターは非常に希少で、お金があっても簡単に手に入るものではありませんでした。
この時代を、私はコンピューティングリソースの「古代」と呼びたいと思います。その特徴はずばり希少性です。
中世
私は大学を卒業した後、ある大手国有商業銀行に入行し、情報技術の業務に従事しました。初めてサーバー室に入ったとき、ずらりと並ぶサーバーの列に圧倒されました。サーバーのランプがちらちらと点滅するのを見て、これらが数十億、数百億、数兆規模の資金の流れを支えているのだと想像しました。
それらのサーバーは巨大で、強力で、安定していました。しかし、非常に高価でした。購入費用が高いだけでなく、これらの大型サーバーを正常に稼働させるためには、サーバー室や運用保守スタッフのコストもかさみます。大企業ならともかく、中小企業には手が届きません。
この時代を、私はコンピューティングリソースの「中世」と呼びたいと思います。その特徴はずばり高コストです。
近代
2018 年に民間企業に入社すると、ほとんどの企業が ECS を使っていることがわかりました。ECS の利点は、デプロイするプログラムのアクセスが多く、高い同時実行数と大量のデータを処理する場合は、高スペックで高価格な構成を購入でき、プログラムがシンプルでアクセスが少ない場合は、低スペックで低価格な構成を選べることです。
さらに、時間の経過とともにアクセスが大幅に増加した場合、費用をかけて構成をスペックアップすることもできます。また、ECS を使えば専用データセンターを構築する必要がなく、ハードウェアルーターやファイアウォールを購入する必要もないため、コスト面でも手頃です。こうして中堅・中小企業は ECS を積極的に導入するようになりました。在職中、私は数十台の ECS サーバーを管理し、毎年数台ずつ追加していました。
この時代を、私はコンピューティングリソースの「近代」と呼びたいと思います。その特徴は高いコストパフォーマンスです。
現代
実は、業務を進める中でずっと気づいていたことがあります。それは、コンピューティングリソースへの需要は時間的・空間的に不均衡だということです。
たとえば、学校の決済システムを開発した場合、普段はほとんどアクセスがありません。しかし学校から請求書が送付される時期になると、システムへのアクセスが殺到します。それでもサーバーを購入する際は、最大トラフィックに対応できるスペックを購入しなければなりません。普段の余剰コンピューティング能力は無駄になっているのではないでしょうか。
もし、需要に応じてコンピューティング能力を柔軟に伸縮できる方法があれば、ユーザーは実際のコンピューティング使用量に応じて課金されるだけで済みます。それは大きな進歩と言えるでしょう。
さらに、社会発展の観点や人類運命共同体の視点から見ても、社会リソースを大幅に節約し、生産性を向上させることができます。不勉強ながら、このアイデアはずっと持っていましたが、クラウドコンピューティングの分野で既に実現されている技術だとは知りませんでした。Serverless はその代表的なコンピューティング技術の一つであり、すでに私たちの身近に存在しています。
この時代を、私はコンピューティングリソースの「現代」と呼びたいと思います。その特徴は、きめ細やかさと調和です。
Serverless の概念
文字通り、Server はサーバー、less は無いということで、サーバーがないことを意味します。サーバーレスコンピューティングとは、プログラムを個々のサーバーにデプロイするのではなく、クラウド (Alibaba Cloud など) に直接預け、クラウドがコンピューティングリソースの連携とエラスティックコンピューティングを担う仕組みです。
では、Alibaba Cloud のサーバーレス機能を使って実際に体験してみましょう。
クイック体験
プロダクト入口
Alibaba Cloud には多くのプロダクトがあります。まず、Function Compute の場所を説明します。
アプリケーションの作成
Function Compute のプロダクトページに入ったら、最初にアプリケーションを作成する必要があります。アプリケーションはバックグラウンドサービスやバックグラウンドプロジェクトと理解できます。
Alibaba Cloud には SpringBoot、Django、Flask などの組み込みアプリケーションテンプレートが多数用意されており、非常に便利で強力です。ここでは使い慣れた SpringBoot を選択します。
アプリケーションのデプロイ設定
次の図に示すように、Gitee のコードリポジトリを通じてアプリケーションコードをデプロイするように設定します。これはわかりやすい仕組みです。アプリケーションを Gitee のコードリポジトリに直接関連付けます。アプリケーションをデプロイする場合は、まずコードを Gitee にプッシュします。
注意:上記の図の赤線のリンクをクリックし、Gitee にログインして、Gitee のコードと Alibaba Cloud サービスのバインドと権限付与を完了させてください。
作成をクリックすると、次のウィンドウがポップアップします。作成が完了するまでお待ちください。
コードの記述
上記のプロジェクトを作成する際、Gitee のコードリポジトリ名を [start-spring-boot-jc] と指定しました。このリポジトリをローカルにクローンします。プロジェクトのコード構造は次のとおりです。
pom.xml 設定ファイルを開きます。おなじみの構成です。純粋な SpringBoot プロジェクトで、バージョンは 2.1.8 です。Alibaba Cloud の開発者がこのバージョンを選んだということは、十分に安定していて優れているはずです。
次に起動クラスを見ます。welcome がアプリケーションのデフォルトのエントリーポイントだと簡単に推測できます。
さあ、Java フルスタックプログラマーとして、何も変更せずにいられるでしょうか。
コードのデプロイ
コードをリポジトリにプッシュし、赤線の部分をクリックしてアプリケーション詳細に入ります。
デプロイ履歴を見ると、なんと既に自動デプロイされていました。どうやってわかったかというと、タイムスタンプを見ればわかります。Alibaba Cloud はコードの更新を自動的に検出し、自動的にデプロイをトリガーしているということです。これは素晴らしいですね。
アクセステスト
アプリケーション詳細ページの上部にあるドメイン名をクリックしてアクセスします。
次のページインターフェイスが表示されたら完了です。
よくある使用上の問題の分析
独自のビジネスロジックを開発するには
SpringBoot に慣れていれば、この問題は非常に簡単です。
pom.xml に依存関係を設定し、サービスクラスを記述して、最後に welcome メソッドからカプセル化されたサービスクラスを呼び出します。実行結果はウェブページに表示できます。もちろん、ウェブページなしでバックグラウンドの計算結果を表示することもできます。
正式なドメイン名を設定するには
プロジェクトを本番環境で公開する際は、正式なドメイン名を使いたいことが多いです。Function Compute のホームページに入り、ドメイン名管理メニューをクリックしてから、ユーザー定義ドメイン名の追加をクリックします。
次の図に示すように、ドメイン名をアプリケーション内の関数に関連付けることができます。
インスタンスタイプと環境構成
サービス管理 - 関数管理の赤丸で囲まれた構成ボタンをクリックします。
次の図に示すように、インスタンスタイプや環境情報 (メモリ、同時実行数、インスタンスタイプなど) を設定できます。
メモリは関数実行の最大メモリを指し、同時実行数は関数が同時に処理できるリクエスト数を指します。
インスタンスタイプの選択方法
インスタンスタイプは 3 種類あります。以下は Alibaba Cloud の公式説明です。わかりやすく書かれているので、ここでは詳しく説明しません。
エラスティックインスタンス:Function Compute の基本インスタンスで、主にアクティビティ、大規模プロモーション、レッドパケットなどの突発的なトラフィックシナリオに適しています。
パフォーマンスインスタンス:より高いリソース上限を持つ大規模インスタンスで、主に音声・動画処理、AI モデリング、エンタープライズ Java アプリケーションなどのコンピューティング集約的なシナリオに適しています。パフォーマンスインスタンスを選択すると、関数はより高いコンピューティング能力を持つインスタンスで実行されます。
GPU インスタンス (パブリックテスト中):Turing アーキテクチャベースの GPU インスタンスで、主に音声・動画、AI 人工知能、画像処理などのシナリオに適しています。異なるシナリオに応じて、異なるビジネス負荷を GPU ハードウェアにオフロードすることで、ビジネス処理の効率を大幅に向上させます。
監視とログの確認方法
アプリケーション詳細には、関連する基盤サービスと関数が表示されます。次の図のようになります。
関数をクリックすると、さまざまな情報を確認できます。次の図に示すように、モニタリング指標を簡単に確認できます。
次の図はログ情報を示しています。
エラスティック管理の実行方法
関数の詳細ページで、エラスティック管理 - ルールの作成をクリックし、ルールを設定して関数のエラスティック管理を実行します。
次の図に示すように、時間または指標に基づいてインスタンス数を動的に調整できます。
まとめ
上記の説明から、Serverless の関数コンピューティングは新しい形態のコンピューティングとして、コンピューティングリソースの弾力的な変化のシナリオに、より効果的に対応できることがわかります。
マクロな視点から見ると、異なる企業やサービスのコンピューティングリソース需要は時間的・空間的に不均衡です。クラウドコンピューティングベンダーはリソースを動的にスケジューリングすることでコンピューティング能力の合理的な配分を実現し、大量のアイドルリソースを節約して、コスト削減につなげることができます。
さらに広い視野で見ると、人類運命共同体の理念が一定の水準まで発展すれば、世界中のクラウドコンピューティングメーカーが基盤となるコンピューティング能力を共有できるようになります。ある国や地域のコンピューティングリソースが突発的なイベントに対応できない場合、他の国や地域のクラウドプロバイダーから一時的にコンピューティング能力を調達できます。もちろん、適切な費用の支払いが必要です。
Serverless の研究開発は国と人々に利益をもたらすものです。未来は明るく、私たちは常に希望に満ちています。クラウドの上で舞い踊り、世界と共に明るい年月を歩んでいきましょう。
Related Articles
-
A detailed explanation of Hadoop core architecture HDFS
Knowledge Base Team
-
What Does IOT Mean
Knowledge Base Team
-
6 Optional Technologies for Data Storage
Knowledge Base Team
-
What Is Blockchain Technology
Knowledge Base Team
Explore More Special Offers
-
Short Message Service(SMS) & Mail Service
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00
