OpenAI APIのmockサービス part2: アーキテクチャー
OpenAI APIのmockサービスのアーキテクチャー：AWSの特性を活用
前回の投稿でOpenAI APIのmockサービス openai-mockの開発経緯とその特性について紹介しました。
今回は、そのmockサービスのアーキテクチャについて深掘りし、特にAWSの各サービスをどのように活用したかを説明します。
AWSの採用
AWSを採用しました。AWSは、豊富なサービスを提供しているので、どのサービスを選び、どのように組み合わせるかが重要なポイントとなります。AWSの持つ多様性と柔軟性は、今後の拡張性も考えると自然な選択です。
リクエスト回数課金になるように構成
このmockサービスは、高頻度でのアクセスが予想されるブログのようなサービスではありません。主にユニットテストの実行時や、GitHub Actionsによるソースコードのコミット時に呼び出されます。そのため、大部分の時間は非アクティブな状態になります。時間課金のサービスを利用すると、非活動時間がコストとして発生するため、ここではリクエスト回数に基づいた課金を行うサーバーレスのAWSサービスを選択しました。
利用したAWSサービスとその理由
以下のAWSサービスを利用しています。Lambdaで利用している言語はPythonです：
各サービスを選択した理由を詳しく説明します：
- AWS Certificate Manager：自動更新機能のあるTLS証明書が必要だったため、Certificate Managerを選択しました。これにより、セキュリティの維持と管理の手間を削減できました。
- Amazon CloudFront：カスタムドメインのTLS証明書を設定し、安全な配信を実現するためにCloudFrontとCertificate Managerの組み合わせを選択しました。CloudFrontにTLS証明書をリンクすることで、同じドメインで静的コンテンツとAPIを共存させることが可能になりました。
- Amazon S3：静的なコンテンツ、特にAPIリファレンスマニュアルをホストするためにS3を選択しました。S3とCloudFrontを組み合わせることで、セキュアなコンテンツ配信が可能になりました。
- AWS Lambda：このサービスは呼び出し回数に基づいて課金されるため、Lambdaを選択しました。このような課金モデルは、アクティビティが不規則なmockサービスにとって最適です。
- Amazon API Gateway：Lambdaで実装したWebAPIにレートリミット（スロットリング）を設けるためにAPI Gatewayを利用しました。API Gatewayは全体のアクセスに対するスロットリングを設定することができ、高額な請求を防ぐために10リクエスト/秒の制限を設定しました。また、OpenAIのWebAPIの模倣を柔軟に実現するために、「REST API」ではなく「HTTP API」を選択しました。
最終的なアーキテクチャ
以下の図に示すように、APIリファレンスマニュアルはS3に配置し、CloudFrontから配信しています。APIのロジックはPythonのFastAPIフレームワークで実装し、API Gatewayの「HTTP API」を使ってLambdaに統合しています。TLS証明書はCertificate Managerで取得し、自動更新機能を利用しています。
最後に
以上が、今回開発したmockサービスの裏側にあるアーキテクチャとAWSの各サービスの活用法についての説明です。AWSのサービスは一つ一つが機能豊富で、ドキュメントを読むだけでも大変な作業です。それらを組み合わせて使用するとさらに複雑さが増しますが、適切に活用すれば大きな恩恵を受けることができます。この記事が皆さんのプロジェクトに役立つようであれば幸いです。
Discussion