Azure Well-Architected Review の日本語訳～信頼性編～(2021 年 2 月時点)

はじめに

Azure ワークロードの品質向上に使用できる基本原則として「 Azure Well-Architected Framework 」と呼ばれるものがあります。 Azure Well-Architected Framework は 「コストの最適化」「オペレーショナル エクセレンス」「パフォーマンス効率」「信頼性」「セキュリティ」 の 5 つの柱で構成され、それぞれに細かな指針や確認事項が示されています。

また、自身の Azure 環境がどの程度 Well-Architected Framework に準じているかを評価するための仕組みとして「Azure Well-Architected Review」があります。これは、以下のリンク先で選択肢にチェックを入れていくだけで、誰でも利用できます。

Azure Well-Architected Review

2021 年 2 月現在、Azure Well-Architected Review は英語でのみ提供されています。項目数が多く設問ごとに頭の中で翻訳していると時間がかかると思い、現在のチェックリストを一通り日本語訳してみました。

本記事では 5 つの柱の中から 「信頼性」 を取り上げます。翻訳に自信のない箇所や意訳した箇所については補足で記述していますが、より適切な訳し方があればコメントいただけると幸いです。

What reliability targets and metrics have you defined for your application?

アプリケーションのためにどのような信頼性の目標値とメトリクスを定義したか？

• Recovery targets to identify how long the workload can be unavailable (Recovery Time Objective) and how much data is acceptable to lose during a disaster (Recovery Point Objective).
• Availability targets such as Service Level Agreements (SLAs) and Service Level Objectives (SLOs).
• Availability metrics to measure and monitor availability such as Mean Time To Recover (MTTR) and Mean Time Between Failure (MTBF).
• Composite SLA for the workload derived using the Azure SLAs for all relevant resources.
• SLAs for all internal and external dependencies.
• Independent availability and recovery targets for critical application subsystems and scenarios.
• None of the above.

• ワークロードが利用不可能な期間(RTO)や障害時のデータ損失がどの程度許容されるか(RPO)を識別するための回復目標値。
• SLA や SLO といった可用性目標値。
• MTTR や MTBF といった可用性を測定、監視するためのメトリクス。
• 全ての関連リソースで Azure の SLA を使うことにより得られるワークロードのための統合的な SLA。
• 全ての内部/外部依存性のための SLA。
• 重要なアプリケーションのサブシステムやシナリオ用の独立した可用性や回復目標値。
• 上記いずれでもない。

補足 1

• 他の章と異なり動詞のない文章のようなので、そのように訳しました。
• SLAs for all internal and external dependencies. 「内部/外部の依存関係を考慮した」ぐらいの意訳でもいいかもしれないです。

How have you ensured that your application architecture is resilient to failures?

アプリケーションのアーキテクチャが障害への弾力性を備えていることを、どのように確認するか？

• Deployed the application across multiple regions.
• Removed all single points of failure by running multiple instances of application components.
• Deployed the application across Availability Zones within a region.
• Performed Failure Mode Analysis (FMA) to identify fault-points and fault-modes.
• Planned for component level faults to minimize application downtime.
• Planned for dependency failures to minimize application downtime.
• None of the above.

• 複数リージョン間でアプリケーションがデプロイされている。
• アプリケーションコンポーネントを複数インスタンスで動かすことにより、単一障害点を取り除かれている。
• リージョン内の可用性ゾーン間でアプリケーションがデプロイされている。
• 障害点や障害モードを識別するため障害モード分析が使用されている。
• アプリケーションのダウンタイムを最小化するため、コンポーネントレベルの障害が計画されている。
• アプリケーションのダウンタイムを最小化するため、依存性を考慮した障害が計画されている。
• 上記いずれでもない。

補足 2

• Planned for ～ 「～になるよう設計されている。」ぐらいのニュアンスかもしれないです。

How have you ensured required capacity and services are available in targeted regions?

ターゲットとなるリージョンにおいて、要求されたキャパシティやサービスが有効であることをどのように確認するか？

• Built a capacity model for the application
• Planned for expected usage patterns.
• Confirmed Azure service availability in required regions.
• Confirmed Availability Zones are available in required regions.
• Validated required capacity is within Azure service scale limits and quotas.
• Validated all APIs/SDKs against target runtimes and languages for required functionality.
• Aligned with Azure roadmaps for required preview services and capabilities.
• None of the above.

• アプリケーションのためのキャパシティモデルが立てられている。
• 予想される利用パターンが計画されている。
• 要求されたリージョンで Azure のサービスが利用可能であることが確認されている。
• 要求されたリージョンで可用性ゾーンが利用可能であることが確認されている。
• 要求されたキャパシティが Azure のサービスのスケール上限やクォータの制限内であることが検証されている。
• 要求された機能で定めたランタイムや言語に対する全ての API や SDK が検証されている。
• 要求されたプレビューのサービスや機能が Azure のロードマップに沿ったものである。
• 上記いずれでもない。

補足 3

• Validated all APIs/SDKs～ 「全ての API や SDK が有効/有益であること」ぐらいの意味かと思います。
• Aligned with～ 「整列されている」という直訳だと意味が通じないため、上記の通り意訳しました。

How are you handling disaster recovery for this workload?

ワークロードの災害からの回復をどのように実行するか？

• Application is available across multiple regions in an active-active configuration.
• Application is deployed across multiple regions in an active-passive configuration in alignment with recovery targets.
• Traffic is routable to the application in the case of a regional failure.
• Defined a backup strategy in alignment with recovery targets.
• Defined a disaster recovery strategy to capture recovery steps for failover and failback.
• Failover and failback steps and processes are automated.
• Successfully tested and validated the failover and failback approach at least once.
• Decomposed the application into distinct subsystems with independent disaster recovery strategies.
• Network connectivity redundancy for on premise data/application sources.
• None of the above.

• アプリケーションがアクティブ-アクティブ構成で複数リージョン間で利用可能である。
• アプリケーションが回復目標値に沿ってアクティブ-パッシブ構成で複数リージョン間でデプロイされている。
• リージョン障害の場合におけるアプリケーションのトラフィックがルーティングされている。
• 回復目標値に沿ったバックアップ戦略が定義されている。
• フェイルオーバーやフェイルバックのリカバリー手順を補足するための災対戦略が定義されている。
• フェイルオーバーやフェイルバックの手順とプロセスが自動化されている。
• フェイルオーバーやフェイルバックのアプローチが最低 1 回は成功裏にテスト/検証されている。
• 独立した災対戦略を持つ明確なサブシステムごとにアプリケーションが分離されている。
• オンプレミスのデータ/アプリケーションソースのためにネットワーク接続が冗長化されている。
• 上記いずれでもない。

補足 4

• ～to capture recovery steps～「リカバリー手順を実行する」ぐらいのニュアンスかと思います。

What decisions have been taken to ensure the application platform meets your reliability requirements?

アプリケーションプラットフォームが回復性要件を満たしていることを確認するための決定要因は何か？

• Application processes are stateless.
• Session state is non-sticky and externalised to a data store.
• Application configuration is treated as code and deployed with the application.
• Application platform services are running in a highly available configuration/SKU.
• Application platform components are deployed across Availability Zones or Availability Sets.
• Leveraged platform services are Availability Zone aware.
• Application platform components are deployed across multiple active regions.
• Load balancing is implemented to distribute traffic across multiple nodes.
• Health probes are implemented to check the health of application components and compound application health.
• Queuing and reliable messaging patterns are used to integrate application tiers.
• Client traffic can be routed to the application in the case of region/zone/network outages.
• Procedures to scale out application platform components are automated.
• None of the above.

• アプリケーションのプロセスがステートレスである。
• セッション状態がスティッキーでなく、データストアへ外部化されている。
• アプリケーションの構成はコードで取り扱われ、アプリケーションへデプロイされる。
• アプリケーションプラットフォームのサービスは高可用性の設定/SKU で動作している。
• アプリケーションプラットフォームのコンポーネントは可用性ゾーンや可用性セットをまたがりデプロイされている。
• 主となるプラットフォームサービスが可用性ゾーンに対応している。
• アプリケーションプラットフォームのコンポーネントが複数のアクティブなリージョン間でデプロイされている。
• 複数のノード間でトラフィックを分散させるため、ロードバランシングが実装されている。
• アプリケーションコンポーネントの状態や複合的な状態を確認するため、正常性プローブが実装されている。
• アプリケーション層を統合するため、キューイングや回復性メッセージングパターンが使われている。
• リージョン/ソーン/ネットワーク停止時のクライアントトラフィックのアプリケーションへの経路がある。
• アプリケーションプラットフォームのコンポーネントをスケールアウトする手順が自動化されている。
• 上記いずれでもない。

補足 5

• Client traffic can be routed～「クライアントトラフィックの経路が確保されている」ぐらいのニュアンスかもしれません。

What decisions have been taken to ensure the data platform meets your reliability requirements?

データプラットフォームが回復性要件を満たしていることを確認するための決定要因は何か？

• Data types are categorized by data consistency requirements.
• Data platform services are running in a highly available configuration/SKU.
• Data is replicated across multiple regions.
• Data is replicated across Availability Zones.
• Data is backed-up on zone/geo-redundant storage.
• Active geo-replication is used for data platform components such as storage and databases.
• Application traffic can be routed to data stores in the case of region/zone/network outages.
• Read operations are segregated from update operations.
• Load balancer health probes assess data platform components.
• Data restore processes have been defined to ensure consistent application state when data is corrupted or deleted.
• Data restore processes have been validated and tested to ensure consistent application state when data is corrupted or deleted.
• None of the above.

• データの一貫性要件によってデータタイプが分類されている。
• データプラットフォームのサービスは高可用性の設定/SKU で動作している。
• データは複数のリージョン間で複製されている。
• データは可用性ゾーン間で複製されている。
• データはゾーン/地理的冗長化されたストレージにバックアップされている。
• ストレージやデータベースといったデータプラットフォームコンポーネントのためにアクティブジオレプリケーションが使われている。
• リージョン/ソーン/ネットワーク停止時のアプリケーショントラフィックのデータソースへの経路がある。
• 読み取り処理は更新処理から分離されている。
• 負荷分散正常性プローブがデータプラットフォームコンポーネントへのアクセスを割り振る。
• データが破損したり消去された際にアプリケーションの状態が一貫性があることを確認するためのデータ復旧プロセスが定義されている。
• データが破損したり消去された際にアプリケーションの状態が一貫性があることを確認するためのデータ復旧プロセスが検証/テストされている。
• 上記いずれでもない。

補足 6

• Load balancer health probes assess data platform components.直訳だと意味が通じないため「コンポーネントへのアクセスを割り振る」と意訳しました。

How does your application logic handle exceptions and errors?

アプリケーションのロジックは例外やエラーをどのように制御しているか？

• Have a method to handle faults that might take a variable amount of time to recover from.
• Request timeouts are configured to manage inter-component calls.
• Retry logic is implemented to handle transient failures, with appropriate back-off strategies to avoid cascading failures.
• The application is instrumented with semantic logs and metrics.
• None of the above.

• 回復に一定の時間を要する障害を制御する方法を持つ。
• 内部のコンポーネント呼び出しを管理するため、リクエストタイムアウトが設定されている。
• 連鎖的な障害を回避する適切なバックオフ戦略として、一時的な障害を制御する再試行ロジックが実装されている。
• アプリケーションは意味のあるログやメトリクスで計測されている。
• 上記いずれでもない。

What decisions have been taken to ensure networking and connectivity meets your reliability requirements?

ネットワーク接続が回復性要件を満たしていることを確認するための決定要因は何か？

• All single points of failure have been eliminated from application communication flows.
• Health probes are configured for Azure Load Balancer(s) to assess application traffic flows and compound health.
• Azure Load Balancer Standard or Zone redundant application gateways are used to load balance traffic across Availability Zones.
• Redundant connections from different locations are used for cross-premises connectivity (ExpressRoute or VPN).
• A failure path has been simulated for cross-premises connectivity.
• Zone redundant gateways are used for cross-premises connectivity (ExpressRoute or VPN).
• Network traffic is monitored, and a response plan is in place to address network outages.
• None of the above.

• アプリケーション通信フローから全ての単一障害点が排除されている。
• アプリケーションのトラフィックフローや複合的な状態を振り分けるため、Azure Load Balancer で正常性プローブが設定されている。
• 可用性ゾーンをまたぐトラフィックを負荷分散するため、Azure Load Balancer Standard やゾーン冗長化した Application Gateways が使われている。
• ExpressRoute や VPN のオンプレ-Azure 間の接続のために、異なる地点からの冗長化した接続が使われている。
• オンプレ-Azure 間の接続において、異常時の経路が想定されている。
• ExpressRoute や VPN のオンプレ-Azure 間の接続のために、ゾーン冗長化のゲートウェイが使われている。
• ネットワークトラフィックが監視され、ネットワークの停止への対応計画がある。
• 上記いずれでもない。

補足 7

• cross-premisesは馴染みのない言葉だったため、意訳しました。

What reliability allowances for scalability and performance have you made?

スケーラビリティとパフォーマンスのためにどのような信頼性を考慮するか？

• The application has dedicated cross-premises bandwidth.
• Components with sensitive latency requirements are collocated.
• Gateways (ExpressRoute or VPN) have been sized according to expected cross-premises network throughput.
• Expected throughput passing through security/network appliances has been tested and autoscaling is configured based on throughput requirements.
• Autoscaling is enabled for application components and integrated with Azure Monitor.
• Autoscaling has been tested and the time to scale in/out has been measured.
• Tested and validated defined latency and defined throughput targets per scenario and component.
• Calculated target data sizes and associated growth rates per scenario and component.
• Operational procedures are defined in case data sizes exceed limits.
• Validated that long-running TCP connections are not required for the workload.
• Throttling is implemented to govern inbound application calls and inter-component calls.
• None of the above.

• アプリケーションはオンプレ-Azure 間で帯域を占有している。
• デリケートなレイテンシ要件を持つコンポーネントが併置されている。
• ExpressRoute や VPN のゲートウェイは予測されたオンプレ-Azure 間のネットワークスループットに応じてサイジングされている。
• セキュリティ/ネットワークアプライアンスを通過する想定スループットがテストされ、スループット要求に基づきオートスケーリングが構成されている。
• アプリケーションコンポーネントでオートスケーリングが有効になっており、Azure Monitor に統合されている。
• オートスケーリングがテストされ、スケールイン/アウトにかかる時間が計測されている。
• シナリオやコンポーネントごとに定義されたレイテンシーやスループットがテスト/検証されている。
• シナリオやコンポーネントごとにデータサイズの目標値や関連する増加率が計算されている。
• データサイズが上限を超えた場合の運用手順が定義されている。
• ワークロードで TCP コネクションの長時間実行が要求されていないことが検証済みである。
• アプリケーションやコンポーネントへの内部呼び出しを治めるため、スロットリングが実装されている。
• 上記いずれでもない。

What reliability allowances for security have you made?

セキュリティのためにどのような信頼性を考慮するか？

• The identity provider (AAD/ADFS/AD/Other) is highly available and aligns with application availability and recovery targets.
• All external application endpoints are secured? i.e. Firewall, WAF, DDoS Protection Standard Plan, etc.
• Communication to Azure PaaS services secured using Virtual Network Service Endpoints or Private Link.
• Keys and secrets are backed-up to geo-redundant storage.
• The process for key rotation is automated and tested
• Emergency access break glass accounts have been tested and secured for recovering from Identity provider failure scenarios.
• None of the above.

• AAD/ADFS/AD などの認証プロバイダーは高い可用性を持ち、アプリケーションの可用性と回復目標値に沿っている。
• Firewall, WAF, DDoS Protection Standard Plan のような全ての外部アプリケーションエンドポイントはセキュアである。
• Azure PaaS services との通信は VNET サービスエンドポイントや Private Link を使いセキュアである。
• キーやシークレットは地理冗長化ストレージにバックアップされている。
• キーのローテーションのプロセスは自動化されテストされている。
• IdP 障害のシナリオからの回復のため、緊急アクセス用アカウントがテストされセキュアな状態である。
• 上記いずれでもない。

What reliability allowances for operations have you made?

運用のためにどのような信頼性を考慮するか？

• Application can be automatically deployed to a new region without any manual operations to recover from disaster scenarios.
• Application deployments can be rolled-back and rolled-forward through automated deployment pipelines.
• The lifecycle of the application is decoupled from its dependencies.
• The time it takes to deploy an entire production environment is tested and validated.
• None of the above.

• 災対シナリオでの回復のために手動作業なしで新しいリージョンへアプリケーションが自動でデプロイ可能である。
• アプリケーションのデプロイは自動化されたデプロイパイプラインを通してロールバックやロールフォワードが可能である。
• アプリケーションのライフサイクルは依存性から分離されている。
• プロダクション環境全体のデプロイに要する時間がテスト/検証されている。
• 上記いずれでもない。

How do you test the application to ensure it is fault tolerant?

障害許容性を確認するためにアプリケーションをどのようにテストするか？

• The application is tested against critical Non-Functional requirements for performance.
• Load Testing is conducted with expected peak volumes to test scalability and performance under load.
• Chaos Testing is performed by injecting faults.
• Tests are automated and carried out periodically or on-demand.
• Critical test environments have 1:1 parity with the production environment.
• None of the above.

• アプリケーションはパフォーマンスのための重要な非機能要件に対してテストされている。
• ロードテストは負荷の下でスケーラビリティとパフォーマンスをテストするために想定されたピーク量で実行される。
• カオステストは障害の注入により実行される。
• テストは自動化され、一定期間もしくはオンデマンドで実行される。
• 重要なテスト環境はプロダクション環境と 1:1 で等価である。
• 上記いずれでもない。

How do you monitor and measure application health?

アプリケーションの正常性をどのように監視/測定するか？

• The application is instrumented with semantic logs and metrics.
• Application logs are correlated across components.
• All components are monitored and correlated with application telemetry.
• Key metrics, thresholds, and indicators are defined and captured.
• A health model has been defined based on performance, availability, and recovery targets and is represented through monitoring dashboard and alerts.
• Azure Service Health events are used to alert on applicable Service level events.
• Azure Resource Health events are used to alert on resource health events.
• Monitor long-running workflows for failures.
• None of the above.

• アプリケーションは意味のあるログやメトリクスで計測されている。
• アプリケーションログはコンポーネントをまたいで収集されている。
• 全てのコンポーネントはアプリケーションテレメトリーで監視/収集されている。
• 主要なメトリクス、閾値、指標が定義/収集されている。
• パフォーマンス/可用性/リカバリー目標値に基づき正常性モデルが定義され、監視サッシュボードやアラートを通して表現されている。
• 該当するサービスレベルのイベントを通知するため、Azure サービス正常性イベントが使われている。
• リソース正常性のイベントを通知するため、Azure リソース正常性イベントが使われている。
• 障害のため長時間実行されているワークフローを監視している。
• 上記いずれでもない。

まとめ

今回は「信頼性」を取り上げました。他の章で聞かれた項目が再度出てきたりしており、重要なことは何度も聞かれるのかなという印象を受けました。

次回は最終回「セキュリティ」の予定です。

参考

Microsoft Azure Well-Architected Framework

関連記事

Azure Well-Architected Review の日本語訳～コストの最適化編～(2021 年 2 月時点)

Azure Well-Architected Review の日本語訳～オペレーショナル エクセレンス編～(2021 年 2 月時点)

Azure Well-Architected Review の日本語訳～パフォーマンス効率編～(2021 年 2 月時点)