WEB問題集
解説
【正解: B】の理由
高可用性 (HA) はゾーン障害やハードウェア故障などの通常障害でサービスを止めない冗長化設計で、Availability Zone 分散や Load Balancer + 複数インスタンス構成が代表例です。Disaster Recovery (DR) はリージョン規模の広域災害時に別リージョンへ復旧する計画で、RTO / RPO の設定と Azure Site Recovery によるレプリケーションが核となります。HA は「継続させる仕組み」、DR は「復旧計画」と整理できます。
【他選択肢が違う理由】
- D. HA と DR は同義: 守備範囲もコストも異なり、同義ではありません。HA はリージョン内、DR はリージョン横断が基本です
- A. 説明が逆: HA = 同一リージョン冗長、DR = 別リージョン復旧が一般的な役割分担で、本選択肢は逆です
- C. HA 無料 / DR 有償: いずれも構成によりコストが発生し、HA と DR で課金体系が分かれているわけではありません
【参考】
解説
【正解: C】の理由
水平スケーリング（Scale Out / In）と垂直スケーリング（Scale Up / Down）は、拡張の方向が異なります。
- 水平スケーリングはインスタンスの台数を増減する方式で、VMSS や App Service のインスタンス数調整が典型例です。負荷分散と可用性向上を同時に得られ、クラウドの弾力性と相性が良い手法です。
- 垂直スケーリングは同一インスタンスの CPU・メモリ・ディスクなどのスペックを増減する方式で、多くの場合再起動を伴います。
- 単一台の性能上限に縛られる垂直に対し、水平は台数を足して伸ばせるため、クラウドでは水平を優先するのがベスト プラクティスです。
【他選択肢が違う理由】
- B. 両者は同義であり置換可能: 異なる戦略と用途を持ち、互換ではありません
- D. 水平はオンプレ専用、垂直はクラウド専用: どちらもクラウド / オンプレ両方で利用されます
- A. 垂直スケーリングはディスク容量のみ増加できる: 垂直は CPU / メモリ / ディスクすべてを対象とし、ディスクに限定されません
【参考】
解説
【正解: はい】の理由
これは FinOps Foundation が提唱するフレームワークのうち、可視化を担う Inform フェーズの典型的な実装です。Azure Cost Management のダッシュボードで全サブスクリプションのコストを可視化し、タグを使って部門別に実コストを分解して毎月レビューすることは、あらゆるコスト最適化活動の出発点になります。何にいくらかかっているかを継続的に把握できて初めて、無駄の特定や最適化の意思決定が可能になるためです。タグによる部門別の分解は、各部門に自分たちのコストを意識させ、コスト オーナーシップを醸成する効果もあります。CFO が求める FinOps 体制の導入と継続的なコスト最適化の基盤として不可欠なステップであり、設問の目的に沿った適切な取り組みです。
【不正解の選択肢の場合】
Cost Analysis のフィルタや Workbooks / Power BI コネクタで CFO 向けダッシュボードも容易に作成できます。タグ強制は Azure Policy の Require a tag and its value で Audit / Deny を整備すれば運用可能で、FinOps 体制構築の基盤フェーズとして要件を満たします。
【参考】
解説
【正解: いいえ】の理由
Azure Advisor のコスト推奨は、節約できる想定金額とともに具体的な最適化の機会を提示してくれる、最も実行しやすい改善策の 1 つです。未使用 VM の停止、過剰にサイズを割り当てたリソースの適正化 (Right-sizing)、Reservations の購入候補、Spot への切り替え候補などが自動的に洗い出されます。これを四半期ごとに無視する方針は、継続的なコスト最適化を求める FinOps の考え方の根本に反します。せっかく提示された削減機会を見過ごし続ければ、無計画な拡大で膨らんだコストがそのまま放置され、CFO が求める最適化はまったく進みません。むしろ Advisor の推奨を定期的にレビューして実施に落とし込むべきであり、これを無視する解決策では設問の目的を達成できません。
【不正解の選択肢の場合】
推奨を確認しないと累積的コスト超過が積み上がり、年間で数百万円から数千万円規模の機会損失が発生します。FinOps Foundation は月次から週次での Advisor 確認 / 評価 / 実装を推奨しており、無視は最適化要件を満たしません。
【参考】
解説
【正解: はい】の理由
これは FinOps における最適化 (Optimize) フェーズの典型的なベスト プラクティスです。安定して稼働し続ける本番ワークロードには Reservations や Savings Plan を購入し、一定期間の利用をコミットすることで大幅な割引を得られます。常時起動が不要な開発環境には Auto-shutdown を設定し、夜間や休日のアイドル時間の課金を削減できます。中断が許容されるバッチ処理には Spot VM を使えば、余剰キャパシティを安価に利用でき最大 90% 近い割引が可能です。ワークロードの特性ごとに最適な購入・稼働形態を使い分けることで、全体で大きなコスト削減を実現できます。継続的なコスト最適化を求める CFO の要件に沿った適切な取り組みであり、目的を満たします。
【不正解の選択肢の場合】
単発実施ではなく、Policy で Auto-shutdown 必須化やタグ強制、Reservations 定期見直し、Spot 利用率モニタリングを運用プロセスに組み込めば組織文化として定着します。月 5,000 万円規模なら年間数千万円の削減効果が期待でき、要件を満たします。
【シリーズ全体の正解一覧】
| 問 | ステートメント | 正解 |
|---|---|---|
| 問1 | Azure Cost Management のダッシュボードで全 Subscription を可視化し、Tag ベースで部門別の実コストを毎月レビューする。 | はい |
| 問2 | Azure Advisor のコスト推奨を四半期ごとに無視する。 | いいえ |
| 問3 | 安定稼働する本番ワークロードに Reservations / Savings Plan を購入し、開発 / バッチには Auto-shutdown と Spot を組み合わせる。 | はい |
【参考】
解説
【正解: D】の理由
マネージド サービスでは、インフラの運用管理を Microsoft が代行するため、利用者は運用負荷を大幅に削減できます。
- OS やランタイムのパッチ適用、自動バックアップ、スケーリング、可用性設計（冗長化・フェイルオーバー）をプラットフォーム側が担います。
- Azure SQL Database / App Service / AKS / Functions などが代表例で、利用者はアプリやデータといった上位レイヤーに集中できます。
- 専任の運用チームやハードウェア管理が不要になり、限られた人員でもコア事業に注力できる点が最大の利点です。
【他選択肢が違う理由】
- A. カスタム OS が使える: マネージド サービスでは OS は Microsoft 標準のみで、顧客は変更できません
- C. ハードウェア直接交換: 物理層は Microsoft 管理で、顧客が触れることはありません
- B. 料金ゼロ: マネージド サービスは利用料が発生し、無料ではありません
【参考】
| ステートメント | 選択 |
|---|---|
障害から回復し稼働を維持する能力 障害から回復して稼働を維持し、期待どおり動作し続ける能力が信頼性。 | |
コストと性能を事前に見通せること コストと性能を事前に見通し計画できる特性が予測可能性。 | |
多層防御でデータとシステムを保護すること 多層防御によりデータとシステムを脅威から保護することがセキュリティ。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| 障害から回復し稼働を維持する能力 | 信頼性 |
| コストと性能を事前に見通せること | 予測可能性 |
| 多層防御でデータとシステムを保護すること | セキュリティ |
【ポイント】
クラウドを使う利点には、性能面だけでなく運用品質に関わる特性も含まれます。信頼性 (Reliability) は、障害が発生しても回復し、システムが期待どおりに稼働を維持できる能力で、地理的に分散した Azure のインフラや冗長構成によって高い信頼性が得られます。予測可能性 (Predictability) は、性能とコストの両面を事前に見通せる特性で、性能面では必要なリソース量を計画的に確保できること、コスト面では使用量に基づいて費用を前もって見積もれることを指し、予算計画やキャパシティ計画を容易にします。セキュリティ (Security) は、多層防御 (Defense in Depth) の考え方でデータやシステムを脅威から保護することで、物理・ネットワーク・ID など複数の層で対策が講じられ、責任共有モデルのもとで守られます。障害からの回復力なのか、性能とコストの見通しなのか、脅威からの保護なのかという観点で特性を選び分けます。
【参考】
解説
【正解: D】の理由
クラウドネイティブ アーキテクチャは、クラウドの弾力性やスケーラビリティを最大限に引き出すことを目的とした設計手法で、CNCF (Cloud Native Computing Foundation) が原則を定義しています。中心となるのは、機能を独立したサービスに分割するマイクロサービス、可搬性の高いコンテナ、迅速な提供を支える DevOps や CI/CD、インフラを宣言的に扱う API、そして負荷に応じて伸縮する弾力性です。Azure では AKS や Container Apps、Functions、Cosmos DB といったマネージド サービス群がこの設計を実現する基盤となります。これらの要素を組み合わせた選択肢 D が正しい説明です。
【他選択肢が違う理由】
- C. 物理サーバ最適化: クラウドネイティブは物理ハードウェアの抽象化が前提で、真逆の概念です
- B. 単一モノリシック: 対照的なアーキテクチャで、クラウドネイティブの分散設計とは矛盾します
- A. オンプレ実行: クラウドネイティブはクラウド利用が前提で、オンプレ前提とは相反します
【参考】
- VMSS オートスケール (CPU しきい値 + スケジュール)
- 常時 20 倍の固定キャパシティ
- ピーク期間のみ 1 年 Reservations
解説
【正解マッチング】
| 項目 | 正しいカテゴリー |
|---|---|
| 通常時は最小構成、ピーク前後で自動拡張しコスト効率を両立する最適解 | VMSS オートスケール (CPU しきい値 + スケジュール) |
| ピーク以外の 50 週間もリソースが遊休し課金され続ける不適解 | 常時 20 倍の固定キャパシティ |
| 1 年継続を前提とするため、年 2 回の突発ピークには根本的に不適な購入 | ピーク期間のみ 1 年 Reservations |
【ポイント】
年 2 回・各 1 週間のピークがある EC サイトでは、コスト効率を重視して弾力性を活かします。VMSS のオートスケールは、CPU などのメトリクスのしきい値で通常時は最小構成に縮小し、ピーク前後で自動的にインスタンスを増減します。事前にピーク日時が判るならスケジュール ベースのスケール アクションを併用でき、需要変動にコスト効率よく追従する最適解です。常時 20 倍のキャパシティを保有する固定構成は、ピーク以外の約 50 週間 (年間の 96%) でリソースの大半が遊休するのに課金は続き、クラウドの弾力性を活かさず従来の CapEx 思考に逆戻りするため不適です。ピーク期間のみ 1 年 Reservations を購入する方式は、Reservations が 1〜3 年の継続稼働を前提とし対象期間中は常時課金されるため、年 2 回の突発ピークには根本的に不適です。自動追従の最適解か、遊休課金か、前提違いの購入かで対応付けます。
【参考】
解説
【正解: B】の理由
Azure における規制コンプライアンスは、Microsoft と顧客が責任を分担する責任共有モデルを前提に、複数の仕組みを組み合わせて担保するのが標準的なアプローチです。まず Service Trust Portal から、Microsoft がクラウド基盤について取得している ISO 27001 / SOC / HIPAA / FedRAMP などの第三者認定書や監査レポートを入手し、基盤側の準拠を確認します。次に顧客の責任範囲では、Azure Policy を用いて自社が守るべきルールを Deny や Audit の効果で強制し、逸脱した構成を防ぎます。さらに Microsoft Defender for Cloud の規制コンプライアンス ダッシュボードで各基準への準拠状況をスコアとして継続的に評価し、改善アクションを追跡します。この三層構成で認定の確認、統制の強制、継続的な評価を組み合わせるのが代表的な進め方です。
【他選択肢が違う理由】
- D. 規制無視: 罰金や業務停止など法的リスクが極大化し許容できません
- A. 紙ベース手動: 大規模クラウド環境では追跡が破綻し現実的ではありません
- C. Microsoft が肩代わり: 責任共有モデル上、顧客側の構成と運用責任は残ります