kumo：Goで書かれた軽量AWSサービスエミュレータ

CI/CDとローカル開発のためのGo製AWSエミュレータ

kumoはGoで書かれた軽量AWSサービスエミュレータであり、READMEではCI/CDテストツールとローカル開発サーバーの両方として位置付けられています。リポジトリのメタデータでは言語がGoであり、説明も一致しています。READMEはいくつかの機能を強調しています：認証が不要でCI環境に適していること、単一バイナリで配布されること、Dockerサポートがあること、軽量で起動が速くリソース消費が少ないこと、Go AWS SDK v2と互換性があること、KUMO_DATA_DIRが設定されている場合にデータを永続化できることです。これらの機能により、kumoはAWSアカウントなしでAWS APIをテストできる自己完結型のエミュレータとなっています。

82のAWS APIをカテゴリ別にカバーするサービスカタログ

READMEは82のサポートサービスを主張し、カテゴリごとに整理されたテーブルを提供しています。ストレージにはDynamoDB、DynamoDB Streams、EBS、ElastiCache、Glacier、MemoryDB、S3、S3 Control、S3 Tablesが含まれます。コンピュートにはBatch、EC2、Elastic Beanstalk、Lambdaが含まれます。コンテナサービスはECR、ECS、EKSです。データベースサービスはDocumentDB、Neptune、RDS、Redshiftです。メッセージングと統合はEventBridge、Firehose、Kinesis、MQ、MSK、Pipes、SNS、SQSをカバーします。セキュリティとアイデンティティにはACM、Cognito、IAM、KMS、Macie、STS、Secrets Manager、Security Lakeが含まれます。完全なリストは監視、ネットワーキング、アプリケーション統合、管理、分析、開発者ツールに続きます。READMEは各サービス内で実装されているAPI操作を特定していないため、各サービスの正確なカバレッジは未検証のままです。

Docker、バイナリ、またはComposeでkumoを起動する

クイックスタートセクションでは、kumoを実行する3つの方法を示しています。1つ目はDockerです：`docker run -p 4566:4566 ghcr.io/sivchari/kumo:latest`でポート4566でエミュレータが起動します。永続化のためには、READMEは`-e KUMO_DATA_DIR=/data`を追加し、名前付きボリュームをマウントします。2つ目はソースからビルドし、`make build`を実行してから`./bin/kumo`を実行する方法で、オプションで`KUMO_DATA_DIR=./data`を設定します。3つ目はDocker Composeで、ポート4566をマップする最小のYAML例と、永続化のために環境変数とボリュームを追加する拡張例があります。デフォルトポートは4566で、使用例全体で使用されています。

AWS SDK v2クライアントをlocalhostに向ける

READMEの使用例では、AWS SDK v2クライアントをkumoに向ける方法を示しています。S3の場合、コードはリージョン`us-east-1`と静的認証情報`test`/`test`で設定を作成し、`o.BaseEndpoint`を`http://localhost:4566`に設定し、パススタイルアドレス指定を使用します。次にバケットを作成し、オブジェクトを置きます。SQS、DynamoDB、Secrets Managerの例も同じパターンに従います：デフォルト設定をロードし、ベースエンドポイントをオーバーライドし、関連する操作を呼び出します。例では`context.保留項目()`を使用し、エラーを無視しているため、これらは本番コードではなく最小限の説明であることがわかります。kumoは認証を必要としないため、任意の静的認証情報が機能します。

環境変数と構造化ロギング

kumoの設定は、表に記載されている4つの環境変数によって制御されます。`KUMO_HOST`はバインドアドレスを設定し、デフォルトは`0.0.0.0`です。`KUMO_PORT`はポートを設定し、デフォルトは`4566`です。`KUMO_LOG_LEVEL`はdebug、info、warn、errorを受け付け、デフォルトはinfoです。`KUMO_DATA_DIR`はデフォルトでは未設定で、設定すると永続化が有効になります。ロギングは、method、path、status、duration、request IDなどのフィールドで構造化されています。INFOレベルでは、各リクエストはSecrets Manager、DynamoDB、SQSなどのJSON/Queryプロトコルサービスでは`target`フィールド、URLにActionがあるEC2やSNSなどのQueryプロトコルサービスでは`action`フィールドでログに記録されます。DEBUGレベルでは、完全なリクエストボディがログ出力に含まれます。

デフォルトではインメモリ、要求に応じて永続化

データ永続化はオプションです。`KUMO_DATA_DIR`がない場合、kumoは完全にメモリ内で実行され、プロセスが終了するとすべてのデータが失われます。READMEはこれを、テスト実行ごとにクリーンな状態が必要なCI/CDパイプラインに最適だと述べています。`KUMO_DATA_DIR`が設定されている場合、各サービスは起動時に`$KUMO_DATA_DIR/{service}.json`から以前の状態をロードし、SIGTERMまたはSIGINTによる正常なシャットダウン時に現在の状態を保存します。ディレクトリが存在しない場合は自動的に作成されます。書き込みはアトミックです：READMEはクラッシュ時の破損を防ぐために一時ファイルとリネームのパターンに言及しています。SQSのインフライトメッセージやS3のマルチパートアップロードなどの一時的な状態は永続化されません。この設計により、ローカル開発では再起動間でデータを保持でき、CIでの使用を複雑にしません。

/kumo/プレフィックス配下のテスト専用エンドポイント

kumoは`/kumo/`プレフィックスの下に、AWS APIの一部ではない2つのカスタムエンドポイントを公開しています。`GET /kumo/ses/v2/sent-emails`はSES v2 `SendEmail` APIを介して送信されたメールのリストを返し、`GET /kumo/pinpointsmsvoicev2/sent-messages`はPinpoint SMS Voice v2 `SendTextMessage` APIを介して送信されたSMSメッセージを返します。READMEには、メールの`MessageId`、`FromEmailAddress`、`Destination`、`Subject`、`Body`、`SentAt`、およびSMSメッセージの対応するフィールドを示すサンプルcurlコマンドとJSONレスポンスが含まれています。これらのエンドポイントは、期待される内容でメールが送信されたかどうかの確認など、テストでアプリケーションの動作を検証するためのものです。

sivchari-kumo-deep-analysisについてREADMEの固有ファイル、コマンド、入力、出力を照合し、未記載の挙動は未確認として扱います。

編集部の結論

kumoは、82のサービスをカバーし、Dockerとバイナリデプロイをサポートし、オプションの永続化を提供する自己完結型のAWSエミュレータです。SESとPinpoint SMS用のカスタムテストエンドポイントは、他のエミュレータと区別される特徴です。このプロジェクトはMITライセンスの下でリリースされており、使用、コピー、変更、マージ、公開、配布、サブライセンス、販売の権利を許可しますが、ソフトウェアは「現状のまま」提供され、いかなる保証もありません。READMEには本番利用やセキュリティ保証については記載されていません。

公式情報源

1. Official README
2. Project repository
3. Release notes