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

Transcript

1. CrowdWorks Inc.｜ CrowdWorks Inc.｜ 散らばったAWS Lambdaの 　GitHubリポジトリをモノレポ構成にして 　　メンテナンスコストを削減する
 1
2. CrowdWorks Inc.｜ 自己紹介
 株式会社クラウドワークス プロダクト本部 テクノロジーエクセレンスグループ SRE ベンチャー企業でバックエンド・インフラを 6年務めた後、CWに入社
 仁昌寺 克行
 2
3. CrowdWorks Inc.｜ CrowdWorks Inc.｜ 3 3 突然ですが、 AWS Lambdaって使ってます？
4. CrowdWorks Inc.｜ CrowdWorks Inc.｜ 4 4 CWでもよく使ってます ・SNS経由でSlackへ通知 ・SendGridのWebhookを受ける ・メール送信 etc.
5. CrowdWorks Inc.｜ CrowdWorks Inc.｜ CWで起こったAWS Lambda周りの問題
 5 5
6. 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
7. CrowdWorks Inc.｜ AWS Lambdaのメンテナンスコスト、認知負荷が増加 • SREチームでは、言語やライブラリのEOL対応を定期的に行なっている • GitHubリポジトリが乱立し、使用言語もCI/CDもバラバラは辛い • （これは別の問題ですが）たまにCI/CDを動かそうとするとlinterやtestが壊れているのも辛い 7
8. CrowdWorks Inc.｜ CrowdWorks Inc.｜ 問題点と解決策 8 8
9. CrowdWorks Inc.｜ （1）乱立したGitHubリポジトリ • GitHubリポジトリが多いとメンテナンスコストが増加する • なので、乱立したGitHubリポジトリを1つにまとめるようにした ◦ ディレクトリを切って、各ディレクトリ内でコードを管理する ◦ いわゆる、モノレポ構成です 9
10. CrowdWorks Inc.｜ （2）バラついてる使用言語 • CWでは、大半のLambdaがGoで実装されていたこともあり、出来るだけGoに寄せる方針にした • 一部、Node.jsやRubyで実装されていたが、Goへの書き換えは今後の課題とした • 今後、AWS Lambdaを新規作成する時は、出来るだけGoに寄せる予定です 10
11. CrowdWorks Inc.｜ （3）バラついてるCI/CD • 幸い、CI/CDでそこまで複雑な処理をしていなかった • GitHubとCircleCIを連携させるメリットも無い • GitHub Actionsに寄せる方針とした 11
12. CrowdWorks Inc.｜ （4）バラついてるデプロイツール • Lambdaのデプロイツールは、時代によって移り変わりがある • CWでは、ApexやServerless Frameworkが使用されていた ◦ Apexは、GitHubリポジトリがアーカイブ済み ◦ Serverless Frameworkは、裏でAWS CloudFormationを使っていて見通しが悪い • よりシンプルなLambdaのデプロイツールとして、lambrollに統一しました ◦ https://github.com/fujiwara/lambroll ▪ カヤックの藤原さんが作成しているツール 12
13. CrowdWorks Inc.｜ CrowdWorks Inc.｜ 試行錯誤の結果 13 13
14. 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を分けている
15. 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 }}
16. 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内で実行する方法を採用した
17. CrowdWorks Inc.｜ CrowdWorks Inc.｜ まとめ 17 17
18. CrowdWorks Inc.｜ まとめ • 実施 ◦ AWS LambdaのGitHubリポジトリをモノレポ構成にした ◦ 使用言語はGoに寄せ、CI/CDはGitHub Actionsに寄せた ◦ デプロイツールは、lambrollに統一した • 結果 ◦ 管理対象のGitHubリポジトリが減り、使用言語やCI/CDのパターンが減った ◦ AWS Lambdaのメンテナンスコストと認知負荷を削減出来た 18
19. CrowdWorks Inc.｜ CrowdWorks Inc.｜ ご清聴いただきありがとうございました 19 19 クラウドワークス エンジニアブログ ※詳細はテックブログをご参照ください