応用情報技術者 2022年 春期 午後 問04

解答の論理構成

1. [引用]「事前の設定が必要だが、トランザクションの急激な増加に応じて、aできる。」
   • “トランザクションの急激な増加”に合わせて台数を自動的に増やす動作は「水平方向の自動拡張」を指します。クラウド分野では “scale out” と呼ばれ、日本語では「スケールアウト」が定訳です。
2. [引用]「FaaSでは、実行したい処理の部分だけをプログラム中でbとして実装すればよい。」
   • FaaS(Function as a Service) の “F” は Function を示します。サービス利用者はビジネスロジック単位を “function＝関数” として登録し、イベント発生時だけ実行させる方式です。したがって答えは「関数」となります。
3. [引用]「ストレージからの静的コンテンツは、一度読み込むと、更新されるまでcで再利用される。」
   • CDNの役割はコンテンツをネットワークの縁辺に保持して再配信し、オリジンサーバの負荷を下げることです。この仕組みは「キャッシュ」と呼ばれます。更新が掛かるまでキャッシュに留め、同一データを高速配信します。

誤りやすいポイント

• 「スケールアップ」と混同しやすい
  “スケールアップ”はCPUやメモリを大きくする垂直拡張。設問では “台数を増やす” 水平拡張を求めています。
• FaaSを「モジュール」「スクリプト」などと書いて失点
  問題文に “FaaS” とあり、頭文字の “F” ＝ Functionまで示唆されています。
• CDNの動作を “レプリケーション” と誤記
  複製自体も行いますが、設問は「更新されるまで再利用」という特性にフォーカスしており用語は「キャッシュ」です。

FAQ

解答の論理構成

1. IaaSの特徴
   • 【問題文】「IaaS…ただし、OSやミドルウェアのメンテナンスやサービス利用者側が実施する必要がある。」
   • 利用者が保守作業を行うため、人的・時間的コストが発生します。
2. PaaS／FaaSの特徴
   • 【問題文】「PaaS…OS、ミドルウェア…はクラウドサービス側が提供する。」
   • 【問題文】「FaaS…PaaS同様、アプリケーション実行環境をサービスとして提供する。」
   • 基盤の保守をクラウド事業者が担当し、利用者はアプリケーション部分だけに集中できます。
3. 運用コストの比較
   • IaaSはメンテナンス要員・工数を自社で確保。
   • PaaS／FaaSは保守作業が不要＝その分のコスト削減。
   • よって「IaaSと比較して運用コストを抑えられる」理由は、保守が不要な点にあります。

誤りやすいポイント

• 時間課金（「1台当たり200円／時間」など）だけを比較してしまい、人的コストを無視する。
• 「PaaS／FaaSは拡張性が高いから安い」と誤記する。拡張性は利点だが直接の費用削減理由ではありません。
• FaaSのみを対象と考え、PaaSとの共通点（基盤保守不要）を見落とす。

FAQ

解答の論理構成

1. 文章中の該当箇所を確認
   問題文には「そのWebAPIは、ストレージに保存されたスクリプトファイルが d とFWを介してWebブラウザへ配信され、実行されて呼び出される。」とあります。
2. 表2で“ストレージ”からコンテンツを配信する役割を持つサービスを特定
   表2「CDN」の特徴には「ストレージ、IaaS、PaaS又はFaaSからのコンテンツをインターネットに配信する。ストレージからの静的コンテンツは、一度読み込むと、更新されるまでcで再利用される。」と記載されています。
3. 文脈との整合性
   ・Webブラウザへ配信する経路でFW（ファイアウォール）が並記されているため、FWの前段または後段でキャッシュ配信を行うサービスが必要です。
   ・「CDN」はまさにストレージの静的コンテンツをインターネット向けに配信し、キャッシュ機能も提供します。
4. 他サービスとの比較
   • 「FW」はセキュリティ目的であり配信機能を持ちません。
   • 「IaaS」「PaaS」「FaaS」は実行基盤であり、静的ファイル配信専用ではありません。
     したがって配信役に該当するのは「CDN」しかありません。
5. 結論
   よって d に入る適切な字句は「CDN」です。

誤りやすいポイント

• 「FWは外部公開部分とブラウザ間の中継だから d にFWを入れたくなる」
  → FWは“防御”であり“配信”ではない点を見落としがちです。
• 「ストレージから直接配信できるのでは？」
  → 問題文は“d とFWを介して”と二つの経路要素を示しており、ストレージ単体では成立しません。
• 「PaaS／FaaSもリクエストを処理するから配信可能では？」
  → 表2の説明でPaaS／FaaSはアプリケーション実行基盤であって静的ファイル配信やキャッシュは触れられていません。

FAQ

解答の論理構成

1. バッチ処理はデータ件数が増えるにつれて処理時間が長くなります。本文には「登録データ量が増加した場合、②PaaSやFaaSを利用することには問題がある」とあります。
2. PaaSとFaaSには共通の制約として「1トランザクションの最大実行時間は10分」と明記されています。
3. 一方、非機能要件（表1）ではバッチ処理の性能目標値として「BIツール連携処理30分以内」と記載されています。
4. つまり、件数が増加してバッチ処理が10分を超えるとPaaS／FaaSの制約に抵触し、処理が完了できなくなる恐れがあります。
5. したがって下線②が示す“問題”は「バッチ実行時間がPaaS／FaaSの10分制限を超えてしまう」ことになります。

誤りやすいポイント

• 「30分以内」という性能目標値だけを見て、PaaS／FaaSでも問題ないと判断してしまう。実際にはサービス側の「1トランザクションの最大実行時間は10分」という厳しい制限がある。
• バッチ処理は夜間実行なのでレスポンス要件に関係ないと思い込み、時間上限の影響を見落とす。
• IaaSを選択した理由を「ミドルウェアのバージョン差」と混同し、実行時間制限を答えられない。

FAQ

解答の導き方

1. PaaSの必要台数（各処理で独立に計算し、台数は端数を切り上げる）

• 名刺登録処理の必要台数
  PaaS 1台で処理できる件数が「名刺登録処理200件／台」であるため、必要台数は
  $\lceil 1,000÷200\rceil =\lceil 5\rceil =5$ 台。
• 名刺参照処理の必要台数
  PaaS 1台で「名刺参照処理500件／台」であるため、必要台数は
  $\lceil 4,000÷500\rceil =\lceil 8\rceil =8$ 台。
  したがって e = 8。

1. PaaSの1時間当たり費用
   PaaSの料金は「1台当たり200円／時間」です。必要台数は登録5台と参照8台を合計して $5+8=13$ 台（両処理とも同一時間帯に発生する可能性があるため合算します）。よって1時間当たり費用は
   $13\times 200=2,600$ 円。
   したがって f = 2,600。
2. FaaSの1時間当たり費用

• リクエスト数：登録と参照の合計で $1,000+4,000=5,000$ リクエスト／時間です。FaaSのルールで「1時間当たり10万リクエストまで0円」なのでリクエスト数に対する課金は0円になります。
• CPU使用時間の課金：表3により1件当たりのCPU使用時間は登録が50ミリ秒、参照が10ミリ秒なので合計は
  $1,000\times 50+4,000\times 10=50,000+40,000=90,000$ ミリ秒。
  課金単価は「CPU使用時間1ミリ秒ごとに0.02円」なので費用は
  $90,000\times 0.02=1,800$ 円。
  したがって g = 1,800。

• e：8
• f：2,600
• g：1,800

誤りやすいポイント

• 台数計算で端数処理を誤る：インスタンス台数は小数を切り捨ててはいけません。必ず切り上げ（$\lceil \cdot \rceil$）して整数台数にします。
• 台数を合算し忘れる／最大値だけ取るミス：複数種類の処理が同じ時間帯に発生する前提では、各処理で必要な台数を合算して総台数を求めます（今回のように5台＋8台）。
• 単位の取り扱いミス：FaaSのCPU課金は「ミリ秒」単位です。秒やマイクロ秒と混同すると誤算になります。
• 無料枠の扱いミス：FaaSの「1時間当たり10万リクエストまで0円」といった閾値を見落とすと不要な課金計算をしてしまいます。

FAQ

解答の論理構成

1. 症状の整理
   本文には「早朝や深夜にシステムを利用した際、…データが表示されるまでに10秒以上の時間を要する」とあります。
2. 制約を満たすクラウドサービスの特定
   表2のうち、応答遅延に関する具体的な制約を持つものは
   「FaaS ― 『20分間一度も実行されない場合、応答が10秒以上掛かる場合がある。』」だけです。
   他のサービス（PaaS、CDNなど）には同様の10秒超の記載がありません。
3. 採用しているオンライン処理基盤の確認
   料金比較の結果「FaaSを採用した」と本文で明言されています。したがって、オンライン処理はFaaS上で稼働しています。
4. 結論
   遅延の直接原因となり得る「10秒以上掛かる場合がある」という制約を持ち、かつ実際に採用しているサービスはFaaSです。よって
   h ＝ FaaS となります。

誤りやすいポイント

• 「PaaSも1トランザクション最大10分」の記述に目が行き、10秒遅延と誤って結び付ける。実際に10秒遅延を明示するのはFaaSだけです。
• CDNのキャッシュ更新遅延と混同する。CDNは「更新されるまでcで再利用される」とあるだけで、10秒超の応答遅延を示す記述はありません。
• 料金比較の段階でFaaSを採用したことを読み飛ばし、どの基盤が使われているかを取り違える。

FAQ

解答の論理構成

1. 課題の現象
   本文には「早朝や深夜に…名刺登録や名刺参照を実行すると、データが表示されるまでに10秒以上の時間を要する」とあります。
2. 原因の特定
   ログ解析の結果は「『hの制約が原因』」と記載されています。
   h に該当するサービスは、表2のFaaSの説明中の
   「20分間一度も実行されない場合、応答が10秒以上掛かる場合がある。」
   という制約です。この“20分未満の無呼び出しなら遅延なし”という仕様が、深夜などリクエストが来ない時間帯にコールドスタートを発生させ、10秒超の遅延を招いていました。
3. 解決策の検討
   制約そのものを変えることはできません。しかし“20分間呼び出されなければ遅延が起こる”のであれば、“20分以内に一度呼び出しておく”ことで常にウォームな状態を維持できます。
4. 回避策の具体化
   したがって「20分未満の間隔でFaaS上のアプリケーションを定期的に呼び出す」ことで、リクエストが少ない時間帯でもコールドスタートを防ぎ、オンラインレスポンスを安定させられると結論付けられます。

誤りやすいポイント

• FaaSではなくPaaSの制約と誤認してしまう。PaaSには「20分間…」という記述がないため注意。
• 「10分の最大実行時間」ばかりに注目し、遅延原因を処理時間オーバーだと早合点する。
• 定期呼び出しの間隔を“20分”ちょうどに設定してしまう。ネットワーク遅延やジョブ開始誤差を考慮し、安全マージンを取る必要がある。

FAQ