はじめに

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

How are you modeling cloud costs of this workload?

ワークロードのクラウドのコストをどのようにモデリングしているか？

Cloud costs are being modelled for this workload.

The price model of the workload is clear.

Critical system flows through the application have been defined for all key business scenarios.

There is a well-understood capacity model for the workload.

Internal and external dependencies are identified and cost implications understood.

Cost implications of each Azure service used by the application are understood.

The right operational capabilities are used for Azure services.

Special discounts given to services or licenses are factored in when calculating new cost models for services being moved to the cloud.

Azure Hybrid Use Benefit is used to drive down cost in the cloud.

None of the above.

ワークロードのためにクラウドのコストがモデリングされている。
ワークロードの価格モデルが明確である。
すべての主要なビジネスシナリオのために、アプリケーションを通した重要なシステムフローが定義されている。
ワークロードのために十分に理解された容量モデルがある。
内部および外部への依存性が識別され、コストへの影響が理解されている。
アプリケーションによって使用される個々の Azure サービスのコストへの影響が理解されている。
Azure サービスのために適切な運用能力が使われている。
クラウドへ移行するサービスのために新しいコストモデルを試算する際に、サービスやライセンスに与えられる特別な割引が考慮されている。
クラウドにおけるコスト削減のために、AHUB(Azure Hybrid Use Benefit)が使われている。
上記いずれでもない。

補足 1

The right operational～ は「運用能力が使われている」というより「ケーパを有している」というニュアンスの方が近いかもしれません。

How do you govern budgets and application lifespan for this workload?

ワークロードのために、予算やアプリケーションライフサイクルをどのように管理するか？

Budgets are assigned to all services in this workload.

There is a cost owner for every service used by this workload.

Cost forecasting is done to ensure it aligns with the budget.

There is a monthly or yearly meeting where the budget is reviewed.

Every environment has a target end-date.

Every environment has a plan for migrating to PaaS or serverless to lower the all up cost and transfer risk.

There is a clear understanding of how budget is defined.

Budget is factored into the building phase.

There is an ongoing conversation between the app owner and the business.

There is a plan to modernize the workload.

Azure Tags are used to enrich Azure resources with operational metadata.

The application has a well-defined naming standard for Azure resources.

Role Based Access Control (RBAC) is used to control access to operational and financial dashboards and underlying data.

None of the above.

ワークロードにおいて、全てのサービスに予算が割り当てられている。
ワークロードで使われる全てのサービスにコストオーナーがいる。
コストの予測は、予算との一致を確認するために行われる。
予算がレビューされる月次または年次の会議がある。
全ての環境には終了日が定められている。
全ての環境には、総コストを下げリスクを移転するために PaaS やサーバーレスに移行する計画がある。
どのように予算が決まるか、明確な理解がある。
予算は構築フェーズで考慮されている。
アプリケーションオーナーとビジネスサイドとの間で、継続的に議論が交わされている。
ワークロードをモダナイズする計画がある。
運用メタデータと一緒に Azure リソースを向上させるために、Azure Tags が使われている。
アプリケーションは Azure リソースのために明確に定義された命名規約を持つ。
運用・会計ダッシュボードやそれに紐づくデータへのアクセス制御のために RBAC が使われている。
上記いずれでもない。

補足 2

Cost forecasting is～ は今の直訳でも通じますが、「コストを予測することで、予算と差異がないことを確認する」ぐらいの方が自然かもしれません。
There is an ongoing conversation～ 「進行中の会話」だとさすがに意味が通じないので、上記のように意訳しました。
～underlying data も直訳の「根底にあるデータ」だと苦しいため、上記のように意訳しました。

How are you monitoring costs of this workload?

ワークロードのコストをどのように監視するか？

Alerts are set for cost thresholds and limits.

Specific owners and processes are defined for each alert type.

Application Performance Management (APM) tools and log aggregation technologies are used to collect logs and metrics from Azure resources.

Cost Management Tools (such as Azure Cost Management) are being used to track spending in this workload.

None of the above.

コストの閾値や限度額でアラートがセットされている。
それぞれのアラートの種類によって、特定のオーナーやプロセスが定義されている。
Azure リソースからログやメトリクスを収集するために、APM ツールやログの集計技術が使われている。
ワークロードで支出を追跡できるよう、Azure Cost Management のようなコスト管理ツールが使われている。
上記いずれでもない。

How do you optimize the design of this workload?

ワークロードの設計をどのように最適化するか？

The application was built natively for the cloud.

There is an availability strategy defined and cost implications of it are understood.

This workload benefits from higher density.

Data is being transferred between regions.

Multi-region deployment is supported and cost implications understood.

The workload is designed to use Availability Zones within a region.

None of the above.

アプリケーションはクラウドネイティブに構築された。
コストへの影響を理解した上で定義された可用性戦略がある。
このワークロードは高密度な利益をもたらす。
データは複数リージョン間で転送されている。
マルチリージョンデプロイがサポートされ、コストへの影響が考慮されている。
ワークロードではリージョン内の可用性ゾーンを使うよう設計されている。
上記いずれでもない。

補足 3

The application was built～ 設計の話なのに構築されたという過去形の記述になっているのがあまり腑に落ちていませんが、一旦直訳のままにしています。
～higher density もう少し自然な日本語にしたいですが、適切な言葉が浮かばずそのままにしています。

How do you ensure that cloud services are appropriately provisioned?

クラウドサービスが適切にプロビジョンされたことを、どのように確認するか？

Performance requirements are well-defined.

Targets for the time it takes to perform scale operations are defined and monitored.

The workload is designed to scale independently.

The application has been designed to scale both in and out.

Application components and data are split into groups as part of your disaster recovery strategy.

Tools (such as Azure Advisor) are being used to optimise SKUs discovered in this workload.

Resources are reviewed weekly or bi-weekly for optimization.

Cost-effective regions are considered as part of the deployment selection.

Dev/Test offerings are used correctly.

Shared hosting platforms are used correctly.

None of the above.

パフォーマンス要件が明確に定義されている。
スケール操作の実行に要する目標時間が定義され、測定されている
ワークロードは独立してスケールするよう設計されている。
アプリケーションはスケールイン/アウト両方で設計されている。
アプリケーションのコンポーネントやデータは、災対戦略の一部としてグループに分割されている。
ワークロードにおける最適な SKU の発見のために、Azure Advisor のようなツールが使われている。
リソースは最適化のために週次または隔週でレビューされている。
デプロイ選定の一部として、コスト効果の高いリージョンが考慮されている。
Azure Dev/Test サブスクリプションが正しく使われている。
共有サービスが正しく使われている。
上記いずれでもない。

補足 4

Dev/Test offerings～ 最初はよく意味がわからなかったのですが、Microsoft Docs で Azure Dev/Test サブスクリプションについての記述があったためそのように意訳しました。
Shared hosting platforms～ 同様に、特定の Azure プランで提供される共有サービスのテナントやリソースのことを指していると思われます。

What considerations for DevOps practices are you making in this workload?

このワークロードで DevOps の実践のために何を考慮するか？

There is an automated process to deploy application releases to production.

There is a difference in configuration for production and non-production environments.

Test-environments are deployed automatically and deleted after use.

There is awareness around how the application has been built and is being maintained (in house or via an external partner).

There is awareness regarding the ratio of cost of production and non-production environments for this workload.

None of the above.

アプリケーションを運用環境へデプロイするために、自動化されたプロセスがある。
運用環境とそれ以外では構成に差異がある。
テスト環境は自動的にデプロイされ、使用後は削除される。
アプリケーションがどのように構築・維持されているかを社内またや外部パートナー経由で認識している。
ワークロードにおける運用環境とそれ以外の環境のコストの割合に関して認識している。
上記いずれでもない。

How do you manage compute costs for this workload?

ワークロードのために、コンピューティングのコストをどのように管理するか？

Appropriate SKUs are used for workload servers.

Appropriate operating systems are used in the workload.

A recent review of SKUs that could benefit from Reserved Instances for 1 or 3 years or more has been performed.

Burstable (B) series VM sizes are used for VMs that are idle most of the time and have high usage only in certain periods.

VM instances which are not used are shut down.

Spot virtual machines are used.

PaaS is used as an alternative to buying virtual machines.

Costs are optimized by using the App Service Premium (v3) plan over the Premium (Pv2) plan.

Zone to Zone disaster recovery is used for virtual machines.

The Start/Stop feature in Azure Kubernetes Services (AKS) is used.

None of the above.

ワークロードのサーバーのために、適切な SKU が使われている。
ワークロードで適切な OS が使われている。
1 年/3 年以上 Reserved Instances で利益のあった SKU の最近のレビューが実行されている。
大半の時間は稼働せず特定の期間だけ高い使用率となる VM のために、B シリーズの VM が使われている。
使われていない VM インスタンスはシャットダウンされている。
スポット VM が使われている。
VM を購入する代わりに PaaS が使われている。
App Service の Pv2 プランよりも Premium (v3)プランを使うことで、コストが最適化されている。
仮想マシンのために、ゾーン間のディザスタリカバリーが使われている。
AKS で開始/停止機能が使われている。
上記いずれでもない。

補足 5

A recent review～ RI の運用を定期的に見直していることが説明できればよいのですが、良い文章が浮かばずイマイチな訳になってしまってます。

How do you manage networking costs for this workload?

ワークロードのために、ネットワークのコストをどのように管理するか？

Service Endpoints or Private Link are used for accessing Azure PaaS services.

Hub and spoke design pricing is understood.

Microsoft backbone network is preferred.

DDoS attack mitigation plans and capabilities are in place.

Azure Front Door, Azure App Gateway or Web Application Firewall is used.

The workload is connected between regions (using network peering or gateways).

Azure resources are connecting to the internet via on-premises.

Public IPs and orphaned NICs are regularly cleaned up.

None of the above.

Azure PaaS へのアクセスのために、Service Endpoints や Private Link が使われている。
ハブ&スポーク型の設計の料金が理解されている。
Microsoft のバックボーンネットワークが優先されている。
DDoS 攻撃の軽減計画と機能が導入されている
Azure Front Door や Azure Application Gateway、Azure WAF が使われている。
ワークロードは network peering やゲートウェイを使ってリージョン間で接続されている。
Azure リソースはオンプレミス経由でインターネットに接続している。
パブリック IP と孤立 NIC は定期的にクリーンアップされる。
上記いずれでもない。

補足 6

Hub and spoke design pricing～ 「ハブ&スポーク設計のコストの利点が理解されている。」ぐらいの訳の方が自然かもしれません。

How do you manage storage and data costs for this workload?

ワークロードのために、ストレージとデータのコストをどのように管理するか？

Reserved capacity is used for data in block blob storage.

Data is organized into access tiers.

Lifecycle policy is used to move data between access tiers.

Shared disks are leveraged for suitable workloads.

Reserved premium disks (P30 & above) are used.

Bursting for P20 and below disks is utilized for suitable workloads.

For database workloads, data and log files are stored on separate disks.

Unused storage resources (e.g. unattached disks, old snapshots) are periodically cleaned up.

Selective disk backup and restore for Azure VMs is used.

None of the above.

予約容量はブロック Blob でのデータのために使われている。
データはアクセス層に組成される。
ライフサイクルポリシーはアクセス層間でデータを移動させるために使用される。
共有ディスクは適切なワークロードのために活用される。
P30 以上のリザーブドプレミアムディスクが使われている。
P20 以下のディスクのバーストは適切なワークロードのために利用される。
アタッチされていないディスクや古いスナップショットなどの、未使用のストレージリソースは定期的にクリーンアップされる。
Azure VM のために選択的なディスクのバックアップとリストアが使われている。
上記いずれでもない。

補足 7

Data is organized into access tiers～ データに応じてホット層やクール層など適切なところに配置されるということが言えればよいので、もっと大胆に意訳しても良いかもしれません。

所感

翻訳自体は怪しいところも多々ありますが、訳してみることで結果的に Well-Architected Framework やレビュー項目についての理解を深めることができたような気がします。今後は、コスト以外のセクションについても順次対応していきたいと思います。

また、Azure Well-Architected Review のチェック項目については日々更新されているようですので、お使いになるタイミングによっては設問内容が異なるかもしれません。あらかじめ、ご了承ください。

参考

Microsoft Azure Well-Architected Framework