継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

東京リージョンの障害から設計と運用の考慮点を整理する

タダです.

先日, AWS の東京リージョンでの障害があったことは AWS 利用者のみなさんはご存知かと思います.今回の障害を踏まえ,今後の設計や運用にどう活かすかを考えたりチームで話し合ったりしていると思うのですが,僕も所属チームで振り返りをしました.その振り返りを踏まえ,自分なりに今回の障害から今後の設計と運用にどう活かしていくかをこの記事に残していきます.なお,記事で取り扱う考慮点以外にも考慮事項がある場合,ご指摘いただけるとありがたいです.

公式レポート

aws.amazon.com

メディアの記事

www.itmedia.co.jp

piyolog さんの時系列や影響のあったサービスの記事

piyolog.hatenadiary.jp

AWS CLI で振り返る AWS 障害時の各種ステータス確認方法

sadayoshi-tada.hatenablog.com

設計の考慮点

今回の障害を受けて設計時に検討が必要なキーフレーズとして以下を考えます.

  • Availability Zone の冗長化(マルチAZ)
  • ELBのスティッキーセッション
  • ステートレス
  • Design for Failure

Availability Zone の冗長化(マルチAZ)

AWS のネットワーク設計の重要な概念の1つである Availability Zone (データセンター群)を冗長化するのは今回のような特定の Availability Zone で障害が発生した時もシステムの稼働を継続させるために行います.

東京リージョンでは現状3つの Availability Zone が利用可能です.ただ,今回の障害においては 冗長化した Availability Zone(マルチAZ) に設定していても影響があったサービスがありました.3つの Availability Zone において影響があったかは公開されてないものの,システムの可用性を上げるために利用可能な Availability Zone は全て利用した設計を検討すべきでしょう.当然ながら Availability Zone を冗長化していれば万事安全ではなく,後述する復旧の手順・プロセスや承認フローを確立しておくのも合わせて大事だと考えます.

個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。

ELBのスティッキーセッション

今回の障害でも影響があったとレポートがあったスティッキーセッションですが,チーム内の振り返りでスティッキーセッションはできる限り使わず,ステートレスな設計を進めるべきだと話し合いました.ステートレスの話は後述するためここではスティッキーセッションの話を整理しておきます.

ロードバランサーのスティッキーセッションの効果は,セッション維持を固定のインスタンスで管理することです.今回の障害では特定の Availability Zone 1つで障害が発生して該当の Availability Zone に配置したサーバーは稼働できない状況に陥りました.そのため,セッション管理の維持は可能であれば,例えばデータベースやキャッシュサーバーに外出し管理する設計をできないかを検討しましょう.

AWS ドキュメント

docs.aws.amazon.com

ステートレス

チーム内の振り返りでスティッキーセッションを使わず,ステートレスな設計を使って EC2 を AutoScaling で構成していた場合復旧はインスタンスを入れ替えるだけで復旧できた事例がありました.ステートレスな設計をしておくことで復旧が簡易かつ,迅速に行えたことはとても有益な設計考慮点だと言えるのではないしょうか? また,有名なThe Twelve-Factor Appにもステートレスが文脈に出てくるほどです.このような事実と設計思想からステートレスな設計が今後の設計で活かしていきたいと強く感じたポイントでした.改めてThe Twelve-Factor Appの思想も読み直します.

www.slideshare.net

Twelve-Factor App(日本語訳) 12factor.net

Design for Failure

クラウドと言えどもオンプレミスのデータセンター同様にサーバーがダウンしてしまうことはあるということを今回再認識された方は多いのではないでしょうか? 障害が発生することを前提に設計する考えを Design for Failure(故障のための設計)と呼びますが,まさしくこの観点を入れる必要があります.この設計の考えを実現するには,如何に復旧する仕組みを入れるかがキモですが,自動復旧するように AutoScaling やAutoRecovery, CloudWatch Events などを取り入れて障害に強いアーキテクチャを検討しましょう.

Amazon EC2のイベント対応を楽にするためのアイデアと「Design for Failure」の考え方

codezine.jp

運用の考慮点

今回の障害を受けて運用で検討が必要なキーフレーズとして以下を考えます.

  • 障害検知
  • バックアップの取得
  • 復旧試験の実施
  • カオスエンジニアリング

障害検知

一般的にサーバーの監視は各種サービスを使って管理していいると思いますが,今回のようなサービス基盤の障害を感知する手段をここでは整理します.AWS にはAWS Personal Health Dashboardで通知を受取り,障害を感知することが可能なので, CloudWatch Events と組み合わせて設定しましょう.障害だけでなく, EC2 のリタイアメントのイベントも通知可能です.

AWS Personal Health Dashboard

aws.amazon.com

CloudWatch Events との統合

docs.aws.amazon.com

バックアップの取得

障害に対峙するために改めて AMI やスナップショットを取得し,復旧できるようにする仕組み化できていない部分がないかを見直しましょう.管理している AWS 環境によっては大量のリソース状況を網羅するのは容易ではないため,AWS Trusted Advidosr を使って確認するのもよいでしょう.

AWS Trusted Advidosr のベストプラクティス

aws.amazon.com

復旧試験の実施

バックアップを取るだけでなく,どう復旧するかの復旧プロセスや組織内で復旧を誰がどのようにハンドリングするかの方針を確立し,復旧プロセスの試験も行うべきでしょう.復旧できてこそバックアップの効果がでます.そのためにも,バックアップを使って如何に復旧するかを試験してリリースするのが望ましいと考えます.

カオスエンジニアリング

障害を意図的に起こして対応する手法として,カオスエンジニアリングがあります.Netflix で実際に行われている手法です.詳細はまた別の記事で整理したいと思いますが,カオスエンジニアリングの目的は本番サービスで意図的に障害が発生しても復旧し,通常サービスを提供していけるかといった安定性・可用性向上のためです.リリースできたから OK ではなく,システムを育て続けるための手法の1つとして検討して良いかもしれません.なお,日本ではクックパッドさんがカオスエンジニアリングの実施宣言をした記事が有名ですね.

PRINCIPLES OF CHAOS ENGINEERING

principlesofchaos.org

Chaos Engineering やっていく宣言

techlife.cookpad.com

まとめ

先日発生した AWS の Availability Zone 障害から今後の設計や運用に活かすための整理を行いました.クラウドといえどオンプレ同様にデータセンターで管理されているのだから障害は発生するし,障害が発生したからクラウドがダメでなく,クラウドの強みを活かすよう今回の経験を活かした改善活動に繋げたいですね.

Effective DevOpsオンライン輪読会 第15回開催レポートと振り返り

タダです.

challenge-every-month の Slack メンバーで 「Effective DevOps」のオンライン輪読会を継続してきましたが今回が本書のラストの輪読会でした.

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

開催概要

方針や輪読会の概要は @kojirock さんがまとめてくださっているのでご覧ください.

kojirooooocks.hatenablog.com

過去の開催レポート

これまでの開催レポートは以下の通りです.

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kojirooooocks.hatenablog.com

担当章について

今回の範囲は18章から19章までになります.最終章となるためまとめの話が多くなっていました.

資料

資料はこちらです.

所感

  • 個々人の意見を重視し、仕事よく知る人に改善方法を提案してもらうのがDevOpsで大きな成果の基礎になってる
    • 個人を一作業員として軽視せず,業務をよく知るメンバーとして意見を尊重し,フェアに評価していく
  • 組織の健全性は,人の受け入れ・昇進・退職・勤務形態の選択などに現れる
    • 上記のような文化的課題を文化的負債といい,負債なので対処していかなければ組織の悪影響は広がり続けることになる
  • 不健全なシステムや組織の観点が書かれており,自分の環境はどうなのかを見るための参考になった
  • DevOps とサイロ化の問題がよく文脈に出てきたが,いまいち理解できていなかったので整理してみた.
    • サイロ化とは,システムや業務プロセスが他のアプリケーションや他事業部や部門との連携を持たずに自己完結して孤立してしまう状態
      • サイロ化は他チームとのコミュニケーションが取りづらい状況を作る(改善や課題が共有されづらい)
    • DevOps は孤立したチームやコミュニケーションの取りづらい状況を改善し,組織のゴールは何で,どう実現するための文化を醸成していく活動になる
  • DevOps に万能なソリューションはなく,大事なのは組織における課題を明らかにして見分ける必要がある
    • 最終目標は顧客のために問題を解決できる組織を作り維持すること
    • DevOps には終わりはなく,継続的に繰り返し改善し続けていく反復的プロセスなので,旅と似ているなと思った

まとめ

第15回目の輪読会で扱った資料と所感を書きました. オンライン輪読会は継続するかをメンバー同士で話して,これまで通り輪読会を継続していくのが難しそうだったため一旦終了としました.振り返ると全員が直接面識ない中でも一冊の本を読破できたことはすごく嬉しいですし,その要因は何かなと振り返ったら3つのポイントがあったと思います.

  • 全員自宅から参加したが,Slack,Skype を使って知見や考えを共有してコラボレーションできたこと
  • 本書のような300P超えの本を各章で細かく区切り進めることで読書のペースを作れたこと
  • 継続することに重きを置き,訳あってスキップしたいときは気軽にスキップできるようにしたこと

約四ヶ月完走できてよかった... @kojirock さん,kdnaktさん,参加いただきありがとうございました!また都合が合えばオンライン輪読会開催予定です!

Amazon Forecast で家庭の電力消費量を予測する

タダです.

Amazon Forecast が一般利用可能になったので,サンプルデータを突っ込んで時系列データ予測を行ってみます.

aws.amazon.com

aws.amazon.com

Amazon Forecast の概要

Amazon Forecast は時系列予測のためのフルマネージドサービスです.過去の時系列データを提供することで時系列の未来を予測できます.例えば,小売・財務計画・サプライチェーン・ヘルスケアなど複数の分野で時系列予測は役立ちます.

AWSドキュメント docs.aws.amazon.com

そもそも時系列予測って何かというと,時間単位で整列したデータの集合です.

Q: 時系列データとは何ですか?

時系列とは、何らかの時間単位で整列されたデータポイントのセットです。時系列の例としては、ある商品の週間売上、日々の在庫状況、1 時間ごとのウェブサイトアクセス数などが挙げられます。

Amazon Forecast の仕組み

Amazon Forecast でデータの予測をするための仕組みとして以下の3つを理解しておきます.

  1. データセットおよびデータセットグループ : Amazon Forecast で予測する対象のデータ.データセットグループを作成し,関連するデータセットを追加する.Amazon Forecast アルゴリズムはデータセットを利用して,予測子というカスタム予測モデルをトレーニングする.
  2. 予測子 : データに基づいて学習されたモデル.予測子をトレーニングするには,事前に構築されたアルゴリズムか,AutoML オプション(Amazon Forecast に最適なアルゴリズムを選択するよう依頼)を選択する.
  3. 予測 : 時系列データの予測を生成する.予測結果をS3 バケットにエクスポートする

docs.aws.amazon.com

対応リージョン

対応リージョンは,以下の通りです.

料金

料金は以下のようになります.

価格タイプ 価格
予測の生成 1,000個の予測あたり $0.60
ストレージ容量 GB あたり $0.088
学習時間 1時間あたり $0.24

サンプルデータをインポートして Amazon Forecast の時系列予測を行う

サンプルデータ(時系列の過去の電力使用量)をインポートして, Amazon Forecast の時系列予測を行います.なお,詳細な手順はドキュメント内に記載があるので,サンプルデータを Amazon Forecast にインポートして時系列予測を行うまでの注意点や理解したことをまとめます.

AWS ドキュメント

サンプルデータをインポートして時系列予測を行う手順 docs.aws.amazon.com

サンプルデータの準備方法 docs.aws.amazon.com

サンプルデータをインポート時の注意点

サンプルデータをデータセットに登録する際にデータスキーマというデータタイプと順序を時系列データ(インポートデータ)に一致するように更新する必要があります.サンプルデータはデータセットグループのタイプとしてCustomにあたるので,timestamp,target_value,item_idのカラムに対応させる必要があります。

下記のようなデータスキーマに書き直す必要があります.

{
    "Attributes": [
        {
            "AttributeName": "timestamp",
            "AttributeType": "timestamp"
        },
        {
            "AttributeName": "target_value",
            "AttributeType": "float"
        },
        {
            "AttributeName": "item_id",
            "AttributeType": "string"
        }
    ]
}

予測子をトレーニングする時間および予測を生成する時間

データを Amazon Forecast にインポート後に予測子をトレーニングします.

予測子 (トレーニング済みモデル) を作成するには、アルゴリズムと、行う予測の数 (長さ × 頻度) を選択します。

f:id:sadayoshi_tada:20190908223416p:plain

レーニングの時間ですが30分以上はかかった印象なので,すぐにはトレーニング済みモデルが出力されないものと思っておくと良いです.また,予測の生成も時間を要します.下記のように数分以上とありますが,40分以上は待つ必要があります.

Amazon Forecast で、予測の作成が終了するまで待ちます。このプロセスには、数分以上かかることがあります。予測が作成されると、進行状況は [Active] に変わります。さらに、ダッシュボードの上部にあるバナーが変わり、次のメッセージが表示されます。

f:id:sadayoshi_tada:20190908225651p:plain

フルマネージドサービス型の時系列予測

フルマネージドサービス型の時系列予測を行う Amazon Forecast を使ってみて思ったのは,データが揃っていればフルマネージドのメリットは存分に享受できます.EC2 のプロビジョニングやトレーニング済みのデータモデルを作ったりをボタン数クリックで賄えて,予測モデルが生成されるのは時系列予測に詳しくなくても扱えます.

まとめ

Amazon Forecast のサービス概要や仕組み,サンプルデータを使った時系列予測を行った際の注意点や理解したことをまとめました.次は,以前ツイートしたデータを突っ込んでみようと思います!

特定のリージョンのみのリソース制御するための IAM ポリシー設定

タダです.

IAM 権限の制御としてリージョンレベルで制御したい要件が出てきたので調べてみたところ, aws:RequestedRegionで制限できるようなので検証した結果をブログにまとめます.なお,今回東京リージョンとソウルリージョンに EC2 を起動している状況で読み取り権限は全リージョン有効ではあるが, EC2 への変更権限や起動,停止といった権限は東京リージョンのみに限定する IAM ポリシーを設定して検証しました.

検証イメージ図 f:id:sadayoshi_tada:20190902160553p:plain

検証した IAM ポリシー

検証で使った IAM ポリシーは以下の通りです.このポリシーを IAM ユーザーに関連づけて東京とソウルの EC2 を起動,停止してみます.期待する結果は東京リージョンのサーバーは起動と停止はうまくいき,ソウルリージョンのサーバーは停止も起動もできない,です.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InstanceConsoleReadOnly",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "InstanceWriteRegionRestricted",
            "Effect": "Allow",
            "Action": [
                "ec2:ModifyInstancePlacement",
                "ec2:TerminateInstances",
                "ec2:ImportInstance",
                "ec2:StartInstances",
                "ec2:MonitorInstances",
                "ec2:RunScheduledInstances",
                "ec2:ResetInstanceAttribute",
                "ec2:RunInstances",
                "ec2:ModifyInstanceAttribute",
                "ec2:StopInstances",
                "ec2:AssociateIamInstanceProfile",
                "ec2:ModifyReservedInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1" <= 東京リージョンのみ指定
                    ]
                }
            }
        }
    ]
}

AWS ドキュメント

docs.aws.amazon.com

EC2 の起動と停止の検証

東京リージョンの場合

東京リージョンで IAMTESTインスタンスが起動しているので,停止の操作を行なってみると無事に停止まで操作可能なことが確認できました. f:id:sadayoshi_tada:20190901230244p:plain

f:id:sadayoshi_tada:20190901225142p:plain

f:id:sadayoshi_tada:20190901225155p:plain

次に,起動してみます.起動も問題なく完了しました.東京リージョンは期待通りの操作ができることを確認できました. f:id:sadayoshi_tada:20190901230300p:plain

f:id:sadayoshi_tada:20190901230317p:plain

ソウルリージョンの場合

ソウルリージョンでも IAMTESTインスタンスが起動しているので,停止の操作を行なってみると停止処理が失敗することを確認できました. f:id:sadayoshi_tada:20190901231945p:plain

f:id:sadayoshi_tada:20190901232001p:plain

f:id:sadayoshi_tada:20190901232017p:plain

なお,エラー文をデコードするのは下記の AWS CLI で確認可能です.

$aws sts decode-authorization-message --encoded-message <エラー文>

次に,事前に違う権限を持つユーザーで停止しておいたサーバーを起動してみます.起動も失敗したのでソウルリージョンは期待通りの操作ができることを確認できました. f:id:sadayoshi_tada:20190901232924p:plain

f:id:sadayoshi_tada:20190901232937p:plain

f:id:sadayoshi_tada:20190901232947p:plain

まとめ

リソース制御をリージョンレベルで設定する IAM ポリシーの紹介とIAMポリシー制御の検証を EC2 の操作で確かめてみた結果をまとめました.AWS のドキュメントページにも注意事項として記載がありますが,リージョンレベルで制御することで動作しないサービスの操作もあるため設定を行う際は十分に注意し,テストした後設定を行うようにしましょう.

aws:RequestedRegion 条件キーを使用すると、呼び出されるサービスのエンドポイントを制御できますが、オペレーションの影響を制御することはできません。一部のサービスではリージョン間の影響があります。たとえば、Amazon S3 にはリージョン間レプリケーションを制御する API オペレーションがあります。1 つのリージョン (s3:PutBucketReplication の条件キーの影響を受ける) で aws:RequestedRegion を呼び出すことはできますが、他のリージョンはレプリケーションの構成設定に基づいて影響を受けます。

AWS CLI で振り返る AWS 障害時の各種ステータス確認方法

タダです.

先日, AWS で大規模なネットワーク障害が発生して様々な部分で影響が出ていたと各種メディアで報じられていました.

aws.amazon.com

8/28追記

2019年8月28日(日本時間)更新 で記事が更新されました.更新された箇所を引用します.影響箇所として新たに EC2 の障害が発生した Availability Zone の RDS, Redshift, ElastiCache, WorkSpaces, 予期せぬ影響として ALB の記載が追加されました.個別の問題は AWS より個々の利用者に共有するとのことです.

今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。AWS では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。

aws.amazon.com

以下,本事象のサマリーです.

原因

東京リージョンの単一の Availability Zone(データセンター群) の一部(apne1-az4)でオーバーヒートが発生したが,空調設備の管理システムの障害により冷却装置が作動しなかったことが原因のようです.

影響

影響として次の部分に出ていました.

  • 該当 Availability Zone(apne1-az4)の EC2 インスタンス及び EBS ボリュームのパフォーマンスの劣化, RDS の使用不可やマルチ Availability Zone でのフェイルオーバーに伴う一時的な通信断が発生
    • EC2 RunInstances APIのエラー率の上昇が発生し,その他の EC2 API や Auto Scaling グループからのインスタンスの新規起動も阻害
  • EC2 の障害が発生した Availability Zone の RDS, Redshift, ElastiCache, WorkSpaces, 予期せぬ影響だがALB への影響

参考

piyolog.hatenadiary.jp

僕の会社でも本障害を受けて報告資料を公表しています.

今回,たまたま遭遇したのですがマネジメントコンソールの画面の表示が崩れたり表示ができない時間帯があり,状況確認が難かったです.その時に AWS CLI を使ってステータスの状況を確認していました.当時を振り返って,他にも利用できるコマンドもあると思い調べたのでブログにまとめていきます.

Availability Zone のステータス確認

今回の障害の原因となった Availabity Zone のステータスを確認するコマンドは describe-availabity-zonesです.障害が発生した「apne1-az4」はコマンド実行結果のZoneIdからステータスを確認可能です.

docs.aws.amazon.com

コマンド実行例

$ aws ec2 describe-availability-zones --output table                                     
-------------------------------------------------------------------
|                    DescribeAvailabilityZones                    |
+-----------------------------------------------------------------+
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az4 |  ap-northeast-1a  ||
|+-----------------+------------+------------+-------------------+|
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az1 |  ap-northeast-1c  ||
|+-----------------+------------+------------+-------------------+|
||                       AvailabilityZones                       ||
|+-----------------+------------+------------+-------------------+|
||   RegionName    |   State    |  ZoneId    |     ZoneName      ||
|+-----------------+------------+------------+-------------------+|
||  ap-northeast-1 |  available |  apne1-az2 |  ap-northeast-1d  ||
|+-----------------+------------+------------+-------------------+|

EC2 インスタンスのステータス確認

EC2 インスタンスのステータス確認を行うコマンドはdescribe-instance-statusになります.--filters オプションで Availability Zone や インスタンスのステータスをを指定して状況を確認することが可能です.

docs.aws.amazon.com

コマンド例

$ aws ec2 describe-instance-status --filters Name=availability-zone,Values=ap-northeast-1a Name=instance-status.status,Values=impaired --output table
-------------------------------------------------------------------------
|                        DescribeInstanceStatus                         |
+-----------------------------------------------------------------------+
||                          InstanceStatuses                           ||
|+-------------------------------+-------------------------------------+|
||  AvailabilityZone             |  ap-northeast-1a                    ||
||  InstanceId                   |  i-xxxx                ||
|+-------------------------------+-------------------------------------+|
|||                              Events                               |||
||+------------------+------------------------------------------------+||
|||  Code            |  instance-stop                                 |||
|||  Description     |  The instance is running on degraded hardware  |||
|||  InstanceEventId |  instance-event-xxxxxxx              |||
|||  NotBefore       |  2019-xx-xxTxx:xx:xx.xxxZ                   |||
||+------------------+------------------------------------------------+||
|||                           InstanceState                           |||
||+---------------------------+---------------------------------------+||
|||  Code                     |  xx                                  |||
|||  Name                     |  running                              |||
||+---------------------------+---------------------------------------+||
|||                          InstanceStatus                           |||
||+-----------------------------+-------------------------------------+||
|||  Status                     |  impaired                           |||
||+-----------------------------+-------------------------------------+||
||||                             Details                             ||||
|||+-----------------------+-----------------------------------------+|||
||||  ImpairedSince        |  2019-xx-xxTxx:xx:xx.xxxZ                 ||||
||||  Name                 |  reachability                           ||||
||||  Status               |  failed                                 ||||
|||+-----------------------+-----------------------------------------+|||
|||                           SystemStatus                            |||
||+-----------------------------+-------------------------------------+||
|||  Status                     |  impaired                           |||
||+-----------------------------+-------------------------------------+||
||||                             Details                             ||||
|||+-----------------------+-----------------------------------------+|||
||||  ImpairedSince        |  2019-xx-xxTxx:xx:xx.xxxZ               ||||
||||  Name                 |  reachability                           ||||
||||  Status               |  failed                                 ||||
|||+-----------------------+-----------------------------------------+|||

EBS ボリュームのステータス確認

EBS ボリュームでも障害が発生していましたので, EBS ボリュームのステータス確認を行うコマンドとしてdescribe-volumesがあります.--filters オプションで Availability Zone を絞れるので問題発生した Availability Zone を指定して状況を確認することが可能です.

docs.aws.amazon.com

コマンド例

$ aws ec2 describe-volumes --filters Name=availability-zone,Values=ap-northeast-1a --output table
---------------------------------------------------------
---------------------------------------------------------
|                    DescribeVolumes                    |
+-------------------------------------------------------+
||                       Volumes                       ||
|+---------------------+-------------------------------+|
||  AvailabilityZone   |  ap-northeast-1a              ||
||  CreateTime         |  2019-xx-xxTxx:xx:xx.xxxZ     ||
||  Encrypted          |  False                        ||
||  Iops               |  100                          ||
||  Size               |  8                            ||
||  SnapshotId         |  snap-xxxx       ||
||  State              |  in-use                       ||
||  VolumeId           |  vol-xxxx        ||
||  VolumeType         |  gp2                          ||
|+---------------------+-------------------------------+|
|||                    Attachments                    |||
||+----------------------+----------------------------+||
|||  AttachTime          |  2019-xx-xxTxx:xx:xx.xxxZ  |||
|||  DeleteOnTermination |  True                      |||
|||  Device              |  /dev/xvda                 |||
|||  InstanceId          |  i-xxxx       |||
|||  State               |  attached                  |||
|||  VolumeId            |  vol-xxxx     |||
||+----------------------+----------------------------+||

RDS インスタンスのステータス確認

RDS インスタンスの使用不可な状態やフェイルオーバーによる一時的な通信断があったため,RDS インスタンスへの接続確認も必要ですが,AWS CLI でステータス確認を行うコマンドとしてdescribe-db-instancesがあります.--queryオプションを使って Availability Zone やステータスを絞って確認可能です.

docs.aws.amazon.com

コマンド例

$ aws rds describe-db-instances --query 'DBInstances[?AvailabilityZone==`ap-northeast-1a`].{Name:DBInstanceIdentifier,Status:DBInstanceStatus}' --output table
---------------------------------------------------------
|                  DescribeDBInstances                  |
+------------------------------------------+------------+
|                   Name                   |  Status    |
+------------------------------------------+------------+
|  xxxx                         |  available |
|  xxxx                         |  available |
|  xxxx                      |  available |
|  xxxx                     |  available |
|  xxxx                     |  available |

まとめ

先日発生した AWS のネットワーク障害で障害点であった Availability Zone, EC2, EBS, RDS のステータスを確認するためのコマンドとコマンド例をまとめました.正解はないと思いますし,もっといい手法があれば教えてください! 今回の障害を機にどこが弱点か,改善するところがないかを再考し,より良いシステムの形に持っていけるようにしていきたいですね.