この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事はAWS re:Invent 2019のセッション「Amplifying CI/CD helped Wag! reduce release process by 600%」のレポートです。
概要
日本語訳
DevOpsプロセスを改善するために、Wag Labsの戦略は1枚のガラス板を構築することでした。その結果、Wag！犬の散歩のプラットフォームは、AWSでセルフホストされたGitLabを使用してCI / CDを駆動することにより不可能を達成しています。ワグ！ GitLabとTerraformの組み合わせを使用して、アプリケーションとインフラストラクチャを展開します。ワグ！開発プロセスを簡単にし、リリースプロセスを40分から6分に短縮しました。どのようにWagをご覧ください！これらの素晴らしい結果を達成するための自動化を実装し、いくつかのベストプラクティスを学び、会社の今後の方向性を内部的に把握します。このプレゼンテーションは、APNパートナーのGitLabによって提供されます。
原文
To improve its DevOps process, Wag Labs’ strategy was to build a single pane of glass. As a result, the Wag! dog-walking platform is achieving the impossible by using self-hosted GitLab on AWS to power its CI/CD. Wag! deploys its application and infrastructure using a combination of GitLab and Terraform. Wag! made its development process painless and has cut its release process from 40 minutes down to six. Come see how Wag! implemented automation to achieve these awesome results, learn some best practices, and get an inside look at where the company is going next. This presentation is brought to you by GitLab, an APN Partner.
スピーカー
- Dave Bullock - VP of Technology, Wag Labs
- Brandon Jung - VP of Alliances, GitLab
レポート
Wag! intro
- On-demand dog walking,sitting,boarding,and daycare platform
- In 43 states and over 110 cities
- Millions of walks per year
- We create joy for dogs and those who love them
- We like dogs puns
- Slackmoji-heavy enviroment
1.5年前..
犬の散歩プラットフォームの以前の構成
問題：アプリケーションPipeline
- 複雑で危険を伴うデプロイ
- ロールバックの回復パスが遅い
- 多様な環境（開発、ステージング、本番）
- Travis CIを使用した固定サイズのPipeline
- 組織全体にわたるリリース/障害における単一の連絡先
計画：フェーズ1A
- アプリケーションのコンテナ化
- ECSクラスターの自動スケーリング
- Blue/Green + Canary デプロイメント
- デプロイの民主化
アプリケーションのコンテナ化
- AnsibleとPackerでパイプラインGitLabを構築
- DockerイメージとAMIを作成
- 最新バージョンOS、パッケージなど
- いつでもビルドをトリガーしてセキュリティパッチをプッシュ
- ベースイメージをAmazon ECRにプッシュ
- Amazon ECRからベースイメージを取得するGitLabのステージを構築
- ブランチ、タグ付きリリースをDockerイメージにコピーし、Amazon ECRにプッシュしてタグ付け
- Dockerイメージに機密情報や設定なし
- 自動化されたテスト、同一イメージを開発、ステージング、本番環境で使用
Amazon ECSクラスター
- アプリケーションをAmazon ECSクラスターにデプロイする
- SSMとChamberを使用して機密情報や設定をプル
- CPUベースのスケーリング
- コストを削減し、スケーラビリティを向上
Blue/Green + Canary デプロイメント
- デプロイする前に新しいAmazon ECSクラスターをスピンアップ
- Amazon ECRからタグ付きリリースイメージを取得
- 稼働中のクラスターに合わせてクラスターをスケールアウト
- トラフィックの1％を新しいクラスターに送信
- エラー、ログ、ロードなどを監視
- 新しいクラスターにカットオーバー
- エラー、ログ、ロードなどを監視
- 縮小またはロールバック
- Amazon Route 53 + HAProxyレイヤーで実装
デプロイの民主化
- すべてのチームが独自のコードをデプロイできるように
- シンプルなWEB(DB移行、カットーバー、ロールバック)
- リリース速度を上げる
- リスクを軽減
問題：インフラ
- AWSマネジメントコンソールをクリックしてできたインフラ
- オートスケーリングなし
- デフォルトVPC、デフォルトサブネット..ネットワークACLなし
- テストするためのステージング環境なし
- すべてを支配する1つのセキュリティグループ
計画：フェーズ1b
インフラストの再設計
- コードとして定義
- オートスケーリング、マルチAZ アーキテクチャ
- VPCサブネットの階層化
- 最小許容のネットワークACL / セキュリティグループ
- GitLabを介したアプリケーションのデプロイ
コードとして定義
- クリックではなくコード
- すべてをTerraform化
- モジュール/環境用の大きなmonorepo *1の構築
- ステート用のAmazon S3、ロック用のAmazon DynamoDB
- ハードコーディングなし
オートスケーリング、マルチAZ アーキテクチャ
- すべてがマルチAZになるように構築
- サンドボックス/テスト環境はシングルAZ
- 単一障害点なし
- オートスケーリングによる自動スケーリング
- 本番と同じアーキテクチャを備えたサンドボックスとステージ環境
VPCサブネットの階層化
- 全サブネットの階層化
- API、ワーカー、データベース、キャッシュ等
- ネットワークACL階層間で最小限に許容
- ステートフルルールの追加に一致するセキュリティグループ
- VPCフローログの有効化
GitLabを介したアプリケーションのデプロイ
- Terraformを構築してBlue/Greenデプロイを実行
- GitLab RunnerとAWS STSを使用して、クロスアカウントでデプロイ
- システムへのログイン、コマンドの実行などは不要
- すべてTerraform経由で処理
数ヶ月後..
成功!!
- ピースごとに、プラットフォーム全体を新しい環境に移動
- チームが独自のデプロイを行えるようになった
- AWS Well-Architectedレビューに合格
- コスト節約
- リリース速度の増加
- デプロイリスクの削減
Blue/Green architecture
何が悪かったのか？
教訓
- 変更は難しい
- システムは複雑
- モノは壊れる
- 誰も完璧ではない
- 人々は間違いを犯す
それ以降
計画：フェーズ2
- デプロイPipelineのガードレール
- インフラスのソフトウェア開発ライフサイクル
- Terraform monorepo の分割
- マルチAWSアカウント(Amazon S3バックエンドに移動)
- チームのためのCI/CD
- チームビルディング
ガードレール
- デプロイPipelineはPAWのような魔法だった
- 正しい順序で行わなかった場合、モノは壊れました
- 悪いことを防ぐためにガードレールを追加
- アップタイムは良好、ダウンタイムは不良
- ガードレール！
Terraformのソフトウェア開発ライフサイクル
コードベースのインフラストラクチャがある。GitLabを使用してソフトウェア開発を実装しよう！
- masterからブランチを切り取る
- AWSサンドボックスでテストする
- ブランチをプッシュし、lint/testsを実行
- コードレビューを取得
- 変更をマージ
- 自動ステージングとテスト
- Terraform planの確認
- Apply plan（deploy）
monorepoを細断処理
../../../と同じリポジトリで参照されるモジュールは理想的ではなかった
- タグを介してモジュールをロックする方法が必要
- モジュールの変更が他の環境に影響を与えたくない
- 各環境のリポジトリを構築：Prod、Date、Ops、QAなど
- Luckilly、Gruntworkの推奨同様、構造化したとおりにステージを移動した
- live / prod / ..
- live / pdate / ..
- live / ops / ..
TerraformマルチアカウントAmazon S3バックエンド
- 単一の管理用AWSアカウントを作成
- ステート用のAmazon S3バケット
- ロック用のAmazon DynamoDB
- サンドボックス、ステージング、本番にデプロイするためのIAMユーザー/ロール
- ワークスペースとロールを使用して、複数の環境でTerraformを共有
- テスト、ステージング、デプロイを簡単かつスケーラブルに
TerraformのCI / CD
- GitLabでテスト実行、ステージング、planを適用するためのPipelineを構築
- コードをプッシュし、Terraform planでSlackにping
- クリックして適用
チームを構築する
- 優秀なエンジニアを見つけるのは難しい
- Terraformを知っている優秀なエンジニアを見つけるのは難しい
- 情熱的な人を雇う
- 使命と仕事を気にする人を雇う（そして明らかに犬）
- 学び、成長することに興奮している人を雇う
- 駄洒落(犬の駄洒落)が好きな人を雇う
数ヶ月後..
成功!!
- monorepoを分割する
- インフラストラクチャ用の完全なCI / CDパイプラインを作成しました
- 素晴らしいチームを作り上げた
- チームにオンボードされたが、彼らは皆怒りをやめなかった
- 非常に多くの犬の駄洒落に来た
何が悪かったのか？(再掲)
教訓
- 変更は難しい
- システムは複雑
- モノは壊れる
- 誰も完璧ではない
- 人々（私、特に）は間違いを犯す
さいごに
稼働中のシステム変更がいかに難しいか伝わってきました。運用を見越したCI/CDの重要性について改めて確認することができました。
脚注
- 1つのリポジトリの中に複数のパッケージを同梱しリポジトリを運用すること ↩
18
