Loading article…
ISO/IEC 22123-2によると、 Function as a Serviceは「プラットフォームレベルのクラウド機能」であり、ユーザーは「拡張性のために初期投資を少なくしてマイクロサービスアプリケーションを構築および管理する」ことができる。[ 1 ]
Function as a Service は、サーバーレスコンピューティングエコシステムのサブセットです。[ 2 ]
「砂粒アンチパターン」とは、システム内で過度に小さなコンポーネント（関数など）を作成することを指し、多くの場合、複雑性の増加、運用上のオーバーヘッド、およびパフォーマンスの非効率性につながります。[ 3 ]「ラムダピンボール」は、サーバーレスアーキテクチャで関数（AWS Lambda、Azure Functionsなど）が断片化されたチェーンで過剰に互いを呼び出す場合に発生する関連アンチパターンであり、レイテンシ、デバッグとテストの課題、および可観測性の低下につながります。[ 4 ]これらのアンチパターンは、分散モノリスの形成に関連しています。
これらのアンチパターンは、公開インターフェースと公開インターフェースを区別する明確なドメイン境界を適用することによって対処されることが多い。[ 4 ] [ 5 ]公開インターフェースは、メソッド、クラス、APIエンドポイント、トリガーなど、技術的にアクセス可能なインターフェースであるが、正式な安定性の保証は付帯しない。対照的に、公開インターフェースには、正式なバージョン管理、徹底したドキュメント、定義された非推奨ポリシー、そして多くの場合、後方互換性のサポートを含む、明示的な安定性契約が伴う。公開インターフェースでは、破壊的変更が導入された場合、複数のバージョンを同時に維持し、正式な非推奨プロセスに従う必要がある場合もある。[ 5 ]
サーバーレス コンポーネント (関数) が複雑なパターンで他のリソースと相互作用するシステムでは、関数呼び出しの断片的な連鎖がよく見られます。これは、スパゲッティ アーキテクチャや分散モノリスと呼ばれることもあります。対照的に、境界がより明確なシステムでは、通常、サーバーレス コンポーネントがまとまりのあるグループに編成され、内部のパブリック インターフェイスがコンポーネント間の通信を管理し、公開インターフェイスがグループ境界を越えた通信を定義します。この違いは、安定性の保証と保守のコミットメントの違いを浮き彫りにし、依存関係の複雑さの軽減に貢献します。[ 4 ] [ 5 ]
さらに、過剰なサーバーレス関数チェーンに関連するパターンは、個々の関数ではなくネイティブサービスの統合を重視するアーキテクチャ戦略によって対処されることがあり、これは「関数レス思考」と呼ばれる概念です。ただし、このアプローチは学習曲線が急峻であり、統合の制限は同じクラウドベンダーのエコシステム内でも異なる場合があることが指摘されています。[ 2 ]
サービスとしての機能ワークロードは、ベンダーとの緊密な統合によるサービスロックインのために移行の障害に直面する可能性があります。ヘキサゴナルアーキテクチャはワークロードの移植性を向上させることができます。[ 6 ]