障害に備えたアーキテクチャを考える「あのとき何が起こった！？」 – Developers.IO TOKYO 2019 #cmdevio

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

2019年11月01日に開催された「Developers.IO 2019 in TOKYO」で
障害に備えたアーキテクチャを考える 「あのとき何が起こった！？」
というタイトルで発表させていただきました。
本記事ではその登壇資料を公開します。

セッション概要

• 2019年8月23日 東京リージョン障害
• トラブルで右往左往しないためには
• AWS Well-Architected Framework 信頼性の柱 紹介
• 障害に備えるアーキテクチャとは

2019年8月23日 東京リージョン障害

• 8月23日 スーパーサマリー
• 何が起きていたか (経験談)

トラブルで右往左往しないためには

右往左往しないために準備しておくことが大切です。

1. サービス断を検知→通知する仕組み
2. 何が起きているか判るようにメトリクスを取得
3. ログを S3/CWLogs へ出力
4. ログの検索手順を確立
5. 想定障害と復旧手順があるとベスト

AWS Well-Architected Framework 信頼性の柱 紹介

弊社坂巻のエントリを参照ください。

Developers.IO 2019 Tokyoで「AWS Well-Architected Framework 信頼性の柱の紹介」を発表してきました #cmdevio

障害に備えるアーキテクチャとは

稼働率パターンごとにサンプルとなるアーキテクチャと月額利用料金を記載しました。
月額利用料金はあくまでサンプルですが、稼働率を上げると何倍になるのか
肌感覚が分かってもらえると嬉しく思います。

稼働率を高めるためには、

1. AZ またぎ
2. サーバー (EC2) でなんとかしようとしない、AutoScaling、RDS など AWS サービス使う
3. サービス継続に必要なデータを腹持ちしない、RDS、DynamoDB、S3、ElastiCache など活用
4. 復旧アクションは自動化、半自動化する

稼働率

コンポーネントが直列になっているシステムの稼働率を計算するために
「稼働率 = A1 x A2 x A3」のような式を用いることがあります。
今回は単純なインフラの稼働率だけではなく、
自動化、フロー見直しを導入してシステムとしての稼働率を向上させるよう取り組みます。
その前提でご覧ください。

セッション資料

補足

Well-Architected Framework 信頼性の柱 ホワイトペーパー が日本語化されました。

以上、吉井 亮 がお届けしました。