YARN の ResourceManager はクライアントからアプリケーションを受け取って ApplicationMaster を立ち上げる ApplicationsManager と、 ApplicationMaster からリクエストを受けリソースの割り当てを行う Scheduler から構成される。
Hadoop YARN によってアプリケーションにリソースが割り当てられる流れと割り当てられているリソース量の確認 - sambaiz-net
Scheduler
Schedulerには、複数の組織でリソースを共有するクラスタでのスループット最大化を目指す CapacityScheduler や、 各アプリケーションに均等にリソースが割り当てられるようにする FairScheduler などの 実装 があり、 どれを用いるかは yarn.resourcemanager.scheduler.class で設定できる。EMR のデフォルトは CapacityScheduler。
ResourceCalculator
CapacityScheduler はリソース量を比較する ResourceCalculator の設定 を持ち、 これによってリソースの割り当て量が決まるようだ。 デフォルトの DefaultResourceCalculator が メモリのみを見るのに対し、 DominantResourceCalculator はシェアが大きい方のリソースを見るので、 CPU-heavy なタスクの CPU シェアと memory-heavy なタスクのメモリシェアが同量になるようにはたらく。 このリソース割り当て手法を Dominant Resource Fairness (DRF) と呼ぶ。
Dominant Resource Fairness: Fair Allocation of Multiple Resource Types, Ghodsi et al. (2011)
論文では他の手法として Asset Fairness と Competitive Equilibrium from Equal Incomes (CEEI) というものを紹介し次の観点で比較している。
- Sharing incentive: 各ユーザーがリソースを排他的に占有するのではなく共有するべきか
- Strategy-proofness: ユーザーが必要量について嘘をつく利益があるか
- Envy-freeness: 他のユーザーに優先してリソースが割り当てられることがないか
- Pareto efficiency: 他のユーザーへの割り当て量を減らさないと自身の割り当て量を増やせないか
Asset Fairness は CPU やメモリの使用率、帯域幅など異なるリソースを同種のものとして扱い、その和が均等になるようにする手法で、 次のようなケースで User2 は半分のリソースを占有した方が良いことになり Sharing incentive を満たさない。
- 各リソースの総量は (30, 30) でユーザーは 2 人
- User1 のタスクは (1, 3) のリソースが必要 -> 3 タスク分 (6, 18) が割り当てられる
- User2 のタスクは (1, 1) のリソースが必要 -> 12 タスク分 (12, 12) が割り当てられる
CEEI は 初めに均等なリソースを受け取った後、他のユーザーと交渉し Nash bargaining solution によって割り当て量を決定する手法。 次のようなケースで Strategy-proofness を満たさない。
- 各リソースの総量は (100, 100) でユーザーは 2 人
- User1 の Task は (16, 1) のリソースが必要 -> 100/31 = 3.2 タスク分が割り当てられる
- User2 の Task は (1, 2) のリソースが必要 -> 1500/31 = 48.8 タスク分が割り当てられる
- User1 が嘘をついて (16, 8) のリソースが必要だというと 25/6 = 4.2 タスク分が割り当てられるようになる
一方、DRF は全ての観点について満たし、固定サイズの slot 単位での割り当てと比較していずれのリソースも能率的に使われている結果が示されている。