Azure 障害との上手な付き合い方

Azure 障害との上手な付き合い方

1. 1. Azure 障害との上手な付き合い方 竹井 悠人, 萬藤 和久 bitFlyer, Inc. 2017/04/22 Global Azure Bootcamp 2017 @ Tokyo
2. 2. 免責 このトークは、情報提供のみを目的として行われており、正確性・最新性についての保 障は一切ありません。内容は、会社の見解ではありません。この情報を元にして生じた 不利益について、当社およびスピーカは一切の責任を負いません。 bitFlyer 上での取引についての詳細は、当社カスタマ サポートへお問い合わせくださ い。
3. 3. C# (浮気もありましたが) 大好き 8年 新機能開発、データベース監視マン SNS は息してません BTC 送金お待ちしております 竹井 悠人 萬藤 和久 C# 大好き一筋 15年 セキュリティ研究開発 Facebook は飯テロ アカウント
4. 4. 今日のあらすじ ● これまでお付き合いした障害 ● 部位別！ 障害の調理の仕方 ● まとめ
5. 5. これまでお付き合いしてきた障害
6. 6. これまでお付き合いしてきた障害 ● 2016/9/15, 20:48 JST 全世界で DNS 障害 ● 2017/3/8, 21:42 JST 東日本のストレージ障害 (Redis) ● 2017/3/28, 3:04 JST 西日本のストレージ障害 (Redis) ● 2017/3/31, 22:28 JST 東日本のストレージ障害 (VM, DB…) 3 月みると、 めっちゃ障害多いですが 大丈夫っすかね...?
7. 7. 2016/9/15 全世界で DNS 障害 症状 ● システム上で発注がいっさい出せなくなった ● Worker Role から Database へアクセスできなくなっていた 対応 ● サーバ再起動や再デプロイを試みたが、DNS が引けなくて傷が広がる 学んだこと ● 緊急時に IP 直指しする方法あると良いかも ● 本当に重要なところは DNS の冗長化が必要かもしれない 機器 のバグ
8. 8. 2017/3/8 東日本ストレージ障害 症状 ● chainFlyer が死ぬ ● Redis Cache にアクセスできず。死んでることが判明 ● ユーザが Lightning から強制的にログアウトされる ● SignalR のバックプレーン接続不可 その他のサービスに重大な影響はなく、なんとか動いていた バックエンド のバグ
9. 9. 2017/3/8 東日本ストレージ障害 対応 1. 死活監視で障害検知、Redis Cache 接続不可を確認 2. Azure Status で東日本ストレージ障害を確認 3. 即座に Redis Cache を西日本へ移行決断 4. 接続文字列を変更してデプロイ 5. ステージング環境で動作確認を行い、サービス再開 他のサービスが 無事だったこと で即決断
10. 10. 2017/3/8 東日本ストレージ障害 学んだこと ● Multi-AZ 構成を事前検討 障害が起きても耐えられる冗長設計を常日頃から考えるべし ● 影響範囲・依存関係の明確化 状態を持つものの移行・再開は大変。事前検証すべし(Queue, DB) 緊急時手順と予行演習をしていないと見落としがある ● ステータス ページ お客さまへの情報開示を継続的に行うべし
11. 11. 2017/3/28 西日本ストレージ障害 症状 ● Redis Cache が死ぬ。。。 対応 ● 3/8 で東 → 西にしていたものを西 → 東に戻す 学んだこと ● 東日本 ⇔ 西日本の引越侍が爆誕 ● ペアリージョン (後述) は信じていいのかも！？ Azure にてリージョンをまとめたグループ。 東日本、西日本で見た場合、どちらかは正常に動作していた メンテの 失敗
12. 12. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 22:44 未処理の注文がキューに一定数たまり 監視システムからアラート DB を中心に、システムの状態確認開始 (キューに処理たまる場合、 DB 遅延が多い) SQL Database (以降 DB) が不安定に 22:54 Cloud Service の VM に接続出来なくなる Azure Status ページ確認「正常稼働」 対応 1. Cloud Service の VM を西日本へデプロイ 23:10 DB 無応答 Azure Portal 無応答 東: 東日本リージョン、西 : 西日本リージョン、MS: Microsoft 扇風機の 電源の故障
13. 13. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 23:11 Lightning 含む各サービスが レスポンスを返せなくなる 23:13 東、全滅っぽい空気が漂う Azure Status ページ確認「正常稼働」 長い夜が始まるとはこの時誰も知る由はなかった... 一方、西は問題なく動作 西に移行すれば動きそう。 DB 以外を西へ移行開始 プライマリ DB の移行も必要。。。 → ご安心を！ 西に Geo レプリカあります 23:19 対応 2. Geo レプリカを使う セカンダリのスケールアップを開始
14. 14. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 23:22 対応 3. 緊急度 A でサポート依頼をあげる 23:26 スケールアップ失敗 (GatewayTimeout) 「ゲートウェイが指定された期間内に 　'Microsoft.Sql’ からの応答を受信しま 　せんでした」 再度、セカンダリのスケールアップ要求を投げる 23:28 Azure Portal 「東日本サービスが停止しています」 と表示がでるようになった Azure Status ページ確認「正常稼働」 ... ? スケールアップまたも失敗 計 5 回ほど試したが出来なかった 23:32 Azure Status で Storage, VM 障害報告があがる
15. 15. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 23:52 MS サポートから電話あり セカンダリ スケールアップ不能な件、 Failover の挙動について確認するも明確な回答なし 00:07 対応 4. セカンダリから DB コピー開始 西リージョン内に 1 つ、香港に 1 つコピー 00:22 DB コピー中 - 状況整理 - 東 DB, Redis Cache, 一部 VM は接続不可 Blob, Queue は接続可能 00:36 DB コピー中 ... DB 切り替え後 (コピー完了後) のデータの整合性、 動作確認方法を改めて整理
16. 16. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 01:21 DB コピー中 ........ 各担当者がそれぞれの対応を継続 データの整合性含めサービス再開時の対応も検討 Get-AzureSqlDatabaseCopy で Copy 進捗率とるも 有意義な情報を取得できず (後述) ~ DB コピー中 ........................ 02:22 Portal 上でプライマリ DB が閲覧可能に 一部 VM への接続が復活 02:40 chainFlyer 復旧
17. 17. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 02:55 プライマリ DB Management Studio から接続可能に プライマリ DB の状態を確認、問題なさそうと判断 東のサービスを再開 プライマリとセカンダリとで不整合 セカンダリ、プライマリ間の同期完了 4:45 をサービス再開時刻と決定 03:28 注文処理が行える事を確認 サービス再開に向けて、 各サービスの動作、データの状態を確認 03:57 MS サポートから連絡あり 「VM 一部対応中だが、現在動いているもの 　は基本的に正常と判断してよい」 (...いまさら感)
18. 18. 2017/3/31 東日本ストレージ障害 時刻 症状 対応 04:10 DB の負荷が上昇 通常稼動時のメンテ処理 : Index の reorganize が走ってしまう 04:45 サービス再開 エラー・負荷など、システム健全性の確認 05:00 サービス再開後、大きな問題は発生せず 障害対応完了！ 完全復旧！！
19. 19. 2017/3/31 東日本ストレージ障害 学んだこと ● 技術面 ○ ジオレプリを使っても死ぬときは死ぬ (後述) ● 運用面 ○ 属人化を減らす システム構成を複数名が把握しておくことで作業分担が可能 ○ 適切な権限移譲 環境移行を行う決断と実際に行う事は状況によっては難しい ○ 緊急時の役割分担 エンジニア以外でもやれることはたくさんある
20. 20. 障害は 私たちの準備なんか 待ってくれない
21. 21. 部位別！ 障害の調理の仕方
22. 22. 部位別！ 障害の調理の仕方 システム構成ごとに障害への対応方法が異なる Redis Cache ● Main system ● Lightning ● chainFlyer ● マーケット処理 ● 取引約定 ● バッチ処理 Web Apps Worker Roles SQL Server Web Roles ● fundFlyer ● BTC News ● セッション管理 Storage Queue バックアップへ
23. 23. Storage (Blob, Queue, etc.) レプリケーションの種類 ● Locally Redundant Storage (LRS) ● Zone Redundant Storage (ZRS) ● Geo-Redundant Storage (GRS) ● Read-Access Geo-Redundant Storage (RA-GRS)
24. 24. Storage (Blob, Queue, etc.) 対応できること ● ジオ冗長をうまく使いましょう ○ ( でも GRS は実は発動したことはないらしい ) ● 同じアセットを別のストレージにデプロイしておく ○ 面倒だからデプロイ自動化しましょうね ○ 接続文字列を動的に変えられる内部の仕組みを ● CDN を使ってエッジ サーバに退避させるのも手
25. 25. Cloud Service バックエンドは普通の VM。ストレージが倒れると死ぬかも 対応できること ● 別リージョンにデプロイし直すしかない デプロイに 5 分とか、混雑時はもっとかかることを織り込むこと ● DNS の設定変更を忘れなく 必要なところは TTL を短くしておくなどの対応もあり
26. 26. Azure DNS / その他 DNS がらみ 接続を切らない限りは死なないかも（だが確証はない） 対応できること ● DNS 自体の冗長系統を用意しておくしかない A○S とか G○○gle とか S○ftLayer とか ● Traffic Manager を組み合わせるもよし
27. 27. Redis Cache 3/8 の障害時にやった対応はこれ 対応できること ● 重要なデータは入れない 最悪、飛んでもよい覚悟はしておくべし ● キャッシュとしての使い方 つながらない場合は後ろの DB にとりに行くなどの構成を用意 ● あったまるまで 30 分ほど 事前に作っておくなども考慮したほうがよい
28. 28. SQL Database 対応できること ● 接続文字列を変えられるようにする ● バックアップをとる ● geo レプリケーションを組む
29. 29. Geo レプリケーションを使うときの注意 Failover してからスケールアップすること！ geo レプリケーションのいずれかに影響があると 他方も影響を受ける可能性が零ではない 今回は... (3/31) セカンダリがプライマリの同期待ちを行っており スケールアップ要求を受け付けられなかった
30. 30. SQL Database のコピーについて補足 ● 1 つの DB から同時コピーしてはいけない！ ● コピーより geo リストア推奨 何らかの理由で Failover 出来ない場合も geo リストア ● 処理時間は容量とサービス レベルに影響うける データ量が多ければ時間がかかる あわせて、構築するサービスレベルのサイズに応じてコピー速度が変わる 今回は... (3/31) 同一サーバー内6時間38分、香港サーバー8時間1分かかったが、 コピー元 DB で reconfiguration が発生し、内部的にやり直ししていた
31. 31. マルチ リージョンについて どこにバックアップを立てますか？ 近いところ？ ペアリージョンを使いましょう ● どちらか 1 つのリージョンは 稼動するよう調整されている ● 日本は東と西がペアリージョン (DB の構成変更が走ったりするので油断禁物 )
32. 32. その他のはなし
33. 33. SLA ● 保証された稼働率に注意。99.9 % なのか？ 99.99 % なのか？ ○ Storage : 99.9 % (RA-GRS の場合は読み取り 99.99%) ○ VM / Cloud Service : 99.95 % ○ SQL Database / DNS : 99.99 % ● 正しい冗長構成でなければ、可用性が担保してもらえない ○ VM は可用性セット組んでますか 参考: エンタープライズ契約（EA）の SLA 返金手続きについて https://blogs.msdn.microsoft.com/dsazurejp/2016/12/12/easla/
34. 34. インシデントの上げ方 Azure ポータル ヘルプとサポート から上げる ● 基本 問題の種類、サブスクリプション、サービス リソース、 サポートプラン ● 問題 重要度、問題の種類、カテゴリ、詳細、 (問題発生日)、(添付ファイル) ● 連絡先情報 ご希望の連絡方法、名、性、メール、電話番号 を入れればOK! 、、、うん、面倒。仕方ないけど。
35. 35. インシデントの上げ方 (3/31 の事例) ● 至急とにかく回避策を知りたくて、緊急度 A で対応依頼。詳細欄に 「接続に時間が異常にかかります。 サービスに影響でています」と書いた ● 依頼してから 30 分後に電話あり (SLA によれば 1 時間以内連絡で、満たしてはいるんだけど、現実的にはもっと早く連絡来ないとつらい) ● 今の構成を伝え、 (面倒。少なくとも 5, 6 回以前から連絡してるので、こちらの文脈を把握してほしい。) 早急に復旧可能な手段を確認するも回答は得られず (Failover 関連の質問には適切な回答をその場でもらいたかった。。) ● 問い合わせ種別「サービス」で依頼し、他のサービスに ついても状況を聞いたが、期待する回答はもらえず...
36. 36. インシデントの上げ方 我々にできること ● 現在の構成と、動いていないところを明確に説明して依頼する ● 期待しすぎない。なんでもかんでも対応してくれるわけではない 緊急度 A だからといってスーパー エンジニアが対応してくれるわけではない MS への要望 ● インシデント上げるの面倒すぎ ● 特に 緊急度 A の場合はつらすぎ ● 大規模障害時はサポート体制もっと熱くしてほしい (しているのかもしれないが感じられない...)
37. 37. まとめ
38. 38. まとめ ● これまでの障害の紹介 ○ ‘16/9/15 DNS 障害 (全世界) … 内部でサーバ名が解決不能に ○ ‘17/3/8 ストレージ障害 (東日本) … Redis を再デプロイ ○ ‘17/3/31 ストレージ障害 (東日本, 西日本) … スケール変更に失敗 ● システム構成部分ごとの障害対策 ○ Storage / Redis … 冗長構成 / 接続文字列変更の仕組み用意 ○ Cloud Service / VM … デプロイし直しが基本 / Managed Disk 併用 ○ Database … 冗長構成 / スケールに注意 ● その他 ○ ペア リージョンについて ○ SLA / インシデント時の問い合わせ手順