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

Transcript

1. D2-5-S05 GCP を活用してスケーラブルな CI サー ビスを作った話 Rocro 株式会社 CEO, 小早川知昭 CTO, 峯尾嘉征 Software Engineer, 永松竜夫 2018 年 9 月 20 日
2. Agenda • 作ったサービスのご紹介：Rocro（小早川：5 分） • GAE / GKE の活用（峯尾：15 分） • Cloud Build の活用（永松：20 分）
3. 小早川 知昭 Rocro 株式会社 代表取締役社長 ネットワークエンジニア、経営コンサルタントを経て、各社で事業 開発。モバイル管理サービス立ち上げ、クラウド基盤の再構築、ド ローン向けクラウド事業立ち上げ等。2017 年にソニーのグループ 会社として Rocro （株）を設立、ソフトウェア開発者向け SaaS を 提供。日本発のグローバルなインフラを目指す。著書に ”IPsec 徹底入門”、共著に ”インターネットルーティング入門”、”IPv6 実践 ガイド”。 Photo Speaker
4. 1 作ったサービスのご紹介: Rocro
5. Rocro とは • 開発者の定常的・共通的タスクを自動化する CI 分野の SaaS 群 ◦ Inpecode : 自動コードレビュー＆修正サービス ◦ Docstand : API ドキュメント生成＆ホスティングサービス ◦ Loadroid : 自動負荷試験サービス • ソニーのクラウド開発から始まる • 回転させながらモノを作るプロの道具：轆轤（ろくろ）とソフトウェア開発の類 似性から命名
6. Inspecode : コードレビューを SaaS で手間なく廉価 に利用 • GitHub.com / Bitbucket のレポジト リと連携、プッシュごとに自動的に静 的解析を実行 • 実行結果はInspecode によるWeb サーバでホスティング • プルリクエストもレビュー • 検出したIssue を自動修正。修正内 容は Pull Request として発行 → エンジニアの修正作業の時間を大幅 に削減 if err != nil { return err } return nil return err
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
8. Loadroid : 負荷試験SaaS。シナリオに沿ってクラウ ド上で負荷を自動発生、自動集計 • YAML で負荷試験シナ リオを記述 • シナリオを実現する負 荷サーバを GCP 上に 自動構築 • 負荷試験を自動実行、 結果を集計 • 負荷試験を CI 化。IoT 機器群も模擬
9. Rocro の開発自体にも Rocro を活用 • Inspecode で、チームのレ ビュールールを設定。マージ前 ・後両方でルールをパスしなけ れば、人間はレビューしない • Docstand で API ドキュメントを 生成・共有
10. GKE を活用したインフラで並列実行されるので待ち 時間が非常に短い • 一般的に CI の待ち時間が 30 分な どということはザラ • Inspecode は実行するツール群の 依存関係を自動解析し、パイプライ ンを自動生成、並列実行 • 並列実行には GKE を活用（後述） • 他のサービスで 20 − 30 分かかる ところ 5 分で完了するイメージ
11. 2 GAE / GKE の活用
12. Photo 峯尾 嘉征 Rocro 株式会社 代表取締役 CTO ソニー (株) において Web ブラウザ、Web サーバ、Web サー ビス共通基盤などの開発を主導。 2017 年に Rocro (株) を設 立 。Node.js の C++ 実装 libnode のほか、Sonyflake、 gobreaker、v8eval など OSS 作成多数。 Speaker
13. Section Agenda • GAE/GKE の使い分け • GKE におけるリソース管理
14. GAE/GKE の使い分け
15. Rocro サービスの構成 App Engine Kubernetes Engine Cloud Datastore Cloud Storage Stackdriver Container Registry Cloud Build ユーザリクエストを処理 ユーザジョブを非同期実行
16. GAE Standard Environment の特徴 ステートレスな Web API サーバ向けのマネージドサービス • インスタンスが高速に起動し迅速にスケール ◦ 特に Go 言語の場合、数百 msec で起動 • 制約 ◦ automatic scaling で request timeout 1 分 （task queue 経由なら 10 分） ◦ local disk アクセス不可 （second generation では /tmp にアクセス可） ◦ 言語 / ライブラリに制限あり
17. GKE の特徴 Kubernetes のマネージドサービス • Kubernetes：コンテナオーケストレーションのデファクト ◦ 他のクラウドベンダーも採用 ◦ Docker for Mac/Windows に統合（Swarm と共存） • 汎用的なサーバプラットフォーム ◦ Web API 処理、バッチジョブ etc. ◦ 基本的に GAE で可能なことは GKE でも可能 ▪ CronJob、ノード自動修正など継続的に機能追加
18. GAE Standard Environment の優位性① • Web アプリ開発に必要な機能がデフォルトで統合 ◦ 非同期処理（Task Queue） ◦ インメモリ・キャッシュ（Memcache） ◦ ユーザ認証 ▪ URL パスに対して login: admin / required ◦ ローカル開発環境
19. GAE Standard Environment の優位性② • 運用が楽 ◦ バージョンアップが簡単 ▪ 同時に複数のバージョンをデプロイ可能 ▪ トラフィックの割り当てを変更するだけ （ロールバックも容易） ◦ Task Queue によるインスタンス障害対応 ▪ 成功するまでリトライ可能 ▪ Task Queue を一時的に停止してタスクを保留 ▪ 503 やアクセスできないと push rate を自動で低下
20. GKE の優位性 • ポータビリティ ◦ Docker / OCI Image + Kubernetes ベンダーロックインされにくい • 自由度の高さ ◦ 言語 / ライブラリに制限なし ◦ 自在なコンテナ構成（Pod, Service, Namespace)
21. GAE/GKE の使い分け GAE Standard GKE 参考: GAE Flexible 用途 Web API サーバ 汎用 汎用 開発運用効率 ◯ △ △ ポータビリティ ☓ ◯ △ 自由度 ☓ ◯ △
22. GKE におけるリソース管理
23. Resource Quota • 各コンテナへの CPU / メモリ配分を制限可能 • limit は上限、request は下限 ◦ limit を超えるリソースは割り当てられない ◦ 空きリソースが request 未満なら配置されない resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
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 +
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
26. インスタンスタイプ選択のトレードオフ② • インスタンス数が多い方がインスタンス障害に強い • デフォルトで各インスタンス最大 110 Pod の制限があり、 小さい Pod を多数実行する場合は、大きいインスタンスを 使い切れない場合もあるので注意 ◦ 例：n1-standard-64 > cpu: 0.5 × 110 ◦ GKE において現在この制限は変更不可
27. Namespace • 仮想クラスタ ◦ オブジェクト (Pod, Service, etc.) をグループ化 ◦ オブジェクト名のスコープを提供 • 同一の物理クラスタの上に複数の Namespace を配置可能 ◦ 動的に生成/削除可能
28. Namespace の使い所 物理クラスタを共有してリソースの利用効率を改善 • チームや Web アプリごとに Namespace を分ける • 全体でコストを分担し、大きいインスタンスを多数使用 → 利用効率改善とインスタンス冗長化の両方を狙える
29. Namespace Resource Quota Namespace にも Resource Quota を設定可能 • 仮想的なリソース空間 • Namespace 内の全コンテナの request / limit の合計値を制限 ◦ コンテナと違って request で指定された物理リソースは不要 ◦ request / limitを動的に変更可能
30. Namespace Resource Quota の注意点 • Namespace で request / limit を設定 → コンテナでも request / limit の設定が必須になる • 複数の Namespace を共存させて安定的に運用するために Namespace に request / limit を指定 → 各コンテナの必要リソースの見積もりが必須
31. Namespace のトレードオフ • Pros ◦ クラスタを複数の Namespace で共有して リソースの利用効率を改善 • Cons ◦ 安定運用のために Namespace / コンテナに quota を設定 → 安全マージンが積み重なって利用効率が悪化 • シンプルに複数のクラスタを運用するのも選択肢の１つ
32. 3 Cloud Build の活用 並列実行によるビルドの高速化
33. 永松 竜夫 Rocro株式会社 ソフトウェア・エンジニア Photo Speaker
34. Cloud Build の活用 1. Cloud Build を利用する理由 2. 他の CI サービスとの比較 3. ビルドの並列実行 4. 各種 TIPS
35. 1. Cloud Build を利用する理由 Inspecode では 70 以上の静的解析やスタイルチェックのツールが利用 可能。これらのツールはコンテナで実行 デプロイ時には、多くのコンテナのビルドが必要 Cloud Build を利用してデプロイ時のコンテナビルド時間を短縮する
36. コンテナとビルド時間 78 コンテナ - のべ約6 時間 ビルド時間 (HH:MM:SS) コンテナ名
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分 / 日の無料枠 出典:
38. Cloud Buildとは Google Cloud Platform で高速かつ一貫性のある信頼性の高いビルドを実行 最低限のコストで利用できるフルマネージド サービス CI / CD パイプラインを自動化 プライバシーと安全性を保護 柔軟なビルドステップ
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
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 のソースコードを参照
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の為
42. 3. ビルドの並列実行 Cloud Build はデフォルトではビルドステップは順番に実行される waitFor フィールドに ‘-’ を指定することで並列実行される steps: - id: foo waitFor: [ ‘-’ ] - id: baa waitFor: [ ‘-’ ] https://bit.ly/2NdJGcx
43. Build Quota 一度に実行可能なビルドリクエストは 10 に制限されている Quota を超えたリクエストはキューイングされる https://bit.ly/2BPJqzg
44. machineType の指定 machineType として 指定なし（n1-standard-1） N1_HIGHCPU_8 N1_HIGHCPU_32 が指定可能
45. MachineType、並列ステップ数、コストとビルド時間 tentative Build Time Cost N1_STANDARD_1 N1_HIGHCPU_8 N1_HIGHCPU_32
46. 全てのコンテナの並列ビルド N1_HIGHCPU_8 マシンタイプを利用し、９並列のビルドリクエストを同時 に９つ発行することで、デプロイに必要な７８のコンテナのビルドが同時に 実行可能 のべ６時間分のコンテナのビルドを 並列化することで２０分の待ち時間で ビルド可能となった
47. 4. 各種 TIPS
48. コンテナのビルドステップ ソースコードの取得 git + 秘密鍵のハンドリング コンテナのビルド docker build docker push
49. ３つのコンテナ並列ビルド steps: - id: fetch-source - id: build-container1 waitFor: [ 'fetch-source' ] - id: build-container2 waitFor: [ 'fetch-source' ] - id: build-container3 waitFor: [ 'fetch-source' ]
50. ３つのコンテナ並列ビルド
51. ３つのコンテナ並列ビルド
52. ３つのコンテナ並列ビルド
53. 共通カスタムコンテナ読み込みの並列化
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' ] 共通カスタムコンテナ読み込みの並列化
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
56. ビルドキャッシュの利用 ビルド結果を Cloud Storage に保存。次回ビルド前に読み込む 問題 git clone ではファイルの更新日時がクローン時に設定される 結果の読み書きの効率化
57. git のコミット時のタイムスタンプ付与 Setting the timestamps of the files to the commit timestamp of the commit which last touched them git のコミットログの時刻をファイルに付与するスクリプトを利用 これを利用して生成物をビルド前に読み込むことでキャッシュとして利用 可能 https://bit.ly/2P1bcdz
58. Example Scripts https://bit.ly/2P1bcdz
59. gzip の代わりに pigz を利用 Parallel Implementation of GZip (pigz) 高性能なマシンタイプを指定する場合には、Multi-Core を有効利用できる ツールを利用する % tar cf - ./out --use-compress-prog=pigz
60. gsutil cp に -m オプションを指定 数多くのファイルをマルチスレッド / マルチプロセスでコピーする場合に は、並列処理を行う -m オプションを利用する % gsutil -m cp -r dir gs://my-bucket
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 トリガから起動されたビルドから、さらに並列ビルドのリクエス トを発行することが可能
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"
63. Cloud Build の活用 まとめ Cloud Build はビルド環境を自由に選択可能 並列ビルドを行うことで、のべ６時間のビルドが２０分で実行可能 毎日２時間の無料枠があるので、みなさん Cloud Build を使ってみましょ う
64. セッションへのご感想 ウェブまたはアプリのセッション ページか ら、すぐにご感想を送信できます ! ご予約したセッション終了 5 分前に、アプ リまたはウェブのセッションページに " ★ 評価 " が表示されます。 そちらからフィードバックをぜひ送信くださ い。 #GoogleNext18
65. Thank you.