Lowe’s が Google SRE プラクティスで顧客の要求に応えている方法
Google Cloud Japan Team
※この投稿は米国時間 2021 年 6 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: 今回の投稿では、Lowe’s の SRE チームの声をご紹介します。同社が Google のサイト信頼性エンジニアリング（SRE）フレームワークを導入し、Google Cloud とのパートナーシップを活用して、サポートできるリリース数をどのように増加させたかをご説明いただきます。
Lowe’s では、複数年にわたるテクノロジー トランスフォーメーションで大きな成果を達成しました。自社システムをモダナイズし、お客様と社員向けの新たな機能を構築するために、Google の SRE フレームワークと Google Cloud を活用しています。おかげで、お客様と社員のニーズをスピーディかつ効率的に満たすことができています。こうした取り組みにより、リリースの頻度を 2 週間に 1 回から 1 日 20 回以上に増加させることができました。1 か月あたりのリリース数が約 20 倍に増えたのです。
ただし、SRE トランスフォーメーションを一夜にして実現できたわけではありません。取り組みの各段階でいくつかの課題に直面しました。ただ、振り返ってみると、最終的にお客様のために達成できた成果について大変満足しています。
まだ SRE プラクティスを導入していなかった 2018 年には、先回りではなく何か問題が起きてから対処しており、常時監視アプローチをとっていました。オンコール体制とインシデント管理の効率性は最適なレベルとは言えず、反復作業と手動作業が多すぎて運用上のトイルが発生していました。本番環境の懸念が製品ロードマップに反映されていなかったため、修正を行うのが遅れていました。
Lowe’s における SRE のブートストラップの取り組み
オンプレミスから Google Cloud への移行を進めるなか、モノリシック アーキテクチャからマイクロサービス ベースのアーキテクチャに乗り換えることを決定しました。また、この新しいアーキテクチャをより適切に管理できるよう、SRE の取り組みを始めることにしました。
そのタイミングで襲い掛かってきたのが COVID-19（新型コロナウイルス感染症）です。フルリフォームのニーズを満たすために、オンラインの注文と配達を利用するお客様が増えるなか、当社ではこの取り組みを一層加速させる必要がありました。これを実現するために、以下の 4 つの基本原則に従いました。おかげで、急速に変化するお客様のニーズに応え、スピーディかつ信頼性の高い形でリリースを行うことができました。
トイルの自動化
従来型の運用から SRE エコシステムに移行するなかで、最大の課題はトイルを削減することでした。トイルを削減することで、エンジニアはビジネスにプラスの影響をもたらし、お客様満足度を向上させる業務に時間を費やせるようになります。手動かつ反復的で、マニュアル化され、永続的な価値を生み出さない、自動化可能な作業を当社では「トイル」と定義しています。トイルに対処するために、手動作業を自動化することに力を入れました。その取り組みの一環として、アラートが上がっても真っ先にエンジニアに連絡が入らないようにしました。エンジニアで対応できるトリアージや修正は、トレーニングを受けたマシンでも対応できます。トイルの自動化に使ったのが教師あり学習と教師なし学習の手法です。「トイルをなくす」という長期目標のもと、当社の SRE は組織全体のトイルを特定し、その量を対処可能なレベルにまで削減することに取り組んでいます。ロードマップ全体にわたるエンジニアの意識統一
当社の目標は、開発チームのエンジニアリング スピードを最大化しながら、製品の信頼性を維持することです。当社が求めているのは、プロダクト、SRE、開発の各チームが緊密に連携するエンゲージメント モデルです。主に、SRE をドメインチームとプロダクト チームに配置することで、このようなモデルを実現しています。ドメインごとに SRE が配置されており、プロダクト開発の初期段階に関わることで、SRE イニシアティブに沿ってドメインのステークホルダーに開発を進めてもらうようにしています。こうすることで、SRE はサービス ライフサイクルのすべてのフェーズを通してサービスの信頼性、パフォーマンス、スケーラビリティ、リリースまでにかかる時間を改善できます。ワンタッチ リリースの導入
当社ではかつて、本番環境にデプロイするまでに多数の手動ステップと検証を行っていたため、機能をリリースする頻度が低くなっていました。また、複数のリリースを一括でデプロイしていたため、失敗のリスクが高くなり、本番環境からのフィードバック ループが長くなっていました。SRE のマインドセットでこれに対処するべく、SRE がプロダクト チームの pull リクエストをレビューするワンタッチ リリース プロセスを構築しました。リクエストが承認されると、承認された変更を本番環境に安全にデプロイする DevSecOps パイプラインがトリガーされます。このプロセスにより、安全で信頼性が高く、持続可能な継続的デリバリー パイプラインとスピーディなフィードバック ループが構築されました。スピード、イノベーション、安定性の間で最適なバランスを取ることで、年間のリリース数を飛躍的に増やすことができました。リリース 1 件につき 30 分もかからずに、自動化されたさまざまな品質チェックやプロセスなど、質の高いコードをわずかワンクリックでデリバリーすることができたのです。キャパシティ プランニングの導入
トラフィック パターンの急増にも対処できる十分な予備キャパシティをサービスに用意するために、当社の SRE はキャパシティ プランニングに力を入れることで推奨されるキャパシティの変更を継続的デリバリー（CD）パイプラインに施しています。SRE は継続的にパフォーマンスをモニタリングして、サービスの堅牢性、安定性、可用性を維持しています。また、予想していた以上にトラフィックが急増した場合は、SRE がオンデマンドでキャパシティを変更し、パフォーマンス チームとドメインチームのために変更内容を記録します。
ブラック フライデーとサイバー マンデー（BFCM）など、負荷がピークに達するホリデー シーズンにはキャパシティ プランニングが特に重要になります。当社ではシーズンの 3 か月前から SRE 安定化計画を立て、その計画をドメインチームのプロダクト ロードマップに反映させています。こうすることで、開発チームは信頼性の維持に十分なエンジニアリング時間を割り当てることができます。パフォーマンス テストを実施することで、負荷の増加に環境が長期間にわたって耐えることができるだけでなく、トラフィックの急増にも対処できることを確認しています。また、グローバル規模でリージョンごとのフェイルオーバー テストを実施して、サービスレベル契約（SLA）の自動フェイルオーバー期間、SRE とドメインの準備体制を検証しています。さらに、ブラック フライデーとサイバー マンデーに特化した、高い負荷をかけるテストを実施することで、カスタマー エクスペリエンスや信頼性などを検証しています。
Google Cloud のブラック フライデーおよびサイバー マンデー ホワイト グローブ サービスは、2019 年と 2020 年の BFCM で成功を収めるうえで重要な役割を果たしてくれました。このサービスでは、Google の顧客信頼性エンジニアリング（CRE）チームの担当者が現場を訪ねてくれました。担当者は Lowe’s のウェブ アーキテクチャやキャパシティ プランニング、イベントリスクに対する運用プラクティスをレビューして、インシデント対応のベスト プラクティスなどに関するワークショップを実施してくれました。
今後の対応
改善の余地は常にあり、Lowe’s では引き続き SRE プラクティスの改善に取り組んでいきます。当社にとって特にうまくいったのが、今後も継続を予定しているロードショーです。ロードショーでは、SRE に関する最新の原則やベスト プラクティスをシニア SRE リードが他の SRE やアプリケーション ドメイン チームに紹介しながら、リアルタイムでフィードバックを受け取ります。
SRE プラクティスの変革とお客様向けサービスの向上において、Google のツールと方法論がとても役立ちました。Lowe’s で SRE の取り組みを継続していくなかで、さらに勢いを増しながらパートナーシップを構築していけるのを楽しみにしています。
Google Cloud に SRE のベスト プラクティスを導入する方法については、こちらのドキュメントをご覧ください。Google SRE の詳細についてはこちらのウェブサイトをご覧ください。Lowe’s がどのようにしてエンジニアにトレーニングを実施して SRE のプラクティスとツールを導入し、SRE 原則に沿って平均復元時間（MTTR）を向上させたかをご紹介する次回のブログもぜひご覧ください。
-Lowe’s Companies, Inc. デジタル SRE およびオペレーション担当ディレクター Vivek Balivada
-Lowe’s Companies, Inc. デジタル SRE 担当シニア マネージャー Rahul Mohan Kola Kandy
