「毎週Ops Metrics Reviewやってる？」 AWS re:Invent 2024で私が思わずハッとした瞬間
本記事は、Japan Digital Design Advent Calendar 2024 の22日目の記事になります。
三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）でSolution Architectをしている木美です。
本記事は、AWS re:Invent 2024（毎年ラスベガスで開催されるAWS最大のグローバルカンファレンス）の開催前に投稿した以下記事のアンサーブログです。前回紹介した5つのセッションを聴講して、私自身が思わず「ハッ」とさせられた瞬間を振り返ります。セッションの要約や解説は生成AIに任せれば良いので、なるべく私の主観や興味に偏ったごく一部分だけ自由にコメントします。
ARC334 | Building resilient applications on AWS with Capital One
Capital Oneの本セッションで個人的に気になったポイントです。
結局、対策が難しいのはグレー障害
週に一度、Ops Metrics Reviewやってる？
ミッションクリティカルな認証機能で250ミリ秒という厳密なレイテンシ要件を最重要視
結局、対策が難しいのはグレー障害
マルチリージョンやらマルチAZ構成を作ることばかりに気をとられていませんか？
もちろんこれらは前提として大切です。しかし、結局、対策が難しいのはグレー障害です。グレー障害とはシステム的には（AWSのインフラ側や自身が構築した監視機能からは）Healthyに見えるのにお客さまが問題を経験している状態です。
グレー障害にどう対処すればいいのでしょうか？本セッションに登壇したAWSのSAは「Observabilityが最も重要。私が話をした顧客のほとんどが何らかの形で改善できる領域」と言っています。
では、Observabilityはどのように高めていけば良いのでしょうか？
週に一度、Ops Metrics Reviewやってる？
AWS社内での取り組みとして「Ops Metrics Review」が紹介されました。
週に一度、前週のサービスの健全性について担当チームが徹底的に質問される高コストな会議だそうです。単にダッシュボードや綺麗に整えられたレポートをながめる会議ではありません。
この会議により、チームは自発的に（問題が起こる前に）Observabilityを高め続けるようになります。「Observabilityが高い」とは、「未知の事態が発生しても、環境に追加の手を加えず、即座にシステムの内部状態に関する問いに答えられる状態」を指します。つまり、何を聞かれるか分からない大量の質問を毎週乗り切るための準備は、堅牢なObservabilityを構築することと同義になります。
徹底的に質問されると書きましたが、非難や処罰のための会議では決して無いはずです。目的はチームにレジリエンスのオーナーシップを与えることだと理解しています。これはうまい仕組みだなと「ハッと」しました。
ミッションクリティカルな認証機能で250ミリ秒という厳密なレイテンシ要件を最重要視
ここで素晴らしいなと思ったのは「お客さまの気持ちに寄り添ってレイテンシを最重要視した」といの一番に言っていたことです。
お客さまがクレジットカードをスワイプして、食料品の支払いやホテルのチェックインをしようとしているときに、ずっと待たされる状況を想像してみてください
「何を当たり前のことを」と思われるかもしれません。しかし、ミッションクリティカルなシステムでは可用性・完全性を重視するあまり、二重にも三重にもかけた石橋を叩いて叩いて叩き切ってから渡るようなシステム構成でお客さまが体験するレイテンシが二の次になっているケースが見られます。
これに対して、Capital Oneは不正検知を含む認証機能に対して、End-to-Endで250ミリ秒という厳密なレイテンシ要件を設定しています。厳密な要件化により、違反しそうな場合は処理をフォールバックするといった選択が可能になっています。
以上が私の主観や興味に偏った本セッションのごくごく一部分です。
セッション内では、Cell-based Architectureやシンプルで速い復旧方法はルーティングによる回避といったレジリエンスの考え方が紹介されていますので、ぜひチェックしてみてください。
FSI318 | Fidelity Investments: Building for mission-critical resilience
Fidelity Investmentsの本セッションで個人的に気になったポイントです。
FMEA（故障モード影響度解析）やってますか？
Chaos Engineeringにおいて私たちは「科学者」である
CI/CDパイプラインにAWS Fault Injection Serviceを組み込む
FMEA（故障モード影響度解析）やってますか？
FMEAは自動車業界や製造業においては何十年も前から活用されている潜在的な故障モードの分析手法です。
ざっくり言うと、
機能や部品、プロセスを特定
機能や部品、プロセスごとに故障モードとその発生原因をリストアップ
故障の影響を明確化
深刻度・発生確率・検出難易度を1〜10でスコアリング
深刻度×発生確率×検出難易度＝リスク優先度数を計算
という形で故障モードを特定・分析し優先度をつける手法です。
Capital Oneのセッションでも触れましたが、マルチリージョンやらマルチAZ構成を作ることばかりに気をとられていませんか？このような分析を勘や経験、思いつきではなく、体系的に行っていますか？
Chaos Engineeringにおいて私たちは「科学者」である
マッドサイエンティストではありません。Chaos Engineeringを行うとき、私たちは責任ある科学者です。
科学者は未知なるものを探求するために仮説を立て実験を行います。既知のことを検証することは科学者の最終的なゴールにはなりません。科学者は顕微鏡や測定器を使って実験をつぶさに観察・記録します。ウイルスの研究中に実験が制御不能になり、街をゾンビタウンにすることは絶対に避けなければなりません。制御された環境下で実験を行い、万が一のために緊急停止用の安全レバーが必須になります。
ついつい誤解されがちなChaos Engineeringについて説明するときにこの説明は良さそうです。
CI/CDパイプラインにAWS Fault Injection Serviceを組み込む
セキュリティと同様にレジリエンスもシフトレフト（開発プロセスのなるべく早期に問題を発見・対処する）の考え方が効果的です。シフトレフトにより、レジリエンスに対する開発者のオーナーシップを高め、レジリエンスを維持しながら短期間で頻繁なリリースを可能にします。
CI/CDパイプラインにAWS Fault Injection Serviceを組み込むのはぜひ参考にしたいと思いました。AWS Fault Injection ServiceはChaos Engineeringにもとづく実験を行うためのサービスです。実験がCI/CDパイプラインで実行されるため、環境間での再現性が高まります。このCI/CDパイプラインを通せば本番リリースに対する心理的安全性を高められます。
AWS Fault Injection Serviceを利用するメリットは、アプリケーションコードに障害注入のためのコードを挿入しなくて良いことです。ビジネスロジックと障害注入をシンプルに分離しながら、遅延といった予測が難しい障害モードを再現できます。アプリケーションコードとパイプラインの結合を弱くできるので、CI/CDパイプラインに組み込むにあたってこれは重要な要素になります。
以上が私の主観や興味に偏った本セッションのごくごく一部分です。
セッションでは、レジリエンス向上の取り組みの中で古典的なFMEAを実践し、その中でAWS Fault Injection Serviceをどのように活用していくか、本質的・実践的に紹介されていますので、ぜひチェックしてみてください。
FSI321 | How Stripe achieves five and a half 9s of availability
Stripeの本セッションで個人的に気になったポイントです。
「Stripeのやり方を真似しよう」とは考えない
結局、対策が難しいのはグレー障害
信頼性は単なる指標ではなくマインドセット？
「Stripeのやり方を真似しよう」とは考えない
当たり前ですが、他社の事例をそのまま適用してもうまくいくわけがなければ、迷走すらしがちです（ただの事例収集家が迷惑な理由）。
本セッションやCapital Oneのセッション、Keynoteでも、Cell-based Architectureが取り上げられています。しかし、本セッションで述べられているようなCell-based Architectureは可能な限り導入しない方が良いのです。必要に迫られていない場合、コストと複雑性だけが増大してしまいます。
まずは、自分たちがStripeと同様に99.9995%の可用性でグローバルにサービス展開し、ピーク時には毎秒25,000件以上のリクエストをさばいているか考えてみてください。Stripeはこれを実現するためにCell-based Architectureが必要だったのです。
結局、対策が難しいのはグレー障害
Capital Oneのセッションと同じ話です。やはり、頭を悩ますべきはグレー障害ということです。
信頼性は単なる指標ではなくマインドセット？
AWSは「セキュリティはカルチャー」と繰り返し強調しています。レジリエンスも同様です。技術的な仕組みだけで高められるものではありません。
「カルチャーってなんやねん」というとレジリエンスのオーナーシップをチームに与えることです。Capital OneのセッションでもOps Metrics Reviewによりチームにオーナーシップを与える話がありました。
99.9995%という可用性目標を設定することも文化醸成の一翼を担っています。99.9995%に対するエラーバジェット内で障害を検知し対応できるのは機械だけです。99.9995%ということは1ヶ月で見るとわずか13秒の余裕しかありません。復旧に人手が関与すると当然間に合いません。チームは「機械にやらせるべき仕事を人にさせない」というマインドで立ち向かうしかありません。
以上が私の主観や興味に偏った本セッションのごくごく一部分です。
セッションでは、Stripeのレジリエンスへの取り組みが技術・文化の両面で紹介されています。あくまで、99.9995%の可用性でグローバルにサービス展開し、ピーク時には毎秒25,000件以上のリクエストをさばくための事例ということを念頭に置いてチェックしてみてください。
FSI322 | How Vanguard rebuilt its mission-critical trading application on AWS
Vanguardの本セッションで個人的に気になったポイントです。
通常のマイクロサービスとは異なるアプローチを採用
EKSではなくECS+Fargateを採用
その時点で最善と思われる決定を下して前進しつつ変更を厭わない姿勢が重要
通常のマイクロサービスとは異なるアプローチを採用
本セッションの特徴はCapital OneやStripeのセッションとは異なり、既存のレガシーと向き合っていることです。
Vanguardはモダナイゼーションを進める中でモノリスを分解し、コンテキスト境界に分割しています。ただし、データベースは1つにまとめたままで、その周辺にAPIを配置するというパターンを取っています。
アーキテクチャには銀の弾丸もなければ、何が正解かも検討・決定時点では分からないものです。Vanguardは「通常」や事例に踊らされず、自分たちの頭で判断しているのだと感じ取れました。
EKSではなくECS+Fargateを採用
ミッションクリティカルで大規模な事例ではEKSが採用されているケースが多い印象です。一方、Vanguardは「自分たちにEKSの機能が本当に必要か？」をしっかりと見極めたうえで、ECS+Fargateを採用しています。これも非常に実直な姿勢に感じました。また、この決定は定期的に再評価しており、EKSに移行すべきかという自問も常に出ているという姿勢も見習うべきものです。
その時点で最善と思われる決定を下して前進しつつ変更を厭わない姿勢が重要
Vanguardにおけるアーキテクチャ選定の姿勢はこの方針に集約されています。Dr. Werner Vogels KeynoteでもS3のプロダクトチームが「1〜2年後にはS3において同じアーキテクチャは使っていないことを知っていた」と話していました。この姿勢はクラウドを使っていくうえでは本当に重要です。自らの状況や外部環境、取りうる選択肢も日々変化し続けます。
以上が私の主観や興味に偏った本セッションのごくごく一部分です。
このセッションはCapital OneやStripeのような尖った話ではありません。一方で実直に地に足がついた事例なのでぜひチェックしてみてください。
FSI314 | Service event replay: Stress-testing your architecture’s resilience
こちらはChalk Talk（ホワイトボードを用いた即興セッション）のためアーカイブ動画があがっておらず、おうちre:Inventの私には情報が得られませんでした…
おそらく、以下のResilience lifecycle frameworkのような議論がされたのではないかと妄想します（参加した方がいれば教えてください）。
まとめ
re:Invent 2024の金融セッションを通して、ミッションクリティカルで大規模な事例が本当に増えてきているなと感じました。AWS活用のフェーズが一段進んだような印象です。そんな中で、アーキテクチャだけでなく、Ops Metrics Reviewといった仕組みを通して、レジリエンスのオーナーシップを持たせることに注力していることが分かりました。日本のAWS活用も、もう一段、フェーズが進みそうだなとそんな期待を胸に今後の動向もウォッチしていきたいと思います。
最後までご覧いただきありがとうございました！
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。
この記事に関するお問い合わせはこちらにお願いします。
Technology & Development Division
Architecture Team Lead / Senior Solution Architect
Yuta Kimi