Kaziu

Posted on Nov 8

たった1枚の引き伸ばされた画像から、AWS Lambdaのコード移行とCI/CD構築に至った話

#aws #cicd

始まり

ある日、開発中の画面でサムネイル画像が不自然に引き伸ばされて表示されていることに気づきました。

「ああ、このパターンな。CSSのobject-fitがcoverになってるのをcontainにすれば直るやつじゃ」

そう高を括ってコードを修正。しかし、表示は変わらず引き伸ばされたまま。ブラウザの開発者ツールで画像のURLを直接開いてみると、Amazon S3から返されている画像そのものが既に引き伸ばされていました

「まじすか先輩」

しかし、わしはプロジェクトに参加したばかりでしかもインフラはよぉ知らん。該当の画像生成処理がどこに書かれているのか見当もつきませんので同僚に聞いてみましたわ

「すんまへん、このサムネイル画像、どうもAWS側でリサイズされてるっぽいんですが、どこの処理か分かりますか？」

すると、同僚から

「ああ、その処理は別のインフラ用リポジトリにあるLambda関数がやってるんですよ。ただ、そのリポジトリを直接編集しても意味なくて、今のアプリケーション用リポジトリにコードを移行して、CI/CDを再設定する必要があるんですわこりゃ」

わしの頭の中は「あーLambda聞いたことあるわー、awsのやつじゃわー」て感じでしたが、とりあえずやってみました。

STEP1: Lambdaてそもそもなんですの？

これは「特定のイベントをきっかけに、自動で動いてくれる小さなプログラム」で、サーバーの管理を自分でする必要がない「サーバーレス」という仕組みの一つで、例えば以下のようなイベントをきっかけに処理を実行できます。

Amazon S3にファイルがアップロードされた時
API Gatewayにリクエストが来た時
特定の時間になった時 (cronのように)

今回のケースでは、「S3バケットにオリジナル画像がアップロードされたら、Lambda関数が起動してサムネイル画像を生成し、別のS3バケットに保存する」という処理が行われていたのです。これなら、画像が引き伸ばされている原因も、Lambda関数のコードを修正すれば解決できそうです

STEP 2: Lambda関数の移行とCI/CDの構築

旧インフラリポジトリから、Lambda関数のソースコードを現在のアプリケーションリポジトリに持ってくる。
持ってきたコードを修正し、画像が引き伸ばされないようにする。（今回はリサイズのロジックを修正、resize methodをthumbnail methodに変）
コードが更新されたら、自動でAWS上のLambda関数にデプロイされる仕組み（CI/CD）をGitHub Actionsで構築する。

▼ GitHub ActionsでLambdaに自動デプロイ
GitHub Actionsのワークフローを使い、特定のブランチ（例: main）にコードがプッシュされたら、自動でAWS Lambdaにデプロイされるように設定します。.github/workflowsの中に設定します

# sample code
name: Deploy to AWS Lambda

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先の環境を選択してください'
        required: true
        type: choice
        options:
          - release-candidate
          - staging
          - production

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ github.event.inputs.environment }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      # ... (Node.jsやPythonのセットアップ、依存パッケージのインストールなど) ...

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: Build and Zip
        run: |
          # ビルドやパッケージングの処理
          zip -r function.zip .

      - name: Deploy to Lambda
        run: |
          aws lambda update-function-code \
            --function-name ${{ secrets.YOUR_LAMBDA_FUNCTION_NAME }} \
            --zip-file fileb://function.zip

このワークフローのポイントは2つです

1. 環境に応じたSecretsの利用

GitHubリポジトリの Settings > Environments で release-candidate, staging, production の各環境がありました。なのでそれぞれの環境のSecretsに YOUR_LAMBDA_FUNCTION_NAMEというキーで、対応するLambda関数名（例: rc-YourLambdaFunctionName）を登録しておきます。
ワークフローが実行されると、選択された環境に応じて適切な関数名が自動で読み込まれるため、デプロイ先を間違えるリスクを低減できます。

2. 手動トリガーによる安全なデプロイ

on: push を使わず on: workflow_dispatch を使うことで、意図しない自動デプロイを防ぎます。開発者はGitHubのActionsタブから「Run workflow」ボタンを押し、デプロイしたい環境を選択するだけで、安全かつ確実にリリース作業を行えます。

🔥 つまずきポイント：GitHub Actionsの「Run workflow」が表示されない！

ワークフローを作成し、いざ手動で実行テストをしようとした時のことです。GitHubリポジトリのActionsタブを見ても、手動実行ボタンである「Run workflow」が表示されません。

原因は単純で、workflow_dispatch を含むワークフローファイルが、リポジポジトリのデフォルトブランチ（mainやmaster）にマージされていないと、手動実行のUIは表示されないという仕様でした。
開発ブランチでいくら試行錯誤してもボタンは現れません。この仕様を知らずに、githubと戦っておりました

まとめ

たった1枚の引き伸ばされた画像でしたが、AWS Lambda、そしてCI/CDの世界に飛び込めました

表示の不具合は、必ずしもフロントエンド、バックエンドが原因とは限らない。
AWS Lambdaは、イベント駆動で動く便利な自動処理プログラム。
ワークフローの手動実行（workflow_dispatch）は、デフォルトブランチでしか有効にならない。

てなわけでバグも修正され、気持ちよくなりましたわ〜

DEV Community