【ITニュース解説】Serverless Dashboard Architecture Using AWS Lambda, API Gateway, and GitHub Actions

このニュース記事は、AWS（アマゾン ウェブ サービス）のクラウドサービスを活用して、複数の機能を持つダッシュボードをサーバーレスアーキテクチャで構築したプロジェクトについて解説している。サーバーレスとは、開発者がサーバーの構築や運用といった管理作業を直接行うことなく、アプリケーションのコードを動かせる仕組みを指す。このモデルでは、必要な時にだけコンピューティングリソースが提供され、使用した分だけ料金が発生するため、コスト効率が良く、高い可用性（システムが常に利用可能であること）とスケーラビリティ（負荷が増えても対応できる能力）を実現しやすいというメリットがある。

構築されたダッシュボードには、「ExpenseApp（費用管理）」「WeatherApp（天気予報）」「NewsApp（ニュース）」「GitHubApp（GitHub連携）」といった様々なアプリケーションが含まれている。これらのアプリケーションのバックエンド（ユーザーからは見えない裏側の処理）は、すべてAWS Lambdaというサービス上で動作している。外部からのリクエストは、API Gatewayというサービスを通じて受け付けられ、適切なLambda関数にルーティング（振り分け）される。特にExpenseAppのようにデータを永続的に保存する必要があるアプリケーションでは、DynamoDBというNoSQLデータベースが利用されている。さらに、開発プロセスを効率化するため、GitHub Actionsというツールを使って、コードの変更が自動的にテストされ、デプロイされるCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインが構築された。

プロジェクトの技術スタックを見てみると、ユーザーインターフェースとなるフロントエンドはTypeScriptというプログラミング言語で開発された。今回はインフラストラクチャの構築に焦点を当てるため、フロントエンドの一部はAIツールを活用して効率的に作成されたという。バックエンドの各アプリケーションロジックはPythonで記述され、AWS Lambda関数として実装されている。Lambdaは、WebからのAPIリクエストのような特定のイベントが発生したときにのみコードを実行し、実行時間に対してのみ課金されるため、サーバーを常時稼働させておく必要がなく、コストを大幅に削減できる点が大きな特徴である。

API Gatewayは、インターネットからのHTTPリクエストを受け取り、それを適切なLambda関数などのバックエンドサービスに転送する役割を担う。例えば、ダッシュボードのURLに「/ExpenseApp」というパスが含まれていればExpenseAppのLambda関数に、同様に「/WeatherApp」であればWeatherAppのLambda関数にリクエストが送られるといった具合だ。これは、アプリケーションへの外部からの「入り口」であり、リクエストを適切な処理へと導く「交通整理役」として機能する。データストレージとしては、ExpenseAppのユーザーデータを保存するためにAmazon DynamoDBが使用された。DynamoDBは、柔軟なデータモデルを持つ高速なNoSQLデータベースであり、このプロジェクトでは利用量に応じて自動的にキャパシティを調整する「オンデマンドキャパシティモード」が選択された。これにより、アプリケーションのトラフィックが少ないうちはAWSの無料利用枠内で運用でき、費用を抑える工夫がされている。

セキュリティはクラウド環境において非常に重要であり、このプロジェクトでもIAM（Identity and Access Management）というAWSのサービスを使って、各リソース（Lambda関数、API Gateway、DynamoDBなど）へのアクセス権限が厳密に管理された。具体的には、専用のIAMユーザーを作成し、そのユーザーには各アプリケーションが機能するために必要な最小限の権限のみが付与された。この「最小権限の原則」は、セキュリティリスクを低減するための基本的な考え方である。例えば、Lambda関数がDynamoDBのデータにアクセスする必要がある場合、そのLambda関数にはDynamoDBへの読み書き権限を持つIAMロールが割り当てられる。

プロジェクトの具体的な実装段階では、いくつかの課題に直面し、それを解決している。API GatewayとLambda関数の統合では、リクエストのパス設定の不一致が問題となった。API Gatewayが特定のパス（例: 「/ExpenseApp」）を期待しているにもかかわらず、Lambda関数が汎用的なルートパス（「/」）で定義されていたため、正しく連携できなかったのである。この設定ミスは、パスを一致させることで解決された。

もう一つの重要な課題は、CORS（Cross-Origin Resource Sharing）の設定だった。CORSは、Webブラウザが異なるドメイン（オリジン）からWebリソースへのアクセスを制限するセキュリティメカニズムである。ダッシュボードのフロントエンドとバックエンドが異なるドメインで動作する場合、このCORS設定を正しく行わないと、ブラウザはバックエンドへのリクエストをセキュリティ上の理由でブロックしてしまう。当初はAPI Gatewayの最上位リソースでCORSを有効にすればよいと考えられたが、実際には「/ExpenseApp」のような各子リソースでも個別にCORSを有効にする必要があった。さらに、Lambda関数自体もHTTPレスポンスに「Access-Control-Allow-Origin」などの適切なCORS関連ヘッダーを含めて返すように修正する必要があった。AWS CLI（コマンドラインインターフェース）を使ってこれらのヘッダーを設定しようとした際には、コマンドライン上での引用符の扱いに問題があり、最終的にはヘッダー情報を別のJSONファイルに記述し、そのファイルをCLIコマンドから参照するという工夫が用いられた。

手動でのデプロイや設定作業は、繰り返し行うと時間と手間がかかり、人的ミスも発生しやすいため、このプロジェクトではAWS CLIを活用してインフラのデプロイプロセス全体を自動化した。deploy_infra.shというシェルスクリプトを作成し、この単一のスクリプトでIAMロールの作成、Lambda関数のデプロイ（コードの圧縮や秘密のAPIキーの安全な管理を含む）、そしてAPI Gatewayの詳細な設定（ルーティングや複雑なCORS設定を含む）をすべて自動で実行できるようにした。このスクリプトは、既にリソースが存在するかを事前にチェックする機能も持ち、不要な再作成を防ぐ。この自動化により、通常15分以上かかっていた手動設定作業が、たった一つのコマンドで完了するようになり、開発効率が大幅に向上した。

最後に、GitHub Actionsを用いたCI/CDパイプラインについても言及する。これは、開発者がGitHubリポジトリにコードの変更をプッシュするたびに、事前に定義された一連のタスク（コードのテスト、ビルド、デプロイなど）を自動で実行する仕組みである。このプロジェクトでは、バックエンドのLambda関数が自動的にデプロイされ、フロントエンドのコードもビルドされてAmazon S3というオブジェクトストレージサービスに自動的にアップロードされる。これにより、開発者はインフラのデプロイ作業に煩わされることなく、コードの記述と機能開発に集中できるようになった。

このマルチアプリケーションダッシュボードプロジェクトを通じて、サーバーレスアーキテクチャの設計と実装、AWS Lambda、API Gateway、DynamoDBといった主要なクラウドサービスの具体的な活用方法、そしてGitHub Actionsによるデプロイの自動化といった、クラウドエンジニアリングの重要なスキルを実践的に習得できたことが示されている。今後の展望としては、AWS CDKやTerraformのようなInfrastructure-as-Code（IaC）ツールを用いて、インフラの構築と管理をコードとして扱うことで、さらなる自動化と効率化を目指すことが計画されている。