Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

© DMM 今日お話しすること 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

© DMM オンラインサロン事業部のインフラ（一部抜粋） 5 Elastic Beanstalk API サーバ 静的コンテンツ配信 キューワーカー データストア・キャッシュなど エンドユーザ ELB APM ロギング

Slide 6

Slide 6 text

© DMM 6 Elastic Beanstalk

Slide 7

Slide 7 text

© DMM Elastic Beanstalk • インフラを気にすることなくアプリケーションをデプロイできる マネージドサービス • いわゆるPaaS • 実際にはCloudFormationのラッパー • インフラ知識がなくてもすぐにサービスを起動できる • 構成のカスタマイズがやや大変 7

Slide 8

Slide 8 text

© DMM インフラで抱えていた課題 • Beanstalkは抽象化レイヤの下にある実リソースを触りづらい • 細かなカスタマイズは特殊な設定ファイルで管理する必要がある • EC2のスケールアウト・スケールインに時間がかかる • BeanstalkのPlatformで非推奨のMulticontainer Dockerを利用 していた 8 2022 06/30 リタイア

Slide 9

Slide 9 text

© DMM 9 ECS Fargate

Slide 10

Slide 10 text

© DMM ECS Fargate • コンテナオーケストレーションサービス • 移行の決め手 • アプリケーションはDockerコンテナで動いていたため、移行が容易 • スケールイン・スケールアウトが高速 • OSレイヤの管理が不要 • 社内に知見が多い 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

© DMM 移行後 12 データストア・キャッシュなど エンドユーザ ELB APM・ロギング CloudFront 静的コンテンツ配信 ECS Fargate API Service キューワーカー Service * 5 APIとキューワーカーをECS Serviceに変 更 キューワーカーはジョブの種類ごとに Serviceを立てる（ジョブごとにスケールで きる）

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© DMM 移行後 14 ECS Fargate データストア・キャッシュなど エンドユーザ ELB API Service キューワーカー Service CloudFront 静的コンテンツ配信 APM・ロギング APMとログ基盤をNewRelicに 統一 NewRelic Logsはデフォルトで 保持期間が30日なので長期保 存にはS3を併用

Slide 15

Slide 15 text

© DMM 15 1. 検討したこと

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

© DMM 新リソースの作成方針 17 TG1 TG2 Fargate OR new TG1 TG2 (new) Fargate new ELBごと既存環境との分離 ・Elastic Beanstalkのリソースを変更しない ・旧環境をまとめて削除するのも簡単 ・DNSの向き先を変える事でリリース

Slide 18

Slide 18 text

© DMM リリース方針 • API • 当初はRoute53の加重ラウンドロビンを使ってカナリアリリースを予定 • Socket.ioの実装制約で難しいことが分かった • long pollingとWebSocketを併用する時はALBのstickyセッションが必要 • https://socket.io/docs/v4/using-multiple-nodes/ • カナリアリリースではなく、全てのトラフィックを一気に切り替える方針に変更 • stgでのテストが十分にできていたため • キューワーカー • 徐々にECSタスクの割合を増やす 18

Slide 19

Slide 19 text

© DMM 19 2. 移行後に発生 した問題

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

© DMM 24 スパイクへの対処法1 スケーリングポリシーを増 やす

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© DMM 27 スパイクへの対処法2 時刻帯によるスケーリング

Slide 28

Slide 28 text

© DMM 時刻帯によるスケーリング • サービスのピークタイムは21時ちょうど • オンラインサロンにはライブ配信の機能があり、この時刻に ライブ配信するサロンが多い • 20:50にタスク数を前もって増やしておき、深夜帯に減らす • AWSコンソールからだとこの機能は見えない • aws-cliやTerraformで設定 28

Slide 29

Slide 29 text

© DMM 29 スパイクへの対処法3 外型監視のアラートによる スケーリング

Slide 30

Slide 30 text

© DMM 30 /health OK

Slide 31

Slide 31 text

© DMM 31 /health ・・・

Slide 32

Slide 32 text

© DMM 32 Alert Condition Violation Notification channel: webhook $ aws ecs update-service --desired-count N

Slide 33

Slide 33 text

© DMM 33 /health OK

Slide 34

Slide 34 text

© DMM アラートによるスケーリング • NewRelicの外型監視違反をトリガーにしたwebhook通知を利用 • LambdaでECSのタスク数を大きな数に設定する • ECSのスケジューラとは異なる仕組みで強制的にタスク数を増やす • 最後の安全装置 • Lambdaのカスタムランタイムを使ってBashをコンテナで動かしている 34

Slide 35

Slide 35 text

© DMM 2.NewRelic APM PHP Agentによる性能劣化

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

© DMM 37 ECS移行後、レスポンスタイムが 悪化（黄: 99%ile） Elastic Beanstalk （EC2） ECS Fargate

Slide 38

Slide 38 text

© 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

Slide 39

Slide 39 text

© 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 から引用

Slide 40

Slide 40 text

© DMM 効果 40 詳細トレースON 詳細トレースOFF

Slide 41

Slide 41 text

© DMM 41 3. Fargate移行の 効果

Slide 42

Slide 42 text

© DMM インフラ移行の効果 • インフラの構成管理が容易になった • .ebextensionsのALB設定などはTerraformに • キュー遅延の軽減 • キューワーカーの待ち行列が伸び、プッシュ通知などの送信まで時間がかかる 時があった • スケールアウトが高速化したことで緩和された 42

Slide 43

Slide 43 text

© DMM 43 4. まとめ

Slide 44

Slide 44 text

© DMM まとめ • Elastic BeanstalkからECS Fargateへの移行事例を紹介 • ECS Fargateで起こりがちな問題と対処法を紹介 • スケールアウトがスパイクに間に合わずサービスダウン • 対処法: 複数のスケーリング手法を組み合わせる • NewRelic APMで性能が劣化する • 対処法: 状況に応じてトレース詳細をOFFにする 44

Slide 45

Slide 45 text

© DMM 45 SRE部ではAWSが 好きな仲間を募集 しています https://dmm-corp.com/recruit/engineer/8/

Slide 46

Slide 46 text

No content