1.
Azure 障害との上手な付き合い方
竹井 悠人, 萬藤 和久
bitFlyer, Inc.
2017/04/22 Global Azure Bootcamp 2017 @ Tokyo

2.
免責
このトークは、情報提供のみを目的として行われており、正確性・最新性についての保
障は一切ありません。内容は、会社の見解ではありません。この情報を元にして生じた
不利益について、当社およびスピーカは一切の責任を負いません。
bitFlyer 上での取引についての詳細は、当社カスタマ サポートへお問い合わせくださ
い。

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…)

6.
障害は
私たちの準備なんか
待ってくれない

7.
部位別！ 障害の調理の仕方

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 / インシデント時の問い合わせ手順