Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Amazon CodeBuild でテストをめっちゃ並列実行する話 #builderscon

Rick Koike
August 05, 2017

Amazon CodeBuild でテストをめっちゃ並列実行する話 #builderscon

builderscon 2017 tokyo で話したものです

Rick Koike

August 05, 2017
Tweet

Other Decks in Technology

Transcript

  1. Amazon CodeBuild
    でテストをめっちゃ並列実行する話
    ター
    ゲット
    CI
    の実行時間長くなってきて辛い人
    Docker
    で無茶したい人
    Amazon ECS
    で頑張ってテスト実行環境作ってる人
    Rails
    での Docker
    ベー
    スで分散テストの実際を知りたい人
    Rails
    以外でも役に立つ現実の世界での糞みたいな知見
    今日しない話
    CI
    の導入とか基礎的な話
    ソフトウェアのテスト手法そのもの
    (
    特に本番環境での)
    デプロイ関連
    インター
    ネットのもめごとについて

    View Slide

  2. 問題意識
    ソフトウェアの開発は簡単になった。
    フロント疲れみたいな言葉もいい加減聞かれなくなった
    巨大化、
    複雑化する UI

    View Slide

  3. テストは簡単になったか?
    別に最初からそんなに難しくはなかった。
    そして、 E2E
    テストが書かれ
    まくるようになった。
    v
    i
    s
    i
    t "
    /
    h
    o
    m
    e
    "
    a
    s
    s
    e
    r
    t
    _
    s
    e
    l
    e
    c
    t
    o
    r "
    h
    1
    #
    t
    i
    t
    l
    e
    "
    , t
    e
    x
    t
    : /
    ^
    H
    o
    m
    e
    $
    /
    , c
    o
    u
    n
    t
    : 1
    f
    i
    n
    d
    (
    "
    #
    l
    o
    g
    o
    u
    t
    "
    )
    .
    c
    l
    i
    c
    k
    (
    )
    a
    s
    s
    e
    r
    t
    _
    e
    q
    u
    a
    l "
    /
    "
    , p
    a
    g
    e
    .
    c
    u
    r
    r
    e
    n
    t
    _
    p
    a
    t
    h
    みたいな。

    View Slide

  4. 結果起きること
    大量に書かれる、
    実行に時間がかかりまくるテスト
    単純に直列に実行すると、 CI
    に数時間とか
    ぼくが働いてる会社の実例

    View Slide

  5. 当然並列ビルド!!

    View Slide

  6. いやいや大規模になってきたらインフラ自分
    で組めばいいじゃん?
    さっきも言いましたが、
    ソフトウェア開発は、
    本当に簡単になった。
    小規模で資金、
    人的な問題から運用にリソー
    スを割けない組織でも巨大
    なテストベー
    スを持ってしまうようになった
    テスト実行環境は本番環境と同等の信頼性が必要、
    不用意な運用はして
    はいけない

    View Slide

  7. そこで Amazon CodeBuild
    でやっていくこ
    とにしてみた

    View Slide

  8. Amazon CodeBuild
    とは何ではないか
    TravisCI
    を捨てて引っ越せるものではない
    Jenkins
    を捨てて引っ越せるものではない
    では何?
    いろんなシステムから使える汎用的な Jenkins
    の slave
    のような存

    View Slide

  9. すごくシンプルな使い方
    buildspec.yml
    ってファイルを作ってリポジトリに置く
    v
    e
    r
    s
    i
    o
    n
    : 0
    .
    2
    p
    h
    a
    s
    e
    s
    :
    i
    n
    s
    t
    a
    l
    l
    :
    c
    o
    m
    m
    a
    n
    d
    s
    :
    - b
    u
    n
    d
    l
    e i
    n
    s
    t
    a
    l
    l
    b
    u
    i
    l
    d
    :
    c
    o
    m
    m
    a
    n
    d
    s
    :
    - b
    u
    n
    d
    l
    e e
    x
    e
    c r
    a
    k
    e t
    e
    s
    t
    みたいな。
    その上で設定して、
    ビルドボタンみたいのを Web UI
    から押す。

    View Slide

  10. AWS CodeBuild
    に無いもの
    リポジトリを監視して、master
    の最先端を常にビルドする
    Pull Request
    を監視して、
    作成、
    更新されるたびにビルドする
    CI
    ツー
    ルではない。 UI
    を見てよく分かったかと思います。

    View Slide

  11. 常識的な使い方をする場合
    AWS CodeStar

    AWS CodeBuild Plugin for Jenkins
    Pull Request
    を受けて CodeBuild
    でビルドしたいとかだけな
    らこれでよさそう感あり

    View Slide

  12. ところで
    v
    e
    r
    s
    i
    o
    n
    : 0
    .
    2
    b
    u
    i
    l
    d
    :
    c
    o
    m
    m
    a
    n
    d
    s
    :
    - d
    o
    c
    k
    e
    r r
    u
    n -
    t
    i s
    o
    m
    e
    _
    i
    m
    a
    g
    e

    View Slide

  13. AWS CodeBuild
    はすぐに起動する Docker
    リソー
    スプー
    ルである
    しかも時間課金(1
    分 $0.005)
    ただしコンテナは永続化しない
    ポー
    ト解放もできない

    View Slide

  14. AWS Batch
    は?
    あれはなんかエンプラエンプラした感じのタスクランナー

    View Slide

  15. 最近 Azure
    にももうちょっと汎用的な Docker
    リソー
    スプー
    ルがで
    きた(
    秒課金)
    けど個人的にも会社的にも AWS
    なのであんまり真面
    目に調べてない
    不真面目にはとりあえず使ってみたんだが Azure
    のコンパネ
    の酷さはなんだ? GCP
    のコンパネを触った時、 AWS
    未満のも
    のを作れることに驚きを感じたが、 Azure
    を触ると GCP
    が最
    悪ではなかったという点で驚きを感じる
    あっちはコンテナが永続化する、
    ポー
    ト解放もできるのでデプ
    ロイもできます
    ただ基本的には瞬間火力需要をタゲってるっぽさ
    1
    秒課金なので、 1
    秒未満でコンテナを終了させると無料
    MS
    日本法人のプロモ戦略が気に食わないみたいなのが無い人はや
    っていくといいのでは

    View Slide

  16. 即起動 => docker run =>
    即死 というのをやりやすくなってきている

    View Slide

  17. テストの数だけ、
    実行環境を大量に建てて、
    1
    テスト 1
    実行環境でやったら、
    最強なのでは?

    View Slide

  18. まあ実際そう上手くはいかないんですが

    View Slide

  19. ここからは現実の話をします

    View Slide

  20. 全体の流れ
    1. Travis
    でリポジトリ監視
    2. Travis
    で Docker build & push
    push
    先は宗教上の事情無い限り Amazon ECS
    が楽と思う
    3. Travis
    から適宜大量に CodeBuild
    たてる
    4. Travis
    側で API
    ポー
    リングするかなにかして実行状況監視 = >
    実行
    結果を集計
    このうち 1.
    については特に話すことはないでしょう。

    View Slide

  21. 2.
    について僕が実際に会社でやったこと

    View Slide

  22. 一番簡単なやり方としては、 Travis
    からは CodeBuild
    をとにかく起動
    するだけで、 CodeBuild
    の設定で実行環境のビルドからなにからやると
    いうのが考えられる。
    それが駄目な理由
    めっちゃ並列数上げると、 Github
    リポジトリへの git
    による大量ア
    クセスが発生して死ぬ
    CodeBuild
    は時間課金なので、
    実行環境のビルドという共通処理を
    各インスタンスでやるのは無駄
    CodeBuild
    はビルド成果物のキャッシュ機構がないので時間(==
    金)
    の無駄
    毎回 0
    から bundle install
    とか npm i
    とかしたくないっていう

    View Slide

  23. いいかんじにものごとをキャッシュしながら Rails
    アプリの
    Docker
    イメー
    ジを build
    したい
    TravisCI
    には依存ライブラリとかそういうものをディレクトリキャッシ
    ュしてくれる機能があります。
    c
    a
    c
    h
    e
    :
    d
    i
    r
    e
    c
    t
    o
    r
    i
    e
    s
    :
    - c
    l
    i
    e
    n
    t
    /
    n
    o
    d
    e
    _
    m
    o
    d
    u
    l
    e
    s
    - v
    e
    n
    d
    o
    r
    /
    b
    u
    n
    d
    l
    e
    これを使おう!!!

    View Slide

  24. Docker Image
    を複数回に分けてビルドする
    1.
    全体のベー
    スイメー
    ジをビルドする
    言語処理系とかテストツー
    ルとかが入ってるやつ
    2.
    依存ライブラリインストー
    ル用のイメー
    ジをビルドする
    Gemfile package.json requirements.txt
    など「
    だけ」
    を作業
    用ディレクトリにコピー
    する
    3. docker run
    で依存ライブラリをホスト側ディレクトリにインストー

    d
    o
    c
    k
    e
    r r
    u
    n \
    -
    v `
    p
    w
    d
    `
    /
    c
    a
    c
    h
    e
    /
    b
    u
    n
    d
    l
    e
    :
    /
    a
    p
    p
    /
    v
    e
    n
    d
    o
    r
    /
    b
    u
    n
    d
    l
    e \
    b
    u
    n
    d
    l
    e i
    n
    s
    t
    a
    l
    l
    4.
    テスト実行用イメー
    ジには cache/bundle
    を COPY
    する
    5. ↑
    の 3.
    で作ったディレクトリを CI
    ツー
    ルのキャッシュ機構でキャ
    ッシュする

    View Slide

  25. Docker Multi Stage Build
    とか CircleCI
    の Docker Image
    Cache
    じゃ駄目なの?
    docker build
    中に外部環境にアクセスしたい、
    というものなので大分話
    が違うと思う。
    https://github.com/moby/moby/issues/15338
    でこれと似たような話(docker build
    中に link
    をしたい)
    が門前払い食ら
    ってたので、
    公式機能としてこういうことが出来るようにはならん気す
    る。
    Dockerfile
    のなかにディレクトリを固めて S3
    に上げたり持ってきたり
    とかしてキャッシュ機構を自前で書いてもいい気はする。
    なにが一番シ
    ンプルに見えるかは人それぞれ?

    View Slide

  26. テストの実行
    CodeBuild
    は API
    で環境変数を与えながら docker image
    を起動できま
    す。
    テストファイルごととかにコンテナを起動して並列数をめっちゃ上
    げて実行してしまうと便利。
    注意点
    コンテナ実行環境のプロビジョニングは失敗する可能性がありま
    す、
    失敗したらリトライするといったコー
    ドが必要
    一瞬で起動する実行環境が 70
    を越えたあたりからプロビジョニン
    グの失敗率が激増します。
    並列数を 60
    ぐらいに抑える制御がある
    とよい

    View Slide

  27. 簡単にやる
    https://github.com/wata727/drunker
    これちょうすごい。
    プロジェクトディレクトリを tar.gz
    で固めて
    docker hub
    にあるありもののイメー
    ジで docker run
    すれば動くような
    プロジェクトだとこれでよさそう。
    E2E
    テストとか沢山書かれている環境だとわりと自分でビルドプロセス
    書きまくらないといかんかな。

    View Slide

  28. ところで
    調子に乗ってるとそこそこ金はかかる。
    0.005/min == 0.3/h
    m4.xlarge
    は 0.28$h

    View Slide

  29. まとめ
    1. Docker
    リソー
    スプー
    ル的なサー
    ビスが出てきている
    2.
    自分でテスト実行用クラスタ構築する必要はなくなってきている
    3.
    並列数を(
    従来比で)
    猛然と上げても大丈夫な感じなのでやっていき
    ましょう

    View Slide

  30. 自己紹介
    ssig33 /
    小池 陸
    ユビレジというところからきました、 B2B
    プロダクトで今日話したよう
    なことをやってます

    View Slide