インフラエンジニアBooks 30分でわかる 「クラウドアプリケーション 10の設計原則」 Toru Makabe Senior Cloud Solution Architect Microsoft

About me • 真壁 徹(まかべ とおる) • 日本マイクロソフト株式会社 • シニア クラウドソリューションアーキテクト(App Innovation) • アプリケーションとプラットフォームの間にあるグレーゾーンを得意とする • 国立 北陸先端科学技術大学院大学 修了 修士(情報科学) • 分散コンピューティングの学びなおし/研究のため、社会人コースへ • 研究: 分散コンピューティング基盤における宣言的構成管理(2021年 情報処理学会 山下記念研究賞) • 主な著書 • しくみがわかる Kubernetes(翔泳社) • クラウドアプリケーション 10の設計原則(インプレス)

Agenda  本書を書いた動機  インフラ技術者視点での本書の価値  本書の抜粋  「2. 自己復旧できるようにする」  Q&A

本書を書いた動機

本書の「つかみ」 「まずベストプラクティスを教えてください」 筆者の嫌いな言葉です。 [まえがき]

ベストプラクティス そのものは素晴らしい  ベンダやユーザの思想、経験にもとづく、貴重な知識  ベンダの公開するベストプラクティス  製品の設計思想に沿った使い方  ユーザからのフィードバックを整理して還元  ユーザの公開するベストプラクティス  複数の選択肢があった中から、実践しうまくいった経験を紹介

ベストプラクティスの「負の側面」  特定の環境、条件下での「ベスト」である  いまのあなたとチームにとってベストかは、わからない  複数のベストプラクティスが衝突、矛盾することもある（例: A製品とB製品のベストプラクティスが矛盾）  変化する  製品はフィードバックを受けて変化する  使い手の環境も変化する  合わせて、ベストプラクティスも変化する  たとえば、そのベストプラクティスが半年後にベストかは、わからない  鵜呑みにしてしまう  自分の頭で考えなくなってしまう

ベストプラクティスを鵜呑みにした結果  ベストプラクティスが現在の社内ルールに反していることが分かったが、その価値 や妥当性を主張できない  複数のベストプラクティスを参考にしたが一貫性がなく、どれを優先すればよい か判断できない  トラブル対応ができない [まえがき]

とはいえ、すべてを吟味してもいられない ベスト プラクティスA ベスト プラクティスB ベスト プラクティスC ベスト プラクティスD 言わんとすること を理解し 他のベストプラクティスとの一 貫性を確認し 内容に変化がないか定期的 に確認し 自分たちの環境や条件 に合うか議論し

原則を理解しよう!! ベスト プラクティスA ベスト プラクティスB ベスト プラクティスC ベスト プラクティスD 原則 （+背景）

いいドキュメントがある、しかし  全体的に端折り気味  読み手の知識に期待している  翻訳がやや惜しい  もっと具体例がほしい  エピソードやサンプルコードなど  クラウド中立にできそう  Azureに限らない話が多い Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn

そこで「解説本」とした  転載や翻訳、翻案ではなく、解説本という建付け  筆者の経験をもとに解説、要約、加筆  Azureではないパブリッククラウドでも参考になるよう意識  具体例（クラウドの内部構造やサンプルコードなど）はAzure中心

インフラ技術者視点での 本書の価値

よくある会話 アプリ開発者 「DB接続が時々切れるんですよ」 インフラ技術者 「クラウドではメンテナンスとかあるので再接続してくださいね」 アプリ開発者 「どうやって実装すればいいか教えてください」 インフラ技術者 「（むむっ やったことないし 詳しくは知らない）」 アプリ開発者 「（わかってないことを やれって言ってるな）」

知識は荷物になりません アプリ クラウド サービス • 本書の推奨事項はアプリ開発者が主体的に取り組むことを念頭に書いているが、その多くは アプリとインフラ(クラウドサービス)が交わる領域にある • クラウドサービスに関する課題解決や改善には、インフラ技術者も関わることが多い • 原則や具体的な実装を学ぶことで、地に足のついた課題解決や改善ができる

この本は筆者の越境の物語でもある  筆者はアプリケーション開発者として技術者のキャリアをはじめたが、ここ数年は インフラ技術者として仕事をしていた  「インフラ野郎」のキャラ設定をしていた時期もある  しかしクラウドでは「インフラだけでは解決が難しい」課題に度々ぶつかるように  そこで異動し、仕事の軸足をアプリケーションに移した  インフラ技術者の仕事がなくなるとは思っておらず、クラウドでも引き続き重要 （たとえば、全社ネットワークの設計をアプリケーション開発者がやるべきとは思わない)  しかし、アプリケーション担当の帽子をかぶったほうがやりやすいことがある  そのような経験や想いを本書に込めた

10の設計原則

10の設計原則 すべての要素を冗長化する 自己復旧できるようにする 調整を最小限に抑える スケールアウトできるようにする 分割して上限を回避する 運用を考慮する マネージドサービスを活用する 用途に適したデータストアを選ぶ 進化を見込んで設計する ビジネスニーズを忘れない

図やコード、本音や裏話が盛りだくさん [試し読み] クラウドアプリケーション 10の設計原則 - インプレスブックス

<抜粋> 2.自己復旧できるようにする

概要 • 自己復旧がなぜ重要か • 自己復旧の基本的なアプローチ • 推奨事項 • 失敗した操作を再試行する • リモートサービスを保護する（サーキットブレーカー） • リソースの消費や障害を閉じ込める (バルクヘッド) • キューで負荷を平準化する • 失敗したトランザクションを補正する • 実行時間の長い処理にチェックポイントを設ける • 潔く機能を停止する、減らす • クライアントを制限する • など

分散コンピューティングの「落とし穴」 • ネットワークは信頼できる。 • レイテンシはゼロである。 • 帯域幅は無限である。 • ネットワークはセキュアである。 • ネットワーク構成は変化せず一定である。 • 管理者は1人である。 • トランスポートコストはゼロである。 • ネットワークは均質である。 分散コンピューティングの落とし穴 - Wikipedia サン・マイクロシステムズのピー ター・ドイチュらが提唱した、初 めて分散アプリケーションを開 発するプログラマが想定してし まいがちな、「誤った前提」を集 めたもの

この章の重要ポイント 一過性の障害を前提に、それを吸収し回復するアプリケーションを作るべきです。 [リード文]

質問 所属する組織やチームで「再試行やタイムアウトの考慮が文化として根付いてい る」という人は挙手してください

この章の重要ポイント 一過性の障害から回復する最も代表的な方法は、再試行です。アプリケーショ ンに再試行ロジックを組み込みます。筆者の経験でもその効果は大きく、逆にい うと再試行しないアプリケーションは問題がおきやすいです。優先して検討してくだ さい。 [推奨事項 - 失敗した操作を再試行する] 経験的に、再試行の実装を当たり前とする、もしくは潔いタイムアウトの判断ができるチームが作るアプリケーション は、ライフライクル全体で問題がおきにくいです

本書を読んだインフラ技術者の会話 アプリ開発者 「DB接続が時々切れるんですよ」 インフラ技術者 「クラウドではメンテナンスとかあるので再接続してくださいね」 アプリ開発者 「どうやって実装すればいいか教えてください」 インフラ技術者 「参考情報を紹介しますよ。言語は何で書いてます？」 アプリ開発者 「（頼りになるわぁ…）」

まとめ

まとめ  本書はマイクロソフトの公開文書「Azureアプリケーションの10の設計原則」の 解説本です  「ベストプラクティスを鵜呑みにしたくない、その背景にある原則を学びたい」人に おすすめします  Azureだけでなく、ほかのクラウドでも役立つように書きました  想定読者はアプリケーション開発者ですが、インフラ技術者の日々の課題解決 や改善、スキルアップにつながる知識を散りばめました

Thank you