Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Summer Internship 2020 Final Presentation

アカツキSummer Internship 2020成果報告会資料 (髙津)

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Summer Internship 2020 Final Presentation

  1. 1. 概要 課題:「AWS ECSインフラ環境での新たなAuto Scaling技術検証」 キーワード: ECS Capacity Provider、ECS Service Auto Scaling 成果: • 技術に対する知見 • 基礎的な検証 • ドキュメント作成 • 設定の一部自動化 1
  2. 2. ECS環境とScalingについて • インスタンス : タスク = 1 : 1を想定 • 本番環境 = 数十台程度 • Scaling = 負荷に応じてインスタンスやタ スクが変化 → Scale Out: 増やす / Scale In: 減らす 2
  3. 3. Scaling連携例 (Lambdaスクリプト) • Lambdaスクリプトの役割: インスタンス数を増減に連動したタスク数調整・割り当て 3
  4. 4. Lambda scriptによるScalingの難しさ • Scale In: タスクを安全にdrainingしてインスタンスを終了 • タスクの安全なdraining: ALBからタスクの登録を解除、タスクの停止など… • Service in ECS v.s. ASG in EC2 →別々のサービスに属しているので管理が面倒! 4
  5. 5. 課題 • Lambdaスクリプトのロジックが煩雑 • Scale Out/In処理が入り組んでいる (複数のEventの処理) • 安全にScale In時のタスクdrain&インスタンス終了が大変 「 ECS側でManagedにScalingしてくれる仕組みが欲しい!」 → Capacity Provider 5
  6. 6. Capacity Provider (CP) とは? • 2019/12に新登場 • タスクとインスタンスを紐付け → Service側からScaling • ECS側でインスタンスのScalingを管理 (安全) 6
  7. 7. 運用上の懸念事項 1. 動作の上で最適な設定は何か? 2. Scalingは十分に速いか? 3. 安全にScale Inできるか? 7
  8. 8. 1. Service Auto Scaling 周辺知識 1. Service Auto Scaling (SAS) : タスクのScaling 2. Service Scaling Policy (SSP): ServiceのScalingルール、 CWAをトリガーとして セット 3. CloudWatch Alarm (CWA): CloudWatchで一定の条件 を超えた時に鳴らすア ラーム 8
  9. 9. 1. SAS設定と実験条件 1. SSPタイプ: ターゲット追跡 or ステップスケーリング 1. ターゲット追跡: CWメトリクス値を追跡するSSPを自動で作成 2. ステップスケーリング: 作成済みCWAをトリガーとしてスケーリング 2. Scale Out / In条件: CPUUtilizationやTargetResponseTimeなど 1. CPUUtilization: クラスターやService、ASG等の平均CPU負荷 → 今回はServiceのものを採用 2. TargetResponseTime: ALBがリクエストを送ってからtaskが応答を返すまでの時間 ※ Locustで負荷を掛けながら実験 9
  10. 10. 1. 動作の上で最適な設定は何か? 10 • SSPタイプ: ターゲット追跡 • CPUUtilizationの許容範囲が狭すぎて安定しない • 最初のScale Outが遅い (10分近く掛かる)
  11. 11. 1. 動作の上で最適な設定は何か? 11 • SSPタイプ: ステップスケーリング • Scale Out条件: TargetResponseTimeだと不安定 (API毎に可変)
  12. 12. 2. Capacity ProviderのScaling詳細 1. Auto Scaling Policy (ASP): ASGのScalingルール、 CWAをトリガーとしてセット 2. Capacity Provider Reservation (CPR): serviceのScaling状態を反映し たCWメトリクス 3. CP作成時に自動で: 1. ServiceのCPRが作成 2. CPRのCWAをトリガーとする ASPをASGに付与 12
  13. 13. 2. SP評価クールタイムについての考察 問題点: 1. Scalingが遅い 1. Outが10分も掛かる (クールタイムが長すぎる; cf: 本番環境では5分) 2. inが15分も掛かる 2. クールタイムが短すぎるとScalingしすぎる 解決方法: 1. 各種ログから、各フェーズで掛かる時間を見積もり&設定 2. ASPを自作してScale Inの遅さを解消 13
  14. 14. 2. Scalingスピードは十分か? 14 • 条件: 負荷は手動で段階的に上昇させる; SPクールタイムは180秒に • 35% < CPUUtilization < 100% • 5分程度でScale Out
  15. 15. 3. 安全なScale Inの上で必要な点 15 課題: 1. Scale In時のタスクの急な終了を避けたい (ダウンタイム回避) 2. タスク実行中インスタンスを誤って終了させたくない 解決法: 1. ALBのhealth checkログにstatus_code:5XXが出てこないか確認 2. CP設定:マネージドターミネーション保護をYes 実験条件: 負荷一定下で10タスクからAuto Scale In
  16. 16. 3. 安全にScale Inできるか? 16 • Scale In 条件: CPUUtilization < 35 • health checkエラーは一つも出ず→ 安全なタスク終了が実現
  17. 17. 検証結果まとめ 1. 動作の上で最適な設定はなにか? → ServiceのCPU負荷をトリガーに、SSPタイプをステップス ケーリングに設定 2. Scalingは十分に速いか? → 適切に設定することで実現可能 (Out/In共に5分程度) 3. 安全にScale Inできるか? → 可能 →「十分導入できるレベル!」 17
  18. 18. 成果のまとめ • Capacity Providerについての知見 • Auto Scaling時の挙動の基礎的な検証 • ドキュメント作成 • CloudFormation&ShellScriptによる設定の一部自動化 (PR発行まで) 18
  19. 19. 実運用に向けた課題 現状からの代替で必要なこと: 1. schedule設定 (CPでは現時点で未対応) 2. deployスクリプトの修正 本番運用レベルで必要なこと: 1. 本番条件での負荷試験・評価クールタイムのチューニング 2. 負荷試験中のデプロイ安全性試験 19
  20. 20. 感想 • 楽しかった / 良かった点: • ECSの最先端技術の開拓に貢献できた • なかなか見ない大規模なインフラ構成を肌で実感できた • IaCやデプロイ自動化の知見を得られた • (雑談がてら)サーバサイドの設計の話も教えていただいた • ランチミーティングで盛り上がった • フルリモートでの働き方を体感できた • etc... • もう一歩欲しかった点: • 多くの方にもっと積極的にコンタクトすべきだった 20

×