CircleCI プラットフォームの信頼性強化に向けた取り組み

取り組みのご報告: 2023 年 4 月 14 日

信頼性の強化に取り組み続けている CircleCI は、歩みを進め、たくさんの学びを得ています。ただ、まだ道半ばであるのも確かです。

なぜそれがわかるかというと、改善の余地をさらに細かく把握するためにデータを深く掘り下げているからです。前回の投稿では、CircleCI の信頼性に対する考え方や主な成果を示すために、具体的な数字を挙げることをお約束しました。

障害を完全に防ぐことは難しいため、CircleCI はインシデントの期間 (とりわけ 60 分を超えるもの) の短縮に力を尽くしてきました。

また重点的に取り組んでいるのが、システム内で障害が発生したときでもビルドを続行可能な状態で維持することです。CircleCI は、この最優先事項を守り続けると共に、お客様への影響を最小限に抑えようとする取り組みを重視しており、それを表す数値を “ビルドインパクト” と呼んでいます。

データからわかること

下図の「Extended Incidents (長期間のインシデント)」グラフは、月ごとの 60 分を超えるインシデントの件数を表したものです。件数は 0 またはほぼ 0 であることが理想的ですが、去年の 4 月から悪化の傾向にあります。CircleCI はこの期間、インシデントへの対応能力に多大なる投資を行いました。チーム全体が CircleCI の分散システムの複雑さを隅々まで理解して、そこからわかる情報を基に決断を下せるようになりました。

もう 1 つ、下図の「 Build Impact (ビルドインパクト」グラフには、過去 12 か月間で発生したインシデントがビルドに与えた影響について、報告期間の開始時 (2022 年 4 月) で正規化した結果を示しています。昨年 4 月のビルドへの影響レベルを 1 として、目標を 0 またはその周辺としています。2022 年 4 月以降は、クリティカルパスを保護しお客様のビルドへの影響を防ぐためにシステムのセクションの分離を最優先に進めており、ある程度の状況改善が見られました。

ただし、2023 年 3 月は Kubernetes のアップグレードで問題が発生し、厳しい 1 か月となりました。詳細についてはこちら (英語)をご覧ください。

CircleCI が目指す場所

CircleCI の目標は、信頼性レベルを上げて、本番インフラの変化が影響する範囲を抑え続け、可能な限り徹底的にテストを行うことです。Kubernetes、そして CircleCI のインフラ全体については、CircleCI のリスク基準を満たすようにアップグレード戦略を強化しています。また、主要な本番クラスタへのアップグレードを次に実行するときは、事前に新しいパスを確保します。

みなさまにお伝えしたいのは、みなさまに価値を提供するためにはプラットフォームの信頼性を強化し続けることが不可欠であり、この投稿もその一環であるということです。これは決して簡単ではなく、手間もかかります。ソフトウェアエンジニアなら、だれもが口をそろえてそう言うでしょう。

本腰を据えて取り組めば、改善できないものはありません。とはいえ、ここはお祝いではなく、報告のための場です。課題はまだ残されています。とりわけみなさまに知っていただきたいのは、CircleCI は今も原因の解消に取り組んでいるということです。

引き続き、ご理解とご協力のほどを、どうぞよろしくお願い申し上げます。

Rob Zuber

取り組みのご報告: 2023 年 1 月 30 日

CircleCI の信頼性強化に向けた取り組みを報告するこの場所では、成果と課題、そしていつでもビルドの行えるプラットフォームを実現するために CircleCI が背後で行っていることを、4 回にわたって説明してまいりました。

今月はセキュリティインシデントが発生し、みなさまの業務に支障をきたす事態となりました。

したがって、今回の報告では、次の 2 点の取り組みについてのみ簡潔にご報告いたします。

1. CircleCI にとって現時点での最優先事項は、インシデントの影響を注視し続けることです。このために、みなさまにはパイプラインが侵害されていないことの確認とシークレットのローテーションをお願いしております。インシデント対応はどれだけの時間がかかってもやり抜きますが、通常業務に戻った暁には、具体的な数字を挙げて取り組みをご報告する予定です。信頼性強化への取り組みの指標となる本質的なメトリクスを、みなさまにお知らせいたします。

2. システムについて考えると、実は信頼性とセキュリティが同じ場所に行きつくことがわかります。信頼性を強化するものは、同時にセキュリティも強化するのです。システムの部分をよりクリーンに分離したり、サードパーティで検証済みの監査ポイントと監査ログを維持したりするなど、信頼性強化のために CircleCI が実施してきた取り組みによって、セキュリティインシデントからの復旧能力も高まっていました。みなさまがお仕事を遂行する上では、セキュリティと信頼性のどちらも欠くことはできません。CircleCI の目標は、高セキュリティおよび高可用性のシステムの水準を上げ続けることです。

シークレットのローテーションがお済みでない方は、こちらの手順に従ってローテーションをお願いいたします (英語)。既にご対応いただいているみなさまには、ご協力感謝申し上げます。

次回の信頼性強化の取り組みに関する報告をお待ちください。

Rob Zuber

取り組みのご報告: 2022 年 12 月 21 日

前回と前々回の報告では、サービスのコアにおいて長期的な信頼性を構築するための取り組みをいくつかご紹介してきました。今回は、根本的な問題をどのように突き止めたのかについて少しお話させてください。具体的に言うと、組織やアーキテクチャに見られるシステム的な問題に目を向けました。

多くの組織と同様、CircleCI ではソフトウェアデリバリーに “開発者が運用する” というアプローチを取っています。つまり、開発チームは自身のデリバリーストリームのライフサイクル全体に責任を持つということです。また CircleCI では、インシデントの調査とフォローアップの手法を共有しています。ところが、ライフサイクル全体をチーム自身で管理できるがゆえに、よりシステム的な問題を見逃すという事態を招いてしまいました。そうした問題が、フォローアップに対処している個々のチームにのみ存在していると考えてしまったのです。

今年、CircleCI のすべてのソースからデータを集約することで、これらのシステム的な問題に注意を向けました。たとえば、インシデント後のレポート、関連する履歴データ、そして個々のチームが実施したフォローアップ作業すべてに目を行き渡らせました。全データの棚卸しも確かに重要でしたが、特筆すべきは、改善に必要なデータの集約をどのように実現したかということです。

CircleCI のツールは、そのほとんどが個々のインシデントを重視しており、集約して確認できるようにはなっていません。インシデント全体のデータを表示するツールからも、私たちの求める情報は得られませんでした。私たちは、インシデント対応において時間がかかった部分から、原因の分類まで、あらゆるものを精査しました。これにより、CircleCI 自体とシステムを全体的にとらえ、影響力が強いものを判断しました。

ほとんどの集約はスプレッドシートで行えましたが、インシデント後のフォローアップの多くは、まるで小説のように書かれていました。このような履歴データを十分に構造化して結論へと導くのは骨が折れる作業でしたが、大局的に物事を見るのに非常に役立ちました。特定のインシデントレポートを読んだり、特定のチームを掘り下げたりするだけではわからないことが見えてきたのです。

このように、ストリームに沿った変化の激しい DevOps 文化は維持しながらも、システム全体を眺めて問題を排除できるようにしたわけですが、興味深い緊張感がそこにはありました。この取り組みによって、組織かアーキテクチャ (またはその両方) に見られる問題をどこで解決すべきか、明確なインサイトを得ることができました。結果、システム的な性質を持つ問題が緩和されたほか、開発チームにガードレールが用意され、アジリティを保ちつつ開発物を維持できるようになりました。このようにデータを集約して確認することで、前もって障害点を見つけてそれに対処するスキルが上がりました。

ビルドを、さらに効率的に。

Rob Zuber

rob@circleci.com

取り組みのご報告: 2022 年 10 月 27 日

先月はみなさまに、信頼性強化に向けた取り組みの進捗、内容、課題について月次報告を行うとお約束しました。

このことで、次に示す 3 つの目標を達成したいと考えています。

1. 現在行っている、信頼性強化に向けた取り組みを強化する
2. 信頼性強化のロードマップをみなさまと深く共有することで、この場で紹介する今後の取り組みについてより詳しいコンテキストを提供する
3. CircleCI の取り組みとインサイトをオープンにして、CircleCI が得た経験をコミュニティも活かせるようにする

ソフトウェアコミュニティでは、サービスが停止するとだれもが例外なくダメージを受けますが、学びを共有することで共に歩みを進めています。

先月 (詳しくは 1 つ下の報告をご覧ください)、お客様のビルドを保護して継続的に実行できるよう、プラットフォームの一部分を分離していることをご報告しました。

今回は、”システム分離を行うことで、ビルドをあらゆる事態から守る” という CircleCI の現在のアプローチを詳しくご説明させてください。ただしこれは、単なるアプローチの 1 つで終わるものではありません。ビルド保護の原則は、これから信頼性を強化していくうえでも、プラットフォームであらゆる新しい開発作業を進めるうえでも、私たちを導いてくれる存在です。

どのプラットフォームにも言えることですが、ここまで来ることができたのは進化があってこそです。そこで、CircleCI プラットフォームの歴史を簡単に紐解いてみましょう。

ほとんどの企業がそうであるように、CircleCI も最初はモノリスでした。モノリスにおいては、すべての作業が混合されるのがデフォルトなので、必然的に結合が生まれ、障害がカスケードされる可能性が生じます。分離を行わないと、コードベースのどこかで発生した障害が、別の場所の障害へとつながる可能性があります。

CircleCI は、モノリスを分解しました。作業のステージに基づいて分解することもあれば、さまざまなポイントで発生していること (ワークフローオーケストレーションやジョブ実行など) に基づいて分解することもありました。このアプローチにより、コードベースは簡素化されデリバリーは容易になりましたが、ステージ内にはアクティブな作業と、その作業の過去のレポートが混在しています。

現在 CircleCI が行っているのは、これらのステージそれぞれで分離を行い、アクティブなビルドの実行にかかわっているすべてのコンポーネントをあらゆるものから保護できるようにすることです。

この取り組みは、障害を最小限に抑えつつ結果をすばやく出すために、段階的に進めています。まずは、必要に応じて履歴の表示を無効化する機能など、シンプルなツールから開始しました。こうしたツールは、リリースバルブとなります。

また、過去のクエリに読み取り専用のレプリカを使用する頻度を高めました。そして、コードが共有されている場合にもコンピューティングリソースを分離するために、一部のサービスの分割デプロイメントを活用しています。

これから移行する次の段階では、システムを完全に分離します。つまり “コードパスとリアルタイムのビルドのデータ” および “コードパスと履歴データ” に分けるということです。レプリカは負荷分散に便利なものの、ストアのデータ量をどれも同一にする必要があります。これはシャーディングで解決できますが、それでも両方のアクセスパターンをサポートしようとするスキーマ設計は煩わしいものです。完全に分離されていれば、スケール的にも製品機能的にも、各設計を最適化することができます。アプローチの進捗としてはまだ初期の状態ですが、前述したとおり、できるだけ迅速に成果を得られるように段階的なステップを踏んでいます。

ここで、「なぜ最初からそうしなかったのか」と疑問に思われる方もいるでしょう。スケーリングが必要であり、最初からすぐに実行すると失敗の可能性があったというのが、その理由です。というのも、CircleCI のようなプラットフォームを初めて作り、アーキテクチャにまつわる初期の決断をするときは、すばやく方向転換できるような意思決定をして、初期のお客様の要望に応えることが非常に重要だと私は考えます。求めるものがわからなければ、お客様にサポートを提供し満足していただくためにチームが構築すべき機能もわかりません。最初に、ゆくゆくはこのようなプロジェクトを迎えるという想像はできても、無限の可能性がある中で一体どこに落ち着くかを知るのは不可能だというのが、私の意見です。

全体として今回みなさまにお伝えしたいのは、CircleCI はこの事態を重く受け止めており、どの取り組みにも一貫している “段階的” なアプローチを取っているということ、そして CircleCI が下す決断はみなさまのニーズを中心に据えているということです。残念ながらシステムの障害を完全に防ぐことはできませんが、適切に分離を行うことで、 __真の目的へと歩みを進めることができます。それは、プラットフォームやエコシステム全体で何が起ころうとも、みなさまのビルドが毎日実行されるようにすること__です。

今後も、この取り組みの段階的なステップについて月次報告を行います。プラットフォームのご利用に必須の情報ではありませんが、CircleCI が内部で何を行っているのか知っていただきたく、このような報告の場を設けております。

ビルドを、さらに効率的に。

Rob Zuber rob@circleci.com

取り組みのご報告: 2022 年 9 月 19 日

先週、1 日の大部分においてパイプラインページが使用不能になり、みなさまの業務に支障をきたす事態となりました。私はエンジニア兼リーダーとして、作業の流れを止めないこと、そして必要なときにツールを使えることの重要性を理解しております。この障害によりご迷惑をお掛けしましたこと、謹んでお詫び申し上げます。

4 月に申し上げたとおり (詳しくは 1 つ下の報告をご覧ください)、 CTO である私の最優先事項は、CircleCI で発生するインシデントの期間を短縮しその影響を軽微なものに抑えることです。

ですが、先週のような事態になるのであれば、どのような進歩を遂げているのかはっきり見えてこないというのも、また事実かもしれません。

前回の報告以降、CircleCI は診断のスピードアップに力を入れるようになりました。またそれに加え、問題発生時にも作業を完了する (つまりパイプライン実行) 能力を守ることに投資を始めています。いまだ道半ばではあるものの、このように、いくつかの重要な進歩を遂げています。ですが、これまでみなさまがこの取り組みの影響を実感できていないのであれば、技術チームとしても、みなさまとの信頼関係を構築するうえでも、成功しているとは言えません。

中でも特筆すべき進歩は、アーキテクチャの一部分を分離するようになったことです。これで、インシデントの影響を抑制してパイプラインを保護することができ、脱線を防げます。パイプラインの実行が継続されるよう、UI を部分的に一時停止するといった措置が可能になりました。先週はこうした取り組みを行っていましたが、みなさまと共有はしておりませんでした。サイトに障害が起きたことで、何も変わっていないと思われたことでしょう。

繰り返しますが、いまだ CircleCI は道半ばであり、これからも投資に熱を注いでいきます。障害を防ぐのは難しくても、ビルドの実行を保証するためにあらゆる手を尽くすことはできます。たとえ “プラン A” が失敗したとしても、みなさまが作業を完了するための方法について、より適切かつタイムリーな情報を提供していきます。

また、前回の報告から 5 か月になり、信頼性強化への取り組みも進んでいます。今後は、新しい情報について毎月報告いたします。次回の報告までに、ご意見があればぜひお寄せください。

取り組みのご報告: 2022 年 4 月 13 日

CircleCI の使命は、開発者のみなさまがより迅速にイノベーションを実現できるよう、変更を管理することです。しかしながら、この度、CircleCI プラットフォームの信頼性がみなさまの期待を下回る事態が発生しました。CircleCI プラットフォームはデリバリーパイプラインの心臓部。このプラットフォームが停止すればみなさまのリリースプロセスも停止に追い込まれてしまうことは、CircleCI 全メンバーが認識しています。それにもかかわらず、この度のプラットフォーム障害によってユーザーのみなさまに多大な迷惑をお掛けしてしまったことを、この場を借りてお詫びいたします。

プラットフォーム障害の背景

この度の障害について調査した結果、CircleCI のプラットフォームやインフラの一部分のみが原因ではなく、 更新によるバグや依存関係の問題、上流プロバイダーの不安定性などのさまざまな要因が絡み合っていることがわかりました。 本年 1 月の無料プランのアップデート後、CircleCI プラットフォームの使用量と流入トラフィックがともに増加しました。 このようなプラットフォームの負担増加に対しては、モデリングを行い備えていたものの、システムの一部が耐えきれない事態に至ってしまいました。

これらのインシデントの原因について明確なパターンは確認されていません。しかし、根本的な解決には多大な時間がかかるものと想定されます。 インシデント対応計画を見直した結果、緊急事態においてチームの業務に支障が生じていることが判明したためです。 CircleCI では、「非難をしない文化」および DevOps の「開発者が運用する」という原則を全面的に採用しています。しかし、CircleCI ではシステムもチームも分散状態にあるために、メンバーどうしの連携や意見交換、問題の解決に問題が生じていました。

このような状況に至った理由として、 過去 12 か月間で CircleCI エンジニアリング チームをほぼ 2 倍に増員したことが挙げられます。 この増員は計画どおりのものであり、そのおかげで開発スピードが大きく向上しました (先週だけでも 850 回以上デプロイを行っています)。 その一方、こうしたメンバー拡大によって、直感的に得られていた知識が分散され、バラつきが出るようになったことも事実です。 そのため、CircleCI は現在、社内全員に深く広い体系的知識が行き渡るように、体制を再構築する必要性に迫られています。

CircleCI の現在の取り組み

CircleCI にとって、テクノロジーは人のためにあるものです。そのため、人間第一の方針を採用して、プラットフォームの信頼性向上の取り組みを進めています。 先週より、第一対応者 （私を含む） の特命チームを発足し、メンバーが交代で待機し問題解決にあたっています。 このチームは世界各地のメンバーで構成されており、各メンバーには問題の修正権限と、プロセスおよびテクノロジーの両面で長期的な変更を実施する権限が与えられています。 このようなチームを編成したねらいは、インシデントの確認から解決までを速やかに遂行できるエンジニアの影響力を高め、CircleCI 全体に知見を共有しやすくすることにあります。

従来、CircleCI の信頼性向上の取り組みでは、システム全体ではなく、サービス障害の要因であるとわかっている “ホットスポット” (フリート管理やマシンのプロビジョニングなど) に注力していました。 こうしたホットスポットの強化に多大な投資を行い、実際に成果を確認していました。 しかし、CircleCI という組織が成長するにつれて、問題の中心がサービスレベルの障害から、システムの大型化・分散化に伴う複雑な相互作用へと移りました。 特命チームの働きを通じて、プラットフォーム障害を可及的速やかに解消しみなさまへの影響を抑えるとともに、対応から学んだ教訓を活かしてインシデントの根本原因を解消します。

さらに、CircleCI では今後、未来志向でプラットフォームの開発および改修を進めるための投資も行います。 新規に雇用したチーフ アーキテクトを中心として、プラットフォームのスケーラビリティの向上、および長期にわたるプロダクト イノベーションに向けた開発を進めてまいります。

みなさまとの進捗状況の共有について

率直に申し上げて、もう 2 度と同じインシデントを起こさないと確約することはできません。しかし、CircleCI は、こうしたインシデントがみなさまに及ぼす影響を軽微なものに抑えるとお約束します。

長期的にはプラットフォームの安定性向上への投資を続けるとともに、短期的にはインシデントの期間の短縮に尽力します。 インシデントの期間が 1 時間を超えた場合には、status.circleci.com にてインシデント レポートを公開します。

インシデント対応の改善は、CTO である私の最優先事項です。　CircleCI は今、課題に直面しています。しかし、本記事でご紹介した対応計画と特命チームの力で、速やかな改善を実現できると確信しています。 今後とも、CircleCI をどうぞよろしくお願い申し上げます。