http://microservices.io/patterns/apigateway.html を読んだ。思考の整理がてらにまとめようと思う。
マイクロサービスアーキテクチャーとは
API Gateway Patternは基本的に対象とするサービスがマイクロサービスアーキテクチャーで構成されている場合に適用できる。
サーバーサイドエンジニアとして会員制のECサイトを構築する場合を考えてみよう。このサービスはWebブラウザ、スマートフォンアプリからアクセスすることが想定されており、また第三者向けにAPIの提供も予定されている。また、開発されたAPIは他のAPIから呼び出される事も想定されている。この際、問題として、どのようにアーキテクチャーを構成するのがベスト・プラクティスであるのかという問題が浮かび上がってくる。そのベスト・プラクティスの一つがサーバーレスアーキテクチャーである。
個々の機能を構成する関数は疎結合であり、互いに影響を及ぼすという場合、サービスのバックエンドはこれらの関数の集合と考えることが出来る。マイクロサービスアーキテクチャーとは、「それぞれの個々の関数が独立して開発され、デプロイされるべきである」という、一つの設計パターンなのである。なお、それぞれの関数は、個々の関数の独立性を高めるために、それぞれ異なったデータベースを保持する。サービス間のデータの一貫性はSaga Patternと呼ばれるデザインパターンによって成し遂げられる。らしい。
で、API Gateway Patternって結局何なのか?
先程提示したECサイトの場合、あらゆるインターフェースからのアクセスを想定している。この場合、Webブラウザからアクセスする場合はサーバーサイドでHTMLを返却するように、スマートフォンアプリからアクセスする場合はREST APIから返却するデータを基にスマートフォンアプリ側で情報を整形して表示するという形になる。マイクロサービスアーキテクチャーを採用する大規模なECサイトの場合、情報を取得するために多くの関数を呼び出す必要がある。この場合、どのようにすればクライアントサイドからマイクロサービスアーキテクチャーで構成された個々の関数を呼び出すのがベスト・プラクティスなのかという問題が発生する。この問題の一つの解決策がAPI Gateway Patternだと言える。AWSを用いたアーキテクチャーが以下のようになる。
API Gateway Patternは、すべてのインターフェースを含むクライアントサイドとデプロイされた関数の間にAPI Gatewayと呼ばれるエントリーポイントを設置するというAPIの設計方法である。クライアントサイドからAPI Gatewayに設置されたAPIをコールし、API Gatewayにマイクロサービスアーキテクチャーで構成された複数の関数にアクセスさせる。API Gatewayはクライアントサイドから見てサーバーサイドAPIの透明性を高めるために設置された中継機器だと捉える事が出来る。
インターフェース毎にそれぞれ異なったAPI Gatewayを用意するというアーキテクチャーもAPI Gateway Patternの変則パターンとして存在する。
なお、API Gatewayを採用する場合、関数への中継を果たすために、以下の性質を持つ。
- Client-side Discovery PatternやServer-side Discovery Patternといったものを用いる。
- API Gatewayはユーザーの認証情報をアクセストークンという形で保持する事が多い。
- API Gatewayは個々の関数を起動するために、Circuit Breakerと呼ばれるものを使用する。
- API GatewayはAPI Composition Patternに則って実装される。
今回説明しなかったパターンに関しては後ほどの記事でまとめたい。