1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWSの設定をミスって本番を落とした話

1
Posted at

要約

PMの経験になればと、副業で参画していたプロジェクトで
本番がダウンしてお客様へご迷惑をおかけした話。

定期的に本番へpingを送信する仕組みが、Amason SNS とLambda関数の設定不足により、無限ループを発生させてしまい、本番環境が自分自身にDos攻撃するといった状態になりダウン。


Amazon SNSとは

マネージド型のメッセージ配信サービス
Publisher-Subscriber関係の非同期なメッセージ配信モデルの実現が可能

  1. SNSにはpublishとsubscriberの役割で、異なるAWSサービスを疎に結合して動作することで依存関係なく連携することができる

Topic

間に挟まることで各々がTopicのみを意識するだけで済む
pub → Topic ← sub

  • Publisher --- メッセージの発行元
  • Topic --- 通信チャネルとして機能する論理的なアクセスポイント(発行されたメッセージは即座に Subscirberに配信される)
  • Subscriber --- Topicを Subscribe するエンドポイント

結果としてpublisher と subscriber 同士の結合を弱めた状態でシステム構成が可能


Topicには2種類ある

  • スタンダード
  • FIFO
スタンダード FIFO
配信順序 保証されない 同一のメッセージグループIDで保証される
配信方式 重複の有無に関わらず配信 重複を排除し1回のみ配信
スループット 無制限のスループットが可能 秒間最大300件
順序性と重複排除は一旦スルー

リトライポリシー

最初の配信が何らかの理由で行われていない場合に行われる処理
①即時 → ②短間隔で最小の再配信 → ③バックオフで再配信 → ④長間隔で最大の再配信

バックオフ --- 線形もしくは指数関数的に間隔を増やす

詳細な回数については割愛


今回起こったこと

Lambda関数でwebサイトの稼働状況をチェックしていたhttpリクエストの
とある一文がLambdaとSNSを無限ループを発生させてしまいました。

下記は例
response = http.request('GET', url, headers=headers, timeout=10.0)

  1. 発生した例外を捕捉する処理で例外を捕捉

  2. 捕捉先でSNSへメッセージを送る処理になっていたが設定不足により送信が失敗

  3. Lambdaが Subscriber として設定されていたため、SNSのリトライポリシーにより再配信、Lambdaが再起動

  4. 上記1~3を繰り返し、Lambdaが成功するまでメッセージを再配信し続けるSNSの永久機関が完成(デンジくんもびっくり。※チェンソーマンの主人公です)

これによって Lambda がping送信を連続実行し続け、本番環境に毎秒数百件のリクエストが送信された。

原因

一重にこれ!という要因はなく、ヒューマンエラーを含むいくつかの原因が関与していました。

  • 上記の1~3
  • オフショア内でのマージリクエストの形骸化 (GitLab)
    (メンバー間でのレビューではなく、リーダーが引き受ける風土だったみたいです。業務を逼迫させていたかもと、私も反省しています)
  • 単体テストの未実施
    → CIを組んでいたのにも関わらずそれが抜けたことを指摘した所、適切なテストコードがなかったとの事。まぁこういう事もあるようです。泣いた。
  • 動作確認の未実施
    上司がこの件について怒ってました。目で見るタイプの動作確認はやはり大事ですね。いのちだいじに。

取った対策

  • バグのあった一文に再帰呼び出しを制御するロジックを追加
  • SNSの再試行回数の上限設定を変更
  • 他監視系の設定

まとめ

今回のインシデントは起こるべくして起こったと考えています。そもそもが準委任ということもあり、品質についてそこまでの考慮されていなかった可能性もあります。
(当時契約した担当はいません。上司も自分も途中から参画しました)

オフショアのため、文化の違いなどもあるとは思いますが、やはり自分自身、圧倒的に経験が足りていないなと感じる一件でした。
インシデントが起こる前に、マージリクエストのURLと共にbacklogで当該ファイルが添付されていたからです。
しっかり確認しておけばと良かったと後悔しています。
(会社的にシステム開発を請け負う会社ではないので、このプロジェクトはある程度あちらにお任せする契約を結んでいたようです。なのでGitLabもあちら管理)

インフラはからっきしだったので、良い勉強になったこと、そしてご迷惑をおかけしたお客様に申し訳ないという気持ちと、AWS面白いな、という複雑な感情でした。

まずはCLFからでしょうか。でも認定試験料、高いんですよねぇ……

まだまだ初心者のため、認識違いなどがあればコメント等でご指摘いただけると嬉しいです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?