2020-10-23 IEEE SERVICE (CLOUD) 2020 4日目速報と #InfraStudy の司会、次回は僕の番！

国際会議 研究日誌
  • 今日も昼からIEEE SERVICEに参加しつつ、興味のある予稿などをさかのぼって読んだりしている

Session CLD 15: Microservices and Containers

  • Realizing a Composable Enterprise Microservices Fabric with AI-Accelerated Material Discovery API Services313

    • Rong N. Chang (IBM Research), Kumar Bhaskaran (IBM Research), Prasenjit Dey (IBM Research), Hsiang Han Hsu (IBM Research), Seiji Takeda (IBM Research), Toshiyuki Hama (IBM Research)

  • Sledge : Towards Efficient Live Migration of Docker Containers321

    • Bo Xu (Huazhong University of Science and Technology, China), Song Wu (Huazhong University of Science and Technology, China), Jiang Xiao (Huazhong University of Science and Technology, China), Hai Jin (Huazhong University of Science and Technology, China), Yingxi Zhang (State Key Laboratory of Intelligent Manufacturing System Technology, China), Guoqiang Shi (State Key Laboratory of Intelligent Manufacturing System Technology, China), Tingyu Lin (State Key Laboratory of Intelligent Manufacturing System Technology, China), Jia Rao (The University of Texas at Arlington, USA), Li Yi (Alibaba Cloud Computing Co. Ltd., China), Jizhong Jiang (Alibaba Cloud Computing Co. Ltd., China)
    • このホワイトペーパーでは、実行時の移行中にイメージと管理コンテキストの両方を統合することでコンポーネントの整合性を確保するライブ移行システムを紹介
    • 階層化されたイメージを活用して移行のオーバーヘッドを削減でき、管理コンテキストを適切に選択的に移行できる
    • ダウンタイムを無視して、QoSを効果的に改善
    • 優れたスケーラビリティを実現するために、エンドツーエンドのイメージ移行用の軽量コンテナレジストリメカニズムは、冗長レイヤーの送信を回避するように設計
    • 軽量コンテナレジストリ（LCR）メカニズムを設計して、エンドツーエンドのイメージ移行を実現し、イメージレイヤーの階層機能の詳細な分析に基づいて、LCRは冗長な送信を効果的に回避
    • 実行中のデーモンに管理コンテキストを正確にロードするための動的コンテキストロードスキームが提案
    • CRIUのインクリメンタルメモリチェックポイント機能を組み込むことにより、Dockerコンテナのランタイムを繰り返し移行
    • DockerデーモンとDockerコンテナー間の結合関係を利用して、動的コンテキスト読み込み（DCL）スキーム、Dockerコンテナーの管理コンテキストを実行中のデーモンに正確にロード
    • Dockerのリロードを回避できるため、ダウンタイムが大幅に短縮
    • 最新技術と比較して、総移行時間の57％、画像移行時間の55％、およびダウンタイムを70％削減

  • RITA: Efficient Memory Allocation Scheme for Containerized ParallelSystems to Improve Data Processing Latency329

    • Danlin Jia (Northeastern University), Mahsa Bayati (Northeastern University), Ron Lee (Samsung Semiconductor), Ningfang Mi (Northeastern University)
    • メモリ仮想化の場合、データ処理フレームワークは、アプリケーションのキャッシュ特性と並列処理を考慮せずに、物理メモリ（RAMなど）を割り当て、ユーザーが指定したアプリケーションにスワップするので、パフォーマンスが低下し、レイテンシが大幅に長くなり、プロビジョニングが過剰になるとさらに悪化するという課題
    • データ処理の待ち時間を改善するために、コンテナ化された並列システム用の効率的なメモリ割り当てスキーム（RITA）を設計
    • RITAは、アプリケーションのメモリ使用量とキャッシュ特性を監視し、メモリリソースを動的に再割り当て
    • コンテナーとDockerエンジンの両方と通信し、各アプリケーションのリソース使用量を監視し、キャッシュに基づいてアプリケーションを並べ替え
    • キャッシュヒット率と一意のメモリアクセスサイズから導出されるフレンドリースコアにもとづく
    • キャッシュに適したスコアが高いアプリケーションは、空間的および時間的な局所性が強いことがよくあるので、これらのキャッシュに適したアプリケーションに物理メモリを割り当てて、貴重な物理メモリリソースを最も効果的に利用し、全体的なパフォーマンスを向上させる
    • キャッシュフレンドリースコアは低いが、より多くの物理メモリリソースを占有するアプリケーションを定期的に検出し、これらのアプリケーションを一時停止して、他のキャッシュフレンドリーアプリケーションの実行のために物理メモリスペースを解放
    • RITAは、他のコンテナベースの仮想化環境に簡単に移行できる実際のシステムに実装
    • RITAがメモリを大量に消費する分散データ処理ワークロードのレイテンシを大幅に改善することを示した
    • 1）コンテナベースの仮想化における分散データ処理ワークロードを調査しデータ処理アプリケーションのさまざまなメモリ割り当て戦略を使用して実験を行い、キャッシュの特性をプロファイリングして分析
    • 現在のメモリ割り当てメカニズムでは、パフォーマンスの干渉とリソースの競合が存在する
    • 2）効率的なメモリ割り当てスキームを設計および実装
    • コンテナ化環境における分散データ処理フレームワークのメモリ割り当ての問題を定式化
    • アプリケーションのキャッシュ特性を考慮してメモリを割り当て、遅延を改善する新しいメモリ割り当てスキーム（RITA）を紹介
    • 3）ワークロードのメモリ強度がシステムパフォーマンスに与える影響を分析
    • さまざまなタイプのワークロードでのRITAのパフォーマンスの差異を調査しオーバープロビジョニングによるメモリ強度の影響を分析

Session CLD 16: Edge Application I

  • Allies: Tile-Based Joint Transcoding, Delivery and Caching of 360° Videos in Edge Cloud Networks337
    • Jianxin Shi (Nankai University, China; Xidian University, China; Tianjin Key Laboratory of Network and Data Security Technology, China), Lingjun Pu (Nankai University, China; Xidian University, China; Tianjin Key Laboratory of Network and Data Security Technology, China), Jingdong Xu (Nankai University, China; Tianjin Key Laboratory of Network and Data Security Technology, China)
    • 360◦またはパノラマビデオアプリケーションは急成長を遂げており、近年大きな注目を集めている
    • サイズが大きく、通常は近距離から視聴するため、没入型のエクスペリエンスを向上させるには、非常に高い帯域幅とフレームレートが必要であり、モバイルネットワークで大きな課題
    • タイルベースのトランスコーディング、ビューポートアダプティブストリーミング、およびエッジキャッシングの大きな可能性を実現するために、エッジクラウドネットワークの360°ビデオサービス向けのタイルベースの共同トランスコーディング、配信、およびキャッシングフレームワークであるAlliesを提案
    • 1）ビデオキャッシュの配置、2）タイル品質のキャッシュの配置、3）リクエストのスケジューリングという3つの重要な問題を解決する
    • タイルベースの共同トランスコーディング、配信、およびキャッシングの問題を、エッジクラウドの総サービス展開コストを最小化する整数非線形プログラム（INLP）として定式化
    • エッジクラウドのキャッシュ使用率を改善するために、ジョイント最適化問題を整数非線形プログラムとして定式化し、ビデオサービスコストを最小限に抑えるために、多項式実行時間を持つ貪欲な準最適アルゴリズムを提案
    • 実際のユーザーの頭の動きのトレースと対応する360°ビデオデータセットを使用した広範なシミュレーションにより、提案されたアルゴリズムの効率、柔軟性、軽量性を評価
    • さまざまなシステム設定での最先端の作業と比較して、25％を超えるパフォーマンスの向上を実現

  • Multi-objective Cross-Layer Resource Scheduling for Internet of Things in Edge-Cloud Computing345

    • Ruichao Mo (Nanjing University of Information Science and Technology, China), Fei Dai (Southwest Forestry University, China), Qi Liu (Nanjing University of Information Science and Technology, China), Wanchun Dou (Nanjing University, China), Xiaolong Xu (Nanjing University of Information Science and Technology)
    • サービス要件（つまり、最短の完了時間、最大のリソース使用率、低エネルギー消費など）を満たすために、クラウドにデプロイされたエッジノードとサーバー間のクロスレイヤーリソーススケジューリングの実装は、依然として大きな課題
    • IoTアプリケーション向けのCRSMという名前のクロスレイヤーリソーススケジューリング方法を提案
    • パレートアーカイブ進化戦略（PAES）を使用して、IoTアプリケーションの時間コスト、リソース使用率、およびエッジノードのエネルギー消費を最適化
    • 理想的なソリューションとの類似性による順序優先の手法（TOPSIS）と多基準意思決定（MCDM）を活用して、最適なクロスレイヤーリソーススケジューリング戦略
    • CRSMの包括的な分析を詳細に紹介

  • Wasmachine: Bring the Edge up to Speed with a WebAssembly OS353

    • Elliott Wen (The University of Auckland), Gerald Weber (The University of Auckland)
    • 非Web環境、特にIoTとエッジコンピューティングにおけるWebAssemblyの可能性を探求し始めている
    • WebAssemblyの主な課題は、ネイティブコードとのパフォーマンスのギャップでWebAssemblyにコンパイルされたアプリケーションは、以前のベンチマークで報告されているように、平均45％遅くなり、減速の主な原因は2つで、まず、従来のWebAssemblyランタイムは、複雑なコード最適化を適用しないジャストインタイムコンパイラを使用してWebAssembly命令をネイティブマシンコードに変換し、次に、WebAssemblyアプリケーションからのシステムコールは、オペレーティングシステムに到達するためにランタイムによってプロキシされる必要があり、これには大きなパフォーマンスのオーバーヘッドが発生する
    • WebAssemblyアプリケーションが起動すると、最初に解釈され、しばらくすると、頻繁に実行されるメソッドがネイティブコードにコンパイルされ、実行効率が向上
    • JITを使用すると、起動時間を短縮できるが、コードの最適化に費やすことができる時間が限られているため、コードの効率が低下
    • Webブラウジングのコンテキストでは、JITの使用は、優れたユーザーエクスペリエンスを提供するために高速な起動時間が重要である場合に合理的な選択だが、IoTとエッジコンピューティングの場合、コード効率が優先される
    • これらの問題に対処するために、IoTおよびリソースに制約のあるエッジデバイスでWebAssemblyアプリケーションを効率的かつ安全に実行することを目的としたOSであるWasmachineを紹介
    • Wasmachineは、WebAssemblyを事前にネイティブバイナリにコンパイルし、ゼロコストのシステムコール用にカーネルモードで実行することにより、効率的な実行を実現
    • Wasmachineはベアメタルマシン用のOSカーネルで、WASIプロトタイプでシステムコールをエクスポートし、各WebAssemblyアプリケーションをカーネルスレッドとして（つまり、リング0で）実行
    • カーネル空間で実行する場合でも、Wasmachineは、WebAssemblyのさまざまな言語機能を利用してソフトウェアベースの障害分離を提供することにより、安全性を維持
    • まず、WebAssemblyのさまざまなセキュリティ機能を活用することで、AOTコンパイラはソフトウェアベースの障害分離を備えたAOT化バイナリを低ランタイムコストで生成
    • カーネルは、特別に設計された仮想メモリマッピングスキームによって追加のプロセス分離を提供し、カーネルが1つのページテーブルをナビゲートするだけで済み、コンテキストスイッチのペナルティもページキャッシュの無効化も発生しない
    • Wasmachineプロトタイプをメモリセーフプログラミング言語Rustで実装し、パフォーマンス評価を実施し、Wasmachineで実行されているWebAssemblyアプリケーションがLinuxのネイティブアプリケーションよりも最大21％高速
    • 1）WebAssemblyの安全なランタイムアーキテクチャを提案しカーネルを多用するアプリケーションのネイティブ実行よりも高速
    • 2）WebAssembly用のAOTコンパイラを実装し、ソフトウェアベースの障害分離を備えた効率的なバイナリを生成
    • 3）WebAssemblyに最適化されたOSカーネルをRustに実装し、ゼロコストのシステムコールとプロセスの分離が実現
    • 4）Wasmachineプロトタイプの定量的性能評価を実施し、Rustカーネルと一般的なCベースのカーネルの比較も行っている
    • WebAssemblyをIoT機器で直接実行できるカーネルを開発したという話だけど、WebAssemblyだとなぜうれしいのかというのはわからなかった
    • Why did you adopt WebAssembly to run it directly on embedded devices?

Session CLD 17: Edge Application II

  • Optimizing Allocation and Scheduling of Connected Vehicle Service Requests in Cloud/Edge Computing

    • Yecheng Zhao (Toyota InfoTechnology Center, USA), BaekGyu Kim (Toyota Motor North America, R&D)
    • パフォーマンス、リソース使用率、およびコストを最適化するために、これらのサービスの要求をクラウド/エッジコンピューティングシステムに慎重に割り当てることが重要
    • 車両の移動性を考慮すると、サービスがますます高度になり、計算量が多くなると、車両はリクエストのキューイングおよび処理中に重要な距離を移動する可能性があり、アクセス集中している時の結果データの送信に影響を与える
    • リクエストの割り当ては、送信とは対照的に、リクエストの完了時に車両の予想される位置を認識することが重要
    • 複数のクラウド/エッジデバイスとリソースの競合が存在する一般的なシナリオでは、車両の軌道、ワークロード、およびリクエストのスケジューリングを同時に考慮して、割り当てを共同で最適化することが重要
    • 異種クラウド/エッジサービスでのコネクテッドカーサービスリクエストの割り当てとスケジューリングにおけるコスト最小化の問題を研究
    • 車両がサービス遅延中に重要なモビリティを持っているシナリオを検討し、データ送信への影響をモデル化
    • 最適化問題を解決するための最適なILP定式化と、効率的で最適に近いヒューリスティックアルゴリズムを紹介
    • 提案された技術が単純なアプローチと比較して10％から30％の改善を達成できることを示している

  • DeepPM: Efficient Power Management in Edge Data Centers Using Energy Storage

    • Zhihui Shao (University of California, Riverside), Mohammad Islam (University of Texas at Arlington), Shaolei Ren (University of California, Riverside)
    • モノのインターネット（IoT）の急速な発展に伴い、計算ワークロードは、低遅延のためにインターネットエッジに向かって徐々に移動
    • ワークロードが大幅に変動するため、分散した場所に構築されたエッジデータセンターは、リソースが十分に活用されておらず、設備投資の無駄を省くために容量のプロビジョニングが不十分
    • ワークロードの変動により、エッジデータセンターは、プロビジョニング不足によるパフォーマンスへの影響に対抗するためのバッテリ支援電源管理により適している
    • ワ​​ークロードの変動により、バッテリーを頻繁に再充電し、一時的な容量の増加に利用できるようになるが、バッテリーを使用すると、電力システムと同じ容量で設計されたデータセンターの冷却システムが過負荷になる可能性がある
    • UPSバッテリーとエッジデータセンター内の冷気をエネルギー貯蔵として活用してパフォーマンスを向上させる、新しい電源管理ソリューションであるDeepPMを設計
    • ディープ補強学習（DRL）を使用して、モデルフリーの方法でオンラインでデータセンターの熱的動作を学習し、オンザフライで使用して、データセンターを過熱することなく最適な遅延パフォーマンスのための電力割り当てを決定
    • DeepPMは、サーバーの入口温度が安全な動作制限（32°Cなど）内にある間、電力上限ベースラインと比較してレイテンシーパフォーマンスを50％以上向上できる
    • これ、さくらが例えばエッジデータセンターを作るとかなると問題になるような話で面白いしいかにもファシリティって感じだ

Session CLD 18: Network and Storage Optimization

  • A Lightweight SOA-Based Network Slicing Creation System389

    • Meng Wang (Beijing University of Posts and Telecommunications), Bo Cheng (Beijing University of Posts and Telecommunications), Junliang Chen (Beijing University of Posts and Telecommunications)
    • 次世代ネットワークシステムは、複数のアプリケーションをサポートするマルチサービスネットワークを想定
    • 同一物理インフラ上に複数の仮想ネットワークを構築するためには、ネットワークスライシング（Network SLicing: NSL）が重要なメカニズム
    • NSLを柔軟かつ完全に自動化して展開することは困難な問題
    • 設計ドメイン、実行ドメイン、インフラストラクチャドメインを含む、SOAベースの軽量なNSL作成システムを提案
    • ネットワークサービスを設計するためのリソースと要件を示すため、Network SLicing Descriptor (NSLD)と呼ばれるNSLの詳細な記述を定義
    • 実行ドメインは、マルチテナンシー対応のサービス実行環境
    • マイクロサービスアーキテクチャに基づくこのドメインは、分散型で自己組織化
    • テナントはWebブラウザ上で直感的で使いやすいUIを介して自由にNSLを作成することができ

  • PCHA: A Fast Packet Classification Algorithm for IPv6 Based on Hash and AVL Tree397

    • Yu-yan Zhang (Beijing University of Posts and Telecommunications), Xing-xing Chen (Beijing University of Posts and Telecommunications), Xu Zhang (Beijing University of Posts and Telecommunications)
    • クラウドデータの運用、交換、保管の中核インフラであるデータセンターは、クラウドコンピューティングの発展のための重要な前提条件である安全性と信頼性を確保することが必要
    • 不正アクセス、攻撃、ウイルスなど様々なセキュリティ上の脅威があるため、セキュリティゲートウェイを介してクラウドデータセンターの境界を保護する必要がある
    • トラフィックはギガバイトレベルにまで増加しているため、セキュアゲートウェイは、クラウドサービスをサポートするために、高い伝送効率とさまざまなネットワークサービスを確保する必要がある
    • IPv6は128ビットのIPアドレスを持ち、IPv4とは異なるパケット構造を持つため、従来のIPv4パケット分類アルゴリズムではIPv6の状況に適切に対応することができない
    • IPv6の高速パケット分類アルゴリズムであるPCHA（ハッシュとAdelson-Velsky-Landis Treeに基づくパケット分類）を提案
    • RFC3697で定義されたIPv6パケット内の送信元IPアドレス(SA)、送信先IPアドレス(DA)、フローラベル(FL)の3つのフロー分類フィールドを採用し、可変長のIPv6アドレスのハッシュマッチングと、より短いフローラベルのツリーマッチングによる高速な3つのタプルマッチングを実現
    • 分析とテストの結果、このアルゴリズムは空間の複雑さの許容範囲内でO(1)に近い時間の複雑さを持っており、IPv6パケットの高速分類の要件を満たしており、ルールセットの高速な前処理をサポートし、ルールセットのサイズの変化にうまく適応することができる
    • このアルゴリズムは、ゲートウェイデバイス上の50万の3タプルルールのストレージをサポートし、78バイトの小さなパケットのスループットの75％のパフォーマンスを維持することができる

Session CLD 22: Cloud Performance and Maintenance

  • RAD: Detecting Performance Anomalies in Cloud-Based Web Services

    • Joydeep Mukherjee (York University, Toronto), Alexandru Baluta (York University, Toronto), Marin Litoiu (York University, Toronto), Diwakar Krishnamurthy (University of Calgary, Canada)
    • パブリッククラウドプラットフォームでホストされているWebサービスは、パフォーマンスの異常にさらされることがよくあり、異常のランタイム検出は重要
    • データセンターのサイズがますます大きくなり、ソフトウェアアプリケーションが複雑になり、動的なトラフィックワークロードパターンが発生するため、パフォーマンスの異常を自動的に検出することは困難
    • アプリケーションレベルのインストルメンテーションを必要とせず、多層クラウドベースのWebサービスの異常を検出するために簡単に実装できる軽量のランタイム異常検出手法
    • 特に、サービス内からの競合による異常や、クラウド上で実行されている他のサービスによる共有リソースの競合による異常など、システムレベルの指標だけを監視するだけでは検出が難しい異常に焦点を当てている
    • RADは、サービスリソースのメトリックを継続的に監視し、キューイングネットワークモデルを使用して、実行時にパフォーマンスの異常を検出
    • RADは履歴データを使用し、統計的手法を実装して異常の根本原因を診断
    • RADは、ツインワークロードにキューイングネットワークモデルを使用して、ツインのランタイム応答時間を、異常がない場合のモデル予測ベースライン応答時間と比較
    • RADは、これら2つの間に統計的に有意な偏差がある場合、パフォーマンス異常の存在を示す
    • 異常が検出されると、RADは異常の根本原因を特定し、内部異常の場合、RADは、システムから収集された履歴データを使用して、ソフトウェアコンポーネント、サービス層、または異常をトリガーする要求URLを分離
    • プライベートクラウドとEC2パブリッククラウドプラットフォームでRADを評価し、RADがサービスで非常に低いレベルのパフォーマンスオーバーヘッドを発生させ、多層モノリシックサービスとマイクロサービスの両方の異常を検出するのに効果的であることを示した
    • 既存の手法では捕捉が難しいソフトウェアのボトルネックや干渉によって引き起こされる異常にのみ焦点を当ててい
    • ゆううきさんの研究分野とかなり似ている、と思ったけどアプリをいじらずアプリの異常を検知するみたいな話だから少しレイヤーが違うか
    • RADはツインワークロードを実行し、ツインのQNM予測ベースライン応答時間を使用して異常を推測
    • 異常が顕在化するサービス層と異常の原因となるURLを特定するなど、異常の根本原因を調査
    • ソフトウェア構成の誤りやクエリの待ち時間のボトルネック、外部干渉などの内部ボトルネックによって引き起こされる頻繁な異常タイプに対して検証
    • RADが導入するオーバーヘッドのレベルはごくわずかであり、モノリシックWebサービスおよびコンテナーベースのマイクロサービスに対してプライベートクラウドとAWSEC2パブリッククラウドの両方で異常を検出するのに効果的であることを示した

  • 予習していたら次のセッション大体理解した気がする（一つはPDFコピペできないし）ので今日は店じまう

  • エッジやクラウドの文脈では負荷や異常やリソース分配に対するワークロードが複雑すぎるから、それをどうにか動的にやるという研究が増えてきているように思えた

  • 今日はInfraStudyの司会をやって、まさに今国際会議で聴いているエッジやクラウドの連携・最適化の話なので、個人的にも随分楽しめた

  • そして次回のInfraStudyは僕しゃべるのでぜひいらしてください！