- Site Reliability Engineeringの現在と未来 - システムとの対話を通じて自己学習するSREの未来構想 - クラウドにおける信頼性工学の現在とAI時代に向けた未来構想 - クラウドコンピューティングにおける信頼性工学の現在とAI時代に向けた未来構想 - Site Reliability Engineeringの現在とAI時代に向けた未来構想 - AI時代に向けたクラウドにおける信頼性工学の未来構想 - AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 40分 （30分+@ぐらい） ## 概要 ITサービスの利用者に必要な機能を頻繁に加え続けながらも、いかに必要十分な信頼性を継続させるかが従前より課題となっている。 この課題に対するひとつの回答とも言える、Googleが提唱したITサービスの新しい運用形態であるSite Reliability Engineering（SRE）の普及が進んでいます。 本発表では、SREの中核概念を整理した上で、AI時代に向けて、AIとの対話を軸にした未来の運用のあり方を構想します。 ![[dicomo2022_6a-1.pdf]] ## メモ - 00年代から2022年までのクラウド分野の運用事情の変遷 - SREが大きな転換点 - [[notes/sre/SRE]]は時代区分に応じて2つの導入がある。 1. 運用にソフトウェアエンジニアリングを持ち込む 2. 信頼性を制御対象とみなす（信頼性100%を目指さない） - 信頼性の定義とサービスレベル - SLI・SLO - エラー予算 - 信頼性に基づく運用のあり方の分類 - 厳密な分散システムプロトコルに基づく、故障からの自動回復（フォールトトレランス、フェイルセーフ） - 管理者による宣言に基づく自動制御アプローチ - 観測データに基づく、オペレーターによる手動制御アプローチ - 予防・予測・検知・原因診断・緩和・修復。 - [[Ironies of Automation]] - 自動制御アプローチ2種を検証するために、[[Chaos Engineering]]による実験アプローチが適用されている。 - 宣言型の限界 - happiness わからない エンドユーザーの脳波データがあればいけるかも？プライバシー問題。 - [[BEATLESSにおける信頼性]] 直感の厳密化の難しさ 言語化できない哲学領域 - 対話によって、一方が人間なので、人間のインターフェイスに従わざるをえない。 - [[Interactive AIOps]] - 2.により、実環境でないとわからない問題にアプローチするChaos Engineeringの実行が可能となる。 - [[Known unknowns]] - [[The Morning Paper on Operability]] - 標準指向ソフトウェア VS 個別最適指向ソフトウェア あえて安定状態をしない。準安定状態のままにする。 XRで身体性をもつ可能性がある 感覚に頼る => 例えば、この世の動画のなかで、自分が映っているシーンをすべて集める。 動画のアップロード時に動画に誰が写っているかのラベル付けされていないとしたら、自分が映るシーンが2,3個だとしても、膨大な計算機コストを要する。 みんながそういう機能をほしがれば、事業者が実装する、あるいは、100人ぐらい公募してみんなでお金はらって処理させるとか。 [[現場の計算機のクラウド化]] ## To-Dos - [x] 本日の趣旨の説明を追記 - [x] プロフィールに研究履歴を追加 - [ ] SREピラミッドをいれる (Option) - [x] AIOpsがSREにどう寄与するか - [ ] AIOpsの具体的な流れ マルチモーダルなど - [x] 2030sの構想を、個々人が自由にアプリケーションへのインターフェイスをデザインする時代 - [x] コンセプト文のブラッシュアップ - [x] 図解 - [x] UI、インフラと信頼性の図解 - [x] 社会 VS 個人を図解する - [x] 対話の様子を図解する - [x] 自動プログラミングの調査 - [ ] マルチエージェントシステムとの関連性 (Option) - [x] AIの発展の未来のサーベイ - [x] 2030sまでの道筋の整理 - [x] 4要件のブラッシュアップ - [x] 今後の展望 - [x] AIモデルの信頼性にどう向かっていくのか - [x] 参考文献の書式変更 - [ ] 発表時間を32分ぐらいに収める ## Slideアウトライン 現在の話 -> 未来の話 -> 差を埋めるには？ **ワンセンテンスサマリー** ソフトウェアシステムの信頼性に関するエンジニアリングの現在を整理し、来たるべき未来のAI時代におけるシステムの信頼性へのアプローチを構想する 研究の着想の種として活用していただきたい。一緒にディスカッションしていきたい。 1. クラウドにおける信頼性エンジニアリング（10min） - 信頼性の重要性 - 情報システムにおいて、「信頼性は最も基本的な機能」である - 今月には、CloudflareとKDDIのそれぞれのシステムに大規模な障害が発生した - 障害や性能劣化に遭遇すると、人々は自動化されたシステムに恐れを感じ、どこまで信頼してよいのかわからなくなる。 - 一方で、情報システムの信頼性を維持するために、IT技術者が日々労苦を重ねている。 - 今後、DXが加速する中で、これらの問題に取り組むことは重要である。 - 情報システムの運用技術 - 情報システムにとって、「信頼性」は最も基本的な機能。 - [[2007__FOSE__Software Reliability Engineering - A Roadmap]] - 信頼性工学との関係性 - 信頼性の定義 - [[2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] - ソフトウェアを納品して終わりではなく、オンラインサービスとして、ソフトウェアを常に稼働させながら、開発を継続するという提供方式へ。 - 信頼性に対するアプローチの歴史的変遷 - 故障モデルの変遷 - ソフトウェアの故障は相互依存。ハードウェアは独立。 - [[Handbook of Software Reliability Engineering]] - [[2009__PRDC__Cloud Service Reliability - Modeling and Analysis]] - [[2013__JCSS__A Survey on Reliability in Distributed Systems]] - [[2006__Reliability Engineering and System Safety__Highlights from the Early (and pre-) History of Reliability Engineering]] - ライフサイクルの変遷 - 開発し続けるためにリスクを受容する - [[notes/sre/SRE]]は時代区分に応じて2つの導入がある。 1. 運用にソフトウェアエンジニアリングを持ち込む - 2004年以降フェーズ１：運用をソフトウェアエンジニアリングで再定義する 2. 信頼性を制御対象とみなす（信頼性100%を目指さない） - 2014年以降フェーズ２：信頼性を制御する - SREでは、システムの利用者からみたときの信頼性のレベルを定義する。 - ソフトウェア信頼性工学でも同様。 - 信頼性に対するアプローチの階層 ([[Onion model]]) - 分散システムプロトコルに基づくフォールトトレランス、フェイルセーフ - ソフトウェアのコンポーネント同士のプロトコル - システムリソースのあるべき内的状態の、管理者による宣言に基づく自動制御アプローチ [[Kubernetes]] - 管理者 -> ソフトウェアシステムへの宣言 - 観測データに基づく、オペレーターによる手動制御アプローチ - 予防・予測・検知・原因診断・緩和・修復。 - システムの利用者からみたソフトウェアシステムのサービスレベル - SREへ現在のAI技術を適用 -> [[AIOps]] - Failure Management - 現在の到達点 - SREの完全な信頼性を目指さないポリシーと、AIがもつ可謬性。 - 1章まとめ - ハードウェアからソフトウェア、クラウドへとシステムの提供形態の変遷にあわせて、信頼性へのアプローチも変遷している。 - SREには、ソフトウェアエンジニアリングによるオペレーションを自動化することと、信頼性を制御することの、2つの側面がある。 - 信頼性の制御アプローチには、3階層ある。 - 最も外側の手動制御アプローチが、AIによる自動化が研究されている。 - SREへのAIOps適用の、現在の到達点は、〇〇である。 2. AI時代における信頼性エンジニアリングのあり方（10min） - 未来構想の考え方 - 30年後に「こうなったらいいな」という「願望」から始める - 願望によって描いた未来像から逆算して現在からの道筋を考える（バックキャスティング） - 情報システムの信頼性は、信頼性を要求するシステムのあり方から考える必要がある - 前提とする技術 - AR、VR、MR、SRなどのXRの普及 - 人間に対する直接的な身体的拡張はなされていない（攻殻機動隊における電脳化など） - 2040s：万人が自分に最適化された支援ソフトウェアを開発することが当たり前になる時代。人類総ソフトウェア開発・運用時代。 - 予測ではなく願望。 - 情報端末を全員もつ時代はきた。 - 現代は、インターフェイスは制約が大きい。利用者が最低限利用可能なレベルを目指す。 - 標準指向ソフトウェア => 個別最適指向ソフトウェア - SF小説などでは、AIがつくった世界に人間があわせる。 - 自動化を進めるほどに、逆説的に創造的になる。 - 開発とはいっても、専門的な実装を行うわけではなく、インターフェイスや要件を設っｊ計する。 - 設計にあわせて、AIが実装したり、推薦する。 - 利用者は専門的な実装を行うわけではなく、AIと対話しながら、自分がほしいものをつくっていく。 - 想定するAIのレベル - 現在のデータ駆動型のAIの延長線上にあるAI - AGI（汎用人工知能）ではなく、特化型人工知能が普及している - 個人の利益 VS 社会の安定 - エネルギー資源は有限である - [[パレート最適点]] - [[2019__HotOS__Nines are Not Enough Meaningful Metrics for Clouds]] でのSLO定義の難しさを顧客がSLOを決めることで解決できるかも。 - AIによる全自動型の開発と運用方式 - 信頼性 VS 低コスト VS 変更速度 - データ駆動AIを前提とするなら、変更することで、信頼性は低下する可能性はある。 - セキュリティの問題で、AI自体が修正され続ける。 - 人間が宣言的に決定することの限界 - [[BEATLESSにおける信頼性]] - [[HAL 9000]] - [[フレーム問題]] - 人間の外界とのインターフェイスはかわらない - 視覚（テキスト、動画、画像）、聴覚（音声）、触覚 - AIが人間を理解することもそれなりに手間を要するため、対話を前提としたアプローチが必要 - Privacy data vs common data - 対話：Input -> Output -> Input -> Output -> ... 着地点（解へ収束） - AIとの対話は新しくはない - Siri, Alexa, Google Assistantなど限定的にできている - アプリケーションではなくとも、AIと対話しながらものをつくるシーンもよくある - 信頼性という基本的な機能の要件を対話的に決定する、というのはみたことがない - 信頼性を個別に決めるべきと考え、アプリ開発もdevopsで個人が行うべきというべき論から着想した。 - 2章まとめ - 2050年：標準指向ソフトウェアから個別最適化指向ソフトウェアの時代という願望 - 計算機が有限の資源に依存する以上は、個人が信頼性、コスト、変更速度の均衡点を調整する必要がある。 - そのためには、対話的アプローチで、解を収束させ、状況変化に応じてあらためて繰り返す 3. 「対話」を軸とした信頼性エンジニアリングのあり方 (10min) - 2040sから現在の道筋へ （タイムライン） - 最終未来(2040s) 利用者が対話・体験的にアプリの信頼性目標を決定 - 利用者や専門家と協働で、エンドツーエンドで要求に応じて最適なプログラムとプロトコルを動的かつ適応的に変化させていく。（AIにしかシステム内部がわからない状態。専門家がシステムの状態を要約して理解はできる） - 自由にアプリを組む - 未来２(2030s中頃) AIによる障害の自律的対応 - 自動プログラミングの発展。専門家により設計された情報システムのアーキテクチャのフレームの範囲で、AIがモジュールを実装したり、モジュール同士を連結させる。 - 専門家の仕事はAIの高信頼化にシフト - 専門家はAIにエンドユーザーを標準化した信頼性目標を対話的に決定 - 未来１(2020s後半) 専門家がAIと協働可能となる - 信頼性：専門事業者が信頼性目標を決定。 - AIと対話的に障害対応 - AIOpsの有用性が理解されはじめ、データのオープン化が整備されていく - 現在 - 信頼性：専門事業者が信頼性目標を決定。障害対応は、AIによる補助的な情報支援まで。 - アプリ開発：AIによるプログラムコード補完 - AIOps分野では、大域的な学習ができるかどうか。 - 現在のAIOpsでは、特定のシステム内の特徴量を入力として、個別に学習モデルを構築する - 例 - システムXのコンポーネントCX、メトリックCMXに紐づく単変量時系列S - システムXのコンポーネントCXに紐づく多変量時系列CXMS - システムX全体に紐づく多変量時系列MXS - 異種混合の多数のシステムのデータから巨大な学習モデルを構築すれば、自然言語処理や画像処理分野のような顕著な成果が得られるはず - しかし、サービス事業者は、プライバシーの理由で、運用データの公開に積極的ではない - まずは、専門家（エンジニア）が対話可能なレベルまで技術レベルを引き上げる。AIと実験する。 - 現状の課題 - 大量のデータセットを入手することが難しい - 専門家による要約データ（障害分析レポート）も、検出や調査過程に関する情報が含まれないことが多い - [[2020__ICSME__Failures and Fixes - A Study of Software System Incident Response]] - 異種混合のシステムの振る舞いに関する一般法則を発見しづらい - Interactive AIOps - (1) 実験可能性 (Experimentability) - [[Chaos Engineering]]のコンセプトの拡張 - システム開発者・運用者が，故障注入実験 [2] により，情報システムの異常を AI に伝達可能とする - 異常を意図的に発生させ情報量を増やす - 異常・影響範囲・原因・回復方法などを教える - (2) 説明性 (Explainability) - 統計解析 - [[XAI|XAI]] - AI が開発・運用者に予測結果を返すときに，なぜそのように予測したのかを説明可能とする - AIモデルが今どのような状態にあるかを説明可能とする - (3) システム間学習性 (Inter-system Learnability) - [[転移学習]] - あるシステムの学習結果を別のシステムへ転移可能とする - (4) 訓練可能性 (Trainability) - オペレーターが訓練を積む - AIが提示する障害パターンに対して，開発・運用者が障害対応訓練を実施可能とする - [[Active Learning]]によりラベル付けさせる。 - 実タスクを実行する例 - 原因診断 - 10~20年後の技術者の仕事 - AIと対話的にオペレーション - AIの性能低下を監視する - AIが解決しきれないインシデントの対応 - AIが壊れたときにどうするか。 - [[Ironies of Automation]] - 独立した複数のシステムによる相互監視機構 - モデルのバックアップから復旧する - 3章まとめ - まずは、技術者がAIと対話する「Interactive AIOps」を実現する - 基本の対話系は、実験可能性（AIに教える） + 説明性（AIから説明） - 外挿性の獲得のために、システム間学習性（他から学ぶ）が必要となる - クリティカルな工程のために、オペレーターの訓練可能性が必要となる 4. おわりに (2min) - 本講演の主要な論点 - クラウドでは、システムの信頼性を制御対象としてみる - 手動制御部分の自動化のためにAIを適用する研究が活発化 - 2050年の願望：万人が自分に最適化された支援アプリケーションを開発することが当たり前になる時代 - 個人がAIとの対話的アプローチを以って、信頼性とその他の変量の均衡点へ収束させる。 - 今後の検討事項 - AIをどこまで信じられるのか - 今後の取り組み - AIOpsのためのコミュニティの醸成 AIをそのものを信頼できるのか？ ## 参考文献 - [[信頼性]] - [[エンジニアのための信頼性工学]] - [[Practical Reliability Engineering]] - [[信頼性工学 電氣學會雜誌 - 1970]] - [[AGREEレポート]] - [[高速マルチメディア通信ネットワーク]] - [[The VOID Report 2021]] - [[SRE Workbook 障害トリガーと根本原因]] - [[LeanとDevOpsの科学 - ソフトウェアのデリバリーのパフォーマンス]] - [[Effective DevOps]] - [[ソフトウェア開発の歴史]] - [[10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]] - [[Verification VS Validation]] - [[Reliability-Driven AIOps for Cloud Resilience - ICSE21 Keynote]] - [[2022__arXiv__GitHub Copilot AI pair programmer - Asset or Liability?]] - [[人工知能は人間を超えるか ディープラーニングの先にあるもの]] - [[ディープラーニングの先の研究]] - [[知能の2階建てアーキテクチャ]] - [[深層学習と人工知能]] - [[相対化する知性---人工知能が世界の見方をどう変えるのか]] - [[未来の知能とバイアス - JSAI2022基調講演]] - 論文 - [[Handbook of Software Reliability Engineering]] - [[Software Reliability Engineering|ソフトウェア信頼性工学]]の1990sの書籍 - [[2007__FOSE__Software Reliability Engineering - A Roadmap]] - ソフトウェア信頼性工学を整理した論文 - [[2019__arXiv__The First 50 Years of Software Reliability Engineering - A History of SRE with First Person Accounts]] - 2060年代の黎明期から５０年のソフトウェア信頼性工学の歴史をまとめた論文。 - [[2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] - [[ディペンダビリティ]]とセキュリティの定義の論文 - [[2006__Reliability Engineering and System Safety__Highlights from the Early (and pre-) History of Reliability Engineering]] - [[信頼性工学]]の歴史 - [[信頼性という言葉の初出]] - 1970sぐらいのソフトウェアの時代の信頼性の考え方まで - [[2013__JCSS__A Survey on Reliability in Distributed Systems]] - 分散システムの信頼性に関するサーベイ論文 - [[2009__PRDC__Cloud Service Reliability - Modeling and Analysis]] - クラウドシステムのモデル化を試みている - [[2003__USENIX Symposium__Why do Internet services fail, and what can be done about it?]] - 今で言うクラウドの障害データに関するまとまった論文。めちゃ長い。 - [[2020__ICSME__Failures and Fixes - A Study of Software System Incident Response]] - いろんなポストモーテムの分析 - [[2021__TIST__A Survey of AIOps Methods for Failure Management]] - [[AIOps]]のサーベイ論文 - [[2022__arXiv__Machine Learning Operations (MLOps) - Overview, Definition, and Architecture]] - [[MLOps]]のサーベイ論文。 - [[The Origins of DevOps - What’s in a Name?]] - [[Learned Index]] - 学習型データ構造の例 - [[2022__EuroSys__Multi-Objective Congestion Control]] - 学習型プロトコルの例 - [[2020__Inf Fusion__Explainable Artificial Intelligence (XAI) - Concepts, Taxonomies, Opportunities and Challenges toward Responsible AI]] - 解釈性のサーベイ論文 - [[2018__ACCESS__Peeking Inside the Black-Box - A Survey on Explainable Artificial Intelligence (XAI)]] - 解釈性のサーベイ論文