KINTO ONE運用新型プリウス発売に備えて

再生速度

要約を読む

新型プリウスの発売に備えて、KINTO ONEのシステム負荷を990PV/分まで耐えられるようにした。その目標は過去最高負荷の10倍だったため、3%の許容範囲しかなかった。この課題を解決するために、3つの対策を実施した。まずデータベースの接続を調整した。フロントからアクセスが多い参照系のリクエストがリーダーインスタンスに集中していたため、すべての接続をライターインスタンスに変更した。その結果、負荷が分散され、リーダーインスタンスを追加するよりも手軽に効果が出た。次に見積画面の処理を改善した。車種選択時に必要なマスタ情報をDBから取得していたが、それをElasticacheのRedisキャッシュに移行した。これによりDBへのアクセスが減り、画面のレスポンスが速くなった。さらに、販売店情報の取得にかかるコストが高い箇所を特定し、インデックスを追加。その結果、クエリのコストがすべて一桁台に下がった。その後、インフラ全体を強化した。 EC2のフロントエンドを6台から36台に、バックエンドを2台から15台に増強。 Elasticacheもt3.mediumからr6g.largeに、RDSもr5.xlargeからr5.12xlargeにアップグレード。これにより、ピーク時の負荷に耐えられるようになった。発売当日の実際のアクセスは10%程度で、トラブルなく安定稼働した。見積や申込の流入も期待通りで、お客様の反応も良かった。その後、一時的に変更していた設定を元に戻した。結果としてインフラのスペックは過剰だったが、正確なアクセス予測は不可能だったため、事前の準備は成功したと判断できる。この取り組みで、システムの耐荷性が大きく向上し、大きなイベントでも安定運営が可能になった。

AI が生成した要約です。正確な内容は本文をご確認ください。

 はじめにこんにちは、KINTOテクノロジーズ新車サブスク開発グループの阿出川です。
アプリケーションエンジニアとして国内のトヨタ新車サブスクリプションサービス「KINTO ONE」の開発・保守・運用に3年間従事しております。
自動車が大好きなので仕事を通して関われてとてもハッピーです。

今は家族優先でミニバンに乗っておりますがいつかトヨタのGR車種に乗りたいです！

好きなエンジン機構は「カムギアトレーン」です！
そんなわたしが今まで関わったプロジェクトで特に印象深く達成感が大きかったお話を紹介しようと思います。
 新型プリウス発売に備えよ2023年1月10日 新型プリウス（5代目）が発売されました。

プリウスといえばハイブリッド車の先駆けで環境車としての確固たる地位を築いたトヨタの中でも注目度高い車種ですよね。
しかしプロジェクト発足当時のプリウス(先代)は既に発売からだいぶ経過していたこともあってKINTO ONE取扱い車種の中で特に人気が高いわけではなかったです。なので個人的には新型が出ても特段反響が大きいとは考えておりませんでした。
しかし掲げられた目標は*,990 PV/分 耐えられる事！

(この数値は過去最高負荷時の10倍)
その時点で許容可能だったのは目標値の3%程度でした。
主な対策ポイントは③点です。

 対策① Databaseの接続先調整RDBはライターインスタンス、リーダーインスタンス１台という構成でしたがフロントからは参照系のアクセスの方が圧倒的に多かったのでリーダーインスタンスに負荷が偏りライターのインスタンスの方は余裕がありました。

暫定的にフロントからの接続先を参照・更新問わずライターインスタンスへ接続させるよう設定変更しました。
結果、意図したとおりに負荷が分散されました。

リーダーインスタンスを追加するより手軽だったのでまずはこの方法を取り入れました。
 対策② 見積画面の改善トップ画面に次いでアクセスが多いのは車種ごとの見積画面になります。

ここでは自動車のグレード、パッケージ、オプションなどを選択しますがその車両マスター情報をリレーショナルデータベーステーブルから取得しておりました。

これをインメモリのkey/valueキャッシュ（Elasticacheのredis）に格納された車両マスタ情報から取得するよう変更し、DB負荷軽減とフロントレスポンスの改善を図りました。
次にキャッシュ化出来なかった情報でDB負荷の高い箇所を特定しました。

見積～申込までは車両情報の他、販売店店舗情報のマスタテーブルの参照しており、slow queryに挙がってくるような問い合わせは行われていないのですが発行回数が多いので塵も積ればとやらで比較的costの高い箇所は対象テーブルへINDEXを追加しquery costは全て一桁台に改善させました。
 対策③ インフラ増強①、②の対策に加え目標数値に耐えられるよう後はインフラの構成見直しで調整します。

特別な一時的な対応という事で手動スケーリングで次の通りインフラ増強を図りました。
 スケールアウト

AWS service
台数-変更前
台数-変更後


EC2 Front End
6
36

EC2 Back End
2
15

 スケールアップ

AWS service
タイプ-変更前
タイプ-変更後


EC2
スケールアウトのみ


Elasticache
t3.medium
r6g.large

RDS
r5.xlarge
r5.12xlarge

 その他急激なアクセス増加に耐えらるよう予めALBの拡張を行う為、暖気運転が必要との事で下記の情報を添えAWSへ暖気申請をしました。
予測されるピーク時間帯
予測されるピーク時のリクエスト数
トラフィックパターン
ユースケース
etc
 発売当日を迎えて負荷としては準備していた許容範囲に対して実際のアクセスはピークで10%程度でしたがトラブルもなく発売当日から安定し稼働しました。

お客様からの反響もよくKINTO専用グレード含めたプリウス全体の流入(見積・申込)は期待通りだったようです。

しばらく推移を見守り落ち着いたところで暫定的に対応していた箇所は元に戻し終了しました。

 さいごに滅多にない大きなイベントだったので大変貴重な経験だったなと思っております。街中でプリウスを見かける度に気になり目で追ってしまうようになってしまいました。KINTOのかな～？って
結果をみるとインフラのスペックは過剰であったようですが事前に正確に流入を予測する事は不可能且つミスするわけにもいかなかったので良かったのだと思います。
年末から年始にかけての忙しい時期にも関わらず様々な方々にご協力いただき無事に乗り越える事が出来たと思っております。
負荷のテストプラン、スケジュールを管理してくださったベンダー会社の方々。

サーバ増強に伴うサービス停止に付き合ってくれた対向システムのメンバー。

インフラ増強に関してはプラットフォームGメンバーにアドバイス助言を頂きました。
この場でもお礼の言葉を残しておきたいと思います。ありがとうございました。