AWS でのプロジェクト:

モノリシックアプリケーションをマイクロサービスに分割する

Amazon Elastic Container Service、Docker、Amazon EC2 を使用した分割方法

はじめに

モノリスのコンテナ化

モノリスのデプロイ

モノリスの分割

マイクロサービスのデプロイ

クリーンアップ

モジュール 4 - マイクロサービスのデプロイ

このモジュールでは、node.js アプリケーションを、Application Load Balancer (ALB) の背後で相互接続されたサービスとしてデプロイします。次に、ALB を使用し、トラフィックをモノリスからマイクロサービスにシームレスに移行します。構築を開始する

アーキテクチャの概要

マイクロサービスをデプロイし、アプリケーションのトラフィックをモノリスから安全に移行するプロセスについて説明します。

トラフィックを切り替える
これが開始時点での設定です。モノリシックの node.js アプリケーションが Amazon ECS のコンテナで実行されています。
マイクロサービスの開始
前のモジュールで構築し、Amazon ECR に送信した 3 つのコンテナイメージを使用して、既存の Amazon ECS クラスターで 3 つのマイクロサービスを開始します。
ターゲットグループを設定する
モジュール 2 と同様に、各サービスのターゲットグループを追加し、ALB ルールを更新して新しいマイクロサービスに接続します。
モノリスをシャットダウンする
ALB 内の 1 つのルールを変更することで、実行しているマイクロサービスへのトラフィックのルーティングを開始します。トラフィックの再ルーティングを確認したら、モノリスをシャットダウンします。

所要時間: 30 分

使用するサービス:

実装手順

以下のステップごとの詳細な手順に従い、マイクロサービスをデプロイします。各ステップの番号をクリックして、セクションを展開してください。

ステップ 1:サービスのタスク定義を記述する
モジュール 2 で起動したクラスターに、3 つの新しいサービスをデプロイします。モジュール 2 と同様に、各サービスに対してタスク定義を記述します

⚐ 注: 単一のタスク定義に複数のコンテナを追加することが可能です。つまり、3 つのマイクロサービスすべてを、単一のサービスから異なるコンテナとして実行できます。ただし、このアプローチでは各コンテナがサービスに比例してスケールする必要があるという、モノリシックな状態のままとなります。目標は 3 つの独立したサービスを持つことです。各サービスは、それぞれのサービスのイメージでコンテナを実行する独自のタスク定義が必要となります。

これらのタスク定義は Amazon ECS コンソールから作成するか、JSON として記述することで高速化できます。タスク定義を JSON ファイルとして記述するには、次の手順に従います。

Amazon Container Services コンソール (Amazon ECS にある) で [タスク定義] をクリックします。

[タスク定義] ページで、[新しいタスク定義を作成する] ボタンをクリックします。

[起動タイプの互換性を選択する] ページで、[EC2] オプション、[次のステップ] の順にクリックします。

[タスクとコンテナの定義を設定する] ページで、[ボリューム] セクションまでスクロールし、[JSON で設定する] ボタンをクリックします。

次のコードスニペットをコピーして JSON フィールドに貼り付け、既存のコードを置き換えます。
[service-name]、[account-ID]、[region]、[tag] のプレースホルダーを置き換えることを忘れないでください。

⚐ 注: 以下のパラメータがタスク定義に使用されます。

Name = [service-name: posts, threads, and users]

Image = [Amazon ECR repository image URL]:latest

cpu = 256

memory = 256

Container Port = 3000

Host Post = 0
```
{
    "containerDefinitions": [
        {
            "name": "[service-name]",
            "image": "[account-id].dkr.ecr.[region].amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[service-name]"
}
```
♻ 以下の手順を繰り返して、各サービスのタスク定義を作成します。

posts

threads

users
ステップ 2:Application Load Balancer を設定する: ターゲットグループ
モジュール 2 と同様に、サービス (posts、threads、users) ごとにターゲットグループを設定します。ターゲットグループによって、トラフィックは指定されたサービスに正しく到達できます。AWS CLI を使用してターゲットグループを設定します。ただし、続行する前に、このチュートリアルで使用されている正しい VPC 名があることを確認してください。

EC2 コンソールの [ロードバランサー] セクションに移動します。

[demo] の横にあるチェックボックスをオンにし、[説明] タブを選択して、VPC 属性 (vpc-xxxxxxxxxxxxxxxxx の形式) を見つけます。
⚐ 注: ターゲットグループを設定する際に、VPC 属性が必要になります。

ターゲットグループを設定する

端末で次のコマンドを入力し、各サービス (投稿、スレッド、ユーザー) のターゲットグループを作成します。さらに、ターゲットグループ (drop-traffic) を作成し、マイクロサービスが完全に実行された後にトラフィックがモノリスに到達しないようにします。[region]、[service-name]、[vpc-attribute] のプレースホルダーを忘れずに置き換えてください。

サービス名: posts、threads、users、drop-traffic
```
aws elbv2 create-target-group --region [region] --name [service-name] --protocol HTTP --port 80 --vpc-id [vpc-attribute] --healthy-threshold-count 2 --unhealthy-threshold-count 2 --health-check-timeout-seconds 5 --health-check-interval-seconds 6
```
ステップ 3:リスナールールを設定する
リスナーは、トラフィックを適切にルーティングするために ALB に送られてくる接続リクエストをチェックします。

現時点では、4 つのサービスすべて (モノリスおよび 3 つのマイクロサービス) が同じロードバランサーの背後で実行されています。モノリスからマイクロサービスに移行するには、マイクロサービスへのトラフィックのルーティングを開始し、モノリスへのトラフィックのルーティングを停止します。

リスナールールにアクセスする

EC2 コンソールの [ロードバランサー] セクションに移動します。

demo という名前のロードバランサーを見つけ、その横にあるチェックボックスをオンにして、ロードバランサーの詳細を表示します。

[リスナー] タブを選択します。

リスナールールを更新する

このタブに一覧表示されるリスナーは 1 つだけです。リスナールールを編集するには、次の手順を実行します。

[ルール] 列で [ルールを表示/編集する] をクリックします。

[ルール] ページでプラス (+) ボタンをクリックします。
[ルールを挿入する] のオプションがページに表示されます。

次のルールテンプレートを使用して、モノリスへのトラフィックを維持するためのルール 1 つと各マイクロサービス用のルール 1 つを含む、必要なルールを挿入します。

IF Path = /api/[service-name]* THEN Forward to [service-name]
例: IF Path = /api/posts* THEN Forward to posts

次の順序でルールを挿入します。

api: /api* forwards to api

users: /api/users* forwards to users

threads: /api/threads* forwards to threads

posts: /api/posts* forwards to posts

[保存] を選択します。

ページの左上の「戻る」矢印をクリックし、ロードバランサーのコンソールに戻ります。
ステップ 4:マイクロサービスをデプロイする
3 つのマイクロサービス (posts、threads、users) をクラスターにデプロイします。3 つのマイクロサービスそれぞれについて次のステップを繰り返します。

Amazon ECS コンソールに移動し、左側のメニューバーから [クラスター] をクリックします。

クラスター [BreakTheMonolith-Demo]、[サービス] タブ、[作成する] の順にクリックします。

[サービスを設定する] ページで、以下のパラメータを編集します (および、以下にリストされていないパラメータのデフォルト値を保持します)。

[起動タイプ] で [EC2] をクリックします。

[タスク定義] で、[値を入力する] ボタンをクリックして、自動的に出る最も高いリビジョン値を選択します。
例: api:1

[サービス名] でサービス名 (posts、threads、または users) を入力します。

[タスク数] で [1] を入力します。

[次のステップ] をクリックします。

[設定ネットワーク] ページの [ロードバランシング] セクションで、次の操作を行います。

[ロードバランサーのタイプ] で [Application Load Balancer] を選択します。

[サービス IAM ロール] で [BreakTheMonolith-Demo-ECSServiceRole] をクリックします。

[ロードバランサー名] で、demo が選択されていることを確認します。

[ロードバランスするコンテナ] セクションで、[ロードバランサーに追加する] ボタンを選択し、次のように編集を行います。

[プロダクションリスナーポート] で、80:HTTP に設定します。

[ターゲットグループ名] で、適切なグループを (posts、threads または users) を選択します。

[次のステップ] を選択します。

[Auto Scaling を設定する] ページで [次のステップ] をクリックします。

[確認] ページで、[サービスを作成する] を選択します。

[サービスを確認する] をクリックします。

すべてのサービスが開始されるまでにかかる時間はほんの数秒です。すべてのサービスとタスクが実行され、アクティブな状態であることを再確認してから次に進みます。
ステップ 5:トラフィックをマイクロサービスに切り替える
現在、マイクロサービスは実行中ですが、まだすべてのトラフィックがモノリスサービスに流れています。トラフィックをマイクロサービスに再ルーティングするには、次の手順を実行してリスナールールを更新してください。

EC2 コンソールの [ロードバランサー] セクションに移動します。

[demo] の横にあるチェックボックスをオンにしてロードバランサーの詳細を表示します。

[リスナー] タブをクリックします。
一覧表示されるリスナーは 1 つだけです。

[ルール] 列で [ルールを表示/編集する] をクリックします。

[ルール] ページで、トップメニューのマイナス (-) ボタンをクリックします。

ルールの横にあるチェックボックスをクリックして、最初のルール (/api* は api に転送) を削除します。

[削除] を選択します。

デフォルトのルールを forward to drop-traffic に更新します。

トップメニューから編集 (鉛筆) ボタンを選択します。

デフォルトルール (HTTP 80: default action) の横にある編集 (鉛筆) アイコンを選択します。

[THEN] 列の編集 (鉛筆) アイコンを選択して、[転送先] を編集します。

[ターゲットグループ] フィールドで、[drop-traffic] を選択します。

[更新する] ボタンをクリックします。

更新したルールの例については、次のスクリーンショットをご参照ください。
モノリスを無効にする: トラフィックがマイクロサービスに流れているので、モノリスサービスを無効にできます。

Amazon ECS のクラスター BreakTheMonolith-Demo-ECSCluster に戻ります。

[サービス] タブで、api の横にあるチェックボックスを選択し、[更新する] をクリックします。

[サービスを設定する] ページで、[タスク数] を見つけて、0 を入力します。

[確認してスキップする] を選択します。

[サービスの更新] を選択します。

Amazon ECS では、サービスによってクラスターにデプロイしたコンテナからの通信を空にしてから、コンテナを停止します。約 30 分後にデプロイメントリストやタスクリストを更新すると、タスクの数が 0 になることを確認できます。サービスはアクティブな状態のままです。何らかの理由でロールバックする必要がある場合は、更新するだけで追加タスクをデプロイできます。

オプションで、api サービスを削除できます。[サービス] タブで、api の横にあるチェックボックスを選択し、[削除する] をクリックして、削除を確認します。

これで、ダウンタイムが発生することなく、node.js をモノリスからマイクロサービスに完全に移行できました。
ステップ 6:デプロイを検証する
サービス URL を見つける: これは、このチュートリアルのモジュール 2 で使用したものと同じ URL です。

EC2 コンソールの [ロードバランサー] セクションに移動します。

[demo] の横にあるチェックボックスをオンにしてロードバランサーの詳細を表示します。

[説明] タブで、DNS 名を見つけ、URL の最後にあるコピーアイコンを選択します。

DNS 名を新しいブラウザのタブまたはウィンドウに貼り付けます。

「リクエストを受信する準備ができました」というメッセージが表示されます。

各マイクロサービスの値を確認する: 要求された URL に基づいて、ALB がトラフィックをルーティングします。各サービスについて確認するには、DNS 名の最後にサービス名を追加するだけです。

http://[DNS name]/api/users

http://[DNS name]/api/threads

http://[DNS name]/api/posts
⚐ 注意: 上記の URL は、モノリスがデプロイされていた時とまったく同じように機能します。このアプリケーションに接続する予定のいずれの API またはコンシューマーも、変更による影響を受けることはないため、これは非常に重要です。モノリスからマイクロサービスに移行する際、インフラストラクチャの他の部分の変更は必要ありません。

API のテストに Postman のようなツールを使用することもできます。

次のステップ: クリーンアップ

ステップ 1:サービスのタスク定義を記述する

ステップ 2:Application Load Balancer を設定する: ターゲットグループ

ステップ 3:リスナールールを設定する

ステップ 4:マイクロサービスをデプロイする

ステップ 5:トラフィックをマイクロサービスに切り替える

ステップ 6:デプロイを検証する