Cloud Operator Days Tokyo 2023 @02 AWS Lambdaから始める Devチームの小さなDevOps改善 〜QCDどれも諦めない運用を目指して〜

© 2012-2023 BASE, Inc. #CODT2023 Web Application Enginner 02 大津 和槻 ：@cocoeyes02 2021/02~ BASE, Inc. 自己紹介 PHP系カンファレンス登壇 執筆 登壇応援中！

© 2012-2023 BASE, Inc. #CODT2023 とあるしくじり話と 小さなDevOps改善 について話します 3 今回のトークでは

今回の話に出てくる サービスについて

© 2012-2023 BASE, Inc. #CODT2023 BASEとは？ 5 コンセプト： 誰でも簡単に使える ネットショップ作成サービス ● 商品・注文管理 ● ショップデザイン ● 顧客情報管理 などを行うショップオーナー向け機能 + ● 商品検索 ● 決済・注文（カート） などを行う購入者（カスタマー）向け機能 ネットショップ作成サービス「BASE」

© 2012-2023 BASE, Inc. #CODT2023 拡張機能「BASE Apps」 6 ショップ運営に必須な機能とは別に、 ショップオーナーが 自身のショップに必要な機能だけを 選択して利用できるようにする仕組み 抽選販売 App クーポン App 広告効果測定 App メッセージ App 他にも外部サービスとの 連携Appも多数…

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 App Google ショッピング広告の一種である キャンペーンがかんたんに出稿・管理で きるApp 2021年10月にリリースされ、 現在でもショップや商品の認知につなが り集客・販路拡大へ大きく貢献している

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 App Google 広告、 Google Merchant Center etc...のAPI （Googleが提供する ライブラリを含む） ※Batch, Workerなども存在するが割愛 簡易的な構成図 ショップ オーナー ログ収集サーバ （中略） Webサーバ

ある日、問題が発生

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appが 動かなくなってしまう！？ 10 Google広告APIのバージョンには以下の仕様があった ● 3~4ヶ月ごとに新バージョンがリリースされる ● 基本的に、新バージョンがリリースされてから約9ヶ月~1年後に廃止される ● 廃止されたバージョンでは、Google広告のAPIが使用できなくなる https://developers.google.com/google-ads/api/docs/sunset-dates?hl=ja

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appが 動かなくなってしまう！？ 11 公式Google 広告APIクライアントライブラリ (googleads/google-ads-php)にも、 バージョンに関する仕様と傾向があった ● APIクライアントライブラリのバージョンによって、使用できるGoogle広告APIの バージョンも変わる ● 現状約1年おきに、phpのrequireのバージョンが上がっている

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appが 動かなくなってしまう！？ 12 定期的にPHPのバージョンを上げないと、ライブラリのバージョンが上げられない ≒Google広告APIのバージョンが上げられず、廃止によってAppが動かなくなる

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appが 動かなくなってしまう！？ 13 定期的にPHPのバージョンを上げないと、ライブラリのバージョンが上げられない ≒Google広告APIのバージョンが上げられず、廃止によってAppが動かなくなる BASE全体の開発基盤を触るチームへ、PHPのバージョンを上げるように依頼 あと約2ヶ月で上げなければいけない状況になっていた（当時PHP7.3 -> 7.4） なんとか、ギリギリでバージョンは上がった 次は7.4 -> 8.0に上げなければいけない 過去10年もののコードかつメジャーバージョンアップなので、難易度は高い 前もって依頼をしよう・・・果たして本当にそれでいいのだろうか？

© 2012-2023 BASE, Inc. #CODT2023 ふと振り返る 14 そもそもとしてビジネスの命運を他チームが握っている状況は、 あまりにも不確実性が高くないか？ （例えばバージョンを上げている時に、優先度がもっと高いインシデント対応が入って しまったら？）

© 2012-2023 BASE, Inc. #CODT2023 ふと振り返る 15 そもそもとしてビジネスの命運を他チームが握っている状況は、 あまりにも不確実性が高くないか？ （例えばバージョンを上げている時に、優先度がもっと高いインシデント対応が入って しまったら？） 確かに言語のバージョンは定期的に上げていくべきではあるものの、 1つのApp（機能）のために他全て巻き込まなければいけないのは 影響範囲が広い（ハードルが高い）のではないか？そもそもその状況は健全なのか？

ビジネスを止めず確実に 自チームでコントロール できる状況を作りたい...！

© 2012-2023 BASE, Inc. #CODT2023 案：ライブラリ部分を 　　別サーバーに切り出す 17 ● 自分たちでGoogle 広告ライブラリやGoogle 広告 APIのバージョンを上げていく ことができるようにしたい ● でもサーバー管理はなるべくしたくない ○ 必要以上の運用の負荷でチームのリソースを圧迫することも望んではいない ● 運用の知見のないようなdevチームでもやっていけるようにしたい Google 広告 API webサーバ Google 広告 ライブラリを含む 運用負荷の少ない サーバ？ ？

© 2012-2023 BASE, Inc. #CODT2023 案：ライブラリ部分を 　　別サーバーに切り出す 18 どうするか ● Devチーム（自チーム）でEC2インスタンスに切り出して運用していく ● Devチーム（自チーム）でECS on fargateに切り出して運用していく ● DevチームでAWS Lambdaを運用していく

© 2012-2023 BASE, Inc. #CODT2023 案：ライブラリ部分を 　　別サーバーに切り出す 19 どうするか ● Devチーム（自チーム）でEC2インスタンスに切り出して運用していく 󰢄 　　→プロビジョニング、管理、スケーリングなど運用負荷がチームのリソースを圧迫 ● Devチーム（自チーム）でECS on fargateに切り出して運用していく ● DevチームでAWS Lambdaを運用していく

© 2012-2023 BASE, Inc. #CODT2023 案：ライブラリ部分を 　　別サーバーに切り出す 20 どうするか ● Devチーム（自チーム）でEC2インスタンスに切り出して運用していく 󰢄 　　→プロビジョニング、管理、スケーリングなど運用負荷がチームのリソースを圧迫 ● Devチーム（自チーム）でECS on fargateに切り出して運用していく ▲ →EC2よりだいぶ管理コストは少ないが、クラスターやタスク定義はちょっと面倒 ● DevチームでAWS Lambdaを運用していく

© 2012-2023 BASE, Inc. #CODT2023 案：ライブラリ部分を 　　別サーバーに切り出す 21 どうするか ● Devチーム（自チーム）でEC2インスタンスに切り出して運用していく 󰢄 　　→プロビジョニング、管理、スケーリングなど運用負荷がチームのリソースを圧迫 ● Devチーム（自チーム）でECS on fargateに切り出して運用していく ▲ →EC2よりだいぶ管理コストは少ないが、クラスターやタスク定義はちょっと面倒 ● DevチームでAWS Lambdaを運用していく ⭕ →管理コストは一番少ない →リクエスト数分だけしか金額がかからず、ECS on fargateよりも安く済みそう →AWS Lambda特有の制約も、今回の要件から考えるとクリアしている

選ばれたのは AWS Lambda

© 2012-2023 BASE, Inc. #CODT2023 AWS Lambdaとは 23 実行環境のプロビジョニングや管理をすることなく、アプリケーションコードを実行できる AWSサービス オートスケーリングしてくれる、可用性や耐障害性を考慮したインフラ構成が手に入る （自分でOSを更新したり、使用量の増加に合わせてサーバーのサイズ変更や追加を考えたり する必要がない） 様々なAWSのサービスやSaaSアプリケーションから、イベントを設定してトリガーすること ができるのでイベント駆動型アプリケーションが実現できる 詳しくはAWS公式サイトへ （詳細の説明は割愛します）

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appの 新しい構成図 Google 広告 API (Google 広告以外の Googleが提供する ライブラリを含む） ※Batch, Workerなども存在するが割愛 ショップ オーナー ログ収集サーバ Google 広告以外の Google API webサーバ (中略） Google 広告APIに リクエストを送る lambda

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appの 新しい構成図 Google 広告 API (Google 広告以外の Googleが提供する ライブラリを含む） ※Batch, Workerなども存在するが割愛 ショップ オーナー ログ収集サーバ Google 広告以外の Google API webサーバ (中略） Google 広告APIに リクエストを送る lambda API Gatewayは使用せず、AWS Lambda Function URLsを使ってコストを抑える ● そこまでリクエスト数が多いわけではない ● 実質社内サーバーとなる今回のケースにおいて、API Gatewayで使いたい機能が限られている Github Actionによるデプロイへ ● 元々はChatOpsによるデプロイだった

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appの 新しい構成図 Google 広告 API (Google 広告以外の Googleが提供する ライブラリを含む） ※Batch, Workerなども存在するが割愛 ショップ オーナー ログ収集サーバ Google 広告以外の Google API webサーバ (中略） Google 広告APIに リクエストを送る lambda PHP → Pythonに言語を変更 ● 大前提、公式ライブラリが提供されている言語にしたい ● lambdaの最新機能をすぐ使える言語にしたい ● 組織の変更によって他のチームが管理することになっても管理できる言語にしたい ● 採用戦略に沿う、さらには社内でも知見がある言語

© 2012-2023 BASE, Inc. #CODT2023 Google商品連携・広告 Appの 新しい構成図 Google 広告 API (Google 広告以外の Googleが提供する ライブラリを含む） ※Batch, Workerなども存在するが割愛 ショップ オーナー ログ収集サーバ Google 広告以外の Google API webサーバ (中略） Google 広告APIに リクエストを送る lambda Lambdaの監視もNew Relicで ● アクセスログやアプリケーションログ ● リクエスト数や平均実行時間 LogをNew Relicで同期するのもLambdaで実施

© 2012-2023 BASE, Inc. #CODT2023 新しい構成になってから変わったこと 28 Quality ● アプリケーションエラーだけでなく、リクエスト数や平均実行時間もNew Relicで見る ように Cost ● デプロイ時間は以前に比べると、1/5に短縮 ● 別サーバに切り出しつつも、リクエスト数分だけの金額だけで済んでいる ● AWS Lambdaに切り出した分の運用負荷も必要最小限に Delivery ● 言語のバージョンやライブラリのバージョンアップ作業が自チーム内で完結するように

© 2012-2023 BASE, Inc. #CODT2023 最後に 29 結果だけ見ると、単にAWS Lambdaを取り入れただけのありふれた事例と言える しかし、1つAWS Lambdaを取り入れるだけでもたくさんの意思決定や環境の変化が あった 今後、リクエスト数が増えてlambdaのコストが増えてきた時、キャッシュ戦略を取り 入れる・非同期にするなどで構成が変わることはありうる ビジネスを守るために必要なことであれば、どんどん取り入れて変化していきたい

© 2012-2023 BASE, Inc. #CODT2023 最後に バックエンド エンジニア SRE フロントエンド エンジニア セキュリティ エンジニア QA エンジニア データ エンジニア etc… We are hiring! https://binc.jp/jobs