応用情報技術者 2022年 春期 午後 問04
クラウドサービスの活用に関する次の記述を読んで、設問1〜4に答えよ。
J社は、自社のデータセンタからインターネットを介して名刺管理サービスを提供している。このたび、運用コストの削減を目的として、クラウドサービスの活用を検討することにした。
〔非機能要件の確認〕
クラウドサービス活用後も従来のサービスレベルを満たすことを基本方針として、その非機能要件のうち性能・拡張性の要件について表1のとおり整理した。

〔クラウドサービスの概要〕
クラウドサービスの一覧を表2に示す。

〔システム構成の検討〕
現在運用中のサービスは、OS やミドルウェアが PaaS や FaaS の実行環境のものよりも 1 世代古いバージョンである。アプリケーションに改修を加えずに、そのままの OS やミドルウェアを利用する場合、利用するクラウドサービスは IaaS となる。
しかし、①運用コストを抑えるためにオンライン処理は PaaS 又は FaaS を利用することを検討する。PaaS 又は FaaS でのアプリケーションは、WebAPI として実装する。その WebAPI は、ストレージに保存されたスクリプトファイルが d と FW を介して Webブラウザへ配信され、実行されて呼び出される。
バッチ処理については、登録データ数が増加した場合、②PaaS や FaaS を利用することには問題があることから、IaaS を利用することにした。

〔PaaS と FaaS とのクラウドサービス利用料金の比較〕
アプリケーションの実行環境として、PaaS 又は FaaS のどちらのサービスを採用した方が利用料金が低いか、通常時の業務量の場合に掛かる料金を算出して比較する。
クラウドサービス利用料金の試算に必要な情報を表3に整理した。

PaaSの場合、通常時の業務量から、オンライン処理で必要な最小必要台数を求めると、名刺登録処理では5台、名刺参照処理では e 台となる。したがって、1時間当たりの費用は f 円と試算できる。
FaaSの場合、通常時の業務量から1時間当たりのリクエスト数とCPU使用時間を求め、1時間当たりの費用を試算すると、その費用は g 円となる。
試算結果を比較した結果、FaaSを採用した。
〔オンラインレスポンスの課題と対策〕
クラウドサービスを活用したシステムの運用が始まるとすぐに、早朝や深夜にシステムを利用した際、はじめの画面は表示されるが名刺登録や名刺参照を実行すると、データが表示されるまでに10秒以上の時間を要することがある、との課題が報告された。クラウドサービスで提供されている各サービスのログを確認したところ、hの制約が原因であることが判明した。そこで、採用したクラウドサービスを別のものには変更せずに、③ある回避策を施したことで、課題を解消することができた。
設問1:
表2中のa~cに入れる適切な字句を答えよ。
模範解答
a:スケールアウト,,afternoon
b:関数
c:キャッシュ
解説
解答の論理構成
-
[引用]「事前の設定が必要だが、トランザクションの急激な増加に応じて、aできる。」
- “トランザクションの急激な増加”に合わせて台数を自動的に増やす動作は「水平方向の自動拡張」を指します。クラウド分野では “scale out” と呼ばれ、日本語では「スケールアウト」が定訳です。
-
[引用]「FaaSでは、実行したい処理の部分だけをプログラム中でbとして実装すればよい。」
- FaaS(Function as a Service) の “F” は Function を示します。サービス利用者はビジネスロジック単位を “function=関数” として登録し、イベント発生時だけ実行させる方式です。したがって答えは「関数」となります。
-
[引用]「ストレージからの静的コンテンツは、一度読み込むと、更新されるまでcで再利用される。」
- CDN の役割はコンテンツをネットワークの縁辺に保持して再配信し、オリジンサーバの負荷を下げることです。この仕組みは「キャッシュ」と呼ばれます。更新が掛かるまでキャッシュに留め、同一データを高速配信します。
以上より、
a:スケールアウト
b:関数
c:キャッシュ
a:スケールアウト
b:関数
c:キャッシュ
誤りやすいポイント
- 「スケールアップ」と混同しやすい
“スケールアップ”は CPU やメモリを大きくする垂直拡張。設問では “台数を増やす” 水平拡張を求めています。 - FaaS を「モジュール」「スクリプト」などと書いて失点
問題文に “FaaS” とあり、頭文字の “F” = Function まで示唆されています。 - CDN の動作を “レプリケーション” と誤記
複製自体も行いますが、設問は「更新されるまで再利用」という特性にフォーカスしており用語は「キャッシュ」です。
FAQ
Q: スケールアウトは自動も手動も含まれますか?
A: 設問では「事前の設定が必要」という文脈から自動スケールアウトを指しますが、一般には手動で台数を追加する場合もスケールアウトと呼びます。
A: 設問では「事前の設定が必要」という文脈から自動スケールアウトを指しますが、一般には手動で台数を追加する場合もスケールアウトと呼びます。
Q: FaaS と PaaS の最大の違いは何ですか?
A: PaaS は常駐プロセスとしてアプリケーション全体を配置し、常時待機します。FaaS はイベント発火時のみ “関数” が実行され、アイドル時間の課金を抑えられる点が大きな違いです。
A: PaaS は常駐プロセスとしてアプリケーション全体を配置し、常時待機します。FaaS はイベント発火時のみ “関数” が実行され、アイドル時間の課金を抑えられる点が大きな違いです。
Q: CDN キャッシュはどのくらい保持されますか?
A: 問題文では「更新されるまで」とだけ示されています。実運用では TTL(Time To Live) やバージョニングで細かく制御します。
A: 問題文では「更新されるまで」とだけ示されています。実運用では TTL(Time To Live) やバージョニングで細かく制御します。
関連キーワード: スケールアウト, 関数型, キャッシュ, オートスケーリング
設問2:〔システム構成の検討〕について、(1)~(3)に答えよ。
(1)本文中の下線①について、IaaSと比較して運用コストを抑えられるのはなぜか。40字以内で述べよ。
模範解答
PaaSやFaaSでは、OSやミドルウェアのメンテナンスが不要だから
解説
解答の論理構成
-
IaaSの特徴
- 【問題文】「IaaS…ただし、OSやミドルウェアのメンテナンスやサービス利用者側が実施する必要がある。」
- 利用者が保守作業を行うため、人的・時間的コストが発生します。
-
PaaS/FaaSの特徴
- 【問題文】「PaaS…OS、ミドルウェア…はクラウドサービス側が提供する。」
- 【問題文】「FaaS…PaaS同様、アプリケーション実行環境をサービスとして提供する。」
- 基盤の保守をクラウド事業者が担当し、利用者はアプリケーション部分だけに集中できます。
-
運用コストの比較
- IaaSはメンテナンス要員・工数を自社で確保。
- PaaS/FaaSは保守作業が不要=その分のコスト削減。
- よって「IaaSと比較して運用コストを抑えられる」理由は、保守が不要な点にあります。
誤りやすいポイント
- 時間課金(「1台当たり 200円/時間」など)だけを比較してしまい、人的コストを無視する。
- 「PaaS/FaaSは拡張性が高いから安い」と誤記する。拡張性は利点だが直接の費用削減理由ではありません。
- FaaSのみを対象と考え、PaaSとの共通点(基盤保守不要)を見落とす。
FAQ
Q: IaaSでも自動更新機能を使えば差が小さくなるのでは?
A: 自動化しても最終責任は利用者側にあり、動作確認・障害対応などの運用工数は残ります。PaaS/FaaSは基盤層をサービス側が一括管理する点が根本的に異なります。
A: 自動化しても最終責任は利用者側にあり、動作確認・障害対応などの運用工数は残ります。PaaS/FaaSは基盤層をサービス側が一括管理する点が根本的に異なります。
Q: PaaSとFaaSで運用負担に差はありますか?
A: 基盤保守という観点では同等ですが、FaaSは「20分間一度も実行されない場合…応答が10秒以上掛かる場合がある」といった特有制約があり、別の運用配慮が必要です。
A: 基盤保守という観点では同等ですが、FaaSは「20分間一度も実行されない場合…応答が10秒以上掛かる場合がある」といった特有制約があり、別の運用配慮が必要です。
Q: バッチ処理をIaaSにしたのはなぜ?
A: 【問題文】「登録データ数が増加した場合、②PaaS や FaaS を利用することには問題がある」とあり、長時間実行や制約(「1トランザクションの最大実行時間は10分」)に抵触する恐れがあるためです。
A: 【問題文】「登録データ数が増加した場合、②PaaS や FaaS を利用することには問題がある」とあり、長時間実行や制約(「1トランザクションの最大実行時間は10分」)に抵触する恐れがあるためです。
関連キーワード: IaaS, PaaS, FaaS, メンテナンス, 運用コスト
設問2:〔システム構成の検討〕について、(1)~(3)に答えよ。
(2)本文中のdに入れる適切な字句を、表2中のサービスの中から答えよ。
模範解答
d:CDN
解説
解答の論理構成
- 文章中の該当箇所を確認
問題文には「その WebAPI は、ストレージに保存されたスクリプトファイルが d と FW を介して Webブラウザへ配信され、実行されて呼び出される。」とあります。 - 表2で“ストレージ”からコンテンツを配信する役割を持つサービスを特定
表2「CDN」の特徴には「ストレージ、IaaS、PaaS又はFaaSからのコンテンツをインターネットに配信する。ストレージからの静的コンテンツは、一度読み込むと、更新されるまでcで再利用される。」と記載されています。 - 文脈との整合性
・Webブラウザへ配信する経路で FW(ファイアウォール)が並記されているため、FW の前段または後段でキャッシュ配信を行うサービスが必要です。
・「CDN」はまさにストレージの静的コンテンツをインターネット向けに配信し、キャッシュ機能も提供します。 - 他サービスとの比較
- 「FW」はセキュリティ目的であり配信機能を持ちません。
- 「IaaS」「PaaS」「FaaS」は実行基盤であり、静的ファイル配信専用ではありません。
したがって配信役に該当するのは「CDN」しかありません。
- 結論
よって d に入る適切な字句は「CDN」です。
誤りやすいポイント
- 「FW は外部公開部分とブラウザ間の中継だから d に FW を入れたくなる」
→ FW は“防御”であり“配信”ではない点を見落としがちです。 - 「ストレージから直接配信できるのでは?」
→ 問題文は“d と FW を介して”と二つの経路要素を示しており、ストレージ単体では成立しません。 - 「PaaS/FaaS もリクエストを処理するから配信可能では?」
→ 表2の説明で PaaS/FaaS はアプリケーション実行基盤であって静的ファイル配信やキャッシュは触れられていません。
FAQ
Q: CDN は必須なのですか?
A: ストレージの静的コンテンツを高速かつ効率的に Web ブラウザへ届けるために採用されます。キャッシュを活用してレスポンス改善・通信量削減が期待できます。
A: ストレージの静的コンテンツを高速かつ効率的に Web ブラウザへ届けるために採用されます。キャッシュを活用してレスポンス改善・通信量削減が期待できます。
Q: FW と CDN の順序はどちらが先ですか?
A: 問題文では「d と FW を介して」と並列表現のため厳密な順序は指定されていません。ただし実サービスでは FW が外部境界にあり、その後段に CDN(もしくは逆)を設計するケースがあります。
A: 問題文では「d と FW を介して」と並列表現のため厳密な順序は指定されていません。ただし実サービスでは FW が外部境界にあり、その後段に CDN(もしくは逆)を設計するケースがあります。
Q: CDN を使うとどのコストが増えますか?
A: 表2「CDN」の料金欄にある「1万リクエストまで0円、次の1万リクエストごとに10円」「1Gバイトのデータ送信20円/月」が追加で発生します。
A: 表2「CDN」の料金欄にある「1万リクエストまで0円、次の1万リクエストごとに10円」「1Gバイトのデータ送信20円/月」が追加で発生します。
関連キーワード: CDN, WebAPI, ファイアウォール, キャッシュ
設問2:〔システム構成の検討〕について、(1)~(3)に答えよ。
(3)本文中の下線②にある問題とは何か。30字以内で述べよ。
模範解答
バッチ実行時間が上限の10分を超えてしまう問題
解説
解答の論理構成
- バッチ処理はデータ件数が増えるにつれて処理時間が長くなります。本文には「登録データ数が増加した場合、②PaaS や FaaS を利用することには問題がある」とあります。
- PaaS と FaaS には共通の制約として「1トランザクションの最大実行時間は10分」と明記されています。
- 一方、非機能要件(表1)ではバッチ処理の性能目標値として「BIツール連携処理 30分以内」と記載されています。
- つまり、件数が増加してバッチ処理が 10 分を超えると PaaS/FaaS の制約に抵触し、処理が完了できなくなる恐れがあります。
- したがって下線②が示す“問題”は「バッチ実行時間が PaaS/FaaS の 10 分制限を超えてしまう」ことになります。
誤りやすいポイント
- 「30分以内」という性能目標値だけを見て、PaaS/FaaSでも問題ないと判断してしまう。実際にはサービス側の「1トランザクションの最大実行時間は10分」という厳しい制限がある。
- バッチ処理は夜間実行なのでレスポンス要件に関係ないと思い込み、時間上限の影響を見落とす。
- IaaS を選択した理由を「ミドルウェアのバージョン差」と混同し、実行時間制限を答えられない。
FAQ
Q: バッチ処理を複数トランザクションに分割すれば PaaS/FaaS でも可能では?
A: 分割設計は理論上可能ですが、処理を分割・再開できるよう改修が必要となり、今回の「運用コスト削減」という目的と矛盾します。
A: 分割設計は理論上可能ですが、処理を分割・再開できるよう改修が必要となり、今回の「運用コスト削減」という目的と矛盾します。
Q: PaaS と FaaS の「10分制限」は同じだが、どちらかで緩和策はないのか?
A: いずれもサービス仕様で固定されており緩和策はありません。長時間処理は IaaS のような制約のない環境で行うのが一般的です。
A: いずれもサービス仕様で固定されており緩和策はありません。長時間処理は IaaS のような制約のない環境で行うのが一般的です。
Q: 10分制限を回避する他のクラウドサービス例は?
A: マネージドバッチサービスなどがありますが、本問では選択肢に含まれていないため考慮外です。
A: マネージドバッチサービスなどがありますが、本問では選択肢に含まれていないため考慮外です。
関連キーワード: トランザクション制限, バッチ処理, クラウド選定, 非機能要件, 処理時間制約
設問3:
本文中のe~gに入れる適切な数値を答えよ。
模範解答
e:8
f:2,600
g:1,800
解説
解答の論理構成
-
[e] 名刺参照処理の最小必要台数を算出
- 【問題文】「オンライン処理…・名刺参照処理 4,000件/時間」
- 【表3】「PaaS 1台当たりの処理能力…・名刺参照処理 500件/台」
- 必要台数 = 台
よって [e] は 8。
-
[f] PaaS の1時間当たり費用を算出
- 【問題文】「名刺登録処理では5台、名刺参照処理では 8 台となる。」
- 両処理を並行稼働させるため、合計台数 = 5 + 8 = 13 台
- 【表2】「PaaS…料金 1台当たり 200円/時間」
- 費用 = 13 台 × 200円 = 2,600 円
よって [f] は 2,600。
-
[g] FaaS の1時間当たり費用を算出
(1) リクエスト課金- 総リクエスト数 = 1,000件(登録)+ 4,000件(参照)= 5,000件/時間
- 【表2】「1時間当たり10万リクエストまで0円」より課金 0 円
(2) CPU時間課金- 【表3】「名刺登録処理 50ミリ秒/件」→ 1,000件 × 50ms = 50,000ms
- 【表3】「名刺参照処理 10ミリ秒/件」→ 4,000件 × 10ms = 40,000ms
- 合計 CPU 使用時間 = 90,000ms
- 【表2】「CPU使用時間1ミリ秒ごとに0.02円」
- 費用 = 90,000ms × 0.02円 = 1,800 円
よって [g] は 1,800。
誤りやすいポイント
- 必要台数の切上計算を忘れ、 を切捨てて 7 台にしてしまう。
- 「名刺登録処理 5 台」「名刺参照処理 8 台」を排他利用と勘違いし、PaaS費用を 8 台分だけで計算する。
- FaaS の CPU時間を秒や分に換算してから課金単価を掛け、単位を混同する。
- FaaS のリクエスト課金 0 円を見落として、余計な 20 円を加算してしまう。
FAQ
Q: PaaS の合計台数はなぜ 13 台で良いのですか?
A: 【表3】の処理能力は“1台当たり”なので、登録処理 5 台と参照処理 8 台を独立に確保します。両方の負荷が同時に掛かるため、合計 13 台を並列稼働させる想定です。
A: 【表3】の処理能力は“1台当たり”なので、登録処理 5 台と参照処理 8 台を独立に確保します。両方の負荷が同時に掛かるため、合計 13 台を並列稼働させる想定です。
Q: FaaS の CPU課金は秒数に直しても良いですか?
A: 可能ですが、単位変換ミスを起こしやすいです。ms のまま「90,000ms × 0.02円」と掛け算する方が安全です。
A: 可能ですが、単位変換ミスを起こしやすいです。ms のまま「90,000ms × 0.02円」と掛け算する方が安全です。
Q: 5,000リクエストでも将来は課金対象になりますか?
A: 【表2】の「1年の増大率 2.0倍」を考慮すると、約 3 年で 4 万件/時間を超えます。10 万件/時間を超えた時点でリクエスト課金も発生しますので、長期コスト試算が必要です。
A: 【表2】の「1年の増大率 2.0倍」を考慮すると、約 3 年で 4 万件/時間を超えます。10 万件/時間を超えた時点でリクエスト課金も発生しますので、長期コスト試算が必要です。
関連キーワード: スケールアウト, 台数算出, リクエスト課金, CPU時間課金, コールドスタート
設問4:〔オンラインレスポンスの課題と対策〕について、(1)、(2)に答えよ。
(1)本文中のhに入れる適切な字句を、表2中のサービスの中から答えよ。
模範解答
h:FaaS
解説
解答の論理構成
- 症状の整理
本文には「早朝や深夜にシステムを利用した際、…データが表示されるまでに10秒以上の時間を要する」とあります。 - 制約を満たすクラウドサービスの特定
表2のうち、応答遅延に関する具体的な制約を持つものは
「FaaS ― 『20分間一度も実行されない場合、応答が10秒以上掛かる場合がある。』」だけです。
他のサービス(PaaS、CDN など)には同様の10秒超の記載がありません。 - 採用しているオンライン処理基盤の確認
料金比較の結果「FaaS を採用した」と本文で明言されています。したがって、オンライン処理は FaaS 上で稼働しています。 - 結論
遅延の直接原因となり得る「10秒以上掛かる場合がある」という制約を持ち、かつ実際に採用しているサービスは FaaS です。よって
h = FaaS となります。
誤りやすいポイント
- 「PaaS も 1トランザクション最大10分」の記述に目が行き、10秒遅延と誤って結び付ける。実際に10秒遅延を明示するのは FaaS だけです。
- CDN のキャッシュ更新遅延と混同する。CDN は「更新されるまでcで再利用される」とあるだけで、10秒超の応答遅延を示す記述はありません。
- 料金比較の段階で FaaS を採用したことを読み飛ばし、どの基盤が使われているかを取り違える。
FAQ
Q: なぜ PaaS では同じ遅延が起きにくいのですか?
A: PaaS は「配置されたアプリケーションは常時稼働し、リクエストを待ち受ける」と明記されており、長時間アイドル状態になってもコンテナ停止→再起動といった挙動が原則ありません。
A: PaaS は「配置されたアプリケーションは常時稼働し、リクエストを待ち受ける」と明記されており、長時間アイドル状態になってもコンテナ停止→再起動といった挙動が原則ありません。
Q: 回避策③とは一般的に何を指しますか?
A: 代表例は“ウォームアップ”です。定期的にダミーリクエストを送信して FaaS を起動状態に保ち、20分間のアイドルを発生させない方法がよく用いられます。
A: 代表例は“ウォームアップ”です。定期的にダミーリクエストを送信して FaaS を起動状態に保ち、20分間のアイドルを発生させない方法がよく用いられます。
Q: 今回のように非機能要件へ影響する制約はどこで確認すべきですか?
A: 表2のようなサービス仕様書に必ず目を通し、応答時間・同時実行数・最大実行時間などの条項を非機能要件一覧(表1)と突き合わせておくことが重要です。
A: 表2のようなサービス仕様書に必ず目を通し、応答時間・同時実行数・最大実行時間などの条項を非機能要件一覧(表1)と突き合わせておくことが重要です。
関連キーワード: コールドスタート, レスポンス性能, 関数実行環境, 非機能要件
設問4:〔オンラインレスポンスの課題と対策〕について、(1)、(2)に答えよ。
(2)本文中の下線③の回避策とは何か。40字以内で述べよ。
模範解答
20分未満の間隔でFaaS上のアプリケーションを定期的に呼び出す。
解説
解答の論理構成
- 課題の現象
本文には「早朝や深夜に…名刺登録や名刺参照を実行すると、データが表示されるまでに10秒以上の時間を要する」とあります。 - 原因の特定
ログ解析の結果は「『hの制約が原因』」と記載されています。
h に該当するサービスは、表2の FaaS の説明中の
「20分間一度も実行されない場合、応答が10秒以上掛かる場合がある。」
という制約です。この“20分未満の無呼び出しなら遅延なし”という仕様が、深夜などリクエストが来ない時間帯にコールドスタートを発生させ、10秒超の遅延を招いていました。 - 解決策の検討
制約そのものを変えることはできません。しかし“20分間呼び出されなければ遅延が起こる”のであれば、“20分以内に一度呼び出しておく”ことで常にウォームな状態を維持できます。 - 回避策の具体化
したがって「20分未満の間隔でFaaS上のアプリケーションを定期的に呼び出す」ことで、リクエストが少ない時間帯でもコールドスタートを防ぎ、オンラインレスポンスを安定させられると結論付けられます。
誤りやすいポイント
- FaaS ではなく PaaS の制約と誤認してしまう。PaaS には「20分間…」という記述がないため注意。
- 「10分の最大実行時間」ばかりに注目し、遅延原因を処理時間オーバーだと早合点する。
- 定期呼び出しの間隔を“20分”ちょうどに設定してしまう。ネットワーク遅延やジョブ開始誤差を考慮し、安全マージンを取る必要がある。
FAQ
Q: コールドスタートを完全になくす方法はありますか?
A: FaaS で完全に排除するのは難しいですが、今回のようなウォームアップ呼び出しの他、FaaS ではなく常時稼働の PaaS へ移行する方法もあります。
A: FaaS で完全に排除するのは難しいですが、今回のようなウォームアップ呼び出しの他、FaaS ではなく常時稼働の PaaS へ移行する方法もあります。
Q: ウォームアップ呼び出しの実装例は?
A: 監視用スクリプトやクラウドのスケジューラサービスを用い、curl などで対象 API を定期的に GET するだけでも十分です。
A: 監視用スクリプトやクラウドのスケジューラサービスを用い、curl などで対象 API を定期的に GET するだけでも十分です。
Q: コスト増加は問題になりませんか?
A: 表2の FaaS 料金は「1時間当たり10万リクエストまで0円」であり、数分に1回程度のウォームアップ呼び出しは実質無料です。
A: 表2の FaaS 料金は「1時間当たり10万リクエストまで0円」であり、数分に1回程度のウォームアップ呼び出しは実質無料です。
関連キーワード: FaaS, コールドスタート, ウォームアップ, スケジューラ, レスポンス遅延


