re:Inventで学んだ Webシステム運用のBad Dayへの備え方

自己紹介 宮崎 怜美（みやざき さとみ）  入社時期：2022年5月（中途）  担当サービス：スマート証憑管理  AWS経験：1年弱  休日の過ごし方：楽器演奏（クラリネット）、散歩

AWS re:Invent初参加の感想  とにかく楽しくて毎日が充実 ➢ 国際カンファレンスならではのスケールの大きさに感動 ➢ 参加したいセッションが多くて迷う  英語でのやり取りはやっぱり大変 ➢ 雑談が一番難しい ➢ 準備しておいて良かったフレーズ ◼ セッション会場までの行き方を尋ねる ◼ ワークショップ中にわからない箇所を質問

参加したセッションの紹介①  セッション形式：Chalk Talk  内容： ➢ レジリエンスの担保 ➢ 発生しうる障害にどう対処するか ◼ ビジネス損失の定量化 ◼ 障害発生のシナリオと対策検討の流れ ◼ 障害への備えと対処  参加した理由： ➢ セッションタイトルに惹かれて ➢ 自分が担当してきた業務と関連しそう

参加したセッションの紹介②  参加者からも多くの意見や質問が出る ➢ 発言するとステッカーがもらえる  Speaker⇔参加者のやり取りでケーススタディを進めていく EC2をECSに置き換えると レジリエンスは変化する？ YES! NO! Depends!

ビジネス損失の定量化  障害発生時のビジネス損失を正確にとらえる ➢ 収益損失（違約金等も含む） ➢ ブランドイメージの低下 ➢ 障害に対処するエンジニアの生産性の低下  対応が必要かの判断 ➢ 見積もった損失が対応コスト下回る場合は許容もあり

障害発生のシナリオと対策検討の流れ ビジネス損失を想定する 例）インターネット通販で商品を購入できない 損失を発生させうる障害の種類を挙げる 例）商品購入時のログインに失敗する 障害発生のシナリオを洗い出す 例）認証システムがダウン 各シナリオへの備え（または対処）を検討する 例）マルチAZ、エラー検知の仕組みを導入 etc.

障害への備えと対処  アクションの種類 ➢ 探知（Detective） ➢ 予防（Preventive） ➢ 復旧（Recovery） ➢ テスト（Testing）  アーキテクチャ図だけでは備えが十分か判断できない ➢ 安全にデプロイされる仕組みがあるか ➢ 障害復旧のプロセスは整備されているか etc. 現状で不足しているものがないか？

実際のセッションで議論した内容

担当サービスの状況を確認してみる  シナリオ①関連システムの停止により処理が行えない エラー発生時のCloudWatch Alarm→Slack通知 SQSを使用し、リトライ／再実行可能に 上記の処理が正しく動作するかの検証  シナリオ②災害発生によるシステムダウン マルチAZ対応 データバックアップおよび別リージョンへのコピー バックアップデータから復元できることの検証 探知 復旧 テスト 予防 復旧 テスト この他にも、社内ガイドラインに従ってチームで対応を継続中

まとめ  議論を楽しめるのも現地参加のメリット ➢ エンジニア同士の白熱したやり取りから刺激をもらった ➢ 自分も発言できるとより楽しい（はず）  これまでの運用業務をふりかえるきっかけになった ➢ 自分の担当タスクの意義を再確認 ➢ 社内ガイドラインや相談に乗ってくれる有識者に改めて感謝 Thank you!