Ops JAWS Meetup#24 静的安定性を考える 依存しないアーキテクチャ 2023年6月26日

2 自己紹介 経歴 HWエンジニア → 中小SIer → ERPコンサル → AWS パートナー Follow Me https://twitter.com/YoshiiRyo1 Community OpsJAWS JAWS-UG GameTech専門支部 好きな言葉 No human labor is no human error. Ryo Yoshii 吉井 亮

静的安定性とは システムが静的な状態で動作し、 依存関係に障害が発生しても、 通常通り動作し続けることができる

静的安定性のアプローチ ● 循環的な依存関係を排除 ● 事前のプロビジョニング ● 正常な状態を維持する ● 非同期処理を採用

前提知識

コントロールプレーンとデータプレーン コントロールプレーン ● リソースの作成、読み込み、更 新、削除、リスト (CRUDL) に使用される管理API ● 複雑な仕組みで依存関係が多い データプレーン ● AWS サービスの動作部分 ● 比較的シンプルで依存関係が 少ない ● 障害が起きにくい

コントロールプレーンとデータプレーン EC2例 コントロールプレーン ● 容量のある物理サーバを探す ● ネットワークインターフェースを 割り当てる ● EBS ボリュームを準備する ● IAM 認証情報を生成する ● セキュリティグループのルールを 追加する データプレーン ● EBSボリュームから読み書きする ● EC2 インスタンスの実行 ● S3 バケットへのオブジェクトの取 得と配置 ● Route 53 DNSクエリへの応答 ● ヘルスチェックの実行

re:Invent 2022 SUP401 https://www.youtube.com/watch?v=62ZQHTruBnk

コントロールプレーンに依存しない

Availability Zone (サブネット) AZ-A AZ-C AZ-D NAT Gateway NAT Gateway NAT Gateway Subnet Subnet Subnet

Availability Zone (サブネット) とりあえず 2AZ で運用して障害起きたら残りの AZ 使おう NAT Gateway 料金もったいないし → AZ 障害や近い規模の障害が発生しているときに サブネット増やす API が受け付けられるとは 考えないほうが静的安定性の観点で安心。

サブネットの例以外でも原則として 復旧手順にコントロールプレーン依存を 含めないようにする

EC2 Auto Scaling AZ-A AZ-C AZ-D サービスに必要なインスタンス数が 6 だとしたら？ 2 or 3 2 or 3 2 or 3

コントロールプレーンに依存しない (北米リージョンに依存しない)

日本時間 2023年06月14日 午前4時18分～午前7時42分 に バージニア北部リージョン(us-east-1)の 複数のサービスにおいてエラーレートの上昇および遅延が 発生していました

IAM コントロールプレーンは US-EAST-1

商用リージョンでのコントロールプレーン場所 パーティショナルサービス ● AWS IAM (us-east-1) ● AWS Organizations (us-east-1) ● AWS Account Management (us-east-1) ● Route 53 Application Recovery Controller (ARC) (us-west-2) ● AWS Network Manager (us-west-2) ● Route 53 Private DNS (us-east-1) エッジネットワークグローバルサービス ● Route 53 Public DNS (us-east-1) ● Amazon CloudFront (us-east-1) ● AWS WAF Classic for CloudFront (us-east-1) ● AWS WAF for CloudFront (us-east-1) ● Amazon Certificate Manager (ACM) for CloudFront (us-east-1) ● AWS Global Accelerator (AGA) (us-west-2) ● AWS Shield Advanced (us-east-1) シングルリージョンサービス ● Route 53 (us-east-1) ● S3 (us-east-1) ● S3 Multi-Region Access Points (us-west-2) ● CloudFront (us-east-1) ●

アプリケーションロジックの考慮 1. S3 バケット存在確認 2. Yes なら後続処理 3. No なら作ってから後続処理 みたいロジックは書かないほうが幸せかも

AWS の物量に依存しない

キャパシティ不足 🥺 We currently do not have sufficient t3.medium capacity in the Availability Zone you requested (ap-northeast-1a). Our system will be working on provisioning additional capacity. You can currently get t3.medium capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1c, ap-northeast-1d.

https://dev.classmethod.jp/articles/ec2-capacity-reservations-matome/

EC2 Auto Scaling

サービス間に依存しない

連鎖障害を防ぐ App A App B App B がダウンしたときにその影響が全体に 及ばないようにすると、静的安定性が高まる。 - リクエストタイムアウト - リクエストリトライ回数制限 - キューイング - サーキットブレーカー - Read Only なデータはローカルにキャッシュ App C

参考 モダンアプリケーションのためのアーキテクチャデザインパターンと実装 https://pages.awscloud.com/rs/112-TZM-766/images/AWS-21_AWS_Summit_Online_2020_MAD01.pdf クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン https://pages.awscloud.com/rs/112-TZM-766/images/D-02.pdf AWS Fault Isolation Boundaries https://dev.classmethod.jp/articles/aws-fault-isolation-boundaries/ アベイラビリティーゾーンを使用した静的安定性 https://aws.amazon.com/jp/builders-library/static-stability-using-availability-zones/

THANK YOU