はじめに

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 つの柱の中から 「オペレーショナルエクセレンス」 を取り上げます。翻訳に自信のない箇所や意訳した箇所については補足で記述していますが、より適切な訳し方があればコメントいただけると幸いです。

Have you defined key scenarios for your workload and how they relate to operational targets and non-functional requirements?

ワークロードのために重要なシナリオを定義し、運用目標や非機能要件とどのように関連付けているか？

Availability targets such as SLAs, SLIs and SLOs are defined for the application and key scenarios and monitored

Availability targets such as SLAs, SLIs and SLOs for all leveraged dependencies are understood and monitored

Recovery targets such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are defined for the application and key scenarios

The consequences if availability and recovery targets are not satisfied are well understood

There are targets defined for the time it takes to perform scale operations

Critical system flows through the application have been defined for all key business scenarios and have distinct availability, performance and recovery targets

There are well defined performance requirements for the application and key scenarios

Any application components which are less critical and have lower availability or performance requirements are well understood

None of the above.

アプリケーションや重要なシナリオのために SLA/SLI/SLO といった可用性目標が定義され、監視されている。
活用されている全ての依存関係のための SLA/SLI/SLO といった可用性目標が理解され、監視されている。
アプリケーションや重要なシナリオのために RTO/RPO といった回復目標が定義されている。
可用性や回復目標が満たされない場合の結果が十分に理解されている。
スケール操作の実行に要する時間の目標が定義されている。
全ての重要なビジネスシナリオのためにアプリケーションを通じてクリティカルなシステムフローが定義され、明確な可用性、パフォーマンス、回復目標を持つ。
アプリケーションや重要なシナリオのために十分に定義されたパフォーマンス要件がある。
重要度が低く可用性や性能要件も高くないアプリケーションコンポーネントがあることが十分に理解されている。
上記いずれでもない。

補足 1

～all leveraged dependencies～ サードパーティとの依存関係があるシステムを意味していると思われますが、そこまで大胆に意訳してよいか悩ましく直訳気味になっています。

How are you monitoring your resources?

リソースをどのように監視するか？

An Application Performance Management (APM) tool like Azure Application Insights is used to collect application level logs

Application logs are collected from different application environments

Log messages are captured in a structured format and can be indexed and searched

Application events are correlated across all application components

It is possible to evaluate critical application performance targets and non-functional requirements based on application logs and metrics

End-to-end performance of critical system flows is monitored

None of the above.

アプリケーションレベルのログを収集するために、Azure Application Insights のような APM ツールが使われている。
異なるアプリケーション環境からアプリケーションログが収集されている。
構造化されたフォーマットでログメッセージが取得され、索引や検索可能な状態となっている。
全てのアプリケーションコンポーネント間でのアプリケーションイベントが相関付けられている。
アプリケーションログやメトリクスに基づき、重要なアプリケーションのパフォーマンス目標や非機能要件が評価可能である。
重要なシステムフローのエンドツーエンドのパフォーマンスが測定されている。
上記いずれでもない。

How do you interpret the collected data to inform about application health?

アプリケーションの状態を通知するために、収集したデータをどのように解釈するか？

A log aggregation technology, such as Azure Log Analytics or Splunk, is used to collect logs and metrics from Azure resources

Azure Activity Logs are collected within the log aggregation tool

Resource-level monitoring is enforced throughout the application

Logs and metrics are available for critical internal dependencies

Critical external dependencies are monitored

None of the above.

Azure リソースからログやメトリクスを収集するために、Azure Log Analytics や Splunk といったログ集計技術が使われている。
ログ集計ツール内で Azure Activity Logs が収集されている。
リソースレベルのモニタリングがアプリケーションを通して行われている。
重要な内部の依存関係のためにログやメトリクスが有効になっている。
重要な外部の依存関係が監視されている。
上記いずれでもない。

How do you visualize workload data and then alert relevant teams when issues occur?

ワークロードのデータをどのように可視化し、問題発生時に関連するチームにどのように通知するか？

Application and resource level logs are either aggregated in a single data sink, or it is possible to cross-query events at both levels

Application level events are automatically correlated with resource-level metrics to quantify the current application state

A health model is used to qualify what 'healthy' and 'unhealthy' states represent for the workload

Critical system flows are used to inform the health model

The health model can distinguish between transient and non-transient faults

Long-term trends are analysed to predict operational issues before they occur

Retention times for logs and metrics have been defined and with housekeeping mechanisms configured

None of the above.

アプリケーションとリソースレベルのログが単一のデータシンクでどちらも集計されているか、もしくは両方のレベルでイベントを交差して問い合わせできる。
現在のアプリケーションの状態を定量化するために、アプリケーションレベルのイベントはリソースレベルのメトリクスと自動的に相関付けられている。
ワークロードで正常/異常の状態を表すために、正常性モデルが使われている。
重要なシステムフローが正常性モデルを通知するために使われている。
正常性モデルは一時的な障害とそうでないものを区別できる。
運用の問題を発生前に予測するために、長期間の傾向が分析されている。
ログやメトリクスの保持期間が定義され、ハウスキーピングのメカニズムとともに設定されている。
上記いずれでもない。

補足 2

～at both levels 「双方の観点で」ぐらいのほうがわかりやすいかもしれないです。
～health model 正常性モデルという訳し方が正しいのか怪しいですが、一旦この言葉で統一しています。Microsoft Docs で health は正常性と訳されているので、そこまで的外れではないとは思います。

How are you using Azure platform notifications and updates?

Azure プラットフォームの通知や更新を、どのように使用するか？

A tool such as Azure Monitor or Grafana is used to visualize the application health model and encompassed logs and metrics

Dashboards are tailored to a specific audience such as developers, security or networking teams

A tool such as Azure Monitor or Splunk is used for alerting

Specific owners and processes are defined for each alert type

Operational events are prioritized based on business impact

Push notifications are used to inform responsible parties of alerts in real time

Alerting is integrated with an IT Service Management (ITSM) system such as ServiceNow

None of the above.

アプリケーションの正常性モデルや含まれるログやメトリクスを可視化するために、Azure Monitor や Grafana といったツールが使われている。
開発者やセキュリティ/ネットワークチームといった特定の人々のために、ダッシュボードが調整されている。
アラート通知用に Azure Monitor や Splunk といったツールが使われている。
個々のアラートタイプごとに特定の所有者やプロセスが定義されている。
ビジネス影響に基づき運用イベントが優先度付けられている。
責任者へ即時にアラートを通達するため、プッシュ通知が使われている。
アラートは ServiceNow といった ITSM 製品に統合されている。
上記いずれでもない。

補足 3

～encompassed logs and metrics 正確にはアプリケーションに含まれるログやメトリクスということでしょうが、前後の文章と冗長になりそうなので削っています。
Dashboards are tailored～ 「用意されている」ぐらいの意訳でもよいかもしれません。

What is your approach to recovery and failover?

リカバリーやフェイルオーバーのためのアプローチは何ですか？

Recovery steps are defined and well understood for failover and failback

The failover and failback approach has been tested/validated at least once

The health model is being used to classify failover situations

Automated recovery procedures are in place for common failure events

Automated recovery procedures are tested and validated on a regular basis

Critical manual processes are defined and documented for failure responses.

Manual operational runbooks are tested and validated on a regular basis

None of the above.

フェイルオーバーやフェイルバックのためのリカバリー手順が定義され、十分に理解されている。
フェイルオーバーやフェイルバックのアプローチが最低一回はテストされ、検証されている。
フェイルオーバーの状況を分類するために、正常性モデルが使われている。
一般的な障害時のために、自動復旧手順が置かれている。
自動復旧手順は定期的にテスト、検証されている。
障害対応のために重要な手動プロセスが定義、ドキュメント化されている。
手動運用の runbooks が定期的にテスト、検証されている。
上記いずれでもない。

補足 4

Automated recovery procedures are in place～ 直訳してしまってますが、実際は「存在する/作成されている」といったニュアンスかと思います。

How are scale operations performed?

どのようにスケール操作が実行されるか？

There is a capacity model for the workload

Auto-scaling is enabled for supporting PaaS and IaaS services

The process to provision and deprovision capacity is codified

The impact of changes in application health on capacity is fully understood

It has been validated that the required capacity (initial and future growth) is within Azure service scale limits and quotas

It has been validated that the required capacity (initial and future growth) is available within targeted regions

Capacity utilization is monitored and used to forecast future growth

None of the above.

ワークロードのためにキャパシティモデルがある。
PaaS や IaaS でサポートされているオートスケールが有効になっている。
キャパシティのプロビジョニングと解放のプロセスが文書化されている。
アプリケーションの状態におけるキャパシティの変化の影響が十分に理解されている。
初期及び将来的な増加分として要求されるキャパシティが、Azure サービスのスケール制限やクォータの範囲内であることが検証されている。
初期及び将来的な増加分として要求されるキャパシティが、対象のリージョン内で有効であることが検証されている。
キャパシティの利用率が監視され、将来の増加量を予測するために使われている。
上記いずれでもない。

補足 5

～in application health～ アプリケーションの観点から見た、ぐらいの意訳がよいかもしれません。

How are you managing the configuration of your workload?

ワークロードの構成をどのように管理するか？

Application configuration information is stored using a dedicated management system such as Azure App Configuration or Azure Key Vault

Configuration settings can be changed or modified without rebuilding or redeploying the application

Passwords and other secrets are managed in a secure store like Azure Key Vault or HashiCorp Vault

Procedures are in place for key/secret rotation

The application uses Azure Managed Identities

The expiry dates of SSL certificates are monitored and there are processes in place to renew them

None of the above.

アプリケーションの構成情報は Azure App Configuration や Azure Key Vault といった専用の管理システムを使って保存されている。
構成の設定はアプリケーションのリビルドや再デプロイ無しで変更や修正が可能である。
パスワードやその他のシークレットは Azure Key Vault や HashiCorp Vault といったセキュアや場所で管理されている。
キーやシークレットのローテーションのための手順が置かれている。
アプリケーションは Azure Managed Identities を使っている。
SSL 証明書の有効期限日が監視され、更新プロセスが置かれている。
上記いずれでもない。

補足 6

補足 4 と同様、in place の訳し方はもう少しうまくやりたいという思いがあります。

What operational considerations are you making regarding the deployment of your workload?

ワークロードのデプロイを作っていくにあたり、どんな運用の考慮事項がありますか？

The application can be deployed automatically from scratch without any manual operations

There is a documented process for any portions of the deployment that require manual intervention

N-1 or N+1 versions can be deployed via automated pipelines where N is current deployment version in production

There is a defined hotfix process which bypasses normal deployment procedures

The application deployment process leverages blue-green deployments and/or canary releases

Releases to production are gated by having it successfully deployed and tested in other environments

Feature flags are used to test features before rolling them out to everyone

None of the above.

アプリケーションは手動作業無しでスクラッチから自動でデプロイされる。
手動作業を介す必要のあるデプロイのどの箇所においても、文書化されたプロセスがある。
プロダクション環境にデプロイされている現行バージョンに対して、1 世代前後のバージョンが自動パイプラインを経由してデプロイ可能である。
通常のデプロイ手順を迂回する、決められた修正プロセスがある。
アプリケーションのデプロイプロセスで、ブルーグリーンデプロイメントやカナリアリリースを利用する。
他の環境でのデプロイとテストの成功を以て、プロダクション環境へのリリースが通過する。
全てを置き換える前に機能をテストするため、フィーチャーフラグが使われている。
上記いずれでもない。

補足 7

～making regarding the deployment～ deployment は直訳よりもデプロイ環境/デプロイ手順ぐらいの方が意味が通じるように思います。
The application can be deployed automatically from scratch～ scratch は意訳したいのですが、良い言葉が浮かばずそのままとなっています。
There is a defined hotfix process which bypasses～ bypasse は省略する/異なる、ぐらいのニュアンスかもしれません。
Feature flags are used to test features～ features としか書かれてませんが「いくつかの」機能をテストするという意味合いだと思われます。

What operational considerations are you making regarding the deployment of your infrastructure?

インフラでデプロイを作っていくにあたり、どんな運用の考慮事項がありますか？

The entire application infrastructure is defined as code

No operational changes are performed outside of infrastructure as code

Configuration drift is tracked and addressed

The process to deploy infrastructure is automated

Critical test environments have 1:1 parity with the production environment

None of the above.

アプリケーションのインフラストラクチャー全体がコードで定義されている。
infrastructure as code でない運用での変更は実行されない。
構成の流れが追跡され、説明されている。
インフラストラクチャーのデプロイプロセスが自動化されている。
プロダクション環境と同等の重要なテスト環境がある。
上記いずれでもない。

How are you testing and validating your workload?

ワークロードをどのようにテスト、検証しますか？

The application is tested for performance, scalability, and resiliency

Tests for performance, scalability, and resiliency are performed as part of each major change

At least a subset of tests is also performed in the production environment

Fault injection tests are being utilized

Smoke tests are performed during application deployments

Integration testing is performed as part of the application deployment process

All these tests are automated and carried out periodically

Failing tests at least temporarily block a deployment and lead to a deeper analysis of what has happened

Business Continuity 'fire drills' are performed to test regional failover scenarios

Security and penetration testing is performed regularly

None of the above.

アプリケーションのパフォーマンス、スケーラビリティ、弾力性がテストされている。
パフォーマンス、スケーラビリティ、弾力性のテストはそれぞれの主要な変更の一部として実行されている。
プロダクション環境において、少なくともテストのサブセットも実行される。
フォールトインジェクションテストが利用されている。
アプリケーションデプロイの間、スモークテストが実行される。
アプリケーションデプロイプロセスの一部として統合テストが実行される。
これらのテスト全てが自動化され、定期的に実行されている。
障害テストは少なくとも一時的にデプロイを阻害し、何が起こったのかを深い分析を導く。
リージョン間のフェイルオーバーシナリオを試すため、ビジネス継続性の予行演習が実行されている。
セキュリティやペネトレーションテストが定期的に実行されている。
上記いずれでもない。

補足 8

～are being utilized 意訳して「採用されている/実施されている」ぐらいのニュアンスが近いかと思います。
Failing tests at least temporarily block a deployment and～ and よりも but のニュアンスで「デプロイを阻害するけれども/阻害する代わりに」と訳す方が自然に思われます。

What processes and procedures have you adopted to optimize workload operability?

ワークロードを運用に最適化させるために、どのようなプロセスや手順がありますか？

Specific methodologies, like DevOps, are used to structure the development and operations process

Collaboration between development and operations team to resolve production issue is clearly defined and well understood

Operational shortcomings and failures are analyzed and used to improve and refine operational procedures

There are tools or processes in place, such as Azure AD Privileged Identity Management, to grant access to critical systems on a just in-time basis

No users have long-standing write-access to production environments

Azure Resource Tags are used to enrich resources with operational meta-data

There are tools and processes, like Azure Policy, in place to govern available services, enforce mandatory operational functionality and ensure compliance

Standards, policies, restrictions and best practices are defined as code, for example by using solutions like Azure Policy or HashiCorp Sentinel

None of the above.

開発と運用プロセスを構築するために、DevOps のような特定の方法論が使われている。
プロダクションの問題解決のために開発と運用チームの間でコラボレーションが明確に定義され、よく理解されている。
運用の欠点や失敗が分析され、運用手順の改善や洗練のために使われている。
重要なシステムへのアクセスを必要な時のみ許可するため、Azure AD PIM のようなツールやプロセスがある。
プロダクション環境へ長期間書き込み権限を持つユーザーは存在しない。
運用メタデータとともにリソースを豊かにするために、Azure Resource Tags が使われている。
利用可能なサービスを管理し、運用機能を強制しコンプライアンスを確保するため、 Azure Policy のようなツールやプロセスがある。
基準やポリシー、制限やベストプラクティスが Azure Policy や HashiCorp Sentinel のようなソリューションを使うことによってコードで定義されている。
上記いずれでもない。

補足 9

～to enrich resources with operational meta-data enrich は直訳ではなく「リソースに情報量を持たせる」というニュアンスの意訳の方がよいかもしれません。

まとめ

今回は「オペレーショナルエクセレンス」を取り上げました。次回は「パフォーマンス効率」の予定です。

参考

Microsoft Azure Well-Architected Framework

関連記事

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