ISO/IEC 22123-2によると、サーバーレスコンピューティングとは、「顧客がハードウェアまたはソフトウェアリソースのプロビジョニング、展開、管理を行うことなく、顧客が様々なクラウド機能を利用できるクラウドサービスカテゴリーです。サーバーレスコンピューティングは、仮想化コンピューティングの一形態です。」[1] シーン・ブリサルズ氏によると、サーバーレスコンピューティングは、クラウドプロバイダー、Function as a Service（FaaS）、マネージドサービス、ツール、フレームワーク、エンジニア、ステークホルダー、その他の相互接続された要素を含む広範なエコシステムです。[2]

概要

サーバーレスとは​​、クラウドサービスプロバイダーが開発者向けのコード実行に依然としてサーバーを使用しているという意味で、誤った名称です。サーバーレスコンピューティングの定義は時間の経過とともに進化し、多様な解釈が生まれています。ベン・キーホー氏によると、サーバーレスとは​​厳密な定義ではなく、幅広い範囲を指すものです。厳密な定義や特定の技術に重点を置くのではなく、サーバーレスの考え方を取り入れ、サーバーレスソリューションを活用してビジネス課題に対処することに重点を置くべきです。[3]

サーバーレスコンピューティングは複雑さを解消するものではなく、運用チームから開発チームへと多くの複雑さを移行させます。しかし、運用チームは引き続きアイデンティティおよびアクセス管理（IAM）、ネットワーク、セキュリティポリシー、コスト最適化といった側面を管理するため、この移行は絶対的なものではありません。さらに、アプリケーションをより細分化されたコンポーネントに分割すると管理の複雑さが増す可能性がありますが、粒度と管理の難易度の関係は必ずしも直線的ではありません。多くの場合、モジュール化には最適なレベルがあり、そのメリットが管理オーバーヘッドの増加を上回ることがあります。[4] [2]

Yan Cui氏によると、サーバーレスは顧客価値をより迅速に提供できる場合にのみ導入すべきです。そして、導入にあたっては、組織は小さなステップを踏みながら、リスクを軽減していく必要があります。[5]

課題

サーバーレスアプリケーションは分散コンピューティングに関する誤解に陥りやすい。さらに、以下のような誤解にも陥りやすい。[6] [7]

監視とデバッグ

サーバーレスアプリケーションの監視とデバッグは、分散型、イベント駆動型、そして独自の環境という特性上、特有の課題を抱える場合があります。従来のツールでは不十分な場合があり、サービス間の実行フローの追跡が困難になることがあります。しかし、分散トレースツール（AWS X-Ray、Datadogなど）、集中ログ、クラウドに依存しない可観測性プラットフォームといった最新のソリューションは、これらの課題を軽減しています。OpenTelemetry、AIを活用した異常検知、サーバーレスに特化したフレームワークといった新興技術は、可視性と根本原因分析をさらに向上させています。課題は依然として残っていますが、監視およびデバッグツールの進歩により、これらの限界は着実に解決されつつあります。[8] [9]

安全

OWASPによると、サーバーレスアプリケーションは、従来の攻撃のバリエーション、安全でないコード、そしてサーバーレス特有の攻撃（ウォレット拒否攻撃など[10]）に対して脆弱です。つまり、リスクは変化しており、攻撃の防止には考え方の転換が必要です。[11] [12]

ベンダーロックイン

サーバーレスコンピューティングはサードパーティサービスとして提供されます。サーバーレス環境で実行されるアプリケーションやソフトウェアは、デフォルトで特定のクラウドベンダーにロックされます。この問題はサーバーレスコンピューティングにおいてさらに深刻化します。抽象化レベルが高まっているため、パブリックベンダーは顧客がFaaSプラットフォームにコードをアップロードすることしか許可せず、基盤となる環境を構成する権限を与えないからです。さらに重要なのは、バックエンド・アズ・ア・サービス（BaaS）を含むより複雑なワークフローを考えると、BaaSサービスは通常、同じプロバイダーのFaaSサービスをネイティブに起動することしかできないということです。そのため、サーバーレスコンピューティングにおけるワークロードの移行は事実上不可能です。したがって、マルチクラウドの観点からサーバーレスワークフローの設計と展開方法を検討することで、この問題を軽減できる可能性があります。[13] [14] [15]

高性能コンピューティング

サーバーレスコンピューティングは、クラウドプロバイダーによって最大メモリ、CPU、ランタイム制限など、リソース制限が課せられることが多いため、特定の高性能コンピューティング（HPC）ワークロードには適さない場合があります。持続的または予測可能なリソース使用量を必要とするワークロードの場合、サーバーレスプラットフォームに典型的な従量課金モデルよりも、一括プロビジョニングされたサーバーの方が費用対効果が高い場合があります。しかし、サーバーレスコンピューティングは、その拡張性と弾力性を活用することで、特に高度な並列化とイベント駆動型のワークロードなど、特定のHPCワークロードをサポートできる能力が高まっています。HPCにおけるサーバーレスコンピューティングの適合性は、クラウド技術の進歩とともに進化し続けています。[16] [17] [18]

アンチパターン

「砂粒アンチパターン」とは、システム内に過度に小さなコンポーネント（関数など）を作成することを指し、多くの場合、複雑さの増加、運用オーバーヘッド、パフォーマンスの非効率性につながります。[19]「ラムダピンボール」は、サーバーレスアーキテクチャで関数（AWS Lambda、Azure Functionsなど）が断片化されたチェーンで過度に互いを呼び出す場合に発生する可能性のある関連するアンチパターンであり、レイテンシ、デバッグとテストの課題、および観測性の低下につながります。[20]これらのアンチパターンは、分散モノリスの形成に関連しています。

これらのアンチパターンは、多くの場合、公開インターフェースと公開インターフェースを区別する明確なドメイン境界を適用することで対処されます。[20] [21]公開インターフェースは、メソッド、クラス、APIエンドポイント、トリガーなど、技術的にアクセス可能なインターフェースですが、正式な安定性の保証はありません。一方、公開インターフェースには、正式なバージョン管理、徹底したドキュメント、明確な非推奨ポリシー、そして多くの場合、後方互換性のサポートなど、明示的な安定性契約が締結されています。公開インターフェースでは、複数のバージョンを同時に維持し、互換性を破る変更が導入された場合には、正式な非推奨プロセスに従うことが求められる場合もあります。[21]

関数呼び出しの断片化された連鎖は、サーバーレスコンポーネント（関数）が他のリソースと複雑なパターンで相互作用するシステムでよく見られ、スパゲッティアーキテクチャや分散モノリスと呼ばれることもあります。対照的に、より明確な境界を持つシステムでは、サーバーレスコンポーネントがまとまりのあるグループに編成され、内部の公開インターフェースがコンポーネント間の通信を管理し、公開インターフェースがグループ境界を越えた通信を定義します。この違いは、安定性の保証と保守のコミットメントの違いを浮き彫りにし、依存関係の複雑さの軽減に貢献します。[20] [21]

さらに、過剰なサーバーレス関数チェーニングに関連するパターンは、個々の関数ではなくネイティブサービス統合を重視するアーキテクチャ戦略によって対処されることがあります。これは「関数レス・マインドセット」と呼ばれる概念です。しかし、このアプローチは学習曲線が急峻であること、そして同じクラウドベンダーのエコシステム内であっても統合の制限が異なる可能性があることが指摘されています。[2]

サーバーレスデータベースでのレポート作成には課題があります。レポートサービス用のデータを取得すると、境界付きコンテキストが破壊されるか、データの適時性が低下するか、あるいはその両方が発生する可能性があるためです。これは、データがデータベースから直接取得されるか、HTTP経由で取得されるか、あるいはバッチで収集されるかに関係なく当てはまります。マーク・リチャーズはこれを「リーチイン・レポート・アンチパターン」と呼んでいます。[19]このアプローチの代替案として、レポートサービスがデータを取得するのではなく、データベースが必要なデータを非同期的にレポートサービスにプッシュする方法があります。この方法では、サービスとレポートサービスの間に個別の契約が必要になり、実装が複雑になる可能性がありますが、境界付きコンテキストを維持しながら、高いレベルのデータの適時性を維持するのに役立ちます。[19]

原則

DevSecOpsプラクティスを採用することで、サーバーレス技術の利用とセキュリティを向上させることができます。[22]

サーバーレスアプリケーションでは、インフラストラクチャとビジネスロジックの区別が曖昧になることが多く、アプリケーションは通常複数のサービスに分散されます。テストの有効性を最大化するために、サーバーレスアプリケーションでは統合テストが重視されます。[5]さらに、デバッグと実装を容易にするために、境界付けられたコンテキスト内ではオーケストレーションが使用され 、異なる境界付けられたコンテキスト間では振り付けが採用されます。[5]

エフェメラルリソースは通常、高い凝集性を維持するためにまとめて管理されます。しかし、 AWS RDSクラスターやランディングゾーンなど、スピンアップに長い時間がかかる共有リソースは、別々のリポジトリ、デプロイメントパイプライン、スタックで管理されることがよくあります。 [5]

参照

参考文献

  1. ^ 「ISO/IEC 22123-2:2023 (E) - 情報技術 - クラウドコンピューティング - パート2：概念」国際規格：25。
  2. ^ abc Brisals, Sheen. AWS でのサーバーレス開発：エンタープライズ規模のサーバーレスソリューションの構築. O'Reilly Media. ISBN 978-1098141936。
  3. ^ エミソン、ジョセフ (2023). 「ゲームチェンジャーとしてのサーバーレス：クラウドを最大限に活用する方法」Addison-Wesley Professional. ISBN 9780137392551。
  4. ^ ソフトウェアアーキテクトエレベーター：デジタル企業におけるアーキテクトの役割の再定義. O'Reilly Media. 2020. ISBN 978-1492077541。
  5. ^ abcd Cui, Yan (2020). AWS におけるサーバーレスアーキテクチャ（第2版）. Manning. ISBN 978-1617295423。
  6. ^ リチャーズ、マーク（2020年3月3日）。『ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ』（第1版）。オライリーメディア。ISBN 978-1492043454。
  7. ^ リチャーズ、マーク (2021). 『ソフトウェアアーキテクチャ：ハードパーツ：分散アーキテクチャの最新トレードオフ分析』（第1版）. O'Reilly Media. ISBN 978-1492086895。
  8. ^分散トレースの実践：マイクロサービスの計測 、分析、デバッグ。O'Reilly Media。ISBN 978-1492056638。
  9. ^ OpenTelemetryによるクラウドネイティブな可観測性：OpenTelemetryを使用してトレース、メトリクス、ログ記録を組み合わせることで、システムの可視性を高める方法を学びます。ISBN 978-1801077705。
  10. ^ Kelly, Daniel; Glavin, Frank G.; Barrett, Enda (2021-08-01). 「ウォレットの拒否：サーバーレスコンピューティングへの迫り来る脅威の定義」. Journal of Information Security and Applications . 60 102843. arXiv : 2104.08031 . doi :10.1016/j.jisa.2021.102843. ISSN  2214-2126.
  11. ^ 「OWASP Serverless Top 10 | OWASP Foundation」。owasp.org 。2024年5月20日閲覧。
  12. ^ OWASP/Serverless-Top-10-Project、OWASP、2024年5月2日、 2024年5月20日取得
  13. ^ Aske, Austin; Zhao, Xinghui (2018-08-13). 「エッジにおけるマルチプロバイダー・サーバーレスコンピューティングのサポート」.第47回国際並列処理コンパニオン会議議事録. ICPPワークショップ '18. ニューヨーク州ニューヨーク: Association for Computing Machinery. pp.  1– 6. doi :10.1145/3229710.3229742. ISBN 978-1-4503-6523-9. S2CID  195348799。
  14. ^ Baarzi, Ataollah Fatahi; Kesidis, George; Joe-Wong, Carlee; Shahrad, Mohammad (2021-11-01). 「マルチクラウド・サーバーレスのメリットと実現可能性について」ACM Symposium on Cloud Computing Proceedings . SoCC '21. ニューヨーク州ニューヨーク：Association for Computing Machinery. pp.  600– 608. doi :10.1145/3472883.3487002. ISBN 978-1-4503-8638-8. S2CID  239890130。
  15. ^ Zhao, Haidong; Benomar, Zakaria; Pfandzelter, Tobias; Georgantas, Nikolaos (2022年12月6日). 「サーバーレスコンピューティングにおけるマルチクラウドのサポート」. 2022 IEEE/ACM 第15回国際ユーティリティ・クラウドコンピューティング会議 (UCC) . pp.  285– 290. arXiv : 2209.09367 . doi :10.1109/UCC56403.2022.00051. ISBN 978-1-6654-6087-3. S2CID  252383217。
  16. ^ サーバーレスコンピューティング：原則とパラダイム. Springer. 2023年5月12日. ISBN 978-3031266324。
  17. ^ フォスター、イアン、ギャノン、デニス・B（2017年9月29日）『科学技術のためのクラウドコンピューティング』（科学技術計算） MITプレス、ISBN 978-0262037242。
  18. ^ Hellerstein, Joseph; Faleiro, Jose; Gonzalez, Joseph; Schleier-Smith, Johann; Screekanti, Vikram; Tumanov, Alexey; Wu, Chenggang (2019), Serverless Computing: One Step Forward, Two Steps Back , arXiv : 1812.03651
  19. ^ abc Richards, Mark (2015).マイクロサービスのアンチパターンと落とし穴. O'REILLY.
  20. ^ abc 「TECHNOLOGY RADAR VOL. 21 テクノロジーに関する独自のガイド」(PDF) . Technology Radar . 21 . ThoughtWorks.
  21. ^ abc Fowler, Martin (2002年3月～4月). 「公開インターフェースと公開インターフェース」(PDF) . IEEEソフトウェア. 19 (2): 18– 19. doi :10.1109/52.991326.
  22. ^ Katzer, Jason (2020). 『Learning Serverless: Design, Develop, and Deploy with Confidence』O'Reilly Media. ISBN 978-1492057017。

さらに読む

  • Roberts, Mike (2016年7月25日). 「サーバーレスアーキテクチャ」. MartinFowler.com . 2016年7月30日閲覧。
  • ジェイミーソン、フレイザー（2017年9月4日）「サーバーがなくなる？誰もがサーバーレスアーキテクチャについて語っている」BCS（英国公認IT協会）. 2017年11月7日閲覧。
  • アンダーソン、デイビッド（2022年3月9日）「『バリュー・フライホイール効果』で未来を力づけ、組織をモダンクラウドとサーバーレスへと加速」The Serverless Edge 。 2022年3月9日閲覧。
  • カリフォルニア大学バークレー校の14名の著者（2019年2月9日）。「クラウドプログラミングの簡素化：バークレー校のサーバーレスコンピューティングに関する見解[1]」
  1. ^ Jonas, Eric (2019年2月). 「クラウドプログラミングの簡素化：サーバーレスコンピューティングに関するBerkeleyの見解」pp.  1– 33. arXiv : 1902.03383 [cs.OS].