自己管理型 Kubernetes ワークロードを最小労力で移行する
ドイツのオンラインチケット販売会社が、自社データセンターで稼働しているウェブサイトを AWS へ移行しようとしています。サイトはマイクロサービスで構成され、自前で構築した自己管理型 Kubernetes クラスター上のコンテナとして動作しており、Deployment や Service を定義したマニフェスト一式は社内の Git リポジトリで管理されています。コンテナイメージはオンプレミス環境に併設したオープンソースのイメージレジストリに格納され、サイトのデータはすべて PostgreSQL データベースに保存されています。ソリューションアーキテクトは AWS 上で採用するアーキテクチャを決定しなければなりません。移行にかかる労力を最小限に抑えてこれらの要件を満たすソリューションはどれですか。
解説を読む（正解: B）
移行労力を最小化する設計では、既存資産をどれだけそのまま再利用できるかが判断基準になります。Amazon EKS はアップストリーム互換の Kubernetes コントロールプレーンを AWS がマネージドで提供するサービスであり、既存の Deployment や Service のマニフェストを書き換えることなく kubectl でそのまま適用できます。マネージド型ノードグループを使えばワーカーノードのプロビジョニング、AMI 更新、ドレインといった作業も AWS 側の自動化に委ねられ、コンテナイメージを Amazon ECR に複製すればレジストリの自前運用も不要になります。PostgreSQL は互換性のある Amazon Aurora PostgreSQL に載せ替えることで、アプリケーションを変更せずに運用管理を委譲できます。この組み合わせが、マニフェストという既存資産を最大限活かしつつ運用負荷も下げる最小労力の解であり、B が正解です。A の AWS App Runner はコンテナイメージまたはソースコードから単一のウェブサービスを実行するサービスで、Kubernetes マニフェストを解釈する機能を持たず、イメージソースも基本的に ECR やソースリポジトリに限られるため、オンプレミスの独自レジストリを直接つなぐ構成自体が成立しません。C の Amazon ECS は堅実なコンテナオーケストレーターですが、Kubernetes のマニフェストは利用できず、Deployment ごとにタスク定義と ECS サービスへ書き起こす変換作業がマイクロサービスの数だけ発生するため、労力が大きく増えます。D は Kubernetes コントロールプレーン、イメージレジストリ、データベースのすべてを引き続き自前で運用することになり、オンプレミスの運用責任をそのまま持ち込むだけで、労力削減にも可用性向上にもつながりません。
コンテナ化した多層アプリの共有ストレージとセッション管理
オンライン診療の予約プラットフォームを運営する企業が、オンプレミスで稼働する 3 層アプリケーション (問診動画配信層、予約管理層、患者データベース層) をコンテナ化して AWS へ移行しようとしています。新しいアーキテクチャは高可用性を備え、季節性の受診ラッシュによる急激なトラフィック変動にも追随できる必要があります。また、すべてのサービスが共通して頻繁に参照する問診テンプレートなどの共有ファイルへ、常時アクセスできなければなりません。さらに動画配信サーバーは視聴セッションの継続性を保ったままスケールアウトできる必要があります。運用負荷を抑えつつこれらの要件を満たすソリューションはどれですか。
解説を読む（正解: D）
コンテナ化した複数のサービスを高可用かつ弾力的に動かす設計では、(1) 複数のタスクやポッドから同時に読み書きできる共有ファイルストレージ、(2) どのインスタンスに振り分けられても処理を継続できるようにセッション状態をコンピューティングの外へ出すステートレス化、という 2 点を切り分けて考えるのが定石です。Amazon EFS は複数のアベイラビリティーゾーンから同時にマウントできる POSIX 互換の共有ファイルシステムであり、全サービスが参照する共有ファイルの置き場所として最適です。一方、セッション状態は低レイテンシーで水平にスケールし、キー指定でミリ秒応答が得られるストアへ外部化するのが推奨パターンで、Amazon DynamoDB はその代表例です。選択肢 D は各サービスを Deployment として実行してスケールアウトに対応させ、セッションを DynamoDB に外部化し、共有ファイルを EFS に置くことで、可用性・弾力性・共有アクセス・セッション継続性という要件をすべて満たします。選択肢 A の EBS Multi-Attach は同一アベイラビリティーゾーン内の限られた台数のインスタンスにしかアタッチできず、複数 AZ にまたがる共有ストレージとしては成立しません。選択肢 B は Fargate による運用負荷削減こそ魅力的ですが、Amazon SQS はメッセージキューであり任意のキーでセッションを読み出す用途には使えないため、機能的に破綻しています。選択肢 C は EFS を共有ファイルとセッションの両方に使いますが、高頻度で小さな読み書きが発生するセッションストアとしてはレイテンシーとスケーラビリティの面で不利であり、専用のキーバリューストアを使う設計に劣ります。
コントロールプレーンもオンプレミスに置く Kubernetes 基盤の選択
精密機器メーカーが、既存のオンプレミスデータセンターを維持しながら、Kubernetes を使った新しい生産管理ソリューションを開発しています。開発環境とステージング環境は AWS リージョン内の Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで動かしています。一方、本番ワークロードについては社内規程により、EKS のコントロールプレーンとデータプレーンの両方を工場敷地内のデータセンターに配置しなければなりません。同時に、Kubernetes の管理そのものは AWS のマネージドソリューションに任せたいと考えています。運用オーバーヘッドが最も少ない構成はどれですか。
解説を読む（正解: D）
AWS Outposts は AWS が設計・設置・保守するラックをオンプレミスに持ち込み、そこで AWS のマネージドサービスをネイティブに動かせるようにするサービスです。Outposts 上で Amazon EKS を使う方式には 2 つあり、拡張クラスター (extended cluster) はコントロールプレーンを AWS リージョン側に置いてワーカーノードだけを Outposts に配置する構成、ローカルクラスター (local cluster) はコントロールプレーン自体を Outposts 上で稼働させる構成です。設問はコントロールプレーンとデータプレーンの両方をオンプレミスに置くことを求めているため、ローカルクラスターを選ぶ必要があります。ローカルクラスターであればリージョンとの接続が一時的に切れてもクラスターの操作を継続でき、しかもコントロールプレーンのプロビジョニングやパッチ適用は EKS のマネージドサービスとして AWS が担うため、運用オーバーヘッドを最小化できます。拡張クラスターを選ぶ案は、コントロールプレーンがリージョンに残るためオンプレミス配置という要件を満たしません。自社ハードウェアに Amazon EKS Anywhere を導入する案は、確かにすべてがオンプレミスで動きますが、EKS Anywhere はユーザー自身がクラスターのライフサイクルを管理するセルフマネージド製品であり、AWS マネージドソリューションという要件から外れるうえ運用負荷も大きくなります。Outposts の上に EKS Anywhere を載せる案は、AWS が管理すべき基盤の上にセルフマネージドの Kubernetes を重ねる構成で、コストと運用負荷が二重になるだけで利点がありません。