適切なコンピューティングサービスの選択

Azureには複数のコンピューティングサービスがあり、それぞれ異なる種類のワークロード、制御レベル、運用モデルに合わせて設計されています。誤ったコンピューティングサービスを選ぶと、不要な複雑さ（低レベルすぎる場合）や、制御不足（抽象化されすぎている場合）につながります。重要な問いは、基盤となるインフラストラクチャをどの程度管理する必要があるかです。このレッスンでは、主要なコンピューティングオプションと、各シナリオに適した選択肢へ導く判断基準を説明します。

Azure Virtual Machinesでは、OS、ランタイム、アプリケーションスタックを完全に制御できます。特定のOSバージョンやカーネル設定を必要とするレガシーアプリケーションを実行する場合、オンプレミスのワークロードを変更せずにリフトアンドシフト移行する場合、システムレベルでカスタムソフトウェアをインストールする場合、または予測可能で固定された構成で24時間365日稼働する永続的なコンピューティングが必要な場合は、VMを使用します。その代わり、運用負担は最も大きくなります。OSのパッチ適用、セキュリティ強化、OSレイヤーの監視をお客様が担当する必要があります。

Virtual Machine Scale Setsは、VMが必要で、さらに需要に応じた自動スケーリングも必要な場合に適しています。ワークロードがステートレス（Webサーバー、APIバックエンド、バッチワーカー）で、すべてのインスタンス上で同じように実行され、需要が変動する場合、VMSSが自然な選択肢です。VMレベルの制御と、自動的な水平スケーリングを組み合わせられます。スタンドアロンVMとVMSSのどちらを選ぶかを決める際の主な判断要素は、通常、ワークロードを単一のインスタンスを超えてスケーリングする必要があるかどうかです。

Azure App Serviceは、Webアプリケーション、REST API、モバイルバックエンドをホスティングするためのPaaSプラットフォームです。Node.js、Python、Java、.NET、PHP、Ruby、またはコンテナーでコードをデプロイすると、Azureがランタイム、OS、パッチ適用、負荷分散、スケーリングを管理します。インフラストラクチャを管理せずに迅速にコードをリリースしたい場合、アプリケーションが標準的なWebアプリのパターンに従う場合、またはOSレベルのカスタマイズが不要な場合は、App Serviceを使用します。App Serviceは、機能とシンプルさのバランスに優れているため、最も人気のあるAzureサービスの1つです。

Azure Container Instances（ACI）を使用すると、インフラストラクチャを管理せずに、クラウドでDockerコンテナーを実行できます。VMもオーケストレーターも必要ありません。ACIは、スケジュールされたバッチジョブ、CI/CDパイプラインのタスク、データ処理スクリプト、開発環境など、短時間だけ実行するオンデマンドのコンテナーワークロードに適しています。コンテナーは数秒で起動し、消費したCPUとメモリの量に対して1秒単位で料金が発生します。ACIには、Kubernetesが提供するサービスディスカバリー、ローリングデプロイ、正常性に基づく再起動などの機能はありません。ACIは、単一コンテナーまたはコンテナーグループの実行環境です。

Azure Kubernetes Service（AKS）は、コンテナー化されたアプリケーションを大規模にオーケストレーションするためのマネージドKubernetes環境です。サービスディスカバリー、ローリングデプロイ、自動修復、高度なスケーリングを必要とする複数のマイクロサービスがある場合は、AKSを使用します。AKSは、Kubernetesコントロールプレーン（APIサーバー、etcd、スケジューラー）を無料のPaaSコンポーネントとして管理し、お客様はワーカーノードVMを管理します。AKSはコンテナーオプションの中で最も運用負担が大きい一方、本番環境のマイクロサービスアーキテクチャに対して最大の機能と柔軟性を提供します。

Azure Functionsは、トリガーに応じて実行される個々の関数を記述する、イベント駆動型のサーバーレスコンピューティングオプションです。トリガーには、HTTPリクエスト、タイマーによるスケジュール、キューに到着したメッセージ、その他のAzureサービスからのイベントなどがあります。実行単位で料金が発生し、1か月あたり最初の100万回の実行は無料です。プラットフォームは、同時実行数0から数千まで自動的にスケーリングします。イベント駆動型の自動化、Webhook、データ変換パイプラインなど、自然に短時間で完了し、トリガーによって実行されるワークロードにはFunctionsを使用します。

次の簡略化された判断ツリーを使用してください。OSを完全に制御する必要がありますか？ → VMまたはVMSS。大規模なコンテナー化ワークロードですか？ → AKS。単一コンテナーで、短時間だけ実行しますか？ → ACI。OS管理なしでWebアプリまたはAPIを実行しますか？ → App Service。イベント駆動で、短時間だけ実行するコードですか？ → Azure Functions。このリストの下に進むほど、管理するインフラストラクチャは少なくなり、より迅速にデプロイできる一方で、実行環境に対する制御は少なくなります。要件を満たす中で、最も高い抽象化レベルを選択してください。

実際のアーキテクチャでは、複数のコンピューティングオプションを組み合わせて使用することがよくあります。たとえば、顧客向けWebアプリケーションにはApp Service、イベント駆動型の注文処理にはAzure Functions、社内マイクロサービスプラットフォームにはAKS、リファクタリングできないレガシーERPシステムにはVMを使用する企業が考えられます。Azureの統合管理ツール（ポータル、CLI、ARMテンプレート、Azure Monitor）は、すべてのコンピューティングサービスで一貫して機能するため、複数のコンピューティングサービスを組み合わせたアーキテクチャも、単一のコントロールプレーンから管理できます。

コンピューティング オプションによってコストは大きく異なります。VM — アイドル状態であっても、VM のサイズに応じて 1 時間単位で課金されます（割り当て解除した場合を除きます）。App Service — App Service プランの SKU に応じて 1 時間単位で課金されますが、1 つのプランで複数のアプリを追加料金なしで共有できます。ACI — 実際に使用した CPU とメモリに対して 1 秒単位で課金され、アイドル時のコストは発生しません。Azure Functions (Consumption Plan) — 実行回数と実行時間 1 秒ごとに課金され、非常に充実した無料枠があります。負荷が断続的に発生するワークロードでは、サーバーレス オプションがほぼ常に最もコスト効率に優れています。常時稼働する安定したワークロードでは、予約済みの VM や App Service プランのほうが安価になる場合があります。

コンピューティング サービスごとにSLA の保証が異なります。単一の VM (Premium SSD): 99.9%。可用性セット内の VM: 99.95%。可用性ゾーンに分散した VM: 99.99%。App Service (Standard レベル以上): 99.95%。Azure Functions (Consumption Plan): 99.95%。AKS: API サーバーの稼働率 99.95%（有料レベルの場合）。複数のコンポーネントで構成されるアーキテクチャの複合 SLA は、個々の SLA を掛け合わせて算出します。たとえば、App Service (99.95%) と Azure SQL (99.99%) を接続した場合、複合 SLA は約 99.94% になります。

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認しましょう。

このレッスンでは、Azure には VM、VMSS、App Service、ACI、AKS、Functions など複数のコンピューティング オプションがあり、それぞれ異なるワークロードの特性や制御要件に適していること、運用負担を最小限に抑えるため、要件を満たす範囲で最も抽象度の高いレベルを選択するのが一般的な原則であること、そして実際のアーキテクチャでは、Azure の統合管理レイヤーを通じて複数のコンピューティング サービスを連携させることが多いことを学びました。次は Azure のストレージ サービスについて学習し、まず Storage Accounts から始めます。