045-AWS SAP AWS 「理論・実践・一問道場」Webhook

type

status

date

slug

summary

理論

1. Gitリポジトリ

Gitリポジトリとは、ソフトウェアのコードやプロジェクトの履歴を管理するための場所です。Gitはバージョン管理ツールで、コードの変更履歴を追跡したり、チームでコードを共同作業する際に役立ちます。

簡単に言うと、Gitリポジトリは「コードの保管庫」や「コードの歴史を記録する場所」です。

2. Webhook

Webhookは、あるイベントが発生したときに、自動的に指定されたURLにHTTPリクエストを送信する仕組みです。これにより、異なるシステムやサービスがリアルタイムで連携できます。

例として、Gitリポジトリでコードを更新したときに、その情報を別のシステム（例えばデプロイ用のサーバーや通知サービス）に送信するためにWebhookが使われます。

具体的な流れは以下のようになります：

Gitリポジトリでコードの変更があったとき

Webhookがその情報を指定されたURL（例えば、APIエンドポイントやサーバー）に自動で送信

受け取ったサーバーはその情報を基に、例えば自動的にコードをデプロイしたり、通知を行ったりします

Webhookは、外部のシステムにイベントを通知するために利用され、リアルタイムでの連携を助けます。

Webhookロジックとは、Webhookが送信したリクエストを受け取って処理する一連の操作や機能のことを指します。具体的には、Webhookから送られてくるデータを元に何らかのアクションを実行する部分です。

Webhookロジックの流れ

Webhookリクエストの受信

Gitなどの外部システムからWebhookがトリガーされ、指定されたURLにHTTPリクエストが送信されます。このリクエストには、変更された内容やその他の情報が含まれています。

リクエストの処理

Webhookロジックは、リクエストを受け取って、その内容を解析します。例えば、Gitのリポジトリでコードが変更されたことを示す情報を処理し、必要な操作を実行します。

アクションの実行

Webhookロジックは、受け取った情報に基づいて、次のアクションを実行します。例えば、次のようなことが考えられます：

コードのデプロイ

自動テストの実行

チームへの通知

結果の返却（必要に応じて）

Webhookロジックが処理を完了した後、結果を呼び出し元に返すこともあります。例えば、「成功した」とか「エラーが発生した」といったステータスを返すことがあります。

例

GitのWebhookの場合、リポジトリにコードがプッシュされると、Webhookが呼び出され、そのリクエストに基づいてCI/CD（継続的インテグレーション／継続的デリバリー）のツールが自動的にコードをビルドしたり、テストを実行したりします。この処理がWebhookロジックです。

Webhookロジックは、主にWebhookを受けて実行する必要がある機能やアクションを含んでおり、他のシステムと自動で連携するために非常に重要な役割を果たします。

3.AWS App Runner

AWS App Runner は、開発者がコードを簡単にコンテナ化して、スケーラブルな Web アプリケーションや API を運用できるフルマネージドのサーバーレスサービスです。App Runner を使用することで、インフラの管理を意識せずにアプリケーションのデプロイとスケーリングが可能になります。

主な特徴

サーバーレス運用: サーバーの管理を必要とせず、アプリケーションを自動的にスケールさせます。

簡単なデプロイ: GitHub や Amazon ECR からソースコードやコンテナイメージを直接デプロイできます。

自動スケーリング: トラフィックの需要に応じて、アプリケーションのインスタンス数が自動でスケールします。

簡単な設定: アプリケーションのデプロイや管理が簡単で、インフラ設定やオーケストレーションを気にする必要がありません。

使い方

GitHub / GitLab などのリポジトリを連携して、コードを自動的にデプロイ。

コンテナイメージ（例えば Amazon ECR から）を使用して、アプリケーションを直接デプロイ。

App Runner は、サーバーレスの利便性と簡易性を提供し、インフラ管理の負担を軽減するため、特に Web アプリケーションや API に向いています。

以下は ECS、EKS、AWS App Runner の簡単な比較です。

特徴	Amazon ECS	Amazon EKS	AWS App Runner
管理対象	コンテナ管理サービス、EC2 または Fargate 上で動作	Kubernetes クラスター管理	サーバーレス、コンテナのデプロイを簡単に管理
柔軟性	高い柔軟性、カスタマイズ可能	Kubernetes による非常に高い柔軟性	シンプルで自動化された管理
利用シナリオ	複雑なコンテナアプリケーション	複雑でスケーラブルなマイクロサービス	シンプルなコンテナアプリケーションのデプロイ
スケーリング	手動で設定、オートスケーリング対応	Kubernetes を使ったスケーリング	自動スケーリング
運用管理	自動化されていない部分も多い、管理が必要	Kubernetes の運用管理に関する深い知識が必要	インフラ管理不要、ほぼ全自動で管理
対象ユーザー	高度なカスタマイズが必要なユーザー	Kubernetes に精通しているユーザー	簡単なデプロイを希望する開発者

まとめ

ECS はコンテナの柔軟な管理が可能ですが、設定や運用に関しては手動で行う部分が多く、よりカスタマイズされた運用が求められます。

EKS は Kubernetes を使用した非常に高い柔軟性を提供しますが、運用や管理が難しく、Kubernetes の知識が必要です。

AWS App Runner はサーバーレスで、インフラの管理やスケーリングを気にせずに簡単にアプリケーションをデプロイできるため、最小限の運用負荷で開発者が集中できる環境を提供します。

実践

話題のAWS App Runnerをハンズオン！ - Qiita

App Runnerとは？App Runnerはコンテナネイティブのフルマネージドサービスです。オーケストレーターの設定、ビルドパイプラインの準備、ロードバランサーの調整、 TLS 証明書のローテ…

https://qiita.com/ita-k/items/4aa174a2993e8cc87ebe

アプリケーションの用意

ディレクトリ作成:

ファイル作成:

index.js:

package.json:

Dockerfile:

ECRのセットアップ

リポジトリ作成:

プライベートリポジトリ: simple-express-repository

イメージのプッシュ:

IAMロールの作成

ポリシー (AppRunnerECRAccessRole):

信頼関係ポリシー:

デプロイ

App Runnerサービスの作成:

リポジトリタイプ: コンテナレジストリ

プロバイダー: Amazon ECR

コンテナイメージURI: ECRにプッシュしたイメージ

サービスロール: AppRunnerECRAccessRole

ポート: 3000

デプロイ確認:

ステータスがRunningになったら、デフォルトドメインにアクセスして確認。

自動デプロイ確認

index.jsの文字列を変更後、再度ECRにプッシュ。

プッシュ後、App Runnerが自動で新しいバージョンをデプロイ。

まとめ

App Runnerを使って、数分でコンテナベースアプリケーションをデプロイ。AWSのベストプラクティスが組み込まれており、開発者がアプリケーション開発に集中できる素晴らしいサービス。

一問道場

質問 #45

ある会社がオンプレミスのデータセンターで Git リポジトリをホストしています。会社は Webhook を使用して、AWS クラウドで実行される機能を呼び出しています。

会社は、Webhook のロジックを AWS クラウド上で複数の Amazon EC2 インスタンスから構成される Auto Scaling グループにホストし、その EC2 インスタンスを Application Load Balancer (ALB) のターゲットとして設定しています。Git サーバーは ALB を呼び出して Webhook を実行します。

会社はこのソリューションをサーバーレスアーキテクチャに移行したいと考えています。

どのソリューションが最も運用負荷が少なく、この要件を満たしますか？

A. 各 Webhook 用に AWS Lambda 関数 URL を作成して設定します。Git サーバーを更新し、個別の Lambda 関数 URL を呼び出すようにします。

B. Amazon API Gateway HTTP API を作成します。各 Webhook ロジックを別々の AWS Lambda 関数として実装します。Git サーバーを更新し、API Gateway エンドポイントを呼び出すようにします。

C. Webhook ロジックを AWS App Runner にデプロイします。ALB を作成し、ターゲットとして App Runner を設定します。Git サーバーを更新し、ALB エンドポイントを呼び出すようにします。

D. Webhook ロジックをコンテナ化します。Amazon Elastic Container Service (Amazon ECS) クラスターを作成し、Webhook ロジックを AWS Fargate で実行します。Amazon API Gateway REST API を作成し、Fargate をターゲットとして設定します。Git サーバーを更新し、API Gateway エンドポイントを呼び出すようにします。

解説

この問題は、サーバーレスアーキテクチャへの移行に最適なソリューションを選ぶものです。

A: Lambda 関数 URL を使用する方法は管理が煩雑で運用負荷が増えるため、最適ではありません。

B: API Gateway と Lambda を使用する方法は、サーバーレスアーキテクチャに適しており、運用負荷が低く、拡張性も高いため、最適な選択肢です。

C App Runnerは確かにサーバーレスですが、ALBを使用してApp Runnerにリクエストを送る必要があり、運用の負荷が増える可能性があります。

D: Fargate を使用する方法はコンテナ化が必要で、サーバーレスより運用が複雑になります。

最適な選択肢は B です。

もし、サーバーレスでの処理を重視する場合、API Gateway + Lambdaの組み合わせがより適しています。