業務効率化したいのに時間がない？？OSSとLambdaを用いたツールのスピード開発術

AWS Jr.Champions登壇資料。AWS関連のOSSをLambdaを用いたサーバーレスで実現する方法とユースケースの紹介。

Transcript

1. / 2024/09/27 Jr. Chamipions Meetup LTs 豊岡大地 業務効率化したいのに時間がない？？ OSSとLambdaを用いたツールのスピード開発術 少しマニアックな内容になってしまったかもしれません
2. / /14 ―― Agenda ―― ０ 01. 自己紹介 02. 業務効率化の課題点 03. 今回の業務効率化の契機 04. 技術Tipsの紹介 投影画面だとフォントが小さいので資料もご確認ください
3. / /14 ―― 現場で転がっている業務効率化できる数々… ―― ２ 自社業務を進めていく中で、 反復的な作業/非効率な進め方を矯正する効率化に取り組んでいる方も多いのではないでしょうか？ 解決策はツールには限りませんが、自社業務の効率化ツールは多くのリターンが得られます。 ＋若手エンジニアの技術的な育成機会創出にもつなげることができます。 弊社の実績例）エスカレーション効率化、設定値の大幅変更など 一方でメリットだけでなく、下記のようなデメリットを見る機会も増えてきました ✓ 自社業務の効率化であるため、優先度がどうしても下がってしまいがち ✓ ツールの運用（異動などによる）の体制がしっかりと組めていない
4. / /14 ―― 今回の発表対象とした業務効率化 ―― ある日の日常… Aさん：「今月のクラウド使用料やたら高い！なぜだ？？」 Bさん：「稼働し続けているリソースがある！」 ⇒定期的な棚卸しをしたいものの、、 勝手にリソースを削除するとトラブル/インシデントに繋がる可能性も、、 ３
5. / /14 ―― 弊社の検証環境事情 ―― 弊社の検証環境では、、 常時30名以上が利用する 習熟や案件検証も兼ねたAWS環境 × コスト肥大化 リソース数上限管理 案件のフェーズによって、アカウントを切り替えます。 したがって、時期によっては削除されたら困るものもあり、棚卸しにもヒアリングなどが必要 ４
6. / /14 ―― 弊社の検証環境事情 ―― パワー（ヒアリング、周知徹底） を掛けて、棚卸しを実施するものの、、 9ヵ月程度で戻ってしまう、、 縦軸：コスト；横軸：月 ５
7. / /14 ―― 弊社の検証環境管理のアプローチ ―― 恒久的な対策として、下記の解決策で実施。 ※Control TowerのSandBox OUのAccount Factoryも考えていきたい。  棚卸し面 各種アカウントリソースを確認/削除できるサー バーレスウェブアプリケーションを若手主体で 開発着手（デザインはホワイトペーパーとマネコンをイメージ）  コスト把握面 月次開催でコストを振り返る会を開催して、 各種アカウント/サービスのコスト傾向を把握 ６
8. / /14 ―― 現場で転がっている業務効率化できる数々… ―― 再 自社業務を進めていく中で、 反復的な作業/非効率な進め方を矯正する効率化に取り組んでいる方も多いのではないでしょうか？ 解決策はツールには限りませんが、自社業務の効率化ツールは多くのリターンが得られます。 ＋若手エンジニアの技術的な育成機会創出にもつなげることができます。 弊社の実績例）エスカレーション効率化、設定値の大幅変更など 一方でメリットだけでなく、下記のようなデメリットを見る機会が増えてきました ✓ 自社業務の効率化であるため、優先度がどうしても下がってしまいがち ✓ ツールの運用（異動などによる）の体制がしっかりと組めていない
9. / /14 ７ ―― やっとお伝えしたいTips！！！ ―― 棚卸しアプリケーションでは、下記の要件が面倒、、 すでに似たような内容をOSSで作られている方が、、！ 特定リソースの詳細情報取得 提供API： 各種サービスのdescribe系 特定リソースの削除 提供API： 各種サービスのdelete系 OSS awsets (trek10inc/awsets) OSS aws-nuke (ekristen/aws-nuke)
10. / /14 ―― OSSをAPIとして構築するには、、？ ―― ８ OSSで提供されている形式は、Linux上でのコマンド提供がほとんど、、  awsets ```bash awsets list -–include ${service} -–profile ${AWS_PROFILE} ```  aws-nuke ```bash aws-nuke -c config.yml --profile ${AWS_PROFILE} ``` なるべくサーバーレスにこだわりたい、、 LambdaのランタイムでBashを選択できるのは次の2つの選択肢があります！ 1. Custom Runtime：https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-walkthrough.html 2. Container Runtime：https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images-create.html
11. / /14 ―― OSSをAPIとして構築するには、、？ ―― ９ LambdaでOSSが提供するコマンドを叩いてAPI形式のように構築するには、 下記のロードマップを立てました。 01. Custom Runtime 02. Container Runtime 03. AWS CLI 04. awsets* 検証なのでLambdaURLでAPI形式としてデプロイ *aws-nukeは無し （別途説明）
12. / /14 ―― Custom Runtime ―― チュートリアル通りに一度実施、、！ bootstrap #!/bin/sh set -euo pipefail # Initialization - load function handler source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh" # Processing while true do HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018- 06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) # Run the handler function from the script RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA") # Send the response curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06- 01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE" done function.sh #!/bin/bash function handler () { EVENT_DATA=$1 echo "aws --version" 1>&2 RESPONSE="'${EVENT_DATA}'" echo $RESPONSE } 10 【大まかな手順】 1. Bootstrapをlayerとして登録 2. 使いたいコマンド群を追加layerとして登録 ※容量が多すぎると、一度S3にzipを上げる必要がある 3. function.shをzip化して登録 スクリプト内で新しいコマンドが増えると都度 Layer登録の流れになる。 個人的には、、 開発段階のトライ＆エラーとしては△ >&2 でCloudWatchlogsに出力
13. / /14 #!/bin/bash function handler () { EVENT=$1 echo "${EVENT}" >&2 if echo "$EVENT" | jq -e 'has("body")' > /dev/null; then BODY=$(echo "$EVENT" | jq -r '.body') else BODY="$EVENT" fi BUCKET_PREFIX=$(echo ${BODY} | jq -r '.prefix') BUCKETS=¥ $(aws s3 ls | grep ${BUCKET_PREFIX} | awk '{print $3}' | jq -R . | jq -s .) RESPONSE=$(jq -n ¥ --arg status "success" ¥ --argjson buckets "$BUCKETS" ¥ '{"status": $status, "buckets": $buckets}' ) echo ${RESPONSE} | cat } ―― Container Runtime with AWS CLI ―― 11 Container Runtimeは、 新規コマンドはレイヤー登録じゃなくてDockerfileに都度記載追加で良いので効率がよい！ Dockerfile FROM public.ecr.aws/lambda/provided:alami.2024.09.17.15 RUN yum update -y && ¥ yum install -y unzip wget jq && ¥ wget "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" ¥¥ -O "awscliv2.zip" && ¥ unzip awscliv2.zip && ¥ ./aws/install COPY bootstrap /var/runtime/bootstrap COPY function.sh /var/task/function.sh RUN chmod +x /var/runtime/bootstrap ¥ && chmod +x /var/task/*.sh CMD ["function.handler"] function.sh 【大まかな手順】 1. DockerImageをビルドしてECRにPush 2. Lambdaで更新 ※bootstrapは同じでOK そのまま出力結果を返すと、 APIとしての出力形式は担保されない、、 echoの結果をawk/jqコマンドで整形して あげて返すと、従来の返り値に！ #awk, jqの応用編みたいな書き方に、、 内部と外部キックでInputの 渡され方が異なるのでvalidation
14. / /14 ―― Container Runtime with AWS CLI ―― 11 Container Runtimeは、 新規コマンドはレイヤー登録じゃなくてDockerfileに都度記載追加で良いので効率がよい！ curl -X POST ${url} -H "Content-Type: application/json" -d '{"prefix": “parameter"}'
15. / /14 FROM public.ecr.aws/lambda/provided:alami.2024.09.17.15 RUN yum update -y && ¥ yum install -y unzip wget jq RUN wget "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" ¥¥ -O "awscliv2.zip" && ¥ unzip awscliv2.zip && ¥ ./aws/install RUN wget “https://github.com/trek10inc/awsets/releases/${v}.tar.gz” ¥¥ -P /usr/local/src && ¥ tar xvzf /usr/local/src/${v}.tar.gz -C /usr/bin COPY bootstrap /var/runtime/bootstrap COPY function.sh /var/task/function.sh RUN chmod +x /var/runtime/bootstrap ¥ && chmod +x /var/task/*.sh CMD ["function.handler"] ―― Container Runtime with awsets ―― 12 いよいよ本題の要件を満たせるOSS提供のコマンドを実施、、！ Dockerfile #!/bin/bash CMD="awsets" export HOME=/tmp export XDG_CACHE_HOME=/tmp/.cache CACHE_DIR="${XDG_CACHE_HOME}/awsets" mkdir -p ${CACHE_DIR} function handler () { EVENT=$1 echo "${EVENT}" >&2 if echo "$EVENT" | jq -e 'has("body")' > /dev/null; then BODY=$(echo "$EVENT" | jq -r '.body') else BODY="$EVENT" fi SERVICE=$(echo ${BODY} | jq -r '.prefix') RESOURCES=$(${CMD} list --include ${SERVICE}) RESPONSE=$(jq -n ¥ --arg status "success" ¥ --argjson resources "$RESOURCES" ¥ '{"status": $status, "resources": $resources}' ) echo ${RESPONSE} | cat } function.sh 新しいコマンド(awsets)を加える内容もDockerfileに 記述してImageを再プッシュするだけで効率が良い！ 外部コマンドを入れると、 XDG_CACHE_HOMEを定義しないといけないみたい
16. / /14 ―― Container Runtime with awsets ―― 12 先ほどの少ないコード量で情報粒度が細かい内容を取得できた！ curl -X POST ${url} -H "Content-Type: application/json" -d '{"prefix": “parameter"}' AWS Certificate Manager AWS Code Pipeline
17. / /14 ―― Container Runtime with aws-nuke ―― 13 aws-nukeはconfig.ymlを事前に用意する必要があります！ ```bash aws-nuke -c config.yml --profile ${AWS_PROFILE} ``` ⇒sedコマンドを用いて、 あらかじめの予約語をInputParamaterと置換を考えましたが、 一旦保留することにしました、、
18. / /14 ―― まとめ ―― ✓ 業務効率化ツールの開発はリターンも大きいですが、優先度やその後の運用に 課題感もあります。 ✓ 今回はAWSの検証環境の棚卸し業務効率化に着目した、API作成でOSSを利用 した工数削減のアプローチを共有しました。 ✓ 技術的にはLambdaをランタイムBashにするには、 CustomとContainerがあり、個人的には開発効率的に後者がおすすめです！ 【残っている課題感】 • Lambda URLからのAPI Gateway vs ALBデプロイ • Lambda URL経由からだと、処理がすごく遅いのでメモリなどの最適化を検討、、 14