Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
NilAway による静的解析で「10 億ドル」を節約する #kyotogo / Kyoto ...
Search
y_taka_23
December 14, 2024
Technology
4
610
NilAway による静的解析で「10 億ドル」を節約する #kyotogo / Kyoto Go 56th
Kyoto.go #56 オフライン忘年 LT 会で使用したスライドです。
y_taka_23
December 14, 2024
Tweet
Share
More Decks by y_taka_23
See All by y_taka_23
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.4k
形式手法の 10 メートル手前 #kernelvm / Kernel VM Study Hokuriku Part 7
ytaka23
6
1.2k
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
9
2.6k
kcp: Kubernetes APIs Are All You Need #techfeed_live / TechFeed Experts Night 28th
ytaka23
1
390
サーバーレスアーキテクチャの数理的理解と分析 #devsumi / Developers Summit 2023 Summer
ytaka23
9
5.2k
形式手法による分散システムの検証 〜S3 の一貫性モデルを例として〜 #ourdevday2023 / Our DevDay 2023
ytaka23
2
1.4k
Amazon S3 の一貫性モデル超入門 #ハードル激低LT大会 / Low-hurdle LT Meetup 2nd
ytaka23
3
2.2k
謎は全て解けた!安楽椅子探偵に捧げる AWS ネットワーク分析入門 #CNDT2022 / CloudNative Days Tokyo 2022
ytaka23
2
4k
サーバーレスは操作的意味論の夢を見るか? #AWSDevDay / AWS Dev Day 2022 Japan
ytaka23
4
6.9k
Other Decks in Technology
See All in Technology
ウェブアクセシビリティとは
lycorptech_jp
PRO
0
140
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
1.9k
ソフトウェア開発現代史: なぜ日本のソフトウェア開発は「滝」なのか?製造業の成功体験とのギャップ #jassttokyo
takabow
2
780
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
130
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
0
110
パスキー導入の課題と ベストプラクティス、今後の展望
ritou
7
1k
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
480
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
290
PHPでアクターモデルを活用したSagaパターンの実践法 / php-saga-pattern-with-actor-model
ytake
0
920
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
1.7k
ルートユーザーの活用と管理を徹底的に深掘る
yuobayashi
6
670
Dapr For Java Developers SouJava 25
salaboy
1
120
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Six Lessons from altMBA
skipperchong
27
3.7k
Unsuck your backbone
ammeep
669
57k
It's Worth the Effort
3n
184
28k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Git: the NoSQL Database
bkeepers
PRO
429
65k
Become a Pro
speakerdeck
PRO
26
5.2k
Making Projects Easy
brettharned
116
6.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Transcript
#kyotogo NilAway による静的解析で 「10 億ドル」を節約する チェシャ猫 (@y_taka_23) Kyoto.go #56 オフライン忘年
LT 大会 (15th Dec. 2024)
#kyotogo 第 1 問(初級)
#kyotogo 何が起こる? 1. 改行のみ出力して正常終了 2. 何も出力せず正常終了 3. panic になる
#kyotogo 何が起こる? 1. 改行のみ出力して正常終了 2. 何も出力せず正常終了 3. panic になる【正解】
#kyotogo 第 2 問(中級)
#kyotogo 何が起こる? 1. 改行のみ出力して正常終了 2. 何も出力せず正常終了 3. panic になる
#kyotogo 何が起こる? 1. 改行のみ出力して正常終了 2. 何も出力せず正常終了 3. panic になる【正解】
#kyotogo 第 3 問(上級)
#kyotogo あなたは nil 判定をどうやって解いた?
#kyotogo 無効な参照によるエラー • 10 億ドルの過ち(The Billion Dollar Mistake) ◦ null
を「発明」した Hoare による 2009 年の後悔の言 ◦ Dijkstra 「独身者が全員一人の null と重婚した状態」 • nil 参照は実行時エラーとしてはかなり厄介 ◦ あらゆる型に対し nil チェックが必要になってしまう ◦ 原因と結果がコード的にも時間的にも遠く離れがち 参考:https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
#kyotogo 実行前に静的に nil 参照を検出したい
#kyotogo NilAway by Uber https://github.com/uber-go/nilaway
#kyotogo NilAway の特徴 • ソースコードから静的に nil エラーを発見 ◦ 関数やパッケージを跨いだエラーが検知可能 ◦
nil になり得る具体的な原因をメッセージとして表示 • go/analysis パッケージを使用 ◦ 内部は複数の Analyzer でモジュール化され並列動作 ◦ golangci-lint や bazel+nogo などのツールから呼び出し可能 参考:静的解析のモジュール化(https://zenn.dev/tenntenn/books/d168faebb1a739/viewer/9d590e)
#kyotogo NilAway による検査結果 • ソースコードの nil flow を解析 ◦ foo()
が nil リテラルを返却(10 行目) ◦ foo() を参照(6 行目)
#kyotogo nil flow による因果推論 • nil の発生と参照の因果関係を辺としたグラフを構築 ◦ 発生:nil リテラル、var
宣言、関数の引数など ◦ 参照:デリファレンス、フィールドアクセスなど • 各ノードに対して「nil であり得るか」をマーク ◦ 発生側を true、参照側を false として伝播・確定させていく ◦ true かつ false の矛盾したノードが現れたら nil エラー
#kyotogo *foo(x, bar()) bar() foo の x foo の y
foo(x, y) main の x bar の nil リテラル var 宣言 引数 return 引数 デリファレンス return if x == nil
#kyotogo *foo(x, bar()) bar() foo の x foo の y
foo(x, y) main の x bar の nil リテラル var 宣言 引数 return 引数 デリファレンス return if x == nil 赤は nil 確定 緑は nil 不可能 黒は矛盾
#kyotogo *foo(x, bar()) bar() foo の x foo の y
foo(x, y) main の x bar の nil リテラル var 宣言 引数 return 引数 デリファレンス return if x == nil 赤は nil 確定 緑は nil 不可能 黒は両方(矛盾)
#kyotogo というかそれは自明では?
#kyotogo 冒頭の第 3 問への回答 • ちゃんとした形式化の複雑さ ◦ 人間も基本的には因果関係を辿って nil を発見
◦ 意外なトリックがあるという感じではない ◦ しかしアルゴリズムに落とし込むとなると割と複雑 • 計算機科学の裏付けによるスケール可能性 ◦ 因果グラフ推論は 2-SAT 問題とみなせ、線形時間で判定可能
#kyotogo まとめ • nil 参照は厄介なタイプの実行時エラー ◦ 考案者 Hoare 自身も後に「10 億ドルの過ち」と認める
• NilAway により静的に解析が可能 ◦ nil の可能性を制約としてグラフ上で伝播させ矛盾を検出 • 人間が頭の中で行う「普通にわかる」の形式化 ◦ 意外と複雑な処理だが、厳密に記述できればスケール可能
#kyotogo Save the Billion Dollars by NilAway! Presented by チェシャ猫
(@y_taka_23)