Slide 1
Slide 1 text
1
インフラCI/CD継続的改善の道のり
渡部 龍一 / GMO PEPABO inc.
2023.03.14 CI/CD Conference 2023
Slide 2
Slide 2 text
2
セッション対象
● インフラのCI/CDパイプラインの管理者
● インフラのCI/CDの実装に興味がある方
話す事
● ペパボのインフラCI/CDについて
● インフラCI/CDをどのように開発/運用/改善しているか
話さないこと
● CI/CDの基礎的な話
Slide 3
Slide 3 text
3
アジェンダ
1. 自己紹介
2. 担当サービス紹介
3. 所属チーム紹介
4. インフラCI/CDについて
5. 抱えていた課題
6. 解決へのアプローチ
7. まとめ
8. 参考
Slide 4
Slide 4 text
4
1. 自己紹介
Slide 5
Slide 5 text
技術部プラットフォームグループ
2021年 中途入社
5
自己紹介
渡部 龍一 Watanabe Ryuichi
● ロール: SRE
● 趣味: 旅行、ドライブ、(緩めの)自宅サーバ
● 好きな言語: Go、C言語
● Twitter : @ryuichi_1208
Slide 6
Slide 6 text
6
自己紹介
● 経歴
○ 2017年〜 Linux向けファイルシステムの開発プロジェクト
■ テストやデプロイの自動化を担当
○ 2019年〜 ニュースサイトの開発/運用
■ CI/CDパイプラインの改善でJenkinsやCircleCIの導入推進
■ インフラをメインで見ていたがアプリも書いたりしていた
Slide 7
Slide 7 text
7
2. 担当サービス紹介
Slide 8
Slide 8 text
8
Slide 9
Slide 9 text
9
1. インターネットでものを売りたい人を支援
2. 2005年にサービスの提供を開始
3. 総流通額1兆円以上
4. 複数のユーザーで1つのリソースを共有するマルチテナント
5. ざっくりアプリエンジニア : 30〜名、SRE: 6名
Slide 10
Slide 10 text
● カラーミーショップのインフラの歴史
● オンプレ期
● プライベートクラウド期
● k8s on プライベートクラウド期
● ハイブリッドクラウド期
● 詳しく知りたい方へ (https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji
)
10
Slide 11
Slide 11 text
11
3. 所属チーム紹介
Slide 12
Slide 12 text
● 所属
● 技術部プラットフォームグループ
● 役割
● ペパボのサービスの可用性を確保し、成長に合わせて適切な環境を提
供するグループ
● ミッション
● サーバーの調達やキッティングに止まらず、SRE によるサービスレベ
ルの向上やクラウド環境の検証や選定を行い、必要に応じて事業部門
のアプリケーションの改善、開発を通して事業の成長を支える
12
Slide 13
Slide 13 text
● 主な活動
● 私の所属している技術部プラットフォームグループでは事業部を横断し
てSRE活動を実施
● 詳しく知りたい方へ(https://tech.pepabo.com/pdf/pepabo-sre-202104.pdf)
13
Slide 14
Slide 14 text
14
4. インフラについて
Slide 15
Slide 15 text
15
サービスの構成
LB App DB
VM or k8s AWSで稼働
● プライベートクラウドとパブリッククラウドを用いたハイブリッドクラウド
● アプリケーションは80以上のロールで構成されている
● AWSとプライベートクラウドは専用線 (Direct Connect)で通信
Slide 16
Slide 16 text
16
サービスの構成
LB App DB
VM or k8s AWSで稼働
● 積極的にk8sへの移行は実施している
○ それでもロールの数は VM > k8s
○ VMとk8sが混在している
○ 一部のロールはコンテナ化はしない予定なので今後もこの状況は続く
Slide 17
Slide 17 text
17
インフラ周りで使っている技術スタック(抜粋)
プラットフォーム OpenStack, AWS, Kubernetes
開発言語 Ruby, mruby, Go
ミドルウェア Nginx, MySQL, Redis, memcached
CI/CD GitHub Actions, ArgoCD
監視 Mackerel, Prometheus, Grafana, ElasticAPM, DataDog
IaC Puppet, Ansible, Chef, Terraform
Slide 18
Slide 18 text
18
● Puppet
○ puppetlabs/puppet
○ OS設定やアプリケーションの構築を自動化するオープンソース・ソフトウェア
○ Pullモデル
○ manifestはRuby-likeなDSL（Domain Specific Language: ドメイン固有言語）で
記述する
○ 今回紹介するサービスではメインで使用している
主要ツールの紹介
Slide 19
Slide 19 text
19
● Serverspec
○ mizzy/serverspec
○ サーバの構成を自動でテストするオープンソースのテストフレームワーク
○ RubyのRSpecのような使い方が可能
○ 「サーバ構築後の確認作業の自動化」「稼働しているサーバの監視」「サーバの再
起動時の状態確認」などに使う事ができる
○ 今回紹介するサービスではインフラの
CIへの組み込みに加えて稼働しているサー
バに対しての実行も行っている
主要ツールの紹介
Slide 20
Slide 20 text
20
● CI/CD(VMの場合)
● OpenStackレイヤの管理はTerraformを使用
i. インスタンスやネットワーク領域
● ミドルウェアの管理はPuppetを使用
i. ミドルウェアの設定や監視も担当
デプロイパイプラインの紹介
ローカルでの確認は各自で
VMを用意 コンテナに対してPuppetをapply
Serverspecを使ってテストを実施
integration/staging/production
環境ごとデプロイ
Slide 21
Slide 21 text
21
デプロイパイプラインの紹介
manifestの修正をpush Dockerfileのテスト
DockerImageのbuild/push
● CI/CD(Kubernetesの場合)
● kubectlのデプロイは原則禁止
● GitOpsのフローを取っている
i. main branchがstaging環境へ適用
ii. release branchの状態がproduction環境へ適用
Slide 22
Slide 22 text
22
5. 抱えていた課題
Slide 23
Slide 23 text
● インフラテストへの課題
● コードとサーバで差分が発生している問題
● 暗黙知前提の運用問題
● VMとコンテナ混在問題
● セキュリティ対応問題
● 使用しているツールが多く学習に時間がかかる問題
23
Slide 24
Slide 24 text
24
● デプロイまでのフロー
○ 例) nginxのパラメータを一つ変えるための
PRを出すまでに
■ 設定変更を入れるようにコードを修正
● ローカルにVMを用意してコードを適用する(15分)
● Serverspecと実際のVMの設定を見て問題ないかを確認する
■ 問題なければGitHubにpushしCIが実行される
● lintやセキュリティの静的チェック
● CIでコンテナを起動してコードが適用される(20分)
● CIは毎回プレーンな環境で実行される
○ 修正とは関係ない箇所の適用もやり直しになる
○ 末尾セミコロンを忘れた際の修正確認でも
20分追加でかかる
テストに時間がかかりすぎる問題
Slide 25
Slide 25 text
25
● 久々にPRを作ったら、変更箇所以外のところでテストが通らなくなってる
○ CIは実際のVMではなくコンテナを使ってVMをエミュレートしている
○ 存在しないパッケージをインストールしようとして落ちている
○ latest指定しているパッケージが後方互換性がなく落ちている
○ token期限切れて落ちている
○ 障害対応でCIを飛ばしてリリースした時の修正が原因で落ちている
○ テスト自体の取り決めもなかったので粒度がバラバラ
○ linterとかをアップデートしたらCIが通らなくなった
○ 何もしなくても時間の経過と共にシステムは壊れていく
■ システム疲労
テストのメンテナンス大変問題
Slide 26
Slide 26 text
26
● VMはミュータブル
○ 構成ドリフトやスノーフレークサーバが存在していた
● 障害時のアドホックな対応などが残っているケース
● 半年近くデプロイされていないロールが存在する
○ パッケージのバージョンがlatestで指定されているものもある
○ 意図せず大きめのアップデートが走ってしまう
● 構築時にコード管理せずに管理されたロールも存在する
● テスト環境で動作が問題なしでもproductionでは動かないケース
○ オートメーション恐怖症
○ さらにコードを触る人が減っていき属人化が進んでしまう
コードとサーバで差分がある問題
Slide 27
Slide 27 text
27
● インフラのコードを触るメンバーが固定されており暗黙知が多く存在した
○ セットアップの手順書はあるがメンテされていない
○ デプロイが各自のローカルから実行されている
○ コード変更の作業=SREチームへの依頼で本来やりたい作業が進まない
○ CIの実行方法もお作法がある
暗黙知前提の運用問題
Slide 28
Slide 28 text
28
● 積極的にコンテナ化はしつつもVMとコンテナが混在している状況
● ミドルウェアの設定変更をする際はVMとコンテナ両方必要
● VM向けに最適化されたミドルウェアの設定などもある
○ スケールアウトが前提ではない設定
○ /procから取れるメトリクスで上げていたアラート
VMとコンテナ混在問題
Slide 29
Slide 29 text
29
● パッケージ等の脆弱性をチェックするツールは動いていた
○ Trivyやtfsecが実行されている
● 報告される数が膨大で全てを対応することはできていない
○ 報告された脆弱性は深刻度が高いもの以外の優先度が上がらない
○ パッケージアップデートした後に期待する動作をするかどうかを知る術がなかった
○ 既知の脆弱性へのパッチなど、セキュリティアップデートを自動化
セキュリティ対応問題
Slide 30
Slide 30 text
30
● IaCだけでも複数ツールが使われている
○ Puppet, Ansible, Chef, Terraform
● 運用ツールなんかも多数の言語で実装されている
○ ShellScript, Perl, Ruby, Python, Go
● インフラの設定変更を入れたくても複数ツールを学ぶ必要があり最初のス
テップのハードルが高くなっていた
使用しているツールが多く学習コストが高い問題
Slide 31
Slide 31 text
31
● 暗黙知前提での運用でインフラを触れるメンバーがスケールしない
● 開発環境を用意するだけでも一苦労だと触りたい人も増えない
● 変更の影響箇所が見えづらく触るのが怖い
● SREチーム ≒ インフラ作業多めの脱却はチームの課題でもあった
アプリケーションエンジニアも安心して触れるインフラ
CI/CDを目指して改善
Slide 32
Slide 32 text
32
6. 解決へのアプローチ
Slide 33
Slide 33 text
● CIの高速化
● 暗黙知の徹底排除
● テストの拡充
● 開発環境の整備
● 構成ドリフト検出のための仕組みの実装
● コンテナ on VM
● 監視の見直し
● デイリーでコンテナイメージをビルドする仕組み
● 権限移譲を進めた
33
Slide 34
Slide 34 text
34
インフラテストの課題
Slide 35
Slide 35 text
35
● GitHub Actionsの設定のチューニング
○ bundle installやlibrarian-puppet installを都度実行していた
○ actions/cacheの導入やstep の並列化の基本的なことを実施
○ 2~3分程度の時間の削減に繋がった
CIの高速化
Slide 36
Slide 36 text
36
● パイプラインの最適化
○ キャッシュを有効活用していく戦略
○ kernelヘッダーやgccのアップデートなど変更と関係ない部分をキャッシュ
■ 毎日朝に適用済みのコンテナイメージを pushしておきそのイメージを使う
■ 10~15分程度の時間の削減に繋がった
CIの高速化
Slide 37
Slide 37 text
37
暗黙知前提での運用
Slide 38
Slide 38 text
38
● 誰でも簡単に触れるように
○ ドキュメントの整備、勉強会、ワークショップの実施
○ 認知負荷を減らすためにCIに関する作業の自動化を実施
■ mainブランチへマージ後にローカルから必要だったデプロイを自動実行するようにパ
イプラインを修正
■ テストを動かすためのコマンドはあるがオプションが大量にあって何を指定すればよ
いかわからない
● Makefileを用意して指定するオプションの最小化を目指した
■ CIを実行するにはPRに対して必要なラベルを自分で設定する必要があった
● 修正したファイルによって適切なCIが実行される仕組みを自動化した
● サービスの説明や構成図を作成
○ k1LoW/ndiagを用いて構成図などもコード管理を実施
暗黙知の徹底排除
Slide 39
Slide 39 text
39
● テスト通る=本番でも期待している動作をするを目指した
○ テスト自体が形骸化しているロールが多数存在したので直していく
○ nginxを例に
■ パッケージをインストールするまでがテストされていた
■ configが正しいかや正しくてもきちんと起動するかまでは確認されていなかった
■ PuppetやAnsibleでtemplateを使って生成するファイルが正しく生成されているか
■ 期待したポートでlistenされているかやupstream設定が正しいかの振る舞いテストも行うように
した
テストの拡充
Slide 40
Slide 40 text
40
● 開発環境のセットアップもテストする
○ setupコマンド自体が動かなくなるケースもあったので定期的に
CI環境で実行する
仕組みを入れた
● ローカル環境での動作確認を簡単にできる仕組みを用意した
○ Vagrantを使っていたがM1 Macだと動かせなくて動作確認がすぐできない
○ ローカルで色々試せない=入門へのハードルが上がる
○ ローカルでもコンテナを使って試すことができる用に環境を整備
開発環境の整備
Slide 41
Slide 41 text
41
コードとサーバで差分が発生している問題
Slide 42
Slide 42 text
42
● 構成情報と本番環境で差分がある問題
○ 基本的に手動変更は行わない運用をしているが全てを強制はできていない
○ VMだと手動で適用された変更がそのままになっていたり
○ AWSや監視設定が手動で変更されていて差分が発生する
○ いざコードを修正するときに修正箇所以外の差分が出てくる
構成ドリフト検出のための仕組みの実装
Slide 43
Slide 43 text
43
● 定期的に差分検出やコード適用を実施
○ TerraformのplanやPuppetのデプロイを時間を決めて自動実行する
○ 定期実行のplanで差分が出る=コード化されていない変更有
○ Serverspecを稼働しているサーバに実行し差分がないかを確認
● デプロイフローが複数あって何が適用されているかわかりにくかった
○ 変更履歴の管理が容易になりいつ誰が変更したかを追跡しやすくなった
構成ドリフト検出のための仕組みの実装
Slide 44
Slide 44 text
44
VMとK8s混在問題
Slide 45
Slide 45 text
45
● VMとKubernetesの移行期間
○ VMで起きた問題を対応する際にVMでは修正したがコンテナは修正されていない
という事が度々発生した
○ Kubernets化をすぐにできれば色々な経緯があってうまくできていない
● Kubernetesを使わずにVM上でコンテナを動かす
○ DockerをVMで動かして1コンテナ=1VMで動かす
○ VMへの修正=Dockerfileを修正してimageをpushしておけばよい
○ 修正漏れが減るメリットはあるがデプロイフローが複雑化する
コンテナ on VM(取り組み中)
Slide 46
Slide 46 text
46
セキュリティへの課題
Slide 47
Slide 47 text
47
● パッケージの脆弱性は最新版では改善されているケースがある
○ プログラミング言語やミドルウェアを除いて
Dockerfileのパッケージバージョンでは
latestを指定
○ ビルドしたイメージをpushしておきstagingなどで動作確認
○ 問題なければproductionに出し
○ ミュータブルなVMでもyum-cronなどの仕組みを用いて実施
■ 全台同時に更新ではなく一部の VMのみに適用し問題ないかを確認する
■ 問題がなければ全台に適用
○ 脆弱性があるまま運用するよりもよりセキュアな状態になる方向へ舵を切って進め
ている
デイリーでパッケージを最新化していく
Slide 48
Slide 48 text
48
● 自動化しても拾いきれない脆弱性は存在する
○ 例
■ パッケージ管理ツール以外でインストールしたミドルウェア
■ EOLを迎えているアプリケーションを使い続けている
○ アップデートするためには専属のメンバーをアサインして対応
■ 脆弱性報告へのトリアージ /対応
■ 脆弱性アラートの仕組みの改善活動
■ 1週間交代で進めていく
セキュリティ対応体制
Slide 49
Slide 49 text
49
権限移譲
Slide 50
Slide 50 text
50
● これまで実施したインフラCI/CDの改善で触りやすくはなった
● ブランチの運用ルールでSREチームのレビューが必須となっていたので設
定変更を実施
○ SREチームの作業負荷が下がる=アプリケーションエンジニアの負荷が上がるにな
らないように作業難易度を都度確認してどちらのチームが行うかの判断は行ってい
る
○ インフラの操作によってはアプリケーションエンジニアが持っている権限では行えな
いものも存在するので移譲できない物については引き続き
SREチームへの依頼が
発生している
権限移譲を進めた
Slide 51
Slide 51 text
51
● 暗黙知前提での運用でインフラを触れるメンバーがスケールしない
● 開発環境を用意するだけでも一苦労だと触りたい人も増えない
● 変更の影響箇所が見えづらく触るのが怖い
● SREチーム ≒ インフラ作業多めの脱却はチームの課題でもあった
アプリケーションエンジニアも安心して触れるインフラ
CI/CDを目指して改善
Slide 52
Slide 52 text
52
● 取り組み前に比べて作業依頼がほぼ無くなった
○ ドキュメント整備やCIの高速化やローカルで開発しやすくなったことで触りやすく
なった
○ 設定変更などはアプリケーションエンジニアのみでデプロイまで完結できる状況に
なった
アプリケーションエンジニアが触る機会は増えたのか
Slide 53
Slide 53 text
53
● CI/CD改善で生産性はどう変化したのかを計測
○ Four Keysを用いて可視化を行いより改善活動を効果的に実施したい
● Immutable Infrastructureの推進
○ Kubernetes化は引き続き進めていくのに加え難しい箇所はコンテナ on VMの構
成が取れる箇所は取っていく
● CI/CDパイプラインで使うツールの継続的アップデート
○ IaCを実現するためのツール自体は手動でアップデートする必要がある
○ CI/CDパイプラインのセキュア化という課題への取り組み
今後やっていきたいこと
Slide 54
Slide 54 text
54
7. まとめ
Slide 55
Slide 55 text
55
● SREチーム以外のメンバーが触りやすいCI/CDを目指し改善活動を行っ
た結果CI/CDパイプラインを継続的に改善していく必要もあると感じた
○ 改善したが時間の経過でドキュメントが古くなったり
CIが遅くなったりは定期的に見
ていく必要はある
○ コンテナとVMの混在環境は今後も減っていきはするが完全に
0になることはない
ので解決策は現在も試行錯誤中
● SREチームへのインフラ周りの権限集中という新たな課題も見えてきた
まとめ
Slide 56
Slide 56 text
56
8. 参考
Slide 57
Slide 57 text
● Web
● インフラCICDの勘所
● 現場に合わせて考えた パイプラインのデザインパターン
● 書籍
● インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現
● Infrastructure as Code
● Serverspec
● Kubernetes CI/CDパイプラインの実装
● 継続的デリバリー
57
Slide 58
Slide 58 text
58
ご静聴ありがとうございました