“正常”なのに“困る”、その謎をInstanaと一緒に解いた日 〜システムは「大丈夫」って言ってるのに...ユーザーは困ってる。なんで？〜

Transcript

1. AI時代に向けた若手技術者の挑戦 2 “正常” なのに “困る”、その謎をInstanaと一緒に解いた日 〜システムは「大丈夫」って言ってるのに...ユーザーは困ってる。なんで？〜 2025年11月18日 @中日ビル6F CONFERENCE FLOOR ※IBM Championの縁が紡いだPoC実録 (IBM Instana® x AWS Private Link 閉域接続の実証) 株式会社システムリサーチ 日本アイ・ビー・エム株式会社
2. © 2025 IBM Corporation 2 IBM Instana® とは？ システムの「処理の流れ」を追跡し ユーザー体験からインフラまで 「見える化」するツール → 今回のPoC検証対象 自己紹介とIBM Instana®について 登壇者紹介 鈴木 日出夫 システムリサーチ • プロジェクト統括責任者 • インフラからアプリまで 幅広く担当 桑原 武志 システムリサーチ • アプリケーション開発担当 平岡 大祐 日本IBM • IBM Instana® 製品担当 • IBM Champions 担当 登壇者紹介・製品概要・前提知識（今日の話の3本柱） 今日の話の前提知識 Webの「信号機」 = HTTPステータスコード 200番台: 成功（OK） 300番台: リダイレクト(別の場所へ) 500番台: エラー（故障） 今日の問題 エラー( 500 )が リダイレクト( 302 )に化けた ↓ IBM Instana®は「正常」と判断 今日のキーワード 「Wrong is the new down」 = システムは動いているが、 結果が間違っている新しい問 題
3. © 2025 IBM Corporation 3 Amazon RDS for PostgreSQL障害試験で起きた不思議な現象 AWS Private Link 閉域接続での Fargate-RDS障害検知を Instana® SaaSで検証 プロジェクト統括者（鈴木さん） ブラウザ画面 : 500 Internal Server Error (障害試験で意図的に発生)
4. © 2025 IBM Corporation 4 Amazon RDS for PostgreSQL障害試験で起きた不思議な現象 AWS Private Link 閉域接続での Fargate-RDS障害検知を Instana® SaaSで検証 プロジェクト統括者（鈴木さん） アプリケーションの詳細は分からないが この矛盾は明らかにおかしい 直感: 「 500エラーが出ているのに なぜ Instana® はエラーが出ない？ 」 ブラウザ画面 : 500 Internal Server Error (障害試験で意図的に発生) Instana®ダッシュボード: 緑・青「正常判定」 エラー出力なし 緑・青のみ出力(正常)
5. © 2025 IBM Corporation 5 Amazon RDS for PostgreSQL障害試験で起きた不思議な現象 AWS Private Link 閉域接続での Fargate-RDS障害検知を Instana® SaaSで検証 # 正常時の設定 DB_URL = “・・・:5432/demo_app" # 障害試験の設定（間違ったデータベース名を設定） DB_URL = “・・・:5432/wrong_demo_app" アプリケーション開発者（桑原さん） PostgreSQL接続先URLに 意図的タイプミス実施 (障害検証試験のシナリオ） • まず確認:ブラウザに500エラー画面 「よし、障害再現できた！」
6. © 2025 IBM Corporation 6 アプリケーション開発者（桑原さん） PostgreSQL接続先URLに 意図的タイプミス実施 (障害検証試験のシナリオ） • まず確認:ブラウザに500エラー画面 「よし、障害再現できた！」 • 次にInstana確認: 緑色 のまま、正常判定 「え？検知できてない？」 「でも、ログはError出力してる」 疑問: 「 500エラーを起こしたのに、なぜ緑？ 何か見落としがあるかもしれない 」 Amazon RDS for PostgreSQL障害試験で起きた不思議な現象 AWS Private Link 閉域接続での Fargate-RDS障害検知を Instana® SaaSで検証 緑のみ出力(正常) ログはError出力
7. © 2025 IBM Corporation 7 Instana®ダッシュボード(次に確認) 緑色「正常判定」 矛盾の可視化【 Step 1 】 「Wrong is the new Down」現象の3つ比較 ブラウザ画面（最初に確認） 500 エラー画面 (想定通り) 原因の位置 アプリ←→DB接続層でエラー 本番なら、ユーザーは 確実に困っている状況 Instanaは正常と判定 ログではデータベース名の 誤りを検知
8. © 2025 IBM Corporation 8 新しい課題 : Wrong (誤動作) を見逃す Wrong is the new Downとは? この３つの矛盾が「Wrong is the new Down」の完璧な実例 従来の監視 : Down (停止) だけを検知 本番で起きたら : • ユーザーは困っている • でも監視は「 正常 」 • 障害に気づけない システムは動いているが 結果が間違ってる状態 ( =実質ダウン ）
9. © 2025 IBM Corporation 9 Instana® ダッシュボード (詳細分析) 「正常」なのに「エラーログ」の矛盾 なぜアラートが発火しない？ タイムライン: 緑色 正常判定: 「 全て正常 」 HTTPステータス: 302 ERROR: データベース接続で エラーが発生しました ↓ 矛盾 ↓ 結果 : → 302(正常)が優先される → ログのERRORは検出されても、アラート条件にならない ※注: 設定によって可能 Instana ®の判断基準 : • 主 : HTTPステータスコード • 副 : ログ(参考情報) タイムライン 302 (リダイレクト） HTTPステータスコード
10. © 2025 IBM Corporation 10 原因特定【 Step 2 】 Instana ®とコードレビューで特定 現在の処理 改善提案 1 エラー発生 2 except OperationalError: return HttpResponseRedirect(宛先) # → HTTP 302が返される 3 HTTPステータス : 302 (リダイレクト) 1 エラー発生 2 except OperationalError as e: logger.error(f"Error: {e}") return render(..., status=500) # → HTTP 500が返される 3 HTTPステータス : 500 (エラー) ↓ ↓ ↓ ↓ 問題 : 監視は「正常」と判断 効果 : 500で監視が正しく検知 確認結果 • ◯ 本来 : HTTP 500 ( エラー )を返すべき • × 実際 : HTTP 302 (正常 :リダイレクト )を返していた →次のステップ : 桑原さんに改善提案へ
11. © 2025 IBM Corporation 11 改善提案【 Step 3 】 平岡 → 桑原さんへ 平 平岡の改善提案 : 桑原さん 原因が分かりました。 いまの実装だと エラー発生時に 302(リダイレクト）を返してしまっています。 本来は500を返すべきところです。 ここ、適切なHTTP 500エラーレスポンスを返すように 修正していただけますか？ 桑 桑原さんの反応 : 分かりました。すぐに修正します。 → 数行の修正で完了 1〜２日後
12. © 2025 IBM Corporation 12 解決実証 【 Step 4 】 適切なHTTP 500エラーレスポンスへの修正後、再テストを実施 検証結果 • Instana ®が HTTPステータスコード :500 サーバーエラーを正しく検知 • 迅速に原因特定が可能 タイムライン HTTPステータス コード 500 出力 マークでエラー発生を表現 エラー出力
13. © 2025 IBM Corporation 13 システムリサーチ × 日本IBM 共創の成果 IBM Championのご縁から生まれた価値 きっかけ IBM Champion合宿での出会い → AWS Private Link 閉域接続の Instana® PoC成功 発見と解決 「 Wrong is the new Down」を実証 → 迅速な原因特定で早期解決を実現 PoCで品質改善ポイントを早期発見 お裾分け この知見を皆様へ → システムリサーチ と 日本IBMで共同でサポート PoCから本格導入まで全面支援 Instana ®は、システム動作とユーザー体験の差分を可視化し、実運用の真実を捉える可観測性を提供します
14. © 2025 IBM Corporation 14 システム監視の進化 - HTTPステータスから AI応答品質へ Wrong is the new Down 1.0 → 2.0 今回の実証 • システムの「正常」≠ ユーザーの「困った」 • HTTPステータスレベルの矛盾を解決 • 迅速な原因特定による品質向上 次の挑戦（すでに取り組み中） 今回: HTTPステータスレベルの矛盾 → 次回: 「通信は成功したのに、AIの答えが間違っている」 例: 「東京の観光地を教えて」 → AIが「大阪の観光地」を自信満々に解説 → AIの入出力記録による意味レベルでの品質検証 ※2025年12月3日 IBM TechXchange Summit Japan 2025でAI時代版を紹介 16:00-16:40 [G407-5] 生成AIアプリの本番化を加速するIBM Automation最新活用
15. © 2025 IBM Corporation 15 Thank you ワークショップ、セッション、および資料は、IBMま たはセッション発表者によって準備され、それぞれ独 自の見解を反映したものです。それらは情報提供の目 的のみで提供されており、いかなる参加者に対しても 法律的またはその他の指導や助言を意図したものでは なく、またIBM製品やサービスがお客様に適用ある特 定の法令に適合することを保証するものでもありませ ん。本講演資料に含まれている情報については、完全 性と正確性を期するよう努めておりますが、「現状の まま」提供され、明示または黙示にかかわらず、商業 性、特定の目的への適合性、非侵害性を含め、いかな る保証も伴わないものとします。本講演資料またはそ の他の資料の使用によって、あるいはその他の関連に よって、いかなる損害が生じた場合も、IBMは責任を 負わないものとします。 本講演資料で言及されるIBM 製品、プログラム、またはサービスは、IBMがビジネ スを行っているすべての国・地域でご提供可能なわけ ではありません。 本講演資料で言及される将来の展望(製品リリース日付 や製品機能を含む)は、市場機会またはその他の要因に 基づいてIBM独自の決定権をもっていつでも変更でき るものとし、将来の製品または機能が使用可能になる こと、もしくは特定の結果を確約することを意図する ものではありません。本講演資料は、言及される IBM 製品またはサービスに適用ある契約条件を変更するも のでも、追加の表明または保証を意図するものでもあ りません。 本講演資料に含まれている内容は、参加者の活動に よって特定の結果が生じると述べる、または暗示する ことを意図したものでも、またそのような結果を生む ものでもありません。 パフォーマンスは、管理された 環境において標準的なIBMベンチマークを使用した測 定と予測に基づいています。ユーザーが経験する実際 のスループットやパフォーマンスは、ユーザーのジョ ブ・ストリームにおけるマルチプログラミングの量、 入出力構成、ストレージ構成、および処理されるワー クロードなどの考慮事項を含む、数多くの要因に応じ て変化します。したがって、個々のユーザーがここで 述べられているものと同様の結果を得られると確約す るものではありません。記述されているすべてのお客 様事例は、それらのお客様がどのようにIBM製品を使 用したか、またそれらのお客様が達成した結果の実例 として示されたものです。実際の環境コストおよびパ フォーマンス特性は、お客様ごとに異なる場合があり ます。 IBM、IBM ロゴ、 IBM Instana、 Instanaは、世界の 多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名および サービス名等は、それぞれIBMまたは各社の商標であ る場合があります。現時点での IBM の商標リストにつ いては、www.ibm.com/legal/copytrade.shtmlをご覧 ください。 Amazon Web Services、AWS、AWS Private Link、 Amazon RDS、AWS Fargateは、 Amazon.com, Inc.ま たはその関連会社の米国およびその他の国における商 標です。 PostgreSQLは、PostgreSQL Community Association of Canadaの商標です。 Djangoは、Django Software Foundationの商標です。 本講演資料に記載されているシステムリサーチは、株 式会社システムリサーチを指します。 システムリサー チは、本講演資料の作成および発表に協力しています。