CI/CD Conference 2023 by CloudNative Days 登壇レポート / 開発者向けブログ・イベント

CI/CDに特化したテックカンファレンス「CI/CD Conference 2023 by CloudNative Days」が、2023年3月20日に開催されました。東京都内のリアル会場とオンラインの双方で参加でき、全部で18のセッションが行われました。

GMOインターネットグループではCMスポンサーとして協賛し、自社のインフラCI/CDの実装やその課題と解決に関して情報を提供するセッションをお届けしました。今回はその内容をご紹介します。

登壇者

渡部龍一　@ryuichi_1208
GMOペパボ株式会社技術部プラットフォームグループ SRE

アーカイブ動画：https://event.cloudnativedays.jp/cicd2023/talks/1755

GMOペパボの古参サービス・カラーミーショップの歴史

GMOインターネットグループのGMOペパボでは複数のサービスを運用しています。例えばカラーミーショップは2005年にサービスを開始しており、GMOペパボの中でも歴史あるサービスのひとつで、このサービスを利用して作成されたECサイトの流通総額は1兆円を超え、トラフィック量の大きなサービスとなっています。

構成は複数のユーザーで1つのリソースを共有するというマルチテナント型。開発体制は、人の流動性が結構激しいものの、アプリケーションエンジニアが数人から30人、SREは6人ぐらいというイメージだと渡部は説明します。

歴史の長いサービスだけあってカラーミーショップではインフラも随時変更されてきました。「オンプレ期」から始まり、OpenStack上のKubernetesでアプリケーションを運用していた時期を経て、現在は「ハイブリッドクラウド期」です。プライベートクラウドとパブリッククラウドに同じ環境を用意して接続し、アプリケーションやサービスを提供するという構成です。

ちなみに、このあたりの情報に関しては、別のイベントでカラーミーショップのエンジニアが解説したスライドがありますので、興味のある方はそちらもご覧ください。

カラーミーショップがたどったインフラの歴史。プライベートクラウド、プライベートクラウド上のKubernetesで稼働していたKubernetes on プライベートクラウド期が現在主流で、ハイブリッドクラウドに移行しているところだといいます。

カラーミーショップのサービス構成

カラーミーショップは3層構造のサービス構成。ロードバランサーはプライベートクラウド、パブリッククラウド上にそれぞれに実装されていて、アプリケーションはVM（仮想マシン）またはKubernetes上に、データベースはAWS上に存在しています。

アプリケーションは80以上のロールで構成されています。基本的にはKubernetesへの移行を進めているそうですが、全てをVMから移行できるわけではなく、現時点ではVMの方がロールの数は多く、しかも一部のロールはコンテナ化しない予定であり、混在環境が継続することになります。

こうしたインフラ周りで使われている技術スタックは以下のようになっています。

プラットフォーム	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

ロールのほぼ全てはPuppetで管理されていますが、デプロイパイプラインとしてVMとKubernetesに分かれており、それぞれでCI/CDが異なっています。

VMの場合はOpenStackのレイヤをTerraformで管理。ミドルウェアの管理がPuppetで、ローカルでは各自でVMを用意してPuppetをアプライ。コードが完成したらGitHubにプッシュし、Puppetをアプライしたコンテナに対してServerspecでテストを実施。問題なければインテグレーション、ステージング、プロダクションなど、環境ごとにデプロイして動作確認するというフローになっているとのこと。

Kubernetesの場合は、「kubectlのデプロイは原則禁止で、いわゆるGitOpsのフローを取っている」と渡部。フローとしては、main branchがステージング環境に適用され、release branchがプロダクション環境へ適用されます。

開発ではmanifestの修正をGitHubにプッシュし、Dockerfileのテスト、DockerImageのビルドやプッシュを行い、ArgoCDを用いて実際のクラスターに適用するという流れです。

カラーミーショップが抱える6つの課題

こうしたカラーミーショップの環境には、以下の6つの課題を抱えていると渡部は説明します。

インフラテストへの課題
コードとサーバーで差分が発生している問題
暗黙知前提の運用問題
VMとコンテナ混在問題
セキュリティ対応問題
使用しているツールが多く、学習に時間がかかる問題

インフラテストへの課題は、端的に「時間がかかりすぎる」というものです。例えばただnginxでパラメーターをひとつ変えるためのプルリクエストを出すだけでも、ローカルのVMにコードを適用するだけで15分、CIでコンテナを起動してコードが適用されるまで20分、合計35分がかかっていました。

デプロイまでのフローには複数の段階があり、些細な修正でも毎回35分程度の時間がかかっていました

これだけ時間がかかるのは、CIが毎回プレーンな環境で実行されるという点にありました。プレーンになってしまうので修正以外の部分もやり直しになってしまいますし、「末尾のセミコロンを忘れた」というだけの修正確認でも20分かかってしまうのだそうです。

他にも様々な問題が発生しえます。最終的には「何もしなくても時間の経過とともにシステムは壊れていく」と渡部。

2番目のコードとサーバーの差分については、VMがミュータブルな点、障害対応時のアドホックな対応などが残っている点、ロールが80以上と多数になるため半年近くデプロイされていないものも存在する点などで差分が出てしまうことがあるとのこと。サービス開始当初のコード管理せずに構築されたロールなどもあって、属人化が進んでいるということもあったそうです。

似たような課題が暗黙知前提の運用で、インフラのコードに触れるメンバーがある程度固定化されてしまったため、セットアップする人がおらずに以前のセットアップ手順書が使えなくなってしまったり、メンテナンスがされていなかったり、コード変更作業がSREチームに依頼されるためチーム本来の作業ができないという問題がありました。

3番目のVMとコンテナ混在問題は、積極的なコンテナ化を進めつつもVMが混在する状況で、ミドルウェアの設定変更でVMとコンテナ双方で対応が必要になり、VMに最適化されたnginxなどのミドルウェアの設定も問題が発生することがあります。

セキュリティ対応問題では、パッケージなどの脆弱性をチェックするツールを使っても報告される数が膨大で対応しきれないという点があります。深刻度の高いもの以外は優先度を挙げられないという問題もありました。

学習コストの問題は、使用しているツールの数が多いために発生しています。IaCだけでも複数のツールがあり、運用ツールも多数の言語で実装されていて、現在メインのRubyとGo以外にも複数の言語が存在しています。

そもそも2005年からスタートしているサービスのため、当時の開発者の得意言語で作られたツールがシェルスクリプト、Perl、Pythonなどとバラバラにあり、しかもプロダクションで運用されて使われていることもあるため、メンテナンスのために言語習得が必要になることもありました。

課題をいかに解消するか

こうした課題に対しては、まず「課題をどうしたいのか」という定義から始めました。

暗黙知前提の運用のためにインフラに触れるメンバーがスケールせず、「触るのも恐い」という状況で、SREチームがインフラ作業に従事せざるをえないという課題に、「アプリケーションエンジニアも安心して触れる、インフラCI/CDを目指す」ことを目標に改善を目指しました。

解決へのアプローチは以下の通り。

CIの高速化
暗黙知の徹底排除
テストの拡充
開発環境の整備
構成ドリフト検出のための仕組みの実装
コンテナ on VM
監視の見直し
デイリーでコンテナイメージをビルドする仕組みの実装
権限委譲

インフラテストで1回30分の時間を要していたCIは、GitHub Actionsの設定方法のチューニング、ライブラリやPuppetでのキャッシュや並列化などによって1割程度、2～3分程度は削減。

さらにパイプライン自体の最適化としてキャッシュを有効活用。kernelヘッダーやgccのアップデートなど、変更と関係ない部分をキャッシュしておき、毎日朝に適用済みコンテナイメージをプッシュしておき、当日はそのイメージを利用することで、10～15分の削減に繋がりました。

さらに誰でも簡単に使えるようにすることを目指し、暗黙知前提の運用排除を目指しました。まずはドキュメントの執筆と勉強会、ワークショップの実施もしつつ、CIに関する作業の自動化を進めました。

これはプルリクエストに対して必要なラベル付け、開発環境のセットアップコマンドによる必要なツール類のインストール、テストの拡充など多岐に渡り、テストのたびにGitHubにプッシュする必要がなくなるなど効率化。

コードとサーバーの差分で発生している問題については、定期的に差分検出やコード適用する仕組みを実装。毎朝1回、Terraformのplanをチェックしたり、Puppetの差分確認コマンドも時間を決めて実行し、差分の有無を確認したりしているといいます。

デプロイフローも整理して、GitHub Actionsからしか実行できないように整備しました。変更履歴の管理が容易になって、いつ、誰が変更したかを追跡しやすくなったことがメリットです。

VMとKubernetesの混在問題は、移行期間ということもあって同時に同じアプリケーションが動いていることがあります。これに対してDockerをVMで動かし、1コンテナを1つのVMで動かすことにしました。VMの修正はDockerファイルにコンフィグレーションを含めてビルド。そのイメージをプッシュすることにして、1つの修正でVM、Kubernetes双方に反映される仕組みを実装しました。

セキュリティの課題について、パッケージの脆弱性は最新版で改善されているケースが多いので、Dockerファイルのパッケージバージョンではlatest指定し、ステージングなどで動作確認を毎日行います。latest指定で壊れてしまっても、本番環境には影響が出なくなるわけです。

こうした取り組みによってインフラCI/CDが改善され、エンジニアが触りやすい環境にはなってきました。結果として、SREチームのレビューが必須だったブランチ運用ルールを不要にできたと渡部は説明。

とはいえ、CI/CDの改善による生産性の向上が実現したかは難しい問題だと渡部は指摘します。アプリケーションエンジニアの作業量が増えただけで組織全体では生産性が下がっているのではという懸念もあり、可視化ができていない点が課題なのだとしています。

それでも、SREチーム以外が触りづらかったインフラにおけるCI/CDの改善活動を続けて、状況は良くなってきました。現在も試行錯誤中ですが、GMOペパボにおける「コンテナとVMの混在環境」というのは、一般的に起こりえる状況なので、解決するための知見を今後もアウトプットしていきたいと渡部は話していました。