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

DMM meetup #37

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/