LinuC レベル4 4SA01試験のサンプル問題（本番形式・解説付き）

LinuC レベル4 4SA01試験（LPI-Japan・LinuC-4SA システムアーキテクト（4SA01））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（40問）の冒頭から抜粋したオリジナル問題です。当サイトは全320問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

業務ロジックを3つの layer に分けて設計したアプリケーションについて、インフラ担当から「3層なのでサーバーも3台に分ける必要がある」という指摘が出た。この指摘に対する説明として最も適切なものはどれか。

layer は配置による物理的な分割であり、層の数と同じだけノードを用意しないと独立性が保てない。
layer と tier の数は一致させる規約があり、3台に分けて初めて層ごとの独立した変更ができる。
layer をまたぐ呼び出しはノード内でも遅いため、層ごとにノードを分けたほうが応答は速くなる。
layer は役割による論理的な分割であり、3層のまま1台に置くことも3台に分けることもできる。（正解）

解説

layer 構造は役割・関心事による論理的な分割で、tier 構造は実行環境やノードによる物理的な分割です。3層（layer）で設計したアプリケーションを1台に置けば 1-tier、3台に分ければ 3-tier になるため、層の数がそのまま必要な台数を決めることはありません。tier を増やす判断は、層ごとに負荷特性が違って別々にスケールしたい・セキュリティ境界を引きたい・可用性の単位を分けたい、のいずれかが要件にあるときに行い、どれも無ければ遅延と運用対象だけが増えます。（根拠: 学習用テキスト 1-3 分割 ── layer 構造と tier 構造 [1.1]）

他の選択肢が誤りである理由

「layer は配置による物理的な分割であり、層の数と同じだけノードを用意しないと独立性が保てない。」layer は論理的な分割です。物理的な配置の分割は tier 構造が担い、layer の数は必要なノード数を決めません。
「layer と tier の数は一致させる規約があり、3台に分けて初めて層ごとの独立した変更ができる。」layer と tier の数を一致させる規約はありません。1つの layer 構造を1台に置くことも複数台へ割り付けることもでき、層ごとの変更容易性は論理的な分割そのものから得られます。
「layer をまたぐ呼び出しはノード内でも遅いため、層ごとにノードを分けたほうが応答は速くなる。」tier を分けるとネットワークを挟むため、呼び出しあたりの遅延はむしろ増えます。層の分割による間接化の実行コストはノード内では小さく済みます。

設問2

注文確定後に在庫・決済・配送の各サービスを決まった順序で実行し、途中で失敗したときの補償処理の進捗を1か所で追跡したいという要件がある。この要件に最も適した方式はどれか。

中央のオーケストレーターが業務フロー全体を保持し、各サービスを決まった順に呼び出す。（正解）
各サービスがイベントを購読し、受け取った事実に応じて自分の処理と次の発行だけを行う。
各サービスが同一のデータストアを共有し、更新の順序をデータベースのトランザクションに委ねる。
送信側と受信側の間にブローカーを置き、宛先のキュー名だけで経路を決めて受け渡させる。

解説

業務フローが1か所に書かれていて、全体の流れを読める・変更できる・進捗と失敗の状態を追えるのがオーケストレーションの利点です。補償処理の実装も中央に集約できるため、順序と進捗の追跡が要件になっている場面ではこちらを採ります。代償はオーケストレーターが単一障害点かつ変更のボトルネックになることで、サービスを1つ足すたびに中央を直す必要が生じます。（根拠: 学習用テキスト 1-6 制御と連携集約のパターン ── 主従関係で整理する [1.1]）

他の選択肢が誤りである理由

「各サービスがイベントを購読し、受け取った事実に応じて自分の処理と次の発行だけを行う。」コレオグラフィの説明です。全体の流れを保持する中央が存在しないため、進捗の把握には分散トレーシングが要り、補償の設計も各サービスに分散します。
「各サービスが同一のデータストアを共有し、更新の順序をデータベースのトランザクションに委ねる。」データ共有型に戻す案で、機能の分割が半分しか終わっていない状態になります。順序は取れてもデータストアが単一障害点と変更の足かせとして残ります。
「送信側と受信側の間にブローカーを置き、宛先のキュー名だけで経路を決めて受け渡させる。」ブローカーは受け渡しに徹し、経路の決定を宛先の名前へ委ねる仲介者です。業務フローの順序や進捗を保持する役割は持ちません。

設問3

在庫を超えて販売してはならない受注処理を、データ非共有型で分けた複数サービスにまたがって実現したい。確定までの間に同じ在庫が他の注文へ渡ることを避けたい。採るべき方式はどれか。

各サービスが自分のローカルトランザクションを即座にコミットし、失敗時は補償処理を逆順に実行する。
各サービスが Try で資源を仮押さえし、成功時は Confirm、失敗時は Cancel で解放する。（正解）
各サービスの処理を一方向のパイプでつなぎ、段の間にバッファを挟んで速度差を吸収する。
注文確定のイベントを Pub/Sub のトピックへ発行し、購読している各サービスが担当分を実行する。

解説

TCC は Try で資源を仮押さえし、全サービスの Try が成功したら Confirm で確定、どれかが失敗したら Cancel で解放します。仮押さえの状態が存在するため、確定の直前まで他の注文に取られないことを保証でき、在庫や座席の二重取りを避けたい要件に向きます。各サービスに3つの操作を実装する費用がかかること、呼び出し側が落ちたときに備えて仮押さえへタイムアウトによる自動解放を設ける必要があることが代償です。（根拠: 学習用テキスト 1-7 データ連携と整合のパターン ── TCC [1.1]）

他の選択肢が誤りである理由

「各サービスが自分のローカルトランザクションを即座にコミットし、失敗時は補償処理を逆順に実行する。」Saga の説明です。仮押さえをせず都度コミットするため、補償が走るまでの間に同じ在庫が他の注文へ売れてしまう余地が残ります。
「各サービスの処理を一方向のパイプでつなぎ、段の間にバッファを挟んで速度差を吸収する。」パイプラインの説明で、一方向に流れるデータ加工に向く構造です。資源の取り合いを確定前に押さえる仕組みは持ちません。
「注文確定のイベントを Pub/Sub のトピックへ発行し、購読している各サービスが担当分を実行する。」イベント駆動による連携で、複数の相手が同じ事実を必要とする場面に向きます。在庫の引当を確定前に押さえる働きはありません。

設問4

注文確定を契機に、メール通知・ポイント付与・分析基盤への連携を行いたい。連携先は今後も増える見込みで、増えるたびに受注サービスへ手を入れることは避けたい。適した方式はどれか。

注文確定を1回だけトピックへ発行し、購読している各連携先がそれぞれ受け取って処理する。（正解）
連携先ごとにキューを用意し、受注サービスが宛先を指定して1件ずつ順に配送する。
受注サービスが各連携先を順に同期呼び出しし、応答が出そろってから注文を確定する。
1本のキューへ送り、受信者を連携先の数だけ増やして全員が同じメッセージを処理する。

解説

Pub/Sub は1つのメッセージを購読者全員が受け取るモデルなので、発行側は誰が受け取るかを知らないまま1回発行するだけで済み、連携先が増えても購読側を追加するだけで発行側は変わりません。通知・ポイント付与・分析はいずれも結果を待たなくてよい処理なので、非同期で扱えます。ここでメッセージングキューを選ぶと、連携先が増えるたびにキューを増やして送信側を直すことになり、疎結合の利点を失います。（根拠: 学習用テキスト 1-6 制御と連携集約のパターン ── Pub/Sub パターン [1.1]）

他の選択肢が誤りである理由

「連携先ごとにキューを用意し、受注サービスが宛先を指定して1件ずつ順に配送する。」連携先ごとにキューを用意すると、増えるたびに宛先の追加が送信側の変更として跳ね返ります。複数の相手が同じ事実を必要とする形には向きません。
「受注サービスが各連携先を順に同期呼び出しし、応答が出そろってから注文を確定する。」同期の連鎖になるため、利用者の待ち時間は全区間の合計になり、可用性も各サービスの積になります。待たなくてよい処理を待つ構成です。
「1本のキューへ送り、受信者を連携先の数だけ増やして全員が同じメッセージを処理する。」メッセージングキューは1メッセージを1受信者が処理するモデルで、受信者を増やすと処理が分担されます。全員が同じメッセージを受け取る形にはなりません。

設問5

利用者からの登録処理のうち、後続の集計をキューへ渡す非同期方式に変更した。この変更で期待できる効果の説明として最も適切なものはどれか。

下流の処理能力が同じままでも、単位時間に処理できる総量を増やすことができる。
相手の応答を待たなくなるため、処理の順序保証と重複の排除は実装側で不要になる。
呼び出しの経路が短くなり、登録から集計が終わるまでの全体の所要時間が短くなる。
利用者が待つ区間が受付までに縮まり、負荷の山を時間方向にならすことができる。（正解）

解説

非同期化は、利用者を待たせる区間を受け付けまでに縮め、負荷の山を時間方向にならす技術です。全体の処理量が増えるわけではなく、下流の処理能力が同じならキューが伸びて滞留するだけになります。代わりに、順序保証・重複・失敗の扱いを自分で設計する複雑さが増えます。（根拠: 学習用テキスト 1-5 タイミング ── 同期と非同期 [1.1]）

他の選択肢が誤りである理由

「下流の処理能力が同じままでも、単位時間に処理できる総量を増やすことができる。」下流の処理能力が変わらなければ、単位時間に処理できる総量は増えず、依頼がキューに溜まっていくだけです。
「相手の応答を待たなくなるため、処理の順序保証と重複の排除は実装側で不要になる。」非同期では結果の受け取りがコールバックやイベントに変わるため、順序保証・重複・失敗の扱いは実装側の設計事項として増えます。
「呼び出しの経路が短くなり、登録から集計が終わるまでの全体の所要時間が短くなる。」受付から集計完了までの合計時間は短くなりません。短くなるのは利用者が待つ区間だけです。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← LinuC レベル4 4SA01試験の資格ページへ