Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Azure 障害との上手な付き合い方
竹井 悠人, 萬藤 和久
bitFlyer, Inc.
2017/04/22 Global Azure Bootcamp 2017 @ Tokyo
免責
このトークは、情報提供のみを目的として行われており、正確性・最新性についての保
障は一切ありません。内容は、会社の見解ではありません。この情報を元にして生じた
不利益について、当社およびスピーカは一切の責任を負いません。
bitFlyer...
C# (浮気もありましたが) 大好き 8年
新機能開発、データベース監視マン
SNS は息してません
BTC 送金お待ちしております
竹井 悠人 萬藤 和久
C# 大好き一筋 15年
セキュリティ研究開発
Facebook は飯テロ アカウント
今日のあらすじ
● これまでお付き合いした障害
● 部位別! 障害の調理の仕方
● まとめ
これまでお付き合いしてきた障害
● 2016/9/15, 20:48 JST
全世界で DNS 障害
● 2017/3/8, 21:42 JST
東日本のストレージ障害 (Redis)
● 2017/3/28, 3:04 JST
西日本のストレ...
障害は
私たちの準備なんか
待ってくれない
部位別! 障害の調理の仕方
部位別! 障害の調理の仕方
システム構成ごとに障害への対応方法が異なる
Redis Cache
● Main system
● Lightning
● chainFlyer
● マーケット処理
● 取引約定
● バッチ処理
Web Apps
W...
Storage (Blob, Queue, etc.)
レプリケーションの種類
● Locally Redundant Storage (LRS)
● Zone Redundant Storage (ZRS)
● Geo-Redundant S...
Storage (Blob, Queue, etc.)
対応できること
● ジオ冗長をうまく使いましょう
○ ( でも GRS は実は発動したことはないらしい )
● 同じアセットを別のストレージにデプロイしておく
○ 面倒だからデプロイ自動化...
Cloud Service
バックエンドは普通の VM。ストレージが倒れると死ぬかも
対応できること
● 別リージョンにデプロイし直すしかない
デプロイに 5 分とか、混雑時はもっとかかることを織り込むこと
● DNS の設定変更を忘れなく
必...
Azure DNS / その他 DNS がらみ
接続を切らない限りは死なないかも(だが確証はない)
対応できること
● DNS 自体の冗長系統を用意しておくしかない
● Traffic Manager を組み合わせるもよし
Redis Cache
対応できること
● 重要なデータは入れない
最悪、飛んでもよい覚悟はしておくべし
● キャッシュとしての使い方
つながらない場合は後ろの DB にとりに行くなどの構成を用意
● あったまるまで 30 分ほど
事前に作って...
SQL Database
対応できること
● 接続文字列を変えられるようにする
● バックアップをとる
● geo レプリケーションを組む
Geo レプリケーションを使うときの注意
1. スケールアップしてから Failover
2. とりあえず Failover してからスケールアップ
どちらを選択しますか?
「とりあえず Failover してからスケールアップ」が正解
geo...
SQL Database のコピーについて補足
● 1 つの DB から同時コピーしてはいけない!
● コピーより geo リストア推奨
何らかの理由で Failover 出来ない場合も geo リストア
● 処理時間は容量とサービス レベルに...
マルチ リージョンについて
どこにバックアップを立てますか?
近いところ?
ペアリージョンを使いましょう
● どちらか 1 つのリージョンは
稼動するよう調整されている
● 日本は東と西がペアリージョン
(DB の構成変更が走ったりするので油断...
その他のはなし
SLA
● 保証された稼働率に注意。99.9 % なのか? 99.99 % なのか?
○ Storage : 99.9 % (RA-GRS の場合は読み取り 99.99%)
○ VM / Cloud Service : 99.95 %
○ SQ...
インシデントの上げ方
Azure ポータル ヘルプとサポート から上げる
● 基本
問題の種類、サブスクリプション、サービス リソース、
サポートプラン
● 問題
重要度、問題の種類、カテゴリ、詳細、 (問題発生日)、(添付ファイル)
● 連絡...
インシデントの上げ方
我々にできること
● 現在の構成と、動いていないところを明確に説明して依頼する
● 期待しすぎない。なんでもかんでも対応してくれるわけではない
緊急度 A だからといってスーパー エンジニアが対応してくれるわけではない
M...
まとめ
まとめ
● これまでの障害の紹介
○ ‘16/9/15 DNS 障害 (全世界)
○ ‘17/3/8 ストレージ障害 (東日本)
○ ‘17/3/31 ストレージ障害 (東日本, 西日本)
● システム構成部分ごとの障害対策
○ Storage...
Próxima SlideShare
Cargando en…5
×

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

6.106 visualizaciones

Publicado el

2017/4/22 Japan Azure User Group (JAZUG)
Global Azure Bootcamp 2017 @ Tokyo
https://jazug.connpass.com/event/52917/

Publicado en: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

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

×