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部 小野 輝也

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. © DMM
    6
    Elastic Beanstalk

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. © DMM
    9
    ECS Fargate

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    キューワーカーはジョブの種類ごとに
    Serviceを立てる(ジョブごとにスケールで
    きる)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  15. © DMM
    15
    1. 検討したこと

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. © DMM
    30
    /health
    OK

    View full-size slide

  31. © DMM
    31
    /health
    ・・・

    View full-size slide

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

    View full-size slide

  33. © DMM
    33
    /health
    OK

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. © DMM
    43
    4. まとめ

    View full-size slide

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

    View full-size slide

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

    View full-size slide