はじめに こんにちは、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

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEが竹スポンサーとして協賛しているカンファレンス、 PHPカンファレンス小田原2026 のご紹介となります。 phpcon-odawara.jp PHPカンファレンス小田原2026 概要 PHPカンファレンス小田原は「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 2026/4/11（土）、おだわら市民交流センター「UMECO」で開催されます。 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in 登壇メンバーのご紹介 BASEで活躍しているメンバーのうち、2名が登壇予定です。ぜひ聞きにいらしてください。 レガシーPHP転生 〜父がドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜 プログラミングをするパンダ （ @Panda_Program ） 会場：かま 14:45〜 fortee.jp スポンサーLT 川口将貴（ @dmnlk ） 会場：かま 15:35〜 ブースのご紹介 当日はBASE株式会社としてスポンサーブースの出展も行います。 今年は「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施予定です。 BASEをご利用のショップオーナーの中には、ネットショップだけでなく、並行して実店舗を運営されている方もいらっしゃいます。会場であるUMECO周辺にも実店舗を構えているショップがありますので、カンファレンスで小田原にお越しの際は、ぜひ足を運んでみてください。 BASEのブースでお会いできることを楽しみにしております。 おわりに PHPカンファレンス小田原 2026 のチケットはこの記事掲載時点ですでに完売しているそうです。後日こちらのブログでも参加レポートをお届けする予定です。楽しみにお待ちください。 PHPカンファレンス小田原 2026で、みなさまにお会いできることを楽しみにしております！ 発表を見てBASEで働くことに興味を持った方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。