FargateとLambdaで作る スケーラブルなE2Eテスト実行基盤 Autify CTO 兼 バックエンドエンジニア 松浦 隼人

松浦 隼人 ● Autify CTO 兼 バックエンドエンジニア ● Twitter: dblmkt / GitHub: doublemarket ● 趣味 ○ 翻訳

No content

Autifyとは ● AIを用いたE2Eテスト自動化プラットフォーム ● 2019年3月ベータ版提供開始 ● 2019年10月オフィシャルローンチ

Autifyとは ● E2Eテストはハードルが高い ○ 手でやるのは工数がかかる ■ しかも同じシナリオを何度もやることになる ○ シナリオ作る・書くの大変 ■ レコーダ使って簡単にテストシナリオ作成できます ○ 実行するの大変 ■ 複数のブラウザでががっとテスト回せます ○ 作った後も大変 ■ AIの力で変更検出してシナリオ修正の支援します

デモ 1. シナリオの作成(レコーディング) 2. シナリオを基にしたテストの実行 3. テスト実行結果の閲覧 スライド公開版では省略 https://autify.com/ja からデモリクエスト！

Autifyのインフラにおける技術的チャレンジ ● テストがいつ実行されるかわからない ○ 常にテストを待ち受ける必要 ● テスト実行環境はなるべく顧客ごとに分けたい ○ セキュリティリスク低減 ● テストを高速に実行したい ○ 一般的にE2Eテストは遅い

Autifyインフラ 構成要素 ● Web (Elastic Beanstalk) ○ ユーザがアクセスする ○ シナリオの作成・表示 ● Worker (Elastic Beanstalk) ○ テスト実行の指示 ○ 実行結果データ、スクリーンショットなどの一時保存 ● テスト実行環境 (デバイスファーム) ○ テストを実行するデバイス、ブラウザ

S3 Device farms Web servers Workers For customer A For customer B For customer C Queues Test Test Test Scenario Scenario Scenario 1. Create scenario 2. Upload scenario 4. Receive test case Result Result Result 6. Upload test result 5. Execute test case User in customer A (per customer) (per customer) (shared) Test devices (shared) 7. View test result 3. Enque test case For customer A For customer B For customer C

Autifyインフラ Ver. 1の問題点 ● 顧客ごとにワーカのElastic Beanstalk環境を用意 ○ 顧客ごとの分離を優先 ○ 顧客が増えるとサーバも増える ■ テスト実行回数が増えるとは限らない ■ 顧客増に対してリニアにコストが増えてしまう ■ 毎回作るの辛い(SQSキュー、Elasticacheインスタンスなども作る必要) ○ ebscriptが肥大して管理が辛い

Autifyインフラ Ver. 1の問題点 ● テスト実行が遅い ○ 並列実行できない ■ 高速にスケールできない ○ デバイスファームがUSまたはEUに存在している ■ レイテンシが馬鹿にならない ● ログ、メトリクスなどが取れていない

Autifyインフラ Ver.2 ● テスト実行が遅いことへの対策 ○ 自前のSelenium gridを日本リージョンに構築

Selenium / Selenium grid ● Selenium ○ ブラウザの操作を自動化するためのフレームワーク ○ Thoughtbot社が開発を開始したOSS ● Selenium grid ○ ハブ : テストの割り当て・ルーティングを行うマスタの役割 ○ ノード : テストの実行

S3 Device farms Web servers Workers For customer A For customer B For customer C Queues Test Test Test Scenario Scenario Scenario 1. Create scenario 2. Upload scenario 3. Enque test case 4. Receive test case Result Result Result 6. Upload test result 5. Execute test case User in customer A (per customer) (per customer) (shared) Test devices (shared) 7. View test result For customer A For customer B For customer C Hub Nodes

Autifyインフラ Ver.2 ● Fargateを選択 ○ 既にSelenium Grid Hub/Nodeのコンテナが広く使われている ○ Kubernetesを使うほどの規模ではない ■ が、将来移行する時もコンテナにしておけば楽そう ○ Lambdaだと実行時間不足 ■ テストによっては1時間ぐらいかかるものもある ○ LinuxコンテナのみのサポートなのでChrome on Linuxだけ

Autifyインフラ Ver.2 ● Hubのサービス ○ タスク数は1 ● Nodeのサービス ○ タスク数は固定 ○ オートスケールはしない ■ CloudWatchのメトリクスはオートスケールの基準として意味がない

Autifyインフラ Ver.2 ● Nodeはテスト実行が終わったら停止 ○ テストに関する情報がNodeに残っているとまずい可能性 ■ Cookieや閲覧履歴などのブラウザ上の情報 ■ キャプチャ画像、ダウンロードファイルなど ○ 実行完了後HubからNodeのSeleniumプロセスを停止するコマンドが送信される ○ プロセスが停止 → Serviceが自動的にタスクを削除 ○ 新しいタスクが自動的に起動

Autifyインフラ Ver.2 ● テストを高速に実行したい → (一部)解決 ○ 個々のテストは最大10倍高速化

Autifyインフラ Ver.2の問題 ● Seleniumがオートスケールしない ○ 空きスロット数を監視して手動でノード数を増減 ○ スケールインの問題 ■ Serviceを使ったスケールインだと、テスト実行中のタスクも消される可能性 ● テストが途中で強制終了するのは避けたい ● ワーカが相変わらず1顧客1台のまま ○ スケーラビリティなし

Autifyインフラ Ver.3 ● Selenium gridをオートスケール化 ○ ノードのServiceをやめて、Lambda functionで必要タスクを起動する ■ 「最低タスク数」と「空きスロット待ちテスト数」を組み合わせ ■ 1分おきに起動 ○ Unhealthyなタスクを消して回るLambda function ○ タスク数をスケールインする際 ■ 起動タスク数 > 最低タスク数ならタスク起動Lambdaは何もしない ■ テストが終わったタスクは消えていく ■ タスクを強制終了しなくてもタスク数は自然に減る

FargateのServiceを使う利点・欠点 ● 利点 ○ 一定数のタスクが常に起動しているよう自動的に調整 ■ Unhealthyなタスクを自動的に消して新しいタスクを起動 ○ CloudWatchのメトリック基準でオートスケールできる ● 欠点 ○ 動的に実行されるバッチのようなワークロードに向いてない ■ スケールインするときどのコンテナを落とすか指定できない

Autifyインフラ Ver.3 ● ワーカもFargate化 + オートスケール ○ Lambda functionで必要タスクを起動する ○ ついでにElasticacheともさよなら

Autifyインフラ Ver.3 ● ワーカの必要台数をどう管理するか ○ SQSのAPIはそんなに高速でない & 正確でない ■ SQSに入ったジョブ数を使うのは微妙 ○ Key-Value Storeに必要数を入れる ■ ワーカの必要数 = 待ち状態のテスト数 ● Lambdaはこの数を見て適宜タスクを起動 ■ ワーカの稼働数も記録して並列度を管理

Autifyインフラ Ver.3 ● KVSの選定 ○ DynamoDB ■ すぐ使える ■ テスト実行数増えるとコスト上がる ○ Redis ■ 既に使ってる & すぐ使える(Elasticache) ■ AWS以外でも使える ○ Consul ■ ワーカコンテナのサービスディスカバリもできる ■ AWS以外でも使える

S3 Device farms Web servers Workers Queue Test Test Scenario Scenario Scenario 1. Create scenario 2. Upload scenario 3. Enque test case 4. Receive test case Result Result Result 6. Upload test result 5. Execute test case User in customer A (per customer) (on demand) (shared) Test devices (shared) 7. View test result Test For customer A For customer B Start Start Check Hub Nodes

Autifyインフラ Ver.3 ● テストがいつ実行されるかわからない → 解決 ○ ワーカ・Seleniumノードとも必要に応じて起動されるようになった ● テスト実行環境はなるべく顧客ごとに分けたい → 解決 ○ ワーカ・Seleniumノードとも使い捨て ● テストを高速に実行したい → 解決 ○ 並列実行できるようになった

Autifyインフラ Ver.3 ● ログ ○ できるだけ標準出力に出力 ○ CloudWatch Logsで確認 & Insightで検索 ○ テストのIDをログの各行の先頭に出力 ■ InsightでテストIDで検索するとどのコンテナで実行されたかわかる

Autifyインフラ Ver.3 ● 監視 ○ CloudWatch Container Insights ■ ただしタスクごとのメトリクスは取れない ○ Prometheus ■ サイドカーでメトリクスを出力 ■ これから

Autifyインフラ Ver.3 ● コスト ○ 以前 : (t2とはいえ) EC2インスタンスを顧客分だけ起動しっぱなし ○ 現在 : テストが実行されるたびにタスクが起動 ■ ただし最低起動数は常に動作

Ver. 3化 週末 顧客数5割増

Autifyインフラ Ver.3 ● コスト ○ おおまかに2/3程度に ■ Savings Plan検討中 ■ Fargate Spot ● テスト実行中にタスクが停止される可能性 ● 自動リトライを実装中

悩みどころ・今後の改善点 ● トラブルシュートの難しさ ○ ネットワーク関連の問題など ○ 監視・ログの詳細化 ○ sshdも起動しておいて最悪ログインして確認できるように ● Task definitionの管理 ○ 現状 : 手動 ○ ecspressoとか使ったほうがいいかも

悩みどころ・今後の改善点 ● タスクのスケールのタイミング ○ 現在 : 1分おきにLambda関数を実行 ○ すぐにスケールできない場合 ■ Step function? ■ SQSとLambdaの連携 ■ Enqueueするときにアプリケーション側からタスクを起動

悩みどころ・今後の改善点 ● コンテナ起動が遅い ○ 使用するツールの都合でAlpineなど軽量イメージを使えない = イメージでかい ○ マルチステップビルドしにくい構成 ○ Ruby & Python... ● Chrome on Linux以外のサポート ○ Windowsコンテナ...

悩みどころ・今後の改善点 ● 固定IPアドレスが必要 ○ NAT Gatewayから出入りするトラフィック多い → 結構高い ○ Endpoint作ったがあまり変わりなし

S3 Device farms Web servers Workers Queue Test Test Scenario Scenario Scenario 1. Create scenario 2. Upload scenario 3. Enque test case 4. Receive test case Result Result Result 6. Upload test result 5. Execute test case User in customer A (per customer) (on demand) (shared) Test devices (shared) 7. View test result Test For customer A For customer B Start Start Check Hub Nodes

https://autify.com/ja/careers/