助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 36519
問題を開く
あるeコマース企業がAWSに新しいオンラインショップを立ち上げる準備をしている。担当者と話をしたところ以下のような要望があった。「商品ページなどの静的コンテンツを安定的に配信する必要がある。カート処理やユーザーのアカウント管理などの動的な処理は現在運用して実績のあるDockerコンテナを使うが、変動するトラフィックに迅速に対応できないと困る。購入履歴やユーザーのアカウント情報はリレーショナルデータベースで安全に管理したい。サーバーの運用管理は減少させ、インフラストラクチャの自動スケーリングとデプロイを簡素化したい。」担当者の希望要件を満たす最も効果的なアーキテクチャはどれか。

正解

商品ページをAmazon S3でホスティングし、AWS FargateとAmazon ECSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する

解説

担当者の要望を順に検討していきます。
・静的コンテンツの安定配信:
静的コンテンツのホスティングにはS3が最適です。
・Dockerコンテナを使用し、変動するトラフィックに迅速に対応可能な動的処理:
FargateとECSの組み合わせ、FargateとEKSの組み合わせともDockerコンテナの実行に適しており、自動スケーリングもサポートしており問題ありません。
・購入履歴やユーザーアカウント情報のリレーショナルデータベースでの管理:
リレーショナルデータベースサービスにはRDSとAuroraがあります。
・サーバーの運用管理を効率化:
Fargateはサーバーレスのコンテナサービスであり、サーバーの運用管理が不要でとなり効率化が実現できます。
コンテナオーケストレーションにECSを使用する場合、ECSは他のAWSサービスとしての統合が深く、他のサービスとの連携が容易であるため運用管理が簡素化できます。
一方コンテナオーケストレーションにEKSを使用する場合、Kubernetesクラスタの設定と管理が必要となり管理負担が増えます。
・インフラの自動スケーリングとデプロイの簡素化:
FargateとECSの組み合わせ、FargateとEKSの組み合わせとも要件に当てはまります。また、S3のホスティングは管理が簡単であるため要件にあっています。

よって全ての要望を満たしている正解は以下となります。
・商品ページをAmazon S3でホスティングし、AWS FargateとAmazon ECSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する

その他の選択肢については、以下の通りです。

・Amazon EC2インスタンスで静的コンテンツの表示と動的処理を実行し、Amazon Auroraに購入履歴やユーザーのアカウント情報を保存する
EC2は柔軟性が高く、静的・動的コンテンツの両方の表示に使用できます。しかしEC2は柔軟性が高い一方、インスタンスの運用やセキュリティ管理などの手間がユーザーに求められるため、運用の効率が低下する可能性があります。この点で「サーバーの運用管理を効率化」の要望を満たすことは難しいです。よって誤りです。

・商品ページをAmazon S3でホスティングし、Amazon EC2インスタンスで動的処理を実行し、Amazon DynamoDBで購入履歴やユーザーのアカウント情報を保存する
EC2は前述した通り、「サーバーの運用管理を効率化」の要望を満たすことは難しいです。またDynamoDBはNoSQLデータベースであるためリレーショナルデータベースの要件に合いません。よって誤りです。

・商品ページをAmazon S3でホスティングし、Amazon API GatewayとAWS Lambdaで動的処理を実行し、Amazon ElastiCacheに購入履歴やユーザーのアカウント情報を保存する
API GatewayとLambdaはサーバーレスアーキテクチャを提供するため、サーバーの運用管理の負担を減少させることができます。ですが、API GatewayとLambdaの組み合わせでは要望であるDockerコンテナを利用できません。また、ElastiCacheはインメモリデータベースサービスであるためリレーショナルデータベースとしての要望を満たしていません。よって誤りです。

・商品ページをAmazon S3でホスティングし、AWS FargateとAmazon EKSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する
正解との違いは、コンテナオーケストレーションにEKSを使用することです。EKSはAWSが提供するKubernetesのマネージドサービスです。現在Kubernetesで運用している場合は、EKSでも既存のツールや知識を活用できますが、新規環境を作る場合は新たに知識やKubernetesクラスタの設定と管理が必要となるため、運用管理の負担が増えます。よって誤りです。

参考

【コンテナ】
「コンテナ」は、アプリケーションとその実行環境(アプリケーション実行環境・ミドルウェア)をひとまとめにし独立したパッケージに包み込んだものです。「コンテナエンジン」は、これらのコンテナを実行するための環境を提供し、コンテナが他のコンテナやサーバー・OSなどのホストシステムとは隔離された環境で動作することを可能にします。その結果、コンテナは、PCやオンプレミスにあるサーバー、クラウド環境でもコンテナエンジンがあれば同じように実行できます。
このように「コンテナ」は、アプリケーションとその実行環境をパッケージ化する仮想化技術の一種です。

[コンテナ実行環境]


コンテナ技術は、アプリケーションを他の環境に移動や複製し、実行するのを簡素化します。そのため、開発したアプリケーションの共有や、開発・テストの環境へのデプロイ(実行可能な状態にすること)が容易になります。
簡単に言えば、コンテナはアプリケーションとその実行環境を「詰め込んだ箱」のようなもので、さまざまな環境やプラットフォームにも持ち運びやすく、使いやすくするための技術です。
コンテナによる仮想化を用いてアプリケーションを開発・実行するためのソフトウェアに「Docker」があります。

【Amazon ECS(Elastic Container Service)】
Amazon ECS(Elastic Container Service)はコンテナを実行、管理するサービスです。ECSはDocker環境で動作するDockerコンテナをサポートしています。またインフラストラクチャのプロビジョニング※やスケール管理など、多くの運用作業を自動化します。
※インフラストラクチャのプロビジョニング:ハードウェア、ソフトウェア、ネットワークなどの計算リソースをセットアップし、使用可能な状態にすること

ECSのように複数のコンテナのデプロイ、管理、スケーリングを一元的に行う仕組みを「コンテナオーケストレーション」といいます。
ECSは負荷に応じて自動的にリソースを調整し、実行中のコンテナインスタンスの状態を監視し続けるため、継続的な可用性とパフォーマンスを保証する効率的な運用が可能です。これにより、開発者はアプリケーションのコードに集中でき、運用上のオーバーヘッド(システムの維持・管理に関わる追加の時間、労力、費用など)を大幅に削減できます。

[ECSでコンテナを管理する]


【コンテナイメージ】
アプリケーションとその実行環境を、コンテナのひな形としてパッケージ化したものを「コンテナイメージ」といいます。コンテナを動作させるソフトウェアである「コンテナエンジン」が、コンテナイメージから「コンテナ」を起動します。コンテナイメージは異なる環境にそのまま持ち込むことができるので、例えばテスト環境から作成したコンテナイメージを本番環境にコピーしてコンテナを起動すれば、同一の環境を構築できます。

【ECSの主要要素】
ECSの主要要素に「クラスター」「タスク」「サービス」があります。

○クラスター
1つ以上のタスクまたはサービスで構成される論理グループです。クラスターでは、コンテナが動作するVPCやサブネットなどを設定します。

○タスク
ECSで管理するコンテナの実行単位です。タスク内のコンテナは、実行するコンテナイメージ、CPUやメモリのスペック、タスクロールなどを定義した「タスク定義」に基づいて起動されます。なお、タスクロールとはコンテナが他のAWSサービスを利用する際に設定するアクセス権限(IAMロール)のことです。

○サービス
クラスター内で必要なタスク数を維持する機能です。あるタスクが異常終了して必要なタスク数を下回った場合、サービスが新しいタスクを起動して自動復旧します。サービスでは、起動するタスクのタスク定義、必要なタスク数、ELBとの連携などを設定します。

[ECSにおける「クラスター」「タスク」「サービス」の関連図]


【ECSの起動タイプ】
ECSで実行・管理するコンテナは、コンテナを実行する環境によって主に「AWS Fargate」と「EC2起動タイプ」があります。

○AWS Fargate(Fargate起動タイプ)
AWS Fargateはコンテナ向けのサーバーレスコンピューティングエンジンです。コンテナ実行環境のCPUやメモリのスペック、アクセス権限(IAM)などを設定するだけで、サーバーの環境構築や管理をすることなくコンテナを実行できます。
Fargateの利用料金は、タスクで指定したCPU/メモリに応じて課金されます。実行したタスクのリソース使用量に対して料金が発生するので、不定期にタスクが実行されるシステムや、常にタスクが実行可能な状態でなければならないシステムなどに向いています。
Fargateを1年以上継続して利用する場合は「Compute Savings Plans」で契約すると、サービスを割引価格で利用できます。Compute Savings Plansは1年または3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、通常よりも低価格になる購入オプションです。

○EC2起動タイプ
EC2起動タイプはユーザーが管理するEC2インスタンス上でコンテナを実行します。コンテナを実行するEC2インスタンス、ネットワーク、IAMなどを設定すると、ECSがAWS CloudFormationのスタックを作成および実行して、構築したコンテナ実行環境をECSに登録します。EC2起動タイプでは通常のインスタンスと同様に、OSやミドルウェアのアップデート、スケーリングなどのサーバー管理をユーザーで実施する必要があります。
EC2起動タイプの利用料金は、指定したEC2インスタンスタイプに応じて課金されます。インスタンスの起動時間に対して料金が発生するので、インスタンス起動中に多数のタスクが実行されるシステムなどに向いています。

【ECSにおける自動スケーリング】
ECSでは、タスクの数を自動的に増減させるスケーリングを行うことができます。ECS上で設定できる自動スケーリングは「ターゲットの追跡」と「ステップスケーリング」の2種類のポリシーから選択できます。なお、この機能は、起動タイプがAWS FargateとEC2どちらの場合でも利用可能です。



【Amazon ECR(Elastic Container Registry)】
Amazon ECR(Elastic Container Registry)はコンテナイメージを登録・管理するサービスです。ECRに登録されたコンテナイメージをECSが参照し、コンテナ(タスク)を起動できます。ECRのようにコンテナイメージを登録・管理する仕組みを「コンテナレジストリ」といいます。


【Amazon EKS(Elastic Kubernetes Service)】
Amazon EKS(Elastic Kubernetes Service)は、AWSが提供するKubernetesのマネージドサービスです。Kubernetesは、オープンソースのコンテナオーケストレーションプラットフォームで、Amazon ECSと同様に、コンテナの実行・管理を行うことができます。実行環境の起動タイプの選択(EC2かFargate)や、ECRのコンテナイメージの利用など、EKSにおいても同様にサポートされます。

ECSがAWS独自のコンテナオーケストレーションサービスであるのに対し、Amazon EKSはオープンソースのKubernetesをAWS上で運用するためのサービスです。Amazon EKSを利用することで、Kubernetes自体のセットアップの手間や運用の複雑さを軽減することができます。また、すでにKubernetesを利用しているユーザであれば、既存のツールや知識をそのまま活かすことができます。

【EKSの主要要素】
EKSの主要要素には「クラスター」「ノード」「ポッド」があります。

○クラスター
1つ以上のノード(後述)で構成される論理グループです。クラスターの内部は「コントロールプレーン」と「データプレーン」の2つに分けられます。
・コントロールプレーン: クラスターの全体的な管理と制御、ノードの管理などを行う
・データプレーン: ノードが配置される領域

○ノード
コンテナの実行環境です。EC2インスタンスまたはAWS Fargateから選択します。ワーカーノードとも呼ばれます。

○ポッド
EKSで管理されるコンテナの実行単位で、前述のノード上でポッドが実行されます。
ポッドは、単一または複数の関連するコンテナを効率的に、実行・管理するための仕組みを提供します。

[EKSにおける「クラスター」「ノード」「ポッド」の関連図]


【コントロールプレーンへのアクセス設定】
EKSでは、コントロールプレーン内のKubernetes APIサーバが、データプレーン内のノードや管理ツール(kubectl)からの通信を受け付け、クラスター全体の管理や制御を行います。このAPIサーバへの通信は、EKSクラスタの構成時に自動的に作成されるクラスターエンドポイントを介して行われます。このエンドポイントは、デフォルトでインターネットからアクセスが可能な状態です。

コントロールプレーンとのやりとりをVPC内のプライベートな通信に限定し、インターネットを経由した通信(パブリックアクセス)を制限することで、セキュリティを向上させることができます。EKSの管理コンソールでは以下の3種類の設定から選択でき、変更も随時可能です。

・パブリック(デフォルト): エンドポイントへはVPC外(インターネット経由)からアクセス可能、ノードからの通信もVPC外を通る
・パブリックおよびプライベート: エンドポイントへはVPC外(インターネット経由)からアクセス可能、ノードからの通信はVPC内のプライベートアクセスとなる
・プライベート: エンドポイントへはプライベートアクセスのみが許可され、ノードからの通信もVPC内のプライベートアクセスとなる

[クラスターエンドポイントアクセスの設定画面]


なお、プライベートのみに設定した環境で、ノードからコントロールプレーンにプライベートネットワーク経由で通信を行うためには、AWS PrivateLink(インターフェース型のVPCエンドポイント)が必要です。

[プライベート設定時のイメージ]


【EKSクラスタ内のシークレットの暗号化】
EKSクラスタ内の設定情報や各リソースの状態情報、シークレット(例:ログイン認証情報)などの情報は、コントロールプレーン内の専用のデータストア(etcd)に格納されます。etcdのデータはデフォルトでAWSによってディスクレベルで暗号化されますが、より高度なセキュリティが求められる場合、「シークレットの暗号化」オプションを有効にすることで、機密情報に対する追加の暗号化を行うことができます。

[シークレットの暗号化オプションの設定画面]


【EKSにおける自動スケーリング】
EKSには、実行中のアプリケーションの負荷状況に応じてリソース(ポッドやノード)を自動的にスケーリングする機能があります。アプリケーションへのリクエストが集中して負荷が増大した場合にはスケールアウト(リソースの増加)し、負荷が低くなった場合にはスケールイン(リソースの削減)することで、パフォーマンスの維持とコストの最適化を実現することができます。

【EKSのスケーリング機能】
EKSにおいてスケールアウト/インを実現するためには、以下の機能を使用します。

■ Horizontal Pod Autoscaler (HPA)
CPU使用率やメモリ使用量といったメトリクスに基づきポッドの数を自動的に増減させる水平方向のスケーリング機能です。なお、HPAを動作させるには、これらのメトリクスデータを収集するために、別途「Metrics Server」というコンポーネントを導入する必要があります。

■ Cluster Autoscaler
ノードの数を自動的に増減させるスケーリング機能です。HPAによりポッドのスケールアウトが発生した時に、追加されるポッドを実行するだけのリソースが既存のノードに不足していると、追加のポッドは起動できず待ち状態(Pending)になります。このような場合に、Cluster Autoscalerは新しいポッドが必要とするリソースに基づいて新しいノードを追加し、逆に不要なノードがあればそれらのノードを終了します。

【マイクロサービスと疎結合】
■ マイクロサービス
マイクロサービスとは最小限の機能を持つ独立したサービスのことです。例えば、オンラインショッピングサービスの機能を「商品管理機能」「ユーザー管理機能」「ショッピングカート機能」「決済機能」に分け、それぞれが自律して動作するのがマイクロサービスです。
マイクロサービスの主なメリットは、ある機能に障害が発生したりアップデートした場合に他の機能への影響を最小限にできること、機能を別のサービスに流用することが容易になるので開発コストの削減に繋がることなどが挙げられます。
コンテナはマイクロサービスの実現に適しています。ひとつのサービスをひとつのコンテナで実行することで効率的にマイクロサービスを構築できます。
なおマイクロサービスとは反対に、大きな機能を一つに総括したシステムをモノリシックなシステムといいます。


■ 疎結合
疎結合は、サービス間の依存度が低く、各サービスが独立して機能し、変更が他のサービスに影響を及ぼしにくい状態です。マイクロサービスは最小限の機能を持つ独立したサービスなので疎結合の状態です。
反対に、密結合は、サービス間の依存度が高く、変更が他のサービスに広範な影響を及ぼす状態を示します。モノリシックなシステムは密結合の状態です。

上に戻る

Dockerコンテナについて

公開日 2024/02/27

問題:
あるeコマース企業がAWSに新しいオンラインショップを立ち上げる準備をしている。担当者と話をしたところ以下のような要望があった。「商品ページなどの静的コンテンツを安定的に配信する必要がある。カート処理やユーザーのアカウント管理などの動的な処理は現在運用して実績のあるDockerコンテナを使うが、変動するトラフィックに迅速に対応できないと困る。購入履歴やユーザーのアカウント情報はリレーショナルデータベースで安全に管理したい。サーバーの運用管理は減少させ、インフラストラクチャの自動スケーリングとデプロイを簡素化したい。」担当者の希望要件を満たす最も効果的なアーキテクチャはどれか。

こちらの問題について「現在運用して実績のあるDockerコンテナを使う」という要件があるため
「商品ページをAmazon S3でホスティングし、AWS FargateとAmazon EKSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する」が正解と考えたのですが
「商品ページをAmazon S3でホスティングし、AWS FargateとAmazon ECSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する」が正解でした。

解説には以下と書かれていますが、Dockerコンテナの運用実績があるとわざわざ問題文に書いてあるので
Kubernetesで運用していると考えそうですが、どう考えるべきでしょうか?

解説:
正解との違いは、コンテナオーケストレーションにEKSを使用することです。EKSはAWSが提供するKubernetesのマネージドサービスです。現在Kubernetesで運用している場合は、EKSでも既存のツールや知識を活用できますが、新規環境を作る場合は新たに知識やKubernetesクラスタの設定と管理が必要となるため、運用管理の負担が増えます。よって誤りです。

2024/02/29 08:37

Dockerコンテナを使っているが、Kubernetesで運用しているとも、コンテナオーケストレーションを利用しているとも書いてないので、
現在Kubernetesで運用している、とまでは思いませんでした。
いかがでしょうか?


コメント

s shia125

2024/02/29 21:18

ご返信ありがとうございます。 そうなりますと、以下の2択から最適解を選ぶ手がかりがなくなってしまうと思いました。 独自規格を使いたい、OSSを使いたいなどの要件が書いてあれば別ですが・・・。 ・商品ページをAmazon S3でホスティングし、AWS FargateとAmazon ECSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する ・商品ページをAmazon S3でホスティングし、AWS FargateとAmazon EKSで動的処理を実行し、Amazon RDSに購入履歴やユーザーのアカウント情報を保存する

J Jun101

2024/03/30 17:57

私もこの問題はECSに絞り込むことはできない問題だと思います。おそらくですが、EKSがFargateに対応していないときの問題内容だと思います。

この返信に対して
コメントを記入できます

2024/02/29 23:06

「サーバーの運用管理は減少させ」たいとか「デプロイを簡素化したい」って言ってますし、KubernetesでDockerコンテナをServiceとして常駐させるための環境構築やらをするよりもECSでServiceとして起動しておくほうが簡単とかいう話はないですか?


コメント

s shia125

2024/03/02 02:35

この問題を振り返って思ったのですが「現在運用して実績のあるDockerコンテナ」とは ランタイムではなくDockerコンテナのイメージを指していて 運用実績のあるイメージを継続利用する要件と捉えることもできるかと思いました。 もしそうであれば、実績のあるDockerコンテナ(イメージ)を使う要件に対してはEKS/ECSどちらも適切であり 解説いただいた理由を加味して最適解はECSになりそうですね。ご解説ありがとうございました。

この返信に対して
コメントを記入できます

2024/03/01 11:30

「Dockerコンテナ」と「Kubernetes」は類似したシステムではありますが、
厳密には異なるものになるようです。

https://cloud-ace.jp/column/detail229/
※外部サイト

そのため、「Dockerコンテナを使っている=Kubernetesが使える」という式にはなりません。
結果、EKSに切替えた場合は「実績のあるDockerコンテナを使う」という前提要件から外れます。


コメント

s shia125

2024/03/02 02:33

ご返信ありがとうございます。 pinkcammeoさんからも回答いただいたように Kubernetesで運用しているとも、コンテナオーケストレーションを利用しているとも書いてない、 という考え方ですね。

この返信に対して
コメントを記入できます

2024/03/24 15:40

Dockerはkubernetesで非推奨ですので、問題文でDockerがでてきたらECS一択と考えてよいのでは?


コメント

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?