Java週間：パート4：関数のための多層コア

このシリーズの前回までの記事では、エミュレーションツールを用いた開発環境の構築や一般的な多層アーキテクチャの概要など、サーバーレスプロジェクトを確立するための基礎的なステップを探りました。本稿では、Function as a Microservice（FaaM）パラダイムに準拠したサーバーレスシステム開発に特化したデザインパターンの実装に焦点を当てます。\n\nサービスの粒度の問題は、分散コンピューティングの歴史とともに進化してきました。1970年代から80年代にかけて、リモートプロシージャコール（RPC）、CORBA、分散コンピューティング環境（DCE）などの初期統合アプローチが登場しましたが、ハイブリッド環境でのスケーラビリティや柔軟性には限界がありました。1990年代半ばにはサービス指向アーキテクチャ（SOA）が登場し、2000年代初頭にはSOAPベースの実装で広く普及しました。SOAは疎結合サービスを可能にし、ソフトウェア設計に革命をもたらしました。2010年代にはREST、イベント駆動アーキテクチャ（EDA）、マイクロサービスへと進化しましたが、サービスの理想的なサイズと範囲を決定する課題は依然として残っています。\n\n歴史的に、SOAは粗粒度サービスと細粒度サービスの2種類のサービス粒度を定義しました。粗粒度サービスは広範なビジネス機能を包含し、細粒度サービスは狭い範囲の機能に焦点を当てます。両極端には課題があり、大きな粗粒度サービスは扱いにくい「モノリス」になるリスクがあり、細粒度サービスは多数の小さく相互依存するコンポーネントを生み出し、スケーラビリティ、修正性、セキュリティを複雑化させます。サービス指向モデリングフレームワーク（SOMF）は、原子サービス（基本的で分割不可能な限定的プロセスを持つコンポーネント）、複合サービス（原子または他の複合サービスを階層的に集約）、クラスター（関連サービスのグループで広範なソリューションを目指す）という微妙な分類を提供します。\n\nこれらの概念をServerless FrameworkとAWS Lambdaを用いたサーバーレスコンピューティングの領域に翻訳すると、イベント、関数、サービスの3つの中心的構成要素を理解することが重要です。イベントは関数をトリガーし、関数は特定のタスクを実行するコードの断片を実行します。サービスはLambda関数のグループとそれらのトリガーイベントおよびインフラ要件をカプセル化します。Serverless Frameworkは通常、CRUD操作ごとに個別のLambda関数を作成することを推奨しており、例えばUserというエンティティは4つのLambda関数に対応します。この方法は単純ですが、スケールが悪く、10エンティティで40関数となり、それぞれの管理とAWS API Gatewayインスタンスの関連付けが運用負荷を増大させます。\n\nこの複雑さに対処するため、Function as a Microservice（FaaM）パターンが提案されています。ここでは、各Lambda関数が小さなクラスターとして機能し、複数の関連ビジネス機能を処理し、内部で様々な原子イベントをルーティングします。例えば、都市ごとの操作ごとに関数を分けるのではなく、地理位置関数が国、都市、地域のCRUD操作をまとめて管理します。モノリシックな肥大化を防ぐため、各関数はMillerの法則に基づき7±2エンティティ以内を理想とし、各関数が特定のデータソースの単独責任を持つことを前提とします。\n\nAWS LambdaでFaaMを実装するには、各Lambda関数が単一のエントリハンドラーしか持たない制約の下で効率的なルーティング機構が必要です。クライアント-ディスパッチャ-サーバーパターンは、URIパスに基づいて着信リクエストを適切な関数に振り分けるのに役立ちます。例えば、/movieへのHTTPリクエストは映画関連操作を処理する関数にルーティングされます。このパターンを用いることで、ユーザー、地理位置、投稿など複数の論理サービスが同じハンドラーコードを共有しつつ、内部でルーティングにより処理を区別できます。この方法はLambda関数とAPI Gatewayエンドポイントの数を減らし、管理を簡素化しつつビジネスドメインの明確な境界を維持します。\n\n実際には、Serverless Frameworkの設定で複数のHTTPイベントが同一ハンドラーを指す複数のサービスを定義することがあります。例えば、ユーザーのログイン、ログアウト、サインアップエンドポイント、地理位置の各種エンドポイント、投稿のCRUD操作などです。共有ハンドラー内のルーティングロジックはイベントのURIとメソッドを検査し、適切なビジネスロジックモジュールを呼び出します。この戦略はハンドラーコードの重複を避け、保守性を高め、サーバーレスアーキテクチャ内でのモジュール的成長を可能にします。