お客様のパブリッククラウド導入を導入から運用までフルサポートするソフトバンク株式会社のMSP(Managed Service Provider)サービス。お客様が増加しても、クラウドサービスを安定的に品質高くお届けする鍵となるのが、Infrastructure as Code (IaC)の導入です。本稿では、2021年11月24日に開催された CircleCI ユーザコミュニティミートアップ にて、同社 嵯峨 毅郎(@takeo_saga)氏に紹介いただいた CircleCI を使ったインフラ管理手法を紹介します。
目次
クラウド活用ビジネスの成長に必要な３要素とは
ソフトバンクが提供するMSPサービスのようなクラウド事業をスケールするために必要な要素として、嵯峨氏はつぎの３つを挙げています。
- ブランド力向上
- 業務をスケールさせる（増えた案件をさばく）
人力な作業を自動化・機械化し、作業を高速化 - 作業品質の向上
人力な作業を極力減らし、作業ミスと作業者の心理的負荷を削減
この３要素のうち、技術的な要素は後半の「業務をスケールさせる」と「作業品質の向上」で、これらはInfrastructure as Code(IaC)の導入によって解決可能であると嵯峨氏は指摘しており、IaCの１コンポーネントとして、CircleCIをご利用いただいています。
具体的には、
- 1 作業内容を指示したオーダーシートをGitHub上にJSON形式のファイルとして追加
- 2 オーダーシートをプログラムが処理しやすい形に変換
- 3 CircleCIなどの実行環境で制御し、まずはステージング環境にデプロイ
- 4 問題がないようであれば、本番環境にデプロイ
といった一連の機能の中でご利用いただいています。また、ソフトバンクではこの自動化の仕組みで特許を取得しているとのことです。
嵯峨氏に特許取得の理由を伺ったところ、新規サービスを始める際には、他社の特許を侵害しサービス提供に問題が生じないよう、リスク管理がなされているとのことで、クラウドを活用したビジネスを始め、成長させていくためには、知財リスクをゼロに近づけることが重要であることがわかります。
２年半のクラウド活用ビジネス成長のあゆみ
さて、MSPサービスがサービスインしてからおよそ２年半が経過してきた中で、
-
業務をスケールさせる（増えた案件をさばく）
人的な作業を自動化・機械化 -
作業品質の向上
人力な作業を極力減らす
上で、CircleCIはどういった形で貢献してきたのでしょうか？ CircleCIを利用する中で感じたことや、実際に対応してきたことから５つを嵯峨氏にご紹介いただきました。
1. テスト／ビルド結果通知と承認フローの仕組み化
CircleCIによってテストやビルドといった作業が自動化されても、作業完了まで人が画面を見ていては、自動化はできても効率化につながりません。
ソフトバンクにおいても、作業の完了や、その際の成功や失敗といった結果を、チームメンバーに対してプッシュで通知する仕組みが必要でした。CircleCIにはSlack Orbがあるため、これを使えばそれほど工数をかけることなく、プッシュ通知の仕組みが実装できます。
また、お客様の環境へのデプロイに関しては、1) 人によるチェックを行った上で、承認の後に行う 、および 2) 承認者はだれでも良いわけでなく、一定の権限が必要 の２点を「仕組み」として実装する必要がある、とチームでは考えていたとのことです。
そこで、CircleCIが備えている承認機能とSlack Orbとを組み合わせ、Slackで承認要求をプッシュし、承認されれば後続のお客様環境へのデプロイが自動実行される仕組みを構築されたとのことです。
ただし、Slack側の仕様変更により、この仕組みに必要だったIncoming Webhookが非推奨となってしまったため、Google Chatで再度実装しています(前述のSlackの仕様変更に加え、社員と派遣社員の双方が利用可能なメッセージングインフラとして、ソフトバンクではGoogle Chatを使用していたため)。
2. Executorて提供するアプリのバージョンアップによる影響回避
CircleCIではジョブを実行するのは、Dockerコンテナベースのコンテナと、仮想マシンベースのMachine Executorの２種類が用意されています。
コンテナの場合、使用するイメージはCircleCIが用意するイメージや自分で用意するイメージを単体、あるいは組み合わせて利用することが可能です。
一方、Machine Executorの場合、コンテナではなく仮想マシンであるという性質の違いから、自分で環境を用意するのではなく、CircleCIが提供する環境(仮想マシン上のツールなど)をご利用いただくことになります。
ソフトバンクでは、CircleCIが提供するMachine Executorのうちの一つ、Windows ExecutorをMSPサービスで利用していたところ、ある日突然、全サービスのほとんどのビルドが最後まで実行されない、という事故が発生してしまったことがありました。
原因を探ってみると、Executor内にデフォルトでインストールされていたPowerShellパッケージのバージョンが、Executorのバージョンアップの際に変わっており、今まで書いていたコードが対応しなくなり、その結果、全然動かなくなってしまうというクリティカルな事故に至ってしまいました。
対応としては、1) 仮想マシンではなくコンテナで実行できるのであれば、自分で作ったコンテナを使用する、2) 仮想マシンで実行する必要がある場合には、用意されたPowerShellパッケージをアンインストールした後、自分が必要なバージョンを指定した上でインストールする(つまり、バージョンを固定する)仕組みを用意するといった対応を取ったとのことです。
3. GitHubとの疎通の問題によるビルドエラー
次にご紹介するのが、GitHubとの疎通にかかわる問題です。ソフトバンクにおいては、お客様固有のコードはそのお客様用のGitHubリポジトリに格納するものの、ソフトバンクとしてお客様をまたがった形で共通した利用する機能は、Git Moduleに格納した上で接続しています。このGit Moduleの最新化ビルドが時々(数日に一回程度)失敗する、という問題です。
現状では、原因がはっきりとした形でつかめているわけではないため、Git Moduleの最新化ビルドの際には、複数回リトライするような処理を加えるような対応を取ったとのことです。
ただし、Git Moduleを使わないときにはこのような問題は生じないことから、嵯峨氏としては、CircleCI 側で(内部的な動きも含め)問題の調査、解決ができないのかと考えています。
4. ビルドの実行権限管理
さて、実際の業務においては、嵯峨氏をはじめとするソフトバンクの正社員が技術検証し、作成した手順書をもとに、実際の構築作業を派遣社員の方にお願いしているとのことです。とはいえ、デプロイに関しては、正社員が承認することで実行されるようにしたいというニーズがありました。
この「しかるべき責任を持つ人だけが、ビルド承認を可能にする」ことを実現するために、CircleCIが持つContext(本番環境へアクセス可能なシークレット情報を格納したもの)に対して、アクセス可能なメンバーをGitHub上の特定グループに限定するようにしています。
実際には、特定の人だけが承認可能になるわけではなく、前述の承認フローで紹介した「デプロイ」ボタンは誰でも押せるものの、Context(に格納されたシークレット)にアクセスできないメンバーがデプロイしようとしても、必要な情報が得られないためにデプロイがエラーになってしまう、ということで目的を達成しています。
5. コンフィグの肥大化への対応 - Private Orbによる解決
嵯峨氏から「このような取り組みをする中で、CircleCIで多岐にわたる部分が自動化できるようになったものの、その自動化を定義するコンフィグが肥大化、具体的には3000行といった長さになってしまっている」という指摘がありました。
これまでは、コンフィグ全体の見通しを良くするために、ファイルの分割といった手法を取ってきたものの、それでも2000行程度という、短くなったとはいえ、かなりの長さになってしまう、という課題が残されていました。
このコンフィグの肥大化に対しては、(このセッションが実際に行われた)少し前にCircleCIからPrivate Orb機能が提供されたことで、またこのPrivate Orb機能こそが、かねてCircleCIに要望しつづけてきた機能であるということもあり、(かつ、定義可能なPrivate Orbの数に制限が設けられていないため)、CircleCIを「今後もがっつり」使っていきたいという熱い思いを語っていただきました。
さいごに
嵯峨氏から、CircleCIをソフトバンクではこう使っているという話と、CircleCIを使ってもこう困った、こんなトラブルがあったという５つの話をさせていただいたものの、CircleCIに対して、問い合わせのレスポンスの速さや丁寧さ、ユーザ要望を取り入れた機能提供に関して、ご満足いただいているとの言葉をいただきました。嵯峨様、ミートアップでのご登壇、ありがとうございました。
