ラック上のサーバーレス

サーバーレスとは​​、サーバーが物理的に存在しないという意味ではありません。 これはコンテナキラーでも一時的なトレンドでもありません。 これは、クラウド上にシステムを構築するための新しいアプローチです。 今日の記事では、サーバーレス アプリケーションのアーキテクチャについて触れ、サーバーレス サービス プロバイダーとオープンソース プロジェクトがどのような役割を果たしているかを見てみましょう。 最後に、サーバーレスを使用する際の問題について話しましょう。

アプリケーションのサーバー部分 (またはオンライン ストア) を作成したいと考えています。 これは、チャット、コンテンツ公開サービス、またはロード バランサーである可能性があります。 いずれにせよ、多くの頭の痛い問題が発生します。インフラストラクチャを準備し、アプリケーションの依存関係を決定し、ホスト オペレーティング システムについて考慮する必要があります。 次に、モノリスの残りの部分の動作に影響を与えない小さなコンポーネントを更新する必要があります。 さて、負荷時のスケーリングを忘れないでください。

必要な依存関係がすでにプリインストールされており、コンテナー自体が相互に、またホスト OS から分離されている一時的なコンテナーを使用した場合はどうなるでしょうか? モノリスをマイクロサービスに分割し、それぞれを他とは独立して更新およびスケーリングできます。 このようなコンテナーにコードを配置することで、任意のインフラストラクチャ上でコードを実行できます。 すでに良くなりました。

コンテナを構成したくない場合はどうすればよいでしょうか? アプリケーションのスケーリングについては考えたくありません。 サービスの負荷が最小限の場合、アイドル状態で実行されているコンテナーに料金を支払いたくありません。 コードを書きたいです。 ビジネス ロジックに焦点を当て、光の速さで製品を市場に投入します。

このような考えが私をサーバーレス コンピューティングに導きました。 この場合のサーバーレスとは​​、 サーバーが物理的に存在しないのではなく、インフラストラクチャ管理の問題が発生しないのです。

この考え方は、アプリケーション ロジックを独立した機能に分割するというものです。 イベント構造を持っています。 各関数は XNUMX つの「マイクロタスク」を実行します。 開発者に必要なのは、クラウド プロバイダーが提供するコンソールに関数をロードし、イベント ソースと関連付けることだけです。 コードは自動的に準備されたコンテナーでオンデマンドで実行され、実行時間に対してのみ料金を支払います。

アプリケーション開発プロセスがどのようになるかを見てみましょう。

開発者側からすると

先ほど、オンライン ストアのアプリケーションについて話し始めました。 従来のアプローチでは、システムの主なロジックはモノリシック アプリケーションによって実行されます。 また、アプリケーションがインストールされているサーバーは、負荷がない場合でも常に実行されています。

サーバーレスに移行するには、アプリケーションをマイクロタスクに分割します。 それぞれに独自の関数を作成します。 これらの関数は互いに独立しており、状態情報を保存しません (ステートレス)。 異なる言語で書かれていることもあります。 そのうちの XNUMX つが「落ちた」場合でも、アプリケーション全体は停止しません。 アプリケーションのアーキテクチャは次のようになります。

サーバーレスでの機能への分割は、マイクロサービスの操作に似ています。 ただし、マイクロサービスは複数のタスクを実行でき、関数は理想的には XNUMX つを実行する必要があります。 タスクが統計を収集し、ユーザーの要求に応じて表示することであると想像してみましょう。 マイクロサービス アプローチでは、タスクは XNUMX つのエントリ ポイント (書き込みと読み取り) を持つ XNUMX つのサービスによって実行されます。 サーバーレス コンピューティングでは、これらは互いに関連しない XNUMX つの異なる機能になります。 たとえば、統計がダウンロードされるよりも頻繁に更新される場合、開発者はコンピューティング リソースを節約できます。

サーバーレス機能は、サービスプロバイダーによって決定される短い時間 (タイムアウト) で実行する必要があります。 たとえば、AWS の場合、タイムアウトは 15 分です。 これは、存続期間の長い機能を要件に合わせて変更する必要があることを意味します。これが、サーバーレスを今日の一般的なテクノロジー (コンテナーやサービスとしてのプラットフォーム) と区別する点です。

各関数にイベントを割り当てます。 イベントはアクションのトリガーです。

イベント
関数が実行するアクション

製品イメージがリポジトリにアップロードされました。
画像を圧縮してディレクトリにアップロードします

データベース内の物理的な店舗の住所が更新されました
新しい場所を地図にロードする

顧客は商品の代金を支払います
支払い処理を開始する

イベントには、HTTP リクエスト、ストリーミング データ、メッセージ キューなどがあります。 イベント ソースは、データの変更または発生です。 さらに、タイマーによって機能をトリガーすることもできます。

アーキテクチャが練り上げられ、アプリケーションはほぼサーバーレスになりました。 次にサービスプロバイダーに進みます。

プロバイダー側​​からすると

通常、サーバーレス コンピューティングはクラウド サービス プロバイダーによって提供されます。 これらは、Azure Functions、AWS Lambda、Google Cloud Functions、IBM Cloud Functions のように呼ばれます。

プロバイダーのコンソールまたは個人アカウントを通じてサービスを使用します。 関数コードは、次のいずれかの方法でダウンロードできます。

• Web コンソール経由で組み込みエディターにコードを記述します。
• コードを含むアーカイブをダウンロードし、
• パブリックまたはプライベート Git リポジトリを操作します。

ここでは、関数を呼び出すイベントを設定します。 イベントのセットはプロバイダーごとに異なる場合があります。

プロバイダーは、インフラストラクチャ上に Function as a Service (FaaS) システムを構築し、自動化しました。

1. 関数コードは最終的にプロバイダー側​​のストレージに保存されます。
2. イベントが発生すると、環境が準備されたコンテナがサーバー上に自動的にデプロイされます。 各関数インスタンスには独自の分離されたコンテナーがあります。
3. 関数はストレージからコンテナに送信され、計算されて結果を返します。
4. 並行イベントの数は増加しており、コンテナーの数も増加しています。 システムは自動的にスケールします。 ユーザーがこの機能にアクセスしない場合、その機能は非アクティブになります。
5. プロバイダーはコンテナーのアイドル時間を設定します。この間に関数がコンテナーに表示されない場合、コンテナーは破棄されます。

このようにして、すぐにサーバーレスを実現できます。 サービス料金は従量課金モデルを使用し、使用された機能に対してのみ、使用された時間分のみお支払いいただきます。

開発者にこのサービスを紹介するために、プロバイダーは最大 12 か月の無料テストを提供しますが、総計算時間、XNUMX か月あたりのリクエスト数、資金、または電力消費は制限されています。

プロバイダーと連携する主な利点は、インフラストラクチャ (サーバー、仮想マシン、コンテナー) について心配する必要がないことです。 プロバイダー側​​では、独自の開発とオープンソース ツールの両方を使用して FaaS を実装できます。 それらについてさらに話しましょう。

オープンソース側から

オープンソース コミュニティは、過去 XNUMX 年間、サーバーレス ツールの開発に積極的に取り組んできました。 最大の市場プレーヤーもサーバーレス プラットフォームの開発に貢献しています。

• でログイン 開発者にオープンソース ツールを提供 - ネイティブ。 IBM、RedHat、Pivo​​tal、SAP がその開発に参加しました。
• IBM サーバーレスプラットフォームで作業しました オープンウィスク、その後、Apache Foundation のプロジェクトになりました。
• Microsoft プラットフォームコードを部分的にオープンしました Azureの機能.

サーバーレスフレームワークの方向に向けた開発も進行中です。 キューブレス и 核分裂 事前に準備された Kubernetes クラスター内にデプロイされ、 OpenFaaS Kubernetes と Docker Swarm の両方で動作します。 フレームワークは一種のコントローラーとして機能し、要求に応じてクラスター内にランタイム環境を準備し、そこで関数を起動します。

フレームワークには、ニーズに合わせてツールを構成する余地が残されています。 したがって、Kubeless では、開発者は関数の実行タイムアウト (デフォルト値は 180 秒) を構成できます。 Fission は、コールド スタートの問題を解決するために、一部のコンテナを常に実行し続けることを提案しています (ただし、これにはリソースのダウンタイム コストがかかります)。 また、OpenFaaS は、HTTP、Kafka、Redis、MQTT、Cron、AWS SQS、NAT など、あらゆる好みや色に合わせた一連のトリガーを提供します。

開始手順は、フレームワークの公式ドキュメントに記載されています。 プロバイダーと連携するには、プロバイダーと連携する場合よりももう少し多くのスキルが必要です。これには、少なくとも CLI 経由で Kubernetes クラスターを起動できる能力が必要です。 多くても、他のオープンソース ツール (Kafka キュー マネージャーなど) を含めます。

サーバーレスをどのように扱うか (プロバイダー経由かオープンソースを使用するか) に関係なく、サーバーレス アプローチには多くの利点と欠点があります。

メリットとデメリットの観点から見ると

サーバーレスは、チームが XNUMX つのプラットフォームに縛られることなく多言語モードで作業できる、コンテナ インフラストラクチャとマイクロサービス アプローチのアイデアを開発します。 システムの構築が簡素化され、エラーの修正が容易になります。 マイクロサービス アーキテクチャを使用すると、モノリシック アプリケーションの場合よりもはるかに速く新しい機能をシステムに追加できます。

サーバーレスにより開発時間がさらに短縮され、 これにより、開発者はアプリケーションのビジネス ロジックとコーディングだけに集中できるようになります。 その結果、開発の市場投入までの時間が短縮されます。

ボーナスとして、負荷の自動スケーリングが得られます。 また、料金は使用されたリソースに対してのみ、使用された時点でのみ支払われます。

他のテクノロジーと同様、サーバーレスにも欠点があります。

たとえば、そのような欠点は、コールド スタート時間 (JavaScript、Python、Go、Java、Ruby などの言語では平均して最大 1 秒) である可能性があります。

一方で、実際には、コールド スタート時間は、関数が記述されている言語、ライブラリの数、コードの量、追加リソース (同じデータベースまたは認証サーバー) との通信など、多くの変数に依存します。 開発者はこれらの変数を制御できるため、起動時間を短縮できます。 しかしその一方で、開発者はコンテナの起動時間を制御できません。すべてはプロバイダーに依存します。

関数が前のイベントによって起動されたコンテナーを再利用する場合、コールド スタートはウォーム スタートに変わることがあります。 この状況は次の XNUMX つの場合に発生します。

• クライアントがサービスを頻繁に使用し、関数の呼び出し数が増加する場合。
• プロバイダー、プラットフォーム、またはフレームワークにより、一部のコンテナーを常に実行し続けることが許可されている場合。
• 開発者がタイマーで関数を実行する場合 (たとえば 3 分ごと)。

多くのアプリケーションでは、コールド スタートは問題になりません。 ここでは、サービスのタイプとタスクに基づいて構築する必要があります。 XNUMX 秒の開始遅延は、ビジネス アプリケーションにとって必ずしも重大な問題ではありませんが、医療サービスにとっては重大になる可能性があります。 この場合、サーバーレスアプローチはおそらく適切ではなくなります。

サーバーレスの次の欠点は、関数の存続期間が短いことです (関数を実行する必要がある間のタイムアウト)。

ただし、存続期間の長いタスクを処理する必要がある場合は、サーバーレスと別のテクノロジを組み合わせたハイブリッド アーキテクチャを使用できます。

すべてのシステムがサーバーレス スキームを使用して動作できるわけではありません。

一部のアプリケーションは、実行中にデータと状態を保存します。 一部のアーキテクチャはモノリシックのままであり、一部の機能は長期間存続します。 ただし、(クラウド テクノロジやその後のコンテナと同様に) サーバーレスは大きな将来性のあるテクノロジです。

この流れで、サーバーレスアプローチの使用の問題にスムーズに移りたいと思います。

アプリケーション側から

2018 年のサーバーレス使用率 XNUMX倍に成長した。 すでにこのテクノロジーを自社のサービスに導入している企業の中には、Twitter、PayPal、Netflix、T-Mobile、Coca-Cola などの市場大手が含まれます。 同時に、サーバーレスは万能薬ではなく、特定の範囲の問題を解決するためのツールであることを理解する必要があります。

• リソースのダウンタイムを削減します。 呼び出しの少ないサービスのために仮想マシンを常に保持する必要はありません。
• データをその場で処理します。 画像の圧縮、背景の切り取り、ビデオエンコーディングの変更、IoT センサーの操作、数学的演算の実行。
• 他のサービスを「接着」します。 内部プログラムを含む Git リポジトリ、Jira とカレンダーを使用した Slack のチャット ボット。
• 負荷のバランスをとります。 ここで詳しく見てみましょう。

50人が集まるサービスがあるとします。 その下には、弱いハードウェアを備えた仮想マシンがあります。 サービスの負荷が大幅に増加することがあります。 そうなると、弱いハードウェアでは対応できなくなります。

たとえば XNUMX 台の仮想マシンに負荷を分散するバランサーをシステムに含めることができます。 現段階では負荷を正確に予測できないため、一定量のリソースを「予備」として実行し続けます。 そして、ダウンタイムに対して過剰な費用を支払います。

このような状況では、ハイブリッド アプローチを通じてシステムを最適化できます。つまり、ロード バランサーの背後に XNUMX 台の仮想マシンを残し、機能を備えたサーバーレス エンドポイントへのリンクを配置します。 負荷がしきい値を超えると、バランサーはリクエスト処理の一部を引き継ぐ関数インスタンスを起動します。

したがって、サーバーレスは、大量のリクエストを頻繁ではなく集中的に処理する必要がある場合に使用できます。 この場合、仮想マシンやサーバーを常に維持するよりも、複数の機能を 15 分間実行するほうが収益性が高くなります。

サーバーレス コンピューティングにはさまざまな利点があるため、実装する前に、まずアプリケーション ロジックを評価し、特定のケースでサーバーレスがどのような問題を解決できるかを理解する必要があります。

サーバーレスとセレクテル

Selectel ではすでに Kubernetes による作業の簡素化 弊社のコントロールパネル経由で。 現在、私たちは独自の FaaS プラットフォームを構築しています。 私たちは、開発者が便利で柔軟なインターフェイスを通じてサーバーレスを使用して問題を解決できるようにしたいと考えています。

理想的な FaaS プラットフォームがどうあるべきか、プロジェクトでサーバーレスをどのように使用したいかについてアイデアがある場合は、コメントで共有してください。 プラットフォームを開発する際には、お客様のご要望を考慮させていただきます。
 
記事で使用した資料:

• サーバーレス使用率は XNUMX 倍に増加しました (RightScale レポートの全文)
• コールド スタート時間はアプリケーション言語によって異なります

出所： habr.com