Oracle Red Bull Racing、1Passwordで風洞試験の復旧時間を97%短縮

F1世界選手権で複数回の王座に輝いたOracle Red Bull Racingは、工場、風洞、シミュレーションのワークロードに散らばっていたシークレットを1Passwordに集約し、風洞試験中のソフトウェア障害からの復旧時間を1時間から約2分へ、97%短縮しました。風洞の技術者は、ボタン1つで全体をデプロイし直せるようになっています。同チームは2005年、親会社Red Bullのモータースポーツでの存在感を広げ、情熱と遊び心、野心と実績を組み合わせて競技の常識を覆すことを目指して設立されました。コンストラクターズとドライバーズのワールドタイトルを複数回獲得し、100を超えるレースでの勝利を重ね、F1で最も成功したチームの1つに成長しています。

導入前：限られた試験時間をクレデンシャルの調整が奪っていた

同チームは、英国ミルトン・キーンズの拠点と世界各地のサーキットで1,800名を超えるメンバーを抱えています。2億1,500万ドルの予算上限とFIAの空力試験の制限があるため、シミュレーターと風洞での試験時間は1分たりとも無駄にできません。エンドユーザーサービスのグループ責任者のNimesh Kotecha氏は、F1には潤沢な資金があると思われがちだが、予算上限のもとでは全てのライセンスに正当な理由が要り、誰が何を使っているかを把握して賢く判断する必要があったと話しています。

同チームが抱えていた課題は、まずクレデンシャルを一元的に管理できていなかったことです。複数のクラスターにまたがる複雑な技術環境のもとで、拠点とサーキットのスタッフに対するクレデンシャルの配布とアクセスにばらつきがありました。次に、パイプラインの復旧が手作業だったことです。工場、風洞、シミュレーションの重要なパイプラインが停止すると、クレデンシャルを手作業で調整して復旧する必要があり、貴重な試験時間が失われていました。さらに、シークレットを安全に共有する手段もありませんでした。シークレットの管理が分散し、クレデンシャルがコードや設定ファイルに埋め込まれたり場当たり的に共有されていたため、開発の提供が遅れ、CFD（数値流体力学）のワークフローを自動化する余地も限られていました。

選定：エンジニアリング全体のシークレットを1カ所に

同チームはシークレットを1Passwordに移し、Kubernetesのクラスター、環境、名前空間、そして工場、風洞、シミュレーションのワークロードにまたがるクレデンシャルを、信頼できる単一の基盤で管理するようにしました。開発者は、所有者が明確で再現性のある形の共有保管庫を使い、デプロイし直す際やワークフローを変える際も想定した通りにアクセスできます。

人によるアクセスと自動化によるアクセスは、専用の保管庫で分けています。Aeroクラスターをはじめとする重要なKubernetesのワークロード向けの保管庫は、利用者を限定しています。1Password Kubernetes Operatorは1PasswordのConnectサーバーを通じて認証し、1Passwordのアイテムから値を取得して、ワークロード用のKubernetesのSecretを作ります。アイテムが変わるとOperatorがSecretを更新し、ロールアウトを起動すればワークロードが新しい値を読み込みます。

空力部門では5つの保管庫に97件のエントリーがあり、クラスターのクレデンシャル、SQLのパスワード、クライアントシークレット、アクセストークン、WindowsのVMのログイン情報を保管しています。車両パフォーマンス部門とパワートレイン部門も約160件を管理しており、新しいデプロイでは1Passwordを使うのが標準になりました。これによりアクセスの調整にかかる時間が減り、場当たり的な共有も抑えられ、開発者がワークロードを変更・復元する際にどのクレデンシャルが最新かを確かめやすくなっています。同氏は、以前はアクセスの調整だけで時間を失っていたが、今は問題に最も近い人がガードレールのもとですぐに動けるため、速さと引き換えに危うい近道を選ぶ必要がなくなったと述べています。

数字で見た導入効果

風洞の復旧時間を1時間から約2分へ

風洞試験では、マシンにアップグレードを投入する前に、空気の流れ、冷却、バランス、部品の変更を確かめます。空力チームは8週間ごとに風洞の走行回数と送風時間が規定されているため、1回の中断も大きな意味を持ちます。

以前はパイプラインが停止すると、風洞試験は完了前に止まり、貴重な試験時間が失われてマシンの開発も遅れていました。ボトルネックは調整です。誰に連絡するか、どのクレデンシャルが必要か、どう復旧を始めるかを、特に業務時間外に判断しなければなりませんでした。手作業でデプロイし直すには、正しい再起動の順序とKubernetesやKafkaの構成を知る専門家が必要でした。全体をデプロイし直すと、約20のサービスと複数のKafkaのトピックが対象になります。

以前は最大1時間かかっていた復旧は、1Passwordを使った復旧のプレーブックによって、AnsibleとRunDeckで完全に自動化されました。現在は風洞の技術者がボタン1つで、約2分のうちに全体をデプロイし直せます。プレーブックは、ローテーションできる専用のアクセストークンで認証し、実行時に必要なシークレットを取得します。同氏は、シークレットとアクセスの置き場所を標準化したことで復旧が再現可能になり、障害時にクレデンシャルを探し回るのではなく、決まったセルフサービスの手順を始められるようになったと述べています。

シミュレーションから平文のクレデンシャルを排除

シミュレーションは、変更の費用が小さく、結果がその後の判断を左右する早い段階で最も価値を発揮します。一方で、新しいAPIを統合するとシークレットが散らばり、リスクが高まりかねません。同チームには、クレデンシャルとシークレットを一貫して管理する方法が必要でした。

シミュレーションのワークフローでは、1Password CLIを使い、サービスへのアクセスに必要なSQLの接続文字列とMicrosoft Entra IDのクレデンシャルを取得しています。開発者はコードや設定ファイルにシークレットを埋め込む代わりに、管理された共有の情報源を指すシークレット参照を使います。アプリケーションがシークレット参照に依存しているため、クレデンシャルを安全にローテーションでき、自動化をより安全に進め、APIを早い段階で取り込めるようになりました。同氏は、コードから平文のパスワードがなくなり、安全な参照を使えるようになったことは開発者にとって画期的だったと評価しています。

リリースサイクルの短縮

環境全体でクレデンシャル管理が広く定着したことで、ソフトウェアのリリースサイクルも短くなりました。空力担当ソフトウェアエンジニアリング責任者のIan Brunton氏は、組織全体として見ると、1Passwordは非常に複雑で変化の速いエンジニアリング環境のアクセス管理に規律と明確さをもたらしたと述べています。

今後：レース当日のインフラストラクチャーへ

同チームはレースウィークエンドに、リアルタイムのモンテカルロモデルを使った高度なレースシミュレーションでシナリオを評価し、戦略の判断を支えています。エンジニアリング全体でシークレットとアクセスの標準化が進んだことから、クレデンシャルと証明書の管理を含め、同じ仕組みをOCIを基盤とするサーキット側のシステムへ広げる検討を進めています。レース当日の時間的な制約のもとでも、一貫した自動化を保つためです。同氏は、レジリエンスは性能上の強みであり、アクセスとシークレットが信頼できれば、エンジニアは権限を待つことや障害の後始末ではなく、改善を届けることに時間を使えると述べています。

この導入事例からの学び

同チームの成果の中心は、障害からの復旧を属人的な調整から、誰でも起動できる手順に変えたことです。その前提になったのは、シークレットの置き場所を1つに定めたことでした。試験時間や保守時間に厳しい制約のある組織が確認すべきは2点です。1つは、パイプラインの復旧に必要なクレデンシャルを、人を介さずに実行時に取得できるかどうかという点です。ここが手作業のままだと、復旧の速さは連絡のつく専門家がいるかどうかで決まります。もう1つは、コードからシークレットを外し、参照に置き換えられるかどうかです。同チームでは、これがクレデンシャルのローテーションとAPIの早期の取り込みを両立させる土台になっています。

出典：1Password