armeria

LINEヤフーのArmeriaを監査した。 line/armeria 【目的】 HTTP/2・gRPCなどを扱う、マイクロサービス向け通信フレームワーク。 【目的適合性】 正常系の実装やテスト体制は充実している。 ところが、通信の中断・例外・競合といった基本的な故障条件に、看過できない欠陥が残っている。 【確認した欠陥】 ・ファイル配信を中断すると、ファイルが閉じられずに残る。公開された再現報告では、100回の中断で81個のファイルディスクリプタが残留。実運用で上限に達し、サーバーが接続を受け付けなくなった事例もある。 ・Spring Boot Actuatorにも、通信中断時にリソース解放が行われない同型のコードが存在する。 ・HTTP/2の正当なCONNECT要求に対し、存在しない":path"を参照してNullPointerExceptionに至る経路がある。 ・"Expect: 100-continue"に対し、認証や受信拒否の判断前に本文送信を許可する。不要なデータ転送を入口で止められない。 ・HTTP/2の競合条件下で、内部エラー応答がストリームの強制終了に化ける不整合がある。 ・Actuatorの処理で例外が起きると、リクエスト引数が警告ログへ出力される。機密情報を含む場合、そのまま記録され得る。 【総評】 率直に言って、通信基盤としてはかなり深刻。 ネットワーク通信において、切断・中断・例外は特殊事象ではない。 日常的に発生する正常な運用条件だ。 そのとき資源が解放されず、接続受付が停止するなら、基本動作が成立していない。 しかも、同型の欠陥が別モジュールにも存在する。 これは単なるバグの数の問題ではない。 故障条件を設計・検査・受入の成立条件として扱えていない、品質保証の問題だ。 OSやJDKを横断するテストを整備していても、肝心の障害時の動作が成立していないなら、そのテスト体制を品質の証拠にはできない。 【改善案】 ・通信の正常終了・中断・例外を通じてリソース解放を保証する。 ・HTTP規格への準拠、先行拒否、競合処理を再検証する。 ・管理APIのログから機密情報を除去する。 ・障害を再現する試験を追加し、修正後の再発防止まで確認する。 【監査結論】 対象機能は工学的に受入不可。 「通常時に動く」は、通信フレームワークの品質保証ではない。 製品の名前でも、企業の規模でも、テストの本数でもない。 異常が発生したときに何が保証されるのか。 そこを成立させられない製品を、信頼性の高い通信基盤とは評価できない。 【根拠】 ファイルディスクリプタ漏出・公開再現報告 armeria#7066 該当コード github.com/line/armeria/blob/71581491c7a7e442e6b2… HTTP/2のCONNECT処理・競合処理 github.com/line/armeria/blob/71581491c7a7e442e6b2… HTTP/2競合の公開報告 armeria#7061 100 Continueの設計問題 armeria#7036 HTTP/1.1の該当コード github.com/line/armeria/blob/71581491c7a7e442e6b2… Actuatorのリソース処理・ログ出力 github.com/line/armeria/blob/71581491c7a7e442e6b2… 【監査基準・範囲】 目的に対する実装の整合性・成立性・再現性。 2026年10月21日のコミット "71581491" を対象とした静的監査と公開不具合報告の照合。 実機での独自再現試験は未実施。公開再現結果とコード上の検出事項は区別して評価。 @lycorp_jp @lycorptech_jp @armeria_project @trustin

armeria がない。。。 line/armeria #serverside_kotlin_meetup