概要
2024/06/20〜21に幕張メッセで行われている「AWS Summit Japan」にオフライン参加しています！
昨年のレビューで人気が高いと評判のセッション「アーキテクチャ道場！」に参加しましたので、所感をレポートします。
初日の樣子もブログにしていますので、是非併せてご一読ください。
セッション内容
既存のシステムにつき、何らかのお題が与えられ、ソリューションアーキテクトによる改善案のプレゼンテーションならびにMCによる質疑応答が行われます。
今回は「Resilience（回復力）」をテーマに2つの例題が上がりましたが、その内1つの事例につき、レポートします。
例題1「金融機関における決済システムがAWSで稼働しており、3つのAZ上で稼働している。その中、1つのAZで障害が発生した場合、ユーザへの影響度が極力小さくなるようにアーキテクチャを改善してください。」
『基本方針』
- 障害が発生したAZにつき、ワークロードから切り離すことができること。
- 障害が発生したAZを隔離しやすくするために、AZ間の独立性を高めること。（AZを跨ぐ通信・処理をアーキテクチャから極力除外する。）
【使用サービス】
- Route53
- ALB
- EKS（フロント・バック）
- Aurora
【アーキテクチャ改修案】
［ALBへのアプローチ］
- クロスゾーン負荷分散機能が有効になっていると、AZを跨ってリクエストを行ってしまう。
- クロスゾーン負荷分散は無効にし、各AZにALBを配置、Route53側で負荷分散を行う。
［EKSへのアプローチ］
（筆者が業務上EKSを触っていないこともあり、一部記載内容に齟齬がある場合があります。）
- すべてのAZにPodが存在する必要がある。
- 個別のAZにFargate Profileを作成して、各AZごとにDeploymentを作成する。
- バック側につき、各AZごとに作成し、各AZに存在するフロントサービスからのエンドポイントとして環境変数を個別に指定する。
- 個別のAZにFargate Profileを作成して、各AZごとにDeploymentを作成する。
［Auroraへのアプローチ］
- （Readerインスタンス）
- カスタムエンドポイントを用い、各AZに存在するAuroraインスタンスを紐づけ、各AZに存在するバックサービスからのDBエンドポイントとして指定する。
- （Writerインスタンス）
- 1つのクラスターにつき、WriterインスタンスはいずれかのAZのうち、1箇所にしか配置出来ないため、AZ間の通信を例外的に認める。
- Writerインスタンスが複数存在する場合、データの一貫性が担保できないため不採用とする。
- 1つのクラスターにつき、WriterインスタンスはいずれかのAZのうち、1箇所にしか配置出来ないため、AZ間の通信を例外的に認める。
【障害検知】
- 1つのAZで障害は発生した場合に起こり得る事象と、障害発生時に観測される事象を整理する。
- ただし、上記で記載した事象が発生した＝AZの障害とはならない場合があるので、さらに事象の整理を進める。（Aurora単独の障害であり、AZ自体はとくに障害が起きていない可能性もある。）
- 事象の整理を行い、真にAZで障害が発生したと判断できる場合に、AZの隔離を行うか判断する。
- Cloudwatchにおける複合アラームの機能が有効。
【障害が発生したAZの隔離の実現方法】
- Route53 ARC（Application Recovery Controller）を用いて、障害が発生したAZにあるALBのIPを取り除き、リクエストが流れないようにする。
最後に
障害やトラブルの可能性を0％にすることは出来ないが、限りなく0％に近づけることは可能であり、セキュリティ・信頼性を常日頃意識して業務に従事する必要があると再認識できました。
また筆者はALBのクロスゾーン負荷分散はマストであり、脳死で有効にしていましたが、場合によっては無効化した方が要求を実現できるというのは目からウロコでした。
2日間で色んな話をインプットでき、色々試してみたいことが増えたので、試した内容をブログにまとめていきます。
Discussion