テクブロ — 技術ブログの新着まとめ

既読のみBASE

30件

フィード

BASE·2026/05/18

「ルールを押し付けない」ガバナンスをエンジニアリングする。Product Governanceの裏側

はじめにこんにちは、BASE株式会社 Product Governance（通称：プロガバ）チームの緒方です。突然ですが、皆さんは「IT統制」や「ガバナンス」と聞いてどんなイメージを持ちますか？「開発スピードが落ちそう」「お堅い事務作業」……そんな風に思われがちなこの領域ですが、我々は少し違います。今回は、私たちがどのような思いで「守り」を「攻め」に変える仕組み作りをしているのか、その裏側をお話しします。転職を考えている方も、そうでない方も、新しいキャリアの形としてご一読いただければ幸いです。 3年半で激変した、BASEのIT統制を取り巻く環境前回、IT統制についてのブログを投稿させていただいてから早くも3年半が経過しました。この間、BASEグループは目まぐるしい変化を遂げています。 2024年のwant.jp、2025年のEストアー、そして2026年のPortと、次々と新たな仲間がグループに加わりました。これだけでも大きな変化ですが、同時に「PAY.JP」や「YELL BANK」といった既存プロダクトも右肩上がりで業績を拡大しています。（「事業計画及び成長可能性に関する事項」より抜粋）事業が広がり、複雑さが増せば、当然ながらJ-SOX（内部統制報告制度）における評価対象範囲も年々広がっていきます。「異なる文化やシステムを持つ組織でどこまで共通の整備を行っていくべきか？」「急成長する決済・金融事業の信頼性をどう担保するか？」 BASEの行動指針である「Move Fast」を維持しながら、上場企業としての「信頼性」を鉄壁なものにする。この難易度の高いミッションに、かつてないほどやりがいと魅力を感じつつ、日々取り組んでいます。結局、プロガバって何をする人？私たちの役割を一言で言えば、「プロダクトの成長を支える、ガバナンスの設計者」です。大きく2つのミッションがあります。開発現場と監査の「最高の通訳」になる監査法人や内部監査室が求める「守り」の基準と、エンジニアが求める「開発の自由度」。この一見相反する両者の間に立ち、エンジニアリングの知識をフル活用して「これなら現場も納得できるし、統制も取れる」という最適解を導き出します。ガバナンスを「仕組み」で解決する（Engineering for Governance）プロダクト開発のスピード、業務スピードを落とさないためにも「手作業でチェックして承認をもらう」ような面倒なプロセスは徹底的に排除します。以下は主な具体例です。 GitHub Actions / GAS / Slack App を駆使した証跡取得の自動化 AI（LLM）を活用したシステムログチェックの効率化非エンジニア部門に対する内部監査室と連携した業務フローの再構築やシステム化の提案「ルールを押し付けるのではなく、ルールを意識しなくて済む仕組みを作る」ことを目指しています。ここで働くからこそ得られる「プロガバの魅力」 IT×会計・監査のハイブリッドキャリア技術スタック（AWS, GitHub, SQL等）を維持しながら、ビジネスの根幹である経理・法務・監査の深い知識が身につきます。この両方の言語を話せる人材は市場価値が極めて高く、エンジニアとしてのバックグラウンドを活かした「唯一無二の専門性」を築くことができます。グループ全体を俯瞰する「鳥の目」が手に入る特定の機能開発や一つのプロダクトにとどまらず、グループ各社の事業成長や組織構造を横断的に見渡すことができます。経営層に近い視点で「組織がどう動いているか」を肌で感じ、プロダクトを俯瞰して捉えられるのは、このポジションならではの醍醐味です。 AI時代だからこそ光る、代替不可能な「人間力」昨今、多くの業務がAIに置き換わろうとしていますが、プロガバの仕事の核は「正解のない問いに、人間としての納得感を持って答えを出すこと」にあります。ルールを自動化する仕組みはAIで作れるかもしれませんが、「このリスクをどう解釈し、開発現場の熱量を削がずにどう落とし込むか？」という高度な判断や、ステークホルダーとの泥臭い調整は、人間にしかできません。ここで得られる経験やビジネススキルは、AIには当面取って代わられない、一生モノの武器になると確信しています。おわりに現在、BASEグループではこの「Product Governance（プロガバ）」を一緒に作り上げていく仲間を強く求めています。「ガバナンスの経験はないけれど、技術を使って組織を良くすることに興味がある」「エンジニアとしての経験を、より経営に近い領域で活かしてみたい」そんな思いをお持ちの方、まずは難しく考えず、カジュアルにお話ししてみませんか？ 👉[Product Governance の求人詳細・応募はこちら] open.talentio.com また、プロガバ以外にも、BASEグループではさまざまな職種・ポジションで募集を行っています。「BASEという会社そのものに興味が湧いた」という方も、ぜひ一度採用ページを覗いてみてください。 👉 [BASE株式会社採用サイト] binc.jp

SRE
AWS
GitHub
生成AI

BASE·2026/04/24

PHPカンファレンス小田原2026のブース企画でスタンプラリーをやりました

はじめにこんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（@ykagano）です！ 2026/4/11（土）に開催されたPHPカンファレンス小田原2026にブース出店し、今年は「UMECO周辺のBASEショップを巡ろう！小田原ショップスタンプラリー」と題した企画を実施しました。こちらの特設サイトからスタンプラリーをすることができます（5/11までの限定公開）。 odawara2026.thebase.in 当日のスタート地点となっていたUMECOのスタンプ獲得画像です。 UMECOでのスタンプ獲得 BASEをご利用のショップオーナーにご協力いただき、UMECO周辺の実店舗をスタンプラリーのチェックポイントとさせていただきました。ご協力いただいたショップオーナーの皆さまありがとうございました！スタンプラリーサイトの実績早速ですが、スタンプラリーサイトの実績についてです。 4/11のアクセスユーザー数とスタンプ獲得数がこちらになります。対象件数アクセスユーザー数 75 スタンプ獲得数 63 スタンプ種類数 6 今回のイベント参加者は150名ほどと伺っていたので、約半数の方にアクセスいただけて嬉しいです。スタンプを全種類獲得された方はまだいませんが、ご自身のスマホでほとんどの方が最初のスタンプは取っていただけたようです。当日は暑かったため、散歩するにはあまり向いていなかったと思います。それにも関わらずスタンプを獲得していただいた皆さまありがとうございました。以降はスタンプラリーサイトの企画から実装についてお話ししていこうと思います。スタンプラリーサイトの企画私はこれまで何度かブーススタッフを担当してきましたが、企画段階から参加したのは今回の小田原イベントが初めてでした。今回のスタンプラリーサイトの企画が、これまでと大きく方向性が変わったのは同僚の02さん（@cocoeyes02）からの一言がきっかけだったと思います。 Slackでの02さんの投稿こちらの発言の後、ブレインストーミングをして、アイデアを持ち寄った後、最多投票だったのがシンプルスタンプラリーでした。 Figmaの付箋この段階ではまだどうやってやるかは決まっておらず、ボード型のマップにするのか、パンフレット型のマップにするのか色々と話し合った結果、今はバイブコーディング（AIへ会話的にコードを高速生成させる開発スタイル）もあるので、スタンプラリーサイトを作ってみようということになりました。スタンプラリーサイトの実装スタンプラリーサイトはClaude Codeを使って実装しました。実装期間は合計で3日程度でした。技術スタック技術スタックは以下を使用しています。レイヤー技術フロントエンド HTML / CSS / Vanilla JavaScript フロントエンドデプロイ S3 + CloudFront マップ Leaflet.js + OpenStreetMap バックエンド AWS Lambda (Node.js) フロントエンドはビルドのないシンプルな作りとなっており、バックエンドもサーバーレスです。データの永続化当初、LocalStorageにスタンプ獲得を記録するプロトタイプを作ったのですが、会社で同僚のパンダさん（@Panda_Program）に見せたところ、LocalStorageに値を入れて小田原にいないのにスタンプを獲得されてしまいました。そのため、簡単に偽装ができないように、スタンプの獲得判定はバックエンドで行うようにしました。デザイン WebサイトをAIで生成すると人間があまり選ばないようなデザインになる部分がありました（影を付けたり角丸にしたり濃い色を使ったり）。この辺りは一つずつ確認した上で、なるべくシンプルなデザインになるように修正していきました。工夫した点チェックポイントを目立つように工夫しました。チェックポイントの100m以内に近づくと光るようにしています。 100m以内にあるチェックポイント 50m以内に近づくとスタンプ獲得ボタンが表示されます（これも光ってます）。 50m以内にあるチェックポイント本当はスタンプが獲得できるようになったらスマホを振動させることもしたかったのですが、Vibration API にSafariが対応していないことから実装は見送りました。今回こうした普段作っているものと方向性の違うアプリケーションを作成するのは、色々と考えるところがあって面白かったです。おわりにスタンプラリーサイトはまだ2週間近く公開予定ですので、小田原に行かれた際にはぜひご利用ください。 BASEではこのように技術イベント・カンファレンスへのスポンサー協賛活動に取り組んでいます。ブース企画などにご興味がある方はぜひ採用情報をご覧ください！ binc.jp

AWS
フロントエンド
サーバーレス

BASE·2026/04/22

継続的な負荷テスト環境をBASEに構築しました〜第2回: 負荷生成ツールの構築と運用

はじめにこんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（@ykagano）です！こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第2回の記事です。先に第1回を読んでいただくのをおすすめします。継続的な負荷テスト環境をBASEに構築しました〜第1回: 負荷テストの全体像 - BASEプロダクトチームブログこちらは第1回で紹介したBASEの負荷テスト環境の構成図です。負荷テスト環境の構成図本記事では、負荷テストツールとして採用したLocustの選定理由から、実際の構築・運用方法までを紹介します。負荷生成ツールの選定負荷テストのリクエスト元となる負荷生成ツールの選定を行いました。選定の際は、まず今回の要件として以下の通りまとめました。 OSSであるクラウドはコストとセキュリティの両面でハードルが上がるため分散実行が可能である継続的負荷テスト環境としてスケーリングは必要 Web UIがあるレポート品質が高い学習コストが低いメンバーの誰もが利用できるようにしたい実績が豊富である OSSが今後も保守される可能性が高いこうした観点から参考として整理したOSSの比較表が以下となります。ツール名分散実行可能 Web UI レポート品質学習コスト実績が豊富特徴 Locust ◎（Master/Worker が標準） ◎ ○ Web UI 低 ○ OSSで最も簡単にクラスタ構成可能。Pythonでシナリオが柔軟。中規模負荷に強い。 Taurus ○（バックエンドの Locust/JMeter/k6 を分散実行管理） △ ○（バックエンド依存）低〜中 △ CI/CDで分散テスト統合運用。YAMLでテストランナー統一。チーム利用に最適。 JMeter ○（分散実行あり、構成は複雑） △（要プラグイン） ◎ HTMLレポート中 ◎ GUI派に最適。歴史が長く安定。大規模負荷にも実績豊富。 k6 OSS △（K8s/CIで水平スケール。自動クラスタなし） ✕ △（外部連携で補完）低〜中 ○ K8sベースのスケール前提なら実質分散可能。軽量で高性能。 Gatling △（OSS版は限定的。分散は Gatling Enterprise 推奨） ✕ ◎ HTMLレポート中〜高 ○ Scala/Java DSLで高精度なシナリオ記述。レポートが非常に詳細。高スループット計測に強い。 k6、JMeter、Locustは自身で使ったことがありました。 k6は軽量ですが、Web UIがなく、分散環境で実行した場合、サーバーごとに出力されるレポートの収集が必要なのが懸念でした。 JMeterはテストシナリオを作るための構成が独特で理解に時間がかかるため、学習コストが高いと感じていました。 LocustはWeb UIから容易に実行でき、Pythonでテストシナリオを書く体験が良かったので、今回もLocustを選定することにしました。 Locustの公式ドキュメントはこちらを参照ください。 https://locust.io/ Locustの構築と実行 ECSに構築しました。ECSはAWSのコンテナ管理サービスです。 LocustはMasterとWorkerのタスクに分かれて起動します。 MasterはWeb UIとWorkerの管理を行い、Workerが実際の負荷をリクエストします。 Workerの数を増やすことで、負荷リクエストの上限も増やすことができる構成です。 ECSでのLocustの構成 Classごとに実行が可能で、ProfileでGold環境とBronze環境を切り替えられるようにしています。 Locustの実行画面実行結果はWeb UIからRPS、Response Times、User数がチャートで見れます。 Locustの実行結果実際に負荷テストを実行する際は、急激な負荷増加によるスパイクを避けつつ安定状態を観測するため、30秒程度で全てのUserがRamp upするようにして5分間の負荷をかけています。そして5分の間、応答速度が安定的であるかどうかチャートを見ながら確認しつつ負荷テストを行っています。 Terraformを用いたインフラのコード化 Locustを配置している負荷テスト環境のインフラはTerraformで管理しています。 Terraformはインフラの構成を「設定ファイル」として記述できるOSSです。 AWSコンソールから設定せず、Terraformを用いてコード管理することで以下のメリットがあります。負荷テスト環境で使用しているリソースをコードから確認できるコードベースでAIに環境構築を依頼できるため、構築が早い環境の起動と破棄がGitHub Actions（GHA）から実行できるこれにより、負荷テスト環境を使用する時だけ起動し、使い終わったら破棄するといったこともできます。しかし、負荷テスト環境の構築を始めた当初、チーム内にTerraformを使用したことのある知見がなかったため、メンバーから提案をいただき、まずAIにAWSの基礎知識を含めた学習用コンテンツを作ってもらうことから始めました。 AIは主にClaude Codeを使用しています。こちらが学習コンテンツの一部ですが、このような資料を作っていました。学習コンテンツまた環境構築自体も、Claude Codeに設計書を書いてもらい、チーム内でレビューをし、何度も修正を繰り返した上で、Claude CodeにTerraformのコードに落とし込んでもらうという形で進めました。作成されたコードのレビューはチーム全員で行い、全員が負荷テスト環境について知識を揃えるようにしました。また今回Terraformのフォルダ構成として、以下の通りcoreとruntimeという二つのフォルダに分けています。 core：常設リソースの配置場所で、destroy不可に設定して常設リソースを保護します runtime：一時的なリソースの配置場所で、destroy可能とすることでコストを削減しますこれにより、インフラの起動時間の短縮とコストの削減を両立させることができます。今回はTerraformの構成についての知見も得ることができ、良い経験になりました。負荷テストシナリオの作成 LocustではPythonでテストシナリオを書くことができます。下記はClaude Codeに書いてもらったサンプルコードからの抜粋ですが、コードの組み立て方は実コードとあまり変わらないため、イメージしやすいかと思います。 """Locust による会員登録フローの負荷テストシナリオ""" import json import os import random import string from locust import HttpUser, between, task DEBUG = os.getenv("DEBUG") == "1" def random_email(): """テスト用のユニークなメールアドレスを生成する""" rand = "".join(random.choices(string.ascii_lowercase + string.digits, k=10)) return f"test_{rand}@example.com" def log_response(label, response): if not DEBUG: return code = response.status_code mark = "✓" if 200 <= code < 300 else "✗" print(f" {mark} [{code}] {label}") if code >= 400: print(f" body: {response.text[:200]}") class UserRegistration(HttpUser): """新規会員登録フローのシナリオ""" wait_time = between(1, 3) @task def register(self): email = random_email() # 1. 仮登録（メール送信リクエスト） with self.client.post( "/api/v1/signup", json={"email": email}, catch_response=True, ) as r: log_response("signup", r) if r.status_code != 200: r.failure(f"signup: {r.status_code}") return token = r.json().get("confirmation_token") if not token: r.failure("signup: token missing") return # この後の処理は省略</

Locust
AWS
Terraform
ECS
GitHub Actions

BASE·2026/04/15

継続的な負荷テスト環境をBASEに構築しました〜第1回: 負荷テストの全体像

はじめにこんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（@ykagano）です！ Checkout Reliabilityチームはカートの信頼性を向上させるためのチームです。今回、BASEのカート機能を安定的に提供するために、継続的な負荷テスト環境を構築しましたので第1回として、本記事では全体像を紹介します。全3回の記事を予定していますので、よろしくお願いします。 BASEの負荷テスト BASEではこれまで負荷テストは必要に応じて都度実施していました。 k6 というオープンソースソフトウェア（以降OSS）の負荷テストツールを使って、BASEのカートへの商品追加から購入完了までのシナリオの負荷テストを行い、負荷が高まっても機能的な問題がないことを確認していました。しかし、この都度実施の負荷テストには以下の課題がありました。負荷テストの課題 1. 以前作成したテストシナリオがシステムの仕様変更で動かない状態になっている k6のテストシナリオはJavaScriptで書けるのですが、例えば購入可能な状態にするために必要なAPIやパラメータが一つ増えていたりすると修正が必要になります。 2. 外部APIの仕様変更で、外部APIに見立てたモックのコード修正が必要になっている商品を購入する際には、BASEから社外の決済APIを呼び出しているのですが、開発環境とはいえ、社外の決済APIに負荷をかけるわけにはいかないため、決済APIの応答に見立てたモックを用意しています。そのため、この社外APIの仕様が変更になるとモックの方もコード修正が必要となります。 3. 新機能を作成した後、改修の度に負荷テストを行っておらず、現在のキャパシティ（負荷に対する許容量）が分からない当時行った負荷テストの記録は残っているのですが、仕様変更があった今も同じキャパシティを維持できているのかは負荷テストをしてみないと分かりません。しかし、再度負荷テストをするためには、前述のハードルがあります。これらの課題を解決して、継続的に負荷テストを行えるようにしよう、というのが今回の取り組みです。負荷テスト環境の要件継続的な負荷テスト環境として求めた要件は以下となります。 1. 負荷テストを自動で定期実行し、結果をレポートできる定期的に負荷テストを行うことで、仕様変更によるエラー等を早期に検知できることを求めました。 2. 負荷生成ツールもモックもスケールアウトできる k6のようなシステムに負荷を与えるためのツールを負荷生成ツールと呼びます。この負荷生成ツールとモックの両方を今後システム規模が大きくなっても追従して高負荷を与えられるように、負荷生成ツールやモックの台数を増やす機能を求めました。 3. モックがノーコードで更新できるこれまで使っていたモックはPHPによる独自実装をしていました。これだと仕様が変わるとコードの変更が必要です。今回はOSSのモックツールを使用することで、コードの変更をせずにモックの仕様を更新できる機能を求めました。ベストプラクティスの調査これらの要件に加え、負荷テスト環境としてのベストプラクティスを調査したところ、下記の記事を見つけました。引用：負荷テストの全体像を理解しよう｜AWS（第1回/全3回）ベストプラクティスの部分を抜粋します。実際のワークロードを使用して負荷テストを行い、自身のワークロードが本番環境でどう動作するのかを確認すること本番環境同等のサイズの環境を利用して試験を行うこと。また、本番環境同等の量・バリエーションのデータを、本番環境データを匿名化したり模擬的に作成したりして用意することユーザーの実際の行動をリプレイ、もしくはプログラム的に再現することで、大規模にアーキテクチャ全体に対して負荷をかけることデリバリーパイプラインの一環として負荷テストを自動的に実行し、事前に定義した性能目標と比較して評価し、要求性能を満たせるかどうかを継続的に保証することベストプラクティスに書かれていることは、私が負荷テスト環境に求めた要件とほとんど同じですが、負荷テストの考え方が間違っていない裏付けとして非常に参考になりました。負荷テストツールの選定こうした考え方を元に、継続的な負荷テスト環境の要件を満たすための負荷テストツールを選定しました。負荷生成ツールには Locust を選定しています。また外部APIのリクエストを受けるために WireMock を選定しました。それぞれの詳細については第2回以降の記事で説明したいと思います。負荷テスト環境の構成最終的に負荷テスト環境の構成は下図となっています。左が負荷生成ツールとモックツールを使用する負荷テストツール。右が既存のBASEシステムと同等の負荷検証システム（簡略）となります。負荷テスト環境のシステム構成図実際のリクエストと同様にインターネットを跨いでリクエストを処理するようにしています。ここからは負荷テストの構築にあたり進めた内容についてお話しします。キャパシティプランニング負荷テスト環境を構築するために、キャパシティプランニングを行いました。まず以下の2点を確認しました。 BASEのGMV（流通取引総額）がこの先どれぐらい増加する想定なのか現時点での本番環境での最大負荷はいくつなのか 1に関しては事業計画を参照すれば分かりますが、2に関しては、どこの負荷を基準とするかを検討しました。 BASEのカート機能には注文APIがありますので、そのAPIに対する負荷を基準にすることにしました。またBASEではこれまでrpm（requests per minute）を基準にしていましたが、今回は高負荷状態を基準にするため、rps（requests per second）を基準にすることにしました。ここでは注文APIの過去の最大負荷を仮に1,000rpsとします。また事業計画として2年後のGMVが仮に1.5倍になるとします。そうすると、2年後にはrpsも1.5倍の1,500rpsが最大負荷として想定されます。しかし、あくまで成り行きで増える見積もりとなるため、上ブレすることも考えて多めに見積もりを行いました。増加分の500rpsを2倍にして上振れ含め1,000rpsになるため、2,000rpsを目標値とします。このような考え方で、今回構築するシステムの負荷テスト可能なキャパシティとして設定しました。負荷テスト環境の構築キャパシティプランニングでは、注文APIの負荷を仮に2,000rpsと設定しましたが、2,000rpsはあくまで注文API単体の負荷となります。今回購入のワークロードを対象としているため、そのワークロードでは20を超えるAPIを利用しており、全体としては数万rpsの負荷が想定されました。こうした要素を加味して、負荷テスト環境のシステム要件を決めていきました。 Gold環境本番と同等の負荷検証システムは、既に以前から使っているGoldという名前の環境があったため、それを今回も利用することにしました。しかしこのGold環境は、本番と同等のDBを使用するため、本番相当のデータ量の準備に数時間かかるという課題がありました。負荷テスト環境は最終的に負荷テストの定期実行までを見据えていました。負荷テスト環境の起動後、負荷テストを実行し、負荷テスト環境の破棄まで行う想定です。しかし、定期実行が準備だけで数時間かかるとなると、コンテンツのデリバリー途中でタイムアウトする可能性もあります（実際にこのデータ準備の処理が何度か止まっていることがありました）。再実行が頻繁に必要になってくると定期実行に支障が出ます。 DBが巨大すぎるため、Gold環境での定期実行は難しいことが分かってきました。巨大なDBは存在するだけで多大なコストがかかるため、定期的に数時間利用するだけでも多大なコストがかかります。定期実行ではこの課題を解決する必要がありました。 Bronze環境本番同等の環境で負荷テストを行うというベストプラクティスには反するのですが、Gold環境での定期実行の課題を解決するため、負荷テストを自動で定期実行し、結果をレポートするための環境として本番よりスペックの低い縮小環境も今回用意することにしました。この縮小環境には Bronze と名付けました。命名理由としてはすでにSilver環境を別用途で使っていたためです。このBronze環境があれば、テストシナリオの修正と確認もBronze環境で容易に行えます。最終確認としての負荷テストはあくまでGold環境を使用しますが、定常的に必要最小限のキャパシティを担保するには、Bronze環境でも十分要件を満たせると考えました。 Bronze環境では開発環境のデータベースをそのまま流用することにしました。システムの仕様としては、本番環境の構成を縮小した形で仕様を決めていきました。 Gold環境とBronze環境の比較項目 Gold環境 Bronze環境目的本番想定の最終的な負荷検証継続的な負荷テスト・定点観測スペック本番同等本番より縮小データ量本番同等（大規模）開発環境のデータを流用起動時間数時間（データ準備に時間がかかる）比較的短時間コスト高い低い実行頻度必要に応じて実施定期実行（週次）主な用途最終確認・性能限界の検証早期検知・継続的な品質担保メリット本番に近い精度の検証が可能手軽に何度でも実行できるデメリットコスト・準備時間が大きい本番との差異がある Bronze環境で継続的に異常検知を行い、最終的な性能検証はGold環境で行う、という役割分担にしています。チームでの構築今回、チームで負荷テスト環境の構築を進めていきました。草案は私の方で作成しましたが、設計は全員で行いました。その後、Bronze環境の構築、AWSインフラとLocust環境の構築、WireMock環境の構築と3つに分かれて構築を行いました。私は主にBronze環境の構築を行ったのですが、BASEのテスト環境を1セット作成する作業のため、BASEのシステムに対する解像度を上げることができ、非常に良い経験を得られました。 Bronze環境での継続的負荷テスト毎週月曜に以下のスケジュールで負荷テストを自動実行しています。時刻内容 AM3:00 アプリケーションの自動デプロイ AM7:00 負荷テストの自動実行負荷テストの自動実行はGitHub Actionsのワークフローで行っています。以下のジョブが40分程度で実行されます。負荷テスト開始の通知 Bronze環境の起動負荷テストツールの起動負荷テストの実行（メインシナリオ1）負荷テスト結果の通知負荷テストの実行（メインシナリオ2）負荷テスト結果の通知負荷テストツールの停止 Bronze環境の停止負荷テスト完了の通知負荷テスト結果はSlackに投稿されます。以下はレポート内容の例ですが、注文API（post_orders）に対するrpsとAPI全体（aggregated）のrpsを見れるようにしています。 post_orders: requests=2000 failures=0 avg_time=20ms avg_rps=8.0, aggregated: requests=80000 failures=400 avg_time=500ms avg_rps=300.0 これで毎週最新のアプリケーションでキャパシティの定点観測ができる状態になりました。本番と同等の挙動ではないですが、もしパフォーマンスの低下があれば週次で検知できます。また今後負荷テストを実施したい場合にも、すぐに使える環境があるため、負荷テスト実施のハードルも下がってくれるのではないかと期待しています。 Gold環境での本番想定の負荷テスト Gold環境での負荷テストは当初パフォーマンスが想定したよりも出ませんでした。本番と同等の環境ではありますが、本番と仕様や設定が一部異なっていたため、それらを本番と揃える作業が必要でした。また本番と挙動が異なる部分もありました。これは外部APIの通信時間を細かく本番と合わせたり、外部APIが本来持っているRate Limit（一定時間内にリクエスト回数の上限を設ける機能）の機能を再現するための仕組みを入れることで徐々に解決していきました。負荷テストは実行してパフォーマンスが出ない場合にどこが原因か調査しボトルネックを見つけることも大事ですが、パフォーマンスをもっと出すためにはどうすればいいかは、仮説を立てる必要があります。そのため、負荷テストの実施前に負荷改善の仮説DBをNotionに作成し、この辺りを改善すればより早くなるのではないか、といった仮説をチーム内で思い付いたものがあれば、確度が低くても良いのでどんどんDBに入れていくことにしました。今後はこの負荷テストの結果と仮説を元に、BASEのカートの安定性をより高めるための施策を実施していく予定です。おわりに今回の記事では、継続的な負荷テスト環境の全体像と設計方針について紹介しました。第2回では負荷生成ツールの構築と運用について、第3回ではモックツールの構築と運用についてお話しする予定です。順次公開しますので、ご期待いただければと思います。このようなシステム環境で働きたいエンジニアの方はぜひ採用情報をご覧ください！ binc.jp

負荷テスト
AWS
GitHub Actions
Locust
WireMock