[レポート] LambdaとStepFunctionsを使った新しい負荷試験のカタチ #jawsdays #jd2018_g

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

3/10 に開催されました JAWS DAYS 2018 にて、こちらのセッションが開催されました。聴講してきましたのでレポートしたいと思います。

スピーカー

  • 内海恵介さん
    • 株式会社HAROiD リードエンジニア

LambdaとStepFunctionsを利用したスケーラブルな新しい負荷試験実行環境について。
– Lambdaを利用した攻撃ツール
– StepFunctionsのステートを動的に構築
– Fargateへの対応
スマホ×TV連動等での秒間数万reqにもなる負荷や、放送波による大規模同時接続を安全に、より安心して運用するための事例等も交えてお話させていただきます。

資料

※後日公開が予定されています

レポート

  • スマホ連動のTV番組で使用するバックエンドシステム(投票やミニゲームなど)
  • 1分(以内)だけ急激な負荷が来る

  • 特徴
    • 超短期的なアクセス
    • 瞬間的な同時接続数の増加
    • 5400万世帯に配置されたTVがクライアント端末
    • 障害は放送事故に直結
  • 負荷試験しないと怖い
  • 「負荷試験やってますか?」
    • 会場へのアンケート = JMeterが多い
  • 従来型の負荷試験
    • 面倒なこと : 攻撃サーバの準備、シナリオの準備
    • ベストプラクティスがない
    • 攻撃サーバの稼働率が低くなりがち
      • コスト直結
    • 攻撃サーバがボトルネックになることも
  • 千手観音というツールを作った
    • サーバレス攻撃ツール
    • スケーラブル
    • CI組み込みでのe2eテストにも利用可能
    • APIコールするだけで200万同時接続攻撃が可能
    • シナリオ実行中のユーザーデータ空間
    • 容易にユーザー定義関数を追加出来る
    • Lambda (Apex + golang)

  • 機能拡張 < TVは文字コードがEUC
  • 動的にStepFunctionsを生成
  • Lambda
    • ファイルディスクリプタは(メモリ搭載量に関係なく)1024で固定
    • メモリ上げても攻撃性能は変わりにくい
    • 実行時にメモリサイズを指定できない
  • StepFunctions
    • JSONは1MBが上限
    • 千手観音の場合は 4000Lambdaが上限
    • 自身のステートマシンは削除できない
      • 別のLambdaで消す(上図中のStepFunctionsCleaner)
  • コスト感
    • 20万Request/sec、トータル 1200万リクエストで $1.25
    • めちゃくちゃ安い
  • 5分以上の負荷をかけたいときのFargate
    • DockerFile作るだけ
    • DockerImageのキャッシュが効かないので起動に時間がかかり、負荷の上がるタイミングがばらけてしまう
  • 千手観音は内製したが、Vegeta を使うと似たようなことがすぐ出来る(のではないか)
  • 千手観音はOSS化したい

所感

過去の経験(そんなに多いものではないですが)からすると、「攻撃サーバがボトルネックになる」「パラメータ設定中に攻撃サーバが稼働していないので勿体ない」という話はとても頷けます。それをサーバーレスで解決するのはコンセプトとしては比較的考えつきやすいとは思うものの、コストや効果の程、同期などの問題等、実際に構築し運用している経験からの話ということで、非常に興味深く拝聴させていただきました。