9問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
正解数 0/問題数9
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAP-291】モバイルゲームの開発・配信を手がけるある会社では、対戦型タイトルをグローバル同時運営している。
現在、ゲームサーバーは us-east-1 にのみ配置され、プレイヤーのクライアントアプリは UDP で接続する設計のため、企業ネットワークや学校のファイアウォールに登録しやすいよう一連の固定 IP で公開している。
海外ユーザーの急増に伴い、①世界各地へ迅速にサーバーを水平展開して遅延を抑えること(ビジネス狙い)、②リージョン障害時もサービスを停止させないこと(可用性要件)、③運用負荷を増やさず固定 IP を維持すること(技術制約)が経営会議で決定した。
インフラ運用チームは、トラフィックを自動的に最寄りリージョンへ転送し、UDP を終端でき、エッジネットワーク経由で高速化を図れる AWS ネイティブサービスを条件に選定を求められている。
ソリューションアーキテクトは、どのサービスと構成を採用すべきか?
UDP ゲームトラフィックを固定 IP で多リージョンに届けたいとき、Global Accelerator+NLB の組み合わせを思い出す。
【SAP-292】ある大手教育企業は、複数大学の教職員・学生が時間割作成や成績入力を行う社内 Web アプリを Amazon WorkSpaces 上で提供している。
ユーザープロファイルは DNS エイリアスを付与した Amazon FSx for Windows File Server に保存され、自己管理 Active Directory に参加している。
新学期の同時ログイン急増により WorkSpaces のサインイン時間が許容範囲を超過し、調査の結果、スループット 16 MBps の HDD ストレージで構築した FSx ファイルシステムの I/O が性能低下の主因と判明した。
経営層は授業開始前のメンテナンスウィンドウ内で応答速度を回復し、SLA を順守するよう求めている一方、運用チームにはデータ移行や新規サーバー管理に割ける工数がない。
既存の DNS 名や AD 参加設定を維持したまま、最小限の管理作業でスケーラブルに性能を改善する必要があるとソリューションアーキテクトは判断している。
ソリューションアーキテクトは何を行うべきか?
FSx for Windows File Server は作成後に HDD→SSD へインプレース変更できないため、「新しい FSx を作ってデータを移し DNS を切り替える」パターンが必要になります。AWS Backup の復元ではストレージタイプ変更はできないため、FSx 間コピーを自動化できるサービスを使った移行パスがどれかを考えてください。なお、AWS DataSync はフルマネージドサービスですが、FSx for Windows File Server をソースとする場合は SMB アクセスのために EC2 上に DataSync エージェントのデプロイが必要です(S3 や EFS 間の転送ではエージェント不要)。エージェントの導入は AMI から EC2 を起動するだけで済み、転送の自動化・整合性検証はサービス側が行うため、手動コピーより圧倒的に運用負荷が低い点がポイントです。
【SAP-293】あるオンラインチケット販売サービスを展開する企業では、購入ピーク時の急激なリクエスト増加に備え、AWS 上に Web アプリケーション層を構築し、複数の Amazon EC2 インスタンスで処理を分散させている。
ユーザーはブラウザから https://www.example.com にアクセスし、座席選択から決済までを完了するため、通信にはクレジットカード情報など機微データが含まれる。
PCI-DSS 準拠を維持するため、クライアントと各 EC2 ウェブサーバー間の経路はすべて TLS で暗号化された状態を保つことが必須要件となっている。
少人数の運用チームでもピーク時の自動スケールに追従できるよう、負荷分散と証明書管理は極力マネージドサービスで完結させたいというビジネス上の背景もある。
さらに、ロードバランサーは増減するインスタンスを自動認識し、アプリケーション設定の変更を最小限に抑えることが求められている。
これらの技術的・運用的要件を踏まえ、ソリューションアーキテクトは、トラフィックを EC2 インスタンス群へ効率的に分散しつつエンドツーエンド暗号化を確保するために、どの AWS サービス構成を採用すべきか判断する必要がある。
クライアントから EC2 までの通信経路のどこか 1 箇所でも平文になっていないかを意識しつつ、証明書のライフサイクル管理を誰が・どこで担当するかに着目する。ロードバランサーに ACM 証明書を割り当てて TLS を終端しつつ、バックエンドとの間も必要に応じて暗号化できる構成と、インスタンスごとに証明書をばらまいて手作業で管理する構成の違いを比較すると、最も要件に合う案が見えてくる。
【SAP-294】オンライン小売業を営むある企業では、商品検索と購入フローをユーザーに24時間提供しているウェブアプリケーションを、従来の単一 Amazon EC2 からマイクロサービス化し、コンテナで再構築する計画を進めている。
短期キャンペーンや深夜帯の閲覧増など需要変動が大きいため、リリースの迅速化とインフラ運用負荷の低減が経営課題となり、開発部門から「サーバーレス指向でコストを使った分だけに抑えたい」との要望が上がっている。
同一の AWS アカウントおよび同一の VPC 内に本番環境とテスト環境の2つを構築しており、それぞれ異なるアプリケーションバージョンを保持する。
負荷の上下限は把握しているため、最小稼働数を確保しつつピーク時だけ自動で拡張できる仕組みが欠かせない。
さらに、環境ごとに分離されたデプロイとバージョン管理、そしてコンテナイメージ単位での段階的な更新が求められている。
制約条件として、運用チームはインスタンス管理やパッチ適用を極力行わず、ネットワークや IAM ポリシー設定に集中したいと考えている。
これらの前提のもと、ソリューションアーキテクトはインフラ設計レベルで、コンテナ実行基盤とデプロイ方式を選定し、可変負荷に応じた自動スケーリングを実装する必要がある。
ビジネス上の狙い(迅速な機能追加とコスト最適化)と技術的要件(環境ごとのバージョン分離、サーバーレス運用、明確な最小・最大キャパシティ)の双方を満たし、最もコスト効率の高い AWS 構成はどれか?
サーバーレス指向という条件から「EC2 を直接管理する必要がないか」「サービスオートスケーリングでタスク数だけを意識できるか」に注目してください。ECS on Fargate と EKS/EC2 ベース構成の運用負荷の違いを軸に考えると選びやすくなります。
【SAP-295】あるオンライン小売企業は新製品紹介用のシングルページアプリを JavaScript で開発し、us-east-1 の S3 に保存、CloudFront で世界へ配信している。
顧客はこのサイトで商品の閲覧と購入を行っている。
マーケティング部門は購入率を高めるデザインを見極めるため告知なしの A/B テストを希望し、従来版と新デザイン版を別々の S3 バケットに置いて効果を比較したいと考えている。
ビジネス上の狙いは、EU 圏顧客に新デザインを先行投入し、米国顧客には現行デザインを維持して地域別の反応を測定することにある。
さらに SNS キャンペーンなどで指定したユーザーについては、所在地に関係なく新デザインへ誘導する必要がある。
運用チームは既存の S3+CloudFront 構成を踏襲し、サーバーレスで自動スケールする仕組みを維持しつつ追加運用コストを最小化したい。
技術要件として、リクエスト時に国コードと Cookie などのテスト参加フラグを判定し、レイテンシを増やさずエッジ側で動的に適切なバケットへルーティングできる機能が求められる。
これらの条件を満たすため、ソリューションアーキテクトはどの AWS サービス構成を採用すべきか?
S3 の A/B テストを CloudFront だけで実現したいとき、Lambda@Edge でオリジンを動的に切り替える構成を意識する。
【SAP-296】北米で動画配信事業を営むある会社では、視聴者にオンデマンドで映画やドラマを提供する新しい Web アプリケーションを Amazon EC2 上に構築し、us-east-1 を主要リージョンとして本番運用を開始する計画です。
ピーク時にはトラフィックが数倍に跳ね上がるため、自動でインスタンス数を増減させつつ、AZ 障害が発生しても継続提供できる冗長性が求められています。
また、取引先との SLA で「大規模障害時は 1 時間以内に復旧する」ことが義務付けられたため、us-west-1 に待機系を置くアクティブ–パッシブのディザスタリカバリ構成を同時に用意する方針です。
運用チームは少数で 24 時間体制を取れないことから、日常の監視とスケーリングは AWS マネージドサービスに極力任せる必要があります。
ソリューションアーキテクトは、まず us-east-1 に VPC を作成し終えたところです。
動的スケーリングと高可用性の土台を整えたうえで、将来のリージョン間フェイルオーバーにも備えるために、次に実施すべき構成変更はどれでしょうか。
アクティブ−パッシブ DR を Route 53 で実現する際の、プライマリ/セカンダリ ALB+フェイルオーバールーティングの基本パターンをイメージする。
【SAP-297】あるSaaS 企業は、クラウド上のプロジェクト管理サービスを世界中の法人ユーザーに提供しており、高い稼働率と迅速な機能更新を売りにしている。
基盤は Windows ベースのアプリケーションサーバーと Linux ベースのバックエンドサーバーが数千台規模で混在し、複数のアベイラビリティゾーンにまたがって自動スケールしている。
最近、SOC 2 監査および ISO 27001 更新審査に備え、各インスタンスのパッチ適用と変更履歴を一元的に追跡できる仕組みを 30 日以内に整備するようガバナンス部門から要請があった。
ビジネス上は「セキュリティパッチ公開から 24 時間以内の適用」と「7 年間の証跡保管」が新たに必須となり、運用チームの人員は増やさずに達成したいと考えている。
技術的には、①OS によるパッチ管理の差異を吸収し、②インスタンスへの inbound SSH/RDP を開放せずに自動適用を実行し、③適用状況と操作履歴を改ざん困難な形で保存することが条件となる。
これらを最小限の運用負荷で満たすため、ソリューションアーキテクトはどのサービス構成を採用すべきか?
OS 混在・数千台規模・SSH/RDP 不可・証跡要件、というキーワードが揃ったら AWS Systems Manager Patch Manager+CloudTrail の組み合わせを思い出してください。OpsWorks や OS ネイティブツールは運用負荷が重くなります。
【SAP-298】ある小売 EC プラットフォームを運営する企業では、在庫検索や注文状況を社内部門に提供するリアルタイム API をサーバーレスで構築し、Amazon API Gateway、AWS Lambda、Amazon DynamoDB を用いて社内 VPC へデプロイしている。
API は毎週の機能追加に伴い頻繁に更新されるため、手作業でのコンソール操作がリリース工程のボトルネックとなり、開発速度と品質の確保が課題となっている。
経営層は新規マーケットへの早期進出を見据え、迅速かつ一貫性のあるデリバリーパイプラインを要求しており、運用チームは少人数でもインフラの状態をコードとして管理し、変更履歴を監査できるようにしたいと考えている。
さらに、将来的なスケールアウトや複数リージョン展開の際に、同一テンプレートで環境を容易に複製できることが必須条件となる。
これらの背景を踏まえ、ソリューションアーキテクトはインフラレベルの自動化を実現し、レビュー済みの定義ファイルから再現可能にスタックを作成・更新できる仕組みを選定する必要がある。
ソリューションアーキテクトはどのアプローチを採用すべきか?
サーバーレス構成を IaC+CI/CD に載せるときは、『SAM テンプレート+CodePipeline+CloudFormation』の組み合わせを第一候補とする。SAM は CloudFormation の拡張であり、サーバーレス特有のリソースを少ない記述で定義できるフレームワークである。素の CloudFormation でも同等の構成は実現可能だが、SAM を使えばテンプレートの記述量を大幅に削減でき、開発速度と保守性が向上する。
【SAP-299】ある映像制作会社は、顧客がウェブポータルから素材動画をアップロードし、社内エンコーダで変換した後にダウンロードリンクを提供する SaaS 型サービスを展開している。
現行環境では Web サーバが受け取ったファイルを NAS に格納し、メッセージキュー経由で処理サーバへジョブを送付する。
各ファイルの処理時間は最大 1 時間で、昼間にキューが急増し夜間に急減する。
設備投資を抑えつつピークに追従したいという CFO の方針から、従量課金型クラウドへ移行し運用負荷も削減することが求められている。
運用チームは少人数のため、ストレージ冗長化・スケールイン/アウトはマネージドサービスに任せ、既存ワークフロー(アップロード→保存→キュー通知→長時間バッチ)はそのまま残すことが技術的な前提条件である。
ソリューションアーキテクトは、インフラ設計レベルでどの AWS サービス構成を採用し、最も費用対効果の高いクラウド移行を実現すべきか?
「長時間処理(最大 1 時間)」と「ピークに応じた自動スケール」というキーワードから、キュー+EC2 Auto Scaling のパターンを思い出してください。Lambda の時間制限や MQ 導入のオーバーヘッドに着目すると誤答を切りやすくなります。
この教材の改善リクエストがある場合は、お気軽にご報告ください。
カテゴリを選択のうえ、詳細をご記入いただけますと幸いです。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
