インフラCI_CD継続的改善の道のり

Transcript

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