Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウド環境をFargateに 移行して得た知見

teru0x1
February 22, 2022

クラウド環境をFargateに 移行して得た知見

DMM meetup #37

teru0x1

February 22, 2022
Tweet

More Decks by teru0x1

Other Decks in Technology

Transcript

  1. © DMM © DMM CONFIDENTIAL クラウド環境をFargateに 移行して得た知見 ITインフラ本部 SRE部 小野

    輝也
  2. © DMM 2 小野 輝也 DMM.com ITインフラ本部SRE部 1年目 Twitter: @teru0x1

    https://cha-shu00.hatenablog.com/
  3. © DMM 今日お話しすること 3

  4. © DMM 今日お話しすること 4 Webサービスのインフラを Elastic Beanstalkから ECS Fargateに移行した話

  5. © DMM オンラインサロン事業部のインフラ(一部抜粋) 5 Elastic Beanstalk API サーバ 静的コンテンツ配信 キューワーカー

    データストア・キャッシュなど エンドユーザ ELB APM ロギング
  6. © DMM 6 Elastic Beanstalk

  7. © DMM Elastic Beanstalk • インフラを気にすることなくアプリケーションをデプロイできる マネージドサービス • いわゆるPaaS •

    実際にはCloudFormationのラッパー • インフラ知識がなくてもすぐにサービスを起動できる • 構成のカスタマイズがやや大変 7
  8. © DMM インフラで抱えていた課題 • Beanstalkは抽象化レイヤの下にある実リソースを触りづらい • 細かなカスタマイズは特殊な設定ファイルで管理する必要がある • EC2のスケールアウト・スケールインに時間がかかる •

    BeanstalkのPlatformで非推奨のMulticontainer Dockerを利用 していた 8 2022 06/30 リタイア
  9. © DMM 9 ECS Fargate

  10. © DMM ECS Fargate • コンテナオーケストレーションサービス • 移行の決め手 • アプリケーションはDockerコンテナで動いていたため、移行が容易

    • スケールイン・スケールアウトが高速 • OSレイヤの管理が不要 • 社内に知見が多い 10
  11. © DMM 移行後 11 ECS Fargate データストア・キャッシュなど エンドユーザ ELB APM・ロギング

    API Service キューワーカー Service CloudFront 静的コンテンツ配信 IaC
  12. © DMM 移行後 12 データストア・キャッシュなど エンドユーザ ELB APM・ロギング CloudFront 静的コンテンツ配信

    ECS Fargate API Service キューワーカー Service * 5 APIとキューワーカーをECS Serviceに変 更 キューワーカーはジョブの種類ごとに Serviceを立てる(ジョブごとにスケールで きる)
  13. © DMM 移行後 13 ECS Fargate データストア・キャッシュなど エンドユーザ ELB APM・ロギング

    API Service キューワーカー Service CloudFront 静的コンテンツ配信 フロントエンドの配信を CloudFront+S3に変更
  14. © DMM 移行後 14 ECS Fargate データストア・キャッシュなど エンドユーザ ELB API

    Service キューワーカー Service CloudFront 静的コンテンツ配信 APM・ロギング APMとログ基盤をNewRelicに 統一 NewRelic Logsはデフォルトで 保持期間が30日なので長期保 存にはS3を併用
  15. © DMM 15 1. 検討したこと

  16. © DMM 新リソースの作成方針 16 TG1 TG2 Fargate TG1 TG2 (new)

    Fargate OR new new
  17. © DMM 新リソースの作成方針 17 TG1 TG2 Fargate OR new TG1

    TG2 (new) Fargate new ELBごと既存環境との分離 ・Elastic Beanstalkのリソースを変更しない ・旧環境をまとめて削除するのも簡単 ・DNSの向き先を変える事でリリース
  18. © DMM リリース方針 • API • 当初はRoute53の加重ラウンドロビンを使ってカナリアリリースを予定 • Socket.ioの実装制約で難しいことが分かった •

    long pollingとWebSocketを併用する時はALBのstickyセッションが必要 • https://socket.io/docs/v4/using-multiple-nodes/ • カナリアリリースではなく、全てのトラフィックを一気に切り替える方針に変更 • stgでのテストが十分にできていたため • キューワーカー • 徐々にECSタスクの割合を増やす 18
  19. © DMM 19 2. 移行後に発生 した問題

  20. © DMM 1.過負荷によるサービスダウン

  21. © DMM 過負荷によるサービスダウン 21

  22. © DMM 過負荷によるサービスダウン 22 ALBの受けたリ クエスト数

  23. © DMM 過負荷によるサービスダウン 23 API Serviceの タスク数 アクセス数 急増 セルフヒーリング

    頑張る 手動でタスク数増加
  24. © DMM 24 スパイクへの対処法1 スケーリングポリシーを増 やす

  25. © DMM ECSのスケーリングポリシー • ターゲット追跡スケーリングポリシー • メトリクス値(CPU使用率など)が指定値で一定になるようにタスク数を調整 • 障害発生時はこのポリシーだけ利用(設定内容: CPU使用率が50%を保持)

    • ステップスケーリングポリシー • メトリクス値のターゲットからの超過幅と増減タスク数を指定 • 急激なメトリクス値の増加に対して大きくタスク数を増やせる 25
  26. © DMM ECSのスケーリングポリシー • ターゲット追跡スケーリングポリシー • メトリクス値(CPU使用率など)が指定値で一定になるようにタスク数を調整 • 障害発生時はこのポリシーだけ利用(設定内容: CPU使用率が50%を保持)

    • ステップスケーリングポリシー • メトリクス値のターゲットからの超過幅と増減タスク数を指定 • 急激なメトリクス値の増加に対して大きくタスク数を増やせる 26 2つを併用 通常時: ターゲット追跡利用で 緩やかにタスク増減 スパイク発生時: ステップ利用で大き くタスク数を増やす
  27. © DMM 27 スパイクへの対処法2 時刻帯によるスケーリング

  28. © DMM 時刻帯によるスケーリング • サービスのピークタイムは21時ちょうど • オンラインサロンにはライブ配信の機能があり、この時刻に ライブ配信するサロンが多い • 20:50にタスク数を前もって増やしておき、深夜帯に減らす

    • AWSコンソールからだとこの機能は見えない • aws-cliやTerraformで設定 28
  29. © DMM 29 スパイクへの対処法3 外型監視のアラートによる スケーリング

  30. © DMM 30 /health OK

  31. © DMM 31 /health ・・・

  32. © DMM 32 Alert Condition Violation Notification channel: webhook $

    aws ecs update-service --desired-count N
  33. © DMM 33 /health OK

  34. © DMM アラートによるスケーリング • NewRelicの外型監視違反をトリガーにしたwebhook通知を利用 • LambdaでECSのタスク数を大きな数に設定する • ECSのスケジューラとは異なる仕組みで強制的にタスク数を増やす •

    最後の安全装置 • Lambdaのカスタムランタイムを使ってBashをコンテナで動かしている 34
  35. © DMM 2.NewRelic APM PHP Agentによる性能劣化

  36. © DMM NewRelic APM PHP Agent • PHPアプリケーションのオブザーバビリティを提供 • 継続的なパフォーマンスモニタリングに必須

    36
  37. © DMM 37 ECS移行後、レスポンスタイムが 悪化(黄: 99%ile) Elastic Beanstalk (EC2) ECS

    Fargate
  38. © DMM NewRelic APM PHP Agent • 仮想環境下のクロックソースによってはシステム全体の性能劣化を起こ す •

    関数のトレーシングに使うgettimeofdayシステムコールが原因 • Fargateはクロックソースの変更ができない • Fargateのクロックソースでよく見るもの • kvm: vDSOをサポート。性能劣化を起こさない • xen: vDSOをサポートしない。性能劣化を起こす • vDSO • カーネルの関数をユーザ空間にマッピングする技術 • システムコール呼び出しを普通の関数と同じコストにできる 38 参考: https://discuss.newrelic.com/t/php-agent-on-aws-fargate-performance-issue/124367/5
  39. © DMM 対処法 • 詳細トレースをOFFにする • newrelic.transaction_tracer.detail = 0 を設定

    • Agentが選択したorユーザが指定した特定の関数の詳細トレースだけ取得 • 大雑把なトレースしか追えなくなるので、トレードオフではある • 遅い関数の当たりをつけるだけなら十分 39 https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/#inivar-tt-detail から引用
  40. © DMM 効果 40 詳細トレースON 詳細トレースOFF

  41. © DMM 41 3. Fargate移行の 効果

  42. © DMM インフラ移行の効果 • インフラの構成管理が容易になった • .ebextensionsのALB設定などはTerraformに • キュー遅延の軽減 •

    キューワーカーの待ち行列が伸び、プッシュ通知などの送信まで時間がかかる 時があった • スケールアウトが高速化したことで緩和された 42
  43. © DMM 43 4. まとめ

  44. © DMM まとめ • Elastic BeanstalkからECS Fargateへの移行事例を紹介 • ECS Fargateで起こりがちな問題と対処法を紹介

    • スケールアウトがスパイクに間に合わずサービスダウン • 対処法: 複数のスケーリング手法を組み合わせる • NewRelic APMで性能が劣化する • 対処法: 状況に応じてトレース詳細をOFFにする 44
  45. © DMM 45 SRE部ではAWSが 好きな仲間を募集 しています https://dmm-corp.com/recruit/engineer/8/

  46. None