少人数チーム向けの即時ロールバック可能な CI/CD
エンジニア 3 名のゲーム内アイテム取引スタートアップが、モノリシックな Java アプリケーションを AWS 上の Amazon EC2 インスタンス群で運用しています。同社は資金調達を機に機能追加のペースを上げたいと考えており、週に数回のリリースを短時間で完了させ、問題が発覚した場合は数分以内に直前のバージョンへ戻せる CI/CD パイプラインを求めています。インフラ運用の専任担当者はおらず、パイプラインやプラットフォームの自作は避けたいと考えています。これらの要件を満たす設計手順はどれですか。
解説を読む（正解: C）
AWS Elastic Beanstalk は、アプリケーションコードをアップロードするだけで EC2、Auto Scaling グループ、ロードバランサー、モニタリングを自動的にプロビジョニングし、プラットフォームの更新も管理してくれるマネージドサービスです。同一アプリケーション内に複数の環境を作成でき、環境 URL のスワップ (CNAME スワップ) によって、検証済みのセカンダリ環境を瞬時に本番へ昇格できます。これは典型的なブルー/グリーンデプロイであり、リリース直後に問題が判明しても URL をもう一度スワップし直すだけで数分以内に旧環境へ戻せます。専任のインフラ担当者がいない少人数チームという条件にも合致するため、C が正解です。A は AMI のビルドとインスタンス入れ替えに時間がかかり、ロールバックも旧 AMI での再デプロイになるため即時性がありません。B は Systems Manager、ユーザーデータ、Route 53 加重ルーティングを組み合わせた自作の仕組みで、構築と保守の負担が最も大きく、DNS の TTL やクライアント側キャッシュの影響で切り戻しが即座に完結しない可能性もあります。D のローリング置換方式は、新旧のインスタンスが混在する時間が長く、切り戻しには再び旧 AMI で同じ入れ替えを行う必要があるため、数分以内のロールバックという要件を満たせません。
ソースコードを持たない Java アプリの移行先選定
学習塾を運営する企業が、オンプレミスで稼働している成績管理システムを AWS へ移行しようとしています。このシステムは Apache Tomcat 上で動作する Java 製の Web アプリケーションで、バックエンドに PostgreSQL データベースを使用しています。同社は開発元との契約が終了しておりソースコードを保有していませんが、ビルド済みの Java アーカイブ (JAR) ファイルはデプロイできます。アクセスは毎月末の成績集計時期に大きく増加します。運用上の負担を最小限に抑えて要件を満たすソリューションはどれですか。
解説を読む（正解: D）
ソースコードを保有しておらず JAR ファイルのデプロイしかできないという制約は、アプリケーションの書き換えを伴う選択肢をすべて排除します。残るのは、既存の実行環境である Tomcat と PostgreSQL をそのまま維持しつつ、AWS のマネージドサービスで運用を肩代わりさせる方式です。AWS Elastic Beanstalk は Tomcat をマネージドプラットフォームとして提供し、アーティファクトをアップロードするだけで、EC2 のプロビジョニング、複数アベイラビリティーゾーンへの配置、Application Load Balancer の作成、Auto Scaling の設定、プラットフォームの更新までを自動で行います。データベースは Amazon RDS for PostgreSQL に載せ替えることでバックアップやパッチ適用、Multi-AZ による可用性確保を AWS 側に委ねられます。月末のアクセス増加は Auto Scaling が吸収し、静的コンテンツは CloudFront で負荷を軽減できるため、選択肢 D が最も運用負担の小さい解になります。選択肢 A は、全インスタンスに PostgreSQL を同居させるという整合性を欠いた設計であり、Step Functions はワークフローのオーケストレーションサービスでスケーリング手段ではないため誤りです。選択肢 B は、コンテナイメージの作成と Kubernetes の運用という重い負担が生じ、複数リージョンにまたがる Auto Scaling グループという構成も成立せず、要件に対して過剰です。選択肢 C は、ソースコードがないためリファクタリング自体が不可能であり、Storage Gateway はオンプレミスとクラウドのストレージ連携サービスでスケーリングとは無関係です。
高頻度リリースと即時ロールバックを両立する CI/CD 設計
あるオンライン学習サービス企業は、モノリシックなアプリケーションを AWS 上のモダンなアーキテクチャへリファクタリングする計画を進めています。それに合わせて、既存の CI/CD パイプラインを次の要件を満たすようにアップグレードする必要があります。
・1 時間に数回の頻度で変更を本番へリリースできること
・問題が発生した際、可能な限り短時間で変更をロールバックできること
これらの要件を満たす設計はどれですか。
解説を読む（正解: C）
1 時間に数回リリースし、問題があれば最短でロールバックするという要件を満たすには、デプロイと切り戻しの双方が数十秒から数分で完了する仕組みが必要です。AWS Elastic Beanstalk では、同じアプリケーションに対して本番用とステージング用の 2 つの環境を用意し、ステージング環境に新しいバージョンをデプロイして動作を確認したうえで、環境 URL (CNAME) をスワップすることで一瞬で本番トラフィックを切り替えられます。これがいわゆるブルー/グリーンデプロイであり、問題が判明した場合は URL を再度スワップするだけで旧環境へ戻せるため、ロールバックも同じ短時間で完了します。旧環境はそのまま稼働し続けているのでインスタンスの再構築も不要です。アプリケーションと構成を焼き込んだ AMI を作って EC2 を入れ替える案は、AMI の作成に数分から数十分を要して 1 時間に数回というリリース速度に追随できず、切り戻しにも同じ時間がかかります。Systems Manager でデプロイのたびにインフラを再プロビジョニングし Route 53 の加重ルーティングで切り替える案は、プロビジョニング時間に加えて DNS の TTL によりトラフィックの切り替えと切り戻しが即座には完了しません。ビルド済み AMI を使って Auto Scaling で段階的にインスタンスを置き換える案も、全インスタンスの入れ替えが完了するまで時間がかかり、ロールバック時にも同じローリング置換をやり直す必要があるため、最短の切り戻しという要件を満たしません。