- 今日は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の手段やアルゴリズム、それらを組み合わせる新しいアルゴリズムを提案して問題を解く、というストーリーは同じように思えた
- この辺をやっていく必要があるなと改めて思った
- といいつつ、こういう研究って昔からすごいされているけれど、実際に作られているシステムやサービスを考えると、動的に構成されているのはほんの一部で、実際にリアルで使えるというところを考えたときのギャップについてはまだあ違和感があって、そこはもう少し近くの同僚と議論しながら考えていきたい
