サーバーレスアーキテクチャの開発と応用

サーバーレス アーキテクチャは、「サーバーレス コンピューティング」とも呼ばれますが、その名前が示すように完全にサーバーレスというわけではありません。サーバーレス アーキテクチャは、クラウド コンピューティング プロバイダーがサーバーを管理するアプリケーション ベースのクラウド コンピューティング サービスであり、効率性が向上し、コストを節約できる可能性があります。ほとんどのクラウド コンピューティング ユーザーにとって、これはより簡単かつ効率的です。

[[269372]]

サーバーレスは Function as a Service (FaaS) とも呼ばれ、データを保存せずにアプリケーション ロジックを実行します。 FaaS を活用する開発者は依然としてサーバー側のロジックを記述する必要がありますが、それは一時的なステートレス コンテナー内で実行されます。モバイル アプリケーションを含むクライアント アプリケーションは、クラウドベースのインフラストラクチャである Backend as a Service (BaaS) を活用できます。

「サーバーレス」という用語の使用は 2012 年に遡ります。AWS は、パブリック クラウド ベンダー初のサーバーレス コンピューティング製品である Lambda を 2014 年にリリースし、この用語の主流使用を加速しました。 2016 年には、Google Cloud が Google Cloud Functions、Microsoft Azure が Azure Functions、IBM Cloud が IBM Functions をリリースし、OpenWhisk オープンソース プロジェクトがデビューしました。

サーバーレスは、クラウド コンピューティングのサービスとしてのプラットフォーム (PaaS) と混同されることがあります。バックエンド アズ ア サービス (BaaS) とファンクション アズ ア サービス (FaaS) はどちらもクラウド コンピューティング プロバイダーが提供するサービス オプションですが、ファンクション アズ ア サービス (FaaS) はプラットフォーム アズ ア サービス (PaaS) とはいくつかの重要な点で異なります。たとえば、Function as a Service (FaaS) は自動的にスケーリングされますが、Platform as a Service (PaaS) はスケーリングされません。さらに、Function as a Service (FaaS) ではアプリケーション全体の起動と停止が可能ですが、Platform as a Service (PaaS) はそのために特別に設計されていません。

サーバーレス アーキテクチャでは、アプリケーションの粒度が細かく使用されます。以前のモノリシック アーキテクチャよりも、今日のマイクロサービスの世界ではより効果的に機能します。

サーバーレスの例

• 写真アプリのユーザーは、写真を選択するときに自動的にサイズを変更できます。写真は Amazon S3 バケットに送信され、サーバーレスを使用して対応する Lambda 関数がトリガーされます。出力はユーザーが選択した写真サイズになります。
• アプリ内ゲーム開発者は、アプリのレビューが低迷しているため、購入の負担を軽減したいと考えています。プレイヤーは購入したい商品の上にマウスを置くことができるようになりました。たとえば、プレイヤーが「ネオサングラス」の上にマウスを移動すると、API ゲートウェイを通じて仮想製品と購入機能がトリガーされます。各サーバーレス関数はデータベースを使用します。数秒以内に、選択したキャラクターはサングラスを着用します。サングラスはキャラクターの所有物となるため、自由に外したり、再び装着したりすることができます。

サーバーレスのユースケース

• ウェブアプリケーション
• 非同期メッセージ処理。たとえば、アプリケーションのユーザー インターフェイス (UI) の応答時間や正確なトランザクション履歴が重要です。
• 自動スケーリング機能を必要とするチャットボット
• 大規模ストリーム処理
• モバイルアプリケーションバックエンド
• バッチジョブ
• マルチメディア処理
• データ処理
• チャットボットとバーチャルアシスタント
• IT自動化

サーバーレスの利点

• 経費を削減します。 FaaS を使用すると、アプリケーションはサーバーなしで実行できるため、プロビジョニングや管理するサーバーはありません。
• 自動スケーリング。 Function as a Service (FaaS) は自動的にスケールアップまたはスケールダウンするため、顧客はアイドル容量に対して料金を支払う必要がありません。
• 高可用性。 Function as a Service (FaaS) と Backend as a Service (BaaS) の可用性は問題にならないため、アプリケーションの可用性は問題になりません。
• 選ぶ。 Function as a Service (FaaS) を使用すると、開発者は一般的な言語とライブラリを使用できます。
• 料金。プラットフォーム・アズ・ア・サービス (PaaS) やインフラストラクチャ・アズ・ア・サービス (IaaS) と同様に、サーバーレス クラウド コンピューティング プロバイダーはハードウェア要素とソフトウェア要素の両方を所有します。サーバー管理コストもアウトソーシングされます。
• 単純。 FaaS 機能のデプロイは、コードをアップロードするのと同じくらい簡単です。サーバーの展開には、スクリプトの作成とリソース指向の決定が伴います。
• スピード。サーバーレスではサーバーとその管理が不要になるため、貴重な IT 時間を節約できます。また、実験とプロトタイピングのスピードも向上します。

サーバーレスのデメリット

• 無国籍であり、無国籍である。 Function as a Service (FaaS) のステートレスな性質は、ステートフルな機能を使用するアプリケーション アーキテクチャにとって問題となる可能性があります。
• タイムアウト。アプリケーションにタイムアウト制限を超えるタスクが含まれている場合、Function as a Service (FaaS) タイムアウトはアプリケーション アーキテクチャに影響を及ぼす可能性があります。
• 起動遅延。 Function-as-a-Service (FaaS) の起動遅延により、アルゴリズム取引などの極めて機密性の高いユースケースが除外される可能性があります。
• サービスレベル契約。サービス レベル アグリーメント (SLA) の欠如は常に問題となってきました。 2018 年 10 月、AWS は Lambda の月間稼働率が 99.95% であると発表しました。
• 機能設定。 Function as a Service (FaaS) を構成する機能が制限される場合があります。
• 同時実行の制限。許可される同時 FaaS 機能の数には制限があります。同時テストと本番環境、共有エンタープライズ アカウント、複数のクラウド サービスにわたるアカウントが原因でこの数を超えると、本番環境アプリケーションのパフォーマンスが低下する可能性があります。
• Function as a Service (FaaS) の監視。ここでの 2 つの問題は、ベンダーが提供するデータの量と、一時的なコンテナを監視することの一般的な難しさです。
• ベンダーロックイン。クラウド コンピューティング プロバイダーは、他のプロバイダーへの移行を困難にしたいと考えています。プラットフォーム固有のツールと設計機能を異なるものにするには、2 つの方法があります。
• コントロール。プロバイダーはインフラストラクチャ、価格、機能などを完全に制御できます。
• 料金。サーバーレスは必ずしも他のオプションよりも安価であるとは限らないため、他のオプションと比較したコストと利点のトレードオフを理解しておくことが賢明です。 Function as a Service (FaaS) では、関数は呼び出されるまでコストがかかりません。

サーバーレスセキュリティ

• 攻撃対象領域が拡大します。エコシステム内のあらゆる新しい要素は、混乱の可能性を高めます。さらに、サーバーレス アプリケーションには、従来のアーキテクチャを使用するアプリケーションよりも多くのコンポーネントがあります。各コンポーネントは、アプリケーションへの固有のエントリ ポイントです。
• 機能ライセンス。場合によっては、権限を限定した方が賢明な場合でも、幅広い権限がさまざまな機能に適用されることがあります。
• マルチテナント。他のクライアントはエンタープライズ データを表示できないはずですが、表示できる可能性があります。これは、大手プロバイダーが積極的に取り組んでいる一般的なクラウド コンピューティングの問題です。
• サードパーティ ソフトウェアの依存関係。機能は侵害されたサードパーティ製ソフトウェアに依存している可能性があります。

サーバーレスアーキテクチャを始める

サーバーレス アーキテクチャを開始する正しい方法は、この記事で説明されているすべて、つまりサーバーレス アーキテクチャとは何か、その利点と欠点は何かを完全に理解し、適切なユースケースを定義することです。

具体的には、既存のアプリケーションにサーバーレス アプリケーションを追加する場合や、新しいサーバーレス アプリケーションを構築する場合は、次の点を考慮する必要があります。

• サーバーレスとは​​何か、またサーバーレスではないものは何かを学びます。
• 従来型のアーキテクチャのアプリケーションとサーバーレス アプリケーションの使用のトレードオフを理解します。
• サーバーレス アプリケーションを構築するか、既存のアプリケーションを変更して Backend as a Service (BaaS)、Function as a Service (FaaS)、またはその両方を活用するかを決定します。
• プロバイダーを選択します（おそらく企業が使用しているプロバイダーです）。

特に人気のあるサーバーレスソリューションである AWS Lambda を選択するとします。

• Lambda 関数を設定します (メモリとストレージの要件、トリガー、アクセス)。
• Amazon API Gateway をセットアップします。
• 既存のアプリケーションに適応するには、ワークフロー管理に AWS Step Functions を使用します。
• Amazon Identity Access Management および Cognito サービスを通じてアクセスとセキュリティを設定します。
• ログ記録と監視には、AWS Cloudwatch と X-Ray が使用されます。
• ローカルアプリケーションのテストが必要な場合は、AWS サーバーレスアプリケーションモデルを使用します。
• コンプライアンス要件を満たします。
• サーバーレス アーキテクチャ パターンを、同じ種類のアプリケーションの一般的なパターンと比較します。

サーバーレスアーキテクチャの管理方法

名前が示すように、サーバーレス クラウド サービスの場合、IT 部門はサーバーを管理しません。オンプレミスの Function-as-a-Service (FaaS) 実装 (Apache OpenWhisk、Kubeless、OpenFaaS によって有効化されるものなど) の場合、サーバーは内部で管理されます。

アプリケーションベースのクラウド コンピューティングの利点はオンプレミスの FaaS 実装には適用されませんが、より高いサーバー使用率を実現でき、開発者はサーバーレスによって提供される抽象化のメリットを享受できます。

ただし、アプリケーションの設計によっては、権限、セキュリティ、依存関係など、考慮すべき運用上の問題が依然として存在し、これらの問題は解消されません。

重要な質問は、「サーバーレスを管理するために必要な社内専門知識があるかどうか」です。今のところ、サーバーレスはまだ新興技術なので、社内のスタッフや開発者が専門家であると想定しないでください。

サーバーレスコンピューティングの未来

サーバーレス オプションの人気が高まるにつれて、次のようなことが起こる可能性があります。

• より多くの、より良いツール。それは市場の成熟度の問題であり、他の選択肢と比較した人気の機能でもあります。サーバーレスの人気が高まるにつれて、ツールやオープンソース プロジェクトも増えていきます。
• ベストプラクティス。サーバーレスは比較的新しい概念であるため、ベストプラクティスはまだ多くありませんが、サーバーレス アーキテクチャ パターンは、上記のユースケースの多くに使用できます。
• サーバーレスファーストのアプリケーション。ユースケースによっては、サーバーレス オプションを活用するためにアプリケーションを変更するのではなく、サーバーレス アプリケーションがさらに登場する可能性があります。
• フレーム。あるベンダーと他のベンダーと連携しやすくする追加のフレームワークが登場するでしょう。現在の例としては、コンテナネイティブのオープンソース フレームワークおよびサーバーレス フレームワークである Fn プロジェクトがあり、サーバーレス アプリケーションを複数の Function-as-a-Service (FaaS) プロバイダーにデプロイできます。
• プライベート Function as a Service (FaaS)。 Function as a Service (FaaS) はすでに企業内に実装されています。クラウド コンピューティング サービスやハイブリッド クラウド実装と比較して、これが主流になるかどうかは、時間が経てばわかるでしょう。