クラウドの力を生かしてデジタルトランスフォーメーション（DX）を推進したいと考える企業が、具体的にどこからどのように進めるべきか、その指針となるのが「Microsoft Cloud Adoption Framework for Azure」と、「Microsoft Azure Well-Architected Framework」です。Microsoft Cloud Adoption Framework for Azureがテクノロジ以外の領域も包含した包括的な企業戦略のガイダンスとなっているのに対し、Microsoft Azure Well-Architected Frameworkでは、Azure上の具体的な設計原則に落とし込んだ具体的な指針が示されています。

Microsoft Azure Well-Architected Frameworkの前提にあるクラウドの「一般的な基本原則」

Microsoft Azure Well-Architected Frameworkは、「コスト最適化」「オペレーショナルエクセレンス」「パフォーマンス効率」「信頼性」「セキュリティ」という5つの柱から構成されていますが、その大前提として、「一般的な基本原則」とクラウドならではの「共同責任モデル」が存在しています。すでにご存じの方もいるかもしれませんが、あらためてここで基本原則について説明しておきましょう。

一般的な基本原則は「アーキテクチャの進化を実現」「データを使用した意思決定」「教育と有効化」「自動化」という4つの原則からなっています。

アーキテクチャの進化を実現、という原則が意味するのは次のようなことです。当たり前ですがクラウドは日々進化しており、どんどん新しいアーキテクチャやサービスが登場しています。一度構築したら塩漬けにしてしまうのではなく、常に「新しい何か」を取り入れていくことを前提に取り組む必要があります。

2つ目は、あえて言うまでもないことかもしれません。ただ、データを用いて意思決定するには、データがなければ話になりません。ですから「いろいろなパフォーマンスに関するデータやログなど、さまざまなデータを取っていくことを行動原則にしていくことが重要です」とマイクロソフトの第一アーキテクト本部 本部長、内藤稔氏は述べました。

3つ目の教育と有効化ですが、この原則が言わんとするところは、インフラや運用、アプリケーション開発に携わるエンジニアだけではなく、ビジネスチームに対しても「クラウドというものをどう使っていくか」を教育し、巻き込んでいく必要があるということです。「クラウドのことはITに任せた」で終わらせるのではなく、知識や目的を共有し、ともに進めていくことが重要になります。

そして最後の自動化では、2つ目の原則である「データに基づいた意思決定」が効いてきます。過去のデータを元に、「このくらい使用量が上がったらリソースを追加する」といった具合にパターンを導きだし、人がわざわざ判断しなくても自動化していくのです。これにより「クラウドならではの良さを生かして運用を楽にし、しかもビジネス上の効果を高めることができます。ひいては、クラウド利用の効果の最大化に役立つのではないでしょうか」（内藤氏）

利用者と事業者の協力でセキュリティを保つ「共同責任モデル」

ここまでがクラウド利用の一般的な基本原則です。ただ「一方で、クラウドならではの共同責任モデルをきちんと理解しておく必要があります」と内藤氏は述べました。

クラウドに移行すればすべてクラウドプロバイダーにお任せ。そんなイメージを持つ方もいることでしょう。確かにオンプレミスに比べれば、クラウドプロバイダーが責任を追う範囲は広がります。しかし「すべて」ではありません。IaaS、PaaS、SaaSといったサービスモデルごとに範囲は異なりますが、利用者側が責任を持って管理すべき範囲も当然あるのです。

ですから、「利用者が責任を持つ範囲、言い換えればクラウドプロバイダーが触れることができず、自由度がある範囲をきちんと理解しておくことで、正しくクラウドを活用できます」（内藤氏）。この責任範囲を明確に理解することで、「ここはプロバイダーに任せておいたと思っていたのに…」といった不幸な事故を減らし、将来のリスクヘッジにつなげることができます。

Microsoft Azure Well-Architected Frameworkはこうした原則の上で、クラウドの導入準備から採用、管理に至るステップにおけるAzure利用のベストプラクティスを示しています。

ワークロードの変化に合わせた、最適な「パフォーマンス効率」のバランスを探る

さて、Microsoft Azure Well-Architected Frameworkの3本目の柱が「パフォーマンス効率」です。せっかくクラウドを活用しているのに、十分なパフォーマンスが出ずにユーザー体験を損なっては元も子もありません。だからといって無尽蔵にリソースを追加していてはコスト効率が悪くなるばかりでしょう。このバランスをいかに取るかを考えていくことが、クラウドでは特に重要になります。

「パフォーマンスはオンプレミスのシステムにおいてももちろん重要ですが、クラウドの場合、サービス需要は変動します。その変動に基づいてきちんとリソースを割り当てられるか、といった部分も視野に入れてアーキテクチャを設計しておくことが必要です。合わせて、それがきちんと実現できるか、自動的に適用できるかを確認するテストや監視についても考慮する必要があります」（内藤氏）

パフォーマンス効率を考える上でポイントとなる項目は「パフォーマンス効率タスク」「アプリケーションの設計」「容量計画」「ロードテスト」「監視」の5つです。

ここでは「ワークロードをパーティション分割する」「アフィニティ（同種の処理）を回避する」「バックグラウンドタスクのワークロードを分散する」などいくつかヒントになる考え方がありますが、要点は「なるべく分割し、スケールアウト型にしていくこと」だと内藤氏は言います。

「基本的に一箇所に集中するボトルネックをいかに減らし、水平スケールができる作りになっているかどうかを考えておくと、クラウドならではの水平分散型、スケールアウト型のメリットをより享受でき、パフォーマンス効率をどんどん高めていくことができるでしょう」（内藤氏）

パフォーマンス効率の観点でもアプリケーション設計は重要な鍵を握ります。たとえば、アプリケーションの性質に合わせた適切なデータベースを選択できているか、必要な性能値を満たせているか…といった事柄を考慮し、設計に落とし込むことが後々効いてきます。

また容量計画の項目では、CDNをはじめとするさまざまなスケーリングの手法を具体的に検討します。場合によっては、負荷の急増にオートスケールが間に合わないケースもあるため、「もし傾向が分かっていれば、事前にスケールして裁いておく方が安全です」（内藤氏）

こうした容量計画を見極めるためにも欠かせないのが負荷テストです。内藤氏によると時々「Azureで負荷テストをしても大丈夫ですか？」と聞かれることがあるそうですが、「大丈夫ですからぜひやってみてください。いろいろな種類の負荷テストを実施し、システムの最大負荷はどの程度か、どこがボトルネックになるのかを見極めるために、負荷テストは非常に重要です」と答えているそうです。

このとき、Azureのサービスごとに設けられている制限をきちんと理解しておくことがポイントになります。必要に応じて仮想マシンのスペックを上げたり、別のプランに切り替えるといった手を打つことも視野に入れつつ、事前に負荷テストを実施することが重要です。

そして稼働後は、システムが必要なパフォーマンスを満たしているか、必要に応じて自動スケーリングできるかといった事柄を把握する監視が不可欠です。「CPUやメモリを見るシンプルな監視も重要ですが、システム全体のメトリックスを見て、どんな予兆を表しているのかをきちっと理解した上で、Azure Monitorを使って監視を組み立てていくことが重要です」（内藤氏）

こうした事柄を抑えて設計、実装、運用を進めることによって、クラウドならではのメリットを生かしたパフォーマンス効率に優れたシステムを実現できるでしょう。

文：高橋睦美