このモジュールでは、node.js アプリケーションをいくつかの関連するサービスに分割し、各サービスのイメージを Amazon Elastic Container Registry (Amazon ECR) リポジトリにプッシュします。 構築を開始する
最終的なアプリケーションアーキテクチャでは、Amazon Elastic Container Service (Amazon ECS) と Application Load Balancer (ALB) を使用します。
a.クライアント
クライアントがポート 80 経由でトラフィックリクエストを行います。
b.ロードバランサー
ALB は、外部トラフィックを適切なサービスにルーティングします。ALB は、クライアントリクエストを調査し、ルーティングルールに基づきながら、このリクエストを適合するターゲットグループのインスタンスとポートに転送します。
c.ターゲットグループ
各サービスには、そのサービスのために実行されているコンテナごとのインスタンスとポートを記録するターゲットグループがあります。
d.マイクロサービス
Amazon ECS は、EC2 クラスター全体で各サービスをコンテナにデプロイします。各コンテナは単一の機能のみを処理します。
クラッシュの隔離
優秀なエンジニアリング企業であっても、本番環境で致命的なクラッシュが起こる可能性があり、実際に起こっています。クラッシュを適切に処理するためのすべての標準的なベストプラクティスに加えて、このようなクラッシュの影響を制限する方法の 1 つにマイクロサービスの構築があります。優れたマイクロサービスアーキテクチャとは、サービスのある微小な断片がクラッシュした場合、サービスのその部分のみが停止することを意味します。他のサービスは引き続き正常に機能します。
セキュリティのための隔離
モノリシックアプリケーションでは、アプリケーションの機能の 1 つでリモートコード実行を許す脆弱性などのセキュリティ侵害が起こった場合、攻撃者がそのシステムの他のすべての機能にもアクセスできると想定する必要があります。これは危険です。例えば、アバターのアップロード機能に内在するセキュリティ上の問題が原因となり、データベースのユーザーパスワードが盗まれる可能性があります。Amazon ECS を使用して機能をマイクロサービスに分割することにより、各サービスに固有の AWS Identity and Access Management (IAM) ロールを持たせ、AWS リソースへのアクセスを保護できます。マイクロサービスのベストプラクティスに則っていれば、攻撃者がサービスに侵入した場合でも、アクセスできるのは侵入したサービスのリソースのみです。他のサービスが提供する他のリソースには、再びそのサービスにも侵入しなければアクセスできません。
独立したスケーリング
機能をマイクロサービスに分割すると、各マイクロサービスクラスで使用されるインフラストラクチャの規模とインスタンスの数を、独立してスケールアップおよびスケールダウンできます。これにより、特定機能のためのコストが計測しやすくなります。また、優先して最適化すべき機能を発見することにも役立ちます。仮に、一つの固有な機能にリソースの要件に関する問題があったとしても、他の機能には影響はおよばず、パフォーマンス上の信頼性を維持することができます。
開発速度
マイクロサービスは、開発におけるリスクを低減するため、チームは構築時間を短縮できます。モノリスで新しい機能を追加する場合、モノリスに含まれる他のすべての機能に影響を与える可能性があります。開発者は、追加するすべてのコードについて影響を注意深く検討し、どのような障害も生じないことを確認する必要があります。一方、適切なマイクロサービスアーキテクチャでは、新しい機能のための新しいコードは、新しいサービスとなります。開発者は、2 つのマイクロサービス間の接続を明示的に記述している場合を除き、自分の記述したコードが既存のコードにまったく影響を与えないことを確信できます。
以下に示すステップバイステップの手順通り、モノリスを分割します。各ステップの番号をクリックして、セクションを展開してください。
-
ステップ 1:ECR リポジトリをプロビジョニングする
前の 2 つのモジュールでは、単一のサービスと単一のコンテナイメージリポジトリを使用して、アプリケーションをモノリスとしてデプロイしました。アプリケーションを 3 つのマイクロサービスとしてデプロイするには、Amazon ECR で 3 つのリポジトリ (サービスごとに 1 つ) をデプロイする必要があります。
サービスは以下の 3 つに分割します。
- users
- threads
- posts
各サービスに関し次の手順を繰り返して、3 つのレポジトリを作成します。
- Amazon ECR コンソールを開きます。
- [リポジトリを作成] を選択します。
- [レポジトリの作成] ページにある [レポジトリ名] フィールドで、サービス (posts、threads、users) 用にレポジトリを作成します。
⚐ 注: [タグの不変性] オプションには、デフォルト設定を維持します。
これで Amazon ECR に 4 つのリポジトリが作成されました。作成した各マイクロサービスのレポジトリ情報を記録しておきます。この情報は、以後のステップで必要になります。必要となる情報は、次のような書式です。
[account-id].dkr.ecr.[region].amazonaws.com/[service-name]
-
ステップ 2:AWS で Docker を認証する (オプション)
各サービス用のイメージを構築およびプッシュするには、Docker へのアクセス権が必要となります。このチュートリアルを、それぞれ異なる時刻で実施している場合、Docker からログアウトされる可能性があります。その場合は、次のステップ通りに、Docker にログインし直してください。
- 次のコマンドを実行します。$(aws ecr get-login --no-include-email --region [your-region])
[your-region] は次の例のように置き換えます: $(aws ecr get-login --no-include-email --region us-west-2)
認証に成功すると、[ログインに成功しました] といった確認メッセージが表示されます。
- 次のコマンドを実行します。$(aws ecr get-login --no-include-email --region [your-region])
-
ステップ 3:各サービスのイメージをビルドしタグを付ける
プロジェクトフォルダ amazon-ecs-nodejs-microservices/3-microservices/services 内のフォルダに、各サービスのファイルが保存されます。各マイクロサービスが、本質的に前のモノリシックサービスのクローンであることが確認できます。
各サービスとモノリシック API サービスの db.json ファイルを比較することで、各サービスがどのように特化されているかを確認できます。従来では、各サービス、posts、threads、users は、単一のデータベースファイルにすべて保存されていました。現在は、各サービスは個別のデータベースファイルに保存されるようになっています。
ターミナルを開き、パスを ~/amazon-ecs-nodejs-microservices/3-microservices/services に設定します。
各イメージを構築しタグを付ける
- ターミナルから、docker build -t [service-name] ./[service-name] を実行します。
[service-name] は、たとえば以下のように置き換えます: docker build -t posts ./posts
- 構築が完了したら、リポジトリにプッシュするため、イメージにタグ付けします。
docker tag [service-name]:latest [account-ID].dkr.ecr.[region].amazonaws.com/[service-name]:v1
[service-name]、[account-ID]、[region] の部分は、次の例のように置き換えます: docker tag posts:latest [account-id].dkr.ecr.us-west-2.amazonaws.com/posts:v1
- 次のようにイメージを ECR にプッシュします: docker push [account-id].dkr.ecr.[region].amazonaws.com/[service-name]:v1
[service-name]、[account-ID]、[region] を前出同様に置き換えてください。
ECR リポジトリに移動すると、v1 のタグが付けられたイメージが確認できます。
♻ 各マイクロサービスイメージについて、これらのステップを繰り返します。
⚐ 注意: 必ず 3 つのすべてのイメージをビルドし、タグを付けてください。
- ターミナルから、docker build -t [service-name] ./[service-name] を実行します。
