Posted inDevOps

AWS開発環境への支払いをやめよう：LocalStackとDocker活用ガイド

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

「クラウドのみ」の開発に伴う高額なコスト

クラウドネイティブなプロジェクトの多くは、同じようなパターンで始まります。クレジットカードを登録し、リソースの準備ができるのを待ちます。シンプルなAWS Lambda関数を書き、コードをプッシュし、そこから長い待ち時間が始まります。CI/CDパイプラインを待ち、Terraformがリソースをプロビジョニングするのを待ち、ようやくAWSコンソールで動作を確認します。もしIAMポリシーのコンマを1つ忘れていれば、再び15分のサイクルを最初からやり直すことになります。

このフィードバックループは、生産性を著しく低下させます。週末にRDSインスタンスやNAT Gatewayを動かしっぱなしにしただけで、1ヶ月に2,000ドルもの「テスト費用」を浪費してしまったチームを私は見てきました。NAT Gatewayは、通信が全くなくても月額約32ドルかかります。基本的なロジックを確認したいだけの場合、これらのコストは大きな負担となります。

ローカルファーストのワークフローに移行することで, 状況は一変します。LocalStackとDockerを使用すれば、機能的なAWSのクローンを自分のラップトップ上で直接実行できます。これにより、開発ロジックを会社の経理部門の請求から切り離すことが可能になります。

アプローチの比較：本物のAWS vs. LocalStack

適切な環境の選択は、特定のニーズによって異なります。現場での主な2つの手法の比較は以下の通りです。

1. 「サンドボックスアカウント」アプローチ

これは、開発者用に本物のAPIを使用する専用のAWSアカウントを作成する方法です。

  • メリット: 本番環境との100%の一致、および実際のIAMによる制限の適用。
  • デメリット: 高レイテンシ、コストが発生、常時インターネット接続が必要。また、不要なリソースが残った際のクリーンアップが非常に手間。

2. LocalStackアプローチ

自分のハードウェア上で、AWSサービスのコンテナ化されたモックをローカルに実行します。

  • メリット: コストゼロ、即座のフィードバック、オフライン動作、および数秒で全状態をリセット可能。
  • デメリット: すべてのニッチなサービスをサポートしているわけではなく、RDS Auroraクラスターなどの高度な機能にはProライセンスが必要な場合が多い。

なぜローカルシミュレーションが優れているのか

LocalStackは、AWSエコシステム全体の完璧な代替品ではありません。しかし、日常的な開発タスクの90%においては、これで十分すぎるほどです。コードを書いてから実際に動くのを確認するまでのギャップを埋めてくれます。

メリット

  • スピード: AWSでS3バケットを作成するのに30秒かかることがありますが、LocalStackなら200ミリ秒で完了します。
  • コスト: 統合テスト中にLambdaを10万回実行しても、支払う費用は0円です。
  • 安全性: 誤って本番環境のバケットを削除したり、データベースをインターネットに公開したりするリスクがありません。
  • CI/CD統合: 複雑なAWSシークレットを管理することなく、GitHub Actionsで完全な統合テストを実行できます。

トレードオフ

  • 再現度: LocalStackはAPIレスポンスをモック化します。精度は非常に高いですが、実際のAWSエンジンの細かなエッジケースまでは再現できない場合があります。
  • システムリソース: OpenSearchやマルチノードのRDSモックなど、重いサービスをDocker内で実行すると、RAMを大幅に消費します。

セットアップ：Docker Compose

セットアップにはDocker Composeの使用をお勧めします。インフラの構成をGitリポジトリに保持できるため、すべての開発者が同一の環境を利用できます。プロジェクトのルートに docker-compose.yml ファイルを作成します。

version: "3.8"

services:
  localstack:
    container_name: localstack_main
    image: localstack/localstack:latest
    ports:
      - "127.0.0.1:4566:4566"
      - "127.0.0.1:4510-4559:4510-4559"
    environment:
      - DEBUG=1
      - DOCKER_HOST=unix:///var/run/docker.sock
    volumes:
      - "./volume:/var/lib/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

これにより、LocalStackゲートウェイがポート4566にマッピングされます。この単一のポートが、S3、Lambda、SQSを含むすべてのサービスへのリクエストを処理します。

実際に動かしてみる

docker-compose up -d でコンテナを起動します。標準のAWS CLIも使えますが、awslocal をインストールするのが良いでしょう。これはコマンドを自動的にローカルコンテナにルーティングしてくれる軽量なラッパーで、毎回エンドポイントURLを手動で入力する手間を省いてくれます。

pip install awscli-local

例1：S3バケットの管理

バケットの作成やファイルのアップロードには、本物の認証情報もインターネット接続も必要ありません。

# バケットを作成
awslocal s3 mb s3://my-test-bucket

# バケット一覧を表示
awslocal s3 ls

# ファイルをアップロード
echo "Hello from LocalStack" > test.txt
awslocal s3 cp test.txt s3://my-test-bucket/

例2：Lambda関数のデプロイ

LocalStackを使用すると、Lambdaのテストが驚くほど簡単になります。handler.py という名前でファイルを作成します。

def hello(event, context):
    return {
        'statusCode': 200,
        'body': 'ローカルのLambdaからこんにちは！'
    }

ZIPに固めてCLIでデプロイします。

zip function.zip handler.py

awslocal lambda create-function \
    --function-name my-local-lambda \
    --runtime python3.9 \
    --handler handler.hello \
    --role arn:aws:iam::000000000000:role/lambda-role \
    --zip-file fileb://function.zip

# 関数を実行
awslocal lambda invoke --function-name my-local-lambda response.json
cat response.json

アプリケーションコードの接続

Pythonで boto3 を使用する場合、endpoint_url をローカルコンテナに向けるだけです。私は環境を自動的に切り替えるために、以下のパターンを使用しています。

import boto3
import os

# 環境変数がlocalに設定されている場合、LocalStackにリダイレクト
if os.getenv('ENV') == 'local':
    s3 = boto3.client('s3', endpoint_url='http://localhost:4566')
else:
    s3 = boto3.client('s3')

# これ以降のコードは変更なし
print(s3.list_buckets())

最後に

ローカルファーストのワークフローを採用することで、ソフトウェアの構築方法が変わります。月々の請求を心配することなく、アーキテクチャの設計に完全に集中できるようになります。DockerとLocalStackは、高速で再現性が高く、かつ無料のサンドボックスを提供してくれます。

このセットアップは、実際のクラウド上の最終的なステージング環境を完全に置き換えるものではありません。しかし、コードがローカル環境を離れる前に、明らかな設定ミスがないことを保証してくれます。これは、自分の時間と会社の費用の両方を節約するためのプロフェッショナルな標準手法です。

Share:
Tags: