AWS re:Invent 2023参加報告（後編）ー世界の金融機関が注力していた"Resilience"のための大前提とは？
三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）でSolution Architectをしている木美です。
本記事は、ラスベガスで開催されたAWS最大のグローバルカンファレンス「AWS re:Invent 2023」の参加報告の後編です。
前編では、小笠原さんが生成系AIの盛り上がりについてまとめているので是非ご覧下さい。
「AWS re:Invent 2023参加報告（前編）ーAWS re:Invent 2023で感じた生成系AIの盛り上がり」では、Azure OpenAIとの考え方の違いや、Retrieval Augmented Generation（RAG）アーキテクチャへの注力具合、Custom Model構築への期待が分かりやすくまとめられています。生成系AIにご興味がある方は必読の内容です。
re:Invent 2023全体の注目テーマと言われると、前編で取り扱った「生成系AI」や、Amazon.com CTOのWerner Vogelsの基調講演で話された「Frugal Architect」（倹約的なアーキテクト）だと思います。
ただ、金融セッションに限ってみると「Resilience」が注目テーマだったのではないかと個人的には感じています。Capital One、Vanguard、Goldman Sachsといった大手金融機関がResilienceに関連するセッションを行っており、金融業界向けのワークショップでもResilienceをテーマにしたワークショップがにぎわっていました。
本記事では参加報告の後編として、金融セッションの注目テーマ「Resilience」について世界の金融機関の最新動向を報告したいと思います。
本記事の要約
re:Invent 2023で登壇していた世界の金融機関は「システムの振る舞いを実験・観測する」ことをResilienceと向き合うための当たり前の前提としていた
世界の金融機関はシステムの複雑性を受け入れて未知の障害にも向き合いながら「適切なResilienceを調整し続ける」ことに挑戦している
世界の金融機関の取り組みに対して「AWSもFault Injection / Observabilityサービスを拡充」しており、まずは手軽にAWSサービスで試してみることができる状況にある
“Resilience”とは？
ITシステムにおけるResilienceとは「ITシステムが障害に対応し迅速かつしなやかに復旧する能力」といった説明がされます。
ここでのポイントは「障害が起こる」ということは前提にしている点です。2012 re:Invent Day 2 KeynoteにてWerner Vogelsが次のように言っている通り、すべての構成要素はいつか必ず壊れます。壊れることを前提に迅速に復旧する能力を考えるということがResilienceに取り組む理由になります。
Everything fails, all the time
かつて私がResilienceについて考えているときに、ある人からこんなたとえ話をされました。
ブラジルの 1 匹の蝶の羽ばたきがテキサスで竜巻を引き起こす
これは、複雑なシステムにおいては一部の構成要素の微小な変化が予測不可能な大きな変化を引き起こすことのたとえ話として使われます。
このたとえ話を念頭に考えてみていただきたいのですが、みなさまは自分たちの担当システムで一部の構成要素の小さな障害（1匹の蝶の羽ばたき）が甚大な顧客影響（竜巻）を引き起こさない自信はありますでしょうか？
これがまさにResilienceに向き合うということだと思います。本記事では、そんなResilienceに世界の金融機関がどのように向き合っているのか、re:Invent 2023の金融セッションから学んだ内容を共有したいと思います。
世界の金融機関が”Resilience”と向き合ううえでの当たり前の前提としていたこと
世界の金融機関は”Resilience”と向き合うために「システムの振る舞いを実験・観測すること」を当たり前の前提としていました。
具体的に言うと、カオスエンジニアリングの原則にもとづきシステムに「Fault Injection」（障害注入）を行い、システムの振る舞いを観測できるように「Observability」（可観測性）を確保するということです。
多くの金融機関がカオスエンジニアリングの原則にもとづくFault Injectionを当たり前のように実践し、Observabilityへの取り組みを当たり前の前提として話していたことが、今回のre:Inventの金融セッションでは特に印象に残りました。
ガイドラインや他社事例をもとにResilienceが高そうなアーキテクチャを実装したとしても、実験・観測しない限り適切なResilienceが備わっているかは分かりません。すなわち、実験・観測できるということはResilienceと向き合うための前提事項となります。これが、世界の金融機関がFault InjectionとObservabilityを当たり前の前提としている理由であると考察しています。
Fault InjectionとObservability
本記事において「Fault Injection」と言っているのは、カオスエンジニアリングの原則にもとづく制御された実験のことです。カオスエンジニアリングでは、制御された状況下で障害を再現する実験によって、システムの振る舞いについて理解を深めたり改善点を見つけることで、未知の問題が起こりうるシステムのResilienceに対する自信を構築するプロセスです。
「Observability」とはシステムの内部状態を取得できる状態にあるという性質のことです。システムの「性質」ですので保守性や拡張性などと類似の概念になります。ポイントとしては、今までに見たことのない予測できないことが起こったとしてもシステムの内部状態を直ぐに取得できるシステムはObservabilityが高いと言えるということです。
この2つの要素の関係性ですが、Fault InjectionはObservabilityに依存しています。なぜなら、Observabilityがない状態でただ闇雲にFault Injectionをしてもそれは実験とは言えず実施する意味がないからです。目をつぶったままFault Injectionをしても何が起こったのか分かりませんし、そもそも「正常」がどのような状態かも分からないので、異常なのか正常なのかも判断できません。そのため、本記事でもFault InjectionとObservabilityをセットでお話します。
Resilienceはテストとモニタリングを入念に実施すれば確保できるのか
Fault InjectionとObservabilityの話をすると「テストとモニタリングを入念に実施しているので大丈夫」と思う方がいらっしゃるかもしれません。
世界の金融機関も当然テストやモニタリングは入念に実施していると思いますが、それだけで大丈夫とは思っていません。なぜなら、世界の金融機関はテストやモニタリングだけでなく、Fault InjectionやObservabilityにも取り組んでいるからです。
では、両者の違いを考えてみたいと思います。モニタリングとはあらかじめ定められた基準で「既知の」システムの状態変化を把握する行為と言えます。テストは「既知の」条件下で「既知の」システムの振る舞いを確認するプロセスと言えます。つまり、モニタリングやテストがターゲットにしているのは「既知の」障害になります。
一方で、Fault InjectionやObservabilityがターゲットにしているのは「未知の」障害です。Fault Injectionは実験によってプロアクティブに「未知の」システムの振る舞いや特性を理解するプロセスです。Observabilityは予測不可能な「未知の」ことが起こったとしてシステムの内部状態を取得できるという性質を指します。
世界の金融機関は既知の障害だけでなく未知の障害にも向き合うためにモニタリングやテストに加えて、Fault InjectionやObservabilityにも取り組んでいるということです。
一点だけ補足しておくと、テストやモニタリングは変わらず重要であり欠かせないものです。テストやモニタリングはしっかりと行っていることを前提として、Fault InjectionやObservabilityに追加で取り組んでいくという姿勢になります。Observabilityを向上した結果、そこでの気付きをモニタリングに反映する。Fault Injectionによる実験の結果をテストに反映する。このようなプロセスも行うべきことですので、これらは排他的なものではないという点は念のため補足しておきます。
システムのすべてを予測し「既知」にすることは可能なのか
「未知の障害に向き合う」なんて言うと、偉い人から「全部洗い出して既知にしろ！」と言われるかもしれません。しかし、これが現実的ではないということは実感されているかと思います。過去に甚大な影響を及ぼしたような大きな障害の多くは「既知の障害」ではなかったはずです。
すべてを既知にすることがなぜ難しいかと言うと、複雑で変化し続けるクラウド上のシステムの振る舞いは予測困難だからです。以下の例はすべてクラウドのベストプラクティスにそった設計です。これらの構成を取るとクラウドの利点を活かせますが、システムの内部動作は動的で複雑になり予測困難になります。
そこに発生する障害モードも多様です。単純にインスタンスが落ちるという障害であれば分かりやすいですが、一部のコンポーネントで散発的にレイテンシが増加するといった予測が難しい障害も起こりえます。AWSのPrincipal System Dev EngineerであるAdrian Hornsby氏もブログ記事Injecting Chaos to AWS Lambda functions using Lambda Layersの中で次のように言っています。
レイテンシが分散システムのサイレントキラーである
そんな状況において、システムが取りうるすべての挙動を机上で予測し、監視アラームを網羅的に設定したり、結合テストを網羅的にやり切ることは現実的ではないと言えます。
複雑性は排除すべきものなのか
「複雑で変化し続けるクラウド上のシステムの振る舞いは予測困難」なんて話をすると、偉い人から「複雑にするからダメなんだ。シンプルにしろ！」と言われるかもしれません。
しかし、世界の金融機関はそのような複雑性への向き合い方はしていません。複雑性を受け入れるための仕組みの整備に注力しており、そのひとつがFault InjectionとObservabilityです。
システムの機能拡張や改善はシステムに複雑性を追加することにつながります。新しい機能・サービスをリリースする。Resilienceのために冗長性を追加する。オートスケールする仕組みを導入する。パフォーマンス改善のためにキャッシュレイヤを追加する。これらはすべて複雑性を追加する行為です。言い換えると、複雑性を受け入れることで事業を拡大したりシステム特性を改善することができます。複雑性を過度に排除しようとすると何もできなくなってしまいます。そのため、複雑性を受け入れる仕組みの整備に注力していると考えられます。
複雑性と向き合うためのさらなる困難
1度だけ複雑性に対処すれば終わりではありません。Werner Vogelsの基調講演「AWS re:Invent 2023 - Keynote」で以下のような話がありました。
Architecting is a Series of Trade-offs
アーキテクチャの決定はトレードオフの連続です。全ての特性において満点のアーキテクチャは存在せず、ビジネス環境の変化や時間・フェーズの経過によってバランスの取れた最適点は変化し続けます。すなわち、トレードオフの中で適切なResilienceを調整し続ける必要があります。
Capital Oneのセッション「AWS re:Invent 2023 - Capital One: Achieving resiliency to run mission-critical applications (FSI314)」でこんな話をしていました。
コスト、パフォーマンス、信頼性・可用性の間の微妙なバランスを常に調整し続けなければならない
仮に、1度だけ頑張ってすべてを予測しシステムの挙動を洗い出したとしても、それで終わりではありません。複雑性の中でResilienceを調整し続けるプロセスが必要になります。
Resilienceを調整し続けるプロセス
Resilienceを調整し続けるプロセスは次のようになります。プロセス自体は目新しいものではなく受け入れやすいものだと思います。ただ、複雑性を受け入れ、すべてを予測することは困難という前提に立つと、Fault InjectionとObservabilityが整備されていなければこのプロセスを全く回すことができなくなってしまいます。
これが世界の金融機関がResilienceと向き合うためにFault InjectionとObservabilityを「当たり前の前提」としている理由であると、私はre:Invent 2023の金融セッションから考察しています。
AWSも関連サービスを拡充している
ここまで説明したような世界の金融機関の取り組みに対して、re:Invent 2023期間中もいくつか関連サービスのアップデートがありました。AWSも関連サービスを拡充し続けている状況にあり、まずは手軽にAWSサービスを使って、Fault InjectionとObservabilityを試行できる状況にあると言えます。
AWSネイティブなObservabilityの中核サービスは「CloudWatch」であり、Fault Injectionの中核サービスは「Fault Injection Service」です。re:Invent 2023期間中のこの2つのサービスのアップデートを見ていきたいと思います。
Observabilityの中核サービス「CloudWatch」のアップデートと関連する顧客事例
CloudWatchではre:Invent 2023期間中に3件のアップデートが発表されています。
これらはすべて「Observability向上のアップデート」と捉えられます。
特に、CloudWatch Application Signalsの考え方はカオスエンジニアリングの原則にもとづくFault Injectionの観点でも非常に重要です。
Resilienceを調整し続けるプロセスでも説明した通り、まずは「定常状態」を定量的に定義する必要があります。この「定常状態」を定義する際には「顧客の満足度」が重要な指標になります。顧客が満足している状態が事業として正常ですので、顧客の満足度が定量的に観測可能になっていなければなりません。
CloudWatch Application Signalsでは、サービスレベルに関する顧客の満足度を表す定量的に測定可能な指標であるSLI（サービスレベル指標）や、一定期間に渡って測定されるSLIの目標値であるSLO（サービスレベル目標）をCloudWatchで継続的に測定・追跡可能になります。
これはまさに顧客の満足度を定量的に測定し「定常状態」を定義することになります。また、継続的に測定・追跡されることは、Fault Injectionの前後で定常状態からどのような差分が生じたか理解・説明するために必須です。そのため、本アップデートはFault InjectionとObservabilityの観点で重要なアップデートと言えます。
顧客観点でのObservabilityではシンガポールで急成長中のデジタルバンクである「Trust Bank」のセッション「AWS re:Invent 2023 - Trust Bank: Building for scale while enhancing the customer experience (FSI315)」で関連する事例紹介がありました。
Trust Bankは「3分で口座開設」をうたっており、顧客体験としてのレイテンシを非常に重視しています。End-to-Endで顧客ごとのトランザクションを1つずつトレース・可視化することで、ひとりひとりの顧客のシステム内での振る舞いを視覚的に理解できるようにしています（下図の例では、棒グラフの1本1本が顧客の1トランザクションを表し、マイクロサービスごとにレイテンシを色分け・可視化しています）。これにより、顧客体験として改善点とその要因を定量的に説明できる状態にしていました。
このような取り組みにより「3分で口座開設」という圧倒的な差別化要因を作り出し、事業開始1年でシンガポール人口の12%が口座開設するまでに急成長したという話が印象的でした。
2つ目のアップデートであるハイブリット・マルチクラウドメトリクスに対するクエリとアラームは、まさにObservabilityの向上を狙ったものと言えます。システムのログやメトリクス、トレースを確認する際に、AWSはCloudWatch、オンプレミスは別のツール、他クラウドはまた別のツールと切り替える必要があると、Observabilityが高いとは言えません。本アップデートでは、これらを統一的に扱えるようになっています。
3つ目のアップデートであるInfrequent Accessログクラスについては、以下でJDDの吉竹さんが解説していますのでぜひご覧ください。吉竹さんも本アップデートは「Observability向上のアップデート」と解説しています。
re:Invent期間に発表されたCloudWatch Logsのアップデートを金融エンジニアの目線で試してみる
Fault Injectionの中核サービス「Fault Injection Service」のアップデートと関連する顧客事例
Fault Injection Serviceではre:Invent 2023期間中に以下2件のアップデートが発表されています。
AZ障害はAWSを使う上で想定すべき事象であり、AZ障害に対するシステムの振る舞いを理解しておきたいというのは多くの利用者に共通する要望だと思います。また、電源喪失のようなAZの全面障害であれば、連携する他のAWSアカウントも同時に影響を受けるはずなのでマルチアカウントにまたがって実験をしたいということも当然の要望だと思います。本アップデートにより、重要かつ現実的なシナリオの実験ができるようになっています。
関連する顧客事例として、再度Trust Bankの事例を紹介したいと思います。
Trust Bankでは、このアップデートが発表される以前から自前のツールで複数アカウントのFault Injection Serviceを連動させてマルチアカウントで実験をしていたそうです。
このように、多くの世界の金融機関が当たり前のようにカオスエンジニアリングの原則にもとづくFault Injectionを実践していたことがre:Invent 2023では印象的でした。
Fault Injection Serviceではありませんが、AZ障害に関連して以下のようなアップデートも発表されていますので、こちらも合わせてご確認いただけると良いかと思います。
まとめ
本記事では、re:Invent 2023の金融セッションから学んだ世界の金融機関のResilienceに対する向き合い方について共有させていただきました。
私たちが対峙するシステムの複雑性は高まる一方です。そんな私たちの前には以下の2択があるかと思います。
予測不可能な “竜巻”（甚大な障害）にただおびえ続けるか
実験・観測することでResilienceに対する自信を高めるか
本記事がこの2択を考えるきっかけになれば幸いです。
最後までご覧いただきありがとうございました。
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。
この記事に関するお問い合わせはこちらにお願いします。
Technology & Development Division
Architecture Team Lead / Senior Solution Architect
Yuta Kimi