このモジュールでは、node.js アプリケーションを相互に連結されたいくつかのサービスに分割し、各サービスのイメージを Amazon ECR リポジトリにプッシュします。 構築を開始する
最終的なアプリケーションアーキテクチャでは、Amazon Elastic Container Service と Application Load Balancer を使用します。
a. クライアント
クライアントはポート 80 を介してトラフィックリクエストを行います。
b. ロードバランサー
Application Load Balancer (ALB) は、外部トラフィックを正しいサービスにルーティングします。ALB はそのクライアントリクエストを検査し、ルーティングルールを使用して、ルールに一致するターゲットグループのインスタンスとポートにリクエストを送ります。
c. ターゲットグループ
各サービスには、そのサービスのために実行されている各コンテナのインスタンスとポートを追跡するターゲットグループがあります。
d. コンテナ化されたサービス
Amazon Elastic Container Service (Amazon ECS) は、各サービスを EC2 クラスター全体のコンテナにデプロイします。各コンテナは単一の機能しか処理しません。
クラッシュの分離
最高のエンジニアリング組織でさえも、本番環境で致命的なクラッシュを引き起こすことがあります。クラッシュに正しく対処するための標準的なベストプラクティスのすべてに従うことに加え、このようなクラッシュの影響を抑えることができるアプローチの 1 つにマイクロサービスの構築があります。良好なマイクロサービスアーキテクチャとは、マイクロサービスの一部がクラッシュする場合、サービスのその部分だけがダウンすることを意味します。残りのサービスは引き続き正常に機能することができます。
セキュリティの分離
モノリシックアプリケーションでは、アプリケーションの 1 つの機能に、例えばリモートでのコードの実行を許可する脆弱性といったセキュリティ侵害がある場合、攻撃者がシステムのその他すべての機能にもアクセスできると想定する必要があります。これは、例えば最終的にユーザーパスワード付きデータベースが侵害されることになるセキュリティ問題がアバターアップロード機能にある場合に危険となり得ます。Amazon ECS を使用した機能のマイクロサービスへの分割は、各サービスに独自の IAM ロールを付与することによって AWS のリソースへのアクセスをセキュア化することを可能にします。マイクロサービスのベストプラクティスに従うと、攻撃者が 1 つのサービスを侵害した場合でも、そのサービスのリソースに対するアクセス権を得るだけで、他のサービスに侵入しないかぎり、他のリソースに平行してアクセスすることはできません。
独立したスケーリング
機能がマイクロサービスに分割されると、各マイクロサービスクラスによって使用されるインフラストラクチャの量とインスタンスの数は、個別に拡大縮小することができます。これは、特定の機能のコストを測定する、最初に最適化する必要がある機能を特定する、およびある特定の機能がそのリソースのニーズを制御できなくなった場合に、他の機能に対してパフォーマンスを信頼できる状態に保つことを容易にします。
開発速度
マイクロサービスは開発におけるリスクを低減するため、チームはより迅速に構築を行えるようになります。モノリスでは、新しい機能の追加がモノリスに含まれるその他すべての機能に影響を与える可能性があります。開発者は、追加するコードの影響を慎重に検討し、それらが何も壊さないことを確実にする必要があります。一方、適切なマイクロサービスアーキテクチャには、新しいサービスに投入される新しい機能のための新しいコードがあります。開発者は、2 つのマイクロサービス間の関連性を明示的に記述しない限り、記述するコードのいずれも、実際に既存コードに影響を与えることができないという確信を持つことができます。
以下のステップバイステップ手順に従って、モノリスを分割します。各ステップの番号をクリックして、セクションを展開してください。
-
ステップ 1: ECR リポジトリをプロビジョニングする
前の 2 つのステップでは、単一のサービスと単一のコンテナイメージリポジトリを使用して、アプリケーションをモノリスとしてデプロイしました。アプリケーションを 3 つのマイクロサービスとしてデプロイするには、Amazon ECR に 3 つのリポジトリ (各サービスに 1 つずつ) をプロビジョニングする必要があります。
3 つのサービスは次のとおりです。
- users
- threads
- posts
リポジトリを作成する:- Amazon ECR コンソールに移動します。
- [Create Repository] (リポジトリの作成) を選択します。
- リポジトリ名:
- users
- threads
- posts
- users
- リポジトリ情報 [account-id].dkr.ecr[region].amazonaws.com/[service-name] を記録します。
♻ マイクロサービスごとにこれらのステップを繰り返します。
これで Amazon ECR に 4 つの リポジトリが作成されました。
-
ステップ 2: AWS で Docker を認証する (オプション)
このワークショップのモジュール 1 を最近修了した場合は、このステップをスキップできます。
- aws ecr get-login --no-include-email --region [region]
(例: aws ecr get-login --no-include-email --region us-west-2) を実行します。
docker login -u AWS -p ... で始まる大量の出力を受け取ります。この出力全体をコピーし、貼り付けて、ターミナルで実行してください。
[Login Succeeded] (ログイン成功) と表示されます。
⚐ 注意: このログインが成功しない場合は、-e none フラグを廃止した Docker の新しいバージョンを使用していることが原因である可能性があります。これを修正するには、出力をテキストエディタに貼り付け、出力の最終部から -e none を削除して、更新された出力をターミナルで実行します。
- aws ecr get-login --no-include-email --region [region]
-
ステップ 3: 各サービスのイメージを構築してプッシュする
プロジェクトフォルダ amazon-ecs-nodejs-microservices/3-microservices/services 内に、各サービスのファイルが格納されたフォルダが作成されます。各マイクロサービスが、本質的にはその前のモノリシックサービスのクローンであることに注目してください。
各サービスとモノリシック api サービス内の db.json ファイルを比較することによって、各サービスが現在どのように専門化されているかを確認することができます。以前、posts、threads、および users はすべて単一のデータベースファイルに格納されていました。現在は、各リポジトリがそれぞれサービス用のデータベースファイルに格納されています。
ターミナルを開き、GitHub コードの 3-microservices/services セクションへのパスを~/amazon-ecs-nodejs-microservices/3-microservices/services に設定します。
各イメージを構築してタグ付けする
- ターミナルで docker build -t [service-name]/[service-name] (例: docker build -t posts ./posts) を実行します。
- 構築が完了したら、リポジトリにプッシュできるようにイメージに次のタグ、docker tag [service-name]:latest [account-id].dkr.ecr[region].amazonaws.com/[service-name]:v1 (例: docker tag posts:latest [account-id].dkr.ecr.us-west-2.amazonaws.com/posts:v1) を付けます。
- ECR にイメージをプッシュするために docker push (docker push [account-id].dkr.ecr[region].amazonaws.com/[service-name]:v1) を実行します。
ECR リポジトリに移動すると、v1 でタグ付けされたイメージが表示されます。
♻ マイクロサービスイメージごとにこのステップを繰り返します。
⚐ 注意: 3 つすべてのイメージを構築し、タグ付けするようにしてください。