■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓
■ 発表概要(400字程度)
開発になくてはならない CI/CD。GitHub を活用する組織では、GitHub Actions を活用するケースが多いでしょう。
私の所属する GMO ペパボ株式会社では、GitHub Enterprise Server と Self-hosted Runner をオンプレミスのサーバ上で運用しています。
開発者の生産性に直結する基盤である Self-hosted Runner や、それを取り巻くエコシステムへの SREing の適用と、それによる安定稼働への取り組みを実例を交えてお話いたします。
また、この基盤はオンプレミス環境からパブリッククラウドへの移設を予定しています。しかし、その過程ではコストという高い壁が立ちはだかっていました...
課題を解決し、移設へと立ち向かう過程をお話いたします。
■ 発表の詳細(1000字程度)
GMOペパボでは、多くのサーバ環境をオンプレミスのサーバ上で運用しています。
2015年以降、オンプレミスのサーバ上にOpenStackによるプライベートクラウドを構築、運用を開始し、現在まで多くのサービスのサーバプライベートクラウド上で稼働しています。
Self-hosted Runner も例外ではなく、GitHub Enterprise Server で GitHub Actions が提供されて以降、プライベートクラウド上に Self-hosted Runner のプロビジョニング環境を開発者に対し提供しました。
Self-hosted Runner の運用では、Job が enqueue されてから開始されるまでのリードタイム、Job の実行時間など、様々な非機能要件が存在します。すべてを高水準で満たさない限り、開発者の快適な CI/CD を実現することはできません。
また、GMOペパボでは、開発業務のみならず、デプロイ戦略においても GitHub Actions を活用するケースが非常に多いです。Self-hosted Runner が動作しなければ、運営するサービスの信頼性を脅かす可能性があります。
このように、高い信頼性を求められるシステムにおいて SRE のプラクティスを適用することはごく自然な流れと言えるでしょう。
Self-hosted Runner に対し、SLI/SLO の策定や可観測性の向上などを通じ、どのように SRE のプラクティスを適用し、結果どのような改善が見られたか、お伝えできればと思います。
GitHub Actions Runner で重要な要素として、コストが挙げられます。
GitHub managed Runner は非常に高価であるため、コストの最適化を目的として Self-hosted Runner を運用している組織も多く存在するかと思います。
GMOペパボでは、上記の通り、相対的に安価であるオンプレミスのサーバ環境を使用していましたが、様々な要因により、現オンプレミス環境から別環境への移行が必要となりました。
順当にパブリッククラウドへのシフトを実施すると、コストの増加が許容できません。あの手この手で信頼性を担保しつつコストを抑えなければいけません。
SRE のプラクティスを元に、コストへの対策に取り組む過程を詳細にお話できればと思います。
最後に、予定しているアジェンダを共有いたします。
■ 対象聴衆とその人たちが得られるもの
■ なぜこのトピックについて話したいのか(モチベーション)
SRE に関連するプラクティスにおいて話題の中心となるものは、「Site」 Reliability Engineering の名の通り Web サービス運営に直接関わるシステムとなります。
さらに多くの人が SRE の責務であると認識している開発生産性の向上に加え、FinOps に代表されるように、コストへの取り組みも SRE の責務として認知され始めていると感じます。
しかし、開発プロセスにおいて切っても切り離せない CI/CD に関して、信頼性への取り組みや FinOps と並べて語られた機会は多くはないのでしょうか。
この発表を契機に、発表をお聞きいただいた方の組織における CI/CD の信頼性、コスト、生産性などを SRE の責務として意識していただける、さらにその先どのような取り組みを行えばよいかの指針を示すことができれば幸いです。