class: title, smokescreen, shelf, no-footer # 運用もしくはSRE<br>ネットワークの計測,評価,再設計 <div class=footnote> <small> </small> </div> --- name: digest-begin name: quic class: compact # ネットワークの計測,評価,再設計【ガチの運用部】 <div class=footnote> <small> (脚注1) もう少し詳しい解説は <A HREF="/slides/columns/proj/netops/">[こちら]</A> を参照 (脚注2) Stack Overflow 調べ: (経営/管理者層以外で)ギャラが一番高いのはSREエンジニア。 一通り全部わからないとSREなんて出来ないし貴重品なのは世界中同じなのでしょう </small> </div> - QUICがネットワーク運用に与えるインパクトの評価,運用改善の提案 - **HTTP/3**の中核技術**QUIC**(RFC9000)は**443/udp上にTCP似の信頼性のある通信を実現** - 個人はともかく**法人ネットワークはQUIC対応するべき?** という**疑問**の探求please <br> **QUICの利点 > 対応コスト**(機材や回線のupgrade)?をきちんと評価してください - 疑問: (a)そもそも、どれくらい速くなるの? (b)UDPは閉じていいのか判断できないのでNATテーブルがあふれないのか? (c)単純計算でUDPはTCPのパケット数3倍 -> OSの負荷が増大 (d)そしてOSのUDPコードは最適化されているのか? 今まではDNSくらいなのでUDPの処理速度とか関係なかったけど... - **最近「〜をQUICベースへ置き換える」という提案がIETFへ次々と出てきています** <br> 提案する人はノンキなものですが、現場としては、それ大丈夫か?と - (長期的には)大学全体のデータを元にしたネットワークの評価,運用改善の提案 - **SRE = Site Reliability Engineering** (**サイト信頼性工学** <- Google発edgeの効いた用語) --- name: digest-end name: sre class: title, smokescreen, shelf, no-footer # もう少し詳しい解説 --- class: compact # 背景: まずはネットワークの計測を出来るようにする <div class=footnote> <small> (脚注) Google本来のSREは数百万台のPCといったスケールの話で、 ほとんどの企業では、なんちゃってSREでしょう。 それでもSRE的な観点でnetworkを計測し,改善する修行はcareer pathとして有意義だと考えています </small> </div> - インターネットの技術が次々と変化していくので、 ネットワークの設計、運用基準なども、それに合わせて変更していかなければなりません - 変更の際には根拠となるデータ(今風に言えばevidence)がないといけません。 データを取るにはネットワークの計測が必要ですが今できてない;-) 構築しないといけません - **KPI** (ネットワーク運用に対する評価) ... そもそもKPIがはっきりしていないので**KPIを作成、測定**。 そうしないと改善点を提案できない - KPIのために、**学内ログの分析基盤を確立**する。 要素技術とコンテナベースでの構築法については去年のICT-SOLの際に調べました。 まとめは[こちら](https://exercises-aws.fml.org/ja/appendix/logaggr/) - 一般には**SRE (Site Reliability Engineering)**と呼ばれる分野 <br> (あまり訳してないと思うけど、無理やり訳せば「**サイト信頼性工学**」) --- class: compact # ネットワーク運用部のお仕事: 計測,評価,再設計 - [まとめページ](#quic)で紹介したQUIC評価案件は 「大学のfirewallの設定かえようと思うんだけど、やっても大丈夫かな? きちんとデータを取って考えないといけないんだけど(やってる暇がないよ)」 ... を卒論でやってもらってます:-) (本来、情報センター案件かな?) - 就職して運用部隊に配属されたら、こういう仕事をすると思うんよ。 - **実務感は全開** --- class: compact # ネットワークの計測と言えば機械学習とコンビですか? <div class=footnote> <small> (脚注) いずれにせよ、ログの分析基盤を確立しないと、この話へ進めませんので、 数年かかりの案件です </small> </div> - ちなみに、**異常(anomaly)検知なら昔からできてます**、 - これは**機械学習ではなくエキスパートシステムくらいで十分ok** - [異常検知と対応例]: 突然トラフィックが激増した -> DoSくらってる? -> (ISPの出口の)ルータにフィルタかける (たぶん手動,危ないから人間が立ち会うべき) - データが蓄積されたら分析してみてもいいのかも? - ただ、うまく学習できるほどの大量のデータではないみたいです - そして、 正しい運用をしているので、 教師データがありません <br> -> 学習するべきイベント(事件)が起こらないんですけど:-) - ものすご〜くフワッとした案件ならありますけどもね、できるか？こんなの...? <br> たくさんの振る舞いを見て「あやしげだ！」なら教えてほしいね --- name: updates class: title, smokescreen, shelf, no-footer # <small>updates</small> <div class=footnote> <small> (脚注) このあとは動画になっていません。 おもに4年生用のメモです。 </small> </div> --- class: compact # 雑誌記事のたぐい - [技術評論社 HTTP/3入門 記事一覧](https://gihyo.jp/list/group/HTTP-3%E5%85%A5%E9%96%80#rt:/admin/serial/01/http3/0001) --- class: compact # 文献調査(1): 2022/09 - 通信環境とCPU性能を考慮したHTTP/3の通信性能に関する一考察 - 信学技報, vol. 122, no. 170, NS2022-74, pp. 76-81, 2022年9月. - https://ken.ieice.org/ken/paper/20220902lCmd/ - これは近いの?近いの? -> 取り寄せ中