Azure(クラウド)を使った堅牢なシステ
ムを考える
MVP x Student Meetup@つくば
吉野翼(よしのつばさ)
自己紹介
吉野翼(よしのつばさ)
Microsoft MVP for Microsoft Azure (2016 ~)
元MSP(2012 ~ 2015)
Compony : シグマコンサルティング株式会社
Work : Webアプリ
Like : Azure, .NET, Kinect
Twitter : https://twitter.com/papeMK2
Facebook : https://www.facebook.com/papeMK2
Blog : https://papemk2.hateblo.jp/
今日のお話
何を考えて開発をしているのか?
何を考えているのか
楽したい
落ちないシステム → 落ちてもすぐに復旧できるシステム
それぞれを小さく、いつでも捨てられるように作る
陳腐化してもすぐ作り変えられるくらいの規模
マイクロサービスよりは、粒度を粗く
小さい単位で開発・デプロイ
接続先を信用しない
自分の身は、自分で守る
以前よりも考えることが増えたのでは?
自分が良く使うAzureのサービス
Dev系 Ops系
App Services Function App
Queue StorageSql Databases
Application Insights Log Analytics
Azure Monitor Azure DevOps
メール送信の構成を考える
会員管理システム
会員登録確定時にメール認証
外部のメールサーバを使用してメールを送信する
メール送信の構成を考える
メールサーバ会員管理システム
メール送信の構成を考える
メールサーバ
メールサーバがダウンしていたら?
送信に失敗したらどうしよう
メールサーバのレスポンスが遅くなっていたら?会員管理システム
メール送信の構成を考える
会員管理システム
送信成功
メールサーバ
メール送信システムメッセージキュー
送信失敗ポイズンキュー
メールメッセージの保存
メール送信の構成を考える
メールを送信するだけのシステムを間に噛ませる
メールのメッセージは、キューに投入
失敗したらエラーのキューに落ちる
リトライは、エラーのキューから再試行
システムを小さい単位に分割する
小さく作ることで、変更の影響を最小限に抑える
小さく作るとテストしやすい
モノリシックに作る → 小さい変更が全体に波及
小さく作ると見通しもつきやすい
アプリが大きいとデプロイが重たい
連携サービスを信用しない
連携するサービスは、ダウンしているかもしれない
ダウンしているサービスに引きずられない構成を作る
外部サービスがダウン → データロスト → 最悪
キューを間に噛ませて失敗の検知、リトライを容易に
クラウドじゃなくても大事なこと
適切にモニタリングをしてアプリを掌握する
アプリでエラーが出ていないか
インフラが適切なスペックか
異常に遅いサービス連携が無いか
ログ収集、分析のSaaSを活用すれば簡単に出来る
モニタリングを適切にする
何か起こったときの為にログをしっかり取得しておく
ログが無い → 障害発生 → ログが無いから再現不可 → 最悪
可能な限りログを残す
センシティブな情報は、残さない or マスクする
• パスワード、会員データなど
通知を適切に行う
通知を適切に行う
一番頻繁に見るツールに通知する
メール
チャット(Slack, Teams, etc)
ぱっと見で何が起きたかわかる通知をする
どんなエラーか
自動復旧できる or 致命的なエラーなのか
ぱっと見で分かりにくい通知は、絶対に見なくなる
人間は、思ったほど勤勉ではない
ようわからないから
後で確認しよう
なるほどNull
Reference Exception
早めに確認しないと
まとめ
モニタリングしやすい仕組みを作ろう
Azureのサービスを組み合わせるととても簡単にできる
当たり前を当たり前にやるが大切
Azureには、たくさんの便利なサービスがあるのでとりあえず
触ってみましょう

Azure(クラウド)を使った堅牢なシステムを考える