🚀 応用情報から学ぶクラウドアーキテクチャ設計。コスト・性能・運用のトレードオフを「名刺管理サービス」を例に紐解く
～ IaaS / PaaS / FaaS の特性理解からコスト計算、実務上の課題まで ～
問4：クラウドサービスの活用に関する問題
J社は自社のデータセンタからインターネットを介して名刺管理サービスを提供している。このたび、運用コストの削減を目的として、クラウドサービスの活用を検討することにした。
［非機能要件の確認］性能・拡張性の要件（抜粋）
| 中項目 | メトリクス（指標） |
|---|---|
| 通常時の業務量 | ・名刺登録：1,000件／時（5MB／件） ・名刺参照：4,000件／時（2MB／件） |
| 性能目標値 | ・登録：10秒以内（遵守率90%） ・参照：3秒以内（遵守率95%） |
［システム構成案］
検討されたシステム構成案の概要図です。
💡 検討のポイント：
- 下線①： 運用コストを抑えるため、オンライン処理には PaaS または FaaS を検討。
- 下線②： バッチ処理は登録データ増大時の実行時間制限の問題から IaaS を継続利用。
設問のハイライト
本問では、以下の計算と知識が問われます：
- PaaSとFaaSの時間あたり利用料金の比較計算。
- FaaS特有の制約（コールドスタート）によるレスポンス遅延の原因特定。
- CDNを利用した静的コンテンツ配信の仕組み（キャッシュ）。
1. クラウドサービスの種別と特徴まとめ ☁️
名刺管理サービスなどのITビジネスにおいて、どのサービス階層を選択するかは「運用コスト」と「柔軟性」のトレードオフです。
| サービス | 主な特徴と責任範囲 | 制約・注意点 |
|---|---|---|
| IaaS | OS、ミドルウェア、言語を自由に選択・設定可能。 | OS等のメンテナンスを利用者側で行う必要がある。 |
| PaaS | 実行環境が提供され、アプリを配置するだけで稼働。自動スケール可。 | 1トランザクションの最大実行時間に制限あり（例：10分）。 |
| FaaS | 処理（関数）単位で実装。イベント駆動で自動スケール。 | 20分以上未実行だと応答に10秒以上（コールドスタート）かかる。 |
| CDN | 静的コンテンツをキャッシュし、近接サーバから高速配信。 | コンテンツが更新されるまで古いデータを再利用（キャッシュ）する。 |
2. 【実務ケース】具体的な使用状況と選定理由 💡
オンライン処理（名刺登録・参照）
選定：PaaS または FaaS
- 理由： OSやミドルウェアのパッチ適用などの運用コストを削減するため。
- 実装： Web APIとして実装。CDNやFWを介してブラウザへ配信される構成が一般的。
バッチ処理（BIツール連携など）
選定：IaaS
- 理由： PaaS/FaaSには「10分以内」という実行制限があるため。大量データの集計などは制限時間を超えるリスクがあり不向き。
3. 料金計算のシミュレーション（試験頻出！） 🧮
通常時の業務量に基づき、1時間あたりのコストを比較します。
- 名刺登録：1,000件 ÷ 200件/台 ＝ 5台
- 名刺参照：4,000件 ÷ 500件/台 ＝ 8台
- 合計：(5 + 8)台 × 200円 ＝ 2,600円/時
- リクエスト：5,000件（10万件以下なので 0円）
- CPU時間（登録）：1,000件 × 50ms ＝ 50,000ms
- CPU時間（参照）：4,000件 × 10ms ＝ 40,000ms
- 合計：90,000ms × 0.02円 ＝ 1,800円/時
⇒ 結論：FaaSの方が圧倒的に低コスト！
4. オンラインレスポンスの課題と回避策 ⚠️
課題：深夜・早朝の激しい遅延
FaaSには「20分間一度も実行されない場合、起動に10秒以上かかる」というコールドスタートの制約があります。利用者の少ない時間帯にこの問題が顕在化します。
回避策：ウォームアップ（定期呼び出し） 🛠️
「20分未満の間隔で、FaaS上のアプリケーションを定期的に呼び出す（ダミーリクエストを送る）」ことで、実行環境を常に「温まった（Warm）」状態に維持します。
🎯 本章のまとめ
- クラウドの利点： OS/ミドルウェアのメンテ不要による運用コスト削減。
- PaaS/FaaSの壁： 実行時間制限（10分）があるため、重いバッチはIaaSで行う。
- FaaSの料金： 処理した件数とCPU時間に比例。小規模・中規模ならPaaSより安い。
- CDNの役割： 静的コンテンツをキャッシュして配信し、サーバ負荷を軽減。
- FaaSの注意点： 無操作時間が続くと遅くなるため、定期呼び出しで回避する。
📝 最後に：試験対策のポイントと周辺知識
お疲れ様でした！今回の問題は、単なる用語の暗記ではなく、「各クラウドサービスの制約を理解し、実際の業務量に合わせてコストと性能を天秤にかける」という、実務に近い思考力が問われる良問でした。
最近の応用情報技術者試験では、DX推進の流れを受け、サーバーレス(FaaS)やマイクロサービス、コンテナ技術(Docker/K8s)に関連する出題が増加しています。「疎結合」なシステム設計のメリットを意識しておきましょう。
本問の「コールドスタート」対策は、AWS LambdaやGoogle Cloud Functionsを利用する現場でも必須の知識です。また、Shared Responsibility Model（責任共有モデル）の概念も併せて押さえると、セキュリティ分野の対策にもなります。
応用情報の午後試験では、問題文の中に必ずヒントが隠されています。特に「制約事項」や「非機能要件」の表は、解答の根拠となる数値の宝庫です。計算ミスに気をつけつつ、今回学んだ「クラウドの使い分け」を武器に合格を勝ち取りましょう！
🎯 試験直前チェック！記述解答の「定型パターン」
※問題文の文脈に合わせ、「〜から」「〜ため」で調整して使用してください。
- OSやミドルウェアのメンテナンスが不要になるから
- ハードウェアの保守や資産管理の負担を軽減できるから
- 需要の変動に合わせてリソースを柔軟に変更できるから
- 一定期間実行がないと、インスタンスの起動に時間を要する（コールドスタート）
- 1トランザクションの実行継続時間に上限があるから
- メモリやディスク容量などのリソース割り当てに制限があるから
- オリジンサーバへのアクセス集中を回避し、負荷を軽減するため
- 地理的に近いサーバから配信し、レスポンスタイムを短縮するため
「なぜその構成にするのか？」と問われたら、「[機能的制約]により[目標値]を満たせない問題を解消するため」という構文を意識すると、部分点を逃しにくくなります。
🎴 クラウド・システム構成 暗記カード
マウスを乗せるか、カードをタップして正解を確認！
⚠️ 【午後対策】ひっかけ・一問一答チェック
問題をクリックして、自分の考えと「ひっかけポイント」を照らし合わせてください。
📘 登場用語・網羅的解説リスト（完全版）
1. クラウドサービス・配信基盤
1-1. IaaS (Infrastructure as a Service)
仮想サーバやネットワークなどのインフラを提供。OSやミドルウェアを自由に設定できる。本問では、「古いOSバージョンを使い続けたい」「10分を超えるバッチ処理を実行したい」場合に選定される。
1-2. PaaS (Platform as a Service)
アプリの実行環境を丸ごと提供。OS管理は不要。本問では「運用コスト削減」の手段として登場。トランザクション増加に対しては「事前の設定」によるスケールアウトで対応する。
1-3. FaaS (Function as a Service)
関数単位で処理を実装する「サーバーレス」の代表格。CPU使用時間とリクエスト数で課金されるため、本問の試算では「最も低コスト」な結果となった。
1-4. CDN (Content Delivery Network)
キャッシュサーバを分散配置し、静的コンテンツを高速配信する仕組み。ストレージ、PaaS、FaaSの前段に配置し、オリジンサーバの負荷を軽減する。
1-5. ストレージ
HTML、CSS、JSファイル（静的コンテンツ）や、アプリ用のファイルを保存する場所。CDNの配信元（オリジン）として利用される。
2. ネットワーク・性能管理
2-1. FW (ファイアウォール)
不正アクセスを防ぐための関門。本問のシステム案では、Web APIへのリクエストや静的コンテンツの配信はすべてFWを経由する構成になっている。
2-2. スケールアウト
サーバ台数を増やすことで処理能力を拡張すること。PaaSやFaaSは水平スケーリング（スケールアウト）が得意。対義語は単体の性能を上げる「スケールアップ」。
2-3. キャッシュ
一度読み込んだデータを再利用するために一時保存すること。CDNの根幹機能。データ更新時には古いキャッシュが残る（キャッシュヒット）ことに注意が必要。
2-4. コールドスタート
FaaS特有の課題。20分など一定時間未実行の際、環境の起動に時間がかかる現象。「早朝・深夜に遅い」という課題の主要因。
2-5. L3SW等 (レイヤ3スイッチ)
ネットワーク層（IPアドレス）でルーティングを行う機器。システム構成図ではCDNの背後に位置し、各処理サーバへ通信を振り分ける。
3. 業務要件・評価指標
3-1. 非機能要件
可用性、性能、拡張性、保守性など、ビジネスロジック以外のシステム要件。本問では「性能・拡張性」にフォーカスしている。
3-2. メトリクス
「1,000件／時間」「5Mバイト／トランザクション」など、性能を評価するための定量的な指標。
3-3. オンラインレスポンス
リクエストを投げてから結果が返るまでの時間。本問では登録10秒以内、参照3秒以内という目標値が設定されている。
3-4. バッチレスポンス
一括処理（バッチ）の開始から終了までの時間。BIツール連携は「30分以内」が目標だが、クラウド側の実行時間制限（10分）がボトルネックとなる。
3-5. 遵守率
レスポンスタイムの目標を何％の確率で満たすべきかを示す指標。ピーク時を考慮して100％ではなく90％等に設定される。
4. 実装・アーキテクチャ
4-1. Web API
HTTP通信を介して、ブラウザのスクリプト等から機能を呼び出す仕組み。PaaSやFaaSでのオンライン処理はこの形式で実装される。
4-2. 関数 (Function)
FaaSにおけるプログラムの最小単位。リクエストの解析やレスポンスの送信はフレームワークに任せ、「実行したい処理の部分だけ」を実装したもの。
4-3. ミドルウェア
OSとアプリの間で動作するソフトウェア（WebサーバやDBMSなど）。クラウドサービス（PaaS/FaaS）ではこれらがサービス側に内包されるため、メンテナンスが不要になる。
4-4. トランザクション
不可分な一連の処理単位。本問では、PaaSやFaaSにおける「1回のリクエストに対する最大実行時間」を指す際に使われている。
4-5. 静的コンテンツ
HTML、CSS、JavaScriptファイルなど、サーバ側で計算せずそのまま配信するファイル。CDNでのキャッシュ効率が非常に高い。
5. ビジネス・分析関連
5-1. BI (Business Intelligence)
蓄積したデータを分析し、経営判断に活用すること。本問ではこの分析のために1日1回、名刺データをバッチ処理で連携している。
5-2. 業務量増大度
将来の利用者増を見込んだ予測。本問では「1年で2倍」と設定されており、これに耐えられる拡張性（スケールアウト性能）が求められる。
5-3. CPU使用時間
サーバのCPUが実際に処理を動かした時間。FaaSの課金基準。オンラインレスポンス（応答時間）とは異なり、純粋な演算時間を指す。
5-4. メンテナンスコスト
OSのパッチ適用、ライセンス更新、ハードウェア保守にかかる手間と費用。IaaSからPaaS/FaaSへ移行する最大のメリット。
5-5. スクリプトファイル
ブラウザ側で実行されるJavaScriptなどのコード。ストレージからCDN経由で配信され、ユーザーのブラウザ上でAPI（PaaS/FaaS）を呼び出す役割を担う。
この記事へのコメント