Azure 障害との上手な付き合い方
?
22 likes?7,279 views
2017/4/22 Japan Azure User Group (JAZUG) Global Azure Bootcamp 2017 @ Tokyo https://jazug.connpass.com/event/52917/
Azure 障害との上手な付き合い方
- 1. Azure 障害との上手な付き合い方 竹井 悠人, 萬藤 和久 bitFlyer, Inc. 2017/04/22 Global Azure Bootcamp 2017 @ Tokyo
- 3. C# (浮気もありましたが) 大好き 8年 新機能開発、データベース監視マン SNS は息してません BTC 送金お待ちしております 竹井 悠人 萬藤 和久 C# 大好き一筋 15年 セキュリティ研究開発 Facebook は飯テロ アカウント
- 4. 今日のあらすじ ● これまでお付き合いした障害 ● 部位別！ 障害の調理の仕方 ● まとめ
- 5. これまでお付き合いしてきた障害 ● 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…)
- 8. 部位別！ 障害の調理の仕方 システム構成ごとに障害への対応方法が異なる Redis Cache ● Main system ● Lightning ● chainFlyer ● マーケット処理 ● 取引約定 ● バッチ処理 Web Apps Worker Roles SQL Server Web Roles ● fundFlyer ● BTC News ● セッション管理 Storage Queue バックアップへ
- 9. Storage (Blob, Queue, etc.) レプリケーションの種類 ● Locally Redundant Storage (LRS) ● Zone Redundant Storage (ZRS) ● Geo-Redundant Storage (GRS) ● Read-Access Geo-Redundant Storage (RA-GRS)
- 10. Storage (Blob, Queue, etc.) 対応できること ● ジオ冗長をうまく使いましょう ○ ( でも GRS は実は発動したことはないらしい ) ● 同じアセットを別のストレージにデプロイしておく ○ 面倒だからデプロイ自動化しましょうね ○ 接続文字列を動的に変えられる内部の仕組みを ● CDN を使ってエッジ サーバに退避させるのも手
- 11. Cloud Service バックエンドは普通の VM。ストレージが倒れると死ぬかも 対応できること ● 別リージョンにデプロイし直すしかない デプロイに 5 分とか、混雑時はもっとかかることを織り込むこと ● DNS の設定変更を忘れなく 必要なところは TTL を短くしておくなどの対応もあり
- 12. Azure DNS / その他 DNS がらみ 接続を切らない限りは死なないかも（だが確証はない） 対応できること ● DNS 自体の冗長系統を用意しておくしかない ● Traffic Manager を組み合わせるもよし
- 13. Redis Cache 対応できること ● 重要なデータは入れない 最悪、飛んでもよい覚悟はしておくべし ● キャッシュとしての使い方 つながらない場合は後ろの DB にとりに行くなどの構成を用意 ● あったまるまで 30 分ほど 事前に作っておくなども考慮したほうがよい
- 14. SQL Database 対応できること ● 接続文字列を変えられるようにする ● バックアップをとる ● geo レプリケーションを組む
- 15. Geo レプリケーションを使うときの注意 1. スケールアップしてから Failover 2. とりあえず Failover してからスケールアップ どちらを選択しますか？ 「とりあえず Failover してからスケールアップ」が正解 geo レプリケーションのいずれかに影響があると 他方も影響を受ける可能性が零ではない
- 16. SQL Database のコピーについて補足 ● 1 つの DB から同時コピーしてはいけない！ ● コピーより geo リストア推奨 何らかの理由で Failover 出来ない場合も geo リストア ● 処理時間は容量とサービス レベルに影響うける データ量が多ければ時間がかかる あわせて、構築するサービスレベルのサイズに応じてコピー速度が変わる 今回は... (3/31) 同一サーバー内6時間38分、香港サーバー8時間1分かかったが、 コピー元 DB で reconfiguration が発生し、内部的にやり直ししていた
- 17. マルチ リージョンについて どこにバックアップを立てますか？ 近いところ？ ペアリージョンを使いましょう ● どちらか 1 つのリージョンは 稼動するよう調整されている ● 日本は東と西がペアリージョン (DB の構成変更が走ったりするので油断禁物 )
- 18. その他のはなし
- 19. 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/
- 20. インシデントの上げ方 Azure ポータル ヘルプとサポート から上げる ● 基本 問題の種類、サブスクリプション、サービス リソース、 サポートプラン ● 問題 重要度、問題の種類、カテゴリ、詳細、 (問題発生日)、(添付ファイル) ● 連絡先情報 ご希望の連絡方法、名、性、メール、電話番号 を入れればOK! 、、、うん、面倒。仕方ないけど。
- 21. インシデントの上げ方 我々にできること ● 現在の構成と、動いていないところを明確に説明して依頼する ● 期待しすぎない。なんでもかんでも対応してくれるわけではない 緊急度 A だからといってスーパー エンジニアが対応してくれるわけではない MS への要望 ● インシデント上げるの面倒すぎ ● 特に 緊急度 A の場合はつらすぎ ● 大規模障害時はサポート体制もっと熱くしてほしい (しているのかもしれないが感じられない...)
- 22. まとめ
- 23. まとめ ● これまでの障害の紹介 ○ ‘16/9/15 DNS 障害 (全世界) ○ ‘17/3/8 ストレージ障害 (東日本) ○ ‘17/3/31 ストレージ障害 (東日本, 西日本) ● システム構成部分ごとの障害対策 ○ Storage / Redis … 冗長構成 / 接続文字列変更の仕組み用意 ○ Cloud Service / VM … デプロイし直しが基本 / Managed Disk 併用 ○ Database … 冗長構成 / スケールに注意 ● その他 ○ ペア リージョンについて ○ SLA / インシデント時の問い合わせ手順