2020-10-29 久々に福岡オフィスに出社して研究作戦会議をしたり歓迎会をしたり社内研究会をしたり共同研究会をしたりしてnotion最高

研究会 研究日誌 国際会議 会議
  • 機能は飲み会後にすぐゲームの用事があったので昨日のできごとも合わせて
  • 久々に福岡オフィスに出社して研究の作戦会議や研究計画をつるべーさんとおしゃべりしていた
  • 研究の定例MTGもあったので、各研究員が参加していた研究会や国際会議の振り返りをやっていた
  • ゆううきさんがめちゃハイクオリティな振り返りをしていてそれが公開されているので、ぜひ最先端の研究（state-of-the-art）に興味がある方は読むと良さそう

blog.yuuk.io

所感 クラウドコンピューティングにまつわる課題を機械学習をはじめとした数理的アプローチで解く研究が多数発表されたことから、現在取り組んでいる研究の発表の場として適切であると感じた。 このような研究が多数発表されているにも関わらず、未だ現場ではルールベースの運用がなされていることから、実環境への適用可能性に重視して研究していこうという気持ちになった。 同僚のまつもとりーさんも一緒に参加していろいろ感想を書かれているので、そちらも参照してみてほしい。 https://matsumotory.hatenadiary.jp/entry/2020/10/24/232547

まさにこの通りでも僕ももったく同じ感想を持ったのでシンクロ感があった。

matsumotory.hatenadiary.jp

今日でIEEE SERVICEが終わった IEEE CLOUD全体を通して、やっぱり、システムにおけるワークロードの複雑さから、ときたい問題について特徴や関連するパラメータを抽出したりスコープを絞ってからその事象をモデル化したり定式化、NP困難からくる貪欲法や近似、などのような解き方で解いてみてそれがどれぐらい効果があったかを示すような話題がすごく多かった 問題自体はずっと僕が昔から着目してきた得意なところで大学時代からやってきたテーマだけど、それが改めてML/AIやそれを取り巻くツール、コンピュータリソースの進化に伴って、ML/AIを使ったり新しいアルゴリズムやモデル化を利用して数学的・統計学的に解くというのは随分とトレンドになってきているなと思えた さらには、エッジの文脈を含む研究も多くて、その場合はDCをはじめ、ハードも含めたワークロードの複雑さ定式化するというアプローチは同様にあって、解き方の細かい差分はあるものの、複雑なシステムにおける複雑なワークロードを経験的に解決できないので、そこで問題と思われる事象を抽出してモデル化し、それを既存のMLの手段やアルゴリズム、それらを組み合わせる新しいアルゴリズムを提案して問題を解く、というストーリーは同じように思えた この辺をやっていく必要があるなと改めて思った といいつつ、こういう研究って昔からすごいされているけれど、実際に作られているシステムやサービスを考えると、動的に構成されているのはほんの一部で、実際にリアルで使えるというところを考えたときのギャップについてはまだあ違和感があって、そこはもう少し近くの同僚と議論しながら考えていきたい

  • つるべーさんによるIBISMLの振り返りもあって大変面白そうなので、IBISのワークショップに参加することにした
  • はこだて未来大の松原先生とちくわと共同でやっている研究がしっかり査読付きポスターに採録されてうれしい

  • 最近自分の研究よりも周りでやっている研究の方がおもしろくて、そっちの手伝いをしたい気持ちが強い
  • その後は月1ぐらいでやっている社内向け研究会でミジーさんにIaCのこれまでとこれから、さらにはご自身の研究につついても講義頂いた
  • 最高やで

  • 鷲北さん、ちょっと雑談してください、ってお願いした

  • 夜はコロナもあって、4人の歓迎会をやった
  • 取締役の前田さんもいらっしゃってあれこれ盛り上がった
  • 良い話も聴けたので気分がよかった
  • ペパボとの共同研究会をやった
  • 今日はそれぞれの研究計画やディスカッションが盛り上がった
  • なめシス〜〜〜〜
  • 研究所にnotionが導入されたのであれこれさわっていた
  • めちゃ楽しい〜〜〜
  • 研究活動にはかなりあってるきがする

2020-10-27 ラジオしたり共同研究MTGしたり査読を終わらしたりした

研究日誌 研究会 会議
  • ラジオで先週の国際会議の振り返りや、同僚の菊地さんのめちゃ良いスライドの紹介をした

  • いい感じでまとめて説明できた気がするのでぜひきいてみてください
  • 次回のInfraStudyは僕が喋りますので、ぜひ企業における研究がいまいちよくイメージできないとか解像度が低いという方に聴いていただけると幸いです

forkwell.connpass.com

  • メタ査読を書いた
  • 招待論文とかwsa県に向けて改めて整理したい研究もでてきたので、それをぼちぼちやっていく
  • 九大との共同研究のメールシステムについて議論していた
  • 情報をどのように収集して解析するかという話を色々なアプローチで議論していた
  • そういえば今日は久しぶりにpmilterの話をした

  • うづらさんのおもしろい研究を聴いてテンションが上がった
  • これまでうづらさんと共著でやってきた研究は良い評価が多くいつもお世話になっているので、僕もなにかしらお手伝いできればいいなと思った
  • 今日は四半期報告会で田中さんから説得力のある話が聴けてやる気がまたバーンと出てきたので頑張ろう
  • 明日は久々に福岡オフィスにいってご飯を食べる
  • そのまえにつるべーさんと研究の作戦会議を行う

2020-10-24 IEEE SERVICE (CLOUD) 2020 5日目（最終日）聴講と国際会議が終わっての感想

国際会議 研究日誌
  • 今日はIEEE SERVICE最終日でCLOUDアプリの話やセキュリティの話、最後はタスクスケジューリングの話などを聴いている
  • 全体を聴講しての感想を最後にまとめた

Session CLD 25: SHORT– Cloud Applications IV

  • Evaluating Concurrent Executions of Multiple Function-as-a-Service Runtimes with MicroVM

    • Jungae Park (Kookmin University), Hyunjune Kim (Kookmin University), Kyungyong Lee (Kookmin University)
    • サーバーレスコンピューティングとパブリックFunction-as-aService（FaaS）システムは、可用性の高いシステムを簡単に構築できるため、大きな注目を集めている
    • マイクロ仮想マシン（microVM）の最近の進歩により、FaaSシステムの内部アーキテクチャは大幅に変化している
    • 本発表は、多数の同時実行に関するパブリックFaaSシステムの最近の改善に関する徹底的な調査に焦点を当てた
    • microVMの採用により、特にランタイム予約のFaaSの性質が変わり、実験で示されているように、パフォーマンスの低下は前世代のFaaSと比較して大幅に減少
    • FaaSのリソース使用率をさらに高め、セキュリティ上の懸念を軽減するために、AWS Firecracker [1]やGooglegVisor [14]などの複数のFaaSベンダーによってmicroVMが開発されている
      • gVisorもMicroVM？？？
    • さまざまなシナリオでAWSLambdaとGoogleCloud Functionsを徹底的に評価したところ、ユーザーが多数の関数を送信すると、関数ランタイム間の干渉が大幅に減少する
    • パフォーマンスの向上は、重いディスクおよびネットワークI / O機能でより顕著になる
    • さまざまなFaaSシステムを評価した以前の作業[13]、[6]、[9]と比較すると、同時関数呼び出しの数が増えると、同時タスクによるディスクおよびネットワークI / Oのパフォーマンスが大幅に向上
    • たくさんのIOが発生するようなタスクを並行ではしらせるとmicroVMによって、リソース干渉が少なくなるから性能がmicrovm使ってないpodと比べて性能が高いというのを実験から評価したのは面白いけど、gvisorもそうだといわれるとなんで？となった
    • 質疑でやっぱgoogleはmicrovm使ってないとなった
    • となると実験結果からも、microvm使っているawsとそうでないgoogleで、並列度上げたりしてCPU、network disk intensiveなベンチしてるけど、あんまり優位な差がないから、そもそもmicrovmを使っていると並列度が増えたとき強いみたいな考察がおかしいんじゃ…って思えてしまう

  • A Control System for Managing the Flexibility in BPMN Models of Cloud Service Workflows

    • Imen Ben Fraj (Tunis Higher Business School (ESCT)), Yousra BenDaly Hlaoui (Mathematical, Physical and Natural Sciences of Tunis (FST)), Leila Ben Ayed (National School of Computer Science (ENSI))
    • このホワイトペーパーでは、柔軟なワークフローアプリケーションを実行するためのリアルタイムのインタラクティブシステムを紹介
    • 柔軟性メカニズムに基づいているため、実行時間の複雑さの観点からこれらのアプリケーションの実行を容易にする
    • ワークフローは、柔軟性パターンを使用したBPMNモデルを通じて、抽象的なレベルで構築
    • ワークフローのリソース要件の変更を処理するBPMN（ビジネスプロセスモデル表記法）に基づいて、2つの柔軟性パターンを定義
    • 提供されているモデルはワークフローの機能ビューを指定しますが、動作ビューはステートチャート図を使用して記述
    • ステートチャート図は、柔軟性アクションの使用を決定することによってワークフローアプリケーションの実行を制御するリアルタイムシステムを指定するモデルを表す
    • 柔軟なワークフローを実行し、リアルタイムシステムによって制御されるように修正されたBPEL4WSエンジンによってサポート

  • Spark-Tuner: An Elastic Auto-Tuner for Apache Spark Streaming

    • MohammadReza HoseinyFarahabady (The University of Sydney), Javid Taheri (Karlstad University, Sweden), Albert Y. Zomaya (The University of Sydney), Zahir Tari (RMIT University, School of Science, Australia)
    • Sparkは、主に分散環境での計算のスケールアウトを容易にする独自の特性により、大規模企業で最も広く使用されているデータ分析エンジンの1つ
    • このホワイトペーパーでは、共有Sparkプラットフォームで、優先度が異なり、固有の特性が異なる、併置された分析アプリケーション間のリソース競合によるパフォーマンスの低下について説明
    • 各リアルタイムアプリケーションは、特に大規模な販売などの特別なイベントの下で、バーストの強度と期間が異なる、固有のバーストワークロードトラフィックパターンを経験する可能性がある
    • 既存の戦略では、同じマシンで同時に実行されている他のワークロードによって開始される可能性のあるトラフィックスパイクの下で、「レイテンシークリティカル」アプリケーションによって要求されるランタイムサービス品質（QoS）を満たさないことがよくあった
    • 実行時の条件を考慮して、さまざまなアプリケーションに割り当てられたリソース容量を動的に調整する、弾力性のある自動調整アプローチを提案
    • 提出された分析アプリケーションが異なるサービス品質（QoS）要件（遅延制約など）を持ち、コンピューティングリソース間の干渉が重要であると考えられるシナリオを処理するために、分散Sparkプラットフォームでコンピューティングリソースの自動調整戦略を提案
    • 主な設計目標は、遅延が重要なアプリケーションによって適用される目標応答時間の要件を満たすこと
    • 各ストリーミングクエリのエンドツーエンドの応答時間は、トラフィック間隔が長い場合の各タプルの実際の処理時間ではなく、対応するバッファでの待機時間によって決定されるという事実も利用
    • Spark-Turnerは、キューイングの遅延と共有リソース間の干渉によって引き起こされるパフォーマンスの低下をモデル化
    • 独自のLinuxコンテナーで実行されている各Sparkアプリケーションに対して適切な量のCPUキャップを調整できる
    • 不確実ないくつかのトラフィックパターンにわたる広範な実験設定を通じて、大規模なSparkクラスターで広く使用されている2つのリソース割り当てヒューリスティックと比較
    • 実験結果によると、Spark-Tunerを使用すると、Sparkエンジンは、クラスター全体で同じレベルのCPUスループットを維持しながら、高優先度のアプリケーションのp-99レイテンシーを高速トラフィック期間中に43％削減
    • こういう高付加時の競合・干渉状態とその原因と特徴をモデル化して動的にリソース割当をコントロールするという研究が増えてきているなぁ（レンサバでよくやっていたやつ）

Session CLD 26: Cloud Security

  • Forward Secure Public Key Encryption with Keyword Search for Cloud-Assisted IoT

    • Hyeongseob Kim (Korea University), Changhee Hahn (Korea University), Junbeom Hur (Korea University)
    • IoTデバイスによって生成される膨大な量のデータのために、それらは最近クラウドによって保存および管理される可能性がある
    • 機密データに関するプライバシーの懸念から、暗号化技術は通常、クラウドで採用されている
    • cIoTアーキテクチャでは、クラウドサーバー（CS）がデータの計算と保存を担当
    • データ送信者（DS）として、複数のIoTデバイスは、センサーを使用してさまざまな情報データを収集し、インターネット経由でCSに送信
    • 次に、データ受信者（DR）である許可ユーザーは、CSからどこからでも収集されたデータにアクセス
    • 医療記録やホームビデオなどの収集されたデータは機密情報である場合があるため、許可されていない人がデータに関する情報を知ることができないように、データをCSに安全に保存する必要がある
    • これを実現するために、DSはデータをCSにアップロードする前にデータを暗号化する
    • 従来の暗号化では、データ検索などの機能が厳しく制限
    • 暗号化されたデータの検索を可能にする単純なアプローチの1つは、ユーザーが検索のたびにCSからすべての暗号化されたデータをダウンロードして復号化すること
    • 多くのIoTデバイスの膨大な量のデータを考慮すると、これには通信と計算のオーバーヘッドが多すぎる
    • クラウド内の複数のデータ送信者の暗号化されたデータを検索できるようにするために、検索可能な暗号化（SE）の1つのバリエーションとして、キーワード検索による公開鍵暗号化（PEKS）が提案
    • 既存のPEKSスキームは、前方プライバシーが欠如しているため、適応型ファイルインクルード攻撃に対して脆弱
      • 前方秘匿性みたいな話とファイルインクルード攻撃の関連性がよくわからなかった
    • キーワード検索による公開鍵暗号化（PEKS）がBonehらによって最初に提案
    • PEKSでは、複数のデータ送信者が公開鍵を使用して検索可能な暗号文を生成し、データ受信者がその公開鍵に対応する自分の秘密鍵を使用して検索トークンを作成
    • データ受信者は、検索クエリとしてトークンをリモートサーバーに送信
    • リモートサーバーは結果をデータ受信者に返す
    • PEKSは、検索可能な暗号文が複数のデータ送信者によって生成される、電子メールやメッセージングサービスなどのデータ共有およびデータ交換アプリケーションに適している
    • PEKSは、データ送信者である複数のIoTデバイスが検索可能な暗号文を生成するcIoT環境に有効に適用できる
    • PEKSスキームは、適応型ファイルインクルード攻撃に対して脆弱であり、悪意のある攻撃者は、関心のあるキーワードを含む少数のファイルのみを挿入することで、過去の検索クエリに関する情報を知ることができる
      • ファイルインクルード攻撃に脆弱というよりはそういう手法で検索クエリを取得されたら過去にさかのぼって情報が得られるということか
    • 対策として、フォワードプライバシーは、過去の検索クエリが新しく挿入されたファイルの検索に使用されないことを保証
    • データ受信者が以前にキーワードwの検索クエリを作成したとし、その後、データ送信者はキーワードwを含む新しいファイルを更新
    • この場合、CSは、過去の検索クエリと新しく更新されたファイルとの関係を学習できまない
    • いくつかのフォワードセキュア検索可能対称暗号化（FS-SSE）スキームが提案]
    • これらのFS-SSEスキームは、特にIoT環境のようにデータ送信者の数が多い場合、複雑な秘密鍵の配布に悩まされる
    • 最近では、複数のデータ送信者設定に適した格子ベースのフォワードセキュアPEKSスキームを提案
    • 彼らのスキームは、キーを取り消すことによってフォワードプライバシーを実現
    • 公開鍵と秘密鍵のペアが取り消されるまでの期間を展開
    • 一意の期間t中に生成された暗号文は、t中にも作成された検索トークンにのみ一致し、この格子ベースのPEKSは、過去と将来の期間の間でのみ転送プライバシーを保証
    • スキームが非常に短い期間を設定している場合でも、攻撃者は特定の期間にファイルをすばやく挿入できるため、攻撃を成功させることができる
    • データ受信者は、以前の期間の暗号文を検索するために、取り消された秘密鍵を使用して複数の検索トークンを作成する必要がある
    • たとえば、1,000回の検索の後、データ受信者は取り消された秘密鍵を使用して1,000個の検索トークンを作成する必要があるため、検索は実用的ではない
    • 検索のたびに、データレシーバーがデータベース全体をダウンロード、復号化、および再暗号化する必要があり、実際には受け入れられなくなる
    • この問題を解決するために、複数データ送信者設定用のFS-SSEスキームを提案したが、データ受信者に実質的に許容できないストレージオーバーヘッドが発生
    • フォワードセキュリティを実現するためのファイルカウンタテーブルの数は、データ送信者の数とともに大幅に増加
    • FS-SSEスキームでは、データ送信者の数が80を超えると、テーブルのサイズが30GBを超える可能性がある
    • この論文では、クラウド支援IoT環境向けの階層的IDベースの暗号化に基づくフォワードセキュアPEKSスキームを提案
    • 既存のスキームでは、データ送信者の数に比例して増加するストレージオーバーヘッドがデータ受信者に発生しますが、私たちのスキームでは一定のコストしか発生しない
    • AmazonEC2とRaspberriPiを使用した実験的分析では、このスキームは以前のスキームより2〜5倍効率的であることが示されているため、クラウド支援IoT環境の複数のデータ送信者に適している

  • LSH-Based Collaborative Recommendation Method with Privacy-Preservation

    • Jiangmin Xu (Nanjing University of Science and Technology), Xuansong Li (Nanjing University of Science and Technology), Hao Wang (Norwegian University of Science and Technology), Hong-Ning Dai (Macau University of Science and Technology), Shunmei Meng (Nanjing University of Science and Technology)
    • 協調フィルタリング（CF）は、情報過多に対処するためのパーソナライズされたレコメンデーションシステムで最も成功し広く使用されているテクノロジーの1つ
    • 従来のCF推奨アルゴリズムでは、大規模な動作データを処理するときに、時間コストが高くなり、リアルタイムパフォーマンスが低下
    • 従来のCFアルゴリズムは、大規模で高次元でまばらなユーザー評価データを処理するのに効果的ではなく、レコメンデーションアルゴリズムの適応性とリアルタイムのパフォーマンスが深刻な影響を受け、レコメンデーションの結果にさらに影響を与える
    • 研究[14-16]では、著者はクラスタリング手法を推奨モデルに適用して、近傍検索の時間を短縮し、予測精度を向上させている
    • クラスタリング分析は多次元クラスタリングカテゴリーなどの問題に直面しており、測定基準を管理することは困難
    • 因数分解手法は、スパース性の問題に対処するための効果的なツールであることが証明されているが、大規模または高次元のデータマトリックスを処理する場合、従来の因数分解手法はそれほど効果的ではなく、推奨効率は理想的ではない
    • 大規模な評価データを処理する場合、従来のCFアルゴリズムは、スケーラビリティが弱い大量のオフライン計算を引き起こし、推奨効率に深刻な影響を及ぼす
    • ほとんどの共同推奨方法は、プライバシー保護を無視しながら、主に推奨精度の向上に焦点を合わせている
      • どんなプライバシーだろ？
    • 過去の評価データには、ユーザーのプライバシー情報が含まれている
    • これらの情報は、違法に使用されたり、転売されたりする可能性がある
    • ほとんどの既存のCFレコメンデーションシステムはプライバシー保護をほとんど考慮していないため、ユーザーのプライバシー開示のリスクが大幅に高まり、ユーザーの熱意が低下する
    • 従来のCF推奨アルゴリズムの推奨結果は単一であることが多く、ユーザーの多様な要件を満たすことができない
    • これらの問題を解決するために、この論文では、ローカルセンシティブハッシュ（LSH）と因数分解技術に基づくプライバシーを意識した協調的推奨アルゴリズムを提案
    • この論文は、LSHと行列因数分解技術に基づく改良された協調的推奨アルゴリズムを提案
    • 高次元でまばらなユーザー評価データに効果的に適応
    • LSH手法は、近傍探索を高速化するのに効果的で、LSHベースのマッピング手法により、元の評価データではなくハッシュ値が近傍検索に使用されるため、ユーザーの機密情報が保持される
    • 欠落している評価データを予測するために行列因数分解手法が適用され、改良された近隣ベースのCFモデルに基づいて予測が行われる
    • LSHを採用して、ターゲットユーザーの最近傍セットを決定
    • ターゲットユーザーの最近傍行列を生成
    • 行列因数分解手法は、欠落している評価を予測するために隣接行列に適用
    • 次に予測された評価に基づいて最近傍を決定
    • 最後に、ターゲットユーザーの予測は、近隣ベースのCF推奨モデルに基づいて行われ、ターゲットユーザーに対して多様な推奨が行われる
    • 実験結果は、提案されたアルゴリズムが、ユーザーのプライバシーを保護することを前提として、推奨の効率を効果的に改善できることを示している

Session CLD 28: Cloud Task Scheduling

  • RSDS: Getting System Call Whitelist for Container through Dynamic and Static Analysis600

    • Xuhao Wang (Peking University), Qingni Shen (Peking University), Wu Luo (Peking University), Pengfei Wu (Peking University)
    • コンテナはホストと同じカーネルを共有しており、コンテナ内のアプリケーションはホスト上の通常のプロセスのようにホストカーネルのシステムコールを行う
    • seccompはLinuxカーネルのセキュリティ機構で、これを利用して特定のシステムコールをプログラムで実行させないようにすることができる
    • Dockerはバージョン1.10からseccompの仕組みをサポートし始め、デフォルトでは300以上あるシステムコールのうち約44個のシステムコールを無効化している
    • Dockerは幅広いアプリケーションの互換性を提供することを考慮に入れている
    • 実行を許可されている実行に不要なシステムコールがまだ多く、危殆化したコンテナによるシステムコールの悪用は、ホストカーネルのセキュリティ脆弱性の引き金になる可能性がある
    • Dockerは特定のコンテナに必要なシステムコールを取得する方法を提供していない
    • 準備段階で docker デーモンによって行われたすべてのシステムコールがコンテナのシステムコールのホワイトリストに追加される必要がない
    • さらに、docker イメージ内のいくつかの実行ファイルはコンテナの実行中には実行されないため、静的解析の段階ではこれらの実行ファイルを除外する
    • 本論文では、動的解析と静的解析を組み合わせたRSDSを提案します。実験の結果、私たちのソリューションは、Ubuntu 16.04ホストOSを搭載したx86-64 PC上のデフォルト構成と比較して、システムコールを69.27%-85.89%削減でき、これらのコンテナの機能性に影響を与えないことを示している
    • RSDSは、コンテナを起動するために必要なシステムコールと、動的解析によってコンテナを実行するために必要な実行ファイルを取得
    • 多数のアプリケーションのアセンブリコードを解析した結果、システムコールを呼び出す際には、主に3種類のアセンブリコードが存在する
    • そこで、RSDSの静的解析フェーズでは、動的解析フェーズで得られた実行ファイルのアセンブリコードを解析することで、実行時にコンテナが必要とするシステムコールを取得
    • 最終的にRSDSは動的解析で得られたシステムコールと静的解析で得られたシステムコールをマージしてホワイトリストに追加
    • Docker Hubでよく使われている6つのコンテナを選択してRSDSの効果を検証したところ、dockerのデフォルト構成と比較してシステムコールを69.27%～85.89%削減できる
    • コンテナの可搬性とか意識しないんであれば、コンテナ起動後のシステムコールをトレースしてホワイトリスト作って、次回から使うとかそういうのじゃだめなんかなぁ
      • そういうのであれば作れそう

  • Skedulix: Hybrid Cloud Scheduling for Cost-Efficient Execution of Serverless Applications609

    • Anirban Das (Rensselaer Polytechnic Institute), Andrew Leaf (Rensselaer Polytechnic Institute), Carlos A. Varela (Rensselaer Polytechnic Institute), Stacy Patterson (Rensselaer Polytechnic Institute)
    • プライベート・クラウドはリソースが限られているため、プライベート・クラウドだけでは、すべてのワークロードに対してサービス・レベル・アグリーメント（SLA）の要件を満たすことができない場合がある
    • プライベート・クラウドとパブリック・クラウドの両方の利点を活用するために、アプリケーション・オーナはハイブリッド・クラウドのアプローチを使用
    • アプリケーションの所有者は、例えば、一般的なワークロードを処理するために必要なパフォーマン スを保証したプライベート・クラウドを維持
    • ワークロードがプライベート・クラウドの容量を超えて増加した場合、サービス品質を維持するために、ジョブの一部または一部をパブリック・クラウドにディスパッチし、発生したコストで処理することができる
    • このアプローチにより、アプリケーション・オーナーはプライベート・クラウドのプライバシー、パフォーマンス、コスト面でのメリットを享受できる一方で、ピーク時のワークロードのためにハードウェアを維持する必要がなくなる
    • そこで課題となるのは、どのジョブをプライベート・クラウドで実行し、どのジョブをパブリック・クラウドで実行するかを決定して、ハイパフォーマンスと低コストの両方を実現すること
    • 本研究では、パブリック・プライベートハイブリッドクラウド上で多機能サーバレスアプリケーションをスケジューリングするためのフレームワークを提案
    • サーバレスジョブの集合をバッチとして入力し、ハイブリッドプラットフォーム上で機能実行をスケジューリングすることで、パブリッククラウドの利用コストを最小限に抑えつつ、指定された期限までにすべてのジョブを完了させることを目的とする
    • このスケジューリング問題はNP-Hardであるため、我々は、関数実行時間とネットワーク遅延の予測モデルを用いて、関数実行の順序と配置を動的に決定する貪欲なアルゴリズムを提案
    • このスケジューリングと割り当て問題の形式化は、Mixed Integer Linear Program (MILP)として実現され、NP-hardであることが証明されている
    • 本研究では、コスト最小化のために2つのバリエーションを持つ貪欲なアプローチを提案
    • (i) パブリッククラウドでの実行コストを最小化するために、ハイブリッドクラウドにおける多機能アプリケーションのスケジューリングのためのフレームワークを定式化する
    • (ii) ハイブリッドクラウドにおける各機能の順序と配置を動的に決定する貪欲なアルゴリズムを提案
    • (iii) スケジューリングのためには、関数の実行時間、データ転送時間、中間データサイズの正確なモデルが必要であり、パブリッククラウドのAWS LambdaとプライベートクラウドのOpenFaaSを用いて得られたトレーニングデータから、アプリケーション固有のモデルを生成する方法を示す
    • (iv) このハイブリッドクラウドプラットフォーム上で動作する我々のフレームワークのプロトタイプ実装を提示
    • (v) 次に、計算負荷とI/O負荷が混在する3つの典型的な例を用いて、このプロトタイプ上での我々のアルゴリズムの性能を評価
    • その結果、我々のフレームワークは、プライベートクラウドのみを使用するアプローチの40.5%のコストで、プライベートクラウドのみを使用するアプローチの最大1.92倍のバッチ処理の高速化を達成できる
    • 本研究では、AWS LambdaとOpenFaaSを用いて、パブリッククラウドとプライベートクラウドにそれぞれプロトタイプを実装した
    • 計算とI/Oを多用するサーバレスアプリケーションを組み合わせたライブ実験でプロトタイプを評価
    • 我々のフレームワークは、プライベートクラウドのみを利用した場合の40.5%のコストで、プライベートクラウドのみを利用した場合の最大1.92倍のバッチ処理の高速化を達成できることを示した
    • 私たちの結果は、私たちのフレームワークが、マトリックス処理アプリケーションで1.92倍、ビデオ処理アプリケーションで1.65倍の高速化を、それぞれプライベートクラウドのみを使用するアプローチよりも40.5％、パブリッククラウドのみを使用するアプローチよりも39.5％のコストで達成できることを示した

  • TOPOSCH: Latency-Aware Scheduling Based on Critical Path Analysis on Shared YARN Clusters619

    • Chunming Hu (Beihang University), Jianyong Zhu (Beihang University), Renyu Yang (University of Leeds), Hao Peng (Beihang University), Tianyu Wo (Beihang University), Shiqing Xue (Beihang University), Xiaoqiang Yu (Beihang University), Jie Xu (University of Leeds), Rajiv Ranjan (Newcastle University)
    • リソース利用率とアプリケーションQoSのバランスをとることは、クラスタリソース管理における長年の研究課題
    • ビッグデータ YARN クラスタでは、バッチ処理ジョブやストリーミングジョブ、Web サービスやデータベースサービスなどの長時間稼働するアプリケーションを含む共有リソース上の多様なワークロードを共同スケジューリングする必要がある
    • 現在のリソース管理者は、アプリケーションやジョブ間のリソース割り当てのみを担当していますが、対話型アプリケーションやレイテンシに敏感なアプリケーションのランタイムQoS要件を全く認識していない
    • モノリシックアプリケーションのQoSを最大化するための先行研究は、主にマイクロサービスによって駆動される分散アプリケーションの特徴である、固有の依存性やコンポーネントの時間的・空間的な性能変動を無視している
    • 本論文では、バッチタスクとマイクロサービスを適応的に協調配置するための新しいリソース管理システムTOPOSCHを提案
    • TOPOSCHは、マイクロサービス間のすべてのリクエストの完全なフットプリントを時間的に追跡
    • 遅延グラフは定期的に生成され、エンドツーエンドの遅延クリティカルパス解析により、犠牲となるマイクロサービスを特定
    • 次に、マイクロサービスごと、ノードごとのリスク評価を利用して、YARNのキャパシティスケジューラに見えるリソースを評価
    • バッチタスクの実行を適応的にスロットルや遅延させることで、ノードの過飽和によるレイテンシの増加を回避
    • TOPOSCHはYARNと統合されており、YARNのデフォルトのキャパシティスケジューリングと比較して、DLRAのレイテンシを最大39.8%削減できることを実験で示した

国際会議が終わっての感想

  • 今日でIEEE SERVICEが終わった
  • IEEE CLOUD全体を通して、やっぱり、システムにおけるワークロードの複雑さから、ときたい問題について特徴や関連するパラメータを抽出したりスコープを絞ってからその事象をモデル化したり定式化、NP困難からくる貪欲法や近似、などのような解き方で解いてみてそれがどれぐらい効果があったかを示すような話題がすごく多かった
  • 問題自体はずっと僕が昔から着目してきた得意なところで大学時代からやってきたテーマだけど、それが改めてML/AIやそれを取り巻くツール、コンピュータリソースの進化に伴って、ML/AIを使ったり新しいアルゴリズムやモデル化を利用して数学的・統計学的に解くというのは随分とトレンドになってきているなと思えた
  • さらには、エッジの文脈を含む研究も多くて、その場合はDCをはじめ、ハードも含めたワークロードの複雑さ定式化するというアプローチは同様にあって、解き方の細かい差分はあるものの、複雑なシステムにおける複雑なワークロードを経験的に解決できないので、そこで問題と思われる事象を抽出してモデル化し、それを既存のMLの手段やアルゴリズム、それらを組み合わせる新しいアルゴリズムを提案して問題を解く、というストーリーは同じように思えた
  • この辺をやっていく必要があるなと改めて思った
  • といいつつ、こういう研究って昔からすごいされているけれど、実際に作られているシステムやサービスを考えると、動的に構成されているのはほんの一部で、実際にリアルで使えるというところを考えたときのギャップについてはまだあ違和感があって、そこはもう少し近くの同僚と議論しながら考えていきたい

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は僕しゃべるのでぜひいらしてください！

2020-10-22 IEEE SERVICES(CLOUD) 2020 二日目研究速報と研究会

国際会議 研究会 研究日誌
  • 今日はIEEE SERVICEに遅刻しながらつぼのまとめてくれてる最高メモを読んで発表予稿を読んでいた（以下もそのメモを大いに参考にさせていただいている） conferences.computer.org
  • Session CLD 12: Cloud Management I
    • Auto-Scaling Cloud-Based Memory-Intensive Applications229
      • Joe Novak (University of Utah), Sneha Kasera (University of Utah), Ryan Stutsman (University of Utah)
      • 値に依存した単純なスケーリング・ポリシーを提供しているが、テナントにワークロードに関する事前知識を強制する
      • しきい値を必要としない、メモリ負荷の高いワークロードのスケーリングのための新しい方法の提案
      • メモリを多用するアプリケーションの自然なしきい値を決定するために、アプリケーションのミスレシオカーブ（MRC）を自動的に分析し、それを双曲線としてモデル化
            1. Mattson et al., “Evaluation techniques for storage hierarchies,” IBM Systems journal, vol. 9, no. 2, pp. 78–117, 1970.
      • 自然閾値の直感は、システムモデルから自然に発生する現象を使用すること
          1. Novak and S. K. Kasera, “Auto-tuning active queue management,”in 2017 9th Int’l Conf on Communication Systems and Networks(COMSNETS), June 2017.
      • 曲線の「自然なしきい値」を特定し、テナントが選択するであろう類似の動作ポイントにマッピング
      • アプリケーションから抽出されたサンプルMRC上に二次曲線（図1の「ハイパーボラ」）をマッピングします。曲線のニー（「頂点」）は、メモリを追加することでページフォルトが減少して改善される自然なポイント -> あまりにも保守的
        • MRC の尾部をより正確にモデル化し、膝の右側にある別の自然なしきい値、すなわち、曲線と直腸腰部（LR）の交点を選択、我々の直観では、メモリスケーリングポリシーは曲線が平坦化するポイントで動作すべきであり、これはLRが識別するポイント
            1. Gonzalez-Horta et al., “Mathematical model for the optimal utilization percentile in m/m/1 systems: A contribution about knees in performance curves,” arXiv preprint arXiv:1106.2380, 2011.
      • メモリを多用するアプリケーションをスケーリングする際の重大な問題は、新しくプロビジョニングされたVMの起動に数十秒から数分かかることで、新しい VM の準備が整うまでの暫定的なリソースとして、サーバレス・クラウド・ファンクショ ンを使用することで、VM の起動時間を緩和
      • メモリを多用するアプリケーションをクラウドでリアクティブにスケーリングし、ワークロードの変化に事前に指定したしきい値なしで自動的に適応させるリアルタイム手法から抽出されたモデルに対して自然なしきい値を抽出するアプローチ
      • アプリケーションのMRCを双曲線としてモデル化して識別し、キャッシュミスやページフォルトがコストのかかるアプリケーションに適した自然なしきい値として、双曲線とその突起の交点を計算
      • メモリを多用するアプリケーションを水平・垂直にスケーリングして評価し、スループットを1.5倍に向上させ、キューイング遅延を2倍に低減
      • メモリの適応的なオートスケーリング、完全に僕の分野、ただMRCを双極性としてモデル化してその差分をみるととなぜいけるのかみたいなのはやってみたらいけた感があるので、とはいえこういうふうに試すのも大事になってくるんだろうな
    • ImageJockey: A Framework for Container Performance Engineering238
      • Takeshi Yoshimura (IBM Research - Tokyo), Rina Nakazawa (IBM Research - Tokyo), Tatsuhiro Chiba (IBM Research - Tokyo)
      • 異なるバージョンの異なる OS ベースのイメージでは、その中で実行される特定のアプリケーションのパフォーマンスが異なることを検証してきた
      • さらに、コンテナイメージのバージョンを変えずにマイナーアップデートを行った場合も、アプリケーションのパフォーマンスに影響を与える
      • アプリケーションのパフォーマンスを理解するためには、マイナーチェンジの継続的な監視とともに、異なるコンテナイメージにおけるパフォーマンスへの影響を判断することが重要
      • 既存のパフォーマンステストフレームワークでは、コンテナイメージのパフォーマンスリグレッションを解析するために必要な機能が実装されていないため、本論文では、広範囲のコンテナイメージのパフォーマンスを継続的に評価するための独自のテストフレームワークであるImageJockeyを紹介
      • ImageJockeyはツールとして便利そう
    • Flexible and Efficient Partial Migration of Split-Memory VMs248
      • Takahiro Kashiwagi (Kyushu Institute of Technology), Kenichi Kourai (Kyushu Institute of Technology)
      • 大規模なメモリを持つVMを小さなVMフラグメントに分割し、複数の小さなホスト、つまり1つのメインホストと1つ以上のサブホストに転送するものである
      • 仮想CPUやデバイスなどのVMコアの状態をメインホストに転送し、アクセスされそうなVMのメモリをメインホストに転送
      • 残りのメモリはサブホストに転送されｍスプリットマイグレーション後、メインホストとサブホスト間でリモートページングを行うことで、VMはこれらのホスト間で動作
      • 従来のマイグレーションを用いてスプリットメモリVMをマイグレーションする場合、一部のホストのみを保守する場合でも、常にVM全体をマイグレーションする必要がある
      • VMの断片を1つのソースホストに集めるため、リモートページングが頻繁に発生し、マイグレーションの性能が大きく低下する
      • 本論文では、柔軟で効率的な分割メモリVMの部分移行を提案
      • 部分移行は、分割メモリVMの一部を必要なときだけソースホストからデスティネーションホストに直接移行させる
      • サブストマイグレーション、マージマイグレーション、スプリットマイグレーション、スプリット/マージマイグレーションの4つのタイプに分類され、サブストマイグレーションは、メインホストまたはサブホスト内のVMフラグメントを新しいホストに転送し、スプリットメモリVMを実行しているホストのうち、1つのホストのみを置換
      • スプリットメモリVMを実行しているホストの一部のみを維持
      • マージマイグレーションは、スプリットメモリVMを実行しているホスト内のVMフラグメントをリモートページングなしで1つのホストに転送
      • スプリットメモリVMの効率的な統合を可能にし、リモートページングのオーバーヘッドを排除
      • メモリ分割のは面白いけど性能に耐えるのかなぁ、この分割して必要／不必要なものを起動させたりする仕組みにピッタリ合うワークロードだと現実的だけど、クラウド基盤として何が載るか分かりにくいケースに適用するのはすごく難しそう。逆にメモリアクセスをコントロールできるアプリの提案までやれたら、そのケースでは有用そう
  • Industrial Big Data: Opportunities and Challenges
    • ビッグデータ技術とAI技術について言いたいのは AI技術とビッグデータは 私たちのチームダスターだけでなく 他の多くの産業にも応用できるという話
    • AIとかのソルバーがアルゴリズムとして理解できて上手くいく理由がわかれば良いというのはあるのだけど、実際それはどれぐらい有効なのだろうなぁと最近思うようにもなった
    • 具体的には色々試していい結果がでるというのも、数をこなしていくうちに近似的に解を導くのに似ている気もしてきて、それはそれで良いアプローチとも思える
    • 国際会議聞くとこの辺のAIとデータについてすごく積極的なので、ここは日本のインターネットと運用技術関連の研究の雰囲気と差を感じる
    • 僕もそうなのか国民性なのかはよくわからないけど、ブラックボックス的な説明のつかないソルバーを試して良い結果を得るという研究の仕方が苦手なのかもしれないので、国際会議を聞くたびにそこをなんとか改めてやっていきたいなと思う
    • 機械学習の説明性の研究も随分進んでいるし、我々の分野としては上手くいくのを色々試すことをまずやろうと思うし、それを国際会議では思い返させてもらえる

  • Session CLD 14: Serverless Computing and Containers

    • On the Use of Containers in High Performance Computing Environments284
      • Subil Abraham (Virginia Tech), Arnab K. Paul (Virginia Tech), Redwan Ibne Seraj Khan (Virginia Tech), Ali R. Butt (Virginia Tech)
      • データ分析とディープラーニング（DL）/機械学習（ML）アプリケーションは、コンテナ化の恩恵を特に受けており、このようなデータ分析がハイパフォーマンスコンピューティング（HPC）で採用されているため、HPCでのコンテナーサポートの必要性が最も重要になっているがコンテナはHPCで重大なパフォーマンスとI / Oの課題に直面している
      • HPCコンテナーが存在する一方で、特に重要なHPC I / Oスループットへの影響の観点からソリューションが徹底的に調査されていない
      • このペーパーでは、HPC環境における最先端の代表的なコンテナーソリューション（Docker、Podman、Singularity、およびCharliecloud）の経験的分析を提供
      • コンテナがLustreなどのHPC並列ファイルシステムとどのように相互作用するかについても説明
      • HPC環境のすべてのノードに展開され、ノードとストレージシステムからCPU、メモリ、ネットワーク、およびファイルI / O統計をキャプチャする分析フレームワークの設計を示す
      • Charliecloudは、コンテナの起動時間に関して他のコンテナソリューションよりも優れているが、SingularityとCharliecloudはI / Oスループットで同等
      • Charliecloudは基盤となるLustreファイルシステムでほとんどのメタデータとI / O操作を呼び出すため、これにはコストがかかる
      • このようなトレードオフと最適化の機会を特定することで、HPCコンテナーのパフォーマンスと、それらにますます依存するML / DLアプリケーションを強化できる
      • ここでいうHPCとWebとかクラウドのコンテナシステムってどれぐらい基本設計に差があるのかなぁ
      • コンテナの起動時間の差は結局アプリの起動時間からみると少ないのでそのへんどうするのか
      • HPCの文脈においては起動時間早いけど起動後性能が遅いCharliecloudや全体的に性能が遅めのDockerやPadmanは適切じゃなくて、いまのｔこおろSingularityが一番適しているというベンチマーク結果になった
      • HPCのワークロードは非常にIOが重く、通常のコンテナを使ったクラウドコンピューティングのようなケースでは典型的ではないが、HPPは通常、単一の単語やグループのようなもの
      • クラウドとは対照的に非常にローカライズされたスーパーコンピュータ上の単一の重いワークロード、または非常に並列化された重いワークロードのようなもの
      • 特に lustre を使用した場合のようなものでIO が重いアプリケーションを使用している場合、コンテナが IO をボトルネックになる
      • HPCセンターで多くのユーザーが同じ限られた帯域幅を使用しようとしている場合、チャーリークラウドのようなものが多くの帯域幅を占有してしまう可能性がある

    • Lambdata: Optimizing Serverless Computing by Making Data Intents Explicit294

      • Yang Tang (Columbia University), Junfeng Yang (Columbia University)
      • 既存のサーバーレスコンピューティングシステムには、大幅なスピードアップを享受できないという重要な制限がある
      • 各クラウド関数をブラックボックスとして扱い、関数がどのデータを読み書きするかを認識しないため、データのキャッシュや関数の配置など、潜在的に巨大な最適化の機会を逃す
      • 提案するLambdataは、開発者がデータの読み取りと書き込みの両方を含むクラウド関数のデータインテントを宣言できる新しいサーバーレスコンピューティングシステム
      • データの意図が明示されると、Lambdataはさまざまな最適化を実行して、データをローカルにキャッシュしたり、コードとデータの局所性に基づいて関数をスケジュールしたりして速度を向上
      • 複数のinvokerで処理するのではなく、シーケンシャルに完結できる処理は単一のinvokerで処理する
      • こういうデータ局所性をサーバレス側が見るか否か、という最適化がどの領域の誰による作業と捉えるべきかというのが気になった（経験的に使ってきてるとなんとなく説明できそうではある）
      • 評価では、実際のワークロードのターンアラウンドタイムで平均1.51倍のスピードアップを達成し、金銭的コストを16.5％削減

    • Serverless Computing: Behind the Scenes of Major Platforms304

      • Daniel Kelly (National University of Ireland Galway), Frank Glavin (National University of Ireland Galway), Enda Barrett (National University of Ireland Galway)
      • AWS Lambda、Google Cloud Functions、Microsoft Azure Functions、IBMCloudFunctionsを対象に「コールドスタート」という一般的な問題へのアプローチにおいて、これらのプラットフォームを観察および対比し、サーバーレス機能が実行される基盤となるアーキテクチャを明らかにする手段を考案
      • 1ヶ月間プラットフォームの負荷による干渉の影響を調査
      • AWSには、スケーリングとコールドスタートの問題に対処するための設計上の選択であると理論付けている関数コンテナーの使用に対する異なるアプローチがある
      • メモリ割り当ては、これらのプラットフォームでのサーバーレス機能のパフォーマンスに大きく影響するため、アプリケーションを開発する際には真剣に検討する必要がある
      • 機能のパフォーマンスについて1か月にわたる観察を行い、機能ベンチマークの大規模なデータセットを作成し、日中のプラットフォームへの負荷の増加とプラットフォームのメンテナンスによる負担による潜在的な干渉の影響を明らかにた
      • このペーパーの貢献は、サーバーレスプラットフォームのしばしば神秘的な内部の仕組みを明らかにするのに役立つ
      • サーバーレスプラットフォームは、開発者をバックエンドからできるだけ遠ざけるだけでなく、暗闇の中で維持することにビジネスモデルを基づいている
      • 4つの最大のプラットフォームでのサーバーレス機能の実行に関する多くのデータを含むデータセットを作成し、アプリケーションのベンチマーク、機械学習またはサイバーセキュリティによる最適化に関する将来の作業に役立つ

  • どの発表も大変おもしろかった

  • 今日はペパ研でも研究会
  • みんな自分の研究の方向性がまとまってきている
  • 研究テーマを考えるの難しい〜〜〜
  • IEEE SERVICEに参加していた、やっぱりインターネット技術の課題に対して、MLやAIを利用して、細かい説明性をおいておいても（これはこれでML業界が必死に色々やっている）試してどういう結果が得られて、考察はどこまでできるかというフェーズであるなと思えた
  • データとML/AIから既存のものよりも良い効果が出たときに説明性の問題だけでその価値を見失うのはもったいないという価値観
  • インターネット系とかだと説明性を問うことが多いけど、やっぱり他の分野であれば、新しい方法で試したらこんなのが発見できた、というだけで価値ある研究にもなるので、そういう意味では工学であるのでそういうアプローチで研究することも大事だと改めて思いかえされた
  • 同僚にもつるべーさんというそのあたりの専門家がいるのでしっかり強調してやっていきたい

2020-10-21 今日からみっちりIEEE SERVICES 2020に参加している

研究日誌 国際会議
  • IEEE SERVICESの中で今日はIEEE CLOUD（CORE rank B）に参加していた
  • 色々面白発表が多くて、特にクラウドやエッジの分散環境にどうインスタンスやコンテナを、利用者の支店や事業のしてんから、性能やコスト、リソース配分などを考慮して最適に配置・移動するかという最適化問題に落とし込む研究が目立った
  • こういった問題意識をソルバーとして機械学習や深層学習で対処していくのがトレンドになりつつあって、つるべーさんと協力してい色々考えると面白い研究ができそうだなと思えた
  • クラウド基盤のリソースの変化から複雑なワークロードにおける異常検知をするというのも深層学習を使ったりしたいた
  • 予定をいれるとかなりきつきつな予定になったので、無理せずのんびり聴いていこうと思う

  • 今日聴いていた研究

  • Session CLD 8: Cloud Applications II

    • Toward Efficient Indoor Positioning for Cloud Services in SIoT124
    • VMatch: A Matching Theory Based VDC Reconfiguration Strategy133
    • Deep Unsupervised Workload Sequence Anomaly Detection with Fusion of Spatial and Temporal Features in the Cloud141

  • Session CLD 9: Cloud Performance Evaluation

    • Serverless Elastic Exploration of Unbalanced Algorithms149
    • DEAR: Distributed Evaluation of Alerting Rules158
    • A Content-Wise Data Placement Policy for Improving the Performance of MapReduce-Based Video Processing Applications in Cloud Computing166

  • Session CLD 10: Edge Caching & Computation Offloading

    • Collaborative Computation Offloading for Smart Cities in Mobile Edge Computing176
    • Optimal Application Deployment in Mobile Edge Computing Environment184
    • Proactive Data Caching and Replacement in the Edge Computing Environment193
  • ゆううきさんのアブスト・イントロ翻訳メモがあったので、めちゃ快適にプレゼンを聴けて最高だった

  • 明日のCloud Managementは日本人の方が多めなので少し気になるので楽しみ

  • Session CLD 12: Cloud Management I

    • Auto-Scaling Cloud-Based Memory-Intensive Applications229
      • Joe Novak (University of Utah), Sneha Kasera (University of Utah), Ryan Stutsman (University of Utah)
    • ImageJockey: A Framework for Container Performance Engineering238
      • Takeshi Yoshimura (IBM Research - Tokyo), Rina Nakazawa (IBM Research - Tokyo), Tatsuhiro Chiba (IBM Research - Tokyo)
    • Flexible and Efficient Partial Migration of Split-Memory VMs248
      • Takahiro Kashiwagi (Kyushu Institute of Technology), Kenichi Kourai (Kyushu Institute of Technology)

2020-10-20 IEEE SERVICESに参加しつつ他の会議や登壇準備など

研究日誌 会議
  • 昨日、メインは今日からIEEE SERVICE2020が始まっているのでそれに参加中
  • とはいえ、学会や他のお仕事周りで打ち合わせがあって、中途半端に参加しながらという感じ
  • 今日で一通り会議仕事を終わらせたので、明日からみっちりIEEE SERVICEに参加する
  • 来月の登壇の準備でアブストを久々に書いたけど、なんかそれっぽいのがかけたので楽しみにしておいてほしい
  • 招待論文の準備を軽く
  • 共著のポスターのレビューも簡単にやった