How to effectively deal with the elastic changing demand of computing resources?

1. コンピューティングの発展史

1.1 古代

大昔の話です。コンピューターは極めて希少なリソースでした。かつて大学の教授と意見交換したことがあります。その教授によると、大学のコンピューター学科には当初コンピューターが 1 台しかなかったそうです。当時はいくら資金があっても、コンピューティングリソースを簡単に入手できる時代ではありませんでした。

この時代を、私はコンピューティングリソースの「古代」と呼びたいと思います。その特徴は「希少性」です。

1.2 中世

卒業後、ある大手国有商業銀行の情報技術部門に入社しました。初めてコンピューター室に入ったとき、ずらりと並ぶサーバーコンピューターに圧倒されました。サーバーのランプが時折点滅するのを見つめながら、それらが数十億、数千億、数兆規模の資金フローを支えているのだと想像しました。

それらは巨大で、高性能かつ安定的に稼働しますが、非常に高価です。購入費用だけでなく、これらの大型サーバーを正常に稼働させるための専用マシンルームや運用保守人員のコストも少なくありません。大企業なら負担できても、中小企業には手が出せないでしょう。

この時代を、私はコンピューティングリソースの「中世」と呼びたいと思います。その特徴は「高コスト」です。

1.3 近代

2018 年、民間企業に転職したところ、ほとんどの企業がクラウドサーバーを利用していることに気づきました。ECS を利用する利点は、デプロイするプログラムのアクセス量、同時実行数、データ量が多い場合は、より高スペックで高価なものを購入し、プログラムが比較的シンプルでアクセス量が少ない場合は、低スペックで安価なものを購入できることです。

時間の経過とともに、アクセス数が大幅に増加したときに費用をかけて設定をアップグレードすることもできます。同時に、クラウドサーバーを利用すれば、専用マシンルームを構築する必要もなく、ハードウェアルータやファイアウォールなどを購入する必要もないため、コスト面でも優れています。

非常に魅力的であるため、中小企業もクラウドサーバーを採用し始めました。勤務先の会社では数十台のクラウドサーバーを管理しており、毎年着実に新しいサーバーが追加されていたことを覚えています。

この時代を、私はコンピューティングリソースの「近代」と呼びたいと思います。その特徴は「高いコストパフォーマンス」です。

1.4 現代

実のところ、仕事の中で以前からいくつかの問題に気づいていました。それは、コンピューティングリソースへの需要が時間と空間の面で偏っているということです。

たとえば、ある学校の決済システムを開発したことがあります。普段はあまり使われないのですが、学校から支払い案内が出される日には、システムのアクセス数が爆発的に増加します。しかし、サーバーを購入する際は常に最大アクセス数をサポートできる仕様で購入する必要があり、普段は余剰計算能力が無駄になってしまうのではないでしょうか。

必要に応じて計算能力を柔軟に拡張・縮小でき、ユーザーは実際の計算量に応じてのみ課金すればよい仕組みがあれば、それはかなり大きな進歩と言えます。

さらに、社会発展や人類共通の未来という観点からも、社会的リソースを大幅に節約し、生産性を向上させることができます。実は、この考え方は以前から持っていたのですが、これが既にクラウドコンピューティングの分野で実装されている技術だとは知りませんでした。Serverless はその代表的なコンピューティング技術の一つで、既に私たちの前に登場しています。

この時代を、私はコンピューティングリソースの「現代」と呼びたいと思います。その特徴は「精緻で調和が取れている」ことです。

2. Serverless の概念

まず文字通りの意味から、Server はサーバー、less は「ない」という意味で、合わせると「サーバーがない」ということです。Serverless コンピューティングとは、プログラムを個々のサーバーにデプロイするのではなく、クラウド (Alibaba Cloud など) に直接預け、クラウド側がコンピューティングリソースの調整と弾力的なコンピューティングを実行してくれる仕組みです。

次に、Alibaba Cloud Function Compute を使って実際に体験してみましょう。

3. クイック体験

3.1 プロダクトへの入口

Alibaba Cloud には多くのプロダクトがあります。ここでは FC の場所をご案内します。

3.2 アプリケーションの作成

Function Compute のプロダクトページに入ったら、まずアプリケーションを作成する必要があります。アプリケーションとは、バックグラウンドサービスやバックグラウンドプロジェクトのようなものだと理解してください。

Alibaba Cloud には多くのアプリケーションテンプレートが用意されています。たとえば、よく使われる SpringBoot、Django、Flask などがあり、非常に優秀で強力です。ここでは馴染みのある SpringBoot を選択します。

3.3 アプリケーションのデプロイ設定

次の図に示すように、Gitee コードリポジトリを通じてアプリケーションコードをデプロイするように設定します。これは分かりやすい仕組みです。アプリケーションは Gitee コードリポジトリと直接関連付けられます。アプリケーションをデプロイする際は、まずコードを Gitee にコミットすればよいわけです。

注記：上の図の赤線で示したリンクをクリックし、Gitee にログインして、Gitee コードと Alibaba Cloud Serverless のバインド認証を完了してください。

作成ボタンをクリックすると、次のウィンドウがポップアップします。作成が完了するまでお待ちください。

3.4 コードの記述

上記のプロジェクト作成時に、Gitee コードリポジトリの名前を [start-springboot-jc] に指定しました。このリポジトリをローカルにクローンして、プロジェクトのコード構造を確認すると次のようになります。

pom.xml 設定ファイルを開きます。純粋な SpringBoot プロジェクトで、バージョンは 2.1.8 です。Alibaba Cloud の開発者がこのバージョンを選択しているので、安定していて優秀なはずです。

次に起動クラスを見ます。welcome がアプリケーションのデフォルトエントリーポイントであることは容易に推測できます。

さあ、Java フルスタックプログラマーとして、ここで修正を加えずにいられるでしょうか。

3.5 コードのデプロイ

コードをリポジトリにコミットし、赤線をクリックしてアプリケーションの詳細に入ります。

デプロイ履歴を見ると、既に自動デプロイされていることが分かります。どうやって見つけたかというと、タイムスタンプを見れば分かります。Alibaba Cloud はコードの更新を自動的に検出し、デプロイを自動的にトリガーする仕組みを実装しています。これは高く評価できます。

3.6 アクセステスト

アプリケーション詳細ページの上部で、ドメイン名をクリックしてアクセスします。

ポップアップしたページインターフェースは次のようになり、これで完成です。

4. よくある使用上の問題の分析

4.1 独自のビジネスロジックを開発するには

SpringBoot に慣れていれば、この問題は非常にシンプルなはずです。

pom.xml で依存関係を設定し、サービスクラスを記述して、最後に welcome メソッド内でカプセル化したサービスクラスを呼び出します。実行結果は Web ページに表示できますし、バックグラウンドの計算のみで Web ページに表示しないことも可能です。

4.2 公式ドメイン名を設定するには

プロジェクトを本番環境で公開する際は、公式ドメイン名を使用したいことが多いでしょう。Function Compute のホームページで [ドメイン名管理メニュー] をクリックし、[カスタムドメイン名の追加] をクリックします。

次の図に示すように、ドメイン名をアプリケーション内の関数に関連付けることができます。

4.3 インスタンス仕様と環境設定

[サービス管理] - [関数管理] の赤丸で示した [設定] ボタンをクリックします。

次の図に示すように、インスタンス仕様や環境情報を設定できます。たとえば、メモリ、同時実行数、インスタンスタイプなどです。

メモリは関数の実行に使用する最大メモリを指し、同時実行数は関数が同時に処理できるリクエスト数を指します。

4.4 インスタンスタイプの選択方法

インスタンスタイプは 3 つのカテゴリに分類されます。以下は Alibaba Cloud の公式説明です。分かりやすく書かれているので、ここでは詳しく説明しません。

・エラスティックインスタンス：Function Compute の基本インスタンスで、主にトラフィック急増などの突発的なトラフィックシナリオに適しています。たとえば、イベント、大規模プロモーション、ご祝儀配布などです。

・パフォーマンスインスタンス：より高いリソース上限を持つ大規模インスタンスで、主にコンピューティング集約型シナリオに適しています。たとえば、音声・動画処理、AI モデル化、エンタープライズレベルの Java アプリケーションなどです。パフォーマンスインスタンスを選択すると、関数はより高いコンピューティング能力を持つインスタンスで実行されます。

・GPU インスタンス (パブリックベータ)：Turing アーキテクチャベースの GPU インスタンスで、主に音声・動画、AI 人工知能、画像処理などのシナリオに適しています。異なるシナリオで、異なるビジネス負荷を GPU ハードウェアアクセラレーションにオフロードすることで、ビジネス処理の効率を大幅に向上させます。

4.5 モニタリングとログの確認方法

アプリケーションの詳細には、アプリケーションに関連するインフラサービスと関数が表示されます。次の図を参照してください。

関数をクリックすると、さまざまな情報を確認できます。次の図に示すように、モニタリングメトリクスを簡単に確認できます。

次の図はログ情報です。

4.6 弾性管理を行うには

関数の詳細ページで [Auto Scaling] - [ルールの作成] をクリックし、ルールを設定することで関数の Auto Scaling を実行できます。

次の図に示すように、時間やメトリクスに基づいてインスタンス数を動的に調整できます。

5. まとめ

以上の説明から、Serverless Function Compute は新しい形のコンピューティングとして、コンピューティングリソースの弾力的な変化に対応するシナリオにより適していることが分かります。

マクロな視点から見ると、異なる企業やサービスのコンピューティングリソースへの需要は、時空間的な偏りという特徴を持っています。クラウドコンピューティングベンダーは、リソースを動的にスケジューリングすることでコンピューティング能力の合理的な配分を実現し、大量のアイドルリソースを節約し、コストを削減できます。

さらにマクロなレベルでは、人類共通の未来という考え方が一定の水準まで発展したとき、基本的なコンピューティング能力を世界のクラウドコンピューティングベンダー間で共有できるようになります。ある国や地域のコンピューティングリソースが緊急時に不足した場合、他の国や地域のクラウドベンダーのコンピューティングリソースを一時的に利用することも可能です。もちろん、適切な料金が発生します。

Serverless の研究開発は国と人々に利益をもたらします。未来は明るいものです。今日のテクノロジーに対して、私たちは常に希望に満ちているべきです。クラウドで躍動し、世界の輝かしい時代を共に歩みましょう。