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から既存のものよりも良い効果が出たときに説明性の問題だけでその価値を見失うのはもったいないという価値観
  • インターネット系とかだと説明性を問うことが多いけど、やっぱり他の分野であれば、新しい方法で試したらこんなのが発見できた、というだけで価値ある研究にもなるので、そういう意味では工学であるのでそういうアプローチで研究することも大事だと改めて思いかえされた
  • 同僚にもつるべーさんというそのあたりの専門家がいるのでしっかり強調してやっていきたい