やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

SRE-SET Automation Nightに行ってきました #automation_night

メルカリさんで開催された『SRE-SET Automation Night』に行ってきました。

この勉強会は、SRE(Site Reliability Engineer)およびSET/SWET(Software Engineer in Test)な人を対象をした、"自動化"にフォーカスしたもの。

connpass.com

以下、雑なメモ。

Data processing, workflow and us ~How to manage automated jobs~

speakerdeck.com

  • @syu_creamさん。メルカリのSREチーム
  • ログをBigQueryに送る部分を改善
    • fluentd
    • 当初、シェルスクリプトとcronで実現。途中経過が見えない、エラー時の再実行が困難などの課題
    • 会社の成長にともなってログも大きくなってきたので改善したかった
    • 改善
      • Digdagを利用。ジョブの進行をビジュアライズ、再実行が容易に
      • ログサイズを事前にsplitするようにした(upload前でなく)
  • 統計
    • オンメモリ処理だとメモリがつらくなってきた
    • シーケンシャルに実行していたが時間がかかるので並列化したい
    • 改善
      • Full managed ETL(extract, transform, and load) serviceを使う
      • Apache Airflowでジョブ管理

レビューのコストを削減するための施策

www.slideshare.net

  • @tarappoさん。DeNAでSWET、iOS/Android Test Night主催
  • レビューのコストが高いので、できるだけ機械に任せたい
  • レビュー対象は色々あるが、今回はテスト観点のドキュメントの話
    • ここで言う「テスト観点」は、対象プロジェクトにおいてテストで確認すべきポイントを機能単位にまとめたもの
    • QAが書いている
    • GitHubを使い、Pull Request(以下PR)でレビューを行っている
  • 運用の問題。コメント数が最大174のものもできた
    • 指摘を修正されてもチェックしきれない
    • レビュアーとして途中参戦したくない
    • どのPRをレビューすべきか判断できない
  • PRの内容が記載されていない、タイトルにWIPがついたままでレビュー依頼されるのが一因
    • Dangerで事前チェックすることで回避
  • 文書の問題はtextlintでチェック
    • 対象プロダクトの固有名詞辞書で表記ゆれのチェック
    • ですます調、である調、弱い日本語の禁止(〜かもしれない、〜と思う)
  • PRの前に各自textlintを流す(必須ではないけど、ほぼやってくれる)
  • PRのコメントに"review"と書く → CIでtextlintとDangerが走る → okならレビュアーにmentionが飛ぶ
    • JenkinsのGitHub Pull Request Pluginで、特定フレーズでキック
  • Danger
    • 内容のチェック
    • タスクが全て完了しているか、textlintが通っているか
    • 最終コミットがgreenになっているか
    • 通ると、ラベル"In Review"がつく
  • 導入後、表記ゆれ、typoが減った。PRが見やすくなった
  • 今後の課題
    • 辞書の登録が面倒
    • 定量的評価をしたい
    • レビュアーの選定を自動化したい(集中しないようにしたい)
    • API Docに適用できないか
    • Jenkinsからの脱却

Reliable Mobile Test Automation

www.slideshare.net

  • @vbanthiaさん。DeNAでSWET→メルカリでSET
  • Appium Docker DemoとかSTF Appium Exampleとか公開
  • Test Automation Lift Cycle
    • モバイルにおいて、自動テストだけを信じてリリースできるか?(会場では自動テストをやっている人は多かったが、信じられるか?の問に挙手した人は1人だけ)
    • 機能が増えてくるとQAチームがパンクする。振り返りで"We need automation!"となる
    • Development Teamから分割してSET/SWETなどに分けるケースが多い?
  • ツール選定・導入は比較的簡単にできる
  • たくさんテストを書く
  • そのテストをリリースまで使うのが難しい。問題になるのは、
    • Flaky tests(不安定なテスト。様々な要因で成功したり失敗したりするもの)
    • Test execution environment(実機を含めたテスト実行環境)
  • 結果、テストが信じられない。使われなくなり、メンテされず、捨てられてしまう
  • Flaky Tests
    • 原因として
      • User interface issue
      • Backend issue
      • 3rd party service issue
      • Hardware issue
    • problem is not flaky test. 問題は、テストがflakyなことではなく、テスト実行中に何が起きたか我々が知らないこと
    • 対策は"Record everything!"
      • Screenshots, Video
      • ADB logs
      • Timestamp of each UI action and test assertion
      • Test script logs
      • Appium logs
    • レポートの改善
  • Test Execution Environment
    • Cloud Serviceが使えればベスト、誰でも使える環境
    • 以前の発表、"Android e2e testing at mercari"を参照
    • Google Cloud Storageにapkをuploadして、DockerでOpen STF、Circle CIでDocker imageビルド、テスト実行
  • デモ
    • Slack上の対話Bot(名前は"BB-8")で実行できるようにしてある
    • UIで、ビルド番号、複数のデバイス、複数のテストケースを選んで実行できる
  • Mobile test automationはチャレンジングだが不可能ではない

Magic Podの活用を具体的に考えてみた

www.slideshare.net

  • 戸田さん
  • Magic Podについて、Selenium IDEを使っていた層に向けたもの、という印象を持った
    • コード書ける人、Excel+手動テストの人、という人たちがいて、その中間の層
  • アプリが完成してから自動テストを作るのでなく、ワイヤーフレームから仮のテストケースを作っていけばQAも並列作業できるのでは?
  • CLIもある。Travis CIでは検証した(TRIDENTさんのブログで公開)。Circle CIは検証中

Prometheusを導入した話

セキュリティ強化のための自動化

speakerdeck.com

  • @manabusakaiさん
  • freeeでは人やお金に関する情報を扱っている。情報漏えいは厳禁だし、よく攻撃もされる。
  • 1,000台のサーバをSRE 3人で見てるので、自動化で対応
    • セキュリティパッチ、すぐ適用したいけど難しい
    • 外部からの怪しい攻撃は自動的に遮断したい。攻撃されてから気づくことが多い?
  • CodeBuildを使いAMI作成
    • Golden AMI方式
    • 以前は、脆弱性が発見されると手分けしてやっていた → CodeBuildでPackerを流す方式に
    • 1コマンドだけ投入、並列実行できるので1hくらいで全インスタンス入れ替えを完了
  • AWS WAFを使った攻撃の自動遮断
    • 攻撃側のIPアドレスは頻繁に変わるので、security groupなどでは対処しきれない
    • ロードバランサにAWS WAFを導入、DoSっぽいアクセスがきたら、403を返してくれる
    • LBで遮断できるのでWebサーバの負荷は上がらない
    • 一次対応がこれでできるので、他の対処が必要な攻撃であっても人間は余裕をもって対処できる

1人インフラ運用チームで、自動化の作業時間を確保するためにやっている(た)こと

speakerdeck.com

Automation基盤提供のしかた

  • @tnirさん
  • 実行履歴が取れることが大事
  • 実行タイミングを制御できること
    • ナイトリービルド
    • マニュアル実行
    • イベントドリブン
    • 自動再実行、マニュアル再実行
  • 実行命令系との連携
    • dev: SCMとの連携
    • ops: Infrastructure as Code
    • ジョブと変数の分離
  • GitLab CI/CDを使っている
  • 社内への普及活動
  • 業務上は困ってないが、デザイン/パフォーマンスには課題。ほかも検証してみたい

所感

会場にSREな人は少なかったようですが(私も門外漢ですが)、"自動化"というキーワードでくくって広範囲な話が聞ける機会となり、とても面白かったです。

いずれも、導入から運用、改善のスパンが長くなる話なので事例そのものが貴重ですし、かつ今回は単に「試してみた」「導入してみた」を超えた話が聞けて大変ありがたいイベントでした。

第2回以降も(自動的に!)開催されそうな方向なので、期待して待ちます。