Zenn
📳

AWS上のシステム障害、だいたいの原因はオレンジアイコン

2024/01/04に公開
AWS
インフラ
tech

突然のあるあるから失礼します。
2024年になったタイミングということで、zenn初投稿です。

インフラエンジニアとして、AWSを中心としたクラウドサービス上のサービス運用を5年間やってきた結果見えてきたことがあります。
それは AWS上のシステム障害、だいたいの原因はオレンジアイコン ということでした。

この記事で伝えたいこと

  1. システム固有の設定・プログラムが稼働するところが障害の原因になりやすい。
  2. それはAWSでいうところのオレンジアイコンであることが多い。
  3. 障害対応ははぐれメタル級の経験値獲得ができる。
  4. 探偵になった気持ちで障害対応を進めてみよう。

障害対応について

障害対応。
未然に防ぐのため対応をしていたとしても、ゼロにすることはできないものです。

  • 障害が頻発するが、対応できる運用者が多いシステム。
  • 障害発生頻度は少ないが、いざというときに対応できる運用者が少ないシステム。

どちらもサービスが成長するに連れて問題が肥大化してしまっていないでしょうか。

前者はドキュメンテーションや対応フローの最適化や自動化。恒久対応の進行で改善活動を進められます。

今日はどちらかというと後者の 障害頻発頻度は少ないが、いざというときに対応できる運用者が少ないシステム で障害が起きてしまったときに、どのようにその原因特定・障害解消にアプローチしていけばいいかを整理していきます。

システム固有の設定・プログラムが稼働するところが障害の原因になりやすい

結局のところ、システム固有の設定・プログラムが稼働するところが障害の原因になりやすいです。

何故か。
そのオリジナリティ故に、考慮点が増えるからです。

システムがシンプルであればあるほど、障害ポイントはもちろん少なくなります。
しかし、ビジネス要件や外部サービスとの接続等、様々な機能や接点が増え、現実問題なかなかシンプルに収めることは困難です｡
また、シンプルであるが故にSPOF(単一障害点)が生まれてしまい、結果として非機能要件を満たせない。といったトレードオフの関係も発生します。
このあたりは設計段階で考慮されて潰されているので、究極のシンプルさからは遠ざかっているでしょう。

こんなかんじがらめな状況に対してどのように対応するか。
そう、AWSで言うと オレンジアイコンのサービスでどうにかする ことが多いのです。

例を挙げると、

  • Amazon EC2
  • Amazon ECS
  • Amazon EKS
  • AWS Lambda
  • AWS Batch

そう、コンピューティングサービスが障害の原因になることが得てして多くなります。

シンプルな設定しかできないものはシンプルは利用しか想定されていないので、カスタマイズ要素が限定されて障害発生時の切り分けも簡単になります。
しかしこのようなコンピューティングサービスについてはチューニング・カスタマイズ要素の幅が広いです。
仮想サーバではありますが、その仮想サーバ上で稼働するアプリケーションやミドルウェアに関しての制約は、そのコンピューティングサービス上で実現できる範囲で様々な手段を取ることができます。

逆説的にはなりますが、その コンピューティングサービス上で実現できる範囲で様々な手段を取ること が障害の原因となることが多いです。

その障害の種類は様々です。
例えば、

  1. 現状のサーバスペック・台数を超える高負荷に陥る。
  2. アプリケーションのデプロイにより、バグや性能劣化が発生する。
  3. ミドルウェアのチューニングにより別箇所で問題が発生する。
  4. アプリケーション・ミドルウェアのバージョンアップによって問題が発生する。
  5. 接続先の外部システムでのトラブルに巻き込まれる。

ざっと考えるだけでこれらのものが想定されます。

そう、 AWSの責任共有モデル で お客様 側の責任となっているところです。

まずはここを確認しましょう。
話はそれからです。

オレンジアイコンに問題がなかった場合どうするか

以下の2段階で調査を進めてみましょう。

ピンクアイコンを確認する

障害ポイント探偵としてシステム運用者が出動し、オレンジアイコンの点検を終えても障害ポイントが判明しない。
そんなこともあるでしょう。

次にどこを確認するか。
次はピンクアイコンを確認しましょう。
...2023年にサービスアイコンカラーが変わってピンクになったのでまだ浸透していませんね。

  • Amazon RDS
  • Amazon Aurora
  • Amazon DynamoDB
  • Amazon ElastiCache

代表例としてはこのあたりです。

何故ピンクアイコンを確認するのか。
それはオレンジアイコンで処理したデータを格納する場所だからです。

結局はここでもまだオレンジアイコンが被疑箇所である可能性が残っています。

オレンジアイコン(コンピューティングサービス)が負荷に耐えられていたとしても、ピンクアイコン(データストア側)がその負荷に耐えられていないということもあります。

CPU負荷。
コネクション数上昇。
データ量増加による検索性低下。
ピンクアイコンのパラメータチューニング。

オレンジアイコンが原因でピンクアイコンに皺を寄せてしまっている。
あるあるですね。

結局はこれも責任共有モデルでお客様側となっている お客様のデータ に合致する箇所になります。
データの持ち方。取り方。
あくまでユーザ側で選択可能な領域になります。

なので、オレンジアイコンからのデータの書き込み・読み取りにおける負荷がピンクアイコンにかかりすぎていないかを確認しましょう。

その他の場合はAWSサポートへの問い合わせを視野に入れる

オレンジアイコン・ピンクアイコンで原因らしきものが分かったら、あとは自身で特定に到れる可能性がグッと上がるでしょう。

しかし原因が分からず調査に行き詰まった場合は、AWS基盤側の問題である可能性も考慮した方がいいでしょう。

Health Dashboardへ広域障害情報が未反映の状態であったり、広域障害ではない限定的なプラットフォーム障害が発生している可能性もあります。
我々が運用しているサービスがそうであるように、AWSのSLAも決して100%ではありません。

ログやメトリクス、確認したことや質問したいことを整理してAWSサポートへの問い合わせを並行進行しましょう。
まずは責任共有モデルで お客様 となっているポイントに対して、オレンジアイコンを中心に確認を進めていくことが解決への近道になるでしょう。

障害調査は栄養満点

これらの調査を進めていくと、結果としてたくさんの栄養を摂取することができます。

目の前で発生している問題を解決に導くためには多くのカロリー消費を伴いますが、はぐれメタル討伐級の経験値獲得が見込めます。
座学だけの成長には限界があるので、経験を積むことで栄養の吸収効率を最大化していきましょう。

  • 障害の切り分け方を知ること。
  • サービス固有の設計ポイントをおさえること。
  • ワークアラウンドを整理すること。
  • 障害原因に対する根本対処方法の検討を進めること。

これらを実地でやっていけば、インフラエンジニア界の名探偵に近付けると私は信じています。

そのための手段として、オレンジアイコン上の実地確認からやっていきましょう。
様々なサービスやそれぞれのアイコンに惑わされることもあるかと思いますが、一個ずつ確認していけば大丈夫です。なんとかなります。

今年も自身が担当するサービスを愛でていきましょう。
ご安全に！

Discussion