サービスとしての機能
 |
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 ]
移植性の問題
Function as a Service（FaaS）ワークロードは、ベンダー間の緊密な連携によるサービスロックインにより、移行の障害に直面する可能性があります。ヘキサゴナルアーキテクチャは、ワークロードの移植性を向上させます。[ 6 ]
参照
参考文献
- ^「ISO/IEC 22123-2:2023 (E) - 情報技術 - クラウドコンピューティング - パート2：概念」国際規格：25。
- ^ a b Brisals, Sheen (2024年2月). AWSでのサーバーレス開発：エンタープライズ規模のサーバーレスソリューションの構築. O'Reilly Media. ISBN 978-1098141936。
- ^ Richards, Mark (2015).マイクロサービスのアンチパターンと落とし穴. O'REILLY.
- ^ a b c「テクノロジーレーダー Vol. 21 – テクノロジーに関する独自のガイド」(PDF) .テクノロジーレーダー. 21 . ThoughtWorks.
- ^ a b c Fowler, Martin (2002年3月～4月). 「公開インターフェースと公開インターフェース」(PDF) . IEEE Software . 19 (2): 18– 19. doi : 10.1109/52.991326 .
- ^ Cui, Yan (2020). AWS におけるサーバーレスアーキテクチャ（第2版）. Manning. ISBN 978-1617295423。
