ドミノ・ピザUKがいかにSRE機能を構築し、信頼性オペレーションをモダン化したか

ドミノ・ピザは、英国とアイルランド全域に1,200を超える店舗を持つフランチャイズ事業であり、年間1億1,400万枚以上のピザを販売しています。技術的な観点から言うと、店舗数、顧客数、ピザの枚数などから複雑な課題が生じています。顧客は、モバイルアプリ、ウェブサイト、さらにJust Eatなどのオンラインのデリバリプラットフォームという3つの異なるチャネルからピザを注文します。フランチャイズパートナーは、必要に応じて価格変更から、繁忙期における管轄地域の調整まで、全チャネルにわたる複数の変数を管理しています。

継続的改善に向けたフェニックスプロジェクトの一環として、また最新のエンジニアリング原則に従う形で、技術スタック全体にわたるサイト信頼性エンジニアリング（SRE）のケイパビリティの確立を目指しました。このケイパビリティの構築には、ユニークなアプローチが採用されました。学術的理論を取り入れ、それを変革を導くガイドとして活用したのです。

順応するアーキテクチャー：マイクロサービス

従来の組織において典型的なのは、SQLサーバーを使用した標準的なモノリシックアプリケーションです。顧客はウェブブラウザを立ち上げ、バックエンドで取引を行ってピザを購入します。しかし、当社のマイクロサービスアーキテクチャーには、バックエンド経由でフロントエンドアーキテクチャーに連結されている分離したフロントエンドがあります。APIファサードがモノリスと連結され、APIゲートウェイに管理される一連のマイクロサービスが動いています。

モノリスからマイクロサービスへの移行により、ミラーモードでの新機能テストの基盤が整備されました。リアルユーザートラフィックを使用しながらエラーリスクを大幅に低減し、パフォーマンスと信頼性に対する新基準の適用が可能になりました。当社チームは、エンドポイントをミラーモードにして新機能のテストを行い、そのエンドポイントを監視して意図した通りに運用が行われていることを確認できます。その後、新機能を稼働させるためにカナリアテストパターンを使用します。まずアップデートされたシステムでトラフィックの10%をルーティングし、それから徐々に100%まで上げていきます。

最新のSREケイパビリティ構築を始めたときから、私たちは、マイクロサービスアーキテクチャーとAPIゲートウェイが、当社のSREエンジニアがもっとも注力すべきポイントだろうと考えていました。

「ケイパビリティの構造」を活用したSREへのアプローチ

継続的改善のフェニックスプログラムを開始した際、私たちはインシデント対応のコア機能を再構築し、それを信頼性エンジニアリングに変えたいと考えていました。SRE機能の実施を検討し始めた際、私は時間をかけてケイパビリティそのものを扱う学術論文や理論を多く読みました。一般的なケイパビリティの構造とは？組織で新たなケイパビリティを実施しようとする際に大切なことは何なのか？

最初に読んだのは、ドロシー・A・レオナルドの研究でした。彼女の著作『知識の源泉（Wellsprings of Knowledge）』で、彼女はケイパビリティの4つの側面について語っています。すなわち、技術システム、スキル、管理システム、そしてケイパビリティ全般を運用する一連の価値です。また、デイヴィッド・ティースの『ダイナミック・ケイパビリティ（Dynamic Capabilities）』では、ケイパビリティが時間とともにどのように更新され、再定義されるかが説明されています。 

これらの資料を参考にして、私たちは「ケイパビリティの構造」アプローチでSREに臨むことに決めました。また、これを「ケイパビリティピザ」と呼び、6等分に切り分けられるピザに見立てました。

1. 技術システム：フロントエンドおよびバックエンドサービスのドメイン、APIゲートウェイ、New Relicなど
2. スキル：信頼性アーキテクチャー、問題分析、ディストリビューティッド（分散）トレーシング
3. 管理システム：SREシステムの管理と革新、インシデント管理
4. 価値：気づき、大胆さ、技術的、協力と共感、データドリブン
5. 日常業務：信頼性エンジニアリング、監視のセットアップ
6. 学び：新たな技術とスキルを移行させる能力、SREシステムを最適化する能力

ケイパビリティピザに加え、私たちはそのケイパビリティを実行に移すため、再構成可能システムモデルも活用します。当社の開発者は、GitOpsのワークフローと一連の環境を使って、本番環境の製品を左から右へと動かしています。SREエンジニアは、低レベルの設計ドキュメントを確認し、信頼性パターンを分析してから、エンドポイントを可能な限り信頼できるものにする方法を決定することを期待されます。

システムをプロアクティブに監視、改善

SREは、常に監視が必要な特定のコミットメントを伴う、データドリブンな活動です。当社のエンジニアは、レイテンシ、トラフィック、エラー、サチュレーション（飽和度）のゴールデンシグナルを設定しています。それぞれのゴールデンシグナルに、サービスレベル目標（SLO）とエラーバジェットを設定します。このアプローチに関しては、可用性が良い例かもしれません。サーバーに95%の可能性があると判断した場合、エラーバジェットは5%です。12時間リクエストが届くとしたら、そのリクエストの95%が正常に対応される必要があります。もし3%が失敗したら、可用性は97%となり、これはまだエラーバジェットの範囲内です。

New Relicにより、外形監視を使用してゴールデンシグナルをテストし、サイト全体のユーザージャーニーを形成することもできます。良い例のひとつが、モダン化されたログインプロセスの稼働開始時です。ログインはユーザージャーニーの絶好の例であり、私たちは外形監視の可用性と、顧客が全プロセスを完了するのにかかる時間を確認します。もしエンドポイントが間違った方向に向いていれば、レスポンスをオーケストレーションしてシステムを正しい方向に戻すことができます。ひとたびシステムが外形監視のインスタンスで順調に動き始めたら、カナリアテストを始め、それを本番環境へと徐々に移行させていきます。

New Relicは、当社のSREエンジニアがシステムを監視、改善するのに欠かせない役割を果たしています。当社では、アプリケーションパフォーマンスモニタリング（APM）を使用してアーキテクチャースタック全体にわたるアプリケーションの計装を行う一方で、分散トレーシングによりコンポーネントがどう動いているかについての明確な可視化を得ています。分散トレーシングは、分散システムを通過するサービスリクエストを追跡、監視するもので、SREエンジニアがエコシステムを理解するのに欠かせません。

当社のケイパビリティに注目したSREと監視の実践では、エンジニアがインシデント対応にプロアクティブに取り組めるようになりました。また、特定のリリースに際して事前のサポート準備のアクティビティも積極的に行っています。リード開発者がSREエンジニアと一緒にコードを確認するため、その後、SREエンジニアがサービスデスクのリーダーのトレーニングを実施できます。

ゴールデンシグナルとエラーバジェットにより、本番環境へのリリースにおけるリスクが大幅に低減し、変更管理プロセスをモダン化できました。新機能を導入する際、私たちはミラーから始め、次にカナリアテストを行ってライブ環境に移します。エラーバジェットを使い、その機能のリリースに標準的な事前承認の変更管理プロセスを適用できるかを判断し、エンジニアリングの実施を迅速化しています。もしエラーバジェットを超えていなければ、チームはなるべく多くの標準変更を彼らの意向通りに実行できます。

New Relicでパフォーマンスを継続的に追跡し、エラーバジェットが超過していないことを確認します。もしエラーバジェットが超過していたら、その機能にはより時間のかかる、従来的な変更管理プロセスが適用されます。当社のSREマネージャーは毎週エンジニアリング会議を行い、SLIとSLOを使ってライブのエンドポイントをレビューしています。もし間違った傾向を示しているエンドポイントがあれば、対策を講じて正しい方向に戻すことができます。