Landbay が GitOps を Amazon Elastic Kubernetes Service とともに使用

デジタル融資の進化する環境において、英国の賃貸住宅市場で受賞歴を有する住宅ローン融資業者である Landbay は、自社のデジタルインフラストラクチャに革命を起こしています。クラス最高レベルのブローカープラットフォームが引受業務をサポートする Landbay のプラットフォームは AWS のサービス上に構築され、約 60 個のマイクロサービスで構成されており、3 層アーキテクチャに従って、ウェブサーバー、Amazon Elastic Kubernetes Service (Amazon EKS)、および多層データレイヤーを組み合わせています。AWS クラウドサービスの力とオープンソースプロジェクトを組み合わせることで、Landbay はこの新しいアプローチを活用して、Amazon Elastic Kubernetes Service をベースとするクラス最高レベルのアーキテクチャを立ち上げることができました。

GitOps の利点

マイクロサービスアーキテクチャが注目されるにつれて、GitOps がこのデプロイメカニズムの新しい標準として登場しました。Cloud Native Computing Foundation (CNCF) 内で、Flux と ArgoCD という 2 つの注目すべき製品が登場しました。Landbay は、カスタムリソース定義 (CRD) を公開してデプロイ、Helm リリース、Kustomizations などを定義することで、Kubernetes とネイティブ統合する点を評価して、Flux を選択しました。これにより、ソフトウェアエンジニアは Kubernetes を習得できるようになり、エコシステム内で Flux がどのように適合するかをよりシームレスに理解できるようになりました。

ソリューションの概要

Landbay の GitOps 実装を包括的に理解できるように、主要なアーキテクチャコンポーネントと AWS エコシステム内でのそれらの関係を確認してみましょう:

• Amazon Elastic Container Registry (ECR): Landbay は、Helm チャートと Docker イメージの保存に Amazon ECR を活用しています。
• 外部 DNS と AWS Elastic Load Balancing コントローラー: これらのコントローラーは、Route53 とロードバランサーを設定するために使用され、Kubernetes イングレスへの外部アクセスを実現します。
  
• AWS Secrets Manager の統合: アーキテクチャとセキュリティ上の理由から、Landbay は外部シークレットコントローラーなどの外部ツールを使用するのではなく、AWS Secrets Manager との直接統合を選択しました。これは、AWS の責任共有モデルと整合的であり、ソリューションの全体的なセキュリティ体制を強化します。
  
• Terraform 設定管理: Terraform を使用すると、ConfigMap を提供し、主要な設定項目 (エンドポイント、サブネット CIDR など) を要約することで、ギャップを埋めることができます。その後、Flux は、構築後の機能を通じて config-map を使用できます (図 2 を参照)。
  

Landbay の Kubernetes 環境とデータアーキテクチャ

Landbay は Terraform を積極的に採用しており、そのインフラストラクチャはすべて、Infrastructure as Code (IaC) でコード化されています。このアプローチにより、テスト環境と本番環境が確実に同期され、インフラストラクチャのすべての変更が、標準のソフトウェア開発ライフサイクルプロセスを通過するようになります。

Amazon EKS のアップグレード中にダウンタイムをゼロにするために、Landbay は、それぞれが特定のアベイラビリティーゾーンをターゲットとする 3 つのマネージドノードグループを持つ EKS マネージドノードグループを使用します。この設定により、Amazon Elastic Block Store (EBS) CSI ドライバーによって促進される永続ボリュームを利用できます。さらに、Landbay は topologySpreadConstraints (DoNotSchedule) を使用して、StatefulSets がアベイラビリティーゾーン全体に分散されるようにします。

重要なサービスで優先度の低いデプロイを排除するには、カスタム優先度クラスを使用します。

テスト環境でのコストを削減するために、Landbay は Terraform と Amazon EKS マネージドノードグループを通じて Amazon EC2 スポットインスタンスの力を活用します。

最後に、Landbay はアタックサーフェスを大幅に削減する Bottlerocket を採用しました。Kubernetes オペレーターは、ウェーブ の概念を使用してクラスター内のノードを段階的にアップグレードするために使用されます。ルートファイルシステムへのアクセスはロックダウンされていますが、IAM および Systems Manager (SSM) との統合により、Landbay の基本要件が満たされます。

Amazon EKS アドオン

Amazon Virtual Private Cloud (Amazon VPC) CNI プラグインに加えて、Landbay は次のアドオンを実行します:

1. CoreDNS: クラスター内で DNS サービスが確実に解決されるようにします
2. KubeProxy: Kubernetes 内でのサービス検出とネットワークを支えます。
   
3. Amazon VPC CNI と enableNetworkPolicy: ネットワークポリシーの強制を可能にし、Landbay が名前空間とポッドへのさまざまなアクセスを安全に保護するのに役立ちます。
   
4. Amazon EBS CSI ドライバー: 永続ボリュームの使用を可能にします。
   

アクセス管理設定

Landbay は AWS IAM アイデンティティセンターを利用して、AWS API へのすべてのアクセスを制御します。Amazon EKS では、SSO ロールを Kubernetes グループにマッピングできるため、IT 管理チームを通じて Azure Entra ID グループに間接的にマッピングできます。このアプローチにより、IT 管理チームと組織の他の部門の間で関心領域を分けることができます。

上記のフラグメントを使用して、kubernetes_config_map_v1-data aws_auth リソースを設定できます:

ロールの急増を回避するために、Kubernetes は「aggregate-to-admin」を使用して他の Helm リリースからの許可を既存のグループにロールアップするメカニズムを提供します:

AWS Load Balancer Controller

サービス間の統合を強化するために、Landbay は AWS Load Balancer Controller (LBC) と外部 DNS コントローラーを活用しました。

AWS Load Balancer Controller を使用すると、イングレスから直接ロードバランサーをプロビジョニングできるほか、外部で管理されるロードバランサーを再利用してターゲットポッドを割り当てることができます。ロードバランサーのプロビジョニングを別のプロジェクトに分離することで、DevOps チームは 1 つのソースコードリポジトリでより大きな特権を持つことができる一方で、ターゲットを管理するエンジニアに作業用のツールを提供できます。

コントローラーは、必要に応じて、ロードバランサーとそのターゲット間のバックエンドでセキュリティグループも管理します。さらに、group.name アノテーションを使用することで、同じロードバランサーをバックグラウンドで複数のターゲットグループと共有できます

また、Landbay は、AWS Load Balancer Controller を使用して Network Load Balancer をプロビジョニングし、VPC 内で実行されている AWS Lambda 関数から EKS インフラストラクチャへのイングレスを許可します。

これを補完する外部 DNS コントローラーは、Route53 に対する制限された書き込みアクセスを Kubernetes ポッドに許可します。この機能により、わかりやすい DNS 名を持つ外部サービスの自動的な公開が促進され、全体的なユーザーエクスペリエンスが改善されます。

セキュリティの観点から、Application Load Balancer (ALB) コントローラーと外部 DNS コントローラーには、厳重にロックダウンできる、制限された IAM 許可セットが必要です。例えば、DNS コントローラーには、特定の Route 53 ゾーン(route53:ChangeResourceRecordSets) に対する書き込みアクセスと、いくつかの List 許可が必要です。

Kubernetes 内でのシークレット管理

ほとんどのソリューションは、シークレットのローテーションや統合など、シークレットの管理に関する問題に対処していますが、Kubernetes シークレットストレージを使用したり、外部シークレットを Kubernetes に同期したりすると、シークレットが Kubernetes の基盤となる etcd にクリアテキストで保存されます。「EKS で暗号化されたシークレット」の使用は物理的な攻撃ベクトルを軽減するのに役立ちますが、Kubernetes API 経由でアクセスすると、AWS の責任共有モデルに従って、シークレットの生の値が公開されます。

AWS が提供する Container Storage Interface (CSI) ドライバーを使用することには利点がありますが、アーキテクチャがネイティブ Kubernetes 管理から離れてしまいます。CSI ドライバーと外部プロバイダーソリューションの両方で外部シークレットプロバイダーとの直接統合が必要であることを考慮して、Landbay はマイクロサービスを AWS Secret Manager に直接統合することを決定しました。

直接統合オプションにより、環境において複雑さが増すことはなくなります (このオプションがなければ、そのような複雑さにより、メンテナンスとサポートのコストが増大する可能性があります)。コンテナボリュームにクリアテキストのシークレットが存在することも回避できるため、セキュリティがさらに強化されます。

AWS 環境における Flux のプロビジョニング

Landbay が選択した GitOps ソリューションである Flux は、EKS クラスターをブートストラップするための Terraform プロバイダーを提供します。Flux は、設定可能かつ定期的な間隔で、Git リポジトリで定義されているすべての Kubernetes マニフェストが Kubernetes にデプロイされている既存のリソースに照らして調整され、検出されたドリフトが元に戻るようにします。Flux がブートストラップされると、最初の調整が実行され、設定済みのサービス、ポッド、ステートフルセットなどが Kubernetes クラスターにインストールされます (以下の図のとおり)。

Flux は、AWS Elastic Container Registry (ECR) を Helm リポジトリとして活用できます。これは、ECR が OCI アーティファクトのファーストクラスサポートを提供しているためです。これにより、Flux は ECR と EKS の接着剤として機能し、Kustomizations を使用して環境固有の設定を適用できます。

このアプローチの主な利点の 1 つは、デプロイパイプラインの継続的インテグレーション (CI) 部分 (構築、テスト、パッケージ) と継続的デプロイ (CD) 部分 (環境への提供) が論理的に分離されていることです。セキュリティの観点から、Flux は変更をプルします。これにより、日々のデプロイのための許可を大幅にロックダウンできます。デプロイの遅延を回避するために必要な許可は、構築ツールがに早期調整を Flux に「通知」するための許可のみです。これは、制限されたユーザーを使用して、ロックダウンされた kubeconfig を通じて実行できます。

その結果、新しいマイクロサービスのデプロイ、元に戻すこと、または昇格は、YAML ファイル内のセマンティックバージョニング (semver) フラグメントの更新や、コミットを元に戻すことと同じくらいシンプルになります。Git の変更を検知すると、Flux は Kubernetes との調整をトリガーし、それに応じて関連するサービスを更新します。

Flux リポジトリ構造と共有コンポーネント

Flux は、推奨されるリポジトリ構造についての包括的なドキュメントを提供します。Landbay のアプローチは比較的シンプルで、これらのベストプラクティスに従っています。

クラスター設定は独自の専用フォルダで定義され、それぞれが共有コンポーネントを参照します。これらのクラスターフォルダ内では、Kustomizations を幅広く使用することで、クラスター間の分離が実現されます。これにより、バージョニングやメモリなどの環境固有の設定が可能になります。

上に示した構造は、コードの共有と、GitOps パラダイムの宣言的かつ明示的な性質の維持とのバランスをとっています。これにより、エンジニアは Git リポジトリを読み取り、どのコンポーネント、バージョン、パッケージがクラスターにインストールされているかを確認できます。

コンポーネントを分離することで、Landbay は新しいクラスターの構築プロセスを効率化できます。ここからのクラスターの設定作業は、「LEGO ブロック」を選択し、環境固有の設定で組み立てることだけです。

さらに、一部のクラスターはクラウドで動作し、追加のコンポーネントが必要ですが、他のクラスターはローカルで作業する DevOps エンジニア向けにすることができます。このローカル開発アプローチは、より高速なフィードバックループを提供し、AWS サービスに直接関連するコンポーネントを含みません。

足がかりとしてのローカル開発

このローカル開発アプローチは、クラウドベースの一時的な開発環境を迅速にデプロイするための足がかりでもあります。Kubernetes 名前空間を使用し、AWS マネージドサービスへの依拠を排除することで、Landbay は Flux を使用して新しい自己完結型環境を迅速にブートストラップできます。

この場合、Landbay の開発環境では、Amazon Relational Database Service (RDS) をシンプルな MariaDB コンテナに、Amazon OpenSearch Service を同等の OpenSearch コンテナに置き換えることができます。このアプローチでは、開発環境のアーキテクチャが「足並みを揃えて」(例: 類似の名前空間、サービス検出、ネットワークで) 維持されますが、運用上の回復力に欠けるというトレードオフが生じます。これは、一部の開発環境では許容できる可能性があります。

EKS、GitOps、AWS サービスの統合

Landbay では、AWS インフラストラクチャは全体的に Terraform によって管理されています。したがって、Terraform がプロビジョニングした要素 (RDS、OpenSearch など) とクラスター内で実行されている他のポッドとの間のギャップを埋めることが不可欠です。マイクロサービスで Kubernetes の設定にネイティブにアクセスするには、ConfigMap を通じて行います。

次の図は、Terraform プロジェクトと Flux プロジェクトの相互関係を示しています。

最初の Terraform プロジェクトは、すべての基本的なネットワーク、インターネットに接続されたロードバランサー、および AWS マネージドサービスの設定を担当します。2 つ目のプロジェクトは、EKS クラスターを確立し、クラスターに Flux をブートストラップして、EKS クラスターを保護するとともに、IAM ロールを設定して、Bottlerocket を実行するマネージドノードグループなどの低レベルの懸念事項を管理します。このプロジェクトは、AWS にすべての環境変数をクエリして Kubernetes に挿入する環境 ConfigMap を作成します。

最後のプロジェクトは、専用の Flux プロジェクトです。これにより、環境のクラスター設定が定義され、一連の共有コンポーネントにリンクされるとともに、関連する環境に合わせて Helm リリースと Kubernetes マニフェストが kustomizes されます。環境 ConfigMap は Flux リポジトリ内の kustomizations の一部として使用できます。また、Flux は構築後の変数置換機能も提供しており、明確に定義された一連の豊富な bash 文字列置換関数による変数置換を使用できます。

例えば、Helm チャート内では、値は構築後の変数置換を使用できます。以下の図のとおり、このアプローチにより GitOps リポジトリが強化され、共有コンポーネントが環境に依拠しなくなります。

まとめ

Landbay が Flux を通じて GitOps を採用し、Amazon EKS とより広範な AWS エコシステムの両方と緊密に統合するという決定は、大きな変化をもたらす要因となることが証明されました。この最先端のアプローチを採用することで、Landbay は多数の利点を実現し、運用を合理化するとともに、セキュリティ体制を強化できました。おそらく最も重要な利点の 1 つは、全般的に高いエンジニアリング効率を実現したことです。デプロイの高速化や待機時間の短縮から、サードパーティーソリューションのシームレスな活用まで、GitOps と EKS および AWS サービスとの統合により、Landbay の開発プロセスは大きく変わりました。

さらに、Landbay のセキュリティ環境は強化され、より堅牢で、コスト効率よく維持できるようになりました。Bottlerocket を活用し、SCM/Git 許可を介して職務を分離して、Helm を通じて簡単にアップグレードできるようにすることで、Landbay は、運用コストを最適化しながら、セキュリティへの取り組みを強化できました。

この変革的なジャーニーの最も大きな影響は、EKS ワークロードの状態と変更の可視性および透明性の向上にあります。GitOps では、設定は YAML を使用して宣言され、すべての変更は Git コミットとして保存されます。このパラダイムシフトにより、Landbay の Support、Risk、Compliance、Audit の各チームに大きなメリットがもたらされ、ミッションクリティカルなシステムに対する前例のないインサイトとコントロールを活用できるようになりました。

Landbay のようにスタートアップである貴社を変革する準備ができたら、デプロイ可能なテンプレート、AWS クレジット、学習機会にアクセスできるよう、AWS Activate にぜひご参加ください。