「止めない」から「壊れても戻せる」へ Azureで考えるResiliency

「止めない」から「壊れても戻せる」へAzureで考えるResiliency
JAWS-UG浜松・静岡 ×JAZUG Shizuoka クラウド勉強会 202611
https://jawsug-hamamatsu.connpass.com/event/404436/

Transcript

1. 「止めない」から「壊れても戻せる」へ Azureで考えるResiliency JAWS-UG浜松・静岡 × JAZUG Shizuoka クラウド勉強会 202611 FutureOne株式会社 草場 友光
2. • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2716時間 2キャラ目：919時間 3キャラ目：801時間 4キャラ目：190時間(配信用) 自己紹介 • 2022/08-2027 Microsoft MVP (Microsoft Azure, Developer Technologies) • tomo_kusaba 第001462号
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • クラウドでのシステムにおいて回復性を考えるのは一つの関心事 項です。 • しかしながら、回復性はビジネス目標やコストとのバランスが求め られています。 • トータルで見た回復性の必要性について考えていきましょう。
5. その冗長化、本当にResilientですか？ • 本日は、JAWSとJAZUGとの合同イベントということでAzure のみを意識しての冗長化機能を紹介する話ではありません • 「冗長化した構成と障害から回復できる構成は同一なのか？」 これを考えていきます
6. クラウドでも、障害は起きる • 分散システムで「障害が発生しない」と考えるのは現実ではない。 • 一部の機能が壊れることはよくあること。 • 障害をなくすことからスタートしない。
7. 「止めない」だけが信頼性ではない • 信頼性を稼働率だけでとらえない • Azure Well-Architectedでは、Resilient / Recoverable / Availableという観点で信頼性を考えている。 • 特に「耐える」と「復旧する」は分けて考える。
8. 冗長化すれば安心？ • 例えば、Webサーバを2台にしてロードバランサーで冗長化。 • これで、信頼性の目標を満たしたといえるか？？ • 冗長化は単一リソースの問題をシステム全体に波及させないため の手段です。
9. 同じ障害理由なら、同時に止まる • ただ、「2個ある」だけなら同時に止まるかもしれない。 • 同じラック • 同じデータセンター • 地理的に同じ場所
10. アプリが動いていても、サービスは使えな い • App ServiceやContainer Appsが動いていてもサービス正 常とは限らない • ストレージ、データベースなど依存サービスやネットワークをユー ザーが目的を達成するまでのフローと考える。 • サービスが使えるかどうかという点を信頼性目標に置く
11. 守るべきものは、サーバーではなくユー ザー体験 • Webサーバ単体の動作を目的にしない。 • ユーザーの目的を完遂できることを目的にする。 • 重要なフローを定義する • インフラの可用性をビジネス上の可用性に翻訳する
12. どこまで止まってよいのか • ビジネス上要件から許容できる停止を考える。 • すべてのコンポーネントを同じ信頼性にする必要性はない。 • 重要なフローと、縮退してもよいフローを分ける。
13. どこまでデータを失ってよいのか • システムを復旧してもデータを失っては目的を達成できない。 • システム停止時点からどれだけデータをさかのぼってもよいか？ • バックアップ頻度 • システム復旧時点 • 復旧目標は依存関係も踏まえて実現可能なものにする。
14. どれくらいで戻せばよいのか • 障害を防げなかった場合はどのくらいの時間で復旧するか？ • ビジネス上条件から合意した復旧目標内でワークロードを戻せる 設計を考える。 • 回復性を超えた障害に対してリカバリーがある。
15. 要件が決まって、初めてAzure構成が決 まる • 以下から冗長化やDRを選択する • 重要なユーザーワークフローとはなにか？ • 許容できる影響はなにか？ • 復旧目標はどれくらいか？ • Availiability Zoneを使うべき？から考えない。
16. 障害は「起こるか」ではなく「起きたらどう なるか」 • ここが落ちたらどうなるかで考える • コンピューティングリソースが落ちたら？ • データストアが落ちたら？ • ネットワークが落ちたら？ • 障害発生を前提としてどのように機能できるか、縮退するかを考 える。
17. 検知できなければ、回復は始まらない • 信頼できるワークロードには、検知して耐える能力が必要。 • 回復性は冗長化だけの問題ではない。 • つまり、設計対象はインフラだけでなくアプリケーションコードと 運用も入る。
18. 復旧手順は、試して初めて設計になる • バックアップがある • DR環境がある • でも、本当にそれらから戻すことができるのか？？ • 我々はいざというときにバックアップから戻せないという事例を 見聞きしてきました。 • Azure Well-Architectedは設計だけなく運用も信頼性の対 象
19. Resiliencyとは、壊れても価値を提供し 続ける力 • 障害を検知 • 耐える • 必要なら縮退 • それを超えたら復旧 • 壊れないシステムを作るのではなく、壊れたときも目的を果たせ るワークロードを作る
20. 「何を冗長化する？」の前に「何を守る？」 を考えよう • 何を守る？ • 何が壊れる？ • どこまで耐える？ • どう回復する？ • そのために何を冗長化する？
21. 宣伝
23. アクセシビリティカンファレンス福岡 2026(11/21)
24. Microsoft MVPとMicrosoft Ignite の日に徹夜するバー（11/17）
25. 【大阪出張編】.NETラボ 勉強会 2026年 11月(11/28)
26. PyCon mini Tokyo with PythonAsia conference 日本とアジアのPythonコミュニティが交流する1日 2026/12/12（土） 10:00〜19:00 会場 日本語・英語の2トラック GMO Yours・フクラス 渋谷フクラス16階 基調講演 Seth Larson / Mike Fiedler （Python Software Foundation） 一般 1,500円 学生 500円 パトロン 10,000円 参加登録はconnpassへ（事前決済） pyconjp.connpass.com/event/404336/
27. 開催日のお知らせ PyCon mini Shizuoka 2027 2027/2/27（土） 会場 B-nest & 静岡市コクリ 前回と同じ会場です。ぜひ予定の確保をお願いします！ #pyconshizu 2027でお会いしましょう！ 参加・プロポーザル・スポンサーの募集は追って告知します。 pycon-shizu.connpass.com/event/409477/ 詳細はconnpassへ
28. 開催日・会場のお知らせ PyCon JP 2027 Pythonユーザーが集い、情報交換・交流するカンファレンス 2027/9/24（金）〜26（日） 会場 沼津プラサヴェルデ 参加チケット・プロポーザル・スポンサー募集は近日案内 最新情報は公式サイトへ 2027.pycon.jp 静岡県沼津市
29. おしまい