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

GCP を活用してスケーラブルな CI サービスを作った話

GCP を活用してスケーラブルな CI サービスを作った話

Yoshiyuki Mineo

September 20, 2018
Tweet

More Decks by Yoshiyuki Mineo

Other Decks in Technology

Transcript

  1. D2-5-S05
    GCP を活用してスケーラブルな CI サー
    ビスを作った話
    Rocro 株式会社
    CEO, 小早川知昭
    CTO, 峯尾嘉征
    Software Engineer, 永松竜夫
    2018 年 9 月 20 日

    View full-size slide

  2. Agenda
    ● 作ったサービスのご紹介:Rocro(小早川:5 分)
    ● GAE / GKE の活用(峯尾:15 分)
    ● Cloud Build の活用(永松:20 分)

    View full-size slide

  3. 小早川 知昭
    Rocro 株式会社
    代表取締役社長
    ネットワークエンジニア、経営コンサルタントを経て、各社で事業
    開発。モバイル管理サービス立ち上げ、クラウド基盤の再構築、ド
    ローン向けクラウド事業立ち上げ等。2017 年にソニーのグループ
    会社として Rocro (株)を設立、ソフトウェア開発者向け SaaS を
    提供。日本発のグローバルなインフラを目指す。著書に ”IPsec
    徹底入門”、共著に ”インターネットルーティング入門”、”IPv6 実践
    ガイド”。
    Photo
    Speaker

    View full-size slide

  4. 1 作ったサービスのご紹介:
    Rocro

    View full-size slide

  5. Rocro とは
    ● 開発者の定常的・共通的タスクを自動化する CI 分野の SaaS 群
    ○ Inpecode : 自動コードレビュー&修正サービス
    ○ Docstand : API ドキュメント生成&ホスティングサービス
    ○ Loadroid : 自動負荷試験サービス
    ● ソニーのクラウド開発から始まる
    ● 回転させながらモノを作るプロの道具:轆轤(ろくろ)とソフトウェア開発の類
    似性から命名

    View full-size slide

  6. Inspecode : コードレビューを SaaS で手間なく廉価
    に利用
    • GitHub.com / Bitbucket のレポジト
    リと連携、プッシュごとに自動的に静
    的解析を実行
    • 実行結果はInspecode によるWeb
    サーバでホスティング
    • プルリクエストもレビュー
    • 検出したIssue を自動修正。修正内
    容は Pull Request として発行
    → エンジニアの修正作業の時間を大幅
    に削減
    if err != nil {
    return err
    }
    return nil
    return err

    View full-size slide

  7. Docstand : API ドキュメント生成&ホスティングサー
    ビス
    – GitBook
    – GoDoc
    – Javadoc
    – Jekyll
    – MkDocs
    – phpDocumentor
    – ScalaDoc
    • チーム開発に欠かせないAPI ドキュメントの
    生成・維持・公開を、手間なく廉価にサービ
    ス提供
    • レポジトリと連携して、API ドキュメントを自
    動生成
    • 主要な言語/ツールに対応
    – apiDoc
    – Asciidoctor
    – Codox
    – documentation.js
    – Docurium
    – Docusaurus
    – Doxygen
    – Spectacle
    – Sphinx
    – TypeDoc
    – YARD
    – YUIDoc

    View full-size slide

  8. Loadroid : 負荷試験SaaS。シナリオに沿ってクラウ
    ド上で負荷を自動発生、自動集計
    ● YAML で負荷試験シナ
    リオを記述
    ● シナリオを実現する負
    荷サーバを GCP 上に
    自動構築
    ● 負荷試験を自動実行、
    結果を集計
    ● 負荷試験を CI 化。IoT
    機器群も模擬

    View full-size slide

  9. Rocro の開発自体にも
    Rocro を活用
    ● Inspecode で、チームのレ
    ビュールールを設定。マージ前
    ・後両方でルールをパスしなけ
    れば、人間はレビューしない
    ● Docstand で API ドキュメントを
    生成・共有

    View full-size slide

  10. GKE を活用したインフラで並列実行されるので待ち
    時間が非常に短い
    ● 一般的に CI の待ち時間が 30 分な
    どということはザラ
    ● Inspecode は実行するツール群の
    依存関係を自動解析し、パイプライ
    ンを自動生成、並列実行
    ● 並列実行には GKE を活用(後述)
    ● 他のサービスで 20 − 30 分かかる
    ところ 5 分で完了するイメージ

    View full-size slide

  11. 2 GAE / GKE の活用

    View full-size slide

  12. Photo
    峯尾 嘉征
    Rocro 株式会社
    代表取締役 CTO
    ソニー (株) において Web ブラウザ、Web サーバ、Web サー
    ビス共通基盤などの開発を主導。
    2017 年に Rocro (株) を設
    立 。Node.js の C++ 実装 libnode のほか、Sonyflake、
    gobreaker、v8eval など OSS 作成多数。
    Speaker

    View full-size slide

  13. Section Agenda
    ● GAE/GKE の使い分け
    ● GKE におけるリソース管理

    View full-size slide

  14. GAE/GKE の使い分け

    View full-size slide

  15. Rocro サービスの構成
    App
    Engine
    Kubernetes
    Engine
    Cloud
    Datastore
    Cloud
    Storage
    Stackdriver
    Container
    Registry
    Cloud
    Build
    ユーザリクエストを処理 ユーザジョブを非同期実行

    View full-size slide

  16. GAE Standard Environment の特徴
    ステートレスな Web API サーバ向けのマネージドサービス
    ● インスタンスが高速に起動し迅速にスケール
    ○ 特に Go 言語の場合、数百 msec で起動
    ● 制約
    ○ automatic scaling で request timeout 1 分
    (task queue 経由なら 10 分)
    ○ local disk アクセス不可
    (second generation では /tmp にアクセス可)
    ○ 言語 / ライブラリに制限あり

    View full-size slide

  17. GKE の特徴
    Kubernetes のマネージドサービス
    ● Kubernetes:コンテナオーケストレーションのデファクト
    ○ 他のクラウドベンダーも採用
    ○ Docker for Mac/Windows に統合(Swarm と共存)
    ● 汎用的なサーバプラットフォーム
    ○ Web API 処理、バッチジョブ etc.
    ○ 基本的に GAE で可能なことは GKE でも可能
    ■ CronJob、ノード自動修正など継続的に機能追加

    View full-size slide

  18. GAE Standard Environment の優位性①
    ● Web アプリ開発に必要な機能がデフォルトで統合
    ○ 非同期処理(Task Queue)
    ○ インメモリ・キャッシュ(Memcache)
    ○ ユーザ認証
    ■ URL パスに対して login: admin / required
    ○ ローカル開発環境

    View full-size slide

  19. GAE Standard Environment の優位性②
    ● 運用が楽
    ○ バージョンアップが簡単
    ■ 同時に複数のバージョンをデプロイ可能
    ■ トラフィックの割り当てを変更するだけ
    (ロールバックも容易)
    ○ Task Queue によるインスタンス障害対応
    ■ 成功するまでリトライ可能
    ■ Task Queue を一時的に停止してタスクを保留
    ■ 503 やアクセスできないと push rate を自動で低下

    View full-size slide

  20. GKE の優位性
    ● ポータビリティ
    ○ Docker / OCI Image + Kubernetes
    ベンダーロックインされにくい
    ● 自由度の高さ
    ○ 言語 / ライブラリに制限なし
    ○ 自在なコンテナ構成(Pod, Service, Namespace)

    View full-size slide

  21. GAE/GKE の使い分け
    GAE Standard GKE 参考: GAE Flexible
    用途 Web API サーバ 汎用 汎用
    開発運用効率 ◯ △ △
    ポータビリティ ☓ ◯ △
    自由度 ☓ ◯ △

    View full-size slide

  22. GKE におけるリソース管理

    View full-size slide

  23. Resource Quota
    ● 各コンテナへの CPU / メモリ配分を制限可能
    ● limit は上限、request は下限
    ○ limit を超えるリソースは割り当てられない
    ○ 空きリソースが request 未満なら配置されない
    resources:
    requests:
    memory: "64Mi"
    cpu: "250m"
    limits:
    memory: "128Mi"
    cpu: "500m"

    View full-size slide

  24. リソース共有による利用効率の改善
    ● 必要なリソースは実行中一定ではない
    ● 利用頻度の低いコンテナを Pod にまとめてリソース効率を改善
    B CPU
    時間
    1.0
    A A A
    B B B
    requests:
    cpu: 1.0
    A
    requests:
    cpu: 1.0
    B
    requests:
    cpu: 0.5
    requests:
    cpu: 0.5
    +

    View full-size slide

  25. ● 同じコストで、少数の大きいインスタンス、多数の小さいインスタンス、
    どちらが有利?
    ● 大きいインスタンスの方がリソースの利用効率が良い
    ○ 小さいインスタンスはリソースの断片化が起きやすい
    インスタンスタイプ選択のトレードオフ①
    2.5 2.5 2.5
    2.5 2.5
    8 vCPUs × 1
    4 vCPUs × 2
    cpu: 2.5 × 3
    cpu: 2.5 × 2

    View full-size slide

  26. インスタンスタイプ選択のトレードオフ②
    ● インスタンス数が多い方がインスタンス障害に強い
    ● デフォルトで各インスタンス最大 110 Pod の制限があり、
    小さい Pod を多数実行する場合は、大きいインスタンスを
    使い切れない場合もあるので注意
    ○ 例:n1-standard-64 > cpu: 0.5 × 110
    ○ GKE において現在この制限は変更不可

    View full-size slide

  27. Namespace
    ● 仮想クラスタ
    ○ オブジェクト (Pod, Service, etc.) をグループ化
    ○ オブジェクト名のスコープを提供
    ● 同一の物理クラスタの上に複数の Namespace を配置可能
    ○ 動的に生成/削除可能

    View full-size slide

  28. Namespace の使い所
    物理クラスタを共有してリソースの利用効率を改善
    ● チームや Web アプリごとに Namespace を分ける
    ● 全体でコストを分担し、大きいインスタンスを多数使用
    → 利用効率改善とインスタンス冗長化の両方を狙える

    View full-size slide

  29. Namespace Resource Quota
    Namespace にも Resource Quota を設定可能
    ● 仮想的なリソース空間
    ● Namespace 内の全コンテナの request / limit の合計値を制限
    ○ コンテナと違って request で指定された物理リソースは不要
    ○ request / limitを動的に変更可能

    View full-size slide

  30. Namespace Resource Quota の注意点
    ● Namespace で request / limit を設定
    → コンテナでも request / limit の設定が必須になる
    ● 複数の Namespace を共存させて安定的に運用するために
    Namespace に request / limit を指定
    → 各コンテナの必要リソースの見積もりが必須

    View full-size slide

  31. Namespace のトレードオフ
    ● Pros
    ○ クラスタを複数の Namespace で共有して
    リソースの利用効率を改善
    ● Cons
    ○ 安定運用のために Namespace / コンテナに quota を設定
    → 安全マージンが積み重なって利用効率が悪化
    ● シンプルに複数のクラスタを運用するのも選択肢の1つ

    View full-size slide

  32. 3 Cloud Build の活用
    並列実行によるビルドの高速化

    View full-size slide

  33. 永松 竜夫
    Rocro株式会社
    ソフトウェア・エンジニア
    Photo
    Speaker

    View full-size slide

  34. Cloud Build の活用
    1. Cloud Build を利用する理由
    2. 他の CI サービスとの比較
    3. ビルドの並列実行
    4. 各種 TIPS

    View full-size slide

  35. 1. Cloud Build を利用する理由
    Inspecode では 70 以上の静的解析やスタイルチェックのツールが利用
    可能。これらのツールはコンテナで実行
    デプロイ時には、多くのコンテナのビルドが必要
    Cloud Build を利用してデプロイ時のコンテナビルド時間を短縮する

    View full-size slide

  36. コンテナとビルド時間
    78 コンテナ - のべ約6 時間
    ビルド時間 (HH:MM:SS)
    コンテナ名

    View full-size slide

  37. 2. 他 CIサービスの実行環境比較
    Circle CI Travis CI Google Cloud Build
    CPU Xeon 2.3G 2-core Xeon 2.6G 2-core
    n1-standard-1 (Xeon 2.6G 1-core)
    n1-highcpu-8 (Xeon 2.3G 8-core)
    n1-highcpu-32 (32-core)
    Memory 8GB 4GB / 7.5GB
    n1-standard-1 (3.75GB)
    n1-highcpu-8 (7.2GB)
    n1-highcpu-32 (28.8GB)
    Storage 10GB 4GB 100GB~
    Swap swapon可能 swapon可能 swapon不可
    Cost
    Free - 1x 1500min
    $150/mo - 4x unlimited
    $350/mo - 8x unlimited 2x build
    $69/mo - 1x unlimited
    $129/mo - 2x unlimited
    $249/mo - 4x unlimited
    $0.003/min
    $0.016/min
    $0.064/min
    https://bit.ly/2o6eSj1
    https://bit.ly/2o60lUt
    120分 / 日の無料枠
    出典:

    View full-size slide

  38. Cloud Buildとは
    Google Cloud Platform で高速かつ一貫性のある信頼性の高いビルドを実行
    最低限のコストで利用できるフルマネージド サービス
    CI / CD パイプラインを自動化
    プライバシーと安全性を保護
    柔軟なビルドステップ

    View full-size slide

  39. ローカル環境でのデバッグが可能
    $ cloud-build-local -config cloudbuild.yaml --no-source
    2018/08/27 09:11:54 RUNNER - [docker ps -a -q --filter
    name=step_[0-9]+|cloudbuild_|metadata]
    2018/08/27 09:11:54 RUNNER - [docker network ls -q --filter name=cloudbuild]
    2018/08/27 09:11:54 RUNNER - [docker volume ls -q --filter name=homevol|cloudbuild_]
    2018/08/27 09:11:56 Error merging substitutions and validating build: Error
    validating build: invalid .steps field: cannot specify more than 100 build steps

    View full-size slide

  40. Cloud Build Limitations
    // MaxTimeout is the maximum allowable timeout for a build or build step.
    MaxTimeout = 24 * time.Hour
    maxNumSteps = 100 // max number of steps.
    maxNumEnvs = 100 // max number of envs per step.
    maxNumArgs = 100 // max number of args per step.
    maxNumImages = 100 // max number of images.
    maxNumSubstitutions = 100 // max number of user-defined substitutions.
    maxSubstKeyLength = 100 // max length of a substitution key.
    maxSecretSize = 2048 // max size of a secret
    https://bit.ly/2PAoxe6
    cloud-build-local のソースコードを参照

    View full-size slide

  41. Reserved Volume Paths
    reservedVolumePaths = map[string]struct{}{
    "/workspace": struct{}{},
    "/builder/home": struct{}{},
    "/var/run/docker.sock": struct{}{},
    }
    https://bit.ly/2Nd7FbD
    Docker in Dockerの為

    View full-size slide

  42. 3. ビルドの並列実行
    Cloud Build はデフォルトではビルドステップは順番に実行される
    waitFor フィールドに ‘-’ を指定することで並列実行される
    steps:
    - id: foo
    waitFor: [ ‘-’ ]
    - id: baa
    waitFor: [ ‘-’ ]
    https://bit.ly/2NdJGcx

    View full-size slide

  43. Build Quota
    一度に実行可能なビルドリクエストは 10 に制限されている
    Quota を超えたリクエストはキューイングされる
    https://bit.ly/2BPJqzg

    View full-size slide

  44. machineType の指定
    machineType として
    指定なし(n1-standard-1)
    N1_HIGHCPU_8
    N1_HIGHCPU_32
    が指定可能

    View full-size slide

  45. MachineType、並列ステップ数、コストとビルド時間
    tentative
    Build Time
    Cost
    N1_STANDARD_1 N1_HIGHCPU_8 N1_HIGHCPU_32

    View full-size slide

  46. 全てのコンテナの並列ビルド
    N1_HIGHCPU_8 マシンタイプを利用し、9並列のビルドリクエストを同時
    に9つ発行することで、デプロイに必要な78のコンテナのビルドが同時に
    実行可能
    のべ6時間分のコンテナのビルドを 並列化することで20分の待ち時間で
    ビルド可能となった

    View full-size slide

  47. 4. 各種 TIPS

    View full-size slide

  48. コンテナのビルドステップ
    ソースコードの取得
    git + 秘密鍵のハンドリング
    コンテナのビルド
    docker build
    docker push

    View full-size slide

  49. 3つのコンテナ並列ビルド
    steps:
    - id: fetch-source
    - id: build-container1
    waitFor: [ 'fetch-source' ]
    - id: build-container2
    waitFor: [ 'fetch-source' ]
    - id: build-container3
    waitFor: [ 'fetch-source' ]

    View full-size slide

  50. 3つのコンテナ並列ビルド

    View full-size slide

  51. 3つのコンテナ並列ビルド

    View full-size slide

  52. 3つのコンテナ並列ビルド

    View full-size slide

  53. 共通カスタムコンテナ読み込みの並列化

    View full-size slide

  54. steps:
    - id: fetch-source
    waitFor: [ '-' ]
    - id: pull-build-container
    waitFor: [ '-' ]
    - id: build-container1
    waitFor: [ 'fetch-source', 'pull-build-container' ]
    - id: build-container2
    waitFor: [ 'fetch-source', 'pull-build-container' ]
    - id: build-container3
    waitFor: [ 'fetch-source', 'pull-build-container' ]
    共通カスタムコンテナ読み込みの並列化

    View full-size slide

  55. コンテナサイズの縮小
    Cloud Build 提供のサポートされているオープンソースのビルドステップは
    Ubuntu をベースにしている為、Alpine を利用することでサイズを縮小可

    gcr.io/cloud-builders/docker 259.1MB
    gcr.io/cloud-builders/gsutil 956.1MB
    gcr.io/cloud-builders/gcloud 965.1MB
    alpine をベースにしたカスタムコンテナ 381MB
    https://bit.ly/2o6vg2K

    View full-size slide

  56. ビルドキャッシュの利用
    ビルド結果を Cloud Storage に保存。次回ビルド前に読み込む
    問題
    git clone ではファイルの更新日時がクローン時に設定される
    結果の読み書きの効率化

    View full-size slide

  57. git のコミット時のタイムスタンプ付与
    Setting the timestamps of the files to the commit timestamp of the
    commit which last touched them
    git のコミットログの時刻をファイルに付与するスクリプトを利用
    これを利用して生成物をビルド前に読み込むことでキャッシュとして利用
    可能
    https://bit.ly/2P1bcdz

    View full-size slide

  58. Example Scripts
    https://bit.ly/2P1bcdz

    View full-size slide

  59. gzip の代わりに pigz を利用
    Parallel Implementation of GZip (pigz)
    高性能なマシンタイプを指定する場合には、Multi-Core を有効利用できる
    ツールを利用する
    % tar cf - ./out --use-compress-prog=pigz

    View full-size slide

  60. gsutil cp に -m オプションを指定
    数多くのファイルをマルチスレッド / マルチプロセスでコピーする場合に
    は、並列処理を行う -m オプションを利用する
    % gsutil -m cp -r dir gs://my-bucket

    View full-size slide

  61. ビルドステップからビルドをリクエスト
    steps:
    - name: ubuntu
    entrypoint: bash
    args:
    - '-c'
    - |
    cat << EOF > cloudbuild.yaml
    steps:
    - name: ubuntu
    entrypoint: date
    EOF
    - name:
    gcr.io/cloud-builders/gcloud
    args:
    - builds
    - submit
    - --config
    - cloudbuild.yaml
    - --no-source
    トリガから起動されたビルドから、さらに並列ビルドのリクエス
    トを発行することが可能

    View full-size slide

  62. FETCHSOURCE
    BUILD
    Starting Step #0 - "step1"
    Step #0 - "step1": Already have image (with digest): ubuntu
    Finished Step #0 - "step1"
    Starting Step #1 - "step2"
    Step #1 - "step2": Already have image (with digest): gcr.io/cloud-builders/gcloud
    Step #1 - "step2": Created
    [https://cloudbuild.googleapis.com/v1/projects/codelift-plugins-test/builds/e6f4d3d0-e2ae-4035-9a15-8210dbef7
    035].
    Step #1 - "step2": Logs are available at
    [https://console.cloud.google.com/gcr/builds/e6f4d3d0-e2ae-4035-9a15-8210dbef7035?project=407066390234].
    Step #1 - "step2": ----------------------------- REMOTE BUILD OUTPUT ------------------------------
    Step #1 - "step2": starting build "e6f4d3d0-e2ae-4035-9a15-8210dbef7035"
    Step #1 - "step2":
    Step #1 - "step2": FETCHSOURCE
    Step #1 - "step2": BUILD
    Step #1 - "step2": Already have image (with digest): ubuntu
    Step #1 - "step2": Fri Aug 3 01:16:16 UTC 2018
    Step #1 - "step2": PUSH
    Step #1 - "step2": DONE
    Step #1 - "step2": --------------------------------------------------------------------------------
    Step #1 - "step2":
    Step #1 - "step2": ID CREATE_TIME DURATION SOURCE IMAGES
    STATUS
    Step #1 - "step2": e6f4d3d0-e2ae-4035-9a15-8210dbef7035 2018-08-03T01:16:10+00:00 6S - -
    SUCCESS
    Finished Step #1 - "step2"

    View full-size slide

  63. Cloud Build の活用 まとめ
    Cloud Build はビルド環境を自由に選択可能
    並列ビルドを行うことで、のべ6時間のビルドが20分で実行可能
    毎日2時間の無料枠があるので、みなさん Cloud Build を使ってみましょ

    View full-size slide

  64. セッションへのご感想
    ウェブまたはアプリのセッション ページか
    ら、すぐにご感想を送信できます !
    ご予約したセッション終了 5 分前に、アプ
    リまたはウェブのセッションページに " ★
    評価 " が表示されます。
    そちらからフィードバックをぜひ送信くださ
    い。
    #GoogleNext18

    View full-size slide