CrowdWorks Inc.｜ CrowdWorks Inc.｜ 散らばったAWS Lambdaの 　GitHubリポジトリをモノレポ構成にして 　　メンテナンスコストを削減する
 1

CrowdWorks Inc.｜ 自己紹介
 株式会社クラウドワークス プロダクト本部 テクノロジーエクセレンスグループ SRE ベンチャー企業でバックエンド・インフラを 6年務めた後、CWに入社
 仁昌寺 克行
 2

CrowdWorks Inc.｜ CrowdWorks Inc.｜ 3 3 突然ですが、 AWS Lambdaって使ってます？

CrowdWorks Inc.｜ CrowdWorks Inc.｜ 4 4 CWでもよく使ってます ・SNS経由でSlackへ通知 ・SendGridのWebhookを受ける ・メール送信 etc.

CrowdWorks Inc.｜ CrowdWorks Inc.｜ CWで起こったAWS Lambda周りの問題
 5 5

CrowdWorks Inc.｜ CWで起こったAWS Lambda周りの問題
 ● AWS Lambdaを実装する度にGitHubリポジトリを新規作成する ○ GitHubリポジトリが乱立する ● 使用言語がバラバラ ○ Node.js、Ruby、Go etc. ● CI/CDもバラバラ ○ CircleCI、GitHub Actions etc. ● デプロイツールもバラバラ ○ Apex、Serverless Framework etc.
 6

CrowdWorks Inc.｜ AWS Lambdaのメンテナンスコスト、認知負荷が増加 ● SREチームでは、言語やライブラリのEOL対応を定期的に行なっている ● GitHubリポジトリが乱立し、使用言語もCI/CDもバラバラは辛い ● （これは別の問題ですが）たまにCI/CDを動かそうとするとlinterやtestが壊れているのも辛い 7

CrowdWorks Inc.｜ CrowdWorks Inc.｜ 問題点と解決策 8 8

CrowdWorks Inc.｜ （1）乱立したGitHubリポジトリ ● GitHubリポジトリが多いとメンテナンスコストが増加する ● なので、乱立したGitHubリポジトリを1つにまとめるようにした ○ ディレクトリを切って、各ディレクトリ内でコードを管理する ○ いわゆる、モノレポ構成です 9

CrowdWorks Inc.｜ （2）バラついてる使用言語 ● CWでは、大半のLambdaがGoで実装されていたこともあり、出来るだけGoに寄せる方針にした ● 一部、Node.jsやRubyで実装されていたが、Goへの書き換えは今後の課題とした ● 今後、AWS Lambdaを新規作成する時は、出来るだけGoに寄せる予定です 10

CrowdWorks Inc.｜ （3）バラついてるCI/CD ● 幸い、CI/CDでそこまで複雑な処理をしていなかった ● GitHubとCircleCIを連携させるメリットも無い ● GitHub Actionsに寄せる方針とした 11

CrowdWorks Inc.｜ （4）バラついてるデプロイツール ● Lambdaのデプロイツールは、時代によって移り変わりがある ● CWでは、ApexやServerless Frameworkが使用されていた ○ Apexは、GitHubリポジトリがアーカイブ済み ○ Serverless Frameworkは、裏でAWS CloudFormationを使っていて見通しが悪い ● よりシンプルなLambdaのデプロイツールとして、lambrollに統一しました ○ https://github.com/fujiwara/lambroll ■ カヤックの藤原さんが作成しているツール 12

CrowdWorks Inc.｜ CrowdWorks Inc.｜ 試行錯誤の結果 13 13

CrowdWorks Inc.｜ ディレクトリ構成 14 . ├── .github │ ├── actions │ │ ├── deploy │ │ ├── deploy_go │ │ └── deploy_ruby │ └── workflows │ ├── lambda_1_deploy_production.yml │ └── lambda_2_deploy_production.yml ├── .lambroll-version ├── lambda_1 └── lambda_2 GitHub Actions内にバージョンをベタ書きしたくなかったので .lambroll-versionに記載して、これを参照している 言語ごとにビルドや前処理が異なる為、 Actionを分けている

CrowdWorks Inc.｜ デプロイのワークフロー（例：lambda_1） 15 name: deploy production permissions: contents: read id-token: write on: push: branches: - main paths: # (1) lambda_1の変更をトリガーに起動する - 'lambda_1/**' - '!lambda_1/README.md' # (2) デプロイが連続で起動しないように同時デプロイを禁止する concurrency: group: lambda-1-deploy-production jobs: deploy_production: runs-on: ubuntu-latest timeout-minutes: 5 environment: name: production steps: - uses: actions/checkout@v4 # (3) Lambdaのデプロイをする - name: deploy uses: ./.github/actions/deploy with: working-directory: lambda_1 app-name: lambda-1 stage: production aws-account-id: ${{ secrets.AWS_ACCOUNT_ID }}

CrowdWorks Inc.｜ デプロイの共通アクション 16 << inputs周りは省略 >> runs: using: composite steps: # (1) lambrollのバージョンを取得する - shell: bash run: echo "LAMBROLL_VERSION=v`cat .lambroll-version`" >> $GITHUB_ENV # (2) OIDC認証でAWSアクセスキーを取得する - name: configure AWS credentials uses: aws-actions/configure-aws-credentials@v2 with: aws-region: ap-northeast-1 role-to-assume: arn:aws:iam::${{ inputs.aws-account-id }}:role/${{ inputs.app-name }}-${{ inputs.stage }}-deploy role-session-name: github-actions-${{ github.run_id }} # (3) 公式で配布されているlambrollのアクションを使用する - uses: fujiwara/lambroll@v0 with: version: ${{ env.LAMBROLL_VERSION }} # (4) 必要であれば、ここにビルドや前処理のステップが入る # (5) デプロイのコマンドは、Makefileに記載して、それを実行する - name: deploy shell: bash working-directory: ${{ inputs.working-directory }} run: make -e github-actions/deploy Lambdaのビルド・前処理・デプロイのコマンドって バラバラでGitHub Actionsで共通化出来ない ↓ 必要なコマンドをMakefileで用意して GitHub Actions内で実行する方法を採用した

CrowdWorks Inc.｜ CrowdWorks Inc.｜ まとめ 17 17

CrowdWorks Inc.｜ まとめ ● 実施 ○ AWS LambdaのGitHubリポジトリをモノレポ構成にした ○ 使用言語はGoに寄せ、CI/CDはGitHub Actionsに寄せた ○ デプロイツールは、lambrollに統一した ● 結果 ○ 管理対象のGitHubリポジトリが減り、使用言語やCI/CDのパターンが減った ○ AWS Lambdaのメンテナンスコストと認知負荷を削減出来た 18

CrowdWorks Inc.｜ CrowdWorks Inc.｜ ご清聴いただきありがとうございました 19 19 クラウドワークス エンジニアブログ ※詳細はテックブログをご参照ください