re:Invent 2024: AWSマルチリージョン構築のベストプラクティスとSamsung Accountの事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Best practices for creating multi-Region architectures on AWS (ARC323)
この動画では、AWSでマルチリージョンアーキテクチャを構築する際のベストプラクティスと、Samsung Accountの実践例について解説しています。前半では、パフォーマンス向上、規制要件対応、可用性向上という3つの主要な動機と、要件理解、データ理解、依存関係理解、運用準備という4つの基本原則を説明します。後半では、18億以上のユーザーを持つSamsung Accountが、3つのリージョンでActive-Activeアーキテクチャを実現した事例を紹介します。特に、Route 53とARC（Application Recovery Controller）を組み合わせたDNSベースのフェイルオーバー制御や、CloudFrontエッジロケーションを活用したトラフィック分散など、具体的な実装方法と得られた知見を共有しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
マルチリージョンアーキテクチャの基礎とフェイルオーバーの重要性
皆様、ようこそ。マルチリージョン要件を持つ新しいアプリケーションを設計している方も、既存のアプリケーションを新しい要件に合わせてマルチリージョンワークロードに進化させる必要がある方も、考慮すべき点が数多くあります。今年の「Best Practices for Creating Multi-Region Architectures on AWS」へようこそ。過去のイベントでも同様のタイトルのセッションを行ってきましたが、限られた時間で扱える内容には制限があるため、毎年この重要なトピックに対して異なる視点からアプローチしています。私はAWSのPrincipal Solutions ArchitectのJoe Chapmanです。本日は、Technical Account ManagerのSangJun Kimと、Samsung ElectronicsのDevOps LeadであるJe-min Kimと共にお話しさせていただきます。
本日は特にFailoverに焦点を当て、Failoverを念頭に置いたマルチリージョンアーキテクチャについて掘り下げていきます。まず基礎から始め、公開されている4つのAWS Multi-Region Fundamentalsについて説明します。その後、Failoverのベストプラクティスに特化して見ていきます。アプリケーションは大規模で複雑になりがちで、日々進化のスピードが加速しているように見えます。次に、障害が発生してFailover手順を実行する必要がある場合に、実際に何をFailoverすべきかを理解し判断するのに役立つ、さまざまな組織的なFailoverストラテジーについて見ていきます。
私が過去のワークショップで多く受けた質問の一つに、シンプルな答えがない難しい問題があります：「いつワークロードをFailoverすべきか、どうやって判断するのか？」について、皆様のワークロードに適用できるベストプラクティスと考慮事項についてお話しします。その後、Je-minに引き継ぎ、Samsungが単一リージョンのワークロードからマルチリージョンワークロードへどのように進化したのかについてお話しいただきます。また、異なるFailoverストラテジー、Failoverに対する考え方、そして実際にどのように実行しているのかについても説明していただきます。
AWSのグローバルインフラストラクチャとマルチリージョン展開の動機
AWSでの構築において、お客様は世界中に展開されている34のRegionをご利用いただけます。さらに、今後数年のうちに利用可能となる5つのRegionの追加も既に発表しています。これにより、お客様は最終ユーザーに近い場所や、アプリケーションにとって最適な場所にワークロードをデプロイする柔軟性と選択肢を得ることができます。重要な点として、すべてのAWS Regionは高い回復性を備えて構築されています。例えば、各Regionには3つ以上のAvailability Zoneがあり、単一のデータセンターだけでなく、複数のAvailability Zoneを活用してアプリケーションを設計することができます。
各Regionは他のRegionから完全に独立して構築されていますが、高スループット、低レイテンシーの冗長光ファイバーネットワークで接続されています。これをAWS Backboneネットワークと呼んでいます。このAWS Backboneネットワークは、エンドユーザーに一貫した体験を提供します。Backboneネットワークに接続すれば、パケットロスが少なく、レイテンシーが低く、全体的に高品質なネットワーク体験を期待できます。さらに、キャッシングやお客様をAWS Backboneネットワークにより早く接続するために、600以上のPoints of Presenceを展開しています。また現在、41のLocal Zoneと29の5G Wavelength Zoneを提供しており、これによりワークロードを構築し、エンドカスタマーやユーザーにより近い場所にコンピューティングリソースを配置することが可能です。
AWS Global Infrastructureは広大で拡張性に優れています。高い回復力を備えて設計されており、現在も拡張を続けています。これにより、お客様はスケーラビリティ、パフォーマンス、あるいは回復力に関して最も厳しい要件を持つアプリケーションを構築することができます。特にここ5年ほど、マルチリージョンのワークロードへの進化を目指すお客様との会話を重ねる中で、このアプローチを選択する理由は主に3つのグループに分類されることに気付きました。 1つ目は、パフォーマンスの向上です。地理的に分散した多くのエンドユーザーに対して、一貫して低レイテンシーで高パフォーマンスな体験を提供する必要がある場合があります。このような場合、マルチリージョンのActive-Active構成が必要になることもありますが、AWS Global Infrastructureがあるため、必ずしもそうとは限りません。
AWS backboneネットワークを活用し、Points of Presenceを利用することで、アプリケーションの全体的な配信を高速化できる多くの利点があります。 2つ目の動機は、規制要件への対応です。アプリケーションをグローバルに展開する際、異なる地域や国のユーザーにサービスを提供することになりますが、それぞれの場所でデータの保存場所や移動方法に関する異なる法律が存在する可能性があります。これは特に金融サービスやヘルスケアなどの規制の厳しい分野、あるいはユーザーの機密情報を扱う場合によく見られます。このような厳しい規制要件がある場合、お客様は通常、異なるリージョンに複数のワークロードを独立して展開します。この場合、各デプロイメントは完全に独立しており、レプリケーションやその他のデータ移動によって誤ってデータが地理的境界を越えて漏洩することがないよう、厳格な共有禁止ポリシーが適用されます。
3つ目の理由は可用性の向上です。大規模な障害が発生した場合に、異なるリージョンなど、まったく別の場所でワークロードを復旧する機会をお客様に提供することです。今日は主にこの点に焦点を当て、マルチリージョンアーキテクチャでのフェイルオーバーの特徴について見ていきます。ここで目指しているのは、単一ロケーションでの障害を減らすか、迅速かつ効率的にフェイルオーバーできるようにすることで、全体的な可用性を向上させることです。
では、AWS Multi-Region Fundamentalsについて見ていきましょう。今日お話しする4つの基本原則それぞれについて詳しく説明する時間はありませんが、画面に表示されているQRコードから、より詳細な情報を得ることができます。そこにはフェイルオーバー以外の内容も含む、完全なMulti-Region Fundamentalsホワイトペーパーがあります。時間が限られているため、ここではフェイルオーバーに特化した視点から、4つの基本原則のみに焦点を当てていきます。
フェイルオーバーのベストプラクティスと復旧時間の最適化
最初の基本原則は、要件を理解することです。復旧時間を定義し、その範囲を設定することで、最良のシナリオと最悪のシナリオにおける復旧プロセスの所要時間について、適切な期待値を設定することができます。これにより、いくつかの重要なことが可能になります。まず、障害がどのくらい続くかについて、ステークホルダーやお客様に適切な期待値を設定できます。復旧時間に範囲が設定されているため、その特定の期間内に復旧できるよう、適切なアーキテクチャと設計上の判断が行われているかを技術面から検証することもできます。
リカバリー時間の測定と追跡には、プロセス内の各ステップを正確に追跡する必要があります。このような取り組みを始める際、多くの場合、リカバリー時間はフェイルオーバーの開始から完了までの時間だと考えがちです。しかし実際のリカバリー時間は、問題が最初に発生してから、リカバリーが完了し、障害が完全に解決されるまでの時間です。リカバリー時間の全体像を見ると、問題が最初に発生した後、できるだけ早く、私たちの監視ツールを通じて検知が行われます。その検知は、オンコールのエンジニアやNetwork Operations Centerなどに迅速に通知されるはずです。その後、トラブルシューティングやRunbookの確認を行っても担当者が問題を解決できない場合、エスカレーションが発生する可能性があります。エスカレーション先は、上位のエンジニアや、制限されたリカバリー時間を念頭に置きながら次のアクションを判断できる意思決定者かもしれません。その意思決定者がフェイルオーバーの実行を宣言し、フェイルオーバーが開始され完了します。このように、これら6つのステップすべてを確認し、各ステップにかかる時間を短縮することで、全体的なリカバリー時間を改善するための効率化と改善点を見つけるようにしてください。 目標を設定し、正確に測定することで、制限されたリカバリー時間に対するより良い期待値を設定することができます。
可用性を測定する一般的な方法として、3つの用語があります。1つ目はMTTD（Mean Time To Detection）で、問題が最初に発生してから、できれば私たちの監視スタックを通じて検知されるまでの時間を測定します。2つ目はMTTR（Mean Time To Recovery）で、問題が最初に発生してから実際の修復が完全に完了するまでの時間を測定します。最後にMTBF（Mean Time Between Failures）があり、前回の障害が完全に解消されてから次の問題が発生するまでの時間、つまりアプリケーションが完全に正常な状態である時間を測定します。これらすべてを検証することで、監視スタックの強化や新しいモニターの追加によってMTTDを改善できます。また、EC2インスタンスの自動修復や、フェイルオーバーを自動的に処理するMulti-AZデータベースの設定など、リカバリーパスの自動化を実装することでMTTRを短縮できます。その結果、障害の発生頻度が減少し、ワークロードの可用性が全体的に向上します。
基本原則の2つ目は、データを理解することです。データは複雑で、分散した場所間でデータを扱うことは、データが離れれば離れるほど複雑になります。この複雑さの増加を考慮に入れる必要があります。制限されたリカバリー時間の要件を満たすには、データについて徹底的に理解する必要があります。例えば、データがどこに存在するかという質問は簡単そうに見えますが、実際に深く掘り下げてみると、思ったほど単純ではありません。データはどのように複製されているのか？リアルタイムで複製されているのか？同期的か非同期的か？データの整合性レベルは、強整合性なのか結果整合性なのか、あるいはその中間なのか？そして、大規模な障害が発生した場合、許容できるデータ損失の量はどれくらいか？
これらすべてをリカバリー目標と結びつける必要があります。例えば、Recovery Point Objectiveで複製の遅延が特定のしきい値を下回ることが要求される場合、それを完全に監視する必要があります。アプリケーションの遅延がRecovery Point Objectiveより長い場合、アーキテクチャを真剣に見直す必要があります。同様に、リカバリーメカニズムによるワークロードの実際の復旧時間も、全体のリカバリー時間の追跡の一部として監視する必要があります。例えば、バックアップのリストアに時間がかかりすぎてリカバリー時間の要件を満たせない場合、要件を満たすためにリカバリー時間を短縮できるよう、アクティブレプリケーションを使用したフェイルオーバー戦略に変更することを検討する必要があるかもしれません。
3番目の基本原則は、依存関係を理解することです。フェイルオーバーシナリオ時のワークロードの運用を確実にするために、2つのRegion間、あるいは他のRegion間に依存関係があってはいけません。Region 1はRegion 2から完全に独立して100%機能できる必要があります。これにより、明確な障害分離境界を設定でき、Region 1のワークロードに何か問題が発生した場合、その問題は障害分離境界内に限定されます。ワークロードの復旧方法を考える際、すべての復旧アクションはリカバリーRegionから実行する必要があります。潜在的に障害が発生している可能性のあるワークロードに依存するような復旧プロセスや手順は避けるべきです。
最後に、依存関係のマッピングについてですが、特にMicroservicesや複雑なMicroservices間の相互作用を扱う場合は難しい課題となります。私が非常に効果的だと感じている方法の1つは、重要なユーザーストーリーをマッピングすることです。例えば、eコマースプラットフォームの重要なユーザーストーリーとして、ユーザーがサイトにアクセスし、商品カタログを閲覧し、ショッピングカートに商品を追加・削除し、最後にチェックアウトプロセスを完了するという流れが考えられます。
このeコマースアプリケーションの例では、依存関係の理解が最も重要です。このユーザーストーリー内の各ステップにおける依存関係を検証し、ハードな依存関係とソフトな依存関係を理解する必要があります。そして、最も重要なユーザーストーリーを他の重要なユーザーストーリーと結びつけてマッピングすることができます。これにより、依存関係の優先順位付けが可能となり、復旧要件を満たすためにアーキテクチャをどのように変更するかを決定することができます。
最後の基本原則は、運用の準備態勢と、マルチリージョンアプリケーションを通じた継続的な運用改善に関するものです。これらの多くは、基本原則1で確立した明確な目標に基づいています。障害プロセスを改善する最良の方法は、制御された環境でテストすることです。障害プロセスをテストすると、異なるスケーリング特性、気付いていなかった依存関係、認識していなかったサービス制限、Regionの間の設定のドリフトなどについて広く学ぶことができます。運用、ポリシー、手順を見直す中で、Runbookの改善が必要な領域や、ステップバイステップガイドの過度に複雑な部分を特定することができます。
最後の要素は、Observabilityのコンポーネントに焦点を当てています。実施するすべての作業は、アプリケーションの全体的な健全性を360度の視点で把握することに貢献すべきです。一つのアプローチとして、Differential Observabilityと呼ばれる手法があります。これは、アプリケーションを複数の視点から検証することを意味します。私のeコマースアプリケーションの例では、アプリケーションサーバーやWebサーバーを監視しており、リクエストの処理やリソース使用率の面では問題がないように見えるかもしれません。しかし、ユーザーの視点からは、タイムアウトや予期しないエラーを経験している可能性があります。したがって、両方の視点からの監視が必要であり、さらにワークロードを評価するためのサードパーティのSynthetic Monitoringなども考慮する必要があります。
組織的フェイルオーバー戦略とリカバリータイムラインの実例
マルチリージョンの基礎について説明してくれたJoeに感謝します。私はSangJun Kimで、エンタープライズサポートのお客様を担当するTechnical Account Managerです。マルチリージョンのフェイルオーバー戦略を策定する際には、コンポーネントとその依存関係を考慮する必要があります。これは、複数のアプリケーションがエンドユーザーに提供される特定の機能を実現するユーザーストーリーを形成することが多いためです。このセグメントでは、4つの一般的なフェイルオーバー戦略についてご説明します。
まず、最も細かい粒度のアプローチであるコンポーネントレベルのフェイルオーバー戦略から見ていきましょう。この戦略では、問題が発生した際に、個々のアプリケーションコンポーネントを別のリージョンにフェイルオーバーすることができます。例えば、 あるリージョンのAmazon RDSデータベースに問題が発生した場合、アプリケーションは セカンダリリージョンのRDSインスタンスにフェイルオーバーすることができます。この分散型の戦略により、コンポーネントが独立してフェイルオーバーできるため、個々のアプリケーションに柔軟性と自律性を提供します。
しかし、このアプローチにはトレードオフがあります。セカンダリのRDSインスタンスが別のリージョンにあるため、レイテンシーが増加し、パフォーマンスの挙動が変化する可能性があります。リージョン間でコンポーネントを切り替えるには、多くの場合、障害発生時に信頼性が低下する可能性のあるランタイム設定の変更が必要です。また、数多くのテスト構成があるため、すべての組み合わせをテストすることが困難であるという課題もあります。 どのコンポーネントが故障し、それが他のワークロードコンポーネントの動作にどのような影響を与えるかが不明であるため、これは信頼性の低い戦略です。この戦略は完全な成功を保証できないため、お客様にはお勧めしていません。
次の戦略であるアプリケーションフェイルオーバー戦略に移りましょう。このアプローチでは、各アプリケーションが自律的にすべてのコンポーネントを一緒にセカンダリリージョンにフェイルオーバーすることができます。 アプリケーションのコンポーネントを同じリージョン内に保持することで、コンポーネントレベルのフェイルオーバーに関連するレイテンシーのトレードオフを解消します。
この戦略では、各アプリケーションがプライマリとセカンダリの2つの構成のみに制限されるため、複雑さが大幅に軽減されます。しかし、個々のアプリケーションが独自に フェイルオーバーの判断を下せるようにすると、コンポーネントレベルのフェイルオーバーで見られたのと同様の、異なる次元でのパフォーマンスの変動が生じる可能性があります。最悪の場合、ユーザーストーリー内のアプリケーションの50%がフェイルオーバーし、50%がフェイルオーバーしないため、すべてのアプリケーション間の通信がクロスリージョンリクエストになる可能性があります。また、コンポーネントレベルのテストほど複雑ではありませんが、クロスリージョンのすべての組み合わせをテストすることは依然として課題となっています。
以前の戦略の複雑さに対処するため、依存関係グラフを構築し、特定のUser Storyをサポートする関連アプリケーションをまとめることで、すべてのインタラクティブなコンポーネントを一緒にフェイルオーバーさせることができます。これにより、レイテンシーの複雑さが軽減され、他の戦略で見られたようなパフォーマンスの変動を回避できます。ただし、この戦略にも独自の課題があります。特に、多数のアプリケーションとUser Storyを持つ大規模な組織では、すべての依存関係を特定し、この依存関係グラフを構築・管理することは複雑になる可能性があります。一見無関係に見えるUser Story同士が依存関係を共有している場合もあります。例えば、2つの異なるUser Storyが同じ認証システムに依存している場合、1つのグラフをフェイルオーバーすると、もう1つのグラフもフェイルオーバーする必要が出てくるかもしれません。こうした課題はありますが、私たちはこのアプローチを最初の2つの戦略よりも推奨しています。
次に、もう1つの推奨アプローチであるPortfolioフェイルオーバー戦略について説明しましょう。このアプローチでは、障害の直接的な影響を受けているか、影響を受けているアプリケーションと相互作用しているかに関係なく、ポートフォリオ内のすべてのアプリケーションを同時にフェイルオーバーします。この戦略の主な利点はシンプルさにあります。このアプローチにより、ビジネスがサポートする各User Storyの依存関係グラフを作成・維持するという運用上の負担を軽減できます。ただし、すべてのアプリケーションを複数のリージョンで運用できるようにするには大きな投資が必要です。クリティカルな崩壊が差し迫った状況に焦点を当てる戦略とは異なり、より的を絞ったアプローチも可能です。例えば、下位のTierのアプリケーションへの依存関係がない限り、Tier 1のアプリケーションをまとめてフェイルオーバーするなど、特定のTierのアプリケーションに適用することができます。
組織のフェイルオーバー戦略について説明してきましたが、ここで重要な疑問に答えましょう：実際にいつフェイルオーバーを開始すべきなのでしょうか？フェイルオーバーのタイミングを適切に判断することは、ビジネス継続性を確保する上で不可欠です。この問いに答えるために、重要な考慮事項とガイドラインを見ていきましょう。フェイルオーバーの判断ツリーとは、フェイルオーバーを開始するタイミングを導く、事前に計画された意思決定プロセスです。これは、システムがダウンしている緊急時に考えるべきことではありません。この判断ツリーを事前に作成しておくことで、その場の反応的な判断ではなく、合理的で十分に検討された判断を下すことができます。
効果的なフェイルオーバー判断ツリーを開発するには、以下の重要な原則を念頭に置いてください。まず、メトリクスは明確で曖昧さのないものである必要があります。フェイルオーバーの判断を引き起こす具体的な測定可能な閾値を定義する必要があります。これは、システムのパフォーマンス、エラー率、またはビジネスへの影響に関連する可能性があります。例えば、アプリケーションのエラー率が15分以上5%を超える場合や、レイテンシーが特定の期間にわたって特定の閾値を超える場合にフェイルオーバーを実行するといった判断基準を設定できます。次に、判断ツリーを全体的な運用継続性戦略に統合します。フェイルオーバーの判断がより広範な組織の目標をサポートするよう、ビジネス継続性計画と整合させる必要があります。また、技術チーム間の部門横断的なステークホルダーも関与させます。
また、ビジネスリーダーシップ、カスタマーサポート、その他の関連グループ間の部門横断的なステークホルダーも関与させ、技術的な考慮事項とビジネスニーズのバランスを取ることも目標に含まれます。明確で十分に定義されたフェイルオーバー判断ツリーを事前に作成しておくことで、インシデントが発生した際に迅速で確信を持った判断を下すことができます。
それでは、フェイルオーバーの判断において見落とされがちな重要な側面である「情報の欠如」について考えてみましょう。理想的な世界では、適切な判断に必要なすべてのデータが常に手元にあるはずですが、現実には重要な情報が不足している状況に直面することがよくあります。このような状況への対処方法を見ていきましょう。まず、指定された意思決定者が不在の場合について考えてみましょう。事前に明確な指揮系統と権限委譲を確立しておくことが重要です。フェイルオーバー計画には、誰が意思決定の権限を持ち、誰がそのバックアップを務めるかを明確に定めておく必要があります。
次に、メトリクスが不完全または欠落している状況に直面することがあります。システムの一部がダウンしていたり、メインサービスに影響を与えている問題と同じ問題によってモニタリングツールが影響を受けている可能性があります。このような場合、部分的な情報に対する事前定義されたしきい値を持っておくことが重要です。例えば、システムの30%からしかデータを取得できない場合、それ自体がフェイルオーバーのトリガーとなる可能性があります。また、AWSのサービスイベントが進行中である場合もよくあるシナリオです。このような状況では、復旧までの明確なETAが常に得られるとは限りません。ビジネス継続性計画の一部として定義された、ビジネスが許容できる最大ダウンタイムである境界復旧時間から逆算して考えることが重要です。例えば、ビジネスが最大2時間のダウンタイムを許容でき、フェイルオーバーに30分かかるが、ETAもなく既に1時間ダウンしている場合、目標を達成するためにフェイルオーバーを開始する必要があります。ここでの重要なポイントは、情報の欠如が意思決定プロセスを麻痺させてはならないということです。これらのシナリオを事前に計画しておくことで、不完全なデータでも自信を持って判断を下すことができます。
次に、リカバリーのベストプラクティスに焦点を当てましょう。まず、災害を宣言するステップについて説明します。Runbookには、起こりうる災害シナリオごとに、状況、アクション、担当者を明確に記載する必要があります。これにより、インシデントが発生した際に、誰が災害を宣言してフェイルオーバープロセスを開始する権限を持っているのかについて混乱が生じないようにします。Runbookには、災害が宣言された後、各チームメンバーがどのように対応すべきかの詳細な手順を含める必要があります。次に、災害時に従業員が連絡を取り合い、情報を共有するための電話、アラート、メディアなどのコミュニケーション手段を指定します。
Runbookは、計画の作成に関与していない人でも、適切なアクセス権があれば従うことができるほど詳細である必要があります。これにより、属人的な知識への依存を排除し、災害復旧プロセスの再現性と一貫性を確保します。Runbookの各ステップには、実行するスクリプト、その実行方法、次のステップに進む前の期待される結果、各アクションの責任者を明記する必要があります。最後に、フェイルオーバー時には、様々なシステムやサービスへのアクセスが必要になり、場合によっては昇格された権限が必要になることがあります。必要な認証情報がプライマリリージョンとセカンダリリージョンの両方で利用可能であることを確認してください。また、テストと計画の一環として、これらの認証情報を定期的にレビューし更新することをお勧めします。
実際のリカバリータイムラインがどのように見えるか、例を見ていきましょう。オンラインシューズストアを例に、検知から完全復旧までのプロセスを説明します。このシューズストアで突然問題が発生したと想定してみましょう。 5分経過時点で、レイテンシーの増加と受注数の大幅な低下という最初のトラブルの兆候が見え始めます。
通知システムは直ちにメール、Slack、そしてPagerを通じてアラートを送信しました。 その後25分間、ファーストレスポンダーたちが問題の解決を試みましたが、今回のケースでは迅速な解決には至りませんでした。30分が経過した時点で、 エスカレーションのために経営陣が関与し、追加のリソースと意思決定権限が投入されました。その5分後、35分の時点で、 インプットと事前に定義された基準に基づき、リーダーがFailoverプロセスの開始を宣言し、実行に移しました。
Failoverは40分の時点で開始され、 相互接続されたシステムを適切な順序で移行するため、自動化された依存関係グラフFailover戦略を使用しました。そして55分の時点で、 Failoverが完了し、システムはセカンダリリージョンで稼働する新しい状態となりました。このように、問題の最初の検知から完全な復旧までの総復旧時間は55分でした。
ここで、Multi-Regionの取り組みを成功させるための重要なチェックポイントを振り返ってみましょう。まず何より重要なのは、AWSのインフラストラクチャがMulti-Regionのニーズを満たすように設計されているということです。しかし、真の成功を収めるためには、先ほど議論した基本原則を忘れてはいけません。重要な側面の一つは、インシデント発生前にFailoverのタイミングを決定しておくことです。Failoverプランを開始するための明確な事前定義基準を持つことで、災害時の貴重な時間を節約し、合理的な意思決定を確保できます。次に、ビジネスニーズ、技術的能力、組織構造に合ったFailover戦略を選択することが重要です。そして最後に、最も重要なのは、とにかくテストを重ねることです。Failoverプランは、その実行能力次第でしかありません。関連するすべてのチームを巻き込んで、実際のシナリオを想定した定期的で徹底的なテストを実施してください。
Samsung Accountのグローバルサービスとマルチリージョン展開への進化
ありがとうございます。私はSamsung AccountのDevOps LeadのJe-min Kimです。このセッションでは、まずSamsung Accountとは何か、そしてなぜリージョンの障害時でも迅速なFailoverが必要だったのかについてご紹介します。その後、Multi-Region展開に基づく私たちのグローバルディザスタリカバリアーキテクチャについてお話しします。 18億以上のユーザーアカウントを基盤に、Samsung Accountは256カ国で60以上のサービスやアプリを接続するサービスです。SmartThings、Samsung Health、Samsung Payなどの主要なSamsung Electronicsのサービスだけでなく、モバイル、ウェアラブル、TV、PCなど、さまざまなデバイスにわたるアカウントサービスとしても活用されています。さらに、Samsung.comのようなオンラインストア、オフラインストア、カスタマーサービスなど、異なる顧客接点全体で1つのアカウントによる安全で安定した顧客体験を提供しています。私たちが「Do everything Samsung with one account」と言うように。
Samsung Accountは18億人のユーザーをSamsungエコシステムに結びつける中核的なサービスです。Samsung AccountはすべてのSamsungデバイスと60以上のサービスを接続し、大量のトランザクションを処理しながら、より高いレベルの信頼性を追求するビジネスクリティカルなシステムです。3つのリージョンにまたがるグローバルな運用を考えると、リージョン内のディザスタリカバリによるバックアップと復旧を超えて、リージョンの障害を乗り越えられるアーキテクチャが必要でした。そこで、私たちはグローバルディザスタリカバリアーキテクチャを実装しました。 Samsung AccountはEU、US、APの3つのリージョンを基盤に、すべてのサービスをサポートするように設計されたグローバルサービスです。現在、Samsung Accountはデバイス、Web、関連サービスから毎秒270万リクエストに達する大量のトラフィックを安定的に処理しています。この膨大なトラフィックを処理するシステムとして運用の複雑さを最小限に抑えるため、70以上のマイクロサービスで構成されるマイクロサービスアーキテクチャを採用してアーキテクチャを改善しました。これらすべてのマイクロサービスは
高可用性を実現するためAmazon EKSをベースにしています。主要なデータベースとしてRDBを使用しており、1秒あたり20万件のトランザクションを処理しています。3つのリージョンにはそれぞれデータベースクラスターがあり、自社開発のソリューションによって同期されています。また、Amazon MSKベースの同期システムを使用してアーキテクチャの改善も進めています。RDBに加えて、samsung.comやCRWなどのWebベースのサービスのパフォーマンス向上のため、DynamoDBとElastic Cacheをデータとキャッシュのサポートに活用しています。これらはCDNを通じて提供されています。最近では、リージョン障害にも耐えられる高レベルの災害対策を確保するため、CDNをAmazon CloudFrontに移行しました。
Samsung Accountは、いくつかの重要なアーキテクチャの改善と既存の課題に取り組む必要がありました。まず、既存のEUとUSリージョンを補完するため、新しいAPリージョンにサービスを展開しました。しかし、両リージョンはすでに大量のトラフィックを処理しており、クラウドインフラリソースの限界に近づいていたため、リージョン障害が発生すると完全なサービス停止につながる可能性がありました。このリスクを軽減しトラフィック負荷を分散するため、昨年新しいAPリージョンの構築に成功しました。次に、70以上のマイクロサービスが分散していたため、リージョン間でサービス構成に一貫性がありませんでした。つまり、特定のマイクロサービスがEUリージョンにしか存在しない場合、USリージョンは単独でその機能をサポートできませんでした。この問題を解決するため、APリージョンの構築時に、各リージョンペアに分散していたマイクロサービスのセットを統合し、残りの2つのリージョンに展開しました。その結果、現在では各リージョンが100%のサービスと機能をカバーできるようになりました。
最後に、256カ国以上でグローバルな認証サービスとして運営されているSamsung Accountは、3つのリージョン間で必須のデータ同期アーキテクチャを確立し、維持しています。データ同期は主にRDBとDynamoDBの2つのデータベースに関わっています。RDBの場合、CDCとMSKベースの同期アーキテクチャを使用した自社開発の同期パイプラインで同期を実行しています。DynamoDBについては、Global Tablesとして知られるDynamoDB独自の同期ソリューションを活用して同期を実現しています。新しいAPリージョンの確立、全リージョンでの一貫したサービス構成の確保、データ同期の実装により、各リージョンは単一のサービスとして独立して実行できるActive-Activeアーキテクチャに変革されました。そのため、特定のリージョンで問題が発生しても、他の2つのリージョンが迅速にトラフィックを吸収できます。
グローバルなActive-Activeアーキテクチャへのアップグレードに伴い、別のリージョンへのトラフィックのルーティングについても考慮が必要でした。Samsung Accountが処理する大量のトラフィックを考慮すると、障害時のトラフィックルーティングを管理するための最も効率的なトラフィックルーティング制御方法を、最小限のコストで実装することが不可欠でした。主に2つのシナリオを検討しました。1つ目のシナリオは、グローバルロードバランサーベースのトラフィックルーティング制御方法です。個々のリージョンから独立したグローバルロードバランサーを配置し、WebトラフィックとAPIトラフィックを別のリージョンにリルーティングできるようにします。リージョン障害が発生した場合、Global Acceleratorがグローバルロードバランサーとして機能し、即座にトラフィックをルーティングできる利点があり、非常に短いRTOレベルを実現できます。しかし、大量のトラフィックを処理するSamsung Accountにとって、これは高コストという欠点がありました。そこでDNSベースのトラフィックルーティング制御方法を考案しました。このアプローチでは、リージョン障害が発生した場合にRoute 53を使用してDNSレコードを別のリージョンに変更し、グローバルロードバランサーを必要とせずにクライアントのアクセスIPを変更します。この方法は、グローバルロードバランサーなどの追加インフラが不要なため、一般的な運用コストの面で利点があります。また、単にDNSレコードを変更するだけで障害対応テストが簡素化され、コストを考慮しつつ、障害復旧時の運用の複雑さを軽減できます。
Samsung AccountのグローバルDR（災害対策）アーキテクチャは、DNSベースのルーティング制御方法を選択しました。DNSベースのトラフィックルーティング制御を実行するマルチリージョンアーキテクチャを設定し、実際の大規模なトラフィックルーティングには10分以上かかることを確認しました。Samsung Accountは、実際のユーザーとサーバー間のISP DNSキャッシングによって引き起こされる部分を特定しました。
Samsung Accountはグローバルサービスとして3つのリージョンをベースに提供されていましたが、サービスリージョンから遠い場所のユーザーにとって高いレイテンシーの問題がありました。これらの2つの問題に対処するため、Webサービスにのみ適用されていたAmazon CloudFrontの利用を、すべてのAPIに拡大することを決定しました。CloudFrontのネットワークを活用することで、実際のDNSの切り替えがAWS内で行われるため、わずか3分でトラフィックの大規模な切り替えを実現できました。さらに、世界中に分散された600以上のPoints of Presenceを通じて、APIの通信における平均遅延時間を約70%削減することができました。
AWSとDNSベースのフェイルオーバートラフィック制御方式について議論する中で、重要な問題に直面しました。DNSレコードの設定と変更を担当するAWS Route 53は、そのコントロールプレーンがUS East-1リージョンのインフラストラクチャー上に構築されています。そのため、このリージョンでRoute 53のコントロールプレーンに問題が発生すると、Route 53のDNSレコードの変更が不可能になります。これらの懸念に対処し、可用性を向上させるため、Application Recovery Controllerを導入しました。Route 53のコントロールプレーンに障害が発生した場合でも、データプレーンで事前設定されたルーティング制御セットを使用して、API機能によるトラフィックの切り替えを可能にします。
ARCに基づいて、Route 53のコントロールプレーンに問題が発生した場合のディザスタリカバリーの実行方法について説明させていただきます。通常状態では、データプレーンで設定されたプライマリルーティングセットが、入力トラフィックをUS East-1リージョンに誘導します。サービス監視中に障害を検知すると、ARC APIを使用してトラフィックルーティング制御リクエストが発行されます。トラフィックルーティング制御リクエストを受信すると、データプレーンで事前に設定されたスタンバイルーティングセットが、入力トラフィックをEUリージョンにルーティングし始め、状況に関係なくトラフィックの転送を保証します。結果として、ARCの高可用性機能を活用することで、Samsung Accountは堅牢なリージョナルディザスタリカバリーアーキテクチャを確保しています。
トラフィック制御とCloudFrontを活用したジオルーティングアーキテクチャ
Samsung Accountは大量のトラフィックを処理する最大規模のサービスであるため、別のリージョンで障害トラフィックを処理するために、事前にサービスとインフラストラクチャーの規模を拡大するオーバープロビジョニングが必要です。さらに、新しいリージョンを設定する際には、フェイルオーバートラフィックを確実に収容できるよう、その容量を増強しました。それにもかかわらず、各リージョンに分散されるトラフィック量を直接管理し、オーバープロビジョニングに関連する費用を最適化できる、予測可能なトラフィック分散アーキテクチャーの必要性が浮上しました。
Route 53が提供する2種類のトラフィック制御方式を評価しました：遅延が最も少ないリージョンにトラフィックを分散するLatency-based Routingと、DNSクエリの発信元の場所に基づいて振り分けるGeolocation Routingです。Latency-based Routingは最適な速度を保証しますが、ルーティングのルールがRoute 53によって管理され、サービス自体では管理できないため、サービスの規模を定義することができません。一方、Geolocation-based Routingでは、リージョナルルールを確立し、Route 53を利用して直接制御することが可能です。国別のルールには、トラフィック分散の直接的な制御が必要となります。
Amazon Route 53のジオロケーションベースのルーティングスキームを活用することで、国単位での全体的なトラフィック管理を実現し、障害時のトラフィック分散と監視を計画することができました。ただし、ジオロケーションベースのルーティング方式を実装すると、新たな課題が生じます。Route 53のジオロケーションベースのルーティングでは、約256カ国のルーティング設定を個別に指定できます。各国のトラフィックを予測できるなどのメリットがある一方で、運用の複雑さが大幅に増すため、国をグループ化する方法を検討する必要がありました。
Samsung Accountは、Amazon CloudFrontのエッジロケーションを活用するソリューションを見出しました。CloudFrontは、静的・動的なWebコンテンツをCloudFrontエッジロケーションと呼ばれる世界中のデータセンターネットワークを通じて、ユーザーに迅速に配信するWebサービスです。現在、様々な国に10のCloudFrontエッジロケーションが設置されており、ユーザーは地理的に最も近いCloudFrontエッジロケーションを通じてSamsung Accountサービスにアクセスします。3つのリージョンをそれぞれのCloudFrontエッジロケーションの国でグループ化することで、特定のリージョンで障害が発生した場合に、事前に定められたトラフィック分散計画に従って、別のリージョンにトラフィックを振り分けることが可能になります。
例えば、USリージョンが当初、韓国、ブラジル、米国のCloudFrontロケーションのトラフィックを処理していたとします。USリージョンに問題が発生した場合、韓国のトラフィックをEUリージョンに、ブラジルと米国のトラフィックをAPリージョンに分散させることができます。Route 53 ARCの地理的ルーティングとCloudFrontエッジロケーションのアクセシビリティを組み合わせることで、高可用性とフェイルオーバー災害復旧運用を保証するジオルーティングアーキテクチャを最終的に構築することができました。
account.samsung.comを例に、グローバル災害復旧アーキテクチャ全体を説明させていただきます。ユーザーがaccount.samsung.comを通じてサービスにアクセスすると、特定の国のCloudFrontロケーションの1つに到達します。例えば、ユーザーがブラジルのエッジロケーションに到達した場合、10ロケーションの中でブラジルに対応する内部DNS、urabr-account.samsung.comにルーティングされます。次に、Route 53 ARCベースの災害復旧ルーティングが有効化されているfo-br-account.samsung.comに誘導されます。通常時は、最終的にブラジルのトラフィックを処理するUSリージョンのドメインに転送されて処理されます。しかし、USリージョンで障害が発生し、災害復旧モードが有効になった場合、ブラジルのトラフィックは代わりにAPリージョンのドメインに転送され、障害時のトラフィックが処理されます。
もう1つ考慮すべき点は、CloudFrontエッジロケーションの拡張や非エッジロケーション経由のトラフィックという稀なケースでした。これらのシナリオで発生する可能性のあるトラフィックに対応するため、Route 53のレイテンシーベースルーティングをデフォルト値または地理的ルーティングに適用し、3つのリージョンのドメインを登録します。障害発生時には、ARCを使用して影響を受けたリージョンのドメインを除外するように設定します。特定のリージョンでは、Samsung Accountの静的コンテンツはS3がリージョナルリソースであるため、S3バケットをベースに提供されています。動的コンテンツはジオルーティングアーキテクチャで対応できますが、リージョンで障害が発生した場合、静的コンテンツはそのような事態から保護されていません。この問題を解決するため、Webの静的コンテンツをプライマリとセカンダリの両リージョンのS3に冗長的に保存し、CloudFront Origin Groupsでグループ化しています。これにより、プライマリリージョンで障害が発生しても、セカンダリリージョンのS3に保存された静的コンテンツを使用してサービスを提供することができます。
グローバルディザスタリカバリーアーキテクチャの検証と運用改善
その後、私たちは構築したグローバルディザスタリカバリーアーキテクチャの検証を行うことを決定しました。
このアーキテクチャは、実際の本番環境で大量のトラフィックを処理しながら稼働している状態で構築されました。稼働中の環境での検証は失敗のリスクを含む大きな挑戦でしたが、綿密な計画により自信を持って進めることができました。検証プロセスでは、グローバルディザスタリカバリーアーキテクチャが適切に機能することを確認するための機能テストと、災害復旧時の大量トラフィックに対する耐性を評価するためのストレステストを実施しました。これらのテストは、標準的な開発検証手順に従って実施されました。
機能テストは、全トラフィックの2%をグローバルディザスタリカバリーシステムに振り分けて実施しました。この機能テストフェーズでは、URLの設定漏れを早期に発見し、修正することができました。負荷テストは、全トラフィックの10%と50%の2段階に分けて実施しました。既存のコアコンポーネント（サービス、Amazon EKS、データベースなど）に対して徹底的なストレステストを行いました。最後のGame Dayでは、特定のリージョンで障害が発生するというシナリオに従って、あるリージョンからの全トラフィック（100%）を数分以内に切り替えることに成功しました。
Samsung Accountでは、耐久性を高めるために2つの主要な障害カテゴリーを定義し、包括的なモニタリングシステムを確立しました。第一のカテゴリーには、APIエラー、トラフィックの急激な低下、Amazon EKS、データベース、キャッシュなどのインフラ障害といった、サービスとインフラストラクチャに起因するエラーが含まれます。また、新機能開発によって引き起こされる可能性のある機能エラーはAPMを通じて特定できます。第二のカテゴリーは、実際のユーザー環境で発生するエラーを検出するEnd-to-Endモニタリングです。ログイン、ID検索、パスワードリセット、認証など、サービスの中核的な機能を様々な国や環境でテストするためのSynthetic Testを実装しました。また、特定の国におけるフラストレーション信号やエラー発生率に基づいてReal User Monitoringのメトリクスを確立し、ネットワーク障害などのユーザー環境特有の問題を迅速かつ正確に検出できるようにしました。
Samsung Accountは3層のオペレーション構造を持っています。 Tier 1は24時間体制でシステムを監視し、モニタリングダッシュボードを確認し、インシデントを検知した場合はTier 2にエスカレーションします。Tier 2は初期の根本原因分析を行い、問題が継続または深刻な場合はTier 3に支援を求めて、さらなる調査と解決策の判断を仰ぎます。以前は、障害が発生した際、Tier 3の承認を得てから対策を開始する必要があり、しばしば長時間の遅延が生じていました。しかし、可観測性を向上させることで、Tier 2が迅速な判断を下せるようになり、 Tier 3の承認を待たずに、シンプルなフェイルオーバースクリプトを使用して即座にフェイルオーバーを実行できるようになりました。
Samsung Accountは、地域的な問題から迅速に復旧できるグローバルな災害復旧アーキテクチャを確立し、Mean Time to Repairの短縮を実現しました。さらに、詳細なサービスとインフラストラクチャのモニタリングシステムを改善し、エンドツーエンドのモニタリングシステムを実装することで、ユーザーが経験するエラーやパフォーマンス低下を即座に検知できるようになりました。これにより、Mean Time to Detectionを最小限に抑え、障害の検知と意思決定を迅速化し、最終的にSamsung Accountサービスの回復力を向上させることができました。ご来場ありがとうございました。モバイルアプリでセッションアンケートにご協力をお願いいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion