クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則（インプレス） [電子書籍]

クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則（インプレス） の 商品概要

• ●陳腐化しにくい「原則」を理解しよう
  ベストプラクティスや標準化ガイドラインといった、クラウドを使いこなすための情報が増えています。しかしその一方で、背景を理解せずそれらの情報を表面的に利用してしまい、残念な結果に終わることも珍しくありません。
  本書では、Azureアプリケーションアーキテクチャガイドの「Azureアプリケーションの10の設計原則」をもとに、クラウド上にアプリケーションやシステムを構築する際に心にとめておきたい原則を、現役クラウドアーキテクトの経験を大幅に加えて解説します。陳腐化しにくい普遍的なクラウド設計の原理原則を知りたい方に向けた一冊です。単なるテクニックにとどまらない、長く役立つ視点や審美眼を磨いてみませんか。
  
  【クラウドアプリケーション10の設計原則】
  （1）すべての要素を冗長化する
  （2）自己復旧できるようにする
  （3）調整を最小限に抑える
  （4）スケールアウトできるようにする
  （5）分割して上限を回避する
  （6）運用を考慮する
  （7）マネージドサービスを活用する
  （8）用途に適したデータストアを選ぶ
  （9）進化を見込んで設計する
  （10）ビジネスニーズを忘れない
  

• 目次

  表紙
  本書情報および正誤表のWebページ
  はじめに
  本書の特徴
  各章の構成
  想定する読者像／読了後のゴール
  謝辞
  目次
  第 1 章 すべての要素を冗長化する Make all things redundant
  1-1 クラウドにおける障害の特徴／一過性の障害
  一過性の障害が非クラウドで起きにくかった理由／長時間にわたる障害
  サービスレベルの実際
  冗長化がすべてではない
  目標決定と見直しのサイクル
  1-2 推奨事項／ビジネス要件を考慮する／仮想マシンを負荷分散サービスの内側に配置する
  PaaSでも冗長化を意識する／データストアをパーティション分割する／データを複製（レプリケート）する
  Geoレプリケーションを有効にする／RTOとRPOを意識する
  フロントエンドとバックエンドのフェイルオーバーを同期する
  アクティブ／アクティブなマルチリージョン構成を検討する
  正常性エンドポイントを実装する
  自動フェイルオーバーを使用するが、フェイルバックは手動で行う
  負荷分散サービスの冗長性を確保する
  1-3 まとめ
  第 2 章 自己復旧できるようにする Design for self healing
  2-1 基本的なアプローチ
  2-2 推奨事項／失敗した操作を再試行する
  リモートサービスを保護する（サーキットブレーカー）
  リソースの消費や障害を閉じ込める（バルクヘッド）
  キューで負荷を平準化する
  フェイルオーバー、フォールバックで切り替える
  失敗したトランザクションを補正する
  実行時間の長い処理にチェックポイントを設ける
  潔く機能を停止する、減らす／クライアントを制限する
  リーダー選定を使う
  カオスエンジニアリングに取り組む
  2-3 まとめ
  第 3 章 調整を最小限に抑える Minimize coordination
  3-1 性能拡張と異常系処理は「調整」を生む／調整の例─ロック解放待ち
  調整の例─キューと複数のワーカ
  3-2 推奨事項／結果整合性を受け入れる
  ドメインイベントを検討する
  CQRSやイベントソーシングパターンを検討する
  トランザクショナルOutboxパターンを検討する
  データストアをパーティション分割する
  べき等にする／楽観的並行性制御を検討する／
  調整にリーダー選定を使う／並列分散フレームワークを検討する／オーケストレーションフレームワークを検討する
  3-3 まとめ
  第 4 章 スケールアウトできるようにする Design to scale out
  4-1 クラウドでスケールアウトが好まれる理由
  サーバの手に入りやすさとコスト
  スケジューリング
  PaaSで利用可能なリソース量
  4-2 推奨事項／セッションアフィニティやスティッキーセッションに依存しない
  セッション情報は外に持つ
  限界とボトルネックを把握する／ワークロードで分離する
  多くのリソースを消費するタスクを分離する／自動スケール機能を使う
  安全にスケールインする
  4-3 まとめ
  第 5 章 分割して上限を回避する Partition around limits
  5-1 クラウドサービスの上限を理解する／どのような上限があるのか
  5-2 推奨事項／データストアをパーティション分割する
  エンドツーエンドで把握する
  動かして把握する／デプロイスタンプパターンを検討する
  5-3 まとめ
  第 6 章 運用を考慮する Design for operations
  6-1 運用しやすいアプリケーションを作る／“You build it, you run it.“
  運用しやすいアプリケーションとは
  6-2 推奨事項／必要な情報を定義する
  アプリケーションを計装する
  利用者目線での監視を行う
  分散トレースを行う
  インシデントの根本原因の把握手段を整える
  管理タスクを自動化する
  インフラストラクチャや構成をコードとして扱う
  テストを自動化する
  6-3 まとめ
  第 7 章 マネージドサービスを活用する Use platform as a service options
  7-1 IaaSもPaaSもマネージドサービス
  定番はNISTによる定義
  IaaSと比較したPaaSのメリット／PaaSと比較したIaaSのメリット
  活用の第一歩は、トレードオフを理解すること
  7-2 推奨事項／IaaSとPaaSの垣根をなくす
  メンテナンスに備える
  不明なサービス仕様は確認する
  何を自ら作り運用すべきかを問う
  サービスや機能の非推奨化、終了に備える
  7-3 まとめ
  第 8 章 用途に適したデータストアを選ぶ Use the best data store for your data
  8-1 リレーショナルデータベースの代替技術
  8-2 推奨事項／要件に適するデータストアを選ぶ
  一貫性に関するトレードオフを理解する
  ポリグロット・パーシステンスに取り組む
  開発チームの能力を考慮する
  境界付けられたコンテキストでデータストアを使い分ける／補正トランザクションを検討する／イノベーションを取り込むタイミングを見極める
  8-3 まとめ
  第 9 章 進化を見込んで設計する Design for evolution
  9-1 テストを自動化し、マイクロサービスから学ぶ
  9-2 推奨事項／高凝集と疎結合を徹底する／ドメインナレッジをカプセル化する
  非同期メッセージングを活用する
  オープンなインターフェイスを公開する
  インフラストラクチャを抽象化し、ドメインロジックと分離する／サービスを個別にデプロイできるようにする
  マイクロサービスアーキテクチャの設計パターンから学ぶ
  変化を計測、追跡する
  9-3 まとめ
  第1 0 章 ビジネスニーズを忘れない Build for business needs
  10-1 ビジネスニーズは技術の現場から遠ざかりやすい
  10-2 推奨事項／企業、組織のニーズや戦略を確認し、文書化する
  具体的、現実的な目標を設定、文書化する
  コストを最適化する
  10-3 まとめ
  付録 A 守りは左から固める／A-1 シフトレフトとは
  何度も左に戻す
  圧倒されないために
  A-2 推奨事項／エンタープライズセキュリティの3R（Rotate、Repave、Repair）
  Repair（修理）
  Rotate（交換）
  Repave（再舗装）
  A-3 まとめ
  付録 B 目的別 参考ドキュメント集／Azureでアプリケーションを作りたい、設計の助けになる情報が欲しい
  本書で紹介されなかったクラウド設計パターンも知りたい／マイクロサービスに特化した情報が欲しい／.NETに特化した情報が欲しい／本書で紹介されたAzureのサービスに対応するAWS、Google Cloudのサービスを知りたい
  アプリケーション設計にとどまらない、ほかの視点での参考情報が欲しい
  あとがき
  索引
  著者紹介
  奥付
  

クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則（インプレス） の商品スペック