サーバーレス関数とは何か?

PubNub Developer Relations - Feb 7 - - Dev Community

サーバーレス・ファンクションの定義

サーバーレス・ファンクションとは、クラウド・コンピューティング企業によってマネージド・インフラストラクチャ上でホストされる、単一目的のプログラム機能である。これらの機能はインターネットを通じて呼び出され、ワークフローの自動化、待ち時間の短縮、オンデマンド・コンピューティング機能の提供を目的として設計されている。これらのサーバーレスアーキテクチャは、エンジニアリングチームによって維持され、完璧に近いアップタイム、世界中の冗長インスタンス、あらゆるネットワークリクエスト量に対するスケーラビリティを保証します。

誰がサーバーレス機能を作成するのか?

サーバーレス関数は、サーバーレス・コンピューティングの利点を活用するために、製品コードをサーバーレス・プラットフォームに移行するソフトウェア開発者によって作成される。クラウド・コンピューティング企業自身がこれらの機能を作成するのではなく、その顧客が作成するのだ。

サーバーレス機能とサービスの利点とは?

サーバーレスの機能やサービスは、コードのメンテナンス性の向上、費用対効果の高いホスティング、管理されたインフラ上で実行することによる安心感など、数多くの利点を提供する。このパラダイムは、このような利点から急速に普及しており、新しいコードのデプロイはより迅速かつシンプルで、簡単に自動化できる。

サーバーレス機能の例とは?

すべての主要なクラウドプロバイダーがサーバーレス機能を提供している:

サーバーレスインフラストラクチャモノリシック・アーキテクチャとマイクロサービス・アーキテクチャの比較

サーバーレスのファンクションは、サーバーレス環境で人気のあるコンセプトであるマイクロサービスと考えることができる。モノリシックなプラットフォームからカプセル化されたマイクロサービスへのシフトについて、ソフトウェア開発コミュニティでは興奮が高まっている。

企業がサーバーレス機能とアーキテクチャを採用する理由

歴史的に、モノリスは大規模で統一されたコードベースを持っており、新しいコードを出荷する際にはプラットフォーム全体をデプロイする必要がある。これには新機能だけでなく、1行のバグ修正も含まれる。

モノリスは状況によっては実用的ですが、プラットフォームのコードベースが開発チームが大規模になる段階にまで成長すると、いくつかのタスクが煩雑になります。

マイクロサービスのアーキテクチャは、コードベースの保守性を向上させ、ソフトウェア開発チームの全体的な開発者体験を向上させる。マイクロサービスは、大規模なエンジニアリング組織を疎結合で自律的なチームに分割することを可能にする。各チームは、プラットフォームの残りの部分から独立して動作するいくつかのマイクロサービスに注意を集中することができます。マイクロサービスはある程度独立して保守することができますが、それでも統一されたチームのプレーヤーであることに注意してください。

マイクロサービスアーキテクチャでは、実質的な貢献を始めるためにモノリス全体を深く理解する必要がないため、新しい開発者をエンジニアリングプロジェクトに迅速に参加させることができる。マイクロサービスのもう1つの利点は、単一のサービスに対する小さなコード更新のデプロイメントが、顧客にとってダウンタイムをほとんど、あるいは全く発生させないことです。モノリスにコード更新が必要な場合、サーバーレス・デプロイ機能の間、すべての顧客がダウンタイムを経験することになるかもしれない。

サーバーレスファンクションとFaaS(Functions-as-a-Service)

サーバーレスファンクションの魔法の部分は、自動スケーリングと冗長化されたコードのデプロイだ。つまり、アプリ開発者は優れたアプリケーション・コードを書くことだけに専念できる。クラウド・ホスティング・プロバイダーは、この製品提供をFunctions-as-a-Service、略してFaaSと呼んでいる。

従来のアプリホスティングでは、ソフトウェア開発者はコードを書く際に次のような質問を繰り返し自問する必要があった:

  • 私のサーバーは、各クライアントの物理的な場所に関係なく、非常に低いレイテンシーで、すべてのクライアントのリクエストに応答するだろうか?

  • コードのデプロイプロセスにヒューマンエラーの余地を作っていないか?

  • 私のサーバーは、過負荷をかけずにリクエスト量の急激な増加に対応できるか?

  • 私のサーバーは、大金を浪費することなく、リクエスト量の急激な増加に対応できますか?

  • 自分のアプリのインフラを常に監視する必要があるだろうか?私は一晩に8時間眠るのが好きだ。

これらの質問は、ソフトウェアシステムがサーバーレスファンクションのプラットフォーム上に構築されている場合には当てはまらない

サーバーレス・ファンクションのコードは完全にステートレスなロジックであるべきなので、冗長なインスタンスが顧客に不整合を引き起こすことはない。クラウド・ホスティング・プロバイダーは通常、世界中に多くの拠点を持っている。これは、アプリケーションが実行されるサーバーが、可能性のあるすべてのエンドユーザーに最も近いことを意味する。クラウド・ホスティング・プロバイダーは、サーバーレス機能を世界中のデータセンターに同時に冗長的にデプロイする。クライアントサイドのリクエストは可能な限り遅延なく応答されるため、これは開発者の顧客にとって良いことだ。ネットワーキング・ロジックはすべてクラウド・プロバイダーが実装する。

クラウド・ホスティング・プラットフォームを利用したGoogleとAWSのサーバーレス・ファンクション

Serverless Functionsを提供するクラウド・ホスティング・プロバイダーは、コードの自動デプロイに業界標準のベスト・プラクティスを採用している。つまり、デプロイ中に人為的なミスでサービスが壊れる可能性がなく、新しいコードを迅速に出荷できるため、ウェブ製品のダウンタイムはほとんどない。

サーバーレス・ファンクション・ホスティングの最も価値ある機能の1つは、自動スケーリングだ。クラウドホスティングプロバイダーは、顧客にとってアイドルサーバーのコストを過去のものとした。Kubernetesのようなソフトウェア製品のおかげで、サービスは自動化された方法でインフラをプログラム的にスケールすることができる。この新しい種類の「弾力的な」インフラは、ホスティングをより効率的にし、クラウド・ホスティングを購入する企業にとって大きなコスト削減につながる。

FaaSプロバイダーとサーバーレス機能の例

クラウド・ホスティング企業は最先端のFaaSプラットフォームを提供している。大手ハイテク企業がサーバー・ファームをどんどん建設しているため、消費者のサーバー・コストは世界的に下がっている。しかし、すべてのFaaSサービスが同じように作られているわけではない。FaaSプラットフォームは電話会社のようなものではない。各プラットフォームには、それが輝く独自のシナリオがある。

AWS Lambdaサーバーレスファンクション

AWS Lambdaは、Amazon Web Services上のサーバーレス関数環境だ。サポートされているプログラミング言語は、Java、Go、PowerShell、Node.js、C#、Python、Ruby、Rust、PHP。ファイル処理のようなオンデマンドの計算処理に最適だ。

Azure Functions サーバーレスファンクション

Azure Functionsは、Microsoft Azure上のサーバーレス関数環境だ。サポートされているプログラミング言語は、C#、F#、Java、Python、JavaScript、TypeScript。アプリケーションデータを安全に保存するためのエンドポイントを提供するなど、プラットフォームに機能を追加するための単一目的のAPIを作成するのに適している。

Google Cloud サーバーレスファンクション

Google Cloud Functionsは、Google Cloud Platform上のサーバーレス関数環境である。サポートされているプログラミング言語は、JavaScript、Python、Go、.NET(C#)、Ruby、PHPです。Google Cloud Functionsは、他のGoogle Cloudサービスやクライアント・アプリケーションと簡潔に相互作用するサーバーレス・コンピューティングを提供する。画像や動画から関連データを取得するなど、データ処理が重要なシナリオに最適です。

Functions

Functionsは、エッジで関数を実行するサーバーレス環境であり、JavaScriptを使用してPubNubネットワークを経由する際にメッセージを変換、エンリッチ、フィルタリングする。このサーバーレスプラットフォームは、PubNubのPub/Sub APIでメッセージが公開されたときなど、PubNubからのイベントに応答してFunctionのイベントハンドラが実行されるため、他のものとは根本的に異なる。

開発者は、PubNubメッセージが発行された後、メッセージが購読者に到達する前に、転送中のPubNubメッセージに対してコードを実行することができます。公開後のノンブロッキングや、Node.jsサーバーのようにアクセスできるREST APIエンドポイントなど、他の実行構成もある。ステートは、KV-Storeを使用して構築された関数環境で管理できる。また、PubNub Functions Catalogにはオープンソースのサードパーティ統合のカタログも用意されている。

自分のサービスにどのサーバーレスプロバイダーを使うべきか?

この質問に対する答えは、構築する必要があるサービスのタイプによって異なります。上で説明したプロバイダーからわかるように、クラウドによって使用できるプログラミング言語は異なる。プロバイダーを選択する際に最も重要なことは、「自分のサービスにとってどの属性がミッションクリティカルなのか」ということだ。

最大手のクラウド企業(AWS、Azure、Google)は、汎用的なクラウド製品で多様なユースケースに対応できるよう設計された、スケーラブルで費用対効果の高いサーバーレス・コンピューティング・ソリューションを提供している。これらのサーバーレス・プラットフォームは、インフラ管理を簡素化し、アプリケーションにオンデマンドのスケーラビリティを提供する。しかし、PubNubのような企業は、特定の開発者のペインポイント、特にリアルタイムのユースケースに特化している。独自のサーバーレス環境を持つPubNubは、リアルタイムシナリオにおいてのみ、一般的なサーバーレス製品よりも優れている。

PubNubのサーバーレス機能は驚くほど低レイテンシーで実行できるため、チャット、GPS位置追跡、IoTシグナリング、マルチプレイヤーゲームなどのリアルタイムアプリケーションに最適だ。イベントに応じてアプリケーションコードの実行を自動化するこれらの関数は、構築とデプロイが容易であるため、市場投入までの時間を短縮できる。さらに、PubNubは関数開発用にJavaScriptとTypeScriptをサポートし、開発者に柔軟性を提供している。

あなたのユースケースが重い計算を含み、OSアクセスを必要とする言語を必要とし、レイテンシーに敏感でない場合、AWS、Azure、Googleのような大規模なクラウドホスティング会社が提供する広範なサーバーレスがより適していると感じるかもしれない。これらのプロバイダーは、Node.js、Python、Java、Rust、PHP、.NET(C#)、Rubyなどを含むが、これらに限定されない幅広いプログラミング言語をサポートしている。

PubNub FunctionsとAWS Lambdaの包括的な比較については、あなたのビジネスに適したサーバーレスプロバイダーを選択するための詳細な洞察を提供する私たちのブログポストをチェックしてください。

サーバーレスアプリケーションに関しては、セキュリティが考慮すべき重要な側面であることも注目に値する。PubNubのサーバーレス環境はデータセキュリティを最優先し、堅牢な認証メカニズムとセキュアなAPIエンドポイントを提供してデータを保護するのでご安心ください。

結論として、あなたが費用対効果の高いサーバーレス・ソリューションを求めている新興企業であれ、ミッションクリティカルなアプリケーションにサーバーレス・アーキテクチャのパワーを活用しようとしている既存企業であれ、さまざまなサーバーレス・プロバイダーの強みと能力を理解することは、十分な情報に基づいた意思決定に役立ちます。

PubNubはどのようにお役に立てるでしょうか?

この記事はPubNub.comに掲載されたものです。

PubNubのプラットフォームは、開発者がWebアプリ、モバイルアプリ、IoTデバイス向けにリアルタイムのインタラクティブ機能を構築、提供、管理できるように支援します。

私たちのプラットフォームの基盤は、業界最大かつ最もスケーラブルなリアルタイムエッジメッセージングネットワークです。世界15か所以上で8億人の月間アクティブユーザーをサポートし、99.999%の信頼性を誇るため、停電や同時実行数の制限、トラフィックの急増による遅延の問題を心配する必要はありません。

PubNubを体験

ライブツアーをチェックして、5分以内にすべてのPubNub搭載アプリの背後にある本質的な概念を理解する

セットアップ

PubNubアカウントにサインアップすると、PubNubキーに無料ですぐにアクセスできます。

始める

PubNubのドキュメントは、ユースケースやSDKに関係なく、あなたを立ち上げ、実行することができます。

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .