re:Invent 2023: AWSマルチリージョンアーキテクチャの構築ベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Best practices for creating multi-Region architectures on AWS (ARC308)
この動画では、AWSの複数リージョンにまたがるワークロードの構築と拡張について、実際のシナリオを基に解説します。マルチリージョンアーキテクチャの利点や課題、データレプリケーション戦略、observabilityの重要性など、具体的なベストプラクティスを学べます。AWS Fault Injection ServiceやRoute 53 Application Recovery Controllerなど、最新のAWSサービスの活用方法も紹介。レジリエンスの向上を目指すエンジニアにとって、貴重な知見が満載のセッションです。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
マルチリージョンアーキテクチャの概要と目的
はい、それでは始めましょう。皆さんがここにいらっしゃるのは、複数のAWSリージョンにまたがってワークロードを構築または拡張しているか、あるいはその検討をされているからです。 グローバルに分散したユーザーベースのパフォーマンス向上、最重要ワークロードの可用性向上、あるいはデータレジデンシーに関する法規制への準拠など、その理由は様々でしょう。しかし、これがかなり複雑になり得ることにお気づきかと思います。初めての方でも、すでに詳細な検討に入っている方でも、多くの決断を下す必要があります。
このセッションでは、実際のシナリオを見ながら、皆さんのマルチリージョンへの取り組みに役立つベストプラクティスを抽出し、今日からすぐに活用していただけるようにします。AWSでマルチリージョンアーキテクチャを構築するためのベストプラクティスについて、このLevel 300のセッションへようこそ。私はPrincipal Solutions ArchitectのJoe Chapmanです。同僚のPrincipal TechnologistであるNeeraj Kumarと一緒に進行させていただきます。この数年間、NeerajとI私は多くのお客様とお話しし、複数のAWSリージョンにまたがってワークロードを進化させ、構築するお手伝いをしてきました。このセッションは、皆さんと同じようなお客様を支援する中で得た実践的な学びに基づいて構成しています。
アジェンダを簡単に見ていきますと、私たちの目標は、AWSの既知のベストプラクティスを活用して、複数のAWSリージョンにまたがってワークロードを構築し、進化させる方法について、より明確なイメージを皆さんに提供することです。実際のユースケースに基づいて構築された2つの架空の顧客シナリオを詳しく見ていきます。これらの顧客の旅を通じて、それぞれのベストプラクティスを抽出していきます。また、彼らが選んだ道のトレードオフ、考慮事項、長所と短所についても見ていきます。マルチリージョンアーキテクチャに関しては、万能のソリューションは存在しないからです。これにより、違いやトレードオフを理解し、皆さんの特定のワークロードに適応させることができます。
AWSリージョンの設計と単一リージョンの重要性
さて、マルチリージョンアプリケーションやワークロードを展開するかどうかをまだ検討中の方は、AWSリージョンがどのように構築されているかを覚えておくことが重要です。AWSリージョンは設計上、回復力を持つように構築されています。すべてのパブリックAWSリージョンには3つ以上のアベイラビリティーゾーンがあり、お客様はその恩恵を受けています。これらのアベイラビリティーゾーンは、ゾーン内に1つ以上の独立したデータセンターで構成されています。各アベイラビリティーゾーンは、他のアベイラビリティーゾーンから意味のある距離を置いて分離されており、別々の変電所や別々の氾濫原などが考慮されています。これにより、あるデータセンターで洪水などの災害が発生しても、そのリージョン内の別のAZにある他のデータセンターには影響しないことが保証されています。
これらのAZは、高スループット、低レイテンシーのリンクで接続されており、異なるアベイラビリティーゾーン間で非常に低いレイテンシーで回復力のあるアプリケーションを構築することができます。リージョンの境界内で設計された同期アプリケーションさえ構築できます。ここで強調したいのは、AWSリージョンが回復力を持つように構築されているということです。AWSで長年構築されてきた方々にとっては、これは当たり前のことかもしれません。しかし、組織内で設計レビューやWell-Architected Frameworkレビューを行う際には、ワークロードに特別な注目を向け、AWSリージョンの回復力のある設計と性質を活用しているかどうかを本当に見極めてください。
単一のリージョンでうまく設計されていない場合、マルチリージョンに移行しても効果がない可能性があります。実際、問題を複数のリージョンに広げたり、オペレーションを拡大したり、複数のAWSリージョンにまたがって依存関係を広げたりすることで、状況を悪化させる可能性もあります。多くの方々には、マルチリージョンアーキテクチャに移行する十分な理由があるでしょう。この journey を始めるにあたり、まず最初に皆さんにお勧めしたいのは、一歩下がって現在のアーキテクチャをよく理解することです。現在のアーキテクチャは何で構成されているのか？その要件は何か？そして、アーキテクチャとワークロードが対応しなければならない新しい要件は何か？
例えば、成長するグローバルな顧客のためにパフォーマンスを向上させる必要がある場合、パフォーマンスはどのように測定されているのでしょうか？現在のパフォーマンス指標は何で、将来理解し達成すべきパフォーマンス指標は何でしょうか？あるいは、ワークロードの可用性を高める必要があるという要件がある場合、現在の可用性要件は何で、現在のワークロードは何を達成しているのでしょうか？それはどのように測定されているのか、そして将来どのように測定されるのか？将来何を達成する必要があるのでしょうか？また、遵守すべきデータ居住法や規制に関する要件がある場合、それらの法律や規制に定められた要件は具体的に何でしょうか？例えば、データをどこに保存できるのか、あるいはデータをどこに転送できるのか？
誰がデータにアクセスできるのか？そして最も重要なのは、データが不適切な場所に転送されたり移動したりしないようにするために、ガードレールなどどのような要件を設ける必要があるのでしょうか？これらの要件を理解し、ビジネスと技術の両方のステークホルダーと足並みを揃えたら、それらの要件から逆算して、自分たちにとって最適なソリューションを見つけ出します。単一のリージョンでこれらの要件を満たすことができるのか、それともこれらの要件によって単一のリージョンを超えてマルチリージョンのワークロードに拡張する必要があるのか、と問いかけてみてください。ここでビジネスと技術の両方のステークホルダーが合意することで、組織全体でコスト、複雑さ、トレードオフについて認識を合わせることができ、マルチリージョンワークロードへの journey の基盤を確実に築くことができます。
要件を理解することは、マルチリージョンワークロードを作成する上での最初の基本です。次に、Neerajに引き継ぎ、最初の顧客シナリオを見ていきます。
FinTechリテールバンクのDR戦略：RTOとRPOの定義
ありがとう、Joe。皆さん、こんにちは。re:Inventへようこそ、そしてこのセッションへようこそ。遅い時間にお越しいただき、ありがとうございます。先ほどJoeが述べたことを踏まえて、いくつかのストーリー、いくつかのシナリオを皆さんと共有したいと思います。これらのストーリーや顧客の特徴づけは架空のものですが、このセッションを通じてお伝えする教訓とベストプラクティスは非常にリアルなものです。私たちは、さまざまな業界の多数の顧客と協力して得た現場での教訓を、これらのいくつかのストーリーに凝縮しようと努めました。
最初にお話しするのは、FinTechリテールバンクの事例です。この企業は急成長中で、現在は単一のRegionで事業を展開しています。先ほどJoeが指摘したように、彼らは単一Region内でのレジリエンス態勢を改善するための措置を講じてきました。そして今、この急成長により、災害復旧（DR）とビジネス継続性戦略について真剣に考える段階に来ています。この成長段階では、ダウンタイムのコストが非常に大きいため、レジリエンスは取締役会レベルの話題になっています。
彼らの事業ライフサイクルのこの段階での目標は、適切なDRと運用継続性戦略を特定し、それらの戦略のテストに投資することです。彼らが構築する検出制御、復旧制御、緩和制御がどのようなものであれ、それらの制御を定期的にテストして、意図したとおりに機能することを確認したいと考えています。DR戦略への道のりの最初のステップの1つは、ビジネス目標を定義することでした。皆さんの中には、最適な戦略を特定する前に定義する必要がある2つの重要な指標、RTOとRPOをご存知の方もいるでしょう。
これらの用語を初めて聞く方のために、簡単に説明しますと、RPOはRecovery Point Objectiveの略です。これは、ビジネスを運営するために必要なデータの鮮度、言い換えれば、データソースに大規模な障害が発生した場合に許容できるデータのラグまたは失ってもよいデータ量を指します。RTOは回復の速度に関するもので、Recovery Time Objectiveの略です。これは、通常、分または時間単位で定義される、どれだけ早く運用を回復したいかを示します。彼らの場合、RPOは15分、RTOは1時間と定義されました。もちろん、これは業界、ユースケース、そして議論の対象となるミッションクリティカルシステムの重要性によって異なる場合があります。
DRへのアプローチ：4つの主要戦略
これらの指標に基づいて、次のステップは採用可能な異なる戦略を検討することでした。画面に表示されているこのチャートは、Well-Architected Frameworkからのもので、DRへのアプローチを大きく4つの戦略に分類しています。最も単純なバックアップと復元から始まります。どんなクリティカルシステムでも、これをデフォルトの戦略として持つべきだと言えるでしょう。なぜなら、技術的な障害だけでなく、データ破損や以前の既知の正常な状態に戻りたいという理由が様々あるかもしれないからです。これは、すべてのクリティカルシステムが考慮すべき基本レベルの戦略と言えます。
次の戦略はパイロットライト戦略と呼ばれます。パイロットライト戦略では、効果的に、ワークロードやアプリケーションのレプリカを作成し、それを別のサイトに配置します。この戦略により、バックアップと復元に比べて回復時間が短縮され、RPOとRTOは数十分の範囲内に収まります。データはライブで保持されますが、サービスはアイドル状態で、一部のAWSリソースはイベント発生後にプロビジョニングされ、スケールされます。
パイロットライトでは、主に2つのことに焦点を当てます。1つ目はデータレプリケーション戦略です。障害が発生した場合に備えて、データを継続的に同期させたいからです。ビジネスシステムを効果的に運用するために必要な、すべてのデータまたは最新のデータを確保しておく必要があります。2つ目は、すべてのテンプレートやインフラストラクチャ・アズ・コードのテンプレートを準備しておくことですが、この時点ではまだ実際にコンピュートやキャパシティを稼働させていません。ここでのアイデアは、2番目のリージョンにすべてのデータを用意し、インフラストラクチャを立ち上げてスケールアップするために必要なスクリプトを準備しておくことです。
3つ目の戦略はウォームスタンバイです。ウォームスタンバイはパイロットライトと非常によく似ています。ここでの違いは、コンピュートをまったく稼働させないのではなく、ある程度のベースラインとなるコンピュート、つまりウォームアップされたリソースが利用可能な状態にあるということです。パイロットライトとウォームスタンバイ戦略を比較すると、ウォームスタンバイの方が効果的にRTOが短縮されます。なぜなら、すべてのリソース、あるいはそれらのリソースの縮小版がすでに存在しているため、フェイルオーバー時にリソースをすぐに立ち上げてスケールアップできるからです。
スペクトルの反対側にあるのがアクティブ/アクティブです。定義上、アクティブ/アクティブは複数のリージョンを同時に使用することを意味し、読み取りと書き込みの両方のトランザクションに使用するか、あるいは何らかの形でリージョン別のシャーディングを行います。アクティブ/アクティブの実現方法は1つではありません。ここでのアイデアは、ワークロードやトランザクションをリージョン間で分割することです。もちろん、このチャートで左から右に進むにつれて、複雑さ、コスト、運用のオーバーヘッドも変化します。この特定の顧客の場合、ウォームスタンバイを選択することに満足していました。これは、彼らの運用継続性のニーズを達成するための目標を満たすことができると考えたからです。
ウォームスタンバイ戦略の実装とベストプラクティス
この旅の次のステップは、ウォームスタンバイ戦略の開発と実行を開始することでした。それはどのようなものでしょうか？先ほど述べたように、ウォームスタンバイでは、1つのリージョンからレプリカを取得し、データ、コード、設定など、必要なリソースをセカンダリリージョンですぐに利用できるようにします。ここで考慮すべき2つの重要な基本的能力があります。1つ目はデータレプリケーション戦略です。これは、達成しようとしているRPOの目標によって異なります。この事例では、Amazon Auroraを使用しています。Amazon Auroraにはグローバルデータベースという機能があります。つまり、データベースをクロスリージョンクラスターとしてデプロイし、プライマリリージョンからセカンダリリージョンにデータをレプリケートできるので、セカンダリリージョンでノードが稼働している状態になります。そのリージョンを積極的に使用しているわけではありませんが、パッシブなスタンバイリージョンとして存在しています。
同様に、コードをどのようにデプロイするかについても考える必要があります。なぜなら、両リージョン間でコードと設定を同期させたいからです。ここで注意すべき点がいくつかあります。プライマリリージョンにコードと設定をデプロイするためにコードパイプラインを拡張する際は、一度に1つのリージョンずつデプロイすべきです。その理由は、経験上そして統計的に見て、システム障害の最大の原因の1つが 新しいコードや設定が本番環境に現れることだからです。例えば、不具合のあるコードや設定が入ると、そこからロールバックする必要が出てきますが、これは非常に複雑なプロセスになる可能性があります。Region Oneで不具合のあるコードや設定が何らかの障害を引き起こした場合、同時に別のリージョンにデプロイすると、Region Twoでも同じ問題が発生してしまいます。そうなると、Region Oneでのイベントから適時に回復する能力が損なわれてしまうので、このようなことは絶対に避けなければなりません。
もう1つ重要な点は、リカバリー手順やリカバリーメカニズム、DRランブックなど、 そのランブックを両方のリージョンで利用できるようにする必要があるということです。理想的には、セカンダリリージョン、つまり回復先のリージョンからそれらのランブックを実行したいところです。ここでも理由は似ています。カスケード的な影響がある場合や、これらのランブックが依存する共通の依存関係がある場合、Region Oneのサービスに障害を引き起こした原因が、ランブックを効果的に実行する能力も妨げる可能性があるからです。
したがって、セカンダリリージョンからこれらを実行するのが常に良いアイデアです。フェイルオーバー作業がどのようなものであれ、リーダーをプロモートする必要があります。セカンダリリージョンでリーダーを書き込み可能にプロモートし、ある時点でDNSを切り替える必要があります。これらの手順やステップはすべて、回復先のリージョンから実行することを考えるべきです。
DR戦略のテストとGameDaysの重要性
この時点で、このお客様が自社の取り組みの中で採用したベストプラクティスは注目に値します。まず、DRと運用継続性の戦略は、ビジネスインパクト分析（BIA）に基づいて決定されるべきです。BIAは、ビジネスの重要な部分がどこにあるか、その重要なパスがどのようなものか、そしてその重要なパスを支える重要なシステムは何かを正確に把握するための非常に優れたメカニズムです。これにより、RTOやRPOなどの指標を効果的に導き出すことができます。なぜなら、これは単なる技術的な決定ではなく、ビジネス上の決定だからです。そして、これらのアーキテクチャに伴うコストと運用オーバーヘッド、そしてダウンタイムのコストに対するビジネスケースと比較検討する必要があります。
コードと設定について話してきましたが、次のことを考えてみてください。AWSで使用している用語では、これはstaggered deploymentと呼ばれています。一度に1つのリージョンずつ、あるいはより小さなfault isolation unitがある場合は、1つのfault isolation unitずつデプロイを行います。例えば、AZ独立型のワークロードがある場合、新しいリリースが期待通りに機能しているという確信を得るために、1つのAZずつデプロイすることになります。
適切なデータレプリケーション戦略を選択してください。この例では、Amazon Auroraを使用してこれを実現する方法を示しました。システムオブレコードや選択したデータベースが何であれ、RPOの目標を達成できるかどうかを考える必要があります。これは、単純なバックアップと復元戦略から、ほぼリアルタイムのレプリケーションまで幅広く考えられます。RPOの目標を達成するレプリケーション戦略を検討してください。最後に、セカンダリリージョンから復旧手順とrunbookを呼び出せるようにして、プライマリリージョンの復旧手順に影響を与える可能性のある問題を回避してください。
この旅を続けると、warm standbyを実装した後の次のステップは、このお客様が効果的にフェイルオーバーする能力に自信を持つことでした。DR戦略やレジリエンス全般について顧客と話し合う際によく言及することの1つは、イベントが発生する前に復旧能力を練習することです。これらのイベントが発生したときではなく、常に定期的にその能力を鍛えるのです。これらのメカニズムをテストする適切な頻度を選び、実際にテストしようとしているのは、検出コントロールです。問題を検出できますか？そして、検出や信号に基づいて、復旧コントロールと手順が効果的に機能していますか？
彼らは、私たちがよく推奨することも採用しました。それは、全社的なGameDaysを実施することです。GameDaysは、技術が機能するかどうかだけでなく、関連するプロセスが効果的かどうかをテストするのに非常に良いメカニズムです。これは本当に、人、プロセス、技術が一体となって、よく調整された機械のように機能することを目指しています。これは、インシデント対応が意図したとおりに機能しているか、すべてのrunbookが意図したとおりに機能しているかをテストしようとしているのです。GameDaysは本当に良いメカニズムです。リリースサイクルなどに基づいて、ビジネスに最適な頻度を選択してください。
AWS Fault Injection Serviceを活用したカオス実験
この場合、彼らはAWS Fault Injection Serviceも使用しました。Fault Injection Serviceが実際にこれらのシナリオの自動化やシミュレーションにどのように役立つか、簡単に1分ほど説明させてください。 AWS Fault Injection Serviceは、フルマネージドサービスで、故障を意図的に注入して、システムがこれらの故障にどのように耐えられるかを確認するのに役立ちます。実際には、カオス実験という別の用語を聞いたことがあるかもしれません。システムに意図的にカオスを導入して、再び、復旧コントロールと検出コントロールが機能しているかどうかを確認しようとしています。観測可能性は意図したとおりに機能していますか？これらの信号を適時に受け取っていますか？そして、復旧手順はその故障モードに対して適切に機能していますか？
FISを使用すると、これらの実験をマネージドサービスとして実行できます。このサービスでは、アクションと呼ばれるイベントが提供されます。例えば、EC2インスタンスの終了を試みたり、ネットワークの中断やEBSボリュームの中断を導入したりするなどです。懸念される障害モードが何であれ、効果的にシミュレートすることができます。マネージドサービスであるため、アクティブな本番サービスを中断したくないので、安全性を確保しながら、フェイルセーフモードでこれらの実験を実行したいと思います。そのため、このサービスは実験を実行するための一定のガードレールも提供しています。
ここでも、ベストプラクティスは何でしょうか？検知と復旧の制御を定期的にテストすることです。実際のイベントが発生した場合に備えて、これらの制御を定期的にテストすることの重要性は強調しすぎることはありません。そうすることで、これらの手順やrunbookが意図したとおりに機能するという高い信頼性を持つことができます。
この旅を続け、全体的な耐障害性の姿勢を段階的に改善する中で、次に適用したかったのはフェイルオーバーの準備状況を検証することでした。これは何を意味するのでしょうか？復旧と検知の制御をすべて定義したとしても、フェイルオーバー時に、ターゲットリージョン、つまりセカンダリリージョンに、効果的なフェイルオーバーに必要な基本的な機能や設定の不一致があったらどうでしょうか？例えば、プライマリリージョンと同じ制限がセカンダリリージョンにありますか？すべてのサービスレベルの制限をチェックしましたか？なぜなら、イベント中に制限の引き上げを申請すると、Recovery Time Objectiveを損なうことになるからです。プロビジョニングされた容量はどうでしょうか？プロビジョニングされた容量をサポートする特定のサービスがある場合、リージョン間に不一致はありませんか？これらのすべてのチェック、つまり準備状況のチェックは、これまで話してきた復旧と検知の制御以上に非常に重要です。
Route 53 Application Recovery Controllerの活用
そのために、彼らはRoute 53 Application Recovery Controllerを採用しました。これに馴染みがない方のために、簡単に説明します。Application Recovery Controller（ARC）はRoute 53サービスの一部で、マクロレベルで支援します。 Application Recovery Controllerを採用することには3つの主要な利点があります。1つ目は、先ほど話していた準備状況のチェックです。1分間隔で常に、セカンダリリージョンで提供したパラメータと設定を監査します。先ほど例として挙げたサービス制限やプロビジョニングされた容量の不一致などです。そして、他にも多くのチェックが最初から用意されています。
2つ目は、ルーティング制御そのものです。フェイルオーバー時、特に我々が話しているこのような種類のアーキテクチャ、つまりウォームスタンバイのシナリオでは、実際にはアクティブ/パッシブアーキテクチャですが、すべてのステップを自動化すべきだと推奨しています。つまり、すべてのrunbookなどを自動化すべきですが、あるリージョンから別のリージョンへトラフィックをシフトするという、いわゆるレバーを引く最終的な決定は手動で行うべきです。その理由は、これが非常に重要な決定だからです。トラフィックをシフトするという最終決定を下す際には、その一歩を踏み出す準備が完全にできていることを絶対に確信する必要があります。
レディネスチェックはこの点で重要です。なぜなら、2つ目のリージョンにトラフィックを流す際、必要な容量とデータがすべて揃っていて、レディネスチェックが全て青信号を示していることを確実に確認したいからです。これはDNSレベルでの切り替えを行う前に必要なステップです。そして3つ目のポイントは、これが非常に重要なプロセスであるため、安全規則が必要だということです。このレバーを意図せずに作動させないよう、ガードレールを設ける必要があります。実際、チェックを設けることができます。これはARCのもう一つの特徴で、安全規則を提供し、これらの規則が満たされた場合にのみ、レバーを引いた後に実際にアクションが取られます。ルーティングコントロールは、これらの規則に基づいて実際に実行されるのです。
この時点で強調したいベストプラクティスは次の通りです：復旧の検出とミティゲーションコントロールに加えて、フェイルオーバーチェックを復旧戦略の一部として構築することです。セカンダリリージョンでトラフィックを受け入れる準備が完全にできていることを確認する必要があります。可能な限りApplication Recovery Controllerを使用してください。これにより、自分で構築しなければならない多くのことが簡素化され、自動化されます。なお、これはフェイルオーバーだけでなく、フェイルバック時、つまりセカンダリからプライマリリージョンに戻す際にも同様の考え方が必要です。ARCは両方のシナリオで役立ちます。
繰り返しになりますが、可能な限り自動化することをお勧めします。自動化が進めば進むほど、RTOの目標達成が早くなります。ただし、特にこのようなアーキテクチャでは、最終決定は手動で行うべきです。 さて、続けましょう。この顧客は継続的な改善を採用する道を歩んでおり、段階的な改善を重ねています。
Observabilityスタックのリージョン間拡張
彼らのレジリエンスの旅で次に気づいたのは、observabilityスタックについてでした。フェイルオーバーやフェイルバックのメカニズムをトリガーするには、observabilityスタックが提供する信号に依存します。Observabilityは検出コントロールが機能する場所です。これは非常に基本的な能力であり、ワークロードの他の部分と同じかそれ以上のレベルのレジリエンスを考える必要があります。これらの信号を適時に受け取れないと、適時の復旧能力が損なわれてしまいます。
この場合、彼らが気づいたのは、observabilityスタックをRegion Oneで実行していたことでした。これは信号を検出するのに役立ちますが、 observabilityコントロール自体が損なわれた場合はどうでしょうか？これは、先ほど議論した復旧コントロールの概念と似ています。共通の依存関係や根本的な障害の原因がある場合、observabilityで行った計測も損なわれる可能性があります。そこで彼らが取った対策は、 observabilityスタックをリージョン全体に拡張することでした。セカンダリリージョンを積極的に使用していなくても、少なくとも浅いレベルのヘルスチェックで両方のリージョンを観察するためのobservabilityが必要です。
リージョンの外部から観察し、リージョン内で見えるものと外部から実際に観察できるものの両方を関連付けることができるような、何らかのハートビートメトリクスを持つことが重要です。これは、観測可能性について考える際に非常に重要です。なぜなら、観測可能性に何か障害がある場合、この外部からの視点があれば、問題があるかどうかについてより確実な判断を下し、それらのシグナルに基づいてフェイルオーバーの決定を行うことができるからです。 ここで強調したいベストプラクティスは、リージョンの健全性を内部からだけでなく、そのリージョンの外部からも観察し、フェイルオーバーのための確実な選択を行うことです。
これらの段階的な改善を実施した後、アーキテクチャは現在このような状態になっています。これを進化する視点と呼んでいます。なぜなら、レジリエンスに終わりはないからです。レジリエンスは継続的な改善の旅なのです。ここで指摘したいのは、これらの段階的なステップを踏むことで、いくつかのトレードオフが生じたということです。もちろん、彼らのビジネスの文脈と運用しているシステムの重要性を考えれば、これは絶対に理にかなっていましたが、トレードオフには運用上のオーバーヘッド、追加の複雑性、そして追加のコストが含まれていました。
リージョン間の観測可能性、データレプリケーション、デプロイメントプロセスについて考えてみてください。これらは、これらのアーキテクチャでフェイルオーバーとフェイルバックを行う際に考慮すべき追加の運用オーバーヘッドと複雑性をもたらします。 先ほど述べたポイントに戻りますが、このアーキテクチャの道筋は純粋に技術的な決定ではありません。ビジネスによって主導され、ビジネスケースによってサポートされる必要があります。
オンライン認証プロバイダーのマルチリージョン化への取り組み
それでは、Joe に次のシナリオを説明してもらいましょう。次の顧客シナリオは、認証をサービスとして提供するオンライン認証プロバイダーです。これも急成長中の企業で、成長するにつれて2つの主要な問題に直面し始めました。まず、より大規模な顧客を獲得するようになったのですが（これは良い問題ですね）、これらの大規模顧客は契約内で契約上のSLAを設定することを望んでいました。彼らには設定されたSLAがなく、これらの契約のためにアップタイムSLAを向上させる必要があることを認識していました。さらに、世界中でより多くの顧客を獲得し、さまざまな場所からより多くのユーザーがログインするようになると、サポートケース、オンラインスレッド、そして彼ら自身の内部メトリクスを通じて、異なる地域のユーザーが大きく異なるパフォーマンスを経験していることに気づきました。
チームはこれらの要件を理解し、アップタイムSLAを4ナインの可用性に向上させ、グローバルレベルでレイテンシーを30%削減してアプリケーション全体のパフォーマンスを向上させ、特に最も重要なAPI（認証API）に対してこれを実現したいと考えました。ここに簡単なアーキテクチャ図が示されています。これは現在、シングルリージョンのアプリケーションです。ユーザーがアクセスすると、まずAPI Gatewayのエンドポイントにヒットし、そしてリクエストに応じて、ユーザーはLambda関数か、ECSコンテナとEC2インスタンスの両方を持つApplication Load Balancerのいずれかに振り分けられます。そして、下部には永続的なストレージレイヤーがあり、DynamoDBとS3で構成されています。
このお客様がこの旅を始めたとき、まず下位環境でこの環境の構築を始めようとしましたが、すぐに最初の問題に直面しました。ワークロードの約20%が、インフラストラクチャ・アズ・コードのテンプレートで定義されていないか、テンプレートと本番環境で実際に稼働しているものとの間に大きな乖離があることに気づいたのです。そのため、ワークロードの完全な監査を最初から最後まで行い、インフラストラクチャ・アズ・コードのテンプレートと本番環境で稼働しているものが一致していることを確認する必要がありました。複数のリージョンにまたがる手動リリースや手動変更は、問題が多く、エラーが発生しやすく、時間がかかることを認識していました。
デプロイ先のすべてのリージョンで一貫したデプロイメントを確保するため、AWS CloudFormationを採用しました。CloudFormation内で、アプリケーションを別々のスタックに分割しました。これらのスタックは、例えばフロントエンド用、バックエンド用、共有サービス用、データ層用などです。これらのテンプレート内で、CloudFormationスタックセットを作成しました。このCloudFormationスタックセットにより、同じスタックを複数のリージョンにデプロイすることができました。 しかし、すべてのリージョンに同時にデプロイしたくありませんでした。他のリージョンに展開する前に、デプロイメントが健全であることを確認するための十分な焼き込み時間、つまりデプロイ後の十分な時間を確保したかったのです。
これを実現するために、CloudFormationのパラメータとwait conditionを組み合わせて使用し、一度に1つのリージョンにのみデプロイし、次のリージョンにデプロイする前に十分な時間を待つようにしました。 次に克服する必要があった問題は、グローバルに分散した、インテリジェントで信頼性の高いルーティング層をどのように実現するかということでした。ユーザーがアプリケーションにアクセスしたときに、自動的に最も関連性の高い場所、つまりこの場合はレイテンシーが最も低い場所にルーティングされるようにしたいと考えました。
これを実現するために、Route 53のレイテンシーベースのレコードセットを利用しました。これらのレイテンシーベースのレコードセットは、基本的に、ユーザーがRoute 53レコードにリクエストを送信すると、Route 53がその特定のリクエストに対して最もレイテンシーの低いアプリケーションを判断し、最もレイテンシーの低いアプリケーションのIPを返すというものです。 そうすることで、ユーザーは自分にとってレイテンシーが最も低い関連リージョンに誘導されます。
マルチリージョンデプロイメントのベストプラクティス
また、メンテナンスのためにリージョンからトラフィックを移動させたり、リージョナルデプロイメントの1つに予期せぬ問題や課題が発生した場合に対応するための簡単な仕組みも欲しいと考えました。そのために、Route 53 Application Recovery Controllerを利用しました。これは基本的に、そのレイテンシーベースのレコードセットにヘルスチェックを付加し、Route 53の高可用性データプランを利用して、 それらのヘルスレコードのスイッチを切り替え、どのリージョンにルーティングできるか、つまりRoute 53レコードからどのリージョンが返されるかを決定します。
オンライン認証プロバイダーとして、セキュリティは常に最優先事項でした。そのため、SQL インジェクション やクロスサイトスクリプティング攻撃、その他のレイヤー7攻撃に対する追加の保護も必要でした。そこで、API Gateway エンドポイントの前に AWS Web Application Firewall を配置しました。
ここで一旦立ち止まって、このシナリオの最初のスライドから得られるベストプラクティスをいくつか見てみましょう。まず、マルチリージョンアーキテクチャに移行する際、デプロイメントのベストプラクティスと CI/CD のベストプラクティスがますます重要になります。Infrastructure as Code を活用することで、複数の異なるリージョンで一貫したデプロイメントを確実に行うことができます。次に、リージョナルパラメータや待機時間、待機状態などを活用することも、もう一つのベストプラクティスです。一度に1つのリージョンにのみデプロイし、そのデプロイメントが完了した後に十分な時間を設けることが重要です。
このお客様は、信頼性が高くインテリジェントなルーティング層を作成するための最適なソリューションを見つけるのに多くの時間を費やしました。彼らの特定のユースケースでは、Route 53 のレイテンシーベースのレコードと Route 53 Application Recovery Controller を利用して、ユーザーのルーティングとメンテナンスや障害時の誘導を行いました。
ご想像の通り、これは非常に読み取りの多いワークロードです。 ユーザーは、ユーザーの権限を変更するよりも、認証 API で認証リクエストを行う方がはるかに多いのです。しかし、ユーザーの権限を変更する必要がある場合、例えば権限を取り消す場合など、お客様はそれができるだけ迅速かつ確実に行われることを望んでいます。では、彼らがどのようにしてこれを実現したのか見てみましょう。
データレプリケーション戦略とCAP定理
まず、同期レプリケーションと非同期レプリケーションの両方を検討しました。しかし、2つのリージョンでのデプロイメントにおいて、主に2つの理由から同期レプリケーションを選択しませんでした。1つ目の理由は、アプリケーションに入力される単一の書き込みが、両方のリージョナルデプロイメントから完全に一貫性を持ち、承認される必要があるからです。これは、一方のワークロードデプロイメントに問題が発生すると、ワークロード全体がダウンしてしまうことを意味し、依存関係がリージョンをまたがっているため可用性が低下してしまいます。2つ目の理由は、一方のリージョンに入力される書き込みが、もう一方のリージョンからも承認される必要があるからです。これにより、レイテンシーが増加し、これらの書き込みにかかる時間が長くなってしまいます。
彼らが当初持っていた2つの要件は、可用性の向上とパフォーマンスの向上でした。同期レプリケーションはこれらの要件に反するものでした。このため、彼らは非同期レプリケーションを選択し、DynamoDB global tablesを使用して実現しました。DynamoDB global tablesは、マルチリージョン、マルチライターのデータベースソリューションを提供し、リージョン間のデプロイメント間の典型的なレプリケーション遅延は1秒以下でした。また、DynamoDB global tablesには、衝突解決などの組み込み機能もあり、同じリクエストが両方のリージョンに入ってきた場合、最後に書き込んだ方が勝つという仕組みになっています。
さて、ユーザーが来てユーザーの権限を変更する必要がある場合、例えばユーザーの権限を取り消す必要がある場合、彼らはヘッジングという概念と、べき等なトランザクションを利用しました。これがどういう意味なのか、見てみましょう。まず、ユーザーAの権限を取り消すリクエストが来たというシナリオを使ってみましょう。そのリクエストは、インテリジェントSDKに送られます。このSDKのインテリジェンスは、主にアプリケーションの健全なリージョナルデプロイメントをすべて認識しているということです。
SDKに到達すると、SDKはこれが非常に重要なリクエストであるため、すべての場所に送信する必要があると判断し、両方のリージョナルエンドポイントに同時にそのリクエストを送信します。光の速度や長距離での遅延などの要因により、両方のリージョナルエンドポイントに同時に到達することはありませんが、1つのリージョナルエンドポイントにのみ行き、もう一方に複製される場合よりも速く両方に到達します。このように、この場合、P99レイテンシーを実質的に削減しています。また、潜在的なネットワーク伝送の問題からも保護しています。
ここで非常に重要なポイントは、これらのトランザクション、これらのリクエストがすべてべき等であるということです。つまり、同じリクエストが複数回行われても、最終的な結果は変わらないということです。彼らがこのシナリオでこれを実現した方法は、リクエスト内にユーザーの権限セット全体を送信することで、新しいユーザーの権限セットが以前のユーザーセットに基づいて決定されないようにしました。
さて、マルチリージョンアーキテクチャとデータレプリケーションに関しては、多くの場合、最大の課題は光の速度とデータをどれだけ速く転送できるかということです。光の速度はとても速いですよね？しかし、長距離でのデータ転送に使用される光ファイバーに入れ、その上に権威やプロトコル、転送、再転送を加えると、長距離でのデータ転送は光の速度よりもはるかに遅くなります。しかし、結局のところ、データが移動する距離が長くなればなるほど、ワークロードに加わるレイテンシーが大きくなるということです。これを理解し、どのようなオプションがあるかを知るために、私たちには基本定理があります。
私たちには、CAP定理と呼ばれる重要な定理があります。CAP定理は分散システム専用に作られたもので、分散システム（マルチリージョンアーキテクチャもこれに該当します）では、可用性、一貫性、分断耐性の3つのうち2つしか選べないと述べています。マルチリージョンアプリケーションは複数の場所に分散しているため、通常は分断耐性が必須となります。そのため、残りの2つの選択肢から1つを選ぶことになります。
1つ目の選択肢は、一貫性と分断耐性です。これは強い一貫性要件を持つアプリケーションに適していますが、書き込みが両方の場所で完全に永続化される必要があるため、パフォーマンスと可用性が低下するというトレードオフがあります。強い一貫性要件を持つアプリケーションの場合、3つ目のリージョンを追加し、クォーラムベースのモデルを使用することを検討するとよいでしょう。このモデルでは、3つのうち2つの書き込みが完全に確認されてはじめて、その書き込みが完全に一貫性を持つとみなされます。
2つ目の選択肢は、おそらく大多数の顧客が利用している可用性と分断耐性です。これにより、顧客はワークロードの可用性向上というメリットを得られます。ただし、トレードオフとして、ワークロードは結果整合性を許容する必要があります。リージョナルワークロードの1つに問題が発生した場合、進行中のトランザクションが失われる可能性があります。それでも、可用性の向上は大きなメリットと言えるでしょう。
差分観測性とリージョンの独立性
2つ目の選択肢である可用性と分断耐性を選んだ場合、監視すべき重要な項目の1つがデータレプリケーションです。このシナリオでは、DynamoDB global tablesとS3 Cross-Region Replicationの両方を利用することになります。2つの場所間のレプリケーション遅延を監視し、適切なアラートを設定しておくことが重要です。レプリケーション遅延が一定のしきい値を超えた場合、オンコールエンジニアに通知して適切な対応を取ってもらう必要があります。
世界中で可用性を向上させようとしていたこの顧客にとって、可用性メトリクスを適切に理解し測定することは非常に重要でした。彼らは3つの異なる角度からこの問題にアプローチしました。まず、サーバーログを調べてリクエストのエラー率と処理時間を確認しました。次に、Region TwoやさらにThird regionから合成チェックを実行しました。これらの合成チェックは一般的なユーザーワークフローを実行し、アクティブ時間を監視して、予想を超える時間がかかった場合にアラートを発しました。
3つ目の視点はユーザーのエンドポイントからのものでした。彼らはCloudWatch Real User Monitoringを活用して、ユーザーの視点から見た所要時間とエラー率をよく理解し、それらをモニタリングツールに取り込みました。これを我々は差分観測性と呼んでいます。3つの異なる視点を用いて、アプリケーションの健全性をより包括的かつ正確に理解するアプローチです。このアプローチにより、アプリケーション全体の健全性を理解するだけでなく、ワークロードの単一の視点だけでは見えなかったかもしれない問題も掘り下げることができます。
これまで議論してきたベストプラクティスを振り返ってみましょう。まず、ワークロードの一貫性の特性と、その一貫性要件を満たすために利用可能なレプリケーションオプションを理解することです。多くの顧客がワークロードの可用性向上のために非同期レプリケーションを使用していますが、強い一貫性要件を持つワークロードにはクォーラムベースのモデルを使用することについても議論しました。マルチリージョン、マルチライターのワークロードがある場合は、一貫性のための適切なチェックを確実に行う必要があります。これには、リクエストがべき等であることの確認、競合解決の実装、複数の場所に同時に書き込むことによって発生する可能性のある不整合の検出が含まれます。
最後に、差分観測性について話しました。アプリケーションの1つの視点は良いですが、差分観測性を通じて異なる視点から複数の視点を活用することで、アプリケーションの健全性についてより包括的で真の姿を得ることができます。 この顧客が次に確実にしたかったのは、各リージョンが他のリージョンから100%独立して機能できることでした。リージョン1の問題がリージョン2に影響を与えないようにしたかったのです。これを我々はリージョンの独立性と呼んでいます。
マルチリージョン運用の課題と新リージョン選択のフレームワーク
彼らはリージョンレベルで非常に厳格な障害分離境界を強制することでこれを達成しました。本質的に、これはリージョン1とリージョン2のアプリケーションにクロスリージョンの呼び出しや依存関係がないことを意味します。そして、未知の問題を見つけるためにテストを行いました。計画されたイベント中に、リージョン1からリージョン2へすべてのトラフィックをシフトしました。これを行った際、リージョン1内の多くのリソースがまだアクティブにデータを処理していることに気づきました。これにより、未知の問題が明らかになり、それは予期せぬバックエンド呼び出しを行っているレガシーシステムであることがわかりました。テストによってこれを発見し、リージョンレベルでより厳格な障害分離境界を設けることができました。
このお客様がマルチリージョン化を進める中で、IT支出やインフラに関連するコスト増加の見積もりは上手くできていました。しかし、彼らも認めているように、ワークロードの運用コストの見積もりは不十分でした。運用の観点から、運用コストがどこに向かっているのか、今後の見通しはどうなのかを理解するため、一歩下がって考える必要がありました。シングルリージョンではなく、マルチリージョンアプリケーションのためのポリシーや手順を再検討する必要がありました。例えば、アラートが到着したときにどのリージョンからのものかを判断するような単純なことでも、runbookを更新する必要がありました。
また、リージョンの退避やメンテナンスのためのトラフィックシフトなど、新しいタスクのためのrunbookも作成する必要がありました。これらのrunbookは、異なる稼働状態を考慮する必要がありました。例えば、アプリケーションが完全に健全な状態でリージョンを退避する必要がある場合と、ワークロードが部分的に不健全な場合とでは、異なるステップを踏むことになります。部分的に利用可能なシナリオでは、すべてのアクションが健全なリージョンから来ることを確認したいと考えました。さらに、多くのサービスクォータはリージョンレベルで設定されています。ワークロードが成長するにつれて、サービス制限の引き上げを行う可能性が高くなります。これらのサービス制限の引き上げはほとんどがアカウントレベルではないので、そのサービス制限クォータを追跡することが重要です。マルチリージョンアーキテクチャに移行する際、一つのリージョンで制限を引き上げたら、他のリージョンでも引き上げるようにしてください。このために、AWS Service Quotasサービスを使用できます。これは、リージョンレベルで定義された異なるサービスクォータをチェックし、理解し、サービス制限の引き上げを行うのに役立ちます。
このお客様のシナリオの冒頭で述べたように、彼らはすべてをインフラストラクチャ・アズ・コードで行うというマインドセットにシフトする必要がありました。これは素晴らしいことで、会社とエンジニアたちはそれを実践していました。しかし、追加のチェックを入れることも重要です。これらのチェックは、特にこのシナリオでは、Region OneとRegion Twoが同じであることを確認します。なぜなら、彼らは異なるリージョンでユーザーが異なる体験をすることを望んでいなかったからです。これは非常に重要でした。
検知を支援するために、彼らは Route 53 Application Recovery Controller (ARC) を活用して、レディネスチェックを実施しました。これらのレディネスチェックは、両方のリージョンのリソースを継続的にポーリングし、サービス制限、クォータ、スロットリング、そして発生する可能性のあるバージョンの違いなどを確認します。そして、不整合が見つかった場合には誰かが修正できるように警告を発します。
この顧客は複数のリージョンにわたってアプリケーションを展開することに成功しましたが、彼らの主要な要件の1つは、エンドユーザーに対する全体的なパフォーマンスを向上させることでした。
彼らは、グローバルな規模でパフォーマンスを向上させることで、自社製品の新しい市場や新しい企業を開拓できることを知っていました。そこで、次にどのリージョンに進出するかを検討する際、そのためのフレームワークを作成する必要がありました。そのフレームワークの始まりがここにあります。
まず、ユーザーがどこから来ているかを調べました。特に、最も高いレイテンシーを示す場所を特定し、そのレイテンシーの高さと量を分析しました。次に、進出したいリージョンを絞り込む際、現在世界中に32のリージョンがあることを考慮しました。最も高いレイテンシーが見られる場所に基づいて、リージョンを絞り込みました。
次に、彼らはコストを検討しました。AWSサービスの価格は地域によって異なる場合があります。これは、税金、労働力、電力、材料などの要因により、サービスの提供コストが異なるためです。これらの要因は世界の地理的条件によって大きく異なるため、地域ごとにコストが異なります。ここでの最適な出発点は、AWSの公開価格ページとAWS Pricing Calculatorを確認することです。これらは、地域間のコストの違いを把握するのに役立ちます。
3番目の考慮事項はサービスの利用可能性でした。すべてのAWSサービスがすべてのAWSリージョンで利用できるわけではありません。私たちはすべてのサービスをどこでも利用可能にするための取り組みを行っていますが、正直なところ、まだまだ道のりは長いです。ワークロードに必要なリージョンでサービスが利用できない場合は、AWSアカウントチームに知らせてください。ロードマップの90〜95%は、お客様からのこのようなフィードバックに基づいて直接影響を受けています。このお客様が行ったのは、使用しているすべてのAWSサービスと機能の完全な一覧を作成し、それを各サービスの地域別利用可能性に関するAWSの公開ページと照合することでした。
さて、このお客様から学んだ最後のベストプラクティスをいくつか紹介します。まず、異なる地域のワークロード間の不整合を検出するためのツールを用意することです。特にこのようなアクティブ/アクティブ構成では、ユーザーがアクセスする場所によって異なるユーザー体験をすることは望ましくありません。また、進出するリージョンを選択する際には、考慮すべき点が多くあります。ワークロード、ビジネス、ユーザーにとって最適なものを確実に選択してください。ユーザーの所在地、レイテンシー、コスト、サービスの利用可能性などは、非常に一般的な考慮事項です。
マルチリージョンアーキテクチャの結論と追加リソース
では、現在進化中のアーキテクチャをご紹介します。ここでは常に進化が続いています。時間の制約があるため、すべてについて話すことはできませんでした。トップ10の項目だけを取り上げました。しかし、ECSコンテナやレプリケーション、Lambdaファンクションの展開方法、ECS、またはEC2インスタンスなど、いくつかの点に触れていないことにお気づきでしょう。ですので、時間をかけることが重要です。まず要件を理解し、そして一歩ずつ、一つずつ、アーキテクチャをマルチリージョンに進化させていくことが大切です。では、まとめのためにNeerajに戻します。
さて、これら2つのストーリー、2つのシナリオに基づいて、いくつかの結論的な考察をしてみましょう。このプレゼンテーションから皆さんに持ち帰っていただきたい重要なポイントです。まず第一に、AWSのリージョンは非常に回復力が高く、Availability Zoneなどを通じたインフラレベルの冗長性があるため、ほとんどのアプリケーションは必ずしもマルチリージョンである必要はありません。ですので、マルチリージョンに移行する理由を、ビジネスニーズ、達成したい目標、具体的なビジネスケースに基づいて明確にしておく必要があります。
Joeが説明したシナリオで見られたいくつかのニュアンス、特にデータと依存関係が複雑になる可能性があるという点は、マルチリージョンの旅に乗り出す前に十分に考慮する必要があります。どのような依存関係を持つのか、どのようなデータアクセスパターンとデータ一貫性のニーズがあるのかを考える必要があります。なぜなら、それによって特定の方向に導かれるからです。特にアクティブ-アクティブの場合は非常に複雑になる可能性があります。べき等性やそのようなアーキテクチャに付随する他の要素についても考慮しなければなりません。
Observabilityについても、いくら強調してもしすぎることはありません。これは、シングルリージョンの耐障害性のあるアプリケーションを構築する場合でも、この場合のマルチリージョンの耐障害性のあるアプリケーションを構築する場合でも、基盤となる重要な要素です。したがって、Observabilityと、コードをどのように適用し、リカバリー検出および緩和コントロールをどのようにテストするかは非常に重要です。
リカバリーの検出と緩和のコントロールについては、この取り組みを始める前に十分に考えておくことが重要です。もちろん、これらのソリューションを展開する際には追加のコストを考慮する必要があります。この発表では本当に表面的なことしか触れていません。マルチリージョンアーキテクチャを実装する方法は一つではありません。アクティブ/アクティブの例でさえ、アクティブ/アクティブやアクティブ/パッシブのマルチリージョンアーキテクチャを実装するには複数の方法があります。アプローチはビジネスケースに基づいて決定されるべきで、私たちはそのサポートをします。適切な方向に導くため、アカウントチームやAWSの担当者と協力してください。
いくつかのリソースについて簡単に触れたいと思います。先ほど述べたように、この発表はそれほど深い内容ではありませんが、このトピックについてもっと理解したい場合は、マルチリージョンの基礎に関するホワイトペーパーを公開しています。数ヶ月前に同僚の一人が執筆したものです。このセッションで議論してきた同様のベストプラクティスに基づいていますが、私たちが扱った内容よりもはるかに深く掘り下げています。最近公開したもう一つのホワイトペーパーは、「The Resilience Lifecycle Framework」です。Google検索で簡単に見つけられます。このホワイトペーパーは、異なるステージで考慮すべき戦略とメカニズムを共有しています。SDLCモデルに基づいており、目標設定、要件の理解、設計と実装段階でのレジリエンス思考の組み込みなどの側面をカバーしています。マルチリージョンだけでなく、このフレームワークのライフサイクルの概念に沿った幅広いレジリエンスのベストプラクティスに関するホワイトペーパーです。
このような思想的リーダーシップに加えて、 私たちは顧客からのフィードバックに基づいて、さまざまなレジリエンス関連のオファリングにも投資しています。この発表でいくつか触れましたが、例えばカオス実験の管理に役立つAWS Fault Injection Serviceや、ルーティングコントロールとレディネスチェックのためのAmazon Route 53 Application Recovery Controllerなどがあります。他にも、AWS Resilience HubやAWS Backupなど、この発表では触れていないサービスもあります。これらは特に、バックアップとリストアに関するエントリーレベルの戦略を検討している場合に役立ちます。マルチリージョンのDR戦略を考える際には、AWS Elastic Disaster Recoveryも検討に値するサービスです。
また、ランディングページにAWSソリューションをたくさん公開しています。AWS solutionsで検索すると、これまでに公開してきたマルチリージョンやその他のレジリエンス関連のソリューションのいくつかが見つかるでしょう。以上で終わりですが、皆さんにお越しいただき、ありがとうございました。特に遅い時間帯にもかかわらず、本当に感謝しています。 フィードバックを残していただけると幸いです。これらのセッションを継続的に改善するのに役立ちます。ありがとうございました。re:Inventをお楽しみください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion