助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 36218
問題を開く
ある会社では、Dockerコンテナの技術を活用した自社のウェブアプリケーションをオンプレミスからAWSに移行しようと考えている。このアプリケーションは、時間帯によってユーザのアクセス数が大幅に変動するため、AWS上でのスケーラブルな環境が求められている。また、担当者は、サーバの運用や管理のオーバーヘッドは最小限に抑えたいと考えている。これらの要件を満たす最適なソリューションはどれか。

正解

既存のコンテナイメージをAmazon ECRのレポジトリに登録し、実行環境としてAWS Fargateを用いたAmazon ECSクラスタ上で運用する。ターゲット追跡スケーリングポリシーを使用して、リソースが自動的に調整されるように設定する

解説

本設問では、以下の要件があります。
・既存コンテナアプリケーションをAWSに移行する
・スケーラブルな環境とする
・サーバの運用や管理のオーバーヘッドは最小限に抑える

・既存コンテナアプリケーションをAWSに移行する
Amazon ECR(Elastic Container Registry)はコンテナイメージを登録・管理するサービスです。ECRに登録されたコンテナイメージをAmazon ECS(Elastic Container Service)が参照し、コンテナ(タスク)を起動できます。これらの用いることで、既存のコンテナイメージをそのままAWS上に移行し、実行できます。

・スケーラブルな環境とする
ECSでは、タスクの数を自動的に増減させるスケーリングを行うことができます。

・サーバの運用や管理のオーバーヘッドは最小限に抑える
AWS Fargateはコンテナ向けのサーバーレスコンピューティングエンジンです。コンテナ実行環境のCPUやメモリのスペック、アクセス権限(IAM)などを設定するだけで、サーバーの環境構築や管理をすることなくコンテナを実行できます。フルマネージドサービスであるECSやECRと組み合わせることで、運用上のオーバーヘッドを最小限に抑えることができます。

したがって正解は、
・既存のコンテナイメージをAmazon ECRのレポジトリに登録し、実行環境としてAWS Fargateを用いたAmazon ECSクラスタ上で運用する。ターゲット追跡スケーリングポリシーを使用して、リソースが自動的に調整されるように設定する
です。

その他の選択肢については、いずれも技術的に実現は可能ですが、実行環境としてEC2インスタンスを使用したり、ユーザ自身がDockerをセットアップするなど、運用上のオーバーヘッドを最小限に抑えるという要件を満たすことができないため、誤りです。

参考

【コンテナ】
「コンテナ」は、アプリケーションとその実行環境(アプリケーション実行環境・ミドルウェア)をひとまとめにし独立したパッケージに包み込んだものです。「コンテナエンジン」は、これらのコンテナを実行するための環境を提供し、コンテナが他のコンテナやサーバー・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は新しいポッドが必要とするリソースに基づいて新しいノードを追加し、逆に不要なノードがあればそれらのノードを終了します。

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


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

上に戻る

誤字

公開日 2023/12/16

選択肢に誤字があります。
「事項する」

スタッフからの返信

s staff_ishii

2023/12/18 10:00

lingling さん ご指摘の点を修正いたしました。 ご報告、誠にありがとうございました。

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