Agent Skills by ALSEL
Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

aws-lambda-php-integration

Brefフレームワークを使用したPHP/SymfonyアプリケーションのAWS Lambda統合パターンを提供します。Lambdaハンドラークラスの作成、ランタイムレイヤーの設定、SQS/SNSイベントトリガーの構成、ウォームアップ戦略の実装、コールドスタートの最適化を行います。PHP/SymfonyアプリケーションをAWS Lambdaにデプロイする際や、API Gateway統合の設定、サーバーレスPHPアプリケーションの構築、Brefを活用したLambdaパフォーマンスの最適化が必要な場面でご活用ください。

description の原文を見る

Provides AWS Lambda integration patterns for PHP with Symfony using the Bref framework. Creates Lambda handler classes, configures runtime layers, sets up SQS/SNS event triggers, implements warm-up strategies, and optimizes cold starts. Use when deploying PHP/Symfony applications to AWS Lambda, configuring API Gateway integration, implementing serverless PHP applications, or optimizing Lambda performance with Bref. Triggers include "create lambda php", "deploy symfony lambda", "bref lambda aws", "php lambda cold start", "aws lambda php performance", "symfony serverless", "php serverless framework".

SKILL.md 本文

AWS Lambda PHP Integration

Bref フレームワークを使用して PHP および Symfony アプリケーションを AWS Lambda にデプロイするためのパターン。

概要

2つのアプローチが利用可能です:

  • Bref フレームワーク - Symfony サポート付きの標準的な Lambda 上の PHP、組み込みルーティング、コールドスタート < 2秒
  • Raw PHP - 最小限のオーバーヘッド、最大限の制御、コールドスタート < 500ms

両者ともに本番環境対応の構成で API Gateway 統合をサポートしています。

使用するべき場合

  • PHP で新しい Lambda 関数を作成する場合
  • 既存の Symfony アプリケーションを Lambda に移行する場合
  • コールドスタートのパフォーマンスを最適化する場合
  • API Gateway または SQS/SNS イベントトリガーを構成する場合
  • PHP Lambda のデプロイメントパイプラインをセットアップする場合

説明書

1. アプローチを選択する

アプローチコールドスタート最適用途複雑さ
Bref< 2秒Symfony アプリ、フル機能 API中程度
Raw PHP< 500msシンプルなハンドラー、最大限の制御

2. プロジェクト構造

Bref を使用した Symfony 構造

my-symfony-lambda/
├── composer.json
├── serverless.yml
├── public/
│   └── index.php         # Lambda エントリーポイント
├── src/
│   └── Kernel.php        # Symfony Kernel
├── config/
│   ├── bundles.php
│   ├── routes.yaml
│   └── services.yaml
└── templates/

Raw PHP 構造

my-lambda-function/
├── public/
│   └── index.php         # ハンドラーエントリーポイント
├── composer.json
├── serverless.yml
└── src/
    └── Services/

3. 実装

Bref を使用した Symfony:

// public/index.php
use Bref\Symfony\Bref;
use App\Kernel;
use Symfony\Component\HttpFoundation\Request;

require __DIR__.'/../vendor/autoload.php';

$kernel = new Kernel($_SERVER['APP_ENV'] ?? 'dev', $_SERVER['APP_DEBUG'] ?? true);
$kernel->boot();

$bref = new Bref($kernel);
return $bref->run($event, $context);

Raw PHP ハンドラー:

// public/index.php
use function Bref\Lambda\main;

main(function ($event) {
    $path = $event['path'] ?? '/';
    $method = $event['httpMethod'] ?? 'GET';

    return [
        'statusCode' => 200,
        'body' => json_encode(['message' => 'Hello from PHP Lambda!'])
    ];
});

4. コールドスタート最適化

  1. 遅延ローディング - 必要になるまで重いサービスを遅延させる
  2. 使用していない Symfony 機能を無効にする - バリデーション、アノテーションを無効化
  3. Composer オートローダーを最適化 - 本番環境では classmap を使用
  4. Bref 最適化ランタイムを使用 - PHP 8.x の最適化を活用

5. 接続管理

// AWS クライアントをファンクションレベルでキャッシュ
use Aws\DynamoDb\DynamoDbClient;

class DatabaseService
{
    private static ?DynamoDbClient $client = null;

    public static function getClient(): DynamoDbClient
    {
        if (self::$client === null) {
            self::$client = new DynamoDbClient([
                'region' => getenv('AWS_REGION'),
                'version' => 'latest'
            ]);
        }
        return self::$client;
    }
}

ベストプラクティス

メモリとタイムアウト

  • メモリ: Symfony は 512MB、Raw PHP は 256MB から開始
  • タイムアウト: Symfony は コールドスタートバッファのため 10~30秒、Raw PHP は通常 3~10秒で十分

依存関係

{
    "require": {
        "php": "^8.2",
        "bref/bref": "^2.0",
        "symfony/framework-bundle": "^6.0"
    },
    "config": {
        "optimize-autoloader": true,
        "preferred-install": "dist"
    }
}

エラーハンドリング

try {
    $result = processRequest($event);
    return [
        'statusCode' => 200,
        'body' => json_encode($result)
    ];
} catch (ValidationException $e) {
    return [
        'statusCode' => 400,
        'body' => json_encode(['error' => $e->getMessage()])
    ];
} catch (Exception $e) {
    error_log($e->getMessage());
    return [
        'statusCode' => 500,
        'body' => json_encode(['error' => 'Internal error'])
    ];
}

ロギング

error_log(json_encode([
    'level' => 'info',
    'message' => 'Request processed',
    'request_id' => $context->getAwsRequestId(),
    'path' => $event['path'] ?? '/'
]));

デプロイメント

Serverless 構成

# serverless.yml
service: symfony-lambda-api

provider:
  name: aws
  runtime: php-82
  memorySize: 512
  timeout: 20

package:
  individually: true
  exclude:
    - '**/node_modules/**'
    - '**/.git/**'

functions:
  api:
    handler: public/index.php
    events:
      - http:
          path: /{proxy+}
          method: ANY

デプロイと検証

# 1. Bref をインストール
composer require bref/bref --dev

# 2. ローカルでテスト (デプロイ前に検証)
sam local invoke -e event.json

# 3. デプロイ
vendor/bin/bref deploy

# 4. デプロイメントを確認
aws lambda invoke --function-name symfony-lambda-api-api \
  --payload '{"path": "/", "httpMethod": "GET"}' /dev/stdout

Symfony 完全構成

# Symfony 用 serverless.yml
service: symfony-lambda-api

provider:
  name: aws
  runtime: php-82
  stage: ${self:custom.stage}
  region: ${self:custom.region}
  environment:
    APP_ENV: ${self:custom.stage}
    APP_DEBUG: ${self:custom.isLocal}
  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - dynamodb:GetItem
            - dynamodb:PutItem
          Resource: '*'

functions:
  web:
    handler: public/index.php
    timeout: 30
    memorySize: 1024
    events:
      - http:
          path: /{proxy+}
          method: ANY

  console:
    handler: bin/console
    timeout: 300
    events:
      - schedule: rate(1 day)

plugins:
  - ./vendor/bref/bref

custom:
  stage: dev
  region: us-east-1
  isLocal: false

制約と警告

Lambda の制限

  • デプロイメントパッケージ: 最大 250MB (解凍時)、50MB (圧縮時)
  • メモリ: 128MB から 10GB
  • タイムアウト: 29秒 (API Gateway)、15分 (非同期)
  • 同時実行: デフォルト 1000

PHP 固有の考慮事項

  • コールドスタート: PHP には中程度のコールドスタートがあります。最適化されたランタイムには Bref を使用してください
  • 依存関係: composer.json をシンプルに保つ。共有依存は Lambda Layers を使用
  • PHP バージョン: Lambda のパフォーマンスに最適な PHP 8.2 以上を使用
  • ローカルストレージなし: Lambda コンテナはエフェメラル。永続化には S3/DynamoDB を使用

よくある落とし穴

  1. 大きい vendor フォルダ - 開発用依存を除外。--no-dev を使用
  2. セッションストレージ - ローカルファイルストレージを使用しない。DynamoDB を使用
  3. 長時間実行プロセス - Lambda には不向き。代わりに ECS を使用
  4. Websocket - API Gateway WebSockets または AppSync を使用

セキュリティに関する考慮事項

  • 認証情報をハードコードしない。IAM ロールと SSM Parameter Store を使用
  • すべての入力データを検証
  • 最小権限の IAM ポリシーを使用
  • CloudTrail で監査ログを有効化
  • 適切な CORS ヘッダーを設定

例 1: Symfony Lambda API を作成する

入力: "Todo アプリケーション用に Bref を使用した Symfony Lambda REST API を作成する"

プロセス:

  1. composer create-project で Symfony プロジェクトを初期化
  2. Bref をインストール: composer require bref/bref
  3. serverless.yml を構成
  4. config/routes.yaml でルートをセットアップ
  5. ローカルでテスト: sam local invoke
  6. デプロイ: vendor/bin/bref deploy
  7. 確認: aws lambda invoke --function-name <name> --payload '{}'

出力: REST API、DynamoDB 統合、デプロイメント構成を備えた完全な Symfony プロジェクト構造

例 2: Symfony のコールドスタートを最適化する

入力: "Symfony Lambda のコールドスタートが 5秒ですが、どのように最適化しますか?"

プロセス:

  1. スタートアップ時にロードされるサービスを分析
  2. 使用していない Symfony 機能を無効化 (バリデーション、アノテーション)
  3. 重いサービスに遅延ローディングを使用
  4. Composer オートローダーを最適化
  5. 測定: デプロイして呼び出し、コールドスタート < 2秒を検証

出力: コールドスタート < 2秒の リファクタリングされた Symfony 構成

例 3: GitHub Actions でデプロイする

入力: "Serverless Framework で Symfony Lambda の CI/CD を構成する"

プロセス:

  1. GitHub Actions ワークフローを作成
  2. PHP 環境を composer でセットアップ
  3. PHPUnit テストを実行
  4. デプロイ: Serverless Framework でデプロイ
  5. 検証: Lambda 関数が存在し応答することを確認

出力: マルチステージパイプラインとテスト自動化を備えた完全な .github/workflows/deploy.yml

参考資料

  • Bref Lambda - 完全な Bref セットアップ、Symfony 統合、ルーティング
  • Raw PHP Lambda - 最小限のハンドラーパターン、キャッシング、パッケージング
  • Serverless デプロイメント - Serverless Framework、SAM、CI/CD パイプライン
  • Lambda のテスト - PHPUnit、SAM Local、統合テスト

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
giuseppe-trisciuoglio
リポジトリ
giuseppe-trisciuoglio/developer-kit
ライセンス
MIT
最終更新
不明

Source: https://github.com/giuseppe-trisciuoglio/developer-kit / ライセンス: MIT

関連スキル

汎用ソフトウェア開発⭐ リポ 39,967

doubt-driven-development

重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 1,175

apprun-skills

TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。

by yysun
OpenAIソフトウェア開発⭐ リポ 797

desloppify

コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。

by Git-on-my-level
汎用ソフトウェア開発⭐ リポ 39,967

debugging-and-error-recovery

テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

test-driven-development

テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

incremental-implementation

変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。

by addyosmani
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: giuseppe-trisciuoglio · giuseppe-trisciuoglio/developer-kit · ライセンス: MIT