名古屋の市バスGTFS-JPデータ×スガキヤ 最寄りバス停検索をAmazon ElastiCache Serverless for Valkeyで最適化する

0731 JAWS UG 名古屋 × Gov JAWSコラボでの登壇資料です。

Transcript

1. 名古屋の市バスGTFS-JPデータ×スガキヤ 最寄りバス停検索をAmazon ElastiCache Serverless for Valkeyで最適化する JAWS UG 名古屋 × Gov JAWSコラボ usanchu
2. 今回の内容 名古屋の市バスGTFS-JPデータ×現在地からスガキヤの最寄りバス 停の検索 ① 全件検索するコードを実装して検索時間を計測する ② Amazon ElastiCache Serverless for Valkeyを活用してパフ ォーマンスチューニングを行う
3. 発表者について フジイ ヒカリ と申します・x・ 2026 Japan AWS Jr.Champions 社会人2年目：SIerのアーキテクチャチームでSEしてます AWSについて 保有資格：CLF,AIF,SAA,MLA,DEA ★JAWS名古屋、GovJAWSともに対面イベント2回目の参加で す！いつもイベント企画ありがとうございます。 X：@usanchuu
4. 検証の背景：ラーメンが大好き！愛知といえばスガキヤ！ ラーメンが大好き！以前は上越妙 高支部でラーメンLTを実施 今回の会場は名古屋！そして GovJAWSコラボ！ →スガキヤ×公共データでなにか 検証を行いたい
5. 検証内容 「名古屋の市バスGTFS-JPデータ×現在地からスガキヤの最寄りバス 停の検索処理」のパフォーマンスチューニングを行う！ 市バスGTFS-JPデータとは？ 名古屋市オープンデータカタログサイトで公開されている、 バス停座標・時刻表などの静的な運行データ 検証概要 GTFS-JPデータから取得したデータをもとに「位置情報から 最寄りバス停を探す処理」を実装し、Amazon ElastiCache Serverless for Valkeyで高速化する
6. ① 全件検索するコードを実装して検 索時間を計測する
7. ① 全件検索するコードを実装して検索時間を計測する 全件検索するコードを実装 毎リクエストごとに頭から全件ループ ① 最寄りバス停検索 ：stops.txtを全件スキャン3,886件 ② ①をもとに発車時刻検索 ：stop_times.txtを全件スキャン592,164件 1回のリクエストで検索が2段階 ＝N+1問題と同じ構造 店舗 最寄りバス停 距離 栄(ニュー栄ビル) 広小路栄 25.2m 大須(よ志だやビル) 上前津 84.2m 大須(市野ビル) 大須赤門通 42.2m 名古屋エスカ店 名古屋駅（太閤通口） 158.5m
8. ① 全件検索するコードを実装して検索時間を計測する 全件検索時間の計測 最寄りバス停検索：9.9ms／発車時刻検索：733.9ms／合計743.8ms 最寄りバス停検索：キャッシュで62.7ms→9.9ms前後まで短縮 発車時刻検索：毎回700ms台で高止まり →OSのファイルキャッシュが効いても、全件スキャンには限界がある
9. ② Amazon ElastiCache Serverless for Valkeyを活用して パフォーマンスチューニングを行う
10. ② Amazon ElastiCache Serverless for Valkeyを活用してパフォーマンスチューニングを行う Amazon ElastiCache Serverless for Valkeyとは Redis OSS互換のインメモリキーバリューストア。 2026年5月にメジャーアップデート(9.0)実施 https://aws.amazon.com/jp/blogs/news/announcing-valkey-9-0- Valkeyとは？ for-amazon-elasticache/ Linux Foundationが管理するオープンソースのインメモリKVS。 Redis OSSとの完全互換で、既存のRedisクライアントが使える 今回使った機能：GEOSEARCH（地理空間インデックス） 緯度経度をGEO型で扱うことで、最寄り検索がO(log N)で可能に 9.0の新機能：GEOSEARCHにBYPOLYGON(多角形)オプションが追加さ れ、円・矩形だけでなく任意のポリゴン範囲での検索も可能に
11. ② Amazon ElastiCache Serverless for Valkeyを活用してパフォーマンスチューニングを行う 構成図 GTFS CSV（stops.txt / stop_times.txt）は S3を使わず、Lambdaのデプロイパッケージに 直接同梱 実行結果（GEOSEARCH/ZRANGEBYSCORE の処理時間）はCloudWatch Logsで確認
12. ② Amazon ElastiCache Serverless for Valkeyを活用してパフォーマンスチューニングを行う Amazon ElastiCache Serverless for Valkeyでインデックス化 ① GEOADD でバス停の緯度経度を空間インデックス化 → bus_stops キーに全3,886件を登録 ② ZADD で停留所ごとの発車時刻をソート済み集合に → departures:{stop_id} キーに全592,164件を登録 → member文字列に「発車時刻｜trip_id」を仕込み、 HGET不要に ③ 2,000件ごとに pipe.execute() → ElastiCache Serverlessはクラスターモードのた め、 一度に全件をパイプライン送信するとエラーになる
13. ② Amazon ElastiCache Serverless for Valkeyを活用してパフォーマンスチューニングを行う Amazon ElastiCache Serverless for Valkeyでの実測結果 実行回 geosearch zrangebyscore 合計(total_ms) Duration(課金対象) 備考 1回目 272.73ms 1.39ms 274.12ms 276.79ms コールドスタート （Init Duration 632.77ms別途） 2回目 35.56ms 1.32ms 36.88ms 56.77ms ウォームアップ中 3回目 7.13ms 1.13ms 8.27ms 27.19ms ほぼウォーム状態
14. まとめ 全件検索をAWS ElastiCache Serverless for Valkeyでイン デックス化すると、栄のスガキヤまで90倍速くたどりつける！ ★ 743.8ms → 8.27ms（ウォーム時） ★ GEOADD/ZADDで空間・時系列インデックスを作るだけでアプリ側のロ ジックはシンプルなまま ★ Lambda(arm64/Graviton2) × ElastiCache Serverless for Valkeyなら追加のサーバー管理なしでこの速度が出せる