WEB問題集
解説
【正解: A】の理由
マイクロサービスはアプリを小さな独立サービス群に分割し、各サービスが独自のデータベース / コード ベース / デプロイ ライフサイクルを持つ設計です。サービスごとに独立してスケール / デプロイ / 技術選択が可能となり、大規模チームでも並列開発でき組織全体の開発速度が向上します。
【他選択肢が違う理由】
- B. 1 ファイル統合: モノリシックの特徴で、マイクロサービスは分割が本質的な性質です
- C. 物理サーバ増設: 物理層は Microsoft 管理の領域で、マイクロサービスとは別の話です
- D. 起動が必ず高速: 個別サービスは速くてもサービス間 API 呼び出しで全体が遅くなる場合もあります
解説
【正解: A】の理由
コンテナはアプリ コードと依存関係 (ライブラリ / ランタイム / OS 環境) を 1 つのイメージにパッケージ化する技術です。これにより「私の PC では動いたが本番では動かない」問題を解決し、開発 / テスト / 本番で同一実行環境を保証でき、ACI / AKS / Container Apps で容易にデプロイできます。
【他選択肢が違う理由】
- B. 物理ハードウェア管理: クラウドでは物理層は Microsoft 管理であり、コンテナの利点とも無関係です
- C. 仮想化を置き換える: コンテナは仮想化を補完する技術で、両者は共存して使われます
- D. コードを書く必要がなくなる: コンテナはコードを実行する仕組みで、コード自体は依然として必要です
解説
【正解: A】の理由
クラウドネイティブは CNCF が定義する設計原則で、マイクロサービス / コンテナ / DevOps / 宣言的 API / 弾力性を組み合わせクラウドの利点を最大化する設計です。Azure では AKS / Container Apps / Functions / Cosmos DB 等のマネージド サービス群がこの設計を実現する基盤となります。
【他選択肢が違う理由】
- B. 物理サーバ最適化: クラウドネイティブは物理ハードウェアの抽象化が前提で、真逆の概念です
- C. 単一モノリシック: 対照的なアーキテクチャで、クラウドネイティブの分散設計とは矛盾します
- D. オンプレ実行: クラウドネイティブはクラウド利用が前提で、オンプレ前提とは相反します
解説
【正解: A】の理由
イベントドリブン アーキテクチャ (EDA) はコンポーネント間通信をイベントで行うパターンで、送信者と受信者が直接結合しない疎結合な設計が特徴です。Azure では Event Grid / Event Hubs / Service Bus が代表で、各コンポーネントを独立してスケール / 変更でき新機能追加もイベント購読で実現できます。
【他選択肢が違う理由】
- B. 同期 / 強結合: EDA とは正反対の特性で、非同期 / 疎結合こそが本質です
- C. 物理ハードウェア自動増設: 物理層と無関係で、EDA はアプリ アーキテクチャの設計パターンです
- D. コード不要: EDA は依然としてコードでロジックを実装する必要があります
解説
【判定: はい】の理由
これは Microsoft Cloud Adoption Framework でも推奨される現実的な段階的移行戦略です。まず Lift & Shift で速やかに Azure VM に移行しクラウドのコスト最適化と運用負荷削減を早期に得て、その後ボトルネックとなる機能から順にマイクロサービス化する漸進的アプローチで、リスクを最小化しつつビジネス価値を継続的に提供できます。
【「いいえ」が違う理由】
Azure Migrate でアセスメント、ASR で移行、AKS / Container Apps / Functions へ段階リファクタが王道です。Strangler Fig パターンを併用すれば新機能を新サービスとして追加し旧モノリスを徐々に置き換えられ、ビッグバン書き直しと比較して失敗リスクが圧倒的に低い戦略となります。
解説
【判定: いいえ】の理由
ビッグバン書き直しは業界で最も失敗確率が高い戦略の 1 つです。既存ビジネス ロジックの再現性、エッジ ケース、データ移行、テスト工数、切替リスクが同時発生し、サービス間連携 / 観測性 / トランザクション境界 / 組織変革すべてが同時進行で破綻リスクが極めて高くなります。
【「はい」が違う理由】
段階的アプローチ (Strangler Fig パターン) や DDD に基づく境界の慎重な検討、Conway の法則を踏まえた組織再編を並行して進める現実解があります。Microsoft も大規模リプラットフォーミングを段階的に進める方針を推奨しており、ビッグバン戦略は推奨されていません。
解説
【判定: はい】の理由
これは Strangler Fig パターンの典型実装で、最大の効果を最小リスクで得られる戦略です。商品検索は EC のパフォーマンスに直結し、独立サービス化でスケールを個別最適化できます。Azure Cognitive Search を活用すれば自前運用なく全文検索 / セマンティック検索 / フィルタリング機能を即時に獲得できます。
【「いいえ」が違う理由】
商品検索の切り出しで成功体験を得たうえで、カート (Cosmos DB + Service Bus)、決済 (Functions)、ユーザー管理 (Microsoft Entra External ID) と段階的に分解できます。各ステップでメトリクスを測定し効果を検証しながら進められるため、リスクを最小化しビジネス価値を最大化できます。
解説
【正解: A】の理由
サーバーレスは顧客がサーバーを意識せず、コードがイベント (HTTP / キュー / スケジュール等) に応じて自動起動し処理を実行するモデルです。Azure Functions / Logic Apps / Container Apps が代表で、実行時間と回数のみで課金され、アイドル時はゼロ課金、突発トラフィックにも自動スケールします。
【他選択肢が違う理由】
- B. 物理サーバが存在しない: 実体としてサーバーは存在しますが、顧客から完全に抽象化されているだけです
- C. OS 管理を顧客が行う: サーバーレスでは OS 管理は完全に Microsoft 側で実施されます
- D. すべて無料: 実行時間や実行回数に応じて課金が発生します
解説
【正解: A, B, C】の理由
クラウドネイティブ アプリの典型的な特徴は、A の機能を独立サービスに分割するマイクロサービス化、B の Docker / Kubernetes ベースで可搬性を確保するコンテナ化、C の自動化されたパイプラインでデプロイされる DevOps / CI/CD です。これに加え 12 Factor App や Observability 三本柱も特徴に挙げられます。
【他選択肢が違う理由】
- D. 物理サーバ専用: クラウドネイティブはハードウェアの抽象化が前提で、真逆の方向性です
- E. モノリシック統合: マイクロサービスの対極にあり、クラウドネイティブの分散設計とは矛盾します
次の各ステートメントを完成させるために、最も適切な選択肢を選んでください。同じ選択肢は 2 回使用できません。
| ステートメント | 選択 |
|---|---|
アプリ コードと依存関係を 1 つのイメージにパッケージ化し、開発 / テスト / 本番で同一に動作させる技術は [ ] である。 正解はコンテナです。Docker をはじめとするコンテナ技術はアプリ / ランタイム / ライブラリを 1 イメージにまとめ、実行環境差異 (私の PC では動いた問題) を解消します。Kubernetes / AKS / Container Apps で本番運用が可能となります。 | |
アプリを複数の独立した小さなサービスに分割し、独立してデプロイ / スケールできる設計パターンは [ ] である。 正解はマイクロサービスです。アーキテクチャは機能ごとに独立したサービスを構築し、各サービスが独自のデータベース / デプロイ ライフサイクル / 技術スタックを持つ設計となります。AKS / Container Apps が代表的な実行基盤です。 | |
サーバーをプロビジョニング / 管理せず、コードがイベント駆動で自動実行され実行分だけ課金される実行モデルは [ ] である。 正解はサーバーレスです。Azure Functions / Logic Apps / Container Apps (consumption plan) で実装でき、アイドル時ゼロ課金 + 自動スケールという特性でイベント駆動ワークロードに最適となり、サーバー管理を Microsoft に完全委任できます。 |