分散アプリケーションの信頼性観測技術に関する研究 / A study of SRE

SRE NEXT 2020 IN TOKYO https://sre-next.dev/

Transcript

1. 分散アプリケーションの信頼性観測技術 に関する研究 Yuuki Tsubouchi / @yuuk1t SRE NEXT IN TOKYO 2020 基調講演 2020.01.25
2. 2 ⾃⼰紹介 Yuuki Tsubouchi / ゆううき https://yuuk.io/ ܦྺ 株式会社はてな Webオペレーションエンジニア・SRE さくらインターネット株式会社 さくらインターネット研究所 研究員 Webサービスの 開発・運⽤ インターネット 基盤技術研究 5年 現在 Site Reliability Engineering(SRE) Researcher @yuuk1t 情報処理学会 インターネットと運⽤技術研究会 運営委員 セキュリティ・キャンプ全国⼤会講師 id:y_uuki
3. 3 講演の⽬的 ・SREをテーマとした研究開発を通じて，SREの「NEXT」をみなさ んと⼀緒に考える 1. SREの「基調」としてのSREが何であるかの解釈を整理 2. 「NEXT」の⼀つとして，講演者が取り組んできたSREの各研究を1 つのストーリーに統合 ・所属するさくらインターネット研究所のビジョンを⽬指す形
4. 4 1. 研究の背景 2. 研究の⽬的 3. 互換性と性能を両⽴する時系列データベースの研究 4. 分散アプリケーションの依存関係追跡技術の研究 5. 地理分散協調クエリキャッシングの研究 6. むすび ⽬次
5. 1. 研究の背景
6. SRE (Site Reliability Engineering)
7. 7 Ironies of Automation (1983) ⾃動化の⽪⾁ 1. ⾃動化により⼈間の作業負担(Toil)を低減できる 2. しかし，⾃動化すればするほど⼈間の認知負荷が⾼まる 3. 認知負荷に耐えられるように⾼度な訓練が必要となる • L. Bainbridge, "Ironies of automation,” Analysis, design and evaluation of man–machine systems, pp.129-135 1983. • G. Baxter, et al. "The ironies of automation: still going strong at 30?,” the 30th European Conference on Cognitive Ergonomics 2012. • B. Strauch, "Ironies of automation: Still unresolved after all these years," IEEE Transactions on Human-Machine Systems, vol. 48, no. 5, pp. 419-433 2017. • J. Paul Reed, “When /bin/sh Attacks: Revisiting "Automate All the Things”,” USENIX LISA19 2019. • Tanner Lund, “Ironies of Automation: A Comedy in Three Parts,”, USENIX SREcon19 Asia/Pacific 2019. ⼈間と計算機をあわせた制御系の設計が必要となる
8. 8 ⾃動化の⽪⾁に対するアプローチ ・認知範囲外のものを扱うとかえって信頼性が低下する可能性がある ・システムへ変更を加えることを恐れるようになる ・失敗を許容する前提で運⽤を設計をする ・信頼性を向上させるだけでなく，短期的には低下させる選択肢を持つ ・しかし，低下させるといっても程度が不明であれば，最低限要求され る信頼性を下回る可能性がある
9. 9 SREͱ͸ͳʹ͔ ・信頼性低下のリスクを制御化に置くことで変更速度を最⼤化する ・信頼性という守りを制御することで，安⼼して変更速度という攻め に転ずることができる SREとは「サイト信頼性を制御するための⼯学」
10. 10 いかに失敗のリスクを⼩さくできるか？ リスクの事前予測 ・キャパシティプランニング ・サブシステム間の依存関係 の把握 (後述の研究2) ・… リスクの事後最⼩化 ・⾃動回復(フェイルオーバー) ・アラーティング ・因果関係の特定(分散トレー シングなど) ・インシデント対応体制の構築 ・⾼速なデプロイメント ・… リスクを⼩さくできると 恐怖が⼩さくなり変更速度が⾼まり 結果的に信頼性も⾼くなる
11. クラウド以外の領域への適⽤ 地理分散コンピューティング
12. 12 応答性能に占めるネットワーク転送遅延の問題 S Choy, B Wong, G Simon and C Rosenberg, “The Brewing Storm in Cloud Gaming: A Measurement Study on Cloud to End- User Latency,” 11th Annual Workshop on Network and Systems Support for Games, Annual Workshop on Network and Systems Support for Games (NetGames), pp. 1-6 2012. (1)利⽤者の端末 上での処理 (2) ネットワーク遅延 (3) データセンター内の処理 Cloud ・クラウドゲーミング環境で，(2)が⽀配的であるという研究がある ・100msのうち80msを占める
13. 13 さくらインターネット研究所のビジョン
14. 14 地理的に分散したコンピューティング ・複数リージョン構成 ・災害回復や海外の利⽤者とのネットワーク遅延を短縮 ・エッジコンピューティング，フォグコンピューティング ・利⽤者とクラウドのネットワークの間でコンピューティングを実 ⾏し，ネットワーク遅延を短縮 ・超個体型データセンター(さくらインターネット研究所提唱) ※ ・⼩・中規模データセンターを全国の都市単位で配置 ※࿯๺ݡ, ௒ݸମܕσʔληϯλʔΛ໨ࢦ͢౰ݚڀॴͷϏδϣϯ, 2019 https://research.sakura.ad.jp/2019/02/22/concept-vision- 2019/.
15. 15 地理分散コンピューティングの問題意識 システム構成要素の増加 システム内ネットワーク遅延 の増加 ・メトリック数の増加 ・サブシステム間の依存関係 の複雑化 ・データセンター間のネット ワーク遅延はクラウド内の遅 延よりも⼤きい ・各データセンター間でデー タを同期書き込みするときに 性能が低下する 可観測性(Observability) の重要性が増す
16. 研究の背景まとめ
17. 17 研究の背景まとめ 1. SREは信頼性を制御することを前提においた⼀つのアプローチであ ると解釈 2. 地理分散環境の台頭と，構成要素数の増加とネットワーク遅延増⼤ の課題を提⽰
18. 2. 研究の⽬的
19. 19 構成要素数とネットワーク遅延がうむ問題 ・システムの内部状態を把握しづらくなる ・リスクの事前予測と事後最⼩化が難しくなる ・時間軸⽅向と空間軸⽅向の両⽅の可観測性を⾼めて解決 ・ネットワーク遅延が⼤きいと同期待ち時間が⼤きくなる ・データベース(DBMS)の性能と⼀貫性を両⽴させづらい
20. 20 先⾏研究と課題: 可観測性 時間軸⽅向の可観測性 空間軸⽅向の可観測性 ・性能を重視して実装を時系 列データに最適化している ・既存のDBMSを利⽤した互 換性や拡張性が失われる ・サブシステム間の依存関係 を追跡すること ・既存のアプリケーション コードの変更をともなう， あるいはアプリケーション に与 える性能影響が⼤きい
21. 21 先⾏研究と課題: データ⼀貫性 ・強⼀貫性の場合，同期待ち時間 が⼤きくなる 既存のアプリケーションや既存のDBMSのコード変更が必要 アプリケーションの性能影響が⼤きい ・結果整合性モデルの場合，⼀貫 性に対するアプリケーション開 発者の責任範囲が⼤きくなる NoSQL 遅延の⼤きな環境での性能とデータ⼀貫性の両⽴ NewSQL
22. 22 研究の⽬的 ・⼤⽬的: 地理的に分散したアプリケーションの信頼性向上 ・制約: 既存のアプリケーションやミドルウェアのコードを変更せず， 性能影響をあたえない ・3つの⽬的 1. 時間軸の可観測性: 時系列データベースの性能と互換性の両⽴ 2. 空間軸の可観測性: 依存関係を低負荷かつ網羅的に追跡 3. データの⼀貫性を保証しつつ，応答性能を最⼤化できるように制御
23. 3. 互換性と性能を両⽴する 時系列データベースの研究 Yuuki Tsubouchi, Asato Wakisaka, Ken Hamada, Masayuki Matsuki, Hiroshi Abe, Ryosuke Matsumoto, “HeteroTSDB: An Extensible Time Series Database for Automatically Tiering on Heterogeneous Key-Value Stores”, Proceedings of The 43rd Annual IEEE International Computers, Software & Applications Conference (COMPSAC), pp. 264-269, July 2019.
24. 24 研究の⽬的(再掲) ・⼤⽬的: 地理的に分散したアプリケーションの信頼性向上 ・制約: 既存のアプリケーションやミドルウェアのコードを変更せず， 性能影響をあたえない ・3つの⽬的 1. 時間軸の可観測性: 時系列データベースの性能と拡張性の両⽴ 2. 空間軸の可観測性: 依存関係を低負荷かつ網羅的に追跡 3. データの⼀貫性を保証しつつ，応答性能を最⼤化できるように制御
25. 25 ɾετϨʔδΤϯδϯΛ࣌ܥྻσʔλʹ࠷దԽ͢Δ͜ͱʹΑΓɼॻ͖ࠐ ΈɾಡΈࠐΈޮ཰ͱσʔλอଘޮ཰ΛߴΊ͍ͯΔ ɾPrometheus, InfluxDB, M3, Graphite, … ɾγεςϜ؅ཧऀ͸ͦΕҎ֎ͷ༻్͕গͳ͍࣌ܥྻσʔλϕʔε(TSDB) ͷͨΊͷӡ༻ίετΛࢧ෷Θͳ͚Ε͹ͳΒͳ͍ ɾ࢖͍׳ΕͨDBMS΍ɼϚωʔδυͷDBMSΛ࢖͑ͳ͍ ઌߦख๏ͱͦͷ՝୊
26. 26 HeteroTSDBΞʔΩςΫνϟ(1) 1. ҟछࠞ߹DBMSʹΑΔૄ݁߹ΞʔΩςΫνϟ (1)୯ҰͷTSDBΞʔΩςΫνϟΛϩάɼΠϯσοΫεɼ࣌ܥྻσʔλ ߏ଄ͷΑ͏ͳෳ਺ͷ෦඼ʹ෼ׂ͢Δ (2)֤छσʔλߏ଄ʹରͯ͠ಠཱͨ͠DBMSΛ௥Ճ͢Δ (3)͜ΕΒͷ෦඼ΛҰͭͷૄ݁߹ΞʔΩςΫνϟͱͯ͠౷߹͢Δ DBMS Single TSDB DBMS Index DBMS Log HeteroTSDB Time series data
27. 27 HeteroTSDBΞʔΩςΫνϟ(2) 2. ࣌ܥྻσʔλߏ଄Λ୲౰͢ΔDBMSΛަ׵Մೳʹ͢Δ ↪ ΩʔόϦϡʔʹجͮ࣌͘ܥྻσʔλߏ଄ʹΑΔޓ׵ੑ ΩʔόϦϡʔ͸ଟ͘ͷDBMSͰ࣮ݱՄೳͳσʔλߏ଄ 3. ॻ͖ࠐΈॲཧͱσʔλอଘޮ཰ͷ޲্ ↪ ΠϯϝϞϦKVSͱΦϯσΟεΫKVSͷࣗಈ֊૚Խ In-Memory KVS On—Disk KVS Tiering Single TSDB DBMS Index DBMS Log Our TSDB architecture
28. αʔόʔϨεϓϥοτϑΥʔϜʹΑΔ࣮૷ In-Memory KVS Amazon Elasticache For Redis (Redis Cluster) On-Disk KVS Amazon DynamoDB On-Disk KVS2 Amazon S3 Write Ahead Log Amazon Kinesis Streams Index (Label or Tag) Elasticache or DynamoDB
29. 29 ஍ཧ෼ࢄ؀ڥ΁ͷల։ͷߏ૝ தԝͷΫϥ΢υσʔληϯλʔ΁ͷॻ͖ࠐΈෛՙ௿ݮ Cloud Edge On-Disk KVS In-memory KVS In-memory KVS ①Write ①Write ①Read ②古くなったら移動 直近のデータ 直近のデータ ② ②
30. 4. 分散アプリケーションの依存関係追跡 の研究 坪内佑樹, 古川雅⼤, 松本亮介, “Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の⾃動 追跡”, インターネットと運⽤技術シンポジウム論⽂集, 2019, 64-71 (2019-11-28), 2019年12⽉.
31. 31 研究の⽬的(再掲) ・⼤⽬的: 地理的に分散したアプリケーションの信頼性向上 ・制約: 既存のアプリケーションやミドルウェアのコードを変更せず， 性能影響をあたえない ・3つの⽬的 1. 時間軸の可観測性: 時系列データベースの性能と拡張性の両⽴ 2. 空間軸の可観測性: 依存関係を低負荷かつ網羅的に追跡 3. データの⼀貫性を保証しつつ，応答性能を最⼤化できるように制御
32. 32 ・Linuxのパケットフィルタログを利⽤してL4接続の状態を取得 ・Linuxカーネルの通信機構を利⽤する限り，プロセスに対して透過 的に追跡可能 ・遅延オーバヘッド: パケットフィルタ処理のオーバヘッド ・偽陰性: リソース消費を抑えるために，パケットを無作為にサンプ リングするため，検知漏れの可能性がある 既存のパケットベースのトレーシング技術※ ※J. K. Clawson, Service Dependency Analysis via TCP/UDP Port Tracing, Master’s thesis, Brigham Young University-Provo 2015.
33. 33 ネットワークソケットモニタリング Linux OS Kernel Process Process TCP Flows … . . . User ソケット を監視 TCP接続の終端点であるソケットを監視し接続を⾃動追跡 1. 遅延オーバヘッドの解決 ・ソケットの監視をプロセス の通信と独⽴させる 2. 偽陰性の解決 ・すべてのソケットを監視 ・パケット数よりも接続数=ソ ケット数のほうが⼩さい ・接続を永続化していると顕 著な差となる Tracer
34. 34 システム構成 Host 1 Host 2 Host N CMDB Tracer Tracer Tracer Systems Administrator ・ホスト上にTracerプロセスを配置 ・各Tracerプロセスは取得した接続情 報をCMDB(接続情報管理DB)に保存 ・システム管理者はCMDBにアクセス し，複数のホストにまたがり依存関 係を取得
35. 35 地理分散環境への展開の構想 CMDBのホスト単位の⾃律分散配置 Host Tracer Tracer DB Tracer Tracer Host Host Systems Administrator Host 1.各ホスト上のローカルに DBを配置 2.Tracerは⾃⾝のDBに⾃ ⾝の依存関係を書きこみ 3.読み出し時は問い合わ せたのあったホストを起 点に依存先/元のTracer に再帰問い合わせ ᶃ ᶄ ᶄ DB DB DB
36. 5. 地理分散協調クエリキャッシング の研究 ௶಺༎थ, দຊ྄հ, “௒ݸମܕσʔληϯλʔʹ͓͚Δ෼ࢄڠௐΫΤϦΩϟογϡߏ૝”, ৘ใॲཧֶձݚڀใࠂΠϯλʔωοτͱ ӡ༻ٕज़ʢIOTʣ, No.2019-IOT-45, Vol.14, pp.1-7, 2019೥5݄.
37. 37 研究の⽬的(再掲) ・⼤⽬的: 地理的に分散したアプリケーションの信頼性向上 ・制約: 既存のアプリケーションやミドルウェアのコードを変更せず， 性能影響をあたえない ・3つの⽬的 1. 時間軸の可観測性: 時系列データベースの性能と拡張性の両⽴ 2. 空間軸の可観測性: 依存関係を低負荷かつ網羅的に追跡 3. データの⼀貫性を保証しつつ，応答性能を最⼤化できるように制御
38. 38 システム要件1: 分散データセンターへの透過性 スコープ: 動的コンテンツの配信の⾼速化のために読み込み性能を向上 Replica Replica Replica Origin Central Datacenter 全データセンターに キャッシュの複製を配置 することで 透過的にデータを⾼速参 照可能 中央データセンターへ書 き込みを向けて キャッシュを伝搬
39. 39 システム要件2: 既存のアプリケーションを無変更 スコープ: 動的コンテンツの配信の⾼速化のために読み込み性能を向上 Central Datacenter App DB Proxy DataBase HTTP Request Caching Query Edge Datacenter アプリケーションとデータベースの間にプロキシを介してクエリ をキャッシュ 書き込みに対して同期的にキャッシュとデータベースを更新し， 強い⼀貫性を担保
40. 40 ஍ཧ෼ࢄσʔληϯλʔ্Ͱͷෳ੡ͷ՝୊ ɾಉظߋ৽࣌ʹωοτϫʔΫ஗Ԇͷେ͖͍σʔληϯλʔʹ཯଎͞Εͯ Ԡ౴ੑೳ͕௿Լ͢Δ͜ͱ Replica Origin (1) ॻ͖ࠐΈཁٻ (2) ಉظߋ৽ ཯଎ Edge Datacenter Central Datacenter Replica Replica
41. 41 提案: QuorumCacheアーキテクチャ 1. 同期更新の範囲をネットワーク遅延に応じて調節可能 2. アプリケーションの読み書き回数の⽐率に応じて同期更新の範囲を適 応的に決定可能 ネットワーク遅延とアクセス傾向の変動に応じて 応答性能を適応的に最⼤化する基盤の提案 同期更新時にネットワーク遅延の⼤きいデータセンターに律速される 課題を解決
42. 42 QuorumCacheの動作フロー Central Datacenter Origin Replica Replica Replica Replica d: 近傍ネットワーク距離 Edge Datacenter Replica Replica d (1) 書き込み要求 (2) 書き込み要求 転送 (3) 同期更新 (i) 読み込み要求 (ii) d以内のデータ センターから 読み込み Replica (4) ⾮同期更新
43. 43 QuorumCacheのシステム構成 HTTP Proxy Central Datacenter Web App DB Proxy DataBase HTTP Request Caching 読み書き⽐率の 計測(HTTP) 読み書き⽐率の 計測(DBクエリ) 応答性能の計測 Query DB Proxy Web App HTTP Proxy ・制御ポイントとしてHTTPとDBの層にプロキシを配置 Forward Edge Datacenter ・Transtracerによりクエリの TCP層のネットワーク遅延を 計測
44. 6. むすび
45. 45 まとめ ・SREは失敗を前提として信頼性を制御するアプローチであると解釈 ・地理分散コンピューティングが今後台頭してくると予想 ・構成要素数の増加と，システム内ネットワーク遅延の増加の問題 ・問題を解決する研究の提⽰ 1. 時系列データベースにおいて，互換性と性能を両⽴ 2. リスクを事前予測するために，低負荷かつ網羅的な依存関係追跡 3. データ⼀貫性を維持しつつ，読み込み性能を最⼤化
46. 46 SRE “NEXT” SRE 地理分散 High-Performance Computing(HPC) 量⼦コンピュータ 認知システム⼯学 経営学 ⼈と組織 ⼈と機械 拡張 導⼊ ・クラウドコンピューティング以外のコン ピューティング領域への拡張 ・計算機中⼼から⼈間中⼼のアプローチ ※1 ೖࢁষӫ, “ੈքඪ४ͷܦӦཧ࿦,” μΠϠϞϯυࣾ, 2019. ※2 ੁ໺ଠ࿠, “ೝ஌γεςϜ޻ֶతΞϓϩʔνʹΑΔࣾձσβΠϯ,” ԣװ, Vol. 4, No. 2, pp. 68-73 2010. ※3 ᑼ໦఩෉, “ਓͱػցͷڞ૑ʹΑΔ׆ྗ͋Δࣾձٕज़γεςϜͷσβΠϯ,” ܭଌͱ੍ޚ, Vol. 57, No. 2, pp. 79-84 2018. ※1 ※2 ※3
47. 分散アプリケーションの信頼性観測技術 に関する研究 Yuuki Tsubouchi / @yuuk1t SRE NEXT IN TOKYO 2020 基調講演 2020.01.25