1. AWS EKS上での3層アーキテクチャデプロイメントの概要とプロジェクト紹介 [1]

  1. 動画の目的と主題:

    1. 3層アーキテクチャモデルへのディープダイブと、それをAWS EKS (Kubernetesクラスター)にデプロイする方法を理解することである [1]。
    2. 説明のために、デモ用Eコマースプロジェクト「Robot Shop」を使用する [3]。
    3. このプロジェクトを通じて、Dockerファイル、Kubernetesリソース、Helmチャートの書き方、およびEKSプラットフォームへのデプロイメントを学ぶ [2]。

  2. デモプロジェクト「Robot Shop」の特徴:

    1. ロボットとAI製品を販売するデモ用Eコマースプロジェクトである [3]。
    2. 様々なマイクロサービスで構築されており、各マイクロサービスは異なるプログラミング言語で書かれている [4]。
    3. 複数のデータベース（MongoDB、MySQL）を使用し、RabbitMQ、インメモリデータストアとしてRedisを使用している [5]。
    4. リアルタイムプロジェクトに類似した機能（登録、ログイン、カタログ閲覧、カート追加、配送計算、支払い）を備えている [7]。
    5. このプロジェクトは元々IBMのInstana（アプリケーションパフォーマンス監視ツール）のデモ用に作成されたものである [15]。

  3. プロジェクトの準備と学習範囲:

    1. 筆者はこのデモプロジェクトをフォークし、EKSに簡単にデプロイできるように変更を加えた [16]。
    2. 学習範囲は、3層アーキテクチャの理解、高レベル設計の学習、およびマイクロサービス、データベース（Redis、RabbitMQ、Nginxを含む）の構成理解を含む [18]。

  4. EKSクラスターの準備:

    1. 高レベル設計の説明の前に、EKSクラスターを作成する必要がある [21]。
    2. 筆者はローカルシステムで実行中のアプリケーションを停止し、単一のコマンドでEKSクラスターの作成を開始する [22]。
    3. EKSクラスターの作成には時間がかかるため、デモを行う場合も同様に先に作成を開始することが推奨される [24]。
    4. クラスター作成にはeksctl、kubectl、AWS CLIがインストールされていることが前提条件である [26]。
    5. 実行されたコマンドはeksctl create cluster --name demo-cluster-eks-robot-shopである [28]。

2. 3層アーキテクチャモデルの基本とRobot Shopの高レベル設計 [29]

  1. 3層アーキテクチャモデルの定義:

    1. 3層アーキテクチャは、Instagram、Facebook、Amazonなどの日常的に使用されるリアルタイムアプリケーションで非常に一般的である [30]。
    2. これは、3つの異なるレイヤーを使用して書かれたアプリケーションである [32]。
    3. 3つのレイヤーは以下の通りである [33]:
    4. フロントエンド (Presentation Layer): ユーザーインターフェース (UI) である。
    5. バックエンド (Logic Layer): 開発者がJava、Python、GoLangなどでアプリケーションロジックを記述する部分である。
    6. データベース (Data Layer): すべての詳細情報（画像、説明、価格など）が保存される場所である。

  2. レイヤー間の連携:

    1. ユーザーがUI（プレゼンテーション層）でアクションを実行すると、バックエンド（ロジック層）がフロントエンドとデータベースの間でメディエーターとして機能する [39]。
    2. ロジック層はデータベースから製品の詳細を取得し、それをフロントエンドに表示する [40]。

  3. Robot Shopのワークフロー分析とマイクロサービスへの変換:

    1. 高レベル設計を理解することは、コンポーネントがなぜ使用されているかを理解する上で非常に重要である [43]。
    2. ワークフローは主にユーザーワークフローとアプリケーションワークフローの2つに分けられる [44]。

  4. ユーザーワークフローの詳細:

    1. 初期アクセス: ユーザーは登録ページまたはログインページに移動する [46]。
    2. カタログページ: ログイン後、カタログページに移動する。このデモプロジェクトにはAI製品とロボットの2種類のカタログがある [47]。
    3. 製品選択とカート: ユーザーはロボットを選択し、評価を確認し、カートに追加する [50]。
    4. 支払いと配送: 支払いセクションに進み、配送詳細を提供し、注文が完了すると注文IDを受け取る [51]。

  5. モノリシック vs マイクロサービス:

    1. カタログ、評価、カート、支払い、配送といった各機能にはロジックが必要であり、開発者がコードを記述する必要がある [55]。
    2. これらのロジック全体を単一のアプリケーションまたは単一のバイナリとして記述した場合、それはモノリシックアプリケーションと呼ばれる [56]。
    3. マイクロサービスアーキテクチャは、これらのコンポーネントを個別にデプロイ可能にするアーキテクチャであり、今日の標準的なプラクティスである [59]。

  6. マイクロサービスアーキテクチャの利点:

    1. 独立した変更とデプロイ: カタログにのみ変更を加える場合、モノリシックでは他のコンポーネントへの影響を検証する必要があるが、マイクロサービスではカタログ関連のみをテストすればよい [62]。
    2. 大規模な複雑性の回避: Amazonのような大規模な企業（500〜1,000以上のマイクロサービスを持つ）では、モノリシックアプリケーションの単一のコード行が他の数百万行のコードに影響を与える可能性があり、徹底的な回帰テストが必要になる。マイクロサービスはこれを回避する最良の方法である [65]。

3. Robot Shopのマイクロサービスとデータベース構成 [69]

  1. マイクロサービスの構成:

    1. Robot Shopはマイクロサービスアーキテクチャモデルに従って書かれており、GitHubリポジトリにはshipping, ratings, payments, catalog, cartといった各コンポーネントのフォルダが確認できる [69]。
    2. プログラミング言語の多様性:
    3. 支払いはPythonで書かれている [70]。
    4. 評価はPHPで書かれている [70]。
    5. 配送サービスはJavaで書かれている [100]。
    6. ディスパッチサービスはGoLangで書かれている [108]。
    7. すべてのマイクロサービスを単一の言語で書くことも可能であるが、このプロジェクトでは異なる言語を使用することで、DevOpsエンジニアが異なるDockerファイルの書き方を学べるようにしている [72]。

  2. データベースの役割と種類:

    1. プレゼンテーション層: ユーザーインターフェースはAngularで書かれている [79]。
    2. ロジック層: cart, catalog, payments, shipping, userなどの異なるマイクロサービスで構成されている [81]。
    3. データ層（データベース）の必要性:
    4. カタログ: 製品の画像、説明、コストなどの詳細をフェッチするためにデータベースが必要である [83]。
    5. ユーザー: ユーザー名とパスワードを検証し、ユーザー詳細を保存するためにデータベースが必要である [85]。
    6. カート: ユーザーがログアウトしたりアプリケーションがダウンしたりしても、カートに追加された製品を保持するためにインメモリデータストア（Redis）が必要である [87]。

  3. インメモリデータストア（Redis）の選択理由:

    1. インメモリキャッシュ（プログラミング言語に付属）を使用すると、アプリケーションがダウンした場合にカートの詳細が失われる可能性がある [91]。
    2. そのため、インメモリキャッシュの代わりにインメモリデータストアであるRedisを使用し、KubernetesではStatefulSetとして作成される [92]。

  4. データベースの具体的な種類:

    1. ユーザー詳細: MongoDBが使用されている [93]。
    2. カタログ/評価: MySQLが使用されている [93]。
    3. このプロジェクトでは、KubernetesクラスターへのMongoDBとMySQLのデプロイ方法を理解するために、意図的に2種類のデータベースを使用している [94]。

  5. コンポーネントの総数:

    1. 全体として、6つのマイクロサービス、2つのデータベース、および1つのインメモリデータストア（Redis）が存在する [95]。

4. DockerファイルとHelmチャートによるデプロイ準備 [97]

  1. EKSクラスターのステータス:

    1. EKSクラスターはすでに作成済みであり、デプロイの準備が整っている [97]。
    2. ただし、デプロイにはいくつかの前提条件の構成が必要である [98]。

  2. Dockerファイルの構造:

    1. 配送サービス (Java): dbnイメージを使用し、Mavenをインストールしてアプリケーションをビルドする。マルチステージDockerファイルでopenjdkイメージを使用し、Javaコマンドでアプリケーションを開始する [100]。
    2. 評価サービス (PHP): PHPベースイメージを使用し、HTMLページをコピーし、composerを実行する [105]。
    3. ディスパッチサービス (GoLang): GoLangプロジェクト用のDockerファイルが提供されている [107]。
    4. これらのDockerファイルは、異なるプログラミング言語のアプリケーションのビルド方法を説明している [106]。

  3. Helmチャートの利用:

    1. 個々のDockerコンテナとしてデプロイする代わりに、EKSフォルダ内にHelmチャートが作成されている [109]。
    2. Helmチャートのテンプレートフォルダには、各コンポーネントのKubernetesデプロイメントファイルとサービスファイルが含まれている [110]。
    3. コンポーネントリスト: cart, catalog, dispatch, MongoDB, MySQL, payments, RabbitMQ, ratings, Redis, shipping, userのそれぞれにデプロイメントファイルとサービスファイルがある [111]。
    4. デプロイメントファイルでは、コンテナポートを提供する必要がある [114]。
    5. このプロジェクトでは、Pod AffinityやWebhookなどの高度なKubernetes構成は不要である [116]。
    6. values.yamlファイルはほとんど空であるが、イメージの詳細（リポジトリとバージョン）に焦点を当てている [117]。
    7. すべてのDockerイメージはrobot-shopというDockerリポジトリにビルドされ、最新バージョンからプルされる [118]。

5. EKSデプロイメントの前提条件構成 (OIDC/IAM, ALB, CSI) [121]

5.1. 前提条件の確認とOIDC/IAM構成 [121]

  1. 前提条件の確認:

    1. eksctl、AWS CLI、kubectlはすでにインストール済みである [122]。
    2. EKSクラスターもすでにインストール済みである [126]。

  2. OIDC IAM構成の必要性:

    1. EKSにデプロイされたPod（例：RedisのStatefulSet）が、AWSの他のサービス（例：永続ボリューム用のEBS）と通信する必要がある [128]。
    2. これを実現するために、KubernetesのサービスアカウントをAWS IAMと統合する（IRSA: IAM Roles for Service Accounts） [130]。
    3. これにより、Kubernetes PodがAWSリソースへのアクセス権を取得できる [131]。

  3. OIDC構成の手順:

    1. クラスター名（demo-cluster-eks-robot-shop）とリージョン（US West 1）を設定する [132]。
    2. OIDC IDを取得し、OIDCプロバイダーが作成されていないことを確認する [137]。
    3. eksctlコマンドを使用してOIDCプロバイダーを作成する [144]。

5.2. ALB Ingress Controllerの構成 [147]

  1. ALBの必要性:

    1. Robot Shopアプリケーションを外部に公開するためにALB（Application Load Balancer）が必要である [147]。
    2. EKSでは、IngressとIngress Controllerを使用してアプリケーションを公開する [148]。

  2. ALB Ingress Controllerのデプロイ手順:

    1. IAMポリシーの作成: 最初にIAMポリシーを作成する [150]。
    2. IAMロールの作成: ダウンロードしたIAMポリシーを使用してIAMロールを作成する [151]。
    3. サービスアカウントの作成: ALB Controller用のサービスアカウントを作成する [151]。
    • クラスター名、kube-systemネームスペース、アカウントIDを更新する必要がある [151]。
    • ALB Controllerはすべてのネームスペースを監視するため、kube-systemネームスペースにデプロイされる [154]。
    • CloudFormationスタックの失敗時には、スタックを削除してから再作成する必要がある [158]。
    1. Helmチャートの追加とインストール: ALB ControllerのHelmチャートを追加し、インストールする [161]。
    • クラスター名、リージョン（US West 1）、VPC IDを更新する必要がある [164]。
    1. 検証: Helmチャートのインストール後、ALB ControllerのPodが稼働中であることを確認する [174]。

  3. EKSクラスターのタイプ:

    1. 今回のデプロイでは、以前のデモ（Day 22）で使用したFargateではなく、EC2インスタンスを持つEKSを使用している [177]。
    2. EC2インスタンスを使用する理由:
    3. FargateインスタンスでのEKSのデプロイをカバーしていなかったため [178]。
    4. Redisコンポーネントがnet admin権限を必要とし、Fargateがこれをサポートしていないため [178]。
    5. 永続ボリュームとしてEBSを使用しており、Fargateがこれをサポートしていないため [179]。

5.3. EBS CSI Driverの構成 [181]

  1. CSI Driverの必要性:

    1. Redisは通常、永続的な状態を維持するためにStatefulSetとしてデプロイされ、永続ボリューム（PV）を必要とする [184]。
    2. AWS上では、PVとしてEBSまたはEFSが使用され、今回はEBSを使用する [184]。
    3. Redisのデプロイ時には、Persistent Volume Claim (PVC)とStorage Classが作成される [185]。
    4. Storage Classが自動的にEBSボリュームを作成し、Redis StatefulSetにアタッチするためには、EBS CSIプラグインが必要である [186]。

  2. CSI Driverのデプロイ手順:

    1. IAMサービスアカウントの作成: eksctlコマンドを使用してIAMサービスアカウントを作成する [188]。
    • クラスター名とAWSアカウントIDを更新する必要がある [191]。
    1. アドオンの作成: IAMサービスアカウントの作成後、アドオンを作成する [193]。
    2. 検証: CSI Driverの作成が完了したことを確認する [198]。

6. Helmチャートによるアプリケーションのデプロイとアクセス [202]

  1. Helmチャートによるデプロイ:

    1. Dockerファイルや個々のKubernetesマニフェストをデプロイする代わりに、Helmチャートを使用してプロジェクト全体をデプロイする [201]。
    2. ネームスペースの作成: 最初にrobot-shopというネームスペースを作成する [202]。
    3. Helmコマンドの実行: Helmチャートコマンドを実行してデプロイする [203]。
    4. Helmチャートの利点:
    5. Kubernetesリソースを簡単にデプロイおよび管理できる [219]。
    6. values.yamlを使用することで、イメージリポジトリやバージョンなどの値を一元的に管理し、再利用性を高めることができる [215]。

  2. Podのステータス確認:

    1. kubectl get pods -n robot-shopを実行し、すべてのPodがRunning状態であることを確認する [222]。

  3. アプリケーションの外部公開（Ingress）:

    1. Kubernetesでアプリケーションを外部に公開する方法は、Load BalancerタイプのServiceを使用するか、IngressベースのServiceを使用するかの2つがある [225]。
    2. Ingressがより一般的に使用されるアプローチであるため、すでに作成したALB Controllerを使用してIngressを構成する [227]。
    3. Ingressの適用: ing.yamlファイルを使用してIngressを適用する [228]。
    • Ingressは、Webサービス（ポート8080）をALB Controllerを介して公開するために作成される [231]。
    1. ALBのプロビジョニング確認: kubectl get Ingress -n robot-shopを実行してもアドレスはすぐに割り当てられないため、AWSコンソールでロードバランサーのステータスを確認する [233]。
    2. ロードバランサーのステータスがProvisioningからActiveに変わるのを待つ必要がある [241]。

  4. アプリケーションへのアクセス:

    1. ロードバランサーのステータスがActiveになった後、DNS名をクリックしてアプリケーションにアクセスする [259]。
    2. IBM STS Robot Shopが正常に稼働していることが確認される [260]。
    3. ユーザーは登録、ログイン、AI製品の使用、評価の確認、カートへの追加、支払いなど、すべてのワークフローを試すことができる [261]。

  5. 後処理とCI/CDに関する言及:

    1. デモ完了後、クラスターを削除することを忘れてはならない。削除コマンドはEKSクラスターセットアップドキュメントに共有されている [262]。
    2. CI/CDパイプライン:
    3. アーキテクチャとDockerファイルを理解すれば、CI/CDは容易である [245]。
    4. 理想的には、各マイクロサービスに1つのCI/CDパイプラインが必要である [247]。
    5. 同様に、理想的には各コンポーネント（カタログ、製品、ディスパッチなど）ごとにHelmチャートを作成すべきである [251]。
    6. 複雑なため、この動画ではCI/CDパイプラインのデプロイは省略されている [246]。

  6. 結論:

    1. 3層アーキテクチャモデルと、それがリアルタイムでどのように機能するかを理解できた [265]。
    2. このプロジェクトを自力でデプロイできれば、それは大きな成果である [267]。